November 2007 - Yhc - Haskell.org

Lack of monomorphism harms Bernouilli nofib benchmark
by Neil Mitchell 30 Nov '07

30 Nov '07

Hi, I was benchmarking, and Bernouilli has a bit: powers = [2..] : map (zipWith (*) (head powers)) powers Hugs and GHC both see powers :: [[Integer]] and a beautiful CAF. Yhc (and nhc) both see powers :: (Enum a, Num a) => [[a]] and no CAF. This is going to be a severe performance bottleneck! First, can someone with slightly more knowledge check I've got this right. Second, do we "fix" the nofib suite, since the monomorphism restriction is a bit evil and generally to be avoided. Third, do we "fix" nyhc. Fourth, should we care about silly benchmarks. Thanks Neil

1 0

Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend
by Thomas Hartman 27 Nov '07

27 Nov '07

Fair enough, I can wait for a couple of days. You might want to fix thartman@none:~/haskell-installs/yhc-install/yhc/src/translator/js/test>darcs whatsnew { hunk ./src/translator/js/test/Makefile 12 - $(YHC) -includes ../lib/haskell -linkcore $< + $(YHC) --includes ../lib/haskell --linkcore $< } immediately though. This is the only makefile for the javascript stuff in the repo, and it doesn't work because of - instead of --. Given your darcs log message that the javascript compiler would be broken I initially assumed that was the reason and not a flags change. More questions. So okay, it builds, I have Test1.html. It's a blank file with a bunch of javascript. I have firebug, so I can ask execute stuff in the javascript console. But I can't figure out what to execute. factorial isn't there, nor sumlst... none of the interesting looking functions? So what is this supposed to do? And can I change the makefile so that at least it generates javascript where I can execute the interesting functions in the firebug console? thomas. 2007/11/26, Dimitry Golubovsky <golubovsky(a)gmail.com>: > Thomas, > > OK, let's try to get on the same page regarding where the project is. > > The Javascript generator is maybe not optimal, but it works. > > DOM bindings are generated from W3C's IDL files, so everything DOM > provides may be used by Haskell programs, whether in CPS notation, or > monadic, this will become clear, which form to use, in the near > future. > > The recent HsWTKDemo works well in major browsers (FF, MSIE, Opera) > except for Safari, but this is probably a hard case due to the lack of > debugging information. > > If you look at its source http://darcs.haskell.org/yhc/web/jsdemos/HsWTKDemo.hs > > (no, you cannot compile it at the moment because it is plain CPS) you > may see some stuff related to static page layout definition in > declarative way (look for upcntW, factW, etc.) This part is almost > finalized wrt notation. What's left undecided is whether to use plain > CPS notation, or monadic notation for parts of the code that involve > imperative stuff (see e. g. updateD function where node's children are > replaced in order to update what's displayed). > > This all works perfectly in plain CPS. Understanding that nowadays > Monads are mainstream, I am trying to adopt monadic notation based on > the Cont monad instead of plain CPS. I ran one example (EchoM) on MSIE > and noticed memory leaks on each user's action. However when the page > is unloaded, MSIE shrinks in size which is a good sign. I think I know > where the cause is, tonight I'll try to fix it. If unsuccessful, I'll > probably unroll all monadic changes. > > Next steps are: > > 1. Finalize the code notation for static layout and imperative part > and check the base library into the Yhc repo > > 2. Generate haddock documentation > > 3. Write a better documentation for developers > > 4. Set up a web service that would allow everybody to submit their > Haskell source and generate HTML page with Javascript in response; > this I think can be done based on the hpaste program (backed by > Happs). > > Just for now, you have to wait a couple days while I am straightening > the monadic thing out. I'd appreciate if you look at the code of > HsWTKDemo and give me your impressions about notation, etc. > > Thank you. > > -- > Dimitry Golubovsky > > Anywhere on the Web >

1 0

idea for ycr2js demo, actually meant for an in-house project. is this realistic?
by Thomas Hartman 27 Nov '07

27 Nov '07

