>> ---
> 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
> 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.
> ---
> >> 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.
Claus:
>> The size problem is traceable to [Greencard's ffi code generation]
Alastair:
> The problem seems to be present in the current repository.
> Hmmm, I distinctly remember tracking this down and fixing it but it
> doesn't look like I committed the change - I'll check in the
> morning.
I
> sounds familiar, and I've got to admit that the ffi part sounds more
> interesting;-)
I think I did the interesting part about a year and a half ago when I
first wrote an ffi-like system. I'm now contemplating how to make the
configure system automagically detect how to build shared object fi
> A long-term goal is to refactor the code into a portable layer, a
> layer which can be ported (i.e., a maze of ifdefs) and a
> machine-dependent layer. I'm not sure when I'll get to that - work,
> my current ffi hacking and some personal stuff are consuming all my
> time.
sounds familiar, and
>> I guess the Win32 version has fallen behind.
> Yet in other aspects, the SOE version is ahead.. Would it be
> possible to resynch the various versions?
A long-term goal is to refactor the code into a portable layer, a
layer which can be ported (i.e., a maze of ifdefs) and a
machine-dependen
---
Two suggestions for CVS maintainers:
1. we could make better use of the cvs.haskell.org home page:
- add a link to the cvs-web interface proper
- add an overview of what is where in the cvs tree
(probably best generated automatically from brief description
> Shouldn't all those IORefs (e.g., for the list of windows) be
> MVars in the GHC version?
We did that for the X11 version - I guess the Win32 version has fallen
behind. What really needs done though is to introduce a single
semaphore to control all access to all parts of the HGL data
struct
> Thanks for looking at this Claus.
no problem - I'm kind of nearby, and I'm not promising anything
(unless just looking at it is going to help;-).
> > - the full-screen titlebar effect with the SOE variant suggests
> > some window-handling incompatibility, if it wasn't for Hugs and GHC
> > u
Thanks for looking at this Claus.
> - the full-screen titlebar effect with the SOE variant suggests
> some window-handling incompatibility, if it wasn't for Hugs and GHC
> using the same graphics source code.. (is there a difference in the
> win32 bindings for Hugs vs GHC?)
[This mail got rat
S J Thompson <[EMAIL PROTECTED]> writes:
> Can anyone help? I would like to run a program using the Haskell
> Graphics Library under GHC on Windows. HGL is listed as a package
> (when ghc is asked about its packages) but not actually
> distributed
> as a package with ghc-5.02.3. On trying to reme
S J Thompson <[EMAIL PROTECTED]> writes:
> Can anyone help? I would like to run a program using the Haskell
> Graphics Library under GHC on Windows. HGL is listed as a package
> (when ghc is asked about its packages) but not actually distributed
> as a package with ghc-5.02.3. On trying to remedy
Can anyone help? I would like to run a program using the Haskell
Graphics Library under GHC on Windows. HGL is listed as a package
(when ghc is asked about its packages) but not actually distributed
as a package with ghc-5.02.3. On trying to remedy this,
- I am able to compile HGL by
14 matches
Mail list logo
