- Yhc - Haskell.org

Crashing Queens
by Neil Mitchell 29 Aug '07

29 Aug '07

Hi, Using the attached program: -------------------------------------------------------------------------------- D:\Temp>yhc Queens.hs Compiling Queens ( Queens.hs ) D:\Temp>yhi Queens.hbc Assertion failed: pinfo->info.tag == I_PINFO, file d:\sources\yhc\current\src\ru ntime\bckernel\mutins.h, line 295 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -------------------------------------------------------------------------------- This also shows we have assertions on in the release "scons yhi" code, I guess they can stay in for now, but we really do need an optimisation mode. Program from Matt :-) Thanks Neil ----------- Queens.hs -------------- module Queens where main = nsoln 9 len :: [a] -> Int len [] = 0 len (x:xs) = 1 + len xs nsoln :: Int -> Int nsoln nq = len (gen nq) where gen :: Int -> [[Int]] gen 0 = [[]] gen n = [ (q:b) | b <- gen (n-1), q <- [1,2,3,4,5,6,7,8,9] {-toOne nq-}, safe q 1 b] safe :: Int -> Int -> [Int] -> Bool safe x d [] = True safe x d (q:l) = x /= q && x /= q+d && x /= q-d && safe x (d+1) l toOne :: Int -> [Int] toOne n = if n == 1 then [1] else n : toOne (n-1)

2 2

Adding new calling conventions for use in YHC.Core
by Dimitry Golubovsky 22 Aug '07

22 Aug '07

Jeremy, You wrote: ======================== Perhaps when the --core flag is present, the frontend should just treat the calling convention as String? Basically, I would extend the Style from: data Style = Ordinary | CCast | Address | FunAddress | Dynamic | Wrapper deriving Eq to: data Style = Ordinary | CCast | Address | FunAddress | Dynamic | Wrapper | Other String deriving Eq ======================== This message: http://www.haskell.org/pipermail/yhc/2007-August/001083.html mentions this (in the last paragraph). So, was this actually implemented, or still remains a proposal? -- Dimitry Golubovsky Anywhere on the Web

2 1

Adding new calling conventions for use in YHC.Core
by Jeremy Shaw 22 Aug '07

22 Aug '07

Hello, My ycr->swf backend is far enough along that I am ready to figure out how to properly import foreign functions. There are three types of ActionScript 'functions' that I want to import: 1. actionscript primitives, such as ActionSubtract, ActionStringAdd, etc 2. actionscript functions (mostly old functions that predate flash 5.0) 3. actionscript method calls (for flash 5.0 and higher, which has an object system) These each require a slightly different calling convention. So, I think I want to be able to import them by adding lines like this: foreign import primitive "ActionSubtract" actionSubtractInt :: Int -> Int -> Int foreign import ascall "someFunction" someFunction :: Int -> IO Int foreign import asmethod "someMethod" someMethod :: SomeObject -> Int -> IO Int However, to do this requires modifying the yhc frontend to accept these additional calling conventions. In YHC.Core, the calling convention is just a String, so there is no problem representing my new calling conventions in Core. But, the YHC frontend only wants to accept a limited set of predefined calling conventions. Perhaps when the --core flag is present, the frontend should just treat the calling convention as String? Basically, I would extend the Style from: data Style = Ordinary | CCast | Address | FunAddress | Dynamic | Wrapper deriving Eq to: data Style = Ordinary | CCast | Address | FunAddress | Dynamic | Wrapper | Other String deriving Eq And then modify the rest of the code so that when yhc is compiled with the --core flag, the calling convention is not parsed, but simply stuck inside the Other constructor? (Or perhaps, if it parses, the normal constructor is used, but if it fails to parse, then it is just dumped in Other ?) Or, perhaps I am taking completely the wrong approach ? j.

1 0

Possible bug in Yhc bytecode generator
by Dimitry Golubovsky 22 Aug '07

22 Aug '07

Hi, This file: http://www.golubovsky.org/repos/FudgetsOnWeb/Graphics/UI/Fudgets/SP/Spops.hs caused the following error message during compilation: Compiling Graphics.UI.Fudgets.SP.Spops ( ../FudgetsOnWeb/Graphics/UI/Fudgets/SP/Spops.hs ) yhc: src/compiler/ByteCode/CompileYhcCore.hs:(228,4)-(249,20): Non-exhaustive patterns in case This error did not occur when compiling with the --no-bytecode option Thanks. -- Dimitry Golubovsky Anywhere on the Web

1 0

Update on Javascript backend
by Dimitry Golubovsky 19 Aug '07

19 Aug '07

Hi, I have committed patches to fix incompatibilities in the Javascript backend that resulted from recent canges in Yhc Core. The EchoCPS demo now compiles and works. Anybody interested in experimenting with the Javascript backend are welcome to test the new code. Thanks. -- Dimitry Golubovsky Anywhere on the Web

1 0

buildbot failure in windows
by andrewjwilkinsonw＠gmail.com 15 Aug '07

15 Aug '07

The Buildbot has detected a new failure of windows. Full details are available at: http://www.indiegigs.co.uk:8010/windows/builds/182 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: neilwindows Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

Prelude.hs is there anything I can remove to make it smaller?
by Alexis Morris 14 Aug '07

14 Aug '07

Hi all, I am attempting to load up yhi on the Lego NXT, but I have several questions about the main startup files that need to be there. In particular I am referring to Prelude.hbc, _Driver.hbc, Primitive.hbc, and the user created mainMod.hbc. Based on reading the sequence in the main.c file these are all that are needed to start a simple program (say Hello World). I plan to put several of these into a hash table and send them over to the waiting NXT where I will then load from memory. The problem is that I have a limited amount of memory (100KB left in ROM and 64KB in RAM) for loading in files and I note that Primitive.hbc is actually 139KB. I am curious about whether there's anything in Prelude.hs that can be safely removed...some really obscure functions, if any... Any ideas? Cheers and thanks, -- </Alexis>

2 1

Yhc Core with modules that import each other?
by Isaac Dupree 12 Aug '07

12 Aug '07

Although the nyhc frontend currently doesn't support recursively dependent modules, will Yhc Core or the tools that work with it, present any trouble? For example I was thinking of the possibility of making Jhc be able to compile to Yhc Core (ignoring issues of different sets of primitives). Isaac

2 2

buildbot failure in macosx_x86_dual
by andrewjwilkinsonw＠gmail.com 08 Aug '07

08 Aug '07

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

1 0

Yhc.Core.Overlay changes
by Neil Mitchell 07 Aug '07

07 Aug '07

Hi, A recent change in the compiler means that function names are now desugared differently. In particularly: module Foo where bar = .... Used to generate Foo.bar, now it generates Foo;bar. As a result, anyone who was using the Overlay mechanism to match certain names will have to change their overlay file. For example: foreign import primitive global_Prelude'_seq :: a -> b -> b becomes: foreign import primitive global_Prelude''seq :: a -> b -> b I have changed '' to be an alias for ;, and made 'ap be an alias for ' Any questions, feel free to contact me. Thanks Neil

1 0