- Yhc - Haskell.org

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

Re: [Yhc] Replacing libffi with version distributed in gcc-4.2
by Mathieu Boespflug 06 Nov '07

06 Nov '07

> > 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

1 0

Replacing libffi with version distributed in gcc-4.2
by Mathieu Boespflug 06 Nov '07

06 Nov '07

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

2 1

Build Errors
by Thomas M. DuBuisson 21 Oct '07

21 Oct '07

With a clean copy of YHC on both my 64bit Ubuntu and my 32bit Debian system it is unable to determine I have a working gcc compiler. Ex 1: > scons fullclean && scons depends && scons configure Fails to find the size of basic 'C' types (char, int, long, long long, etc). Ultimately bailing with the "Does this system really have a working gcc?" line. Ex 2: > scons build This does detect sizeof() _most_ 'C' types (fails for float, double, and one other). If I manually run ./configure then scons build I get an excessive number of errors 'undefined reference to'... but I didn't travel down that path too far. If I can get the Debian box working then I'll try to set it up as a buildbot. Thomas -- "The philosophy behind your actions should never change, on the other hand, the practicality of them is never constant." - Thomas Main DuBuisson

1 0

buildbot failure in windows
by andrewjwilkinsonw＠gmail.com 17 Oct '07

17 Oct '07

The Buildbot has detected a new failure of windows. Full details are available at: http://www.indiegigs.co.uk:8010/windows/builds/194 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: neilwindows Build Reason: Build Source Stamp: HEAD Blamelist: Tom Shackell <shackell(a)cs.york.ac.uk> BUILD FAILED: failed yhc release sincerely, -The Buildbot

1 0

buildbot failure in macosx_x86
by andrewjwilkinsonw＠gmail.com 17 Oct '07

17 Oct '07

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

1 0

buildbot failure in macosx_ppc_3
by andrewjwilkinsonw＠gmail.com 29 Aug '07

29 Aug '07

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/139 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: macosxppc3 Build Reason: Build Source Stamp: HEAD Blamelist: golubovsky(a)gmail.com BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

Config error..PreludeBuiltin...is this still in the build?
by Alexis Morris 29 Aug '07

29 Aug '07

Hi all, I just built a fresh yhc/yhi (after only adding one line to Primitive.hs) and everything seemed fine. I then copied my inst folder to c:\yhcinstall\. When I run "yhc hello.hs" however I get the following: $ yhc hello.hs Error: File not found, PreludeBuiltin Reason: imported from Prelude Looked in: c:\Documents and Settings\Alexis\Desktop\2007\NXHaskell\current\BCKernel\ c:\yhcinstall\lib\yhc\packages\haskell98\1.0 c:\yhcinstall\lib\yhc\packages\yhc-base\1.0 I'm not sure if this is a bug in the config or is caused by copying. I do have a PreludeBuiltin in my C:/YHC_BASE/version220807/yhc/src/packages/yhc-base-1.0/PreludeBuiltin.hi <file:///C:/YHC_BASE/version220807/yhc/src/packages/yhc-base-1.0/PreludeBuiltin.hi> I'll see if copying it over helps....nope...copying it seems to cause yhc loop until stack overflow. $ yhc hello.hs Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. Cheers, -- </Alexis>

2 3

Adding Custom Primitive functions
by Alexis Morris 29 Aug '07

29 Aug '07

Hi all, I have a number of driver related function calls that I would like to add as Primitive functions to yhc and yhi. For yhi (yhc\src\runtime\BCKernel) I have added definitions to Runtime.c and WrapPrimitive.c, in order to define and wrap stuff like "void display_string(void)" where the function is declared in a display.h/display.c file (this code controls the LCD display of the NXT). So far I think I have this yhi part covered. My question is about where these primitives are made known to the compiler so I can make display_string visible to yhc programs. After adding this line to Primitive.hs yhc hangs... ---------------------------------------------------------------------------------------------------- -- NXT Display ---------------------------------------------------------------------------------------------------- foreign import fastccall display_string :: CString -> IO () I just noticed the following files seem to have something todo with things: C:\YHC_OLD_SOURCES\yhc_again\yhc\src\packages\yhc-base-1.0\YHCPrimitive.hs C:\YHC_OLD_SOURCES\yhc_again\yhc\src\compiler\Prim.hs C:\YHC_OLD_SOURCES\yhc_again\yhc\src\compiler\PrimCode.hs C:\YHC_OLD_SOURCES\yhc_again\yhc\src\compiler98\Prim.hs C:\YHC_OLD_SOURCES\yhc_again\yhc\src\compiler98\PrimCode.hs Which changes I need to make before recompiling YHC? Thanks in advance. :) Cheers, -- </Alexis>

2 1

YHI Loader ...generated bytecode as C but some errors.
by Alexis Morris 29 Aug '07

29 Aug '07

Hi Tom, Thanks for your detailed instructions about splitting YHI into two parts and then loading bytecode from the heap. I followed them, and was able to generate a file to be loaded into yhi. However, upon compiling I get some nasty errors that I'm unable to figure out. Below is a snippet from a factorial function: fac 0 = 1 fac n = n * fac (n-1) main = print (fac 42) -------------------------------------- //this generates....among other things -------------------------------------- . . .snip... UInt8 bytecode_Main_2Emain[] = { 0X1, 0X25, 0X26, 0X8, 0X31, 0X42, 0X1, 0X8, 0X32, 0XC, 0X33, 0X34, 0X5B, 0 }; UByte ctypes_Main_2Emain[] = { C_NODE, C_NODE, C_INFO, C_INFO, C_INFO, C_INFO }; PInfo pinfo_Main_2Emain[] ={ }; FInfo finfo_Main_2Emain = (FInfo){ {I_FINFO}, pinfo_Main_2Emain, NULL, 0, 3, 0x00, NULL, NULL, 14, &bytecode_Main_2Emain, 6, &ctypes_Main_2Emain, &ctable_Main_2Emain }; ConstItem ctable_Main_2Emain[] = { (ConstItem) &node_0x18720028, (ConstItem) &node_0x18720480, (ConstItem) &finfo_Main_2Emain, (ConstItem) &finfo_Main_2Emain, (ConstItem) &finfo_Main_2Emain, (ConstItem) &finfo_Main_2Emain }; Word node_0x18720024[] = { (Word) &pinfo_Main_2Emain[0] }; UInt8 bytecode_Main_2Efac[] = { 0X1, 0X25, 0X12, 0X30, 0X42, 0X1, 0XB, 0X13, 0X12, 0X31, 0X32, 0X5A, 0X1, 0X41, 0X2, 0X1, 0X5A, 0X1, 0X4D, 0X5F, 0XB, 0, 0X1, 0X29, 0X17, 0X30, 0X5A, 0X1, 0X42, 0X1, 0X5B, 0X1, 0X29, 0X12, 0X30, 0X42, 0X1, 0X13, 0X12, 0X34, 0X41, 0X2, 0X1, 0X12, 0X35, 0XB, 0X18, 0X17, 0X36, 0X5A, 0X1, 0X41, 0X2, 0X1, 0X5B, 0 }; UByte ctypes_Main_2Efac[] = { C_NODE, C_INFO, C_INFO, C_INFO, C_NODE, C_INFO, C_INFO, C_INFO }; PInfo pinfo_Main_2Efac[] ={ (PInfo){ { I_PINFO }, 0, 2 }, (PInfo){ { I_PINFO }, 1, 1 } }; FInfo finfo_Main_2Efac = (FInfo){ {I_FINFO}, pinfo_Main_2Efac, NULL, 2, 4, 0x00, NULL, NULL, 56, &bytecode_Main_2Efac, 8, &ctypes_Main_2Efac, &ctable_Main_2Efac }; ConstItem ctable_Main_2Efac[] = { (ConstItem) &node_0x18720494, (ConstItem) &finfo_Main_2Efac, (ConstItem) &finfo_Main_2Efac, (ConstItem) &finfo_Main_2Efac, (ConstItem) &node_0x187204a4, (ConstItem) &finfo_Main_2Efac, (ConstItem) &finfo_Main_2Efac, (ConstItem) &finfo_Main_2Efac }; Word node_0x18720490[] = { (Word) &pinfo_Main_2Efac[0] }; ----------------------------------------------------------------------- When I compile I get these errors for this section of code ../yhi/loaderCode.c:15520: error: 'ctable_Main_2Emain' undeclared here (not in a function) ../yhi/loaderCode.c:15520: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15520: error: initializer element is not constant ../yhi/loaderCode.c:15520: error: (near initialization for 'finfo_Main_2Emain') ../yhi/loaderCode.c:15520: error: initializer element is not constant ../yhi/loaderCode.c:15524: error: 'node_0x18720480' undeclared here (not in a function) ../yhi/loaderCode.c:15524: error: initializer element is not constant ../yhi/loaderCode.c:15524: error: (near initialization for 'ctable_Main_2Emain[1]') ../yhi/loaderCode.c:15556: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15558: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15560: error: 'ctable_Main_2Efac' undeclared here (not in a function) ../yhi/loaderCode.c:15560: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15560: error: initializer element is not constant ../yhi/loaderCode.c:15560: error: (near initialization for 'finfo_Main_2Efac') ../yhi/loaderCode.c:15560: error: initializer element is not constant ../yhi/loaderCode.c:15563: error: 'node_0x18720494' undeclared here (not in a function) ../yhi/loaderCode.c:15563: error: initializer element is not constant ../yhi/loaderCode.c:15563: error: (near initialization for 'ctable_Main_2Efac[0]') ../yhi/loaderCode.c:15567: error: 'node_0x187204a4' undeclared here (not in a function) ../yhi/loaderCode.c:15567: error: initializer element is not constant ../yhi/loaderCode.c:15567: error: (near initialization for 'ctable_Main_2Efac[4]') ../yhi/loaderCode.c:15597: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15599: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15601: error: 'ctable_Data_2FChar_2ELAMBDA1036' undeclared here (not in a function) ../yhi/loaderCode.c:15601: warning: initialization from incompatible pointer type ../yhi/loaderCode.c:15601: error: initializer element is not constant ../yhi/loaderCode.c:15601: error: (near initialization for 'finfo_Data_2FChar_2ELAMBDA1036') ../yhi/loaderCode.c:15601: error: initializer element is not constant ../yhi/loaderCode.c:15605: error: 'node_0x1872038c' undeclared here (not in a function) ------------------------------------------------------------ Any ideas about why that blows up? In particular I'm curious about this error, "error: initializer element is not constant" not sure what it means. Thanks for the help, -- </Alexis>

2 1