From mboes at tweag.net Tue Nov 6 08:38:46 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Tue Nov 6 08:35:51 2007 Subject: [Yhc] Proposed replacement for Yhc's build system using CMake Message-ID: <63c0799b0711060538v47f3c0f9j6895251c4939171b@mail.gmail.com> 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 From mboes at tweag.net Tue Nov 6 08:57:57 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Tue Nov 6 08:55:00 2007 Subject: [Yhc] Replacing libffi with version distributed in gcc-4.2 Message-ID: <63c0799b0711060557r701a20f2u7034021f427713af@mail.gmail.com> Hi all, Here is another proposed update for the YHC repository. Currently as part of the build process either a snapshot is downloaded or a subversion checkout is made on the libffi sources as found in the Python subversion repository. When delving into the scons build system for Yhc the first thing I did was import a version of libffi into the Yhc repository. The build system shouldn't pull something of the Internet every time a target needs to be built and make that target fail when an Internet connection is not available. Also, isn't it best to compile against a version that the Yhc developers know to work, reimporting libffi from upstreams as the developers see fit and as the developers get time to test that it works fine? Instead of importing libffi from the python sources, I propose using another, more complete version. libffi does not seem to be currently maintained due to copyright issues but there seems to be a version of it distributed by gcc-4.2 which is much more recent and complete. I get the impression that version works on all platforms gcc has been ported to (could be wrong though). However, the version in gcc-4.2 uses autotools to build, so I've also imported two other versions of libffi into the tree, libffi-arm_wince and libffi-msvc for building Yhc on windows platforms. The gcc-4.2 version is in depends/libffi/default whilst the other two are in depends/libffi/{arm_wince,msvc}. The CMake based build system has support for building libffi-gcc-4.2, but not the wince and msvc versions, since I don't have any windows machines at hand to test this. Could some windows guru take care of getting libffi to work with CMake on Windows platforms? The patch for importing this new libffi version can be pulled from http://code.haskell.org/~mboes/yhc.cmake Regards, Mathieu From mboes at tweag.net Tue Nov 6 09:10:22 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Tue Nov 6 09:07:29 2007 Subject: [Yhc] Yhc autumn cleaning Message-ID: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> 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 From shackell at cs.york.ac.uk Tue Nov 6 09:12:12 2007 From: shackell at cs.york.ac.uk (Thomas Shackell) Date: Tue Nov 6 09:12:21 2007 Subject: [Yhc] Replacing libffi with version distributed in gcc-4.2 In-Reply-To: <63c0799b0711060557r701a20f2u7034021f427713af@mail.gmail.com> References: <63c0799b0711060557r701a20f2u7034021f427713af@mail.gmail.com> Message-ID: <4730763C.9040700@cs.york.ac.uk> Mathieu Boespflug wrote: > Hi all, > > Here is another proposed update for the YHC repository. Currently as > part of the build process either a snapshot is downloaded or a > subversion checkout is made on the libffi sources as found in the > Python subversion repository. When delving into the scons build system > for Yhc the first thing I did was import a version of libffi into the > Yhc repository. The build system shouldn't pull something of the > Internet every time a target needs to be built and make that target > fail when an Internet connection is not available. Also, isn't it best > to compile against a version that the Yhc developers know to work, > reimporting libffi from upstreams as the developers see fit and as the > developers get time to test that it works fine? Agree entirely, I never really understood why compiling Yhc should insist on an internet connection. > Instead of importing libffi from the python sources, I propose using > another, more complete version. libffi does not seem to be currently > maintained due to copyright issues but there seems to be a version of > it distributed by gcc-4.2 which is much more recent and complete. I > get the impression that version works on all platforms gcc has been > ported to (could be wrong though). At the time we made the choice we considered both the python ctypes version and the gcc version. In the end we rejected the gcc version because it didn't have any support for the windows platform, whereas the python version had been modified by the ctypes people so that it did. Now it's entirely possible that this has now changed and the gcc version supports windows, including use with MSVC. Since Neil insists that Yhc should compile with MSVC (pfft, I never saw why, mingw always worked nicely for me - though that's a different issue). Given these constraints it would only be worth switching to gcc libffi if it does definitely have windows support, including working in MSVC. Thanks for all your contributions! :-) Tom From shackell at cs.york.ac.uk Tue Nov 6 09:45:11 2007 From: shackell at cs.york.ac.uk (Thomas Shackell) Date: Tue Nov 6 09:45:28 2007 Subject: [Yhc] Proposed replacement for Yhc's build system using CMake In-Reply-To: <63c0799b0711060538v47f3c0f9j6895251c4939171b@mail.gmail.com> References: <63c0799b0711060538v47f3c0f9j6895251c4939171b@mail.gmail.com> Message-ID: <47307DF7.3040302@cs.york.ac.uk> Mathieu Boespflug wrote: > 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. Yes, we've had quite a lot of problems relating to scons. > 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. Well, here Neil and I disagree. Whilst 'autotools' in its fullness is 'autohell' parts of it are okay: make works nicely so long as you write your Makefiles well (see "Recusive make considered harmful"), and autoconf is just about tolerable. The other advantage of autoconf & make is their ubiquity: they are well supported because they are "the standard". It's true that you need cygwin or MSYS on windows, but as Neil himself points out most windows users want binaries not source code. You can, as an alternative, cross compile to windows from unix using mingw. I've used this on other projects and it works nicely. Being able to use MSVC to compile Yhc is a very moot point in my opinion. This is because Yhc makes use of several gcc extensions, and since these aren't available on MSVC it runs quite a lot slower as a result. That said there is a certain amount of benefit to keeping all parties happy where possible ;-) > 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. Yes I've become very unconvinced of the scons idea of "you need a full powered language to write build systems". In practice you seem to end up with something as complicated as a program for something as simple as a build system. > 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. One important problem with the Scons system is that only one person was familiar with scons. This became problematic as nobody else knew how to add anything to the build system: a new target, additional options etc. So an important question is "will the other Yhc developers be able to modify the CMake files?". > 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. Indeed, some temporary system would be necessary - possibly a rather hacky CMake file? > 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). Agreed cohabitation is the best strategy for the moment, until the CMake build system becomes stable :-) > 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. None of these are used any more, they were part of the original autoconf&make system. > 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. Both windows and Mac OS X have traditionally been the tricky cases for the build systems Linux has usually always worked, probably because most Yhc development is done by linux users :-) > Beyond building the libraries, further work would include integrating > 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. nhc98 doesn't use the src/runtime/BCKernel makefile since that code is Yhc specific. The only part of the code shared with nhc98 is the src/compiler code. Thanks for your efforts :-) Tom From shackell at cs.york.ac.uk Tue Nov 6 09:57:11 2007 From: shackell at cs.york.ac.uk (Thomas Shackell) Date: Tue Nov 6 09:55:27 2007 Subject: [Yhc] Yhc autumn cleaning In-Reply-To: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> References: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> Message-ID: <473080C7.6010109@cs.york.ac.uk> To my knowledge all these are indeed dead. Cheers :-) Tom Mathieu Boespflug wrote: > 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 > _______________________________________________ > Yhc mailing list > Yhc@haskell.org > http://www.haskell.org/mailman/listinfo/yhc From mboes at tweag.net Tue Nov 6 10:39:52 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Tue Nov 6 10:36:57 2007 Subject: [Yhc] Replacing libffi with version distributed in gcc-4.2 In-Reply-To: <63c0799b0711060738q22e19fc3l3af943413092835d@mail.gmail.com> References: <63c0799b0711060557r701a20f2u7034021f427713af@mail.gmail.com> <4730763C.9040700@cs.york.ac.uk> <63c0799b0711060738q22e19fc3l3af943413092835d@mail.gmail.com> Message-ID: <63c0799b0711060739w64d4bde6ie09e11b67509f7f@mail.gmail.com> > > Instead of importing libffi from the python sources, I propose using > > another, more complete version. libffi does not seem to be currently > > maintained due to copyright issues but there seems to be a version of > > it distributed by gcc-4.2 which is much more recent and complete. I > > get the impression that version works on all platforms gcc has been > > ported to (could be wrong though). > > At the time we made the choice we considered both the python ctypes > version and the gcc version. In the end we rejected the gcc version > because it didn't have any support for the windows platform, whereas the > python version had been modified by the ctypes people so that it did. > > Now it's entirely possible that this has now changed and the gcc version > supports windows, including use with MSVC. Since Neil insists that Yhc > should compile with MSVC (pfft, I never saw why, mingw always worked > nicely for me - though that's a different issue). The GCC version does have support for windows as far as I can tell (see depends/libffi/default/src/x86/win32.S). But of course it won't build unless you have mingw etc. For people who are quite happy to use mingw under windows to compiler Yhc, things should work with little extra modifications if any. For people that insist on MSVC I have included depends/libffi/msvc, which comes from the python ctypes version, actually. So this should keep everyone happy. :-) For building BCKernel and libffi using MSVC it will require to add support for that in src/runtime/BCKernel/CMakeLists.txt, of course. Any takers? We could of course replace the libffi autoconf stuff with CMake files and gain support for building the gcc libffi with MSVC, but I don't think it's worth it. It would be a lot of work and not much point in that. > Given these constraints it would only be worth switching to gcc libffi > if it does definitely have windows support, including working in MSVC. That is a simple case of adding the support into the Yhc CMake files. On the flipside we get a more modern libffi with more architectures supported. I remember giving up porting Yhc to my armel based N800 device because the ctypes libffi doesn't have armel support, only arm (and also because the scons build system was making life terribly difficult..). I haven't reiterated the attempt with the gcc libffi but google tells me the libffi in gcc-4.2 does support that architecture. Note that this libffi update patch only supports CMake. I don't understand scons. Anyone interested in making the appropriate changes to scons to work with this patch? Mathieu From ndmitchell at gmail.com Tue Nov 6 15:35:30 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Nov 6 15:32:33 2007 Subject: [Yhc] Yhc autumn cleaning In-Reply-To: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> References: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> Message-ID: <404396ef0711061235r2b75f37fp6195affb22d12d2a@mail.gmail.com> Hi > * Remove Make/ from src. There is no Make/ in src, its in the root. And it is an alternative build system - please do not remove until we've decided on the "one true" build system. > * Cleanup the misc/ directory. Everything in this directory either had a purpose, or still does - leave it alone. > * Remove the src/compiler98 folder, which is now unused. Kill, kill, kill! > * Remove msvc files in BCKernel directory. No, these are visual studio support, and are used by the Windows build. > * Remove toplevel test/ dir. It looks unused. Does it not have any files in it? Mine seems to have one, but that may be out of the main repo. The test directory was intended to die, as I've been gradually moving tests into the "tests" dir. Certainly anything left in test/ should be moved into tests/ then test/ should die. Thanks Neil From mboes at tweag.net Wed Nov 7 04:34:46 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Wed Nov 7 04:31:49 2007 Subject: [Yhc] Yhc autumn cleaning In-Reply-To: <404396ef0711061235r2b75f37fp6195affb22d12d2a@mail.gmail.com> References: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> <404396ef0711061235r2b75f37fp6195affb22d12d2a@mail.gmail.com> Message-ID: <63c0799b0711070134g3ec7c422q5edb30c4e6f082c1@mail.gmail.com> Hi, > > * Remove Make/ from src. > > There is no Make/ in src, its in the root. And it is an alternative > build system - please do not remove until we've decided on the "one > true" build system. Sure. I guess then this patch should be part of the set of patches removing SCons, which may or may not be applied at a later date depending on the outcome of the Great Build System Debate. I asked another Yhc developer about Make/ who told me as far as he knew this wasn't being worked on anymore. Is it still being worked on? I note Make/ contains source for a Haskell based make system. Isn't it essential that Yhc have a build system that doesn't have Haskell as a dependency? The Yhc runtime has the big advantage of being a bytecode interpreter, meaning porting to a new architecture is theoretically a case of compiling the C runtime using a C compiler, then running the platform independent Yhc bytecode generated by some other computer. Henceforth you have a working Haskell compiler on an entirely new platform having started only with a C compiler. Someday maybe, this could be an alternative way of boostrapping GHC. Using CMake for building only means that more than a C compiler, you need a C++ compiler, but you don't need a Haskell compiler (at least to build the runtime). > > * Cleanup the misc/ directory. > > Everything in this directory either had a purpose, or still does - > leave it alone. The files removed by this patch are Batch.hs and Makefile.bpp, which seems to be yet another method for building under Windows and written in a Visual Basic like language. If the other build systems subsume this (or once they do), shouldn't these files be removed? > > * Remove the src/compiler98 folder, which is now unused. > > Kill, kill, kill! > > > * Remove msvc files in BCKernel directory. > > No, these are visual studio support, and are used by the Windows build. Does this mean they are used by the scons based windows build? > > * Remove toplevel test/ dir. It looks unused. > > Does it not have any files in it? Mine seems to have one, but that may > be out of the main repo. The test directory was intended to die, as > I've been gradually moving tests into the "tests" dir. Certainly > anything left in test/ should be moved into tests/ then test/ should > die. It just has Split.hs, which this patch removes, along with the test/ dir. Regards, Mathieu From ndmitchell at gmail.com Wed Nov 7 04:39:31 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Nov 7 04:36:32 2007 Subject: [Yhc] Yhc autumn cleaning In-Reply-To: <63c0799b0711070134g3ec7c422q5edb30c4e6f082c1@mail.gmail.com> References: <63c0799b0711060610j37a40d07xd525f0bfcf73349b@mail.gmail.com> <404396ef0711061235r2b75f37fp6195affb22d12d2a@mail.gmail.com> <63c0799b0711070134g3ec7c422q5edb30c4e6f082c1@mail.gmail.com> Message-ID: <404396ef0711070139s3213a4c6g9dc25cf9c8371a7d@mail.gmail.com> Hi > > There is no Make/ in src, its in the root. And it is an alternative > > build system - please do not remove until we've decided on the "one > > true" build system. > > Sure. I guess then this patch should be part of the set of patches > removing SCons, which may or may not be applied at a later date > depending on the outcome of the Great Build System Debate. I asked > another Yhc developer about Make/ who told me as far as he knew this > wasn't being worked on anymore. Is it still being worked on? It can build some bits better than scons can, since it uses Cabal rather than painful single file compilation. It isn't being worked on, but it wasn't _that_ far off being a complete replacement. > Henceforth you have a working Haskell compiler on an entirely new > platform having started only with a C compiler. Someday maybe, this > could be an alternative way of boostrapping GHC. True, but the Haskell build system did factor in this and had a plan to deal with it. > > > * Cleanup the misc/ directory. > > > > Everything in this directory either had a purpose, or still does - > > leave it alone. > > The files removed by this patch are Batch.hs and Makefile.bpp, which > seems to be yet another method for building under Windows and written > in a Visual Basic like language. If the other build systems subsume > this (or once they do), shouldn't these files be removed? They should probably be removed soon, but let me move them into their own repo first - I'll send a patch to remove these after that. > > > * Remove msvc files in BCKernel directory. > > > > No, these are visual studio support, and are used by the Windows build. > > Does this mean they are used by the scons based windows build? I can't remember, but they are used by Windows developers to debug the runtime, so are very useful. > > > * Remove toplevel test/ dir. It looks unused. > > It just has Split.hs, which this patch removes, along with the test/ dir. I guess split isn't interesting enough to care about, so just delete it. Thanks Neil From mboes at tweag.net Wed Nov 7 05:07:18 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Wed Nov 7 05:04:20 2007 Subject: [Yhc] Proposed replacement for Yhc's build system using CMake In-Reply-To: <47307DF7.3040302@cs.york.ac.uk> References: <63c0799b0711060538v47f3c0f9j6895251c4939171b@mail.gmail.com> <47307DF7.3040302@cs.york.ac.uk> Message-ID: <63c0799b0711070207w6c1e7cf8y10af8a26ae10a28b@mail.gmail.com> Hi, > > 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. > > Well, here Neil and I disagree. Whilst 'autotools' in its fullness is > 'autohell' parts of it are okay: make works nicely so long as you write > your Makefiles well (see "Recusive make considered harmful"), and > autoconf is just about tolerable. The other advantage of autoconf & make > is their ubiquity: they are well supported because they are "the standard". I agree. CMake isn't as ubiquitous and what users are used to. Also it isn't IMHO much better of a language than shell scripts + m4. However I think it does have some advantages here. It's quite a bit faster than autoconf and automake. It also generates much smaller Makefiles and we don't need to distribute a big configure script. More importantly, it's quite a bit simpler than autotools and easier and faster to learn than autotools. And even more importantly: > That said there is a certain amount of benefit to keeping all parties > happy where possible ;-) Precisely! > Yes I've become very unconvinced of the scons idea of "you need a full > powered language to write build systems". In practice you seem to end up > with something as complicated as a program for something as simple as a > build system. Yep. > One important problem with the Scons system is that only one person was > familiar with scons. This became problematic as nobody else knew how to > add anything to the build system: a new target, additional options etc. > So an important question is "will the other Yhc developers be able to > modify the CMake files?". I think CMake files are easier to learn to write and read than autoconf scripts. And a lot easier than scons scripts, which entail learning a full programming language and a weird build model. CMake files are fairly clear, and currently the two CMakeLists.txt files in the proposed patches weigh in at 164 lines total, whilst providing most of the core functionality of the scons scripts (notably cmake doesn't build libraries atm). In comparison, $ wc -l build/{SConscript.*,*.py,tools/*.py} 1068 total $ find src/packages/ -name SConscript | xargs wc -l > > 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. > > Indeed, some temporary system would be necessary - possibly a rather > hacky CMake file? Yes. I'll get going on that, seeing as though the prerequesite support from Cabal seems still a way off. > > 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. > > Both windows and Mac OS X have traditionally been the tricky cases for > the build systems Linux has usually always worked, probably because most > Yhc development is done by linux users :-) Heh. Any Yhc developer with a Mac OS X machine lying around? > > 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. > > nhc98 doesn't use the src/runtime/BCKernel makefile since that code is > Yhc specific. The only part of the code shared with nhc98 is the > src/compiler code. Ok. I've made a new patch removing that Makefile. Regards, Mathieu From golubovsky at gmail.com Wed Nov 7 10:36:10 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Wed Nov 7 10:33:11 2007 Subject: [Yhc] Yhc autumn cleaning Message-ID: 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 From mboes at tweag.net Thu Nov 8 11:24:41 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Thu Nov 8 11:21:39 2007 Subject: [Yhc] Yhc autumn cleaning In-Reply-To: References: Message-ID: <63c0799b0711080824o18da3153i89a303392d51d107@mail.gmail.com> > 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. I have added a patch to yhc.cmake repo to support this. The user can modify interactively the settings regarding what remote host to bounce from and what ports to use with the ccmake command or any other cmake cache management utility. Note the firewall support is untested. > 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. If the build system is migrated to CMake then ideally this would have to be converted to a CMakeLists.txt file. You can make on in src/translator/js, self contained and independent of the top-level CMakeLists.txt file. We can then add an appropriate directive in the toplevel file to build ycr2js from the toplevel. For now I have added a patch to the repo at http://code.haskell.org/~mboes/yhc.cmake that just calls make in ycr2js's directory. So at the top-level, $ cmake . $ make ycr2js This only calls "make" atm, not "make install". Regards, Mathieu From mboes at tweag.net Thu Nov 8 11:31:59 2007 From: mboes at tweag.net (Mathieu Boespflug) Date: Thu Nov 8 11:28:56 2007 Subject: [Yhc] Proposed replacement for Yhc's build system using CMake In-Reply-To: <63c0799b0711070207w6c1e7cf8y10af8a26ae10a28b@mail.gmail.com> References: <63c0799b0711060538v47f3c0f9j6895251c4939171b@mail.gmail.com> <47307DF7.3040302@cs.york.ac.uk> <63c0799b0711070207w6c1e7cf8y10af8a26ae10a28b@mail.gmail.com> Message-ID: <63c0799b0711080831w48800897l5b5b109fcfefc07a@mail.gmail.com> Hi, I noticed there was a bootstrapping problem whereby the cmake command would fail if the dependencies such as filepath and uniplate hadn't been fetched yet but cmake needed to run at least once successfully to be able to do a "make fetch". This is now solved in the yhc.cmake repository at http://code.haskell.org/~mboes/yhc.cmake So now if you're starting from a fresh darcs get of the yhc repo, you must do $ cmake . $ make fetch $ cmake . $ make yhc for instance to build the yhc compiler. Note that the yhc-compiler98 repo needs a patch to the yhc.cabal file adding Main-Is: MainYhc.hs, in order to build the compiler. Sorry about the bug. Mathieu On Nov 7, 2007 11:07 AM, Mathieu Boespflug wrote: > Hi, > > > > 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. > > > > Well, here Neil and I disagree. Whilst 'autotools' in its fullness is > > 'autohell' parts of it are okay: make works nicely so long as you write > > your Makefiles well (see "Recusive make considered harmful"), and > > autoconf is just about tolerable. The other advantage of autoconf & make > > is their ubiquity: they are well supported because they are "the standard". > > I agree. CMake isn't as ubiquitous and what users are used to. Also it > isn't IMHO much better of a language than shell scripts + m4. However > I think it does have some advantages here. It's quite a bit faster > than autoconf and automake. It also generates much smaller Makefiles > and we don't need to distribute a big configure script. More > importantly, it's quite a bit simpler than autotools and easier and > faster to learn than autotools. And even more importantly: > > > That said there is a certain amount of benefit to keeping all parties > > happy where possible ;-) > > Precisely! > > > Yes I've become very unconvinced of the scons idea of "you need a full > > powered language to write build systems". In practice you seem to end up > > with something as complicated as a program for something as simple as a > > build system. > > Yep. > > > One important problem with the Scons system is that only one person was > > familiar with scons. This became problematic as nobody else knew how to > > add anything to the build system: a new target, additional options etc. > > So an important question is "will the other Yhc developers be able to > > modify the CMake files?". > > I think CMake files are easier to learn to write and read than > autoconf scripts. And a lot easier than scons scripts, which entail > learning a full programming language and a weird build model. > CMake files are fairly clear, and currently the two CMakeLists.txt > files in the proposed patches weigh in at 164 lines total, whilst > providing most of the core functionality of the scons scripts (notably > cmake doesn't build libraries atm). In comparison, > > $ wc -l build/{SConscript.*,*.py,tools/*.py} > 1068 total > > $ find src/packages/ -name SConscript | xargs wc -l > > > > 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. > > > > Indeed, some temporary system would be necessary - possibly a rather > > hacky CMake file? > > Yes. I'll get going on that, seeing as though the prerequesite support > from Cabal seems still a way off. > > > > 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. > > > > Both windows and Mac OS X have traditionally been the tricky cases for > > the build systems Linux has usually always worked, probably because most > > Yhc development is done by linux users :-) > > Heh. Any Yhc developer with a Mac OS X machine lying around? > > > > 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. > > > > nhc98 doesn't use the src/runtime/BCKernel makefile since that code is > > Yhc specific. The only part of the code shared with nhc98 is the > > src/compiler code. > > Ok. I've made a new patch removing that Makefile. > > Regards, > > Mathieu > From naesten at gmail.com Thu Nov 8 16:40:41 2007 From: naesten at gmail.com (Samuel Bronson) Date: Thu Nov 8 16:37:36 2007 Subject: [Yhc] Proposed replacement for Yhc's build system using CMake In-Reply-To: <63c0799b0711070207w6c1e7cf8y10af8a26ae10a28b@mail.gmail.com> References: <63c0799b0711060538v47f3c0f9j6895251c4939171b@mail.gmail.com> <47307DF7.3040302@cs.york.ac.uk> <63c0799b0711070207w6c1e7cf8y10af8a26ae10a28b@mail.gmail.com> Message-ID: On 11/7/07, Mathieu Boespflug wrote: > I think CMake files are easier to learn to write and read than > autoconf scripts. And a lot easier than scons scripts, which entail > learning a full programming language and a weird build model. I don't imagine knowing Python helps much; scons is still really wierd. It certainly doesn't use normal Python style... From golubovsky at gmail.com Sat Nov 17 01:32:41 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Sat Nov 17 01:29:11 2007 Subject: [Yhc] New demo/test program for Yhc Javascript backend Message-ID: 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 From golubovsky at gmail.com Sun Nov 18 09:04:58 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Sun Nov 18 09:01:31 2007 Subject: [Yhc] Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend In-Reply-To: <6205bd290711180541n1249f00n525b502a433aa6fb@mail.gmail.com> References: <6205bd290711180541n1249f00n525b502a433aa6fb@mail.gmail.com> Message-ID: Bit, On Nov 18, 2007 8:41 AM, Bit Connor 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 From ndmitchell at gmail.com Wed Nov 21 17:20:35 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Nov 21 17:16:49 2007 Subject: [Yhc] Re: [Haskell-cafe] yhc install fails In-Reply-To: <910ddf450711211246i28b700c9if18e66c4f8f9b35f@mail.gmail.com> References: <910ddf450711211246i28b700c9if18e66c4f8f9b35f@mail.gmail.com> Message-ID: <404396ef0711211420q1f7476c4w765ede7e980a1425@mail.gmail.com> Yhc people: On Nov 21, 2007 8:46 PM, Thomas Hartman 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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From shackell at cs.york.ac.uk Thu Nov 22 04:31:01 2007 From: shackell at cs.york.ac.uk (Thomas Shackell) Date: Thu Nov 22 04:28:19 2007 Subject: [Yhc] Re: [Haskell-cafe] yhc install fails In-Reply-To: <404396ef0711211420q1f7476c4w765ede7e980a1425@mail.gmail.com> References: <910ddf450711211246i28b700c9if18e66c4f8f9b35f@mail.gmail.com> <404396ef0711211420q1f7476c4w765ede7e980a1425@mail.gmail.com> Message-ID: <47454C55.5090903@cs.york.ac.uk> Apologies, I broke this when I fixed the getArgs bug. It's actually just a build problem, Storable needs to be built before C/String. I didn't notice it because it only happens with a fresh (uncompiled) copy of yhc. Anyway fix pushed. Thanks Tom Neil Mitchell wrote: > Yhc people: > > On Nov 21, 2007 8:46 PM, Thomas Hartman 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@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Yhc mailing list > Yhc@haskell.org > http://www.haskell.org/mailman/listinfo/yhc From golubovsky at gmail.com Mon Nov 26 11:25:24 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Mon Nov 26 11:21:26 2007 Subject: [Yhc] Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend In-Reply-To: <910ddf450711260803o11cd78d6k77e23ecb3b35c9b3@mail.gmail.com> References: <910ddf450711260803o11cd78d6k77e23ecb3b35c9b3@mail.gmail.com> Message-ID: 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 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 From tphyahoo at gmail.com Mon Nov 26 13:11:18 2007 From: tphyahoo at gmail.com (Thomas Hartman) Date: Mon Nov 26 13:07:29 2007 Subject: [Yhc] Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend In-Reply-To: References: <910ddf450711260803o11cd78d6k77e23ecb3b35c9b3@mail.gmail.com> Message-ID: <910ddf450711261011q3c707896ua9720785dcf973a5@mail.gmail.com> 2007/11/26, Dimitry Golubovsky : > Thomas, > > All published examples (source, html) go into web/jsdemos subdirectory > (from the root of the Yhc repo source tree). right; it would be nice to have a makefile (or makefiles) there that works out of the box, rather than relying on the wiki http://haskell.org/haskellwiki/Yhc/Javascript/Users_guide#Building_and_installation_on_Unix which, among other things, requires cleaning up tabs for the formatting to work. Even if it can't be incorporated into the buildbot, it would be nice to have some working make examples to orient one's self. Secondly, with regards to your cps changes, are you aware of *any* demos that will compile from head? I want to get going with this because I have a situation where ycr2js would be really useful for an in-house project, client side table filtering on large tables. Maybe I should say a bit about this as well so you can tell me if this seems realistic, I'll write a separate email about that. t. > > 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 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 > From tphyahoo at gmail.com Mon Nov 26 13:47:05 2007 From: tphyahoo at gmail.com (Thomas Hartman) Date: Mon Nov 26 13:43:03 2007 Subject: [Yhc] idea for ycr2js demo, actually meant for an in-house project. is this realistic? Message-ID: <910ddf450711261047t658ef44fp3781dc205f0e616e@mail.gmail.com> 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. From tphyahoo at gmail.com Mon Nov 26 14:31:08 2007 From: tphyahoo at gmail.com (Thomas Hartman) Date: Mon Nov 26 14:27:18 2007 Subject: [Yhc] Re: [Haskell-cafe] New demo/test program for Yhc Javascript backend In-Reply-To: References: <910ddf450711260803o11cd78d6k77e23ecb3b35c9b3@mail.gmail.com> <910ddf450711261011q3c707896ua9720785dcf973a5@mail.gmail.com> Message-ID: <910ddf450711261131l1b78eaaek45d6ed677f34ed62@mail.gmail.com> 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 : > 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 > From ndmitchell at gmail.com Fri Nov 30 02:08:16 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Nov 30 02:04:03 2007 Subject: [Yhc] Lack of monomorphism harms Bernouilli nofib benchmark Message-ID: <404396ef0711292308k27e9a770vb568d033a2e84e19@mail.gmail.com> 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