Camelia, the Perl 6 bug

IRC log for #parrot, 2008-06-04

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 japhb Can a makefile have a dynamic dependency?  'foo.bar: <script that determines foo.bar's real dependencies>'?
00:08 cotto_work why isn't languages/perl6/README called README.pod?
00:08 japhb <snappy comeback>
00:09 AndyA joined #parrot
00:09 japhb Seriously, I don't see why it wouldn't be that way, aside from making sure any links to it are fixed.
00:09 dalek r28054 | Whiteknight++ | gsoc_pdd09:
00:09 dalek : [gsoc_pdd09] adding a fourth GC pointer to an initialization routine.
00:09 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28054
00:12 cotto_work I'll put it on my todo list for after I get my commit bit
00:13 japhb joined #parrot
00:14 japhb damn fat fingers
00:16 japhb OK, does this sound reasonable for the "configure happy place":
00:16 japhb 1. User puts configure overrides in 'configure.prefs'
00:17 japhb 2. Configure converts configure.prefs and autodetected values into 'build.prefs' and 'Makefile'
00:18 japhb 3. At the bottom of the Makefile dependency tree are steps that generate everything Configure.pl currently generates now, using 'build.prefs' as input
00:19 japhb 4. In the Makefile, build.prefs and Makefile depend on configure.prefs and Configure.pl; if they are out of date, they are regenerated and $MAKE is restarted
00:19 japhb ?
00:23 japhb This means that when a user starts from a virgin Parrot tree, they have to optionally edit 'configure.prefs', then do 'perl Configure.pl; make'.  After that, they only ever have to do 'make', even if they edit 'configure.prefs'
00:23 japhb I wave my hands really hard, and everything Just Works.
00:27 japhb IRC_Warnock
00:28 * chromatic once wrote a screenplay with the same ex post facto grant application technique.
00:28 japhb chromatic: nice!  Was it worth it?
00:29 chromatic With the inevitable winces that a decade of experience gives, yes.
00:33 purl joined #parrot
00:33 cotto_work purl
00:33 purl cotto_work?
00:34 bacek joined #parrot
00:34 japhb Anyone know why purl has been disappearing for longish stretches a lot lately?
00:34 chromatic It's 12 years old.
00:34 japhb tweenager
00:35 japhb "I mean it!  I'm really running away this time!  You'll never see me again, and THEN you'll be sorry!"  ... "Write when you get work, kid."
00:37 bacek morning :)
00:48 tetragon Anyone know off-hand if there are any tickets open about t/pmc/exception.t failures?  I haven't found any on RT yet
00:49 kid51 joined #parrot
01:00 Zaba_ joined #parrot
01:17 pmichaud Limbic_Region: (unable to build due to PGE)  -- particle had a similar issue on his Win32 build -- we never could track it down precisely.  But starting from a fresh checkout seems to have fixed the problem (where 'make realclean' didn't).
01:17 pmichaud At any rate, it doesn't appear to be a problem with PGE itself.
01:18 dalek r28055 | jkeenan++ | trunk:
01:18 dalek : Remove references to SVK, as we no longer officially support it.
01:18 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28055
01:18 pmichaud hanging in an infinite loop is a similar issue -- it's due to some changes within parrot, but not PGE itself.  Make sure you have the latest version of trunk and a freshly built Parrot.
01:22 nopaste "tetragon" at 69.196.141.26 pasted "Recently started exception test failures" (234 lines) at http://nopaste.snit.ch/13155
01:27 TiMBuS joined #parrot
01:27 bacek pmichaud: ho! You don't sleep yet!
01:28 bacek What is your decision about http://nopaste.snit.ch/13149 (without changing subs)
01:30 bacek http://nopaste.snit.ch/13151 is changing "multi(_,List) to :multi(Sub) in List.pir
01:39 Zaba joined #parrot
01:58 chromatic tetragon, can you do an svn bisect and see when those tests started to fail?
01:58 chromatic It looks like Parrot's exiting with an exit code of zero.
02:03 kid51_at_dinner purl nopaste
02:03 Zaba joined #parrot
02:03 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating or App::Nopaste or tools/dev/nopaste.pl
02:05 nopaste "kid51" at 71.247.51.42 pasted "New failure in t/examples/tutorial.t (Linux)" (69 lines) at http://nopaste.snit.ch/13156
02:06 tetragon I have the same tutorial.t failure as kid51
02:07 nopaste "kid51" at 71.247.51.42 pasted "failure in t/op/exceptions.t on Darwin (OS X 10.4/ppc) at r28053 -- but not on Linux at same revision" (95 lines) at http://nopaste.snit.ch/13157
02:07 Zaba_ joined #parrot
02:09 bacek kid51: works on MacOSX/intel.
02:09 kid51 My last previous test run on Linux was at r27982 on 20080531.  All tests passed.
02:09 bacek interesting...
02:09 tetragon I'm OS X 10.5/ppc
02:09 kid51 Another of these ppc vs i386 problems, eh?
02:10 tetragon Looks it
02:11 kid51 My last previous test run on 10.4/ppc was at r27808 on 20080525.
02:11 tetragon I'm rebuilding my r28017 tree as a starting point
02:15 kid51 The Linux failure:  probably between r27973 and r28020 (based on -- believe it or not -- our smoke site).
02:24 tetragon tutorial.t passes on r28017, but the exceptions fail
02:25 Zaba joined #parrot
02:29 kid51 On linux, at r28011, I got only TODO errors in t/examples/tutorial.t.  So I didn't get the failure I pasted.
02:36 kid51 on linux, t/examples/tutorial.t also appeared good at r28013.
02:44 chromatic Everything's good for me at r28052, x86 32 bit GNU/Linux.
02:45 tetragon r27997 is bad, I'm currently building r27982
02:45 dalek r28056 | japhb++ | trunk:
02:45 dalek : Move DEVELOPING release info to NEWS
02:45 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28056
02:48 japhb Point of procedure: when I commit an approved patch for an RT ticket, do I mark it resolved, or someone else?
02:48 Whiteknight i think you do it
02:48 Whiteknight at least, that's how i've been playing the game
02:48 chromatic Ahh tutorial's failing for me now too.
02:48 Whiteknight what does tutorial.t test?
02:48 chromatic I wonder if I accidentally checked in a formatting change.
02:48 kid51 But you may want to wait 24 hours before marking it resolved, i.e., give it a chance to go thru smokes.
02:48 chromatic 'examples/tutorial/01_temp_var.pir
02:49 japhb kid51: OK, fair enough
02:49 Whiteknight ok
02:49 chromatic I usually mark it when I do it, so I don't forget, but if you want to wait that's fine too.
02:50 japhb chromatic: Mark it resolved, or mark it in some other way?
02:50 chromatic Anyone replying to the ticket will re-open it, and we can merge new tickets into old ones, so RT's flexible to support either preference.
02:50 chromatic Yes, I meant mark it resolved.
02:50 kid51 On Linux at r28026 t/examples/tutorial.t is okay.  My earlier hypothesis was wrong (it was based on smokes from freebsd).
02:50 Zaba_ joined #parrot
02:50 chromatic kid51's a lot better at remembering to keep his tickets up to date than I am, so I've optimized my process for lazy.
02:51 kid51 kid51 was given search strings by Coke for that!
02:51 japhb chromatic: I might have to follow your lead, not so much to optimize for lazy as for 'constantly interrupted'.
02:52 chromatic Hah, Coke used to have to follow me around to close tickets!
02:52 chromatic He's just happy enough I close them now.
02:53 Whiteknight I only have three open tickets right now, so it doesnt take me a lot of effort to check them
02:54 Whiteknight although one of them is outside my area of expertise, and I can't really do anything about it :(
02:54 chromatic_fajitas We can give you more....
02:55 Zaba joined #parrot
02:56 kid51 Trying to 'make' on Darwin:  /usr/bin/g++ -o pbc_merge   is taking forever!
02:56 tetragon After this realclean, I'll be doing r27990
02:56 tetragon r27982 is good
02:56 Whiteknight mmm...now i'm hungary for chromatic fajitas
02:56 kid51 I'm actually trying 27900.
02:57 * tetragon prefers achromatic fajitas
03:05 kid51 Okay, at long last:  Darwin at r27900, t/op/exception.t was okay (except for TODO test)
03:07 tetragon Why r27900?
03:07 kid51 On Linux, by r 28046, t/examples/tutorial.t had begun to experience the non-TODOed failure reported earlier.  So that should narrow it on Linux to between 28026 and 28046.
03:08 kid51 tetragon:  I went back to my last successful make test on Darwin/ppc.  That was at 27808.  So I went up to the next (! rev % 100).
03:09 tetragon r27982 succeeded
03:09 kid51 So that suggests that the Darwin problem is between 27900 and 27982.
03:09 tetragon I'm doing r27990 now
03:11 tetragon And 27990 is good
03:11 tetragon I'll do r27993 next
03:12 kid51 Why are you going higher than 27982, which you said succeeded?  Shouldn't you be going lower?
03:12 tetragon Oh, right
03:13 tetragon I'm going higher because the even higher rev of r27997 fails
03:13 tetragon Hrm, between r27990 and r27993 src/exceptions.c was changed
03:15 Zaba_ joined #parrot
03:15 kid51 Alright, I'll try a lower one.  Then I must go to bed.
03:18 skv_ joined #parrot
03:24 kid51 My iBook is so slow that between 'make's I've had time to work on one of my CPAN distributions -- and get the test coverage to 100%!
03:25 kid51 Linux:  failure of t/examples/tutorial.t occurred between 28026 and 28042.
03:27 tetragon In a couple more builds, I'll know when t/pmc/exception.t and t/op/exception.t started failing
03:33 kid51 Linux:  failure of t/examples/tutorial.t occurred between 28026 and 28031.
03:33 skv_ joined #parrot
03:34 kid51 Correction:  Linux:  failure was between 28031 and 28042.
03:41 kid51 Darwin:  t/op/exception.t was okay at r27926 (except for previously mentioned TODO tests)
03:42 tetragon OS X/ppc, exception.t: Failure started at either r27992 or r27993
03:43 kid51 Linux:  failure was between 28033 and 28042.
03:43 * kid51 must sleep
03:43 purl $kid51->sleep(8 * 3600);
03:50 chromatic_fajitas Ahh, r28039.  Bernhard updated the tutorial to use say instead of print.
03:51 chromatic_fajitas RT #55196
03:54 dalek r28057 | chromatic++ | trunk:
03:54 dalek : [t] Fixed tutorial test for printing float with say opcode temporarily broken
03:54 dalek : in r28039 (see RT #55196, where print_n and say_n use differing precisions).
03:54 dalek : This is a workaround pending resolution of that ticket.
03:54 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28057
03:54 * tetragon finishes her gelato right when r27992 finished
03:55 tetragon chromatic: The (non-TODO) failures of t/op/exceptions.t and t/pmc/exception.t started with r27992
04:03 chromatic Thanks, tetragon.
04:03 chromatic The exit status parts of that commit are the suspicious ones then.
04:04 chromatic I wonder if it's undefined in certain conditions.
04:05 chromatic Looks like it.  Hmm.
04:06 nopaste "chromatic" at 63.105.17.30 pasted "tetragon: resolve exception test failures [PATCH]" (13 lines) at http://nopaste.snit.ch/13158
04:08 chromatic I think getting rid of uninitialized values would fix it, but confirmation would be lovely.
04:09 tetragon Looks good on r27992, still waiting on r28053 to finish building
04:10 tetragon Good on r28053
04:10 chromatic Excellent, thanks.
04:11 Zaba joined #parrot
04:12 chromatic Did you file a ticket for this that we need to close?
04:12 tetragon Not at this point
04:13 tetragon Too busy watching the builds and keeping enough disk free
04:13 chromatic That's fine, no need now.
04:13 chromatic Thanks for reporting and bisecting.
04:13 dalek r28058 | chromatic++ | trunk:
04:13 dalek : [src] Initialized some variables accidentally rendered uninitialized in r27992
04:13 dalek : (reported by Seneca Cunningham).
04:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28058
04:35 tetragon joined #parrot
04:58 Zaba_ joined #parrot
05:11 Zaba joined #parrot
05:29 grim_fandango joined #parrot
05:32 barney joined #parrot
05:33 cotto_home barney, ping
05:36 cotto_home maybe I need to be louder
05:36 cotto_home PING
05:40 sheriff_p joined #parrot
05:41 sheriff_p Are there any fully-supported real-world languages running on Parrot yet?
05:43 barney hi cotto, was busy reading mail
05:44 cotto_home what'd be the best starting place to integrate my phparray code with the rest of plumhead?
05:44 cotto_home (which, of course, I can't release yet)
05:47 Tene sheriff_p: not yet.  parrot itself still has a few pieces that need to be completed.
05:47 barney I could make a dummy PHPArray, and you keep a diverging working copy. This is to avoid MANIFEST problems.
05:47 sheriff_p hrm
05:47 Tene sheriff_p: what languages are you most interested in?
05:48 barney cotto: Need to head out for $DAYJOB
05:48 cotto_home barney, I'm thinking more from a coding perspective than "how do I avoid pain when I eventually get my commit bit"
05:48 cotto_home ok
05:48 cotto_home ttyl
05:51 Tene sheriff_p: why are you asking?
05:52 barney cotto: put PMC code into src/pmc, adapt config/makefiles/root.in and create many tests should be fine
05:52 sheriff_p Tene: I have a suspicion that people will start getting excited when it becomes easy to swap libraries between languages
05:53 cotto_home that's definitely what I'm most looking forward to about Parrot
05:53 sheriff_p hrm
05:53 Tene sheriff_p: there are still some namespace issues that need to be worked out before languages can start doing things like that.
05:53 sheriff_p That's a shame
05:54 Tene nothing significant, it's just that nobody has gotten around to it yet.
05:56 sheriff_p I wonder how hard it would be to convert Perl bytecode in to working JS
05:57 Theory joined #parrot
06:11 Zaba joined #parrot
06:17 * bacek going to make few people sick :)
06:18 bacek (just read yesterday's #ps log)
06:18 moritz bacek: ;)
06:18 Tene what about it?
06:19 moritz Tene: http://irclog.perlgeek.de/par​rotsketch/2008-06-03#i_327710
06:22 ank joined #parrot
06:23 uniejo joined #parrot
06:27 Zaba joined #parrot
06:33 bacek any idea which version of pugs known to build on mac/intel?
06:34 moritz bacek: the last version I managed to build at all was r19915 on ghc 6.6.1
06:34 bacek moritz: thanks. I'll try to build it...
06:36 bacek doesn't work with 6.8.2...
06:36 moritz bacek: yes, 6.8.* has a different packaging system, less packages are imported by default
06:37 bacek heh... Pugs is not dead. It just smells like dead...
06:42 Zaba_ joined #parrot
06:46 bacek Module `Data.ByteString.Char8' does not export `copyCStringLen'
06:46 bacek this is from HsSyck..
06:46 moritz bacek: warning or error?
06:46 bacek errro
06:46 bacek error
07:04 Tene http://canonical.org/~kragen/strlen-utf8.html
07:06 ank Tene: very interesting
07:08 Tene http://porg.es/blog/counting-char​acters-in-utf-8-strings-is-faster
07:08 shorten Tene's url is at http://xrl.us/bmhdz
07:10 iblechbot joined #parrot
07:11 moritz Tene: nice reading
07:18 Zaba joined #parrot
07:22 Zaba_ joined #parrot
07:26 Zaba joined #parrot
07:42 Zaba joined #parrot
07:47 Zaba_ joined #parrot
07:54 Zaba joined #parrot
08:03 allison joined #parrot
08:28 tetragon joined #parrot
09:01 dalek allison@perl.org | Bylaws:
09:01 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:03 dalek allison@perl.org | Bylaws:
09:03 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:04 dalek allison@perl.org | Bylaws:
09:04 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:08 dalek allison@perl.org | Bylaws:
09:08 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:32 dalek allison@perl.org | Bylaws:
09:32 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:36 dalek allison@perl.org | Bylaws:
09:36 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:47 dalek allison@perl.org | Bylaws:
09:47 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
09:59 ruoso joined #parrot
10:06 dalek allison@perl.org | Bylaws:
10:06 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
10:10 dalek allison@perl.org | Bylaws:
10:10 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
10:38 dalek allison@perl.org | Bylaws:
10:38 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
10:40 dalek allison@perl.org | Bylaws:
10:40 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
10:44 dalek allison@perl.org | A foundation for Parrot:
10:44 dalek link: http://www.perlfoundation.org/parro​t/index.cgi?a_foundation_for_parrot
10:44 shorten dalek's url is at http://xrl.us/bkxq5
11:27 dalek allison@perl.org | Membership Committee Charter:
11:27 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?membership_committee_charter
11:27 shorten dalek's url is at http://xrl.us/bmhjt
11:32 dalek allison@perl.org | Bylaws:
11:32 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
11:32 silug joined #parrot
11:34 braceta joined #parrot
11:40 ank joined #parrot
11:44 dalek allison@perl.org | Conflict of Interest Policy:
11:44 dalek link: http://www.perlfoundation.org/parrot/​index.cgi?conflict_of_interest_policy
11:44 shorten dalek's url is at http://xrl.us/bmhj7
11:48 bacek joined #parrot
11:48 bacek hi again.
11:48 purl oh, you're back!
11:48 bacek purl, you still there!
11:48 purl bacek: sorry...
11:51 dalek allison@perl.org | Conflict of Interest Policy:
11:51 dalek link: http://www.perlfoundation.org/parrot/​index.cgi?conflict_of_interest_policy
11:51 shorten dalek's url is at http://xrl.us/bmhj7
11:54 dalek allison@perl.org | Conflict of Interest Policy:
11:54 dalek link: http://www.perlfoundation.org/parrot/​index.cgi?conflict_of_interest_policy
11:54 shorten dalek's url is at http://xrl.us/bmhj7
11:56 dalek allison@perl.org | Conflict of Interest Policy:
11:56 dalek link: http://www.perlfoundation.org/parrot/​index.cgi?conflict_of_interest_policy
11:56 shorten dalek's url is at http://xrl.us/bmhj7
11:57 dalek allison@perl.org | Bylaws:
11:57 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
12:00 bacek summon pmichaud
12:02 bacek #perl6?
12:02 purl #perl6 is at irc.freenode.net.
12:02 dalek allison@perl.org | Bylaws:
12:02 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
12:07 Theory joined #parrot
12:07 bacek joined #parrot
12:09 dalek allison@perl.org | Bylaws:
12:09 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
12:14 bacek pmichaud, http://nopaste.snit.ch/13152 makes S29-list/grep.t passing
12:23 kid51 joined #parrot
12:26 pjcj joined #parrot
12:27 kid51 Hurray!  We're back to all tests passing 'make test' on Darwin and Linux.  chromatic and tetragon must have been able to complete the binary search last night.
13:05 Themeruta joined #parrot
13:06 gryphon joined #parrot
13:25 jhorwitz joined #parrot
13:29 Whiteknight joined #parrot
13:31 particle sheriff_p, Tene: parrot's lua implementation is "real world" and "complete"
13:32 particle ...for reasonable definitions of those words
13:32 iblechbot joined #parrot
13:33 kj joined #parrot
13:33 particle bacek: could you send your patches as tickets rather than nopasting always? higher visibility of your work is more likely to lead to a commit bit sooner
13:34 particle bacek: you can copy parrot-porters@ so the list gets the mail immediately, even if it takes rt a while to catch up
13:35 moritz is parrot-porters the same as perl6-internals?
13:36 Zaba joined #parrot
13:37 dalek r28059 | Whiteknight++ | gsoc_pdd09:
13:37 dalek : [gsoc_pdd09] updating to trunk r28058
13:37 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28059
13:38 particle moritz: yes
13:38 particle it's the new name, although it seems impossible to get rid of the old name
13:38 particle ..."new" being about two years old
13:39 bacek pmichaud, ok.
13:39 kj hello everybody
13:39 purl Hello Dr. Nick!
13:40 kj for the interested readers: I converted the pct tutorial to POD; it's in lang/squaak/doc. The solutions will come later, prob. next week or so.
13:43 particle kj++
13:44 kj particle: I guess you don't need it anymore, but any feedback is welcome :-)
13:45 particle well, since i haven't read it yet, i may have some nice feedback when i do :)
13:46 kj yep, that's what I was hoping for ;-) General tips on writing or how to make things clear would help in my future documentation efforts
13:47 kj which I envision :-P
13:58 particle log?
13:58 purl o/` it rolls downstairs, alone or in pairs, rolls over your neighbour's dog, it fits on your back, it's good for a snack, it's log, log log! o/`
13:58 particle it's log, it's log, it's big, it's heavy, it's wood
13:58 Whiteknight it's log, it's log, it's better then bad, it's good!
13:59 particle :)
13:59 moritz it's log, it's log, it's only in four characters different than "beer"
14:00 Whiteknight i grew up on ren & stimpy
14:01 Whiteknight ...which explains some of my more glaring personality deficiencies
14:01 * particle <3 ren&stimpy
14:06 jonathan Yesterday kalashnikovs, today logs. I really must pick my times to glance at #parrot...
14:06 * jonathan will do Rakudo day tomorrow.
14:07 jhorwitz Whiteknight: you EEEEEEEEEDIOT!  :)
14:08 Infinoid Don't touch it, you fool!  It's the history eraser button!
14:11 Whiteknight haha! classic references!
14:11 ruoso joined #parrot
14:14 pmichaud bacek:  (nopaste 13152)  -- we really don't need to make separate calls to 'list'()
14:15 moritz jonathan: are there any tests that I could prepare for your rakudo day tomorrow?
14:16 jonathan moritz: I was going to write some tests myself, for: (more)
14:16 jonathan * subset foo of bar where { baz }
14:16 jonathan * grammar { ... }, with rule/regex/token inside
14:17 bacek pmichaud, I'm little bit paranoid with new tools/languages...
14:17 jonathan * Matching against a grammar / rule / regex / token with ~~
14:17 PowderedToastMan hey kids!
14:17 jonathan If you're interested in working on any of those, then I'll probably dig straight into working on roles with attributes. :-)
14:18 jonathan But I think we have no tests for those things yet.
14:18 jonathan Also, some junctional stuff.
14:19 moritz jonathan: I'll take a look at those, and probably /msg you when I get some of it done
14:19 pmichaud jonathan: note that the  ~~ Grammar   invocation is likely going to change
14:20 moritz I'd expect $variable ~~ MyGrammar to do a type check
14:20 moritz just like with classes
14:20 pmichaud yes, that's what TimToady was speculating a couple of days ago
14:20 particle ayep
14:20 particle with a method call to run it
14:20 pmichaud to match against a grammar may become    $x ~~ MyGrammar.new()
14:20 acmoore joined #parrot
14:21 moritz will $x ~~ MyGrammar.TOP still work?
14:22 pmichaud I can't say for sure on that one yet.
14:22 particle will $x ~~ MyGrammar.TOP check that $x isa regex/rule/token?
14:23 pmichaud for that one would use   $x ~~ Regex
14:23 particle how do i get the type of MyGrammar.TOP?
14:23 pmichaud &MyGrammar::TOP.WHAT  ?
14:23 particle ok
14:24 particle are parens (for invoke) implied in perl 6?
14:24 pmichaud not for &var
14:24 particle foo.bar same as foo.bar()
14:24 pmichaud if bar is a method, yes.
14:24 particle and TOP is a method on MyGrammar
14:24 particle regex/rule/token == method
14:25 particle so, that seems to suggest $x ~~ MyGrammar.TOP will execute TOP
14:25 pmichaud ...and smartmatch $x against whatever  MyGrammar.TOP returns
14:25 jonathan pmichaud: Sure, but best to have *something* tested so we can make sure the functionality still works, even if the details will change.
14:25 particle yes
14:25 moritz so how would you smartmatch against MyGrammar.TOP? $x ~~ &MyGrammar.TOP ?
14:26 pmichaud jonathan: sure.  But the big point about $x ~~ Grammar changing is that we no longer need the .ACCEPTS special stuff.
14:26 jonathan Yes, that will be much cleaner, for sure.
14:27 jonathan $x ~~ MyGrammar.TOP - will be Regex case in smartmatch
14:27 jonathan Regex is method-like, maybe even a subclass of Method.
14:28 moritz 'subset' seems to lack quite some testing
14:28 pmichaud MyGrammar.TOP  _should_ invoke TOP
14:28 jonathan Hmm.
14:28 jonathan True.
14:28 jonathan $x ~~ MyGrammar::TOP would do the Regex match.
14:29 jonathan MyGrammar.TOP - as particle said.
14:29 pmichaud no.
14:29 jonathan Oh?
14:29 pmichaud MyGrammar.TOP _should_ invoke TOP.
14:29 jonathan Yes, invokes TOP
14:29 jonathan But without any arguments?
14:29 jonathan It's just a method call?
14:29 pmichaud $x ~~ MyGrammar.TOP would then do a smartmatch between $x and whatever MyGrammar.TOP returns
14:30 pmichaud same as if I did   $x ~~ $y.bar
14:30 pmichaud $x ~~ $y.bar  does not mean   $y.bar($x)
14:30 jonathan Right, I thought that's what particle had meant.
14:30 pmichaud MyGrammar::TOP would be something different.  In fact, it probably doesn't exist.
14:31 jonathan TOP doesn't exist in the MyGrammar namespace?
14:31 pmichaud if it does, it's a namespace.
14:31 pmichaud The TOP method would be MyGrammar::&TOP
14:31 jonathan Ah.
14:31 jonathan OK, got it.
14:32 * jonathan trundles back to $DAYJOB
14:32 pmichaud TimToady says that TOP  invocation in STD5 is currently:    MyGrammar.new($x).TOP()
14:41 moritz we really need eval_lives_ok and eval_dies_ok
14:41 pmichaud for?
14:42 moritz for testing all kinds of stuff, for example subsets
14:42 pmichaud (not disagreeing, just curious)
14:42 moritz subset Even of Int where { $_ % 2 == 0 };
14:42 pmichaud why does that require eval?
14:42 moritz lives_ok { my Even $x = 3 }, "desc",
14:42 moritz won't work
14:42 moritz because a compiler is allowed to such checks at compile time
14:42 moritz where possible
14:42 purl NOT!
14:43 moritz pmichaud: I found some instances where undeclared variables where used in a try { ... } block, and rakudo bailed at those (rightfully)
14:44 pmichaud eval_lives_ok and eval_dies_ok    -- I agree.
14:45 moritz and there are quite many test like eval 'string'; ok !$!, "compiled"; that could also use these
14:45 pmichaud are these latter tests actually testing eval?
14:45 pmichaud if we're just testing that something parses/compiles, we should use #?impl skip for that
14:46 pmichaud or one of the other fudge directives
14:47 bacek eval_dies_ok can be used for testing parsing failures.
14:47 pmichaud yes, it can be used for that (more)
14:47 pmichaud (nm more)
14:48 moritz bacek: and for failures that can either happen at runtime or compile time
14:48 pmichaud anyway, I agree that we should keep eval_lives_ok and eval_dies_ok
14:48 bacek moritz, +1
14:48 moritz bacek: if you have free tuits, would you like to implement these in Test.pm?
14:48 pmichaud aren't they already there?
14:48 pmichaud or is it just lives_ok and dies_ok ?
14:48 moritz no 'eval' at all in Test.pm
14:49 pmichaud okay, add them.  :-)
14:49 bacek pmichaud, no. But they can be easily implemented
14:50 pmichaud bacek:  do you want me to fix nopaste 13152 and apply it?
14:51 pmichaud actually, I'll clean up exports first.
14:51 nopaste "bacek" at 202.7.166.166 pasted "scetch of eval_dies/lives_ok in Test.pm" (29 lines) at http://nopaste.snit.ch/13162
14:52 pmichaud probably need try { ... }   around those evals
14:52 bacek pmichaud, Already done. I just fixing other... hmm... glitches in List.pir
14:52 moritz do failed evals throw exceptions? don't think so, actually
14:53 bacek $ ../../parrot perl6.pbc
14:53 bacek > use Test;
14:53 bacek > eval_dies_ok('die!');
14:53 bacek Segmentation fault
14:53 purl (Core dumped)
14:53 bacek Yeek...
14:54 pmichaud eval might not throw an exception -- I suppose if the code doesn't eval then it would return one.
14:54 pmichaud in which case we probably need to update rakudo's eval()
14:54 pmichaud however
14:55 moritz inside there could be an exception
14:55 bacek pmichaud, (about List.pir) do you want it in RT?
14:55 pmichaud S04 says "The Perl 6 equivalent to Perl 5's eval {...} is try {...}."   which might lead one to believe that eval doesn't trap exceptions anymore.
14:56 pmichaud (but it could also be that S04 is simply referring to P5's block form of eval.)
14:56 moritz eval { ...} *is* the block form of eval
14:57 pmichaud S04 says there is no eval { ... } in p6
14:57 pmichaud S04"  The Perl 6 equivalent to Perl 5's eval {...} is try {...}. (Perl 6's eval function only evaluates strings, not blocks.)
14:57 moritz that's what I meant ;)
14:58 pmichaud bacek:  just a sec, thinking
14:58 pmichaud bacek:  either nopaste or RT is fine for this.  I'll probably go ahead and apply it now, and then do my export refactoring a bit later
15:00 nopaste "bacek" at 202.7.166.166 pasted "List.pir cleanup for pmichaud" (101 lines) at http://nopaste.snit.ch/13163
15:01 pmichaud for sort, shouldn't 'list' be :slurpy ?
15:01 bacek pmichaud, I also have 'reduce' refactored.
15:01 pmichaud same for map
15:01 bacek pmichaud, why?
15:02 pmichaud otherwise we can't do     sort 1,2,3,4,5
15:02 bacek <pmichaud> bacek:  (nopaste 13152)  -- we really don't need to make separate calls to 'list'()
15:02 pmichaud right
15:02 pmichaud we do '!flatten' on the slurpy arg instead
15:02 pmichaud .param pmc array   :slurpy
15:02 pmichaud array.'!flatten'()
15:03 pmichaud .return array.'whatever'()
15:03 pmichaud (unless the 'whatever' method already does flattening, in which case we don't need the extra '!flatten' step.
15:05 bacek ok. Just a sec.
15:07 bacek hmm... What the difference with my original version? 'list' is actually 'alias' for '!flatten'...
15:07 pmichaud not really
15:07 pmichaud 'list' always constructs a List()
15:08 pmichaud sorry, you're right, that's not what it does
15:08 pmichaud however, it does create an *extra* list.
15:08 particle bbi15m &
15:09 pmichaud using '!flatten' directly avoids the extra list creation.
15:10 * bacek throws Knuth's book to pmichaud - PREMATURE OPTIMIZATION!
15:10 pmichaud I'm willing to accept the argument that this would be a prematu..... right
15:10 pmichaud :-)
15:10 pmichaud okay, I'll apply it.
15:10 pmichaud well, I'll apply 13152
15:10 bacek :)
15:12 bacek BTW... Always flattening is bad idea... We really need lazy lists...
15:12 pmichaud ...except that  sort() does flatten.
15:12 bacek except sort()
15:12 pmichaud and map.
15:12 pmichaud and grep.
15:13 pmichaud and anything that has   *@array    as an argument.
15:13 bacek (grep { $_ % 3 }, 1..Inf)[20]
15:13 bacek flattening is not actually required.
15:14 pmichaud oka, flatten is the wrong name then.
15:14 pmichaud I don't mean flatten in the sense of "eager", I mean it in the sense of "remove dimensions"
15:15 bacek pmichaud, o! '!flatten' is little bit misleading...
15:15 pmichaud it's okay, as you say, it'll go away with lazy lists.
15:15 moritz jonathan: I added two test files for subsets in S02-polymorphic_types/. They seem to pass once we implement eval_lives_ok
15:15 pmichaud or at least it'll become less eager
15:17 bacek moritz, eval trowing exception in rakudo.
15:18 bacek pmichaud, indeed
15:18 jonathan moritz: Nice.
15:19 moritz jonathan: they are very basic, but atm I don't really know what else I can test... a job for Auzon when he gets to it ;)
15:19 nopaste "bacek" at 202.7.166.166 pasted "woring version of eval_dies/lives_ok in Test.pm" (31 lines) at http://nopaste.snit.ch/13164
15:20 bacek use Test; plan 1; eval_dies_ok('die');
15:20 bacek it works :)
15:21 pmichaud I'd be interested to know if eval throws exceptions on parsefails, though.
15:22 jonathan moritz: Basic tests beat no tests. :-)
15:22 bacek pmichaud, it throws
15:23 pmichaud bacek: no, I mean in the spec, not in rakudo.
15:23 pmichaud i.e, "should eval throw an exception on parsefail?"
15:24 bacek pmichaud, hmm...
15:24 bacek pmichaud, my vote for 'shouldnt'
15:24 * moritz too
15:24 pmichaud so, one would have to explicitly check $! after eval?
15:24 jonathan Why shouldn't it? If you've got a parse fail in what you tried to eval, you'd like to know about it?
15:25 moritz pmichaud: or 'use fatal 'eval''
15:25 pmichaud moritz: that's reasonable.
15:25 jonathan I'd go with it following what use fatal does.
15:25 pmichaud anyway, is eval() documented in S29?
15:25 moritz the whole philosophy is not to die unless fatal is in scope
15:25 moritz rather 'fail' instead
15:26 moritz which does the right thing
15:27 pmichaud works for me.
15:27 pmichaud so we need to fix rakudo's 'eval'
15:27 bacek pmichaud, yes.
15:27 bacek moritz, S02-polymorphic passed with this Test.pm :)
15:28 moritz bacek++
15:28 pmichaud either fix eval or file a ticket for it, please.
15:37 bacek pmichaud, src/builtins/control.pir.
15:38 bacek I think we should fix rakudo, not parrot in this case.
15:38 pmichaud bacek: I don't understand.
15:38 * bacek is little bit dumb...
15:38 bacek pmichaud, sorry. I just misread
15:39 bacek ...you proposal to fix.
15:39 bacek Just a sec. I'll fix eval.
15:39 pmichaud we probably ought to have a 'fail' function, too :-)
15:43 bacek pmichaud, it's too many failures without this function... Why we need it? :)
15:44 moritz bacek: because it's specced? ;-)
15:49 NotFound You can implement it just by calling other function that fails X-)
15:54 * bacek still try to understand how set value in '$!'...
15:56 jonathan bacek: I fear that is looking down the callstack, since $! is a context variable.
15:59 Zaba_ joined #parrot
16:00 bacek jonathan, and how it should look like?
16:08 bacek look like time to summon chromatic
16:09 jonathan bacek: You can get at it through the interpinfo opcode, I believe.
16:34 ambs joined #parrot
16:42 bacek bacek@icebolt:~/src/parrot/languages/perl6$ cat e.pl
16:42 bacek eval('die'); print defined $!; eval('1==1'); say defined $!;
16:42 bacek bacek@icebolt:~/src/parrot/languages/perl6$ ../../parrot perl6.pbc e.pl
16:42 bacek 10
16:42 bacek Bingo!
16:44 nopaste "bacek" at 202.7.166.166 pasted "Fixed eval() for pmichaud/jonathan to review" (26 lines) at http://nopaste.snit.ch/13165
16:45 nopaste "bacek" at 202.7.166.166 pasted "Fixed eval() for pmichaud/jonathan to review (again... full version)" (35 lines) at http://nopaste.snit.ch/13166
16:46 particle bacek: include documentation about setting $! and i think it's good to apply
16:46 cognominal jonathan, junctions have a .perl method but no .get_string.
16:50 bacek particle,  # We fetch callers lexpad and set '$!' in it.
16:50 bacek is it enough?
16:50 particle i mean pod doc
16:51 bacek particle, but pod doc is already there...
16:51 particle Returns whatever C<$code> returns, or undef on error. Sets caller's C<$!> on error.
16:51 particle something like that
16:51 bacek particle, ok.
16:51 particle i can apply and add that, if you think it's accurate enough
16:52 jonathan cognominal: I don't know what get_string on a junction should do. Not the same as .perl, that I'm pretty sure of.
16:52 jonathan Stringifying each element and returning a junction of the strings would seem sane.
16:52 particle also, i'm moving the .local away from the .param and closer to where they're used
16:52 cognominal I did not thought that far :)
16:53 nopaste "bacek" at 202.7.166.166 pasted "new version of eval()" (45 lines) at http://nopaste.snit.ch/13167
16:53 jonathan cognominal: Actually, what I just said won't work.
16:54 bacek particle, I just copied your text :)
16:54 jonathan Because you have to return a STRING* and not a PMC*.
16:54 jonathan but prefix:~ on a junction should return a junction of strings, I'm pretty sure about that.
16:54 moritz I think it should be the same as .perl,  but call .str on the asssembled objects, not .perl
16:54 moritz (just intuitive guessing here)
16:55 jonathan .perl of a junction returns a string rather than a junction; stringifying a junction I don't think changes it's junction-ness. Since serializing and stringification are different.
16:55 moritz but shouldn't ~$foo return a string, regardless of $foo is?
16:56 particle bacek: applied, testing now
16:56 bacek particle, ok, thanks.
16:56 bacek must sleep
16:56 purl $bacek->sleep(8 * 3600);
16:56 bacek it's 3 AM here. Good night everyone.
16:57 bacek thanks purl
16:57 moritz sleep well bacek ;)
16:57 bacek moritz, I will. Last 4 hours before waking kids...
16:57 japhb moritz: (~$foo returns string always) No, because ($a + $b) doesn't always return a number, if $a or $b are junctions.
16:57 cognominal I guess as moritz about ~ on junctions
16:58 japhb applying basic opts to junctions produces junctions of applied ops
16:58 moritz japhb: you've got a point there. But how do I *really* produce a string then?
16:59 cognominal .perl does it
16:59 NotFound japhb: please take a look at #49966
16:59 moritz cognominal: but that doesn't do what I want ;)
16:59 japhb NotFound: looking
17:01 japhb OK, give me a minutes to make realclean and compile a fresh parrot, and I will test again here.
17:02 jonathan moritz: $junc.values will get you the values in a junction as a list, which may stringify how you want.
17:02 japhb moritz: What do you really want, if .perl's string output isn't it?
17:02 jonathan say $junc will, eventually, autho-thread.
17:02 jonathan *auto-thread
17:02 jonathan That is, call say for each value in the junction
17:04 moritz japhb: .perl calls .perl on all assembled objects in the list. Which is arbitrary, as long as it reproduces these objects. I'd expect prefix:~ to return something that assembles the stringification of all these objcts
17:04 dalek r28060 | particle++ | trunk:
17:04 dalek : [rakudo] eval: propagate $! to caller (bacek++)
17:04 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28060
17:04 japhb Anyone know if in PIR, the :opt_flag .param must immediately follow the matching :optional .param?  Can there be intervening other .params?  In particular, can you group all of the :optional's together, followed by all of the :opt_flags in the same order?
17:04 moritz japhb: but I think I actually want ~$junc.values, jonathan++
17:04 japhb moritz: fair enough
17:05 particle japhb: i believe they must be :optional :optflag :optional :optflag order
17:05 japhb particle: ok, thanks
17:05 jonathan moritz: Or perhaps (~$junc).values, if you wanted an array of strings...depends what you're after. :-)
17:05 NotFound japhb: given all current bugs in passing arguments, trying that can be a nightmare.
17:05 pmichaud prefix:~   on a junction should return a junction
17:05 pmichaud in this respect it's no different than doing   prefix:-  on a junction
17:06 japhb NotFound: yeah, I thought about testing it to get the answer from the horse's mouth, then realized I would be getting the answer from the donkey's mouth instead.
17:06 pmichaud -(2|3)   "  (-2 | -3)"
17:06 pmichaud ~(2|3)   ==>   "2" | "3"
17:07 pmichaud however, prefix:~ should never actually "see" a Junction -- the dispatcher should autothread the calls to prefix:~
17:08 NotFound japhb: I think it can be a Monte Carlo answer, mostly,
17:09 NotFound (and I don't talk about Alonso-Hamilton things) X-)
17:10 * japhb goes to look up Alonso-Hamilton, can't find anything but Mercedes-Benz racing references
17:11 NotFound That's it.
17:11 particle they race in monte carlo
17:12 cognominal non sequiturs manage to always converge in Perl
17:13 cognominal with the appropriate metric
17:14 NotFound for_each a,b -> distance(a,b)=0 ?
17:32 japhb NotFound: wow, if I'd been more awake ... I still probably wouldn't have figured out that joke.  ;-)
17:36 japhb NotFound: #49966 looks fixed, so I marked it resolved, thanks for pointing that out.
17:57 cognominal japhb: what do you want as include files? I am opengl and glut illiterate
17:58 dalek r28061 | pmichaud++ | trunk:
17:58 dalek : [rakudo]:
17:58 dalek : * Refactor handling of exported methods into !EXPORT sub.
17:58 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28061
17:59 dalek r28062 | kjs++ | trunk:
17:59 dalek : [tutorial] add solutions to episode 3.
17:59 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28062
17:59 nopaste "cognominal" at 82.67.232.89 pasted "glxinfo for japhb" (69 lines) at http://nopaste.snit.ch/13168
18:00 particle pmichaud:  will you be layering 'is export' on '!EXPORT'?
18:00 cjfields joined #parrot
18:00 japhb cognominal: The full contents of any directory containing a header file named 'gl.h', 'glu.h', or 'glut.h'
18:00 cognominal ok
18:01 particle pmichaud: also, if you have some pointers as to what Exporter needs or should act, let me know (test cases give you bonus points)
18:01 cognominal japhb, I thought the problem was that I added a opengl port but removing it did not change anything
18:02 japhb I believe the problem is an extra header file with macros formatted in a weird way I'm not handling.
18:03 * japhb examines cognominal's glxinfo ...
18:03 japhb OpenGL 1.2?  Seriously, Intel!?  Sheesh.
18:03 cognominal this seems to comme with X11
18:03 japhb No wonder NVIDIA is constantly giving Intel a hard time about being graphics-incompetent.
18:03 cognominal that may not be what you sarch
18:04 cognominal this is not the native window system on a mac
18:04 japhb Is there a cglinfo?
18:04 japhb (Or aglinfo, for that matter?)
18:05 nopaste "cognominal" at 82.67.232.89 pasted "for japhb" (12 lines) at http://nopaste.snit.ch/13169
18:05 japhb cognominal: yes, perfect.  The full contents of all of those directories, plus the glut.h-containing ones you posted the first time.
18:06 japhb tar that whole puppy up.  :-)
18:06 cognominal ok
18:06 japhb thank you!
18:06 cognominal you are welcome
18:08 dalek r28063 | pmichaud++ | trunk:
18:08 dalek : [rakudo]:
18:08 pmichaud particle:  (is export)  haven't decided yet.
18:08 dalek : * Add more improvements to List (bacek++)
18:08 dalek : * Two additional subtests in t/spec/S29-list/grep.t now pass.
18:08 dalek : * Patch courtesy Vasily Chekalkin <bacek@bacek.com>
18:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28063
18:09 pmichaud I was simply tired of writing stub code to put methods into the global namespace, so figured an export of some sort would work well.
18:10 sjansen joined #parrot
18:10 pmichaud I see !EXPORT as an interim measure until we decide how we want to handle it in general.
18:11 particle if we decorate methods with 'is export', can we use '!EXPORT' for trait_auxiliary:is ?
18:12 pmichaud not yet.  eventually we'll do something like taht.
18:12 particle what stops us? can't get the name of the method?
18:12 pmichaud only that I'm not sure this is the design I want.
18:12 dalek r28064 | kjs++ | trunk:
18:12 dalek : [tutorial] add solutions to ep.4
18:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28064
18:12 particle hrmm
18:13 particle it is the proper perl 6 syntax, though, isn't it?
18:13 pmichaud if someone wants to implement 'is export' using !EXPORT that's okay, keeping in mind that I may change my mind
18:13 pmichaud I'm only saying that !EXPORT itself might be wrong.
18:13 particle ok, sure
18:14 particle i just want to be able to specify on the routine that it should be exported, rather than hardcoding it in :onload
18:14 pmichaud where 'routine' means "Perl 6 routine"?
18:14 particle yes.
18:14 pmichaud or are you advocating an :export flag on Parrot subs?
18:14 particle no
18:15 particle method foo is export (...) { ... }
18:15 pmichaud right.  but the code to do that is going to end up in an :load :init sub
18:16 japhb grrr ... what's the correct PIR to do a COW assign of string registers? '$S0 = $S1' doesn't seem to do it, unless I have a bug elsewhere
18:16 pmichaud japhb:  $S0 = clone $S1
18:16 japhb pmichaud: thanks.
18:16 japhb That's really COW, not a copy?
18:17 pmichaud so I'm told.
18:17 japhb ok
18:18 Ivatar joined #parrot
18:20 japhb pmichaud: I believe you said a couple days ago what the 'friendliest' way to obtain an iterator from an aggregate was ... was it the 'iter' op?
18:20 pmichaud yes.
18:20 japhb pmichaud: cool, thanks
18:20 particle vtable++
18:20 jhorwitz there's an iter op?  learn something new every day....
18:21 japhb It's listed in the docs as experimental, so I wasn't sure.
18:21 pmichaud it's in experimental ops, but apparently is likely to stay.
18:21 particle it calls the get_iter vtable function
18:22 jhorwitz makes life easier.  that's all i care about.  :)
18:22 * particle hands jhorwitz a beer
18:22 japhb Well, that didn't work -- "get_iter() not implemented in class 'ResizeableStringArray"
18:22 * jhorwitz needs a write_slides_for_talk opcode
18:22 * jhorwitz chugs particle's beer
18:23 pmichaud japhb:  file a ticket, and use    new 'Iterator'   :-)
18:24 japhb pmichaud: I will file a ticket, but I was trying to get rid of "new 'Iterator'" ... ah well, just have to revert a couple "improvements"
18:24 pmichaud japhb: right -- apparently we're not quite ready for "iter everywhere" yet.
18:25 pmichaud unfortunately I tended to use 'iter' as the symbol for my Iterator PMCs, so that's a lot of code to change
18:25 pmichaud (because I was also unaware of the iter opcode)
18:27 barney joined #parrot
18:28 japhb ticket submitted
18:28 * jhorwitz does the same thing with iter
18:29 * japhb was in the habit of naming an iterator for 'foo' as 'foo_iter', so 'foo_iter = iter foo' looked nice
18:30 * particle uses it_foo
18:30 pmichaud it_foo might be okay.
18:31 japhb That begins to border on hungarian notation, which gives me the heebie-jeebies
18:40 Zaba joined #parrot
18:42 dalek r28065 | japhb++ | trunk:
18:42 dalek : [OpenGL] Friendlier function export API
18:42 dalek : * Make the namespace parameter to _export_all_functions_to optional
18:42 dalek : * Accordingly, change name to _export_all_functions
18:42 dalek : * Rename glutcb* to glut* on export, so importing module sees standard names
18:42 dalek : * Fix POD and example to match
18:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28065
18:51 AndyA joined #parrot
19:03 ccube joined #parrot
19:04 ccube I was going to use parrotbug to report a "make test" failure on Parrot_Test and found that parrotbug is non-functional
19:04 Ademan joined #parrot
19:05 ccube It doesn't even respond to a ./parrotbug -h
19:05 ccube Looking at the code for it, it tries to do stuff in the "init" sub that shouldn't come until later
19:06 ccube the "main" part of parrotbug: init(); help();      # bug init() seems not to return
19:07 ccube I think this is a case where you guys are clearly not eating your own dogfood.
19:08 ccube I will note that docs/submissons.pod points you to using this non-functional tool
19:09 NotFound Off with his head!
19:09 pmichaud ccube: current bug report is http://rt.perl.org/rt3/Tic​ket/Display.html?id=41601
19:09 cognominal jonathan, in fpw2008, I think you spoke about a java extension that was cool,  was that groovy?
19:09 jonathan Yes, but I only said I'd been told it was cool, I haven't tried it yet. :-)
19:09 ccube pmichaud: SO update docs/submission.pod why don't you?
19:09 ccube pmichaud: and FIX or REMOVE parrotbug
19:10 pmichaud ccube: I don't know how to fix parrotbug.
19:10 cognominal that's the story of the man that has seen the man that has seen the man that has seen the bear...
19:10 pmichaud ccube: it's not my call whether or not to remove it.
19:10 ccube pmichaud: hmm - then whose is it?
19:11 pmichaud I suspect the people responding in RT#41601
19:11 pmichaud you're welcome to add your report to RT#41601.  That might get it moving again.
19:12 ccube What impression does it make on people investigating parrot, if even the bug reporting tool is not functional?
19:13 pmichaud you're also welcome to contribute a patch.  :-)
19:13 particle ccube: not a good one, but we don't get many complaints
19:13 particle maybe nobody likes parrot, or bothers to complain when parrotbug doesn't work, or they use email instead of the program
19:14 ccube But then they have to know where to email to - it seems simple enought to update docs/submissions.pod
19:14 NotFound I, for example, juts notice his existence some days ago, but never tried.
19:15 braceta joined #parrot
19:16 ccube pmichaud: Could I, say, contirbute a patch that dumps parrotbug and update docs/submissions.pod to direct people to RT or email?
19:17 pmichaud ccube: yes.  But again, it's not my call.
19:18 particle ccube: if you contribute that patch, it will be considered
19:19 PerlJam ccube: it's best to just submit a doc patch IMHO
19:20 PerlJam (especially since parrotbug does work for some cross section of people)
19:20 ccube OK in the meantime - how do I report 6 not oks on my "make test"
19:20 ccube of 6.2
19:20 ccube i mean 0.6.2
19:21 NotFound ccube: you can submit a bug report about parrotbug using parrotbug ;)
19:21 ccube I was waiting for that
19:22 jonathan purl, parrotbug
19:22 purl i think parrotbug is mailto:parrotbug@parrotcode.org or http://svn.perl.org/parrot/​trunk/docs/submissions.pod or see also "rakudobug"
19:22 jonathan ccube: You can email the output to that email address, which will create an RT ticket.
19:23 ccube what should go in the subject line, what minimum information should be in the body (all stuff that I imagine a working parrotbug would take care of)
19:23 jonathan Subject: Test failures in 0.6.2 on <your platform>
19:24 ccube ok, thanks
19:24 moritz ccube: operating system, architecture, compiler + version, parrot version, output of failed tests
19:24 jonathan Body: The details of the test failures, and the contents of the myconfig file (in the directory where you built Parrot)
19:25 NotFound Trailing space in List.pir
19:28 ccube pmichaud: As a parting comment, I worry about that "not my call", it reminds me of my time in a big corporation where you could never get things changed, because you could never find anybody that thought they had the authority to make changes
19:29 pmichaud ccube: I understand, really.  But there are people who can make the call on this one -- I'm just not him or her.  Certainly any of DietCoke, particle, or allison could likely make the call.
19:30 japhb OK, cognominal receives the award for most insane set of OpenGL headers: "77 directories, 223 files"
19:30 PerlJam pmichaud: you could do it and then be reviled when you do it wrong  :)
19:30 japhb "We only second guess the decisions that turned out to be wrong."
19:30 pmichaud PerlJam: if I had little else to do at the moment, I might consider it.  Right now I'm way behind on applying patches as it is.
19:31 * PerlJam cracks the whip over pmichaud's head ... "Get back to patching!"
19:31 PerlJam ;-)
19:31 PerlJam pm: have there been that many contributions to rakudo/PGE/PCT?
19:32 barney Anybody cares about tools/util/pirtidy.pl ?  RT#39132 suggest to kill it.
19:32 pmichaud PerlJam: rakudo, yes.
19:32 cognominal japbh: no surprise, I got an award from TPJ for being demented
19:32 japhb ccube: In any large project, there are always people who have more authority in various pieces of it.  Even in the Linux kernel, though Linus may be titular authority on everything, I'm pretty sure there are entire subsystems where he defers entirely to someone else.  But even regular patch people don't have authority over the stuff that he *does* monitor on a daily basis.
19:33 pmichaud PerlJam: and some of them require some refactoring before I can reasonably apply it.
19:33 dalek r28066 | chromatic++ | trunk:
19:33 dalek : [PMC] Cleaned up a compiler warning found in optimized build.
19:33 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28066
19:33 pmichaud PerlJam: and there are some patches which could be applied or submitted if only I have a few more core items cleaned up.
19:33 japhb cognominal: link?
19:33 dalek r28067 | chromatic++ | trunk:
19:33 dalek : [PMC] Cleaned up a compiler warning found in optimized build.
19:33 cognominal http://www.foo.be/docs/tpj/is​sues/vol3_3/tpj0303-0015.html
19:33 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28067
19:33 dalek r28068 | chromatic++ | trunk:
19:33 dalek : [PMC] Cleaned up a compiler warning found in optimized build.
19:33 PerlJam whenever I get a chance to look at rakudo again it's going to be a different beast I think.
19:33 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28068
19:35 pmichaud PerlJam: a lot has changed yes, but underneath a lot of it is still the same.
19:37 IllvilJa joined #parrot
19:47 Whiteknight that's because "underneath of it" == "Parrot"
19:48 dalek r28069 | chromatic++ | trunk:
19:48 dalek : [IO] Cleaned up a few more compiler warnings from optimized build.
19:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28069
19:49 pmichaud actually, it's more that I re-did the underlying class structures.  P6object, for example, and list context.
19:59 moritz there are two patches from bacek++ pending, one for eval, one for eval_(lives|dies)_ok in Test.pm
19:59 moritz http://nopaste.snit.ch/13164 and http://nopaste.snit.ch/13167
20:00 moritz the Test.pm one looks find, I don't understand the eval() one (lack of PIR knowledge)
20:00 dalek allison@perl.org | Bylaws:
20:00 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
20:01 pmichaud moritz: got a commit bit yet?
20:02 moritz pmichaud: no
20:02 paco in linux/x86 t/spec/S29-conversions/ord_and_chr seems to hang, I am alone ?
20:02 pmichaud :-(
20:02 moritz paco: no
20:02 paco moritz: ok
20:02 moritz paco: that's why tools/update_passing_test_data.pl  unlinks that test
20:02 pmichaud file a ticket if one doesn't exist.
20:03 dalek allison@perl.org | Bylaws:
20:03 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
20:05 moritz ok, will do
20:09 dalek allison@perl.org | Bylaws:
20:09 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?bylaws
20:12 moritz actually bacek's patch for eval_dies_ok doesn't work correctly
20:12 moritz > use Test; eval_dies_ok('asdfkljsdf')
20:12 moritz not ok 1 -
20:12 moritz > asdfsdf
20:12 moritz Could not find non-existent sub asdfsdf
20:13 moritz it seems that the outer try { ... } resets the $! from eval
20:16 dalek r28070 | japhb++ | trunk:
20:16 dalek : [OpenGL] Tweak POD, remove dead code
20:16 dalek : * Point to triangle.pir in OpenGL.pir docs
20:16 dalek : * Remove useless .include in triangle.pir
20:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28070
20:17 particle moritz: is that a problem in try, or in eval?
20:18 moritz particle: I don't know if it's problem in try { } or in bacek's patch
20:18 moritz particle: the current behaviour is try { eval 'asdlkfj' }# $! is undef here
20:19 moritz should $! from eval be propagated to the outer scope? or should it reset $! to undef (as it currently does)?
20:19 pmichaud we should get rid of the try { ... }   that is around eval.
20:19 pmichaud but eval needs some work to do that, I think.
20:20 moritz does an eval catch execeptions?
20:20 moritz it probably should
20:20 moritz so maybe the patch is just overly paranoid
20:21 moritz yes, works without the outer try as well
20:28 dalek r28071 | bernhard++ | trunk:
20:28 dalek : #39132: [DEPRECATED] pirtidy
20:28 dalek : Remove pirtidy-pl and Parrot::PIR::Formatter
20:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28071
20:31 Whiteknight t/tools/smartlinks is spitting out a lot of "Use of uninitialized value ..." errors.
20:31 Whiteknight The test passes, but it still spits out errors
20:32 Zaba joined #parrot
20:32 Whiteknight well shoot, it looks like the error is in Text::Balanced, not in the test itself
20:33 Whiteknight and languages/perl6/src/classes/List.pir is failing t/codingstd/trailing_space too, but I can fix that
20:34 barney Whiteknight: I once looked into that, but got confused
20:34 Whiteknight which one?
20:34 purl THAT ONE!
20:34 Whiteknight thanks purl
20:34 barney Text::Balanced
20:34 purl Text::Balanced is cool
20:36 Whiteknight i didn't see any trailing whitespace in List.pir, i'm going to update and run the test again
20:37 Infinoid Whiteknight: line 950
20:38 dalek r28072 | bernhard++ | trunk:
20:38 dalek : #39132: [DEPRECATED] pirtidy
20:38 dalek : Remove the test for Parrot::PIR::Formatter as well
20:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28072
20:38 Whiteknight I checked line 950, didn't see any trailing whitespace there
20:38 Infinoid its a blank line with 4 spaces that should be removed.
20:38 ruoso joined #parrot
20:39 Whiteknight oh shoot, i was looking in my branch, not in trunk
20:39 Infinoid hate it when that happens :)
20:40 Whiteknight fixed
20:41 dalek r28073 | Whiteknight++ | trunk:
20:41 dalek : [rakudo] Removing trailing whitespace for t/codingstd/trailing_space warnings
20:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28073
20:43 Whiteknight urg, now we're failing t/perl/Parrot_PIR_Formatter (probably because of r28072 just now)
20:43 * Whiteknight updates, AGAIN
20:45 barney Whiteknight: should be fixed, by removing the test
20:48 Whiteknight right, i updated (which removed the test) and I'm testing again
20:48 Whiteknight thanks
21:00 moritz ok, patch finally sent to rakudobug (eval_(lives|dies)_ok)
21:05 Zaba_ joined #parrot
21:07 moritz msg jonathan t/spec/S02-polymorphic_types/subset-range.t  has one failing (fudged) test that should actually work
21:07 moritz no msg/tell bot around?
21:08 cotto_work you killed him
21:08 moritz nasty /me
21:08 cotto_work which is funny because something similar killed him yesterday
21:09 moritz I think irc bots are intrinsically nasty ;)
21:09 moritz my perl 6 evalbot sometimes segfaults, and I have no idea why
21:09 moritz everything that's potentially evil is only executed in forked childs
21:10 moritz and all communication is through temp files
21:10 cotto_work it's a recent development with purl
21:10 moritz dunno how that could lead to segfaults at all
21:12 NotFound At least it can be a reproducible bug.
21:17 cotto_work who's purl's handler?
21:19 Infinoid purl, owner?
21:19 Infinoid oh, duh.
21:19 Infinoid Masque I think
21:19 moritz lol
21:23 Zaba joined #parrot
21:26 purl joined #parrot
21:27 particle moritz: i don't see the patch, just the mail
21:27 moritz particle: dammit, I forgot..
21:27 particle infinoid, owner?
21:28 * particle sends out more resumes
21:28 moritz particle: now sent with patch
21:29 particle moritz++
21:29 Infinoid particle: Use of uninitialized value in print at -e line 1.
21:29 Infinoid particle: owner is .
21:29 moritz actually mostly bacek++
21:30 Whiteknight ++ for everybody!
21:30 Whiteknight particle, resumes? you in the job market too?
21:30 particle i am, i cried
21:31 Whiteknight i've been in the job market for years
21:31 particle me too, that's a consultant's life :)
21:31 Whiteknight it's not a bad place to be, if you like being a poor unemployed graduate student
21:33 particle hrmm... having tests that actually test Test.pm in t/02-test-pm would be nice
21:34 slightlyoff joined #parrot
21:36 donaldh joined #parrot
21:40 particle moritz:
21:40 particle t\spec\S02-polymorphic_types\subset-range.t   (Wstat: 0 Tests: 6 Failed: 1)
21:40 particle Failed test:  4
21:40 particle Files=58, Tests=1107, 412 wallclock secs ( 0.39 usr +  0.31 sys =  0.70 CPU)
21:41 moritz particle: oops, forgot to commit a fudge :(
21:41 moritz particle: try again please
21:41 moritz I'm not really concentrated any more, should go to bed
21:42 particle ok, i'l try again
21:42 particle it'll take 10m to run or so, then will commit
21:44 pmichaud okay, I have a Parrot oddity
21:44 pmichaud and it's pretty annoying
21:44 nopaste "pmichaud" at 76.183.97.54 pasted "very odd behavior in Parrot" (18 lines) at http://nopaste.snit.ch/13171
21:46 nopaste "pmichaud" at 76.183.97.54 pasted "very odd behavior in Parrot, with PIR source" (36 lines) at http://nopaste.snit.ch/13172
21:48 pmichaud for some reason   the line  $P0 = values.'sort'(by)  is jumping directly to infix:cmp
21:50 bacek morning
21:51 bacek Test.pm should be without 'try' around eval
21:52 Zaba joined #parrot
21:55 particle pmichaud: can you do a tailcall there instead?
21:55 particle i'm not sure if pir has sugar for .return values.'sort'(by)
21:55 pmichaud tailcall gives me a segfault.
21:55 particle i wonder if it will change anything
21:55 particle well, it changes something then :)
21:55 pmichaud which is what started me on this path in the first place :-(
21:56 pmichaud getting rid of the tailcall at least got me here.  But let me check something else first.
21:58 pmichaud I think I can get a PIR program that exhibits the difficulty
21:58 pmichaud doh!
21:59 pmichaud found it.
21:59 pmichaud <latella> "Never mind."  </latella>
21:59 pmichaud oh, wait, that's not it.
22:00 pmichaud okay, let me put together a short PIR program
22:01 nopaste "bacek" at 202.7.166.166 pasted "better List.sort for pmichaud" (28 lines) at http://nopaste.snit.ch/13173
22:01 dalek r28074 | particle++ | trunk:
22:01 dalek : add eval_dies_ok and eval_lives_ok (bacek++ moritz++)
22:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28074
22:02 dalek r28075 | particle++ | trunk:
22:02 dalek : [rakudo] more tests passing due to eval_dies_ok and eval_lives_ok (moritz++ bacek++)
22:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28075
22:03 bacek particle, eval_lives_ok is incorrect. It always passed due try{}
22:04 particle ...this is why t/02-test-pm/ needs more tests...
22:05 moritz bacek: did you check the version that particle commited right now?
22:05 moritz bacek: I think I fixed it
22:05 moritz but maybe I broke it in other ways
22:05 particle who woke moritz?
22:05 bacek moritz, yes, I checked diff
22:06 moritz oh, maybe it was just eval_dies_ok that I fixed
22:06 bacek particle, I'll write more tests in 02-test-pm. Later today...
22:06 moritz stupid me
22:06 moritz perhaps we should first fix/fuge the existing 02-test-pm tests
22:06 pmichaud ".sub 'sort' :multi(_)"    might not work if 'sort' has no arguments.
22:08 jonathan pmichaud: If you didn't see earlier - will do Rakudo hacking tomorrow.
22:08 pmichaud let me run a spectest_regression, commit what I have, and we can play more
22:08 pmichaud jonathan++
22:08 jonathan Is there anything you specifically want me to do or not do?
22:08 jonathan I've not been watching the chanel much today, and am too tired to read the whole backscroll to know exactly what you're working on right now...
22:08 pmichaud not off the top of my head.
22:09 pmichaud right now I'm refactoring List a bit more and cleaning up exports
22:09 donaldh japhb: apologies for not yet replying with status of OpenGL on Cygwin testing.
22:09 pmichaud I still need to work on parameters a bit but don't know when I'll get to it.
22:09 jonathan OK.
22:09 jonathan What are you planning for parameters?
22:09 pmichaud just a refactor, mostly.  I think too much of the work is being done too high in the parse tree.
22:09 jonathan I think my patch wasn't too far off correct, aside from forcing Mutable into place...
22:10 jonathan What's remaining todo on Mutable before we can really switch to that?
22:10 pmichaud getting find_method to work properly
22:10 pmichaud or figuring out how we can say "apply X to the mutable instead of what it contains"
22:11 jonathan So that it lets you call methods on the container as well as forwarding them?
22:11 pmichaud i.e., getting infix:= to work, or alternatively, figuring out how we can get vtable assign to dtrt for other types.
22:11 jonathan Why can't we just use assign directly for all types?
22:11 jonathan And customize it a little?
22:12 pmichaud I'm not sure how to overload  assign for, say, Integer without totally messing things up.
22:12 jonathan e.g. Scalar calls .item on what assign is passed
22:12 jonathan Assign for Integer?
22:12 pmichaud @a[0] = 3;    @a[0] = 4;
22:12 jonathan Oh.
22:12 jonathan Hmm
22:12 jonathan Yes, that's...not nice.
22:13 jonathan I guess for now we can have each array element being a scalar.
22:13 pmichaud no, I think that's fundamentally wrong.
22:13 jonathan But it's a whole lotta PMCs.
22:13 pmichaud I'd rather not go that way.
22:13 jonathan Yeah.
22:13 jonathan This boils down to, "I can haz keyed assign", right?
22:14 pmichaud not necessarily
22:14 pmichaud I'm thinking there might be other situations where this comes up
22:14 jonathan OK.
22:14 pmichaud I can't come up with any off the top of my head, but...
22:15 jonathan I guess, when doing an array index assignment we want to get the element, then do a copy op?
22:15 pmichaud that's what is happening now, yes.
22:15 jonathan It'd be nice to have something cleaner.
22:15 pmichaud agreed.  that's "I can haz keyed assign", I think.
22:15 moritz you can temp() items of an array (like perl 5's local())
22:15 jonathan So we can stick the type-check in more neatly, for example.
22:16 moritz can that be done without "a scalar for each item"?
22:16 pmichaud I think so, yes.
22:16 jonathan Yeah, I think so too.
22:16 pmichaud arrays can attach properties to values as they're placed into the array
22:17 moritz or is temp() done via temporary assignment anyway?
22:17 pmichaud we aren't doing temp() yet, so I hadn't really worried about that.
22:17 pmichaud It won't bother me if some of the elements of an array end up being Scalars, but I certainly don't want that for every element
22:18 jonathan Yeah, it's a lot of overhead.
22:18 pmichaud the answer may be to have infix:= check for a Scalar target and dtrt
22:19 jonathan assign vs copy?
22:19 pmichaud yes.
22:19 jonathan Makes sense.
22:19 pmichaud you could try that if you want :-)
22:19 pmichaud seems easier for now than trying to fix vtable.
22:20 pmichaud but somewhere in all of this we will have to decide how to do VAR($x)
22:20 bacek see everyone in couple of hours
22:20 pmichaud maybe a MutableVAR PMC  :-)
22:21 jonathan MutableVAR PMC is almost exactly what I was thinking.
22:21 jonathan I may do that tomorrow.
22:21 pmichaud it is also completely acceptable to try to do it through a special method on Mutable.
22:21 purl okay, pmichaud.
22:21 jonathan On infix:= dispatching properly, I think we need to not just blindly forward find_method, but first check if the container has any matching methods.
22:22 jonathan perl, it
22:22 jonathan purl, it
22:22 purl or completely acceptable to try to do it through a special method on Mutable.
22:22 jonathan purl, forget it
22:22 purl jonathan: I forgot it
22:22 jonathan *sigh*
22:22 pmichaud I don't think we want Scalar's methods interacting with the values methods, though
22:22 pmichaud that's what VAR() is for.
22:23 jonathan OK
22:23 jonathan So tasks are:
22:23 jonathan * MutableVAR, to make VAR work
22:23 jonathan * Get assign to do what infix:= does now for each of the types, so we don't need infix:=
22:24 pmichaud (Get assign to do...)   I don't think that's likely, at least not for the Parrot existing types.
22:24 jonathan Scalar assignment just calls .item on the value, I thought?
22:24 pmichaud or not until we have a way of invoking superclass vtable methods from within a PIR subclass.
22:25 jonathan So Perl6Scalar's assign would call .item on the value, then call SUPER
22:25 pmichaud do you mean the assign vtable op?  I'm not concerned about Perl6Scalar for that -- it's the other types that concern me.
22:27 jonathan Are you thinking the keyed case here?
22:27 pmichaud or anywhere that we end up with a value that could otherwise be assigned to
22:28 pmichaud but for short term I think just get infix:= to recognize Scalar vs. other and perform assign or copy
22:28 jonathan $a = ..., @a = ..., %a = ... - all seem relatively easy to handle with assign; that is, assignment directly to the container
22:28 jonathan The other case is to some other value
22:29 jonathan For that, can we not do .sub 'assign' :method :vtable in Object?
22:29 jonathan And it does a copy?
22:29 pmichaud yes, but
22:29 pmichaud let's suppose that somehow we end up with a Parrot   String, Integer, or Float somewhere
22:29 pmichaud (as opposed to a Perl6 Str, Int, or Num)
22:30 pmichaud the assign vtable will not dtrt for those values.
22:30 jonathan Ah. This, will not dispatch to our assign. :-(
22:30 pmichaud exactly.
22:30 jonathan Damm. And we need .HLL to get rid of those.
22:30 pmichaud and even when we have .HLL, I'm not entirely certain we'll be able to 100% get rid of those for a while.
22:30 jonathan Yeah.
22:30 pmichaud I'm not sure if   :slurpy   and :slurpy :named   map to HLL types
22:30 pmichaud (yet)
22:31 jonathan OK, but they could be made to.
22:31 pmichaud yes, but I'm thinking we're better off leaving that to a longer-term issue
22:31 pmichaud short term, infix:= seems to be flexible enough to do what we want.
22:31 pmichaud at least until we get some of the other particulars in place.
22:32 jonathan OK, but does that mean we need to get infix:= being called on Scalar rather than on a value itself somehow?
22:32 pmichaud I'm thinking we let Object's infix:= figure it out.
22:32 jonathan Ah, because we already fixed isa in Mutable.
22:32 pmichaud rather than trying to get Parrot's MMD to do it.
22:32 pmichaud right.
22:32 jonathan OK, that sounds sane.
22:33 pmichaud not a permanent solution, but clean enough that we can proceed for a while until we start down the road of .HLL mapping
22:33 jonathan OK, sounds good.
22:33 pmichaud it's easy enough to switch   infix:= to assign  later  :-)
22:33 jonathan True. :-)
22:33 pmichaud and yes, I would like as many things as possible to be using assign
22:33 jonathan OK, so I'll look at that and VAR tomorrow.
22:34 pmichaud so perhaps what we do is overload assign for Perl6Object, but continue to use infix:= also
22:34 pmichaud and infix:= does 'copy' only for the non Perl6* types
22:34 pmichaud but I think taking the simpler step first is easier
22:35 pmichaud personally, I'm becoming more interested in how roles get handled
22:35 slightlyoff left #parrot
22:35 jonathan Hang on....infix:= is a method call, so I guess we are sticking those methods into the namespace of other classes?
22:35 pmichaud yes.
22:35 jonathan OK.
22:35 pmichaud a hack, I know.
22:35 jonathan So will we emit an assign anywhere, or just have support ready for when we can use it?
22:36 pmichaud short term I think we continue to stick with emitting infix:=
22:36 IllvilJa joined #parrot
22:36 jonathan OK.
22:36 pmichaud long term goal is to use assign, but in meantime we'll build support for it as we can
22:36 pmichaud oh!  I know something else worth working on :-)
22:37 pmichaud lazy lists.  :-)
22:37 jonathan Alright. So I'll work on that a bit tomorrow morning, as well as VAR. And then I was also planning roles.
22:37 jonathan Aha. :-)
22:37 jonathan Damm, I need like, a Rakudo *week*.
22:37 pmichaud although I'm still messing with the list code.
22:37 jonathan I'll let you finish your messing first, then.
22:37 pmichaud yes, that's probably wise.
22:37 jonathan I can always look at lazy lists in next week's Rakudo day.
22:37 Whiteknight if i had the money, i would fund a week
22:38 pmichaud how much would a week be, at vienna.pm rates?  $750?  ;-)
22:38 jonathan Whiteknight: Due to other commitments, I couldn't actually give a straight week this month anyway.
22:38 jonathan July Rakudo gets me two days a week, thanks to Viena.pm++ and DeepText++.
22:38 pmichaud I'm already declaring Jun-Aug 2008 to be "Rakudo Summer" for me  :-)
22:38 gryphon joined #parrot
22:39 pmichaud anyway, lazy lists for next week's rakudo day would be good.
22:39 PerlJam Does that mean we get "Perl6 Fall"?  :)
22:39 Whiteknight pmichaud, are you a teacher or professor?
22:39 Whiteknight they're the only people I know who get a summer off
22:39 pmichaud heh
22:40 jonathan OK, sounds like a plan.
22:40 pmichaud I think I'm going into my fifth year of being "off"
22:40 pmichaud I took an unpaid sabbatical starting September 2003.   Never really went back.  :-P
22:40 pmichaud (I did teach two online courses this past fall and spring, though.)
22:41 Whiteknight i was hoping that you were a professor, i would apply to be your graduate student
22:41 kid51 joined #parrot
22:41 pmichaud *were* is the operative term, though.
22:41 pmichaud I don't have any real plans to return to being a professor.  "been there, done that."
22:41 clunker9__ joined #parrot
22:43 jonathan http://www.jnthn.net/articles.shtml # uploaded by talks from Stockholm uni, NPW and FPW
22:43 jonathan s/by/my/
22:44 jonathan Will do use.perl.org and rakudo.org post about them now too.
22:44 pmichaud please do.  I'll read them a bit later :-)
22:45 jonathan Hmm...my talks list is starting to get quite long. :-)
22:45 Zaba_ joined #parrot
22:47 teknomunk joined #parrot
22:48 japhb jonathan: several of the talks have the same title, at different venues.  Can we assume that the topmost entry is the newest/most complete?
22:48 jonathan japhb: Yes, pretty much.
22:48 japhb jonathan: great, thanks
22:49 jonathan I will note that in my use.perl.org post
22:49 jonathan The differences are very subtle.
22:49 pmichaud I need to create a page of my talks also.
22:49 mire joined #parrot
22:51 tetragon joined #parrot
22:53 pmichaud should   ns.'add_sub'($P0)    work when $P0 is a MultiSub ?
22:53 pmichaud (and ns is a namespace PMC)
22:55 pmichaud I'm going to vote yes.  I'm even going to commit my vote.  :-)
22:55 jonathan pmichaud: I think so, yes.
22:55 jonathan Commit as in, patch to make it do so? ;-)
22:55 pmichaud yes.
22:55 jonathan pmichaud++
22:55 pmichaud forgiveness instead of permission, and all that.  :-)
22:55 jonathan I'm sure enough that it should work, that I'm happy to share any guilt. :-)
22:56 pmichaud of course, it really needs to be made smarter than what I'm going to write now, so that multiple calls to 'add_sub' merge the multisubs together.
22:56 pmichaud but I'm just going to do the simple case for now.
22:56 pmichaud or,
22:56 pmichaud hmmm
22:56 pmichaud maybe I'll do the long one.
22:57 jonathan And make sure you're doing an isa check rather than base_type ;-=)
22:57 jonathan So when I subclass MultiSub in July, it keeps on working. :-)
22:57 pmichaud of course!
22:57 * pmichaud evilly considers doing base_type anyway, just to see if jonathan catches it.  :-)
22:57 jonathan :-P
22:57 PerlJam jonathan: I just looked through your slides. The ones from the FPW on using parrot/perl6 in teaching are interesting.
22:58 jonathan PerlJam: Yeah, I wasn't really sure what to say in that talk, but I hope I made sense. :-)
22:58 jonathan I'm more used to giving technical talks.
23:07 IllvilJa joined #parrot
23:21 jonathan Stuff posted to various journals.
23:22 Zaba joined #parrot
23:28 Whiteknight longest-token matching is, i take it, hard to implement?
23:29 PerlJam Hard to get right in that it depends on what you're matching against
23:29 Whiteknight okay, i dont know a lot about regex engine implementation, so i dont know
23:31 jonathan It's hard. :-)
23:32 dalek r28076 | Whiteknight++ | trunk:
23:32 dalek : [docs/book] a few fixes to chapter 6 in readability. no major updates needed
23:32 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28076
23:32 Whiteknight okay, that explains why it hasn't been done yet
23:33 cotto_work jonathan++ #manatees do not explode
23:36 PerlJam Whiteknight: imagine that you've got the regex   f | food | f.*  under LTM semantics you don't know which of those 3 alternatives "wins" until you've seen the string you're matching agains.
23:36 dalek r28077 | pmichaud++ | trunk:
23:36 dalek : [core]:
23:36 dalek : * Allow 'add_sub' for namespace PMCs to work for MultiSub PMCs.
23:36 dalek :   See also RT#55308 for some other improvements to make.
23:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28077
23:42 dalek r28078 | pmichaud++ | trunk:
23:42 dalek : [rakudo]:
23:42 dalek : * More List class refactoring.  This commit temporarily breaks
23:42 dalek :   S29-list/sort.t due to an odd Parrot bug, which I'm looking at
23:42 dalek :   now.
23:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=28078
23:44 Whiteknight what would people say are the main principals behind Parrot's design?
23:46 Whiteknight docs/book lists three: "speed, abstraction, and stability"
23:47 Whiteknight I'm wondering if those are really current/accurate descriptions of the design principals
23:50 Infinoid wings, beak, and feet
23:52 PerlJam Whiteknight: s/speed/correctness/ and it reads closer to how I think of it.
23:52 Infinoid those are nice words, and parrot certainly follows them, if not necessarily in that order
23:52 Infinoid I'm sure portability is in there somewhere, too.
23:53 Infinoid and DRY
23:53 Whiteknight and dwimmyness
23:54 Whiteknight ...which isn't really a word
23:54 bacek_ joined #parrot
23:54 japhb Is there a more coloquial way to do an early exit from a void PIR sub than '.return ()' ?
23:55 Whiteknight not that i know of
23:55 Whiteknight '.return'
23:56 japhb Whiteknight: doesn't work.  Parsefail
23:56 Whiteknight see? that's what you get for listening to me
23:57 japhb :-)
23:57 japhb Just as long as you collect that garbage ... ;-)
23:58 ank joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced