March 2007 - Yhc - Haskell.org

New Build System
by Neil Mitchell 04 Mar '07

04 Mar '07

Hi, After hearing numerous complaints from lots of people about our build system (esp Malcolm and Donald ;) ) - I took a look at the details. We now have 1300 lines of Python in our build system, that seems like quite a lot! The build system has evolved over time to keep up with the users, but I was wondering if we'd have more success with something written purely in Haskell. It's not done yet, but I've pushed the first patch which has the basic stuff done. I've made a couple of completely different decisions from the scons method: * All object files go under obj, clean is equal to deleting obj * Use ghc --make, yhc make mode etc, where possible * Everything should be able to be overiden, i.e. os=mac works just fine on a windows box (great for cross compiling!) * Everything is based on profiles, more on that once its done * Compile C files with GHC everywhere (will this go wrong?) * Install Haskell packages using Cabal * No explicit library dependancies It is not currently useable! The "Main configure" works and does the C configure tests and searches for GHC etc. "Main push" works fine. "Main yhc" will work if you have all the required packages pre-installed by Cabal - likely to only be me - but it does work. There are only 3 things left to do which might go wrong/take some time: 1) Download dependancies automatically and install them with Cabal. Haskell's lack of a good wget/tar combo here may hurt us, but I'll see what code I can find lying around. 2) Compile Yhi, which requires make-style knowledge about C. Scons had this built in much more, I'll need to roll my own. 3) Compile the libraries. If this isn't trivially easy I'll extend Yhc until it is. So far I'm quite happy with it - it seems very flexible and very modular. The disadvantage of moving to this (if it works) is that we'd likely throw away some of the fixes we've made. The advantage is fewer dependancies, and more people who know Haskell - provided the Haskell stays simple and clean. Anyone have any thoughts? Thanks Neil

2 1

Problems installing YHC on Windows XP
by Bryan Burgers 03 Mar '07

03 Mar '07

Hello, I'm interested in fiddling with YHC, maybe helping out from time to time whenever I get free time, so I tried to install it from darcs today. Everything went well (got the source from darcs, downloaded SCons) until I did the configure script (error below). The scons output tells me that it can't find a C compiler. I have one on this computer via MinGW (which has executables named "gcc.exe" and "cpp.exe"). Not knowing SCons, I still took a shot in the dark at the configure script, changing the 'env' line to: env = Environment(ENV=os.environ, CPPPATH=["#.", "C:\\MinGW\\bin\\"]) but that didn't work, either. Should I go with an entirely different compiler? I don't remember why I installed that one, but I'm not sure I even used it, so I'm not even sure if it works. I guess I'm mostly appealing to the last line of the output below, "If so then please contact the Yhc developers for help." (smile) Any help would be appreciated! Bryan Burgers D:\My Documents\My Programs\Languages\Haskell\YHC\yhc>"C:\Program Files\Scons\Scons.py" core=2 scons: Reading SConscript files ... Building version 0.7.0-20070224211823-custom. Checking for architecture... Windows implies x86 Checking for operating system... win32 Checking for Subversion binary... Not found Error. 'svn' not found in PATH. Will use ctypes snapshot. Checking for GHC binary... "ghc" Checking for GHC version 6.4.1 or later... Found version 6.4.2. Checking for Python version 2.3 or later... Found version 2.4.3 final (0). Checking for Scons binary... Not found Checking for Darcs binary... "darcs" Checking for Darcs version... Found version 1.0.7 (release). Checking for Haddock binary... Not found Error. Haddock not found, you won't be able to build the documentation. Checking whether byte ordering is bigendian... failed Checking size of char... failed Checking size of short... failed Checking size of int... failed Checking size of long... failed Checking size of long long... failed Checking size of float... failed Checking size of double... failed Checking size of void*... failed Failed to check types sizes/endianness. You do have a working C compiler don't you? If so then please contact the Yhc developers for help.

2 2

buildbot failure in linux_ppc
by andrewjwilkinsonw＠gmail.com 03 Mar '07

03 Mar '07

The Buildbot has detected a new failure of linux_ppc. Full details are available at: http://www.indiegigs.co.uk:8010/linux_ppc/builds/80 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: linuxppc Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell,golubovsky(a)gmail.com BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

Inconsistency in documentation of .hbc format
by Stefan O'Rear 03 Mar '07

03 Mar '07

http://www.haskell.org/haskellwiki/Yhc/RTS/hbc does not list the calling convention and type signature fields for ExtObj. (ndm recommended I tell the list; this was discovered while writing the bytecode parser for ayhi.) Stefan

1 0

Followup to "evaluated node" question
by Dimitry Golubovsky 02 Mar '07

02 Mar '07

Hi, Sorry, it looks like there was a followup (seen in mail-archive, but not in the pipermail archive at haskell.org which shows the latest message on Feb 28). -- Dimitry Golubovsky Anywhere on the Web

