The size problem is traceable to [Greencard's ffi code generation]
I took a look at this and found that Sigbjorn had fixed it some months ago
Would that be in the released Greencard or only in the cvs version?
Building GDITypes with this command:
green-card --target=ffi -i. --include-dir ../../green-card/lib/ghc -i . GDITypes.gc
generates correct code for prim_RGB (the problem Hal Daume ran into). and for Win32Window.adjustWindowRect
So the Win32 sources could now be regenerated and future builds and releases wouldn't run into these problems with Win32 or HGL anymore? -------------------------------------------------------------------
Just as long as someone remembers to do the re-greencarding <<<
in cvs: hslibs/win32 before the next release, please, because that won't happen automatically anymore (but then I may be wrong about this - I don't understand the fptools Makefiles, yet;-). Great - thanks, Claus PS. I still have to figure out how to make hslibs/win32 in isolation, so I won't be able to test & confirm whether this solves all the HGL/GHC/Win32 problems for a while (e.g., there was the problem of polygon creation running out of resources, see Friday's email; that could easily be related to the same ffi problem, but it would be good to check) - anyone else in a better position for testing?
Would that be in the released Greencard or only in the cvs version?
In the CVS version only AFAIK.
So the Win32 sources could now be regenerated and future builds and releases wouldn't run into these problems with Win32 or HGL anymore?
I believe so.
-------------------------------------------------------------------
Just as long as someone remembers to do the re-greencarding <<<
in cvs: hslibs/win32 before the next release,
I'll do that tonight. (Not sure if I can test it that soon but I figure I can't break it any worse than it already is.)
please, because that won't happen automatically anymore (but then I may be wrong about this - I don't understand the fptools Makefiles, yet;-).
My assumption is that the machine generated files are in the repository so that they don't have to install greencard on their test machines so, yes, I'd guess that's right. [btw GHC folks. Instead of putting greencard-generated code into the CVS repository, why don't you run the CVS copy of GreenCard using Hugs - I do it all that way all the time. That'd avoid the cyclic dependency between building GreenCard and building the libraries. It's a small extra requirement to install Hugs on your test machines but we only do one or two releases a year and GreenCard works fine with all of them. I'm sure it runs just as well under NHC if you'd prefer that route. Or you could even compile GreenCard with the copy of GHC you use to build GHC with.]
PS. I still have to figure out how to make hslibs/win32 in isolation,
This seems like a common need for which there should be a standard plan of attack. Sadly, I don't know it. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
-------------------------------------------------------------------
Just as long as someone remembers to do the re-greencarding <<<
in cvs: hslibs/win32 before the next release,
I'll do that tonight. (Not sure if I can test it that soon but I figure I can't break it any worse than it already is.)
I just committed some freshly greencarded files. I also added ghc.mk which is the makefile I used to greencard with. I haven't added any rules to compile the greencard output with ghc - I can't test anything I wrote so I figure best to leave the file uncluttered than to put in broken stuff. A
participants (2)
-
Alastair Reid -
C.Reinke