claus.reinke:
> Don,
>
> thanks for your answers - that looks very promising.
>
> > Only as these are the systems that I've tested on, or that others have.
> > I don't have access to a Windows machine. hs-plugins should only be
> > limited to platforms with a working GHC dynamic loader, which is
On Mon, Aug 16, 2004 at 04:17:31PM +0100, MR K P SCHUPKE wrote:
> >There is a portable System.Process library here:
>
> On that note, perhaps all signals on unix should be
> set to ignore, so if you are writing cross platform
> code you don't have to do special stuff with say
> sigPIPE for exampl
>There is a portable System.Process library here:
On that note, perhaps all signals on unix should be
set to ignore, so if you are writing cross platform
code you don't have to do special stuff with say
sigPIPE for example
Keean.
___
Glasgow-ha
On 16 August 2004 15:37, Carsten Schultz wrote:
> Hi!
>
> On Mon, Aug 16, 2004 at 03:31:04PM +0100, Claus Reinke wrote:
>> a cursory browse of the sources shows up things like "POpen" and
>> "Posix", both no-nos, as far as portable ghc code is concerned (no
>> longer supported in the default ghc
Hi!
On Mon, Aug 16, 2004 at 03:31:04PM +0100, Claus Reinke wrote:
> a cursory browse of the sources shows up things like "POpen" and "Posix",
> both no-nos, as far as portable ghc code is concerned (no longer supported
> in the default ghc for windows, AFAIK). it would be good if ghc-users would
>
Don,
thanks for your answers - that looks very promising.
> Only as these are the systems that I've tested on, or that others have.
> I don't have access to a Windows machine. hs-plugins should only be
> limited to platforms with a working GHC dynamic loader, which is all the
> systems I've teste
On 16/08/2004, at 11:23 AM, Donald Bruce Stewart wrote:
Some timings for the various flavour of load() are in the Haskell
Workshop paper.
... which is at http://www.cse.unsw.edu.au/~dons/hs-plugins/paper/
--
% Andre Pang : trust.in.love.to.save
___
Glasgo
claus.reinke:
> I think you're providing workarounds for some serious short-
> comings in Haskell! while a fully integrated design would be
> nicer (as in the old orthogonally persistent systems - google
> for "type-safe linguistic reflection"; or more recently in Clean),
> I look forward to havi
Hi Don,
I think you're providing workarounds for some serious short-
comings in Haskell! while a fully integrated design would be
nicer (as in the old orthogonally persistent systems - google
for "type-safe linguistic reflection"; or more recently in Clean),
I look forward to having at least a p
