Lisplog

Elm-css vendor prefixes

via Elm - Latest posts by @system system on Sun, 04 Oct 2020 03:18:52 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Newbie compile workflow

via Elm - Latest posts by @akoppela Andrey Koppel on Sun, 04 Oct 2020 02:23:02 GMT

Hi and welcome to the community. You can try https://ellie-app.com/. It has both saving and compiling options. As well as many other options. Good luck!

Newbie help with error

via Elm - Latest posts by @lydell Simon Lydell on Sat, 03 Oct 2020 21:04:42 GMT

You need to say what the array should contain. For example:

type alias Model = Array Int

Or if you need different things in your array in different places:

type alias Model a = Array a

Making aliases for types other than records isn’t the best approach many times. I’d just say Array instead of Model where needed.

Local access to elm documentation?

via Elm - Latest posts by @eiro Marc Chantreux on Sat, 03 Oct 2020 19:15:52 GMT

hello Matthieu,

dmy/elm-doc-preview are
able to retrieve their documentation for local usage.

even if it’s not what i expected in term of ui, this is a real
improvement to me.

thanks!
marc

Alexander Artemenko: dynamic-mixins

via Planet Lisp by on Fri, 02 Oct 2020 18:31:01 GMT

This is an interesting library which allows to add and remove mixin classes to the CLOS objects on the fly!

Common Lisp allows to change object's class, but this library goes further. It keeps track which mixins were already added to the object and allows to add new or to remove existing!

To demonstrate, how this works, let's pretend we have a graphics system where each figure can be filled with color and/or can have rounded corners. And we can have generic methods behave differently depending on traits of the figure:

POFTHEDAY> (defclass figure () ())

POFTHEDAY> (defclass box (figure) ())

POFTHEDAY> (defclass filled ()
             ((fill-color :initarg :fill-color)))

POFTHEDAY> (defclass rounded ()
             ((border-radius :initarg :border-radius)))

POFTHEDAY> (defmethod describe-object ((obj box) stream)
             (format stream "This is the box.~%"))

POFTHEDAY> (defmethod describe-object :after ((obj rounded) stream)
             (format stream "It has round corners.~%"))

POFTHEDAY> (defmethod describe-object :after ((obj filled) stream)
             (format stream "It filled with color.~%"))

Now we can construct the box object and simulate how it evolves over time when the user decides to make it's corner smoother and to fill it with a color:

