working towards a new release
Gentlemen, I think it's time to start putting together a new release of Hugs. A steady trickle of bug fixes, a beefed up FFI and support for the hierarchical libraries, makes this more than worthwhile. So, if people could give me / the CVS list an indication of what remains to be done on the parts they're working on, that'd be helpful. In general, I think we're in a good shape for putting out a release candidate relatively soon. Double-checking the bug reports to verify that nothing major has slipped through the cracks remains to be done; I don't expect anything too big to show up there. --sigbjorn
On Wed, Aug 07, 2002 at 08:17:57AM -0700, Sigbjorn Finne wrote:
I think it's time to start putting together a new release of Hugs. A steady trickle of bug fixes, a beefed up FFI and support for the hierarchical libraries, makes this more than worthwhile.
So, if people could give me / the CVS list an indication of what remains to be done on the parts they're working on, that'd be helpful.
The new library setup works for me, both for accessing the hierarchical libraries and for providing a backwards-compatible interface that old Hugs programs can continue to use. But it probably hasn't had enough testing yet to risk replacing the old libraries, so I'd suggest shipping an installation that provides both, so users have the option of using the new one. There is room for cleaning up the internals, e.g. sharing more code, but this won't be visible to users, and isn't required for release.
So, if people could give me / the CVS list an indication of what remains to be done on the parts they're working on, that'd be helpful.
The only goals I think I can achieve any time soon is: I'd like to find a way to make hugs +G silent and usable from within Makefiles (i.e., return an error code). Tweak hugs? Tweak runhugs? Since ffi-generated files are architecture-dependent, make install ought to put ffi-generated code into an architecture-dependent directory. Is that ${libdir}? (I'll happily let someone else do this if they get the urge.) Other things needing done are: I think there's more ffi-dependent libraries to be had simply by tweaking convert_libraries and MkInstall.in It'd be good to make a list of all the libraries and add a test which does nothing more than load the lot of them. There's some tests of this nature for the old libs. (This might have been done already for all I know.) -- Alastair
So, if people could give me / the CVS list an indication of what remains to be done on the parts they're working on, that'd be helpful.
I thought I'd finished everything and could get the HGL stuff up and going with the new ffi when... 1) I tried using ffihugs on Linux: Yoiks: you have to put double quotes round the +L argument: ffihugs +G +L"\"foo bar\"" Baz The reason is that server.c tries to split each option argument into a list of option arguments. How can I work around this? (I'm tempted to fix server.c to _not_ do this - but it's clear that someone once thought it was a good idea to make it work this way so I'd probably break something else in the process.) 2) I tried using ffihugs on Win32 but... Hugs can't detect if the invocation of CC fails because (IIRC) Win32's 'system' call always returns success. How can we fix this? Is there something else we can use instead? (There's also a problem that my code in ffi.c assumes that / is the directory separator but the fix for this is obvious.) -- Alastair
On Sat, Aug 10, 2002 at 01:08:06AM +0100, Alastair Reid wrote:
1) I tried using ffihugs on Linux:
Yoiks: you have to put double quotes round the +L argument:
ffihugs +G +L"\"foo bar\"" Baz
The reason is that server.c tries to split each option argument into a list of option arguments.
How can I work around this? (I'm tempted to fix server.c to _not_ do this - but it's clear that someone once thought it was a good idea to make it work this way so I'd probably break something else in the process.)
It was put there because #! only permits one argument. But it is a horrible wart. I think there some special syntax do demand arg splitting, so that everyone else doesn't have to pay for it.
"Alastair Reid"
So, if people could give me / the CVS list an indication of what remains to be done on the parts they're working on, that'd be helpful.
I thought I'd finished everything and could get the HGL stuff up and going with the new ffi when...
1) I tried using ffihugs on Linux:
Yoiks: you have to put double quotes round the +L argument:
ffihugs +G +L"\"foo bar\"" Baz
The reason is that server.c tries to split each option argument into a list of option arguments.
How can I work around this? (I'm tempted to fix server.c to _not_ do this - but it's clear that someone once thought it was a good idea to make it work this way so I'd probably break something else in the process.)
The shell strips away unescaped double/single quotes, so this shouldn't come as much of a surprise (and isn't really a Hugs issue, per se.) If you don't want to support multiple -L options on a single command line, I don't really see a way out beside adding an escaped set of quotes. input.c:readFilename() does elide double quotes though -- a version that don't could easily be provided, but it won't really fix your problem.
2) I tried using ffihugs on Win32 but...
Hugs can't detect if the invocation of CC fails because (IIRC) Win32's 'system' call always returns success.
How can we fix this? Is there something else we can use instead?
Works fine here (i.e., compilation failures are reported as errors.) --sigbjorn
Yoiks: you have to put double quotes round the +L argument:
ffihugs +G +L"\"foo bar\"" Baz
The shell strips away unescaped double/single quotes, so this shouldn't come as much of a surprise (and isn't really a Hugs issue, per se.)
The point was that you don't need this with hugs but do with runhugs (and, hence, with ffihugs).
If you don't want to support multiple -L options on a single command line, I don't really see a way out beside adding an escaped set of quotes.
I was thinking in terms of moving the argument parsing hack out of server.c and into runhugs. I hadn't really thought about how I'd do this - maybe have 'parse lots of options' and 'parse one option' entrypoints. Allowing multiple -L options per line would be easier though and we'd only encounter the problem when passing filenames with spaces in them to hugs - probably only happens on windows.
Works fine here (i.e., compilation failures are reported as errors.)
Haven't tried yet whether your recent commit fixes this - but I wonder if you're using something more recent than win98? A
"Alastair Reid"
Works fine here (i.e., compilation failures are reported as errors.)
Haven't tried yet whether your recent commit fixes this - but I wonder if you're using something more recent than win98?
Yes, I am. I'm unable to verify right now whether this is an issue with Win 9x systems (i.e., systems that use COMMAND.COM as their command processor), but if it is, I don't think this is too big a deal. --sigbjorn
Sigbjorn:
So, if people could give me / the CVS list an indication of what remains to be done on the parts they're working on, that'd be helpful.
Alastair:
1) [...] you have to put double quotes round the +L argument: [...] 2) I tried using ffihugs on Win32 but... [...]
Just wanted to report that these are still outstanding (though Sigbjorn's commits may have fixed (2) for all I know). I'm hoping to get these cleared up tonight or tomorrow. A
Gentlemen, I think it's time to start putting together a new release of Hugs.
I've got my head buried in a paper I'm writing (deadline Monday night) so I've sort of lost track of the big picture. It seems like we're pretty close to starting with release candidates (despite the GHC camp's efforts to pull the non-hierarchial libraries out from under us :-). Is this more or less true? What remains to be done? A
We're ready, I think.
My nose is in relative close proximity to the grindstone at
the moment, so I won't have time to start doing any packaging
until the weekend, at least. I'm planning to do a little bit of
background tweaking during the week + double check the
bug reports, to make sure we haven't let anything major slip
through the cracks.
We do have a problem wrt. documentation though - the original
docs are out-of-date and essentially dead, as the author isn't willing
to part with the doc sources. So, either we rewrite from scratch or
continue supplying .txt files along with the old user's manual.
--sigbjorn
----- Original Message -----
From: "Alastair Reid"
Gentlemen, I think it's time to start putting together a new release of Hugs.
I've got my head buried in a paper I'm writing (deadline Monday night) so I've sort of lost track of the big picture.
It seems like we're pretty close to starting with release candidates (despite the GHC camp's efforts to pull the non-hierarchial libraries out from under us :-). Is this more or less true? What remains to be
done?
A _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
We're ready, I think.
Excellent, I'll give HGL another round of testing with the latest version.
We do have a problem wrt. documentation though - the original docs are out-of-date and essentially dead, as the author isn't willing to part with the doc sources. So, either we rewrite from scratch or continue supplying .txt files along with the old user's manual.
Rewriting from scratch isn't too attractive. Maybe we could collect the .txt together into a LaTeX file, and include the old doc by reference? It's not a perfect solution but it meanas that what we ship as the documentation is up to date, can put the old doc in context, prints nicely, and all that good stuff. I've got a few days free so I could take a stab at this. A
participants (3)
-
Alastair Reid -
Ross Paterson -
Sigbjorn Finne