As I mentioned in a previous post, I've been spending quite some time trying to get live with ycr2js because there's a project it would be useful for for my day job, as well as making another nice demo to add to the list. Basically, I have some functionality that does client-side filtering of large html tables. It's pretty smart -- it can filter on multiple columns, and the filter can be any javascript expression from String -> Bool (to use haskell terminology in a javascript context). The filter works by hiding rows that don't match the filter; it's built on mochikit. Unfortunately this is rather ugly from the user's perspective. You have to type something like x.match("my string") into the search string or (x > 5 && x < 7) where x is some variable buried in the javascript. I would like for the user to be able to enter search criteria in a more intuitive "google" style =skittles or (=~"mr. goodbar" and =~"15 grams") so you need a parser that takes the search criteria and converts it into a function from (String -> Bool) This parser is relatively easy to build in haskell; I built it. It's surely also doable in javascript, but not as nicely, easily, and cleanly, and being a better haskell than javascript programmer as well, I would rather generate the javascript from haskell. So at any rate what I have is -- parser from String -> (String -> Bool) (haskell) -- working html/javascript built on mochikit that filters a multicolumn table with multiple filter expressions. There is a function here that takes a string and returns a bool, but it's icky, doesn't recognize quoted strings, doesn't recognize boolean and/or or parentheses. I want to replace it with a function generated from haskell that does all of these things. What I need is to combine these two components. I'll try and post some minimal source code for the parser and the javascript/mochikit stuff soon, and if this problem is tractable it can become another example for ycr2js. A possible reason why this wouldn't work is that when you're using the ycr2js stuff, *everything* has to be generated; it doesn't play well plugging in an existing javascript function with a generated one. I'd be surprised if that was the case, but since I haven't actually successfully generated any code yet i guess anything possible. At any rate, if this sort of thing could cause issues please someone in the know give me fair warning. thomas.

1 0

Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend
by Dimitry Golubovsky 27 Nov '07

27 Nov '07

