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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!