Re: Keep the 'keet Re: Renaming Plumhead
Bill Ricker schrieb: Plumhead may sound stupid but there's nothing wrong with Plum-Headed Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's a real bird whose initials spell PHP, what more could you want in a name?. O'Reilly's cover editor will be happy, although they may have to hand-tint the old block to get the evocative colo[u]?ring - they're quite colo[u]?rful, almost pretty in a garish sort of way, which somehow seems appropriate for PHP. http://en.wikipedia.org/wiki/Plum-headed_Parakeet. (One /could/ be obscure and use the latin name http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) On the Wikipedia page I liked the sentence: "Plum-headed Parakeet is a gregarious and noisy species with range of raucous calls." This is definitly a good description of PHP. If what one wants is a short-form of the name that sounds less goofy than "Plumhead" but still much fewer keystrokes than Plum-Headed Parakeet , perhaps PHPkeet would serve as a logotype for the longer formal name with good pun and allusions, and simultaneously serve as a Google(tm)-able keyword distinct from the aviary variety? My favourite short form would be "PHParakeet", pronounced as "P - H - Parakeet". This still has the PHP in it, but only as a sensible abbreviation of "Plum-Headed Parakeet". Regards, Bernhard
Re: Keep the 'keet Re: Renaming Plumhead
On Jun 14, 2008, at 5:49 PM, Bill Ricker wrote: perhaps PHPkeet Forgive me since I haven't been lurking very long here, but would "PHParrot" be appropriate? A ggogle search didn't turn up evidence that it had been considered. Marvin Humphrey Rectangular Research http://www.rectangular.com/
Re: Renaming Plumhead
> As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". > > > > So I'm still open for an alternative. > > Parroheep? > > > IMHO the name needs to be distinctive from parrot - pharrot is a little too close. What about taking the idea from Space Odyssey where they derived the name for the HAL 9000 by shifting the letters of I.B.M. back one to get H.A.L.? Applying this to P.H.P. you get O.G.O. - but someone is using this already to brand software. Hmmm. What about shifting forwards? You get Q.I.Q. -- which could be pronounced "quick" ... a web development company is using this domain -- so less troublesome than O.G.O. but still not totally unencumbered. Hmmm. Just some ideas ... [1] http://en.wikipedia.org/wiki/HAL_9000
Re: Keep the 'keet Re: Renaming Plumhead
2008/6/15 Bernhard Schmalhofer <[EMAIL PROTECTED]>: > Bill Ricker schrieb: > >> >> Plumhead may sound stupid but there's nothing wrong with Plum-Headed >> Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's >> a real bird whose initials spell PHP, what more could you want in a >> name?. O'Reilly's cover editor will be happy, although they may have >> to hand-tint the old block to get the evocative colo[u]?ring - they're >> quite colo[u]?rful, almost pretty in a garish sort of way, which >> somehow seems appropriate for PHP. >> >> http://en.wikipedia.org/wiki/Plum-headed_Parakeet. >> >> (One /could/ be obscure and use the latin name >> http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) >> >> > On the Wikipedia page I liked the sentence: > > "Plum-headed Parakeet is a gregarious and noisy species with range of > raucous calls." > > This is definitly a good description of PHP. > +1 but currently no opinion for the best short-form. François. > > If what one wants is a short-form of the name that sounds less goofy >> than "Plumhead" but still much fewer keystrokes than Plum-Headed >> Parakeet , perhaps PHPkeet would serve as a logotype for the longer >> formal name with good pun and allusions, and simultaneously serve as a >> Google(tm)-able keyword distinct from the aviary variety? >> >> >> > My favourite short form would be "PHParakeet", pronounced as "P - H - > Parakeet". > This still has the PHP in it, but only as a sensible abbreviation of > "Plum-Headed Parakeet". > > Regards, > Bernhard > >
Re: [perl #36407] [BUG] imcc - register allocation
On Sat, Jun 14, 2008 at 08:58:22PM -0400, Bob Rogers wrote: > [...] And > the easiest fix would be to decide not to support it at all. +1. Another +1 if we can somehow get IMCC to report an error when there's a label/symbol conflict. Pm
Re: [perl #55782] [BUG] for 1..1000 -> $a { say $a } segfaults in rakudo (Gargbage Collector)
On Sat, Jun 14, 2008 at 09:54:09AM -0700, Moritz Lenz wrote:
> As AnonMonk reported here: http://www.perlmonks.org/?node_id=692090 the line
> for 1..1000 -> $a { say $a }
> segfaults in rakudo.
Note that this works if '-G' is passed to parrot.
The other comments and diagnostics are all *extremely* helpful.
I'm moving this ticket into the parrot queue instead of the
perl6 (rakudo) queue, since this is most likely a Parrot bug.
Thanks!
Pm
[perl #55840] [TODO] Implement %*ENV
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #55840] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55840 > %*ENV was requested on PerlMonks -- see http://www.perlmonks.org/?node_id=692090 . Pm
Re: Keep the 'keet Re: Renaming Plumhead
Bernhard Schmalhofer wrote: > Bill Ricker schrieb: >> >> Plumhead may sound stupid but there's nothing wrong with Plum-Headed >> Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's >> a real bird whose initials spell PHP, what more could you want in a >> name?. O'Reilly's cover editor will be happy, although they may have >> to hand-tint the old block to get the evocative colo[u]?ring - they're >> quite colo[u]?rful, almost pretty in a garish sort of way, which >> somehow seems appropriate for PHP. >> >> http://en.wikipedia.org/wiki/Plum-headed_Parakeet. >> >> (One /could/ be obscure and use the latin name >> http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) >> > On the Wikipedia page I liked the sentence: > > "Plum-headed Parakeet is a gregarious and noisy species with range > of raucous calls." > > This is definitly a good description of PHP. >> If what one wants is a short-form of the name that sounds less goofy >> than "Plumhead" but still much fewer keystrokes than Plum-Headed >> Parakeet , perhaps PHPkeet would serve as a logotype for the longer >> formal name with good pun and allusions, and simultaneously serve as a >> Google(tm)-able keyword distinct from the aviary variety? >> >> > My favourite short form would be "PHParakeet", pronounced as "P - H - > Parakeet". I seem to recall that PHP forbids redistribution under names that contain "php" as a substring, but at the moment I can't find evidence for it, and I don't know if it applies to independent re-implementations. Nonetheless you should investigate in that direction before choosing PHParakeet as a name. > This still has the PHP in it, but only as a sensible abbreviation of > "Plum-Headed Parakeet". > > Regards, > Bernhard -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #55840] [TODO] Implement %*ENV
Patrick R. Michaud (via RT) wrote: %*ENV was requested on PerlMonks -- see http://www.perlmonks.org/?node_id=692090 . r28377 should do enough to let them do CGI - I or @other needs to look into why iteration doesn't work, and I haven't tested modifying the environment with this yet. Hope this helps, Jonathan
Re: [perl #55840] [TODO] Implement %*ENV
On Sun, Jun 15, 2008 at 05:09:49AM -0700, Jonathan Worthington via RT wrote: > Patrick R. Michaud (via RT) wrote: > > %*ENV was requested on PerlMonks -- see > > http://www.perlmonks.org/?node_id=692090 . > > > r28377 should do enough to let them do CGI - I or @other needs to look > into why iteration doesn't work, and I haven't tested modifying the > environment with this yet. You and I implemented at the same time. I've refactored %*ENV and the other globals into a separate src/builtins/globals.pir file, as I think they really need to happen _before_ main (i.e., whenever the perl6.pbc module is loaded). Thanks! Pm
Re: [perl #55840] [TODO] Implement %*ENV
[resending to perl6-compiler] On Sun, Jun 15, 2008 at 05:09:49AM -0700, Jonathan Worthington via RT wrote: > Patrick R. Michaud (via RT) wrote: > > %*ENV was requested on PerlMonks -- see > > http://www.perlmonks.org/?node_id=692090 . > > > r28377 should do enough to let them do CGI - I or @other needs to look > into why iteration doesn't work, and I haven't tested modifying the > environment with this yet. You and I implemented at the same time. I've refactored %*ENV and the other globals into a separate src/builtins/globals.pir file, as I think they really need to happen _before_ main (i.e., whenever the perl6.pbc module is loaded). Thanks! Pm
[perl #55840] [TODO] Implement %*ENV
Resolved in r28378. Pm
Re: [perl #36407] [BUG] imcc - register allocation
On Sunday 15 June 2008 03:31:56 Patrick R. Michaud wrote: > On Sat, Jun 14, 2008 at 08:58:22PM -0400, Bob Rogers wrote: > > [...] And > > the easiest fix would be to decide not to support it at all. > +1. Another +1 if we can somehow get IMCC to report an error > when there's a label/symbol conflict. I think that may be possible. I'll look into it while I'm fixing another bug in register allocation today. -- c
Re: [perl #55782] [BUG] for 1..1000 -> $a { say $a } segfaults in rakudo (Gargbage Collector)
On Saturday 14 June 2008 09:54:09 Moritz Lenz wrote:
> As AnonMonk reported here: http://www.perlmonks.org/?node_id=692090 the
> line for 1..1000 -> $a { say $a }
> segfaults in rakudo.
>
> The problem can be reproduced by creating a Range with --runcore=gcdebug:
>
> ../../parrot --runcore=gcdebug perl6.p
> bc -e '1..2'
> src/string.c:514: failed assertion '!PObj_on_free_list_TEST(a)'
> Backtrace - Obtained 17 stack frames (max trace depth is 32).
> (unknown)
> Parrot_confess
> string_append
> Parrot_CodeString_nci_emit
> Parrot_NCI_invoke
> Parrot_callmethodcc_p_sc
> (unknown)
> (unknown)
> (unknown)
> (unknown)
> Parrot_runops_fromc_args
> Parrot_runcode
> (unknown)
> imcc_run
> (unknown)
> __libc_start_main
> (unknown)
> Aborted
If someone can turn the PIR produced from this perl6.pbc into a standalone
file, I'm happy to debug the problem.
-- c
Re: [perl #44763] [BUG] Assertion fails if PCRE is not available
James Keenan via RT wrote:
This is what I'm getting on Linux where Configure.pl says that I do not
have PCRE:
$ prove -v t/library/pcre.t t/examples/library.t
t/library/pcre..
1..1
ok 1 # SKIP no pcre-config
ok
t/examples/library..
1..4
ok 1 - examples/library/getopt_demo.pir
ok 2 - examples/library/md5sum.pir
ok 3 # SKIP no pcre-config
not ok 4 - ncurses_life.pir # TODO ncurses_life.pir not testable yet
# Failed (TODO) test 'ncurses_life.pir'
# at t/examples/library.t line 77.
ok
All tests successful.
Files=2, Tests=5, 0 wallclock secs ( 0.00 usr 0.00 sys + 0.11 cusr
0.03 csys = 0.14 CPU)
Result: PASS
Ron, what are you getting now on Windows?
Sorry, should have been more specific. The key here is to make PCRE.dll
disappear when Parrot tries to load it. The tests now check for PCRE
("SKIP no pcre-config"), so you don't even get to this point.
But r28376 seems to handle this gracefully as well, instead of the
failed assertion deep in the guts. Closing this ticket.
$parrot examples\library\pcre.pir ab a
Failed to load libpcre
current instr.: 'parrot;PCRE;init' pc 99 (library/pcre.pir:106)
called from Sub 'parrot;PCRE;main' pc 244 (examples\library\pcre.pir:39)
Ron
[perl #52048] [TODO] tools/util/pgegrep broken, needs tests
On Thu Jun 05 20:44:17 2008, coke wrote: > On Mon Mar 24 10:47:51 2008, coke wrote: > > This tool doesn't currently run (depends on the borked hllmacros.pir, > > perhaps other issues) > > > > This tool needs tests. > > > > Barring that, we could also remove it from the repository. pgegrep is working again as of r28381 Still needs tests, which will no doubt be easier after the ticket for testing parrot run with various options is implemented. (hopefully we can steal some infrastructure for that.) Jim, tag, you're it. =-) -- Will "Coke" Coleda
[perl #55846] realclean fails to remove ./src/asmfun.s in Parrot v0.6.2
Merged the duplicate tickets. -- Will "Coke" Coleda
[perl #55856] Eliminating (?) _handle_darwin_for_macports and _handle_darwin_for_fink
# New Ticket Created by James Keenan
# Please include the string: [perl #55856]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55856 >
Am sending this to RT so a ticket can be opened.
Hi
Running perl ./Configure.pl in parrot 0.6.2 for the first time on a new
clean install of Mac OS X 10.4.11 with Xcode 2.5 on a PPC G4 12" powerbook
the following oddities appeared four times:
Use of uninitialized value in concatenation (.) or string at
lib/Parrot/Configure/Step/Methods.pm line 106
Excerpted output is appended at the end of this message.
Line 106 appears in sub _handle_darwin_for_macports
It is relevant to note that I have neither MacPorts nor Fink installed.
It is also interesting that _handle_darwin_for_fink does not cause this
problem.
So far three methods of cleaning this up have surfaces here at YAPC::NA
Parrot Hackathon:
1) Modify lib/Parrot/Configure/Step/Methods.pm
2) Make _handle_darwin_for_macports be like _handle_darwin_for_fink
3) Eliminate _handle_darwin_for_macports and _handle_darwin_for_fink
We are currently in favor of (3) but we are a bit confused as to
how this was designed to work ... can some one clarify the intent for us?
As for (1), the immediate problem is that if MacPorts is not present then
my $ports_include_dir = $conf->data->get( 'ports_include_dir' );
is undefined (line 105)
and hence line 106
if ( -f qq{$ports_include_dir/$file} ) {
throws the error quoted above.
Although a simplistic 'fix' would be to change line 106 to be
if (defined($ports_include_dir) && -f qq{$ports_include_dir/$file}
) {
it is instructive to compare this routine (_handle_darwin_for_macports)
to the code for _handle_darwin_for_fink. The ..._fink code tests defined-ness
and also tries to reduce duplication of {link,ld,cc}flags.
So, (2) perhaps the ..._fink code should be echoed into the ..._macport code.
However, (3), the more we stare at this the more we are wondering
why do _handle_darwin_for_{macports/fink} even exist ... and why are they
being called four times? The purpose of _handle_darwin_for_macports
seems to be to add MacPorts to Parrot Configure's {link,ld,cc}flags
if needed. Yet the way it is called, MacPorts paths will be added
once for each module that is probed (current four: GMP,readline,pcre,OpenGL).
And why just for these four libraries in config/auto? It seems likely
that requiring each library probe in config/auto to call these routines
is error prone when new probes are added.
Why not just add the MacPorts(Fink) paths *once* at the time of testing
for MacPorts(Fink) existance? And if we did that, might we not be able
to eliminate _handle_darwin_for_macports (and _handle_darwin_for_fink)?
Any thoughts on what (and why) should be done?
Regards,
Todd Olson
= begin excerpt from perl ./Configure.pl ==
Determining if your platform supports GMP...Use of uninitialized value in
concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm line
106.
no.
Determining if your platform supports readline...Use of uninitialized
value in concatenation (.) or string at
lib/Parrot/Configure/Step/Methods.pm line 106.
dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap
Referenced from:
/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/
01/./test
Expected in: dynamic lookup
dyld: Symbol not found: _rl_get_keymap
Referenced from:
/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/
01/./test
Expected in: dynamic lookup
...no.
Determining if your platform supports gdbm..no.
Determining if your platform supports pcre...Use of uninitialized value in
concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm line
106.
...no.
Determining if your platform supports OpenGL...Use of uninitialized value
in concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm
line 106.
.yes, MacOSX_GLUT 5.
= end excerpt from perl ./Configure.pl ==
[perl #55856] Eliminating (?) _handle_darwin_for_macports and _handle_darwin_for_fink
There are two issues here: First: > > Use of uninitialized value in concatenation (.) or string at > lib/Parrot/Configure/Step/Methods.pm line 106 > Should be fixed with patch I committed in r28390. Second: > Determining if your platform supports readline...Use of uninitialized > value in concatenation (.) or string at > lib/Parrot/Configure/Step/Methods.pm line 106. > dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap > Referenced from: > /Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/ > 01/./test > Expected in: dynamic lookup > > dyld: Symbol not found: _rl_get_keymap > Referenced from: > /Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/ > 01/./test > Expected in: dynamic lookup > This is a problem we've seen before re readline and Mac OS X. We should grep the mailing list archive for '_rl_get_keymap'. kid51
[perl #55856] Eliminating (?) _handle_darwin_for_macports and _handle_darwin_for_fink
On Sun Jun 15 12:40:51 2008, [EMAIL PROTECTED] wrote: > > This is a problem we've seen before re readline and Mac OS X. We should > grep the mailing list archive for '_rl_get_keymap'. > And that brought up rt 52212.
Parrot and Smolder
I had mentioned this to some people at the Oslo QA Hackthon, but I've been really busy since then. Now that I'm at YAPC, I should have some good hacking time, so here goes... My place of business (Plus Three, LP) has allowed me to host the smolder install on our smolder server and I've setup Parrot as a project there: http://smolder.plusthree.com/app/public_projects/details/8 I've done a checkout from svn and ran the tests and produced a TAP archive (more on that later) and uploaded it as the first report: http://smolder.plusthree.com/app/public_projects/smoke_reports/8 http://smolder.plusthree.com/app/public_projects/report_details/1192 And an Atom feeds here: http://smolder.plusthree.com/app/public_projects/feed/8 (all) http://smolder.plusthree.com/app/public_projects/feed/8/failed (failed) So I need to do a couple of things to get these kinds of reports in an automated way. 1) Update the test harness to use Test::Harness 3. I'm assuming that right now parrot just uses what ever is installed with the Perl that's on that machine right? Would it be ok to bundle the new T::H with Parrot? 2) Change t/harness to allow an --archive flag which tells it to create a TAP Archive (which is basically just a tar file with a bunch of TAP files in it). There is TAP::Harness::Archive which does this (and it's what prove -a uses behind the scenes), but I don't know if it's appropriate to bundle this with Parrot since it has a dependency on YAML::Tiny and Archive::Tar (which has *a lot* of other dependencies - http://cpandeps.cantrell.org.uk/?module=Archive%3A%3ATar&perl=any+version&os=any+OS). The act of creating a TAP archive is pretty simple with T::H3 if we have a tar utility (and also preferrably gzip). So should I just do that directly in t/harness (or Parrot::Test::Harness) 3) Change the buildbot setup you already have to run the tests and then submit the TAP archives to the Smolder server. This should be pretty simple once I've gotten the changes to t/harness. Questions? Comments? Verbal abuse? -- Michael Peters Plus Three, LP
Re: Keep the 'keet Re: Renaming Plumhead
François Perrad wrote: 2008/6/15 Bernhard Schmalhofer <[EMAIL PROTECTED]>: Bill Ricker schrieb: Plumhead may sound stupid but there's nothing wrong with Plum-Headed Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's a real bird whose initials spell PHP, what more could you want in a name?. O'Reilly's cover editor will be happy, although they may have to hand-tint the old block to get the evocative colo[u]?ring - they're quite colo[u]?rful, almost pretty in a garish sort of way, which somehow seems appropriate for PHP. http://en.wikipedia.org/wiki/Plum-headed_Parakeet. (One /could/ be obscure and use the latin name http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) On the Wikipedia page I liked the sentence: "Plum-headed Parakeet is a gregarious and noisy species with range of raucous calls." This is definitly a good description of PHP. +1 but currently no opinion for the best short-form. François. If what one wants is a short-form of the name that sounds less goofy than "Plumhead" but still much fewer keystrokes than Plum-Headed Parakeet , perhaps PHPkeet would serve as a logotype for the longer formal name with good pun and allusions, and simultaneously serve as a Google(tm)-able keyword distinct from the aviary variety? My favourite short form would be "PHParakeet", pronounced as "P - H - Parakeet". This still has the PHP in it, but only as a sensible abbreviation of "Plum-Headed Parakeet". Regards, Bernhard The name "Pharrot" has the advantages that it's easy to pronounce, it shows that the project is related to Parrot and is fairly close to "PHP". The association with ferrets seems like a good thing and should make the O'Reilly guys happy. The name is unique enough to use in a search query and the .(com|net|org) domain names are available. Using "Pharrot" would also result in a single way of referring to the implementation. Plum-Headed Parakeet is appropriate *if* you know the definition, but it's fairly obscure and won't have any meaningful connotation to the majority of potential users. Additionally, the name is a mouthful and neither of the abbreviations are particularly elegant or obvious to pronounce. As stated, the name "Plumhead" isn't a very good alternative. This project should have a snappy and memorable name. The name will be the first thing people see and as shallow as it is, this will be how people form their first impressions of the project. Making a good first impression is the first step to world domination. Christoph
Re: Parrot and Smolder
On Sun, Jun 15, 2008 at 3:59 PM, Michael Peters <[EMAIL PROTECTED]> wrote: > I had mentioned this to some people at the Oslo QA Hackthon, but I've been > really busy since then. Now that I'm at YAPC, I should have some good hacking > time, so here goes... > > My place of business (Plus Three, LP) has allowed me to host the smolder > install > on our smolder server and I've setup Parrot as a project there: > http://smolder.plusthree.com/app/public_projects/details/8 > > I've done a checkout from svn and ran the tests and produced a TAP archive > (more > on that later) and uploaded it as the first report: > http://smolder.plusthree.com/app/public_projects/smoke_reports/8 > http://smolder.plusthree.com/app/public_projects/report_details/1192 > > And an Atom feeds here: > http://smolder.plusthree.com/app/public_projects/feed/8 (all) > http://smolder.plusthree.com/app/public_projects/feed/8/failed (failed) > > So I need to do a couple of things to get these kinds of reports in an > automated > way. > > 1) Update the test harness to use Test::Harness 3. > I'm assuming that right now parrot just uses what ever is installed with the > Perl that's on that machine right? Would it be ok to bundle the new T::H with > Parrot? In general, we're trying to avoid including more non-core modules with parrot. However I personally wouldn't have a problem with this bundle until we resolve the issues with Bundle::Parrot. (issues == we don't actually require it. =-) > 2) Change t/harness to allow an --archive flag which tells it to create a TAP > Archive (which is basically just a tar file with a bunch of TAP files in it). Sure. > There is TAP::Harness::Archive which does this (and it's what prove -a uses > behind the scenes), but I don't know if it's appropriate to bundle this with > Parrot since it has a dependency on YAML::Tiny and Archive::Tar (which has *a > lot* of other dependencies - > http://cpandeps.cantrell.org.uk/?module=Archive%3A%3ATar&perl=any+version&os=any+OS). > > The act of creating a TAP archive is pretty simple with T::H3 if we have a > tar > utility (and also preferrably gzip). So should I just do that directly in > t/harness (or Parrot::Test::Harness) If we only need this for smolder (and not vanilla "make test"), then I would say don't bundle this, but die nice if it's not installed. And we'll get them added to Bundle::Parrot. > 3) Change the buildbot setup you already have to run the tests and then submit > the TAP archives to the Smolder server. This should be pretty simple once I've > gotten the changes to t/harness. > > Questions? Comments? Verbal abuse? > > > -- > Michael Peters > Plus Three, LP > > -- Will "Coke" Coleda
Re: Parrot and Smolder
Will Coleda wrote: > In general, we're trying to avoid including more non-core modules with > parrot. However I personally wouldn't have a problem with this bundle > until we resolve the issues with Bundle::Parrot. (issues == we don't > actually require it. =-) That sounds good. T::H3 was built to have no dependencies and to run on lots of platforms for Perl5 core, so it should be ok. > If we only need this for smolder (and not vanilla "make test"), then I > would say don't bundle this, but die nice if it's not installed. And > we'll get them added to Bundle::Parrot. That sounds like a winner for me. It's just for smoke testers, not anyone running normal tests or doing normal dev work. -- Michael Peters Plus Three, LP
[perl #55848] realclean fails to remove ./src/asmfun.s in Parrot v0.6.2
# New Ticket Created by Todd Olson # Please include the string: [perl #55848] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55848 > --- osname= darwin osvers= 8.0 arch= darwin-thread-multi-2level cc= cc --- Flags: category=core severity=low ack=no --- In parrot 0.6.2 make realclean fails to remove the generate ./src/asmfun.s Repeat by perl ./Configure.pl# generates ./src/asmfun.s make realclean # fails to remove ./src/asmfun.s It is not clear how to modify config/gen/makefiles/root.in to fix this. One alternative is to add archclean as a dependency of realclean The documentation in root.in implies that is what intended. This is currently favored at the YAPC:NA Parrot hackathon Another alternative is to find some way to add it to STICKY_FILES It is surprising that asmfun.s is not listed as a dependency of anything .. that it's only reference is as something removed by the command run by archclean Regards, Todd Olson --- Summary of my parrot 0.6.2 (r0) configuration: configdate='Sun Jun 15 16:44:16 2008 GMT' Platform: osname=darwin, archname=darwin-thread-multi-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=perl Compiler: cc='cc', ccflags='-g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -W -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -W! strict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings', Linker and Libraries: ld='c++', ldflags='-L/usr/local/lib -L/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/01/blib/lib', cc_ldflags='', libs='-lm -framework OpenGL -framework GLUT -lcrypto' Dynamic Linking: share_ext='.dylib', ld_share_flags='-dynamiclib -undefined dynamic_lookup', load_ext='.bundle', ld_load_flags='-bundle -undefined dynamic_lookup' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: DYLD_LIBRARY_PATH (unset) HOME =/Users/wparrot01 LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/bin:/sbin:/usr/bin:/usr/sbin SHELL =/bin/bash
[perl #55846] realclean fails to remove ./src/asmfun.s in Parrot v0.6.2
# New Ticket Created by Todd Olson # Please include the string: [perl #55846] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55846 > --- osname= darwin osvers= 8.0 arch= darwin-thread-multi-2level cc= cc --- Flags: category=core severity=low ack=no --- In parrot 0.6.2 make realclean fails to remove the generate ./src/asmfun.s Repeat by perl ./Configure.pl# generates ./src/asmfun.s make realclean # fails to remove ./src/asmfun.s It is not clear how to modify config/gen/makefiles/root.in to fix this. One alternative is to add archclean as a dependency of realclean The documentation in root.in implies that is what intended. This is currently favored at the YAPC:NA Parrot hackathon Another alternative is to find some way to add it to STICKY_FILES It is surprising that asmfun.s is not listed as a dependency of anything ... that it's only reference is as something removed by the command run by archclean Regards, Todd Olson --- Summary of my parrot 0.6.2 (r0) configuration: configdate='Sun Jun 15 16:44:16 2008 GMT' Platform: osname=darwin, archname=darwin-thread-multi-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=perl Compiler: cc='cc', ccflags='-g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -W -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Ws trict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings', Linker and Libraries: ld='c++', ldflags='-L/usr/local/lib -L/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/01/blib/lib', cc_ldflags='', libs='-lm -framework OpenGL -framework GLUT -lcrypto' Dynamic Linking: share_ext='.dylib', ld_share_flags='-dynamiclib -undefined dynamic_lookup', load_ext='.bundle', ld_load_flags='-bundle -undefined dynamic_lookup' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: DYLD_LIBRARY_PATH (unset) HOME =/Users/wparrot01 LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/bin:/sbin:/usr/bin:/usr/sbin SHELL =/bin/bash
[perl #55842] [BUG] empty .const .String broken
# New Ticket Created by François PERRAD # Please include the string: [perl #55842] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55842 > Between r28319 and r28374, the behavior of empty .const .String was broken. Now, the following PIR code produces unexpected character (seen on Windows) : .HLL 'Lua', 'lua_group' .sub main .const .String cst1 = '' print cst1 print "\n" .const .LuaString cst2 = '' print cst2 print "\n" .end François.
[perl #55860] [PATCH] Bool.perl(), Range.perl()
# New Ticket Created by "Olivier Mengué"
# Please include the string: [perl #55860]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55860 >
Here a patch that implements 'perl' methods on Bool and Range objects.
Olivier Mengué (dolmen on CPAN/IRC)
Index: src/classes/Bool.pir
===
--- src/classes/Bool.pir (révision 28379)
+++ src/classes/Bool.pir (copie de travail)
@@ -53,6 +53,20 @@
.end
+=item perl()
+
+Returns a Perl representation of the Bool.
+
+=cut
+
+.sub 'perl' :method
+unless self goto false
+.return ("Bool::True")
+ false:
+.return ("Bool::False")
+.end
+
+
# Local Variables:
# mode: pir
# fill-column: 100
Index: src/classes/Range.pir
===
--- src/classes/Range.pir (révision 28379)
+++ src/classes/Range.pir (copie de travail)
@@ -148,6 +148,35 @@
.return ($I0)
.end
+
+=item perl()
+
+Returns a Perl representation of the Range.
+
+=cut
+
+.sub 'perl' :method
+.local string result, tmp
+.local pmc from, fromexc, toexc, to
+from = getattribute self, '$!from'
+fromexc = getattribute self, '$!from_exclusive'
+toexc = getattribute self, '$!to_exclusive'
+to = getattribute self, '$!to'
+result = from.'perl'()
+unless fromexc goto dots
+result .= '^'
+ dots:
+result .= '..'
+unless toexc goto end
+result .= '^'
+ end:
+tmp = to.'perl'()
+result .= tmp
+.return (result)
+.end
+
+
+
=back
=head2 Operators
Re: Google index and subsets (two topics for the price of one!)
HaloO, Ovid wrote: In other words, I think we could get proper constraint programming if a subset can mutate its variable. Otherwise, all assignment would need to be wrapped inside of an eval and the code would be more bug-prone. I must admit that I hardly follow that statement. Why are side-effects essential to achieve constraint programming and why do you think that the way to get at the constraint programming paradigm are the subset type definitions? E.g. to get constraint programming as I know it from Oz, Perl 6 would need a single assignment store first of all. And then a heavy re-assignment of semantics to things like '$x = $y' which would become a symmetric assertion instead of asymmetric, imperative assignment. Will said mutating work? If it does, all logic handling constraints can be encapsulated in one spot. On the other hand, this could lead to mysterious action at a distance. The losses are significant, but the wins seem absolutely fascinating. Could you give some hints on these fascinating wins, please. I for my part would argue the where blocks to be a very constraint form of block that generally has type :(Object --> Bool) and doesn't alter the object of concern in any way. Note that the where blocks are executed from within the type-checker or the dispatcher where no assumptions of the call environment other then the object should be made. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Google index and subsets (two topics for the price of one!)
HaloO, Daniel Ruoso wrote: In fact, I doubt that there's a way to completely avoid any possible side effects on this closures. as the very first line of the closure shows: $_.inside_of(...) This is a plain method call, there's no way to tell if this method will change anything inside the object or not. Well, we could use something to the effect of const methods in C++. That is we have a trait on a method that prevents changes of the object. And these could be the only ones allowed in where blocks. It's important to remember that, in Perl 6, something is only guaranteed to be fully executed before the next statement when using short-circuit operators, everything else is subject to eventually be made lazy, with the exception of the feed operators, that explicitly say to assume lazy behaviour. So, no C++ sequence points or the like at all in the definition of Perl 6? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: assignable mutators (S06/Lvalue subroutines)
HaloO,
David Green wrote:
I would expect all of those to work the same way in either case. That
is, anywhere the sub is used as an lvalue, it could pass the rvalue as a
special arg, not just when using "=".
I agree. But I want to stress that the big thing is that a lvalue
sub---and to a lesser degree also postcircumfix .[] and .{}---wants
to see its own parameters *and* the rvalue to be assigned.
This data must in general be woven into the control flow of the
sub invocation. That is, when returning a proxy doesn't cut the
whole intension we need something along my yield statement that
joins the functionality of a declarator for a variable to return
as lvalue and capturing the current invocation for later resumption.
OK; but I think that can be handled by a mutating sub -- assuming the
issue is that the proxy-sub "sub foo is rw { blah; $proxy }" runs "blah"
once and returns the proxy that can be assigned to multiple times,
I would prefer to switch back into the sub invocation whenever it is
used in lvalue context. Abandoning control by returning a passive
proxy jumps too short in my eyes.
whereas a mutating sub would run "blah" every time you use it. But:
Hmm, in a statement like
foo(1,2) = 3;
the assignment is the operator that sees both sides involved in the
assignment. And I think it will be the one that other assignment forms
like += and ++ dispatch to unless specifically overridden. My idea is
that foo sees the 1 and 2 as args and prepares itself for rvalue or
lvalue use later in the dispatch. For rvalue use the halted invocation
is garbage collected but in lvalue context the invocation is resumed
by the assignment. This is the point in time when foo "knowns" that
it is in lvalue context and the rvalue 3 is available to the sub as
well. This is a bit like the fork system call where the parent and
child branch into different parts of the code.
sub foo is rw($rval) { unless want~~:($ is rw) { blah };
$unproxy=$rval; }
In other words, the mutating-sub-way can do everything the proxy-way can
(and more), as long as we can tell when being used in lvalue-context.
I think my yield proposal handles all that fine. And it is a more
general concept that is used for coros as well.
Incidentally, now that Perl is all OO-y, do we need tying/proxying like
that, or can we just override the "=" method on a class instead?
It's possible that in perl6, 'STORE' could be spelled 'infix:<=>'; but
then how would 'FETCH' be spelled? And doing so would require that
your storage routine return a value, even if you never intend to use
it. No; I prefer 'STORE' and 'FETCH' as the basic building blocks of
anything that's capable of working like a rw item.
How would the syntax for STORE and FETCH look like in a sub
definition and how would it be related to the invocation involved
in the operation? Note that I make the conceptual unifications
of class and sub definition on the one hand and an object and an
invocation on the other. In the object case the self built-in refers
to the object. Would that work in a STORE or FETCH block of a sub
as well?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
