How to generate elm-runtime-0.5.5.js?

[Piotr Adamski]

Hi!

I've just forked elm and made some changes in compiler. Now it's time to test it, but I stumbled upon a problem: generated files refer to file:///home/piotr/.cabal/share/Elm-0.5.5/elm-runtime-0.5.5.js which is not there. Installing package with cabal fails because it doesn't exist in repository. As a workaround I renamed its 5.0.2 version which was there. Basic examples work, but still, it would be nice to test it with proper version :) Is there a way to generate it by myself or it has to be pushed to upstream by Evan?

Regards

Piotr 

[Evan Czaplicki]

I just uploaded the new version of the RTS, so you should be good to go. I only hesitated to put it up because I am not totally set on a version number for the next release :)

If you want to build the RTS yourself, the cat.bat file in core-js/ will concatenate all of the necessary JS files and build the elm-runtime-x-y-z.js file. It is a Windows specific command in there, but I think it should be fairly straightforward to translate it to the corresponding UNIX version. Tell me if you have problems with this.

Hope that helps!

Evan

[Piotr Adamski]

Thanks! Helps a lot.

As a side question, have you thought about way of exposing right runtime version to be used with certain elm compiler version? You can override path for it with '-r' compiler option, but there is no safe and automated way of getting information which file to put on that path. I'm experimenting with elm plugin for play framework 2 and that matter is the most problematic for me so far.

Regards

Piotr 

[Evan Czaplicki]

No problem :)

The RTS should have exactly the same version number as the compiler. So the Elm-0.5.0.2 compiler is packaged with the elm-runtime-0.5.0.2 runtime system. The compiler and the RTS are very closely related so neither would get updated without the other.

Is that the kind of thing you mean?

Also, the past versions of the RTS should be availible on github if you look back a number of patches. I recently got rid of a bunch of them which were cluttering everything up but are essentially deprecated.

[Piotr Adamski]

If it comes to me copying that file - it is more than enough :) But in case of building a plugin, right now i have to either maintain mapping of elm version to corresponding runtime file link on github or locate it on users system which looks like nontrivial task, mainly because of supporting different operating systems. I imagine it myself as compiler option, like '--with-hosted-runtime', which would put correct link in compiled htmls. At the same time, something that would output path to right file on users file system would also work. I'm willing to make a patch for it to happen, still your opinion and vision on how should it be done is very important for me too :)

Piotr 

[Evan Czaplicki]

I think there are a bunch of options here:

- The Haskell library for Elm exposes the location of the runtime system in a platform independent way. That is how I get elm-server working even though it is a separate package. The value you'd want is Language.Elm.runtimeLocation which should be accessible by importing the Language.Elm module in any Haskell program. Should have mentioned this earlier! (For some reason this value does not show up on Hackage, but it is definitely part of the latest release of Elm.)

- Use the hosted runtime idea. The --runtime-location flag specifies a URL. It is often specified as a relative path so I can run it on any domain I want, but you can definitely give an absolute path or HTTP address for the runtime location.

- Distribute as a standalone .js file. Users can use the --include-js flag to import the file into their project.

Do any of these options work for you? Do you expect that your code will be highly version specific or implementation specific?

Also, this issue has not come up before, so if you feel like you need something just let me know. It is likely missing because I have not thought about it, not because it is difficult or un-Elm-y. Can you tell me a bit more about your project? Maybe I can come up with a way to make it easier to create libraries and extensions in general.

[Piotr Adamski]

W dniu niedziela, 25 listopada 2012 22:36:33 UTC+1 użytkownik Evan napisał:

Also, this issue has not come up before, so if you feel like you need something just let me know. It is likely missing because I have not thought about it, not because it is difficult or un-Elm-y. Can you tell me a bit more about your project? Maybe I can come up with a way to make it easier to create libraries and extensions in general.

Then I'll start from the end. After some time of coding in Scala and Play Framework I got fed up with writing javascript/coffeescript code and turned into looking for some replacement. Elm feels for me like getting work done the right way and . And even though marriage of play and elm doesn't look like easy thing, I want to try. I don't know yet how exactly I'll make it and what changes would it require, but as soon I'll learn that - expect questions or pull requests from me, like today ;) 

 

I think there are a bunch of options here:

- The Haskell library for Elm exposes the location of the runtime system in a platform independent way. That is how I get elm-server working even though it is a separate package. The value you'd want is Language.Elm.runtimeLocation which should be accessible by importing the Language.Elm module in any Haskell program. Should have mentioned this earlier! (For some reason this value does not show up on Hackage, but it is definitely part of the latest release of Elm.)

- Use the hosted runtime idea. The --runtime-location flag specifies a URL. It is often specified as a relative path so I can run it on any domain I want, but you can definitely give an absolute path or HTTP address for the runtime location.

- Distribute as a standalone .js file. Users can use the --include-js flag to import the file into their project.

Do any of these options work for you? Do you expect that your code will be highly version specific or implementation specific?

My first attempt is to call compiler as a subprocess from plugin code. That couples it loosely to elms version and implementation. The problem I have is to generate correct html code that point to valid runtime library location. Running it localy makes it work perfectly with value from Language.Elm.runtimeLocation. For deployed Play application I need to put that file in servers assets, so it it is reachable for clients. I can do some shell script magic to retrieve path of runtime library and copy it from there, as well as hardcoding github url to the latest one. Thus, I'm concerned that it can brake when elm installation on certain machine is customized or someone uses ancient version of elm. The greatest solution would be compiler giving me runtime library file, that it is compiling html files against, or telling me where i can find get it from. And none of those option is able to do that unfortunately. But so far it's not that big issue for me as I'm experimenting only on my own machine where I can safely link to github or local fiel. I was just courious if it can be done somehow already or if you have any plans to implement such functionality :)

Piotr

[Evan Czaplicki]

If I understand you correctly, Language.Elm.runtimeLocation should do the trick. It points to the runtime system that goes with the installed version of Elm. So if you have Elm-0.5.0.2 installed, Language.Elm.runtimeLocation will point to elm-runtime-0.5.0.2.js. This is true for any version of Elm: the compiler is paired with a particular runtime system.

So for all numbers x, y, and z, the Elm-x.y.z compiler is packaged with an elm-runtime-x.y.z.js which can be accessed with Language.Elm.runtimeLocation.

Perhaps I am not familiar enough with the Play framework to understand where this approach goes wrong. Do you want to host code compiled by many different versions of the compiler?

Also, at this point, it is fairly safe to assume that Elm users are upgrading to the latest version of Elm. Elm has had very few breaking changes so far, so upgrading has never been a huge hassle for users as far as I know.