February 2008 - Yhc - Haskell.org

Yhc and Haskell pragmas
by Dimitry Golubovsky 10 Mar '08

10 Mar '08

Malcolm, OK, I see where it is, and even though all calls to parsePragma are commented out, the only one that would be recognized was "YHC_OPTIONS". The way I am going to use it is to grep the source for specific regexp, and then build the backend's command line accordingly. So I think that using pragma names starting with any other prefix than "YHC_" won't cause any conflict in the future, will it? Thanks, -- Dimitry Golubovsky Anywhere on the Web

2 1

YHC.Primitive;_E
by Dimitry Golubovsky 25 Feb '08

25 Feb '08

Hi, One observation about _E: Haddock does not like it. I once tried to generate documentation from Yhc sources. I had to place cpp directives everywhere _E appeared, like this: #ifndef __HADDOCK__ where ioBind (IO xf) y w = let xe = xf w in case xe of _E xv -> case y xv of IO yf -> yf w #endif This is not really a bug report, nor is it a request for any source code updates. Just a note for everyone who may run into this issue: there is a solution. Thanks. -- Dimitry Golubovsky Anywhere on the Web

4 4

build/version.py and darcs dist
by Dimitry Golubovsky 25 Feb '08

25 Feb '08

Hi, It looks like the way Yhc version is determined prevents usage of tarballs created by darcs dist. In the file "version.py" there is a line count of the "inventory" file to count number of patches and thus determine the version of Yhc. Thus, if buiding from a dist tarball, _darcs is not there, nor is inventory, and scons build fails. OTOH I never really saw Yhc printing its version: it always says (unversioned). So is there any need to keep this logic in version.py, or maybe it might be at least conditional upon the presence of the inventory file. Thanks. PS I hope someone maintaining the python part could fix this quickly. Otherwise I'll try to take care of it myself, but I am not a python expert. -- Dimitry Golubovsky Anywhere on the Web

2 3

YHC.Primitive;_E
by Tom Hawkins 21 Feb '08

21 Feb '08

To get the hang of using Yhc.Core, I'm writing a little haskell interpreter. The interpreter errors out when ever it comes across an unknown primitive. The first such primitive I had to implement was SEQ. Now I'm on to YHC.Primitive;_E. What is the meaning of this type? Is there a place where these primitive types are defined? When I print the coreDatas I see: data YHC.Primitive;_E b = YHC.Primitive;_E b When I print coreFuncs, I see no Case expressions that could extract data put into _E. Thanks for any tips! -Tom

2 1

buildbot failure in windows
by andrewjwilkinsonw＠gmail.com 15 Feb '08

15 Feb '08

The Buildbot has detected a new failure of windows. Full details are available at: http://www.indiegigs.co.uk:8010/windows/builds/233 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: neilwindows Build Reason: Build Source Stamp: HEAD Blamelist: golubovsky(a)gmail.com BUILD FAILED: failed yhc release sincerely, -The Buildbot

2 1

File not found, Yhc.Core
by Tom Hawkins 14 Feb '08

14 Feb '08

Any ideas? If I don't import Yhc.Core, things appear to be working. The only thing suspicious is "scons build" died right after "scons: done building targets.": Copy("inst/lib/yhc/packages/haskell98/1.0/System.ycr", "src/packages/haskell98-1.0/System.ycr") scons: done building targets. Exception exceptions.TypeError: TypeError("'NoneType' object is not callable",) in <bound method Popen4.__del__ of <popen2.Popen4 instance at 0x8d0078c>> ignored This must be pilot error, because I get the same results on my Windows box. Thanks for any help! -Tom hawkit1@waterton:~/t1$ cat Main.hs module Main (main) where import Yhc.Core main :: IO () main = do putStrLn "hello Yhc.Core!" loadCore "Main.ycr" >>= print hawkit1@waterton:~/t1$ yhc --linkcore Main Error: File not found, Yhc.Core Reason: imported from Main Looked in: /home/hawkit1/t1/ /home/hawkit1/yhc/inst/lib/yhc/packages/haskell98/1.0 /home/hawkit1/yhc/inst/lib/yhc/packages/yhc-base/1.0 hawkit1@waterton:~/t1$

2 1

Yhc and Haskell pragmas
by Dimitry Golubovsky 12 Feb '08

12 Feb '08

Hi, Does Yhc currently recognize any pragmas in GHC format {-# PRAGMA-NAME parameters #-} or any other format? I need to include some comments in Haskell source to be recognized by the Javascript backend (such approach might be useful for other backends as well) but not by the compiler (therefore I need to aviod pragma name conflict), and if there is no format currently defined I'll stick with GHC one, or please express your objections/suggestions, if any. Thanks. PS I haven't looked into sources/docs yet: maybe someone better familiar with the compiler itself can answer faster. -- Dimitry Golubovsky Anywhere on the Web

2 1

buildbot failure in macosx_ppc_3
by andrewjwilkinsonw＠gmail.com 09 Feb '08

09 Feb '08

The Buildbot has detected a new failure of macosx_ppc_3. Full details are available at: http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/201 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: macosxppc3 Build Reason: Build Source Stamp: HEAD Blamelist: Tom Shackell <shackell(a)cs.york.ac.uk>,golubovsky(a)gmail.com BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

FInfo->codesize woes.
by Stewart Platt 04 Feb '08

04 Feb '08

Hi YHC! Greetings, and for those I haven't already pestered, my interest in YHC pertains to my third year project, creating a JIT compiler for YHC's bytecode. Does anyone know if the FInfo->codesize value is reliable? I am presently compiling the _driver function which states a codesize of 0x24, yet my JIT compiler shows the IP (when I reach an END_CODE op) falls about 6 bytes short of this. Also is every function guaranteed to have an END_CODE op at the end? My current code works for a selection of functions I have played with but I haven't had time to examine any more than a modest selection. Cheers, Stew.

2 3