HGL with GHC in Win32

[C.Reinke]

---------------------------
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 
    text files in each of the major cvs directories)
  - add a link to ghc build guide (which has more complete 
    how to use this cvs info, and more info about the structure)
  - add a link to ghc commentary
  
and

  - add a link to cvs.haskell.org from the top of
    www.haskell.org/libraries/ 

2. introduce parts of hslibs as cvs modules (see cvs(5), so that 
   one can say "cd fptools; cvs co win32" and get all the relevant
   subdirectories and tools. The current suggestion, to do
   "cd fptools; cvs co hslibs/win32" will only give the win32
   subdirectory of hslibs, but not necessarily all files that
   are needed to do a make there..
---------------------------

>> Anyway, is there a useable win32 green card input package hanging
>> around somewhere (the link to glasgow is dead it seems; CVS has
>> moved the gc-sources aside and has never been very modular - is
>> there a way for me to take the win32/gc-src/ directory from CVS and
>> make it, without having to prepare the various other parts of
>> fptools that fptools-Makefiles tend to depend on so merrily?-(.
>
>I have no idea how to do it.  GreenCard I can do (details attached)
>but building Win32 for GHC is beyond me.  

GreenCard is no problem - there's that nice installer, and since
there is no HOpenGL without GreenCard so far, I had to install
GreenCard anyway;-) Unless there have been relevant changes that
would force me to use the cvs version?

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

Ok, I tried that change - no difference.

> 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? Or, even better: once the
various ffi implementations have settled down to the latest spec,
and <dream>HOpenGL works with all Haskell implementations</dream>,
perhaps HGL could be ported to HOpenGL - to eliminate all further
portability issues (missing features under X, etc.)..

Personally, I think I'll try to stick with HOpenGL for both 3d and
2d, but for teaching purposes, there would need to be a simple
interface, a la HGL, and it would have to work with Hugs as well.
But having to switch interfaces when moving from hugs to ghc would
keep students from doing that. So perhaps we need to keep HGL!-)

> What really needs done though is to introduce a single
> semaphore to control all access to all parts of the HGL data
> structures - atomically accessing each part of the data structures
> doesn't necessarily protect all the system invariants.

I'll leave that to others:)

> >   For a start, what about NoInline pragmas for global IORefs?
> 
> Yes, that should be done.  

Tried that as well - no difference (at least not at this stage,
that is, but both the MVars and the pragmas look like the right
thing to do overall).

Btw, you use yield before a potentially blocking call - would the
latter run into the problems (default-configured) ghc has with
blocking foreign calls (see multithreading support in the ghc
commentary)?

Probably not, because it works with Hugs, which has only
non-preemptive concurrency, but I thought I'd better ask..

Or is this what you referred to with GreenCard's safecode?

> (Hmmm, maybe we should push harder on a portable language
> extension for defining global, mutable, monomorphic IORefs.)

The current hack kind of seems to work, yet discourages wide useage
- the problem with a language extension is that noone has suggested
a good solution yet, and noone wants to freeze a hack into the
language (parameterised modules would be my personal favourite, even
though that's not quite as "convenient" as the current hack).

> > --safe-code a try.  But why doesn't the green card input use
> > %safecode to eliminate that potential error source?-) 
> 
> Because I wrote the Win32 bindings for Hugs where %safecode and %code
> mean the same thing.  Really, GreenCard should be changed so that %code 
> is safe by default and you have to write %unsafecode to get the faster
> version.  (That's the way it is in the ffi.)

Either change looks like a straightforward substitution?

> > And how would cross-ffi garbage-collection issues affect window
> > parameters at startup?
> 
> Not sure what you mean - I can't think of any new issues in GC which
> aren't present in Hugs.

I was just trying to understand what safecode does, and the
GreenCard docs say it's about foreign code that might trigger GCs.
Which is allright, but at startup (when the window size parameters
are ignored) there shouldn't be any GCs, so the question was how
the lack of safecode is supposed to cause the effects I see.

> > Anyway, is there a useable win32 green card input package hanging
> > around somewhere (the link to glasgow is dead it seems; CVS has
> > moved the gc-sources aside and has never been very modular - is
> > there a way for me to take the win32/gc-src/ directory from CVS and
> > make it, without having to prepare the various other parts of
> > fptools that fptools-Makefiles tend to depend on so merrily?-(.
> 
> I'm attaching a crudely hacked up version of hugs.mk which generates
> the necessary .hs files.

Thanks, that should help - I'll try it next week. I had all kinds of
problems with the CVS makefile, not only that it doesn't like to be
used in isolation, but complaints about missing files in the win32
package itself, which seems rather unlikely (perhaps a side-effect
of the cross-CVS dependencies?). Also, I'm quite confused about the
current CVS structure - I'm looking in fptools/hslibs, but shouldn't
all that have moved into the new libraries somewhere?

My win98 system here at home has even more problems (apart from a
full disk, or taking ages to configure stuff I haven't even checked
out of cvs..) than the win2k box: when trying to compile the
snowflake example with ghc5.02 and SOE graphics, I get a linker
error - about a missing Win32Window_dfQU .. 

So I won't be back on the problem before Tuesday, I guess.

Claus