All the Perl that's Practical to Extract and Report

Day 61: Sockets, threads, GHC 6.4!

autrijus on 2005-04-02T19:03:35

Too many things happened today and I'm too tired; I guess I'll fill in the blanks tomorrow and update this space. Just some short bullet points for now:

  • Pugs now require GHC 6.4, so we're finally out from the #ifdef hell.
  • Socket primitives are in: see HTTP server and client as examples. Corion is working on a LWP clone.
  • Thread primitives are in, too; the server example above uses the async {} constructor for threads, which works just like Perl 5's threads::async, except faster and more reliable.
  • mugwump triggered a source tree reorganization; the criteria for ext/ are now much more consistent and much cleaner, thanks to great suggestions by stevan, ingy and other people.
  • At my request, ingy the scribe has put Perl6::Bible to CPAN.
  • Pugs::MakeMaker is now renamed as Perl6::MakeMaker, and darren is now doing a real perl6 clone based on it.
  • We started to adopt GADTs, which has uncovered interesting optimization possibilities, and makes IMC generation much easier.
  • shapr implemented chr(), ord() and hex().
  • { block } in qq and rx was eating trailing whitespaces; fixed.
  • slurp($handle) and split(rx:perl5/.../, $string) now both works.
  • mugwump worked on the S29 draft to add OO methods for builting classes. He also began resummarizing Larry's p6l mail into the S28 draft.
  • We can now define and invoke subroutines in other namespaces by adding :: as part of its name.
  • ...lots of other developments; I'll fill in later, sorry...

Finally, let me add that acme is a Mad Ebugger (I want that for Pugs too!), obra's RESTish Bamboo rocks, and best wishes to ingy/gugod on getting FreePAN all up and tidy for tomorrow's Pugs release.

Pugs and compile requirements

rg0now on 2005-04-02T20:39:25

Pugs now require GHC 6.4, so we're finally out from the #ifdef hell.

This was the last one in a sequence of events that got me to the point of being unable to build Pugs from this forth.

It started with the recent development of compiling Parse.hs with GHC requring about 220 MB of memory that immediately put all my PCs at home out of business. My last chance was a Linux server at work, but it comes with GHC 6.2 and I have no chance to get the sysadmins upgrade it (it even was a huge win to at least convince them to install ghc for me...).

I see that Pugs now have nice Debian build scripts. Couldn't you make somehow nightly binary snapshots available as debian packages?

thanks: rg0now

Re:Pugs and compile requirements

autrijus on 2005-04-03T03:57:19

Please ask scw on IRC about the debian snapshots.

Also, for your PCs, I have just committed a "make unoptimized" flag that should make it much happier. Let me know if it works or not. :)

Re:Pugs and compile requirements

rg0now on 2005-04-03T17:07:41

For me at least, "make unoptimized" does not seem to impact the memory requirements of compiling Pugs (it still uses some 200 MB RAM every now and then), however, upgrading to ghc6-4 (as of Debian experimental) and to a more stable Linux kernel (from a highly experimental Con Kolivas patch set) definitely do: I can now compile Pugs at home. Thank you autrijus!

p.s.: it appears that Parse.hs and Eval.hs (not sure about this) are the most demanding files, and as Pugs evolves, it will just get even worse. Maybe you could split these ones into more parts??

GHC 6.4?

merlyn on 2005-04-02T21:05:25

Hmm. The fink packages for OSX are up to only 6.2, so I guess that means I'll have to deinstall Pugs for a while now. :(

Re:GHC 6.4?

sri on 2005-04-02T22:22:59

Try DarwinPorts...

Re:GHC 6.4?

acme on 2005-04-03T00:50:00

GHC make their own 6.4 packages available.

Hear my plea.

schwern on 2005-04-03T11:20:48

Pugs::MakeMaker is now renamed as Perl6::MakeMaker, and darren is now doing a real perl6 clone based on it.

For god's sake don't port MakeMaker into Perl 6. That is all.

Re:Hear my plea.

markjugg on 2005-04-04T23:45:23

(because Module::Build is a better solution. Port Module::Build instead).

But listen to Schwern, since he maintains MakeMaker now /and/ advocates using M::B instead of it.