Pugs.hs is back

brian_d_foy on 2008-07-31T22:46:00

(The excellent news from fglock++ that v6.pm is back prompted me to write something about Pugs, too, so here it is.)

During the past month, I've been quietly releasing Pugs and its dependencies on Hackage.

Installation for Pugs is now much simpler than before; see http://svn.pugscode.org/pugs/INSTALL for details.

There has been no action in terms of features, but the internal has been refactored to reduce compilation time, and the individual components has been released as separate packages to reduce maintenance overhead.

Startup time is also greatly improved. As a consequence, running the full smoke test suite is no longer a multi-hour-long ordeal; it now takes less than 15 minutes on modern machines.

As of the 6.2.13.11 release, the smoke numbers say it passes 17215 tests out of 19260, which is not significantly different from the 6.2.13 release.

Going forward, I think GHC 6.10's Quasiquoting and View patterns are going to be vital for the sanity of Pugs internals, so please expect no Pugs 6.28.* releases before GHC 6.10.1.

And finally, a shameless plug: I'm still looking for ways to make ends meet, so any offers of telecommuting, project-based/part-time jobs would be very much appreciated. :-)


welcome back!

systems on 2008-07-31T09:21:37

really weird, just yesterday i was wondering where you been hiding!

anyway welcome back to Perl!

Great news (and test suite)

moritz on 2008-07-31T11:31:45

This is great news, and very welcome indeed.

But I also have to add that part of the reduced runtime is due to many changes in the tests that leads to parse failures and thus early exists.

The biggest chunk is the changed POD. We're slowly converting the old style POD from

  =pod

  ...

  =cut

to new style POD

  =begin description

  ...

  =end description

Since pugs can't parse that, the number of failing tests rose significantly.

Re:Great news (and test suite)

audreyt on 2008-08-01T08:51:07

Hmm? I don't see why that would be the case; Pugs parsed the begin/end POD comments just fine for quite a while now.

For example, t/spec/S02-builtin_data_types/subtypes.t has such a block, and pugs passes it just fine (with two unexpected successes).

Is it possible for you to give a single test file for me to try against?

Re:Great news (and test suite)

moritz on 2008-08-01T09:12:39

Sorry for the noise, I tried with an outdated version of pugs. Very Outdated.

But there's something different that came to my mind - are you actually using fudge before running the tests? some of the :todo<feature> markers were removed because they are are implementation specific, and substituted by fudge markers.

In the parrot repository languages/perl6/t/harness integrates fudge, and languages/perl6/tools/autounfudge.pl is a script for autotmatically removing fudge markers from passing tests (which broke due to some changes in rakudo a few days ago) which should also be easy to adopt for pugs.
We could generalize it a bit more and move it to t/spec/ in the pugs repo, if you're interested.

Re:Great news (and test suite)

audreyt on 2008-08-01T09:20:43

Sure, that'd be excellent. I did notice the unTODOing, but that did not trouble me as much because as long as the passing tests are still passing, things are going fine.

In retrospect, I regret the insistence of marking :todo<feature> and making sure that all platforms fails with an equal number with tests before each Pugs release. Much of release engineering effort were spent tracking down platform-specific bugs, while it would make more sense simply to let them fail.

But sure, a fudge script living in t/spec/ sounds like a good thing to have, so I can have the pugs tree refreshed to the Hackage version and run against the newly-fudged spectests.

Re:Great news (and test suite)

moritz on 2008-08-01T09:40:39

The trouble with unTUDOed tests is just that they terminate pugs sometimes, and thus hide other tests.

The fudge and fudgeall scripts already live in t/spec/, so you just have to integrate them into the pugs test harness.
It's the unfudge scripts (that basically writes patches that remove '#?rakudo' or '#?pugs' fudge lines for you) that I considered for moving.

I think that we also need to specify the functionality of Test.pm a bit more since rakudo uses its own (simpler) Test.pm, with slightly different is() semantics (it uses string comparison for now). I'll raise that question on p6c after my vacations.

on cygwin

rurban on 2008-08-01T16:52:27

Hi Audrey,

I described the pugs installation on cygwin at
http://use.perl.org/user/rurban/journal/36897

Re: on cygwin

audreyt on 2008-08-02T10:47:23

Yes, the URL to your journal has been added to the INSTALL file. Many thanks!

A commit bit is on its way to your mailbox; if you can check out the latest Pugs from subversion and see if "perl Makefile.PL ; make" just works on Cygwin, that'd be excellent.

Re: shameless plug

thickas on 2008-08-04T08:09:52

Audrey,

There are many, many people who wish you well in all things (not only for what you may do with Perl).

Have you considered posting a link to say an Amazon wish list so that those who cannot afford to employ you, can register their appreciation ?

Why not revisit TPF with a proposal to do more on what you obviously love, namely the Haskell implementation of P6 ? I can't think of a better way for the TPF to invest some of the Ian Hague cash than doing this, and, were I to learn that they'd sponsored you, it would certainly influence my donation intentions to TPF.

God bless you.

Re: shameless plug

beppu on 2008-08-09T07:34:06

I agree 100% with this. Give people a way to help you, and they will.