headers
Galchin Vasili | 1 Dec 2007 03:28
Picon

trouble building "unix-2.2.0.0" on cygwin

Hello,

      0) All work being done on cygwin. Version 6.8.1 of ghc.

     1) I ran "runhaskell Setup.lhs configure" and did a "tail -f config.log" in order to follow the config process.

     2) Next I did the build "runhaskell Setup.lhs build" but there were many include files referenced in HsUnix.h that couldn't be found, e.g. sys/times.h, sys/resources.h, sys/wait.h, ....

    3) I went back through the file config.log and all of the so-called missing include files had supposedly been found during the config process.
  
    4) Next I went to c:/cygwin/usr/include/sys and found all of the so-called missing include files.

    I am trying to get my confidence level up with respect to the config/build/install (and along with darcs and haddock) process up high so I can make a significant contribution to the Haskell effort. please .. any help will be appreciated.

Kind regards, Vasya

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 2 comments |
headers
Galchin Vasili | 1 Dec 2007 03:39
Picon

Re: trouble building "unix-2.2.0.0" on cygwin

More elaboration ...

1) i checked HsUnixConfig.h and the macro HAVE_SYS_TIMES_H is set to 1

On Nov 30, 2007 8:28 PM, Galchin Vasili <vigalchin <at> gmail.com > wrote:
Hello,

      0) All work being done on cygwin. Version 6.8.1 of ghc.

     1) I ran "runhaskell Setup.lhs configure" and did a "tail -f config.log" in order to follow the config process.

     2) Next I did the build "runhaskell Setup.lhs build" but there were many include files referenced in HsUnix.h that couldn't be found, e.g. sys/times.h, sys/resources.h, sys/wait.h, ....

    3) I went back through the file config.log and all of the so-called missing include files had supposedly been found during the config process.
  
    4) Next I went to c:/cygwin/usr/include/sys and found all of the so-called missing include files.

    I am trying to get my confidence level up with respect to the config/build/install (and along with darcs and haddock) process up high so I can make a significant contribution to the Haskell effort. please .. any help will be appreciated.

Kind regards, Vasya

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 0 comments |
headers
Ben Franksen | 1 Dec 2007 04:53
Picon

Re: Re: Re: Waiting for thread to finish

Paul Moore wrote:
> On 28/11/2007, Ben Franksen <ben.franksen <at> online.de> wrote:
>> It was fun, too. For instance, the OP's question reminded me of a little
>> generic wrapper I wrote  -- more or less for my own amusement -- during
>> the course of this project. It outputs dots during an operation that
>> might take a little longer to finish (a database query in my case)...
>> just so the user doesn't get nervous ;-) And because I enjoyed it so much
>> (and to show off) I threw in the timing measurement...
> [...]
>> I think nobody in his right mind would even try to do something like that
>> in C or Perl or whatever, at least not if it wasn't strictly a
>> requirement and correct operation is important (the script gets executed
>> as part of our build process and a subtle concurrency bug could lead to a
>> wrong configuration for the target control system). In Haskell it was so
>> easy to do that I just couldn't resist.
> 
> That's a neat idea. Just (a) because I like the idea, and (b) because
> I'm contrary :-) I coded up the equivalent in Python. It also looks
> beautifully clean:
> [snipped python code]

Looks good to me. I' walk back on the "or whatever" with regard to
Python... ;-)

Cheers
Ben
Permalink | Reply | 0 comments |
headers
Don Stewart | 1 Dec 2007 04:56
Favicon
Gravatar

Re: fast Array operations: foldl, drop

lemming:
> 
> On Fri, 30 Nov 2007, Ketil Malde wrote:
> 
> > Bryan O'Sullivan <bos <at> serpentine.com> writes:
> >
> > > For higher dimensions, there are enough options in terms of
> > > traversal direction and what exactly e.g. a fold should fold over
> > > (single elements? lower-dimensional slices?) that a sensible API
> > > doesn't exactly leap out.
> >
> > How about a 'reduce' instead of 'foldl1'?  I think that if you require
> > a commutative operator, the order doesn't matter (except for
> > efficiency and possible rounding issues, I guess).
> 
> For what I have in mind the order of execution matters.
> 
> I also think now that slices for higher dimensional arrays are useful,
> anyway. If you choose a subrange of indices in the most significant
> dimension this would be possible without copying. It would be also
> possible to 'reshape' (in MatLab terms) an array without copying, as long
> as the number elements remain the same. So you could first transform an
> array of arbitrary dimension to a two-dimensional one, say

I forgot to mention this early, but possibly you could use the ndp array 
library. There are some people using its UArr type for (non parallel)
strict arrays, that support map/fold/zip et al.

    http://darcs.haskell.org/packages/ndp/

This blog post recently,

    http://sequence.complete.org/node/371

shows at least one non-developer is using it :)