POFTHEDAY> (defparameter *obj* (make-instance 'box))

POFTHEDAY> *obj*
#<BOX {10016F64A3}>

POFTHEDAY> (describe *obj*)
This is the box.

;; Now we'll add a trait to our object:
POFTHEDAY> (dynamic-mixins:ensure-mix *obj* 'rounded)

POFTHEDAY> *obj*
#<#<DYNAMIC-MIXINS:MIXIN-CLASS (ROUNDED BOX) {100A46CDB3}> {10016F64A3}>

POFTHEDAY> (describe *obj*)
This is the box.
It has round corners.

;; And yet another trait!
POFTHEDAY> (dynamic-mixins:ensure-mix *obj* 'filled)

POFTHEDAY> (describe *obj*)
This is the box.
It has round corners.
It filled with color.

;; We also can remove a mixin:
POFTHEDAY> (dynamic-mixins:delete-from-mix *obj* 'rounded)

POFTHEDAY> (describe *obj*)
This is the box.
It filled with color.

The only problem I found is that it is impossible to pass initargs to the ensure-mix function. Because of that, slots which we added along with the mixin, remain unbound.

But I found the solution to this problem:

POFTHEDAY> (defun add-mixin (object mixin-class &rest initargs)
             (let ((new-class (dynamic-mixins::ensure-mixin
                               (funcall #'dynamic-mixins::%mix
                                        object mixin-class))))
               (apply #'change-class object new-class initargs)))

POFTHEDAY> (slot-boundp *obj* 'fill-color)
NIL

;; Now we'll remove and add this mixin again:
POFTHEDAY> (dynamic-mixins:delete-from-mix *obj* 'filled)

POFTHEDAY> (add-mixin *obj* 'filled
                      :fill-color "#FF7F00")

POFTHEDAY> (slot-boundp *obj* 'fill-color)
T

POFTHEDAY> (slot-value *obj* 'fill-color)
"#FF7F00"

Hope, Ryan Pavlik will incorporate my pull request with this additional function!

If you are found this post interesting, then you also might like a post about dynamic-classes system.

Local access to elm documentation?

via Elm - Latest posts by @eiro Marc Chantreux on Fri, 02 Oct 2020 21:18:40 GMT

hello people,

I would like to get a local/cached version of the documentation (ideally in a pure text or troff format). i really don’t know the elm ecosystem at all but i imagine there is no such thing available.

if there isn’t, is there a way to query https://package.elm-lang.org/ with a rest API to know what is the URL of the page i need to download locally.

for example: from the key “String”, i would like to access to https://package.elm-lang.org/packages/elm/core/latest/String but i haven’t found a rest API to do so.

any help to do so (or link to existing tool) would be very welcome!

thanks
marc

Elm-music-theory: A toolkit for musical ideas

via Elm - Latest posts by @duncanmalashock Duncan Malashock on Fri, 02 Oct 2020 12:44:12 GMT

I would be curious to hear what tools you think would be most beneficial to those two groups to have at their disposal.

My approach to answering this question in general has been to learn from the creative processes of composers and musicians, and learn to model the techniques involved in the decisions they make.

Here is one such technique I’m working on modeling, which is giving me some trouble; I wonder if any of the folks here might be interested in discussing it, because I feel the design of a solution would benefit from some discussion with both engineers and musicians:

Generating variations on a melody
One technique that composers use a lot is a melodic sequence. The term “sequencing” means taking a melodic line or motif and changing it, while retaining some of the characteristics of the original version.

The opening of Beethoven’s 5th Symphony is one of the most famous examples of a series of melodic sequences:

First the motif: G G G Eb – three of the same note followed by one note that’s lower
Then a variation: F F F D – similar but starting on a different note
Two more variations follow: Ab Ab Ab G, Eb Eb Eb C

Similar to the functionality of generating possible solutions to the problem of voicing a chord that I described in the original post, I think modeling the features of a melodic line and generating variations on it would be very helpful as a compositional tool, and almost essential if your goal was to generate music procedurally (e.g. to generate, say, bebop lines over a set of chord changes).

How to model an abstracted melody in this way?

A simple approach might be to model it as integer differences between notes on the scale it occurs in. Variations could be created by using different starting notes, and/or different scales.

analyzeMelody : Scale.Scale -> List Pitch.Pitch -> List Int

generateVariation : Scale.Scale -> Pitch.Pitch -> List Int -> List Pitch.Pitch

original : List Pitch.Pitch
original =
    [ Pitch.g4
    , Pitch.g4
    , Pitch.g4
    , Pitch.eFlat4
    ]

abstractMelody : List Int
abstractMelody = 
    analyzeMelody (Scale.minor PitchClass.c) original
    -- [ 0, 0, -2 ]

variation : List Pitch.Pitch
variation =
    generateVariation (Scale.minor PitchClass.c) Pitch.f4 abstractMelody
    -- [ Pitch.f4
    -- , Pitch.f4
    -- , Pitch.f4
    -- , Pitch.d4
    -- ]

This works well, but only under these assumptions:

1. A melody uses only one scale
2. A melody uses only pitches contained in the scale
3. Each pitch in a scale is an equally viable possibility
4. A variation should maintain the same scale steps, in the same directions, as in the original

All of these assumptions, unfortunately, break down very quickly:

(1) does not describe the many melodies and melodic fragments that are written across chord changes. Chord changes often imply a change in scale, so a melodic variation should be able to be specified in a way that includes transitions between scales.

(2) leaves out chromatic notes in melodies. The opening line of “When You Wish Upon a Star” is one example of a simple melody that nonetheless includes notes outside the scale.

(3) ignores the distinction between stable and unstable tones. This means some notes are not good options to emphasize in a melody because of their relationships to the current harmony. This idea varies with musical idiom; in classical music, any note that is not in the chord must be resolved. In jazz, all notes in the scale are available except for so-called “avoid notes”.

And (4) ignores the usefulness of variations that adjust the direction or distance of pitch transitions (like the variation Ab Ab Ab G from before).

How can these aspects of melody be modeled in a way that lends itself to the generation of variations? And how can this variation process be parameterized in a helpful way?

I have tried to model in terms of a current harmonic context, and a melody note’s relationship to it, and have some preliminary code working to generate variations in this way, but I am not happy with my designs so far.

I am considering modeling in terms of techniques for resolving nonharmonic tones like escape tones and anticipations. This might have the benefit of being easily understood by musicians, but given that one of my design goals is for designs to apply broadly across musical styles, I wonder if this will be successful in other musical contexts like jazz.

I would be very happy to hear anyone’s input on this, particularly if you have experience with these musical ideas.

Svg-folder-to-elm-module: import SVG icons into your elm codebase

via Elm - Latest posts by @FranzSkuffka Jan Wirth on Thu, 01 Oct 2020 22:38:02 GMT

Thanks!

I reckon by ‘normal mode’ you mean using --optimize to do dead code elimination like explained in https://elm-lang.org/news/small-assets-without-the-headache#dead-code-elimination ?

Can you use elm-ui or elm-css to make a child element display when hovering over its parent element?

via Elm - Latest posts by @system system on Thu, 01 Oct 2020 15:37:14 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Parsers with Error Recovery

via Elm - Latest posts by @rupert Rupert Smith on Thu, 01 Oct 2020 13:09:50 GMT

Released what I have done so far.

On the whole, I’m not completely satisfied with the result, but at least I have a recoverable implementation of sequence which is enough for me to work with for now.

The main issue for my dissatisfaction is that using recovery tactics might recover from an immediate problem, but if that is nested inside something else, the recovery is not going to take the full context into account. So if you had a List embedded inside some other code, but you left out the closing ], it might fast foward to another ] higher up the syntax tree, and then things will just get in a mess. What is really needed is a way to neatly tie up all loose ends as the parser recovers up through higher levels - and that is what the algorithms in the ‘ell’ parser paper do.

The full auto error recovery implementation will have to wait for another time, as I already spent too long getting this far, but I feel sure the idea is viable.