Re: UHC-like JavaScript backend in GHC
You also need an accomplice web server to host the JS file containing the JavaScript for the web worker to run. I don't see how you can "fork" threads without such support. On 13 November 2012 20:53, Luite Stegeman wrote: >> Does/can cabal-install support GHCJS? I suppose that's a minor advantage of >> extending GHC itself; you get cabal support almost for free. > > Yes. There are two GHCJS installation options. One is the standalone > option that includes wrappers for cabal and ghc-pkg. You use > `ghcjs-cabal` to install packages, see the result with `ghcjs-pkg > list`. The standalone compiler can be installed with cabal-install, > but it does require you to run `ghcjs-boot` in a configured GHC source > tree, to install the core libraries (ghc-prim, base, integer-gmp). > > The alternative is the integrated compiler, where you completely > replace your existing GHC with one that can output Javascript. You > don't get separate package databases this way. > >> How big are the JS files generated with either the new or the old code >> generator? I recall there was a HS -> JS effort out there that generated >> huge JS files. UHC's output is relatively compact and doesn't grow as fast >> with bigger programs. > > Relatively big for the new generator because I haven't focused on this > yet. The generated code has lots of redundant assignments that can be > weeded out later with a dataflow analysis pass. The old generator is a > bit more compact (similar to haste compiler). Both versions have a > function-level linker that only includes functions that are actually > used. > >> WebWorkers is quite limited indeed. I'm not yet sure how the serialisation >> might complicate matters, but it seems that WebWorkers is only really a >> possible backend for `fork`, and not `forkIO`. > > For one, you cannot serialize closures, so it will probably be similar > to the restrictions in Cloud Haskell in that you can only call > top-level things on the other side (Unless you don't use Javascript > closures for your Haskell closures, the new GHCJS generator can > actually move closures to a WebWorker, at least in theory, it's not > yet implemented) > > luite > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UHC-like JavaScript backend in GHC
> Does/can cabal-install support GHCJS? I suppose that's a minor advantage of > extending GHC itself; you get cabal support almost for free. Yes. There are two GHCJS installation options. One is the standalone option that includes wrappers for cabal and ghc-pkg. You use `ghcjs-cabal` to install packages, see the result with `ghcjs-pkg list`. The standalone compiler can be installed with cabal-install, but it does require you to run `ghcjs-boot` in a configured GHC source tree, to install the core libraries (ghc-prim, base, integer-gmp). The alternative is the integrated compiler, where you completely replace your existing GHC with one that can output Javascript. You don't get separate package databases this way. > How big are the JS files generated with either the new or the old code > generator? I recall there was a HS -> JS effort out there that generated huge > JS files. UHC's output is relatively compact and doesn't grow as fast with > bigger programs. Relatively big for the new generator because I haven't focused on this yet. The generated code has lots of redundant assignments that can be weeded out later with a dataflow analysis pass. The old generator is a bit more compact (similar to haste compiler). Both versions have a function-level linker that only includes functions that are actually used. > WebWorkers is quite limited indeed. I'm not yet sure how the serialisation > might complicate matters, but it seems that WebWorkers is only really a > possible backend for `fork`, and not `forkIO`. For one, you cannot serialize closures, so it will probably be similar to the restrictions in Cloud Haskell in that you can only call top-level things on the other side (Unless you don't use Javascript closures for your Haskell closures, the new GHCJS generator can actually move closures to a WebWorker, at least in theory, it's not yet implemented) luite ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UHC-like JavaScript backend in GHC
One of the main reasons we didn't do this with UHC was that we had to focus on more elementary parts of the FFI/RTS first: dynamic/wrapper imports, object interaction, etc. I must admit that I forgot the exact reasons for not converting between the types automatically, after we had finished with the first bit, though.. On 13 Nov 2012, at 19:18, Christopher Done wrote: > On 13 November 2012 16:33, J. Stutterheim wrote: >> Yes, I did check out other work that's been done in this area, albeit only >> briefly. Unless I've overlooked it (which is very much possible), none of >> the other solutions (except Fay) support an FFI that bridges the gap between >> JS's OO and the functional world, like our JS-like language in the foreign >> imports. In real-life situations, where you want to get rid of writing JS >> entirely, but still might want to use existing JS libraries such as jQuery, >> this feature is essential. > > Just a small point, but Fay's FFI differs from UHC/GHC's in that it > natively supports String/Double and functions without needing wrappers > and conversions from CString or whatnot. E.g. you write > > addClassWith :: (Double -> String -> Fay String) -> JQuery -> Fay JQuery > addClassWith = ffi "%2.addClass(%1)" > > and you're already ready to use it. If I recall in UHC last I tried, I > had to do some serializing/unserializing for the string types, and > make a wrapper function for the callback. Whether it makes any sense > for a UHC/GHC-backend to behave like this, I don't know. But people > really like it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UHC-like JavaScript backend in GHC
On 13 Nov 2012, at 19:08, Luite Stegeman wrote: > On Mon, Nov 12, 2012 at 9:16 AM, Jurriën Stutterheim > wrote: >> Hi all, >> >> foreign import js "%1.push(%2)" >>push :: JSArray a -> a -> IO (JSArray a) > > I'm not sure if it's even necessary to extend GHC itself for this. > Even though this exact syntax (with the js calling convention name) is > not supported, the import pattern is available as a string at compile > time [1], so you can easily generate the desired code with a compiler > that uses the GHC API. I work on GHCJS [2], a compiler that generates > Javascript from STG. That's an interesting approach too. If you're writing a new compiler which uses the GHC API, I agree there is probably no real need to create a separate js calling convention, although using a C calling convention for JS code might be a bit confusing. Indeed, the string is sufficient for generating the required code. UHC's string parser can probably easily be ported, as can some of the code generation parts. Does/can cabal-install support GHCJS? I suppose that's a minor advantage of extending GHC itself; you get cabal support almost for free. > Unfortunately, GHCJS is in a state of flux at the moment so it's a bit > hard to come up with a proof of concept implementation at this point. > I started a complete rewrite a few months ago, because the old version > didn't have the performance I needed. The new version [3] appears to > generate much faster code, but a lot of things (including FFI) have > not yet been implemented. It's still a bit too early to tell if the > new code generator can fully replace the old one. How big are the JS files generated with either the new or the old code generator? I recall there was a HS -> JS effort out there that generated huge JS files. UHC's output is relatively compact and doesn't grow as fast with bigger programs. > I would like to add the friendlier FFI syntax later, but as far as i > can see, it should be pretty straightforward to do this... (at least > compared to supporting many of the other GHC features in JS) Sounds like it would be pretty straightforward, yes. > WebWorkers might not be able to do what you need for concurrency, > since the ways you can communicate between them are really limited, > you have to serialize everything, no shared data. This is why GHCJS > has its own scheduler [4] in the RTS. WebWorkers is quite limited indeed. I'm not yet sure how the serialisation might complicate matters, but it seems that WebWorkers is only really a possible backend for `fork`, and not `forkIO`. > > luite > > [1] > http://www.haskell.org/ghc/docs/7.6.1/html/libraries/ghc-7.6.1/ForeignCall.html#t:ForeignCall > [2] GHCJS - https://github.com/ghcjs/ghcjs > [3] GHCJS new code generator - https://github.com/ghcjs/ghcjs/tree/gen2 > [4] GHCJS scheduler - > https://github.com/ghcjs/ghcjs/blob/master/rts/rts-trampoline.js#L244 Jurriën ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UHC-like JavaScript backend in GHC
On 13 November 2012 16:33, J. Stutterheim wrote: > Yes, I did check out other work that's been done in this area, albeit only > briefly. Unless I've overlooked it (which is very much possible), none of the > other solutions (except Fay) support an FFI that bridges the gap between JS's > OO and the functional world, like our JS-like language in the foreign > imports. In real-life situations, where you want to get rid of writing JS > entirely, but still might want to use existing JS libraries such as jQuery, > this feature is essential. Just a small point, but Fay's FFI differs from UHC/GHC's in that it natively supports String/Double and functions without needing wrappers and conversions from CString or whatnot. E.g. you write addClassWith :: (Double -> String -> Fay String) -> JQuery -> Fay JQuery addClassWith = ffi "%2.addClass(%1)" and you're already ready to use it. If I recall in UHC last I tried, I had to do some serializing/unserializing for the string types, and make a wrapper function for the callback. Whether it makes any sense for a UHC/GHC-backend to behave like this, I don't know. But people really like it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UHC-like JavaScript backend in GHC
On Mon, Nov 12, 2012 at 9:16 AM, Jurriën Stutterheim wrote: > Hi all, > > foreign import js "%1.push(%2)" > push :: JSArray a -> a -> IO (JSArray a) I'm not sure if it's even necessary to extend GHC itself for this. Even though this exact syntax (with the js calling convention name) is not supported, the import pattern is available as a string at compile time [1], so you can easily generate the desired code with a compiler that uses the GHC API. I work on GHCJS [2], a compiler that generates Javascript from STG. Unfortunately, GHCJS is in a state of flux at the moment so it's a bit hard to come up with a proof of concept implementation at this point. I started a complete rewrite a few months ago, because the old version didn't have the performance I needed. The new version [3] appears to generate much faster code, but a lot of things (including FFI) have not yet been implemented. It's still a bit too early to tell if the new code generator can fully replace the old one. I would like to add the friendlier FFI syntax later, but as far as i can see, it should be pretty straightforward to do this... (at least compared to supporting many of the other GHC features in JS) WebWorkers might not be able to do what you need for concurrency, since the ways you can communicate between them are really limited, you have to serialize everything, no shared data. This is why GHCJS has its own scheduler [4] in the RTS. luite [1] http://www.haskell.org/ghc/docs/7.6.1/html/libraries/ghc-7.6.1/ForeignCall.html#t:ForeignCall [2] GHCJS - https://github.com/ghcjs/ghcjs [3] GHCJS new code generator - https://github.com/ghcjs/ghcjs/tree/gen2 [4] GHCJS scheduler - https://github.com/ghcjs/ghcjs/blob/master/rts/rts-trampoline.js#L244 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Where has the special built-in inline function gone?
Thanks all. I've filed a bug for improving the docs. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Where has the special built-in inline function gone?
Hi Johan, On Tue, Nov 13, 2012 at 6:34 PM, Johan Tibell wrote: > Hi all, > > For the first time, I wanted to use the special built-in inline function. To > my dismay, I can't find it anywhere! On my system (GHC 7.4.2), it is accessible through GHC.Exts. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Where has the special built-in inline function gone?
Hi all,
For the first time, I wanted to use the special built-in inline function.
To my dismay, I can't find it anywhere! Here's a minimal example:
--8<-
module Main where
import GHC.Prim
f x = x + 1
{-# INLINE f #-}
g h x = inline h x
main = print $ g f 1
--8<-
$ ghc /tmp/Repro.hs
[1 of 1] Compiling Main ( /tmp/Repro.hs, /tmp/Repro.o )
/tmp/Repro.hs:8:9:
Not in scope: `inline'
Perhaps you meant `unlines' (imported from Prelude)
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UHC-like JavaScript backend in GHC
On 13 Nov 2012, at 16:17, Simon Peyton-Jones wrote: > | currently doing. Before I get started: does the GHC architecture > | currently allow for adding a new calling convention which departs from > | the conventional C FFIs and introduces a custom RTS? > > GHC certainly supports new back ends. You'd probably want to replace the > entire back end, and go from optimised Core to Javascript. Should be > entirely feasible. Good to hear! > > I'm sure you are checking out all relevant stuff, but you don't mention: > > http://www.haskell.org/haskellwiki/STG_in_Javascript > http://article.gmane.org/gmane.comp.lang.haskell.cafe/88970 > https://plus.google.com/102016502921512042165/posts/Z7NtU4eF8Zh Yes, I did check out other work that's been done in this area, albeit only briefly. Unless I've overlooked it (which is very much possible), none of the other solutions (except Fay) support an FFI that bridges the gap between JS's OO and the functional world, like our JS-like language in the foreign imports. In real-life situations, where you want to get rid of writing JS entirely, but still might want to use existing JS libraries such as jQuery, this feature is essential. > > Difficulties may be in supporting all of GHC stuff, esp concurrency. Eg the > I/O library depends heavily on concurrency, so you may need to replace it > entirely. This is indeed a tricky part, and it might not be possible to map all of it to JS, so replacing it entirely is not an unlikely option. It might be possible to implement fork in terms of WebWorkers, though. > > Keep us posted! Will do :) Jurriën > > Simon > > If not, where are > | the current major bottlenecks? And would it be possible to remove these > | bottlenecks, without significantly affecting the compilation times, and > | without affecting the performance of generated native code (when the JS > | backend is not used)? > | > | Any input on this is appreciated :) > | > | Cheers, > | > | > | Jurriën > | > | > | [1] http://uu-computerscience.github.com/uhc-js/ > | [2] http://fay-lang.org > | ___ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: UHC-like JavaScript backend in GHC
| currently doing. Before I get started: does the GHC architecture | currently allow for adding a new calling convention which departs from | the conventional C FFIs and introduces a custom RTS? GHC certainly supports new back ends. You'd probably want to replace the entire back end, and go from optimised Core to Javascript. Should be entirely feasible. I'm sure you are checking out all relevant stuff, but you don't mention: http://www.haskell.org/haskellwiki/STG_in_Javascript http://article.gmane.org/gmane.comp.lang.haskell.cafe/88970 https://plus.google.com/102016502921512042165/posts/Z7NtU4eF8Zh Difficulties may be in supporting all of GHC stuff, esp concurrency. Eg the I/O library depends heavily on concurrency, so you may need to replace it entirely. Keep us posted! Simon If not, where are | the current major bottlenecks? And would it be possible to remove these | bottlenecks, without significantly affecting the compilation times, and | without affecting the performance of generated native code (when the JS | backend is not used)? | | Any input on this is appreciated :) | | Cheers, | | | Jurriën | | | [1] http://uu-computerscience.github.com/uhc-js/ | [2] http://fay-lang.org | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
> Sounds like a bug, -fpedantic-bottoms should work here. Please open a > ticket. done [1]. [1] http://hackage.haskell.org/trac/ghc/ticket/7411 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Undocumented(?) magic "this" package-id in PackageImports
Simon Marlow writes: > Please submit a bug (ideally with a patch!). It should be documented. done -> http://hackage.haskell.org/trac/ghc/ticket/7409 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
On 12/11/2012 16:56, Simon Hengel wrote:
Did you try -fpedantic-bottoms?
I just tried. The exception (or seq?) is still optimized away.
Here is what I tried:
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs && ./Foo && echo bar
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Linking Foo ...
bar
Sounds like a bug, -fpedantic-bottoms should work here. Please open a
ticket.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Undocumented(?) magic "this" package-id in PackageImports
Please submit a bug (ideally with a patch!). It should be documented. However, note that we don't really like people to use PackageImports. It's not a carefully designed feature, we only hacked it in so we could build the base-3 wrapper package a while ago. It could well change in the future. Cheers, Simon On 13/11/2012 12:30, Herbert Valerio Riedel wrote: Hello Simon, I just found out that in combination with the PackageImports extension there's a special module name "this" which according to [1] always refers to the current package. But I couldn't find this rather useful feature mentioned in the GHC 7.6.1 Manual PackageImports section[2]. Has this been omitted on purpose from the documentation? Cheers, hvr [1]: https://github.com/ghc/ghc/commit/436a5fdbe0c9a466569abf1d501a6018aaa3e49e [2]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#package-imports ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Undocumented(?) magic "this" package-id in PackageImports
Hello Simon, I just found out that in combination with the PackageImports extension there's a special module name "this" which according to [1] always refers to the current package. But I couldn't find this rather useful feature mentioned in the GHC 7.6.1 Manual PackageImports section[2]. Has this been omitted on purpose from the documentation? Cheers, hvr [1]: https://github.com/ghc/ghc/commit/436a5fdbe0c9a466569abf1d501a6018aaa3e49e [2]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#package-imports ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