Roman, what do you think -- are the unlifted, non-parallel arrays usably `beta'?

-- Don
Permalink | Reply | 3 comments |
headers
Ben Franksen | 1 Dec 2007 05:06
Picon

Re: Re: Re: cabal-install

Duncan Coutts wrote:
>> Apropos beta-testing, cabal-1.3 seems to have introduced an incompatible
>> API change; for instance, it can't build MissingH any longer.
> 
> Actually it was 1.2.x that made this change.

Ok. I realized it wasn't 1.3 as I remarked later:

>> One install of cabal-install later: same error with MissingH. So the
>> package was broken to begin with an it wasn't related to the cabal
>> upgrade! Grrrr.
> 
> Yup. It's not been updated to work with ghc 6.8 and related libs.

I tried this (as everything else in this thread) with ghc-6.6.1. It seems to
me that MissingH-0.18.6 only builds with an earlier version of Cabal.

>> Unpacking MissingH and looking at the Setup.hs I see that I can simply
>> replace it by a generic version, add unix dependency to the cabal file,
>> and all works well. So much for "never again runhaskell Setup blabla" ;-)
> 
> I expect it can use configurations to add the unix package dependency
> conditionally and not need a custom Setup.hs file at all.

That would be nice.

>> (I should add that for many packages cabal-install works perfectly well.)
>> 
>> Thanks again for your help!
>> 
>> Cheers
>> Ben
>> PS: a 'cabal remove' would also be nice to have.
> 
> http://hackage.haskell.org/trac/hackage/ticket/106

+1 from my side.

Cheers
Ben
Permalink | Reply | 0 comments |
headers
PR Stanley | 1 Dec 2007 07:18

Editorial error or something meaningful?

Hi
taken from ch.8.3 in the Hutton book:
"Whereas return v always succeeds, the dual parser failure always 
fails regardless of the contents of the input string:"
The dual parser failure?
Cheers,
Paul
Permalink | Reply | 2 comments |
headers
Luke Palmer | 1 Dec 2007 08:06
Picon
Gravatar

Re: Design of a Physics Interface

On Nov 30, 2007 7:26 PM, Dan Weston <westondan <at> imageworks.com> wrote:
> There seems to be three salient benefits of using arrows, as I read the
> Abstract and Introduction of Benjamin Lerner, "Arrow Laws and Efficiency
> in Yampa", 2003,
> http://zoo.cs.yale.edu/classes/cs490/03-04a/benjamin.lerner/
>
> 1) The discipline of using arrows assists in avoiding space-leaks
>     "The reasons underlying this...primarily stemmed from the
>      availability of signals as first-class values."
>     [the "ugly pain" you experience up front saves you
>      chronic pain later. Self-discipline is the key to a happy life.]

I experienced the chronic pain in my initial comonadic implementation
of FRP.  It was
pretty, but ran in quaadratic time :-(.

To be clear, I am not abandoning arrows in FRP.  I am abandoning using
an arrow to
represent *each* object in favor of moving objects into the value level rather
than the signal level.

i.e. the following dies:

ball :: Position -> Velocity -> SF PhysIn PhysOut
...

In favor of

game = proc () -> do
    rec world <- integrate initWorld -< trajectory world
    ...

I have an idea for an external solution though that I'm going to play
with now.  I'll
report on how it goes :-)

Luke
Permalink | Reply | 0 comments |
headers
Jon Fairbairn | 1 Dec 2007 11:34
X-Face
Picon
Picon
Favicon

Re: Editorial error or something meaningful?

PR Stanley <prstanley <at> ntlworld.com> writes:

> Hi
> taken from ch.8.3 in the Hutton book:
> "Whereas return v always succeeds, the dual parser failure
> always fails regardless of the contents of the input
> string:"
> The dual parser failure?

It's a question of how you parse the phrase "dual parser
failure".  The name of the parser is "failure" and it is the
dual (roughly meaning "opposite") of the parser "return".

--

-- 
Jón Fairbairn                                 Jon.Fairbairn <at> cl.cam.ac.uk
Permalink | Reply | 0 comments |
headers
Daniel Fischer | 1 Dec 2007 12:47
Picon

Re: Editorial error or something meaningful?

Am Samstag, 1. Dezember 2007 07:18 schrieb PR Stanley:
> Hi
> taken from ch.8.3 in the Hutton book:
> "Whereas return v always succeeds, the dual parser failure always
> fails regardless of the contents of the input string:"
> The dual parser failure?
> Cheers,
> Paul
>
The dual parser, "failure", probably.

Cheers,
Daniel
Permalink | Reply | 0 comments |
headers
david48 | 1 Dec 2007 13:37
Picon

Re: Re: Categories list in French (off-topic?)

On Nov 30, 2007 9:13 PM, Maurí­cio <briqueabraque <at> yahoo.com> wrote:

> Nice tip. Do you know of a free news server
> that allows read and post for that group?

http://groups.google.com/group/fr.sci.maths/topics?lnk=gschg
Permalink | Reply | 0 comments |

Gmane