1 0

Fwd: Re: Yhc port to Mindstorms
by Neil Mitchell 01 Mar '07

01 Mar '07

Hi, Tobias Muehlberg and I have just given the aforementioned talk. The abstract is at the bottom of this email, and the slides are available at: http://www.cs.york.ac.uk/plasma/talkrelated/318.pdf > I'm keen to get more details of this. Did it use Yhc? Where does > Lava come in? (We were thinking of using some form of FRP, as in > Frob or Yampa.) -- P My approach was just to add a C backend to Lava, in which circuits get turned into C. Lava alone is not great for control systems, but Koen Claessen and Gordon Pace have defined an Esterel-like language (amongst other languages), called Flash, on top of Lava. Essentially, if you write an interepreter/semantics for your own custom language in Lava, then you get a compiler from that language to VHDL (and now C) for free. See Koen's thesis for more details: http://www.cs.chalmers.se/~koen/pubs/phd01-thesis.ps (in particular chapter 6, and perhaps chapter 5) The seperation of Lava and languages like Flash reminds me of the pure/monadic divide when programming in Haskell, e.g. Lava (pure) functions can be called from Flash (impure) programs, and Flash programs can be turned into Lava functions by "running" them. The Lava homepage is: http://www.cs.chalmers.se/~koen/Lava/ I can provide my C/MindStorms backend to anyone who wants it. But it is not the most efficient code! Perhaps this general approach is more attractive to hardware designers than software programmers, because Lava expands out most recursion at compile time (which is good for parallelism, but not for binary size). This isn't a problem when you have languages like Flash available, but you might then ask "is this really programming in Haskell"? So, read the slides and judge for yourself! Thanks everyone for your interest! Matt. Room : CS202J Date : 01 March 2007 Time : 12:15 -- 13:15 Speaker : Matthew Naylor, Jan Tobias Muehlberg Title : FUN with Lego Mindstorms Abstract: In this talk, we will present how Lego Mindstorms robots can serve as a delightful example for the development of safety-critical embeded software systems. We will give a brief overview of Esterel's SCADE suite and show how it can be used to design programs for Lego robots, to prove safety properties for these programs and to generate C source code that actually runs on the Mindstorms RCX. In addition to this, Matthew will explain how the whole stuff can be done using Haskell. The talk is based on our experience from the Reactive Systems Design module. ----- End forwarded message -----

2 1

Core
by Ricky Barefield 01 Mar '07

01 Mar '07

Hi, I'm currently working on a project to convert Haskell to Java preserving lazy evaluation and such at Sheffield University. Neil Mitchell suggested that I look into using YHC Core as an intermediary language. It looks ideal, although I am having a couple of problems using it. Firstly so I can work with it I need to use the `Core' data type which seems to be in `Yhc.Core', I realised this isn't part of the windows snapshot of YHC so I found the files within http://darcs.haskell.org/yhc I've downloaded these files and put them into YHC's library folders. The problem is I'm not able to import these files into any of my own code as I get an error message. Would anyone know if I'm doing something wrong? (Let me know if I can tell you a bit more about what I've done) Or have I not downloaded the correct versions of these files? I understand YHC is still being developed, is there a stable version I could use for these files? Many Thanks and any help will be much appreciated. Ricky Barefield -----Original Message----- From: Neil Mitchell [mailto:ndmitchell@gmail.com] Sent: 06 February 2007 19:22 To: Ricky Barefield Subject: Re: [Haskell-cafe] External Core Hi If you do have any questions either post them to Haskell-cafe or yhc(a)haskell.org and I'm sure we'll be able to get you sorted. If there is any documentation you need, and can't find, also just shout and we'll find someone to write it. Thanks Neil On 2/6/07, Ricky Barefield <aca03rdb(a)sheffield.ac.uk> wrote: > Thanks for this I'll look into it. > > Ricky > > -----Original Message----- > From: Neil Mitchell [mailto:ndmitchell@gmail.com] > Sent: 06 February 2007 18:47 > To: Ricky Barefield > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] External Core > > Hi Ricky, > > > For the last year I've been working on a program to translate between > > Haskell and Java. Originally this was for my third year dissertation > to > > contribute towards my Masters in computer science at Sheffield > University, > > UK. > > > > I have been given the opportunity to continue this project and have > become > > interested in using the Core representation as an intermediary > language. > > You might be interested in Yhc.Core - its like GHC's Core, but is > simpler, untyped and (in my opinion) better supported. > > http://haskell.org/haskellwiki/Yhc/API/Core > > We already have a Haskell -> Javascript convertor written using this, > so your type of application is certainly doable using what we have > already. There are quite a few users of Yhc.Core already, and everyone > has had nice things to say about it :) > > If you have any specific Yhc.Core questions feel free to ask away > > Thanks > > Neil > >

2 3