Thomas, All published examples (source, html) go into web/jsdemos subdirectory (from the root of the Yhc repo source tree). Not all of them may be compilable at the moment though (and some will never be compilable in the future, just kept there for historic reasons - that's why they are not being tested by the buildbot). I am currently going through transition from plain CPS to Cont monad, so regular monadic notation can be used instead of CPS. However I am experiencing memory leaks in MSIE (try the EchoM example) which I did not expect to happen (never had them in plain CPS). If I cannot fix that I'll roll back to plain CPS. On 11/26/07, Thomas Hartman <tphyahoo(a)gmail.com> wrote: > It would be really helpful if you could include this (and other) > examples in an /examples directory under > > src/translator/js > -- Dimitry Golubovsky Anywhere on the Web

2 1

Re: [Haskell-cafe] yhc install fails
by Neil Mitchell 22 Nov '07

22 Nov '07

Yhc people: On Nov 21, 2007 8:46 PM, Thomas Hartman <tphyahoo(a)gmail.com> wrote: > I'm having the devil of a time getting yhc to install. > > http://hpaste.org/4028 > > or for posterity > > root@none:~/yhc-install/yhc>scons > > ... blah blah blah... > > Compiling PreludeAux ( src/packages/yhc-base-1.0/PreludeAux.hs ) > YHC_build(["src/packages/yhc-base-1.0/Foreign/Util.hbc"], > ["src/packages/yhc-base-1.0/Foreign/Util.hs"]) > inst/bin/yhc --core --cpp -c src/packages/yhc-base-1.0/Foreign/Util.hs > Compiling Foreign.Util ( src/packages/yhc-base-1.0/Foreign/Util.hs ) > YHC_build(["src/packages/yhc-base-1.0/Foreign/C/String.hbc"], > ["src/packages/yhc-base-1.0/Foreign/C/String.hs"]) > inst/bin/yhc --core --cpp -c src/packages/yhc-base-1.0/Foreign/C/String.hs > Error: File not found, Foreign.Storable > Reason: imported from Foreign.C.String > Looked in: > /root/yhc-install/yhc/src/packages/yhc-base-1.0/ > /root/yhc-install/yhc/inst/lib/yhc/packages/yhc-base/1.0 > scons: *** [src/packages/yhc-base-1.0/Foreign/C/String.hbc] Error 1 > scons: building terminated because of errors. > > > root@none:~/yhc-install/yhc>ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.1 > > advice? > > thomas. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend
by Dimitry Golubovsky 18 Nov '07

18 Nov '07

Bit, On Nov 18, 2007 8:41 AM, Bit Connor <bit(a)mutantlemon.com> wrote: > > Safari 3.0.2 for windows gives an error though: > > Maximum call stack size exceeded. > http://darcs.haskell.org/yhc/web/jsdemos/HsWTKDemo.html Line: 87 This is in fact a huge progress for Safari ;) Year ago, Safari on Mac gave some weird error message "Type Error line 1". See http://osdir.com/ml/lang.haskell.yhc/2006-11/msg00033.html The problem is, I am not sure how it enumerates lines. Lines around 87 (ran with pr -n): 83 var consStr = function (s) { 84 if (s.length == 0) { 85 return new HSEOL (); 86 } else { 87 var hdc = mkChar (s.charCodeAt (0)); 88 return new HSCons (hdc, s.length > 1 ? s.substring (1) : consStr ("")); 89 }; 90 }; Nothing suspicious because mkChar is a wrapper around the Number constructor. Line 314: 312 function NEG_D(a) { 313 return -(exprEval(a)); 314 } and so on. > > Sometimes it gives the same error but instead of line 87 with line > 314, and other times line 224 or 422 But does it at least display the widgets? Or do these errors appear as you press buttons/type anything? > > Are you aware of this issue? Now I am ;) But to me not being an expert in Safari, these error messages do little help (or if at least I knew what actual lines they meant)... Thanks. -- Dimitry Golubovsky Anywhere on the Web

1 0

New demo/test program for Yhc Javascript backend
by Dimitry Golubovsky 17 Nov '07

17 Nov '07

Hi, For those of you who are interested in using Haskell in client-side web application programming: I have added a new demo/test program to this Wiki page ("Does it leak?"): http://haskell.org/haskellwiki/Yhc/Javascript This demo program shows some progress made since the first announcement of Yhc Javascript backend (Core to Javascript converter) was made about a year ago. Please test the demo for functionality and memory leaks in various browsers. Your feedback is appreciated. The demo program is self-contained (does not require any Haskell libraries beyond those included with Yhc). There is a darcs repo: http://www.golubovsky.org/repos/wsptest/ from which this demo program along with Makefile can be obtained if anybody wants to play with the code. Thanks. -- Dimitry Golubovsky Anywhere on the Web

1 0

Proposed replacement for Yhc's build system using CMake
by Mathieu Boespflug 09 Nov '07

09 Nov '07

Hi all, I've had this for a while on the back burners, so I'm releasing it now lest I forget about it completely. I have a set of patches to replace the existing SCons based build system for Yhc with a new build system based on CMake. You can get them by pulling from http://code.haskell.org/~mboes/yhc.cmake The rationale for this is that SCons is very slow and never worked on my platform, neither has it worked for other people too, I am told. Successive attempts to fix the many problems on my platform just caused more problems and the overhead associated with tinkering and refactoring python files for simple build tasks led me to consider reimplementing the build system using a different build framework. The goals for the new build system are simplicity and portability. GNU autotools, affectionately known by many as autohell, are not suitable here because they do not work natively on Windows (cygwin or MSYS is required). Neil emphasized the importance of not imposing on the user the need for a working cygwin installation simply to compile Yhc. This narrows down the choice of build frameworks quite a bit, and it seems to me like CMake is our best option here in that it is likely to require the least effort in supporting both the Windows and the various Unix like platforms. Other options were to remain with SCons but signifantly rework the code, or to switch to waf. Both options require a working python installation and I am far from convinced that writing Python code is the way to specify builld dependencies. Other build frameworks simply did not seem to provide much in the way of cross-platform automatic configuration. What's more CMake seems to be gaining a lot of traction lately, with several high profile projects switching to CMake, such as KDE4 (after having seriously considered bksys/waf), OpenSceneGraph, Scribus and others. It seems to be well maintained and build an active community around it. The principle of CMake is that build rules are specified using a custom language from which regular Unix Makefiles are generated, or MS Visual Studio project files, or something else, depending on the available options on your platform. The only prerequesite is a C++ compiler for building CMake on your platform and a working make. I propose here a number of patches. The first set of patches is for adding the CMake build system. Currently this system can build the Yhc compiler, the C runtime, libffi and yhe the GUI environment. The building of Haskell sources is offloaded to Cabal whenever possible, and libffi is currently built and configured by calling out to its autoconf configure script and automake generated Makefile. This should make it easier to update libffi from upstream. Currently there is no support for building the Yhc libraries (ie the src/packages directory), because ideally that would be done through Cabal but Cabal does not support building with Yhc, yet. An interim solution would be needed in the interim until Cabal gains proper dependency discovery and Yhc support. Patches names: * Introducing CMake for Yhc. * Introduce CMake build system for BCKernel runtime. * Cabalize src/interactive so that it may be build with CMake. * Create cmake/modules dir and put CMake helper files in there. * Add support for building libffi from CMake and make it a dependency for building BCKernel. * Add ability to build BCKernel with no dynamic linking support and add extra test s to find dlopen on Linux systems. * Fix the fetch target in toplevel CMakeLists.txt. In addition to the libffi from gcc-4.2 patch. The second set of patches removes SCons scripts that are sprinkled around the repository. I believe this set of patches could be applied at a later date, to allow the SCons build system and the CMake build system to cohabit for a while, pending the CMake system surpassing the SCons system in every way and getting a good shaking out for any lurking bugs. However, the SCons system will need to be modified to work with the updated libffi (see separate message on this mailing list). Patch names: * Remove scons build system. * Remove scons files in src/interactive/. * Remove SCons files for building libraries. * Remove scons files for building runtime. * Remove scons files for build src/tester. The third set of patches remove a number of unused Makefiles which seem to be holdovers from a previous build system and were never used by the Scons based build system. These patches can be applied now and probably wouldn't break anything, if indeed the files removed are not currently used. Patch names: * Remove top level Makefile and configure scripts. * Remove seemingly unused Makefile in src/interactive. * Remove Makefiles in libraries, holdover from a prior build system. * Remove msvc files in BCKernel directory. * Remove src/runtime/Makefile. So there goes. I would appreciate any feedback on this proposed system and as much testing as possible on as many platforms as we can get our hands on. I have tested the builds on FreeBSD 7 and on Ubuntu Linux 7.10 but I have not tested on other platforms. Most notably, it would be great if someone could take care of making this work on Windows, since I don't have any Windows box at hand to test this on. Porting to Mac OS X might require some work too, I'm not sure. Beyond building the libraries, further work would include integrating the ycr2js translator into the build system. Here's a short synopsis of how to use the new system. Install CMake (apt-get cmake or equivalent on your platform). After pulling the set 1 patches into your local yhc repo or creating a new repo, do the following at the root of the repo: $ cmake . # note the period after cmake. $ make fetch # fetches all the libs and tools in other darcs repos yhc depends on $ make yhc # for the compiler $ make yhi # for the C runtime $ make yhe # for the GUI environment Alternatively you can $ cmake . $ make To do all the above. make fetch only creates those repos that are missing, essentially running a "darcs get" as appropriate. A regular "darcs pull" will grab new patches for the Yhc repo but to update all the dependencies wrt to their main darcs repo you can $ make update Caveat: cmake generates a Makefile in src/runtime/BCKernel, overwriting the existing Makefile in that directory currently used by nhc98. The nhc98 Makefile will probably need to be renamed or something. In addition to the docs on the cmake.org website, there are some tutorials to get you started at http://www.linuxjournal.com/article/6700 and a subscribers only Linux Magazine article that you can nevertheless access through Google's cache by searching "cmake: make reloaded". All the best, Mathieu

3 4

Yhc autumn cleaning
by Dimitry Golubovsky 09 Nov '07

09 Nov '07

Hi, One side note to the cleaning process: Once I have added a piece of code to the toplevel Sconstruct which helps push changes from within a firewall by running ssh that forwards the connection. ============================== elif "push" in COMMAND_LINE_TARGETS: fw = ARGUMENTS.get("fw", "") if fw == "": os.system("darcs push --no-set-default neil@darcs.haskell.org:/home/darcs/yhc") os.system("darcs push --no-set-default neil@darcs.haskell.org:/home/darcs/york-compiler98 --repodir=src/compiler") else: print "Pushing via firewall - you may be asked for passwords multiple times" os.system("export SSH_PORT=2222;" + \ "ssh -L $SSH_PORT:darcs.haskell.org:22 -f " + fw + " sleep 1000;" + \ "darcs push --no-set-default neil@localhost:/home/darcs/yhc;" + \ "darcs push --no-set-default neil@localhost:/home/darcs/york-compiler98 --repodir=src/compiler") env.Alias("push", []) ============================== so one can run "scons push fw=hostname" and get around a firewall. I'd like that this logic be kept in the new build system, whatever it will be, so what would be the best place to plug it in? With scons, that was just an additional `if ' statement that analyzes the command line. Also, eventually there will come time to integrate the Javascript backend into the new build system: what can be recommended for this? Currently there is a Makefile within the backend, so in order to build and install it, one just runs this (from the top source directory): (cd src/translator/js; make all install) after Yhc itself has been built and installed. Thanks -- Dimitry Golubovsky Anywhere on the Web

2 1

Yhc autumn cleaning
by Mathieu Boespflug 07 Nov '07

07 Nov '07

Hi again, Perusing around the source repository I noticed that there are a bunch of files and directories that seems unused. Here is a list of patches to remove these. They can be pulled from http://code.haskell.org/~mboes/yhc.cmake Patch names: * Remove Make/ from src. * Cleanup the misc/ directory. * Remove the src/compiler98 folder, which is now unused. * Remove msvc files in BCKernel directory. * Remove toplevel test/ dir. It looks unused. These patches are just to flag potentially obsolete files in the repository. Let me know if any of these files are still used and I can make new patches for inclusion into the main darcs repository. Regards, Mathieu

3 4