Parrot 0.9.0 | parrot.org/ | 479 RTs remain
Set by moderator on 10 February 2009.
00:08 AndyA joined
Whiteknight can't wait to be done with this stupid branch 00:09
Coke-really-afk chromatic: I cannot reproduce it right now because fperrard broke the PGE build on feather, so I can't do anything with valgrind. 00:18
Coke msg chromatic I cannot reproduce it right now because fperrard broke the PGE build on feather, so I can't do anything with valgrind. 00:19
purl Message for chromatic stored.
chromatic thanks 00:20
Coke ah, hi. 00:26
sorry.
dalek rrot: r36563 | whiteknight++ | branches/vtable_morph_change:
[vtable_morph_change] update to trunk r36562. Fixes all errors I had. Preparing to merge back to trunk
 00:45
rrot: r36564 | chromatic++ | trunk:
[PMC] Removed a check in NameSpace PMC which prevented the addition of Subs to

with a name directly later with set_global. See TT #56. Now you can insert them in a namespace later.		 00:55
00:55 Limbic_Region joined
rrot: r36565 | cotto++ | trunk/t/benchmark/benchmarks.t:
[gc] redo clobbered DOD->GC name change
 01:11
rrot: r36566 | cotto++ | trunk:
[gc] rename Parrot_shared_DOD_(un)?block to Parrot_shared_gc_(un)?block
 01:13
Whiteknight stupid piece of shit SVN won't let me merge my branch into trunk 01:16
chromatic It's haunted.
kid51 Why not? Conflicts? 01:17
kid51 has to give a talk about SVN branching and merging at $job tomorrow.
Whiteknight svn: working copy path t/src/embed.t does not exist in the repository
kid51 What was your merge command?
Whiteknight svn merge -r36396:HEAD --force svn.parrot.org/parrot/branches/vta...rph_change
kid51 I'm not familiar with that syntax. 01:18
Whiteknight what syntax should I use? I'm a relative SVN newbie
of course, it's always worked for me in the past 01:19
and in either case, t/src/embed.t does exist everywhere that I look for it
kid51 This is 'svn merge' variant #3 in 'svn merge --help' -- correct?
Whiteknight I guess 01:20
chromatic You probably need to merge from trunk again.
Whiteknight craptastic
chromatic We commit too much.
cotto I'll hold off any commits until you've got the merge, if that helps,
s/,$/./ 01:21
Infinoid Whiteknight: t/src/embed.t is renamed from t/src/compiler.t, if it helps
kid51 has never used the --force option to svn merge
cotto the force is not with kid51 01:22
Whiteknight I only tried --force because it wasnt working otherwise 01:23
kid51 cotto: Too true
dalek rrot: r36567 | whiteknight++ | branches/vtable_morph_change:
[vtable_morph_change] another update
kid51 Whiteknight: do you want we to do a 'svn co' of branch and try to merge? 01:24
Whiteknight no, it's personal for me now
Whiteknight WANTS BOOD
or blood
kid51 In that case, kid51 will start making dinner! 01:25
Whiteknight urg, same error
chromatic Did t/src/embed.t get renamed?
Or do you have local changes?
Whiteknight apparently it did
Infinoid usually with svn merges, I eventually just give up, get a clean export and rsync that into a fresh trunk checkout
Whiteknight yeah, i'm doing a clean checkout now 01:26
kid51 Coke: Re trac.parrot.org/parrot/ticket/310 : didn't we have an RT about that once upon a time?
Infinoid it's especially ridiculous because you already *did* the merge (r36563)
Whiteknight same error on a clean checkout. I give up for tonight 01:29
if anybody else has stronger SVN-foo then me, you're welcome to give it a chance
Infinoid will do.
Whiteknight t/src/embed.t exists in both repositories 01:30
dalek rrot: r36568 | cotto++ | trunk/include/parrot/thread.h:
[gc] apparently, capitalization matters in function names
 01:31
Whiteknight so I don't know what it's saying doesn't exist where
Infinoid from svn's perspective, it was renamed *twice*, so its having trouble finding the base to merge from
it's just stupid.
I won't even bother with "svn merge", one rsync coming up. (don't worry, I won't clobber more recent trunk changes)
Whiteknight okay, it makes me feel better that it's not some easy solution 01:32
Infinoid feel free to submit bug reports in their tracker, of course :) 01:33
kid51 More likely: When I was writing tests for the config steps, I probably asked why one would want to manually specify PMCs. 01:35
And I probably went to some length to write a test that demonstrates that one can, indeed, specify individual PMCs to configure with via that option. 01:36
01:40 Fayland joined
kid51 Ah: here's what I was thinking of: first post in rt.perl.org/rt3/Ticket/Display.html?id=43172 01:44
Infinoid Whiteknight: was r36567 a pure merge, or were there any local changes?
dalek rrot: r36569 | Infinoid++ | trunk:
Merge vtable_morph_change branch changes back into trunk. Whiteknight++, svn--, rsync++.
Infinoid Looks like I reverted some stuff by accident. One moment. 01:49
dalek rrot: r36570 | Infinoid++ | trunk:
Revert "Merge vtable_morph_change branch changes back into trunk."

I'll redo the merge, this time the hard way.		 01:53
Whiteknight Thanks Infinoid++ 01:58
I'm going to bed now, too angry at computers to do any more coding 01:59
Infinoid Gives me an excuse to abuse git-svn :)
good night
svn.parrot.org seems much faster than svn.perl.org 02:06
Infinoid just did 9 branch exports in 2 minutes flat 02:07
02:15 bacek joined
kid51 Infinoid: 'branch exports': Is that git-speak? 02:43
Infinoid no, that's "svn export" 02:49
msg whiteknight Was trac.parrot.org/parrot/changeset/3...ge#file187 intentional? It snuck into an otherwise clean merge commit. 03:03
purl Message for whiteknight stored.
shorten Infinoid's url is at xrl.us/beftdq
Infinoid cherrypicked merge successful. \\o/ now to test it 03:19
03:22 tetragon joined
Util_away purl, seen sahadev? 03:26
purl sahadev was last seen on purl 3 years, 219 days, 11 hours, 13 minutes and 17 seconds ago, saying: <private message> [Jul 7 16:12:49 2005]
03:36 janus joined
dalek rrot: r36572 | Infinoid++ | trunk/src/io/win32.c:
[cage] Trim whitespace to pass c_parens.t.
 03:44
kid51 dalek: Why haven't you posted 36573 yet? 03:54
Infinoid dalek has been having some trouble in the last couple of days. It's on my list.
nopaste "Infinoid" at 75.28.75.73 pasted "Test failures in merged vtable_morph_change tree" (11 lines) at nopaste.snit.ch/15579 03:56
"Infinoid" at 75.28.75.73 pasted "BigInt segfault in merged vtable_morph_change tree (attempt to access "bi" ATTR through NULL data pointer)" (22 lines) at nopaste.snit.ch/15580
"Infinoid" at 75.28.75.73 pasted "Summary patch for vtable_morph_change branch merge. (Applies cleanly to r36572)" (946 lines) at nopaste.snit.ch/15581
Infinoid msg Whiteknight I didn't apply the merge results to trunk, as I got some bigint-related test failures. See nopaste.snit.ch/15579 and nopaste.snit.ch/15580. git pull git://squawk.glines.org/merge-branch-vtable_morph_change or apply nopaste.snit.ch/15581 to get the merge results.
purl Message for whiteknight stored.
Infinoid There, now on to dalek.
kid51 Infinoid: thanks 04:03
kid51 must sleep
purl $kid51->sleep(8 * 3600);
04:32 contingencyplan joined 04:37 ask joined
basic Infinoid: we've got another student working on it, i think he's making progress (email2trac). I've got a really busy week and don't have much time to work on getting it working, it's still really close last i checked, some issue with permissions between postfix and apache. We can test that in house though, so no need to send more test emails for now 04:37
Infinoid Ok, thanks for the update, hope your week goes well
04:49 tetragon joined 04:58 dalek joined
Infinoid that should fix the partcl parser, and hopefully make the parrot parser no longer skip any revisions. 04:58
dalek rtcl: r326 | wcoleda++ | trunk/src/ (4 files):
Track rename of string_length
allison@perl.org | Debian/Ubuntu chroot Environment Setup: 04:59
link: www.perlfoundation.org/parrot/index...ment_setup
shorten dalek's url is at xrl.us/beesjm
Infinoid uh, that wasn't a new partcl rev, dalek
05:16 jimmy joined 05:20 jimmy left 06:05 Tene joined 06:08 iblechbot joined 06:13 mikehh joined 06:43 rurban_ joined 07:04 Andy joined 07:14 uniejo joined 08:21 iblechbot joined 08:48 bacek joined 09:09 masak joined
dalek rrot: r36574 | rurban++ | trunk/t:
[t] Fix the last mingw smoke errors. TT#313
 09:14
09:15 alvar joined 09:28 riffraff joined 09:38 bacek joined
dalek rrot: r36575 | chromatic++ | trunk/t:
[t] Marked -0.0 tests as TODO instead of failing on MSWin32 and OpenBSD, per
 09:41
10:13 AndyA joined
dalek kudo: 7b4118d | jnthn++ | Configure.pl:
[config] Configure needs to translate forward slashes in makefile to backwards ones for Win32, as Parrot's Configure did. Otherwise the build silently misses a bunch of important bits!
 10:33
shorten dalek's url is at xrl.us/beft37
mikehh perl Configure --optimize --test is failing tests after configure as at r36575 10:48
specifically t/tools/pmc2cutils/00-qualify Failed test: 5 10:50
t/tools/pmc2cutils/04-dump_pmc Failed test: 63
t/tools/ops2pm/00-qualify Failed tests: 8-9 10:51
and prove fails on these tests after the build - make world 10:55
running make test now 11:00
ok make test passes 11:04
11:06 kid51 joined
dalek kudo: d668ca9 | jnthn++ | src/classes/ClassHOW.pir:
Fixes to make sure dispatches on proto-objects work correctly; resolves RT#62894.
 11:37
shorten dalek's url is at xrl.us/beft6u
dalek rrot: r36576 | fperrad++ | trunk/languages/pipp/config/makefiles/root.in:
[Pipp] add a target 'codetest'
 11:42
rrot: r36577 | fperrad++ | trunk/languages/pipp:
[Pipp] fix some coding standards
 11:44
11:47 Gerd joined
dalek kudo: 59024e0 | jnthn++ | src/classes/Object.pir:
Fix .clone to deref ObjectRefs properly by calling !DEREF, which follows chains. Resolves RT#62828.
 11:52
shorten dalek's url is at xrl.us/beft7a
dalek rrot: r36578 | jkeenan++ | branches/update_pod/t/doc/pod.t:
In the middle of modifications. Not stable.
 12:11
12:31 rg1 joined
dalek rrot: r36579 | rurban++ | trunk/t:
TT #313 win32 (mingw + msvc)

  - fix complex todo error introduced by r36575
  - clarify "inf is not platform-independent" for win32 msvc only, todo added
All win32 arithmetic tests should pass now		 12:57
kudo: 1beabec | jnthn++ | src/ (3 files):
We need to call .clone() rather than just using Parrot's clone vtable method fairly generally, I expect. This does that in a couple of places, which in turn resolves RT#63002 and gets an integration test passing.
 13:01
shorten dalek's url is at xrl.us/befubr
13:05 Whiteknight joined 13:10 iblechbot joined
Infinoid Oh spam, how I love you so. When you order a new internet connection, you can always tell when it's gone live because you start getting SMTP connections. 13:16
It's like the cosmic internet background radiation.
Whiteknight Infinoid, how did that branch merge go last night? 13:19
Infinoid thinks Whiteknight just got ambushed with purl messages
Whiteknight yeah, I'm going through them now
Infinoid :)
Whiteknight so....what happened? 13:20
Infinoid I'm sitting on the patches here hoping we can resolve the bigint failures first 13:21
Whiteknight stupid bigint failures
I'll have to take a look at them tonight unfortunately 13:22
Infinoid I've got a little time before work today, so I'm hoping to make some progress soon 13:24
Whiteknight this whole thing is such a damn mess
Infinoid Also, I've tweaked dalek again. Please yell at me if you notice any more commits being dropped
Whiteknight okay, will do 13:25
I must have missed that one commit during one of the merges 13:27
stupid merges
Infinoid Now that I've got it in git, it'll be easier to track trunk 13:28
Whiteknight I guess I really need to get git now. This isn't the first problem I've had with sloppy SVN merging behavior, and certainly won't be the last 13:29
not with the rate that I create branches
szbalint svn--
Infinoid well, git doesn't always help much directly with svn branches, but it is damned nice for cleaning up the result 13:30
Coke (missing file t/src/embed.t) be very careful when doing svn merges on renamed files, or you can easily lose changes. 13:53
(rename file in branch a. edit file in branch b. merge file from a to b. commit; lose changes you made in b) 13:54
Whiteknight yeah, found that out the hard way 13:55
Coke Infinoid: what shoudl fix partcl's what? 13:56
13:57 tetragon joined 14:02 gryphon joined
Infinoid Coke: dalek's partcl rss parser had a problem when the commit covered multiple files. e.g. irclog.perlgeek.de/parrot/2009-02-09#i_895579 14:02
I fixed that, hopefully.
googlecode's formatting for those things is weird
dalek kudo: fba805c | jnthn++ | src/parser/grammar.pg:
Add panic on malformed declaration, as seen in STD.pm (with note on our little difference against STD.pm). Also we accidentally parsed/passed a private method test; add something to mitigate that to keep the spectests clean.
 14:06
shorten dalek's url is at xrl.us/befufa
pmichaud good morning 14:07
14:08 knewt joined
knewt before i start going looking, anyone know off the top of their head what the current state of documentation is like? 14:09
moritz knewt: whiteknight was looking for readers/reviewers 14:11
and the status as always is "needs more work"
Whiteknight documentation in some places is pretty good
docs/book/ is in decent shape now. Some of the other miscellaneous docs are out of date though
14:12 alinbsp joined
jonathan morning pmichaud 14:12
pmichaud (clone) I'm thinking that for language interop we need to bias towards the Parrot ops instead of the methods. 14:14
jonathan Hmm. True. 14:15
Didn't we decide that we would catch those and re-dispatch to the methods, though?
pmichaud yes.
I think.
jonathan It's a tad tricky for clone...
But we can do that somehow I expect.
pmichaud that's what I tend to do for most vtable methods on Rakudo objects
jonathan We still need access to Object PMC's clone...
pmichaud anyway, we don't need to change/fix anything immediately 14:16
that's just my general bias at the moment.
jonathan Sure. I think if we can get .clone() working right, then later on we should be able to work the re-dispatch into it.
pmichaud right
jonathan BTW, do you agree that in general we should favor calling .clone() within Rakudo over the Parrot op?
pmichaud depends on what you mean by "within Rakudo" 14:17
jonathan I've fixed a bug by doing that...since our clone understands that it needs to deref.
OK, in things like postfix:++ that does a clone.
pmichaud right, that's what I was referring to. I'm thinking that in general we should favor the Parrot op
for language interop reasons.
jonathan Well, if that will just re-dispatch to .clone() then we may as well, in the ops, just call .clone() 14:18
IMHO
pmichaud foreign objects won't redispatch to .clone, though.
jonathan Ah, true...
pmichaud foriegn objects might not have a .clone
jonathan Yes. 14:19
Grr.
pmichaud anyway, it's something we can worry about later
jonathan Sure.
Working first, then better interop. :-)
Can I point you at a copule of tickets?
pmichaud I just didn't want us to start doing a wholesale "change vtable to methods" switch throughout the codebase only to discover we need to switch them all back.
sure.
jonathan rt.perl.org/rt3/Ticket/Display.html?id=58676
I think that this now dos the type-check it should. 14:20
However, Foo.new ~~ Foo dies (Foo.new("") ~~ Foo works though)
pmichaud I'll be having to re-do .new on Match/Grammar objects 14:21
right now it's using PGE's .new, which was a long-time-ago guess as to how things would work
(and PGE's .new requires an argument, I think)
jonathan OK 14:22
pmichaud I'm fine with closing #58676 -- the issue there has been resolved.
jonathan But since the ticket is saying it should do a type-check...right, that was my feeling.
Also, masak gave me a list of tickets that mattered most to him. Two were already fixed, I fixed the rest apart from one today.
Which is rt.perl.org/rt3/Ticket/Display.html?id=62704
I figured you'd have a good idea on what it should do, etc. :-) 14:23
pmichaud well, technically $/ _is_ returning a Match object.
it's just not a Rakudo Match.
jonathan OK. I'll leave the ticket/responding etc with you. :-) 14:25
pmichaud yes, that's fine. The spec isn't very clear on the relationship between Match objects and Grammars 14:26
Infinoid Whiteknight: Oh, I figured it out. Your VTABLE_get_integer addition to class.pmc doesn't work for bigints, because get_integer() has special meaning for integer types. When default.morph() tries to get the integer from the BigInt class object, it thinks you're trying to get the value of the bigint, but since the class object doesn't have an attr array, bam, segfault. 14:27
(20 frames down the stack, the code in question was originally trying to upgrade an integer due to a modulus() call that involved some bigints.) 14:28
Coke rant: our pmc internals suck.
modulus - ooh, i wonder if that's related to my occasional 2%0 errors.
(in partcl)
14:28 gryphon joined
Coke I am wondering why we don't just use Hash for our attrs. 14:29
pmichaud Because that would be too much like Perl.
Infinoid We do, internally.
dalek kudo: 1b7a3e3 | jnthn++ | src/parser/grammar.pg:
A few more panics on malformed code from STD.pm. Resolves RT#59828.
Infinoid Oh, the other attrs
shorten dalek's url is at xrl.us/befug2
Coke the GET_ATTR stuff is hitting actual struct members, no?
(which are auto-gened when the pmc is built?) 14:30
Infinoid Yeah, I was thinking of the prop hash, which is different
Coke pmichaud: perl, which works, and doesn't segfault quite so much? =-)
pmichaud Coke: I don't agree with the reason; I just suspect that _is_ the reason.
Infinoid Coke: I kinda doubt the partcl is related... I'm debugging the vtable_morph_change branch, the code hasn't hit trunk yet 14:31
err, the partcl issue you're seeing
Coke fair enough. I have a modulus related segfault that's been open for months, was just hoping. 14:33
Coke is >this close< to just reverting fperrad's change that broke PGE on feather.
Infinoid Okay, I'm game. Got a ticket and/or a backtrace?
pmichaud 10 characters apart? That doesn't seem very close. :-) 14:34
Coke Infinoid: trac.parrot.org/parrot/ticket/66
pmichaud: yah, that's why I haven't done it yet. :P
is the tcl one. 14:35
the PGE one is:
trac is also slow
purl okay, Coke.
Coke trac is also REALLY slow
purl okay, Coke.
Coke trac.parrot.org/parrot/ticket/261 14:36
(for Infinoid, pge/feather segfault)
Infinoid Yeah, modulus bugs sound a lot less intimidating to me than PGE bugs do
pmichaud note that the failure to build PGE is _not_ a PGE bug.
Coke given that it's a segfault, it pretty much couldn't be. 14:37
Infinoid: of those two bugs, I suspect the one that's stopping PGE is easier to fix.
(because you don't need all of tcl)
I was unable to whittle down #66 to a small test case.
pmichaud what was fperrad's change that broke PGE on feather?
Coke pmichaud: it's in the ticket. moment. 14:38
Whiteknight Infinoid: good catch. The morph vtable should only be taking Class PMCs, not just any random joe schmoe pmc
pmichaud oh, r36176
Coke "Looks like the segfault started happening in r36176."
< set P0["has_exec_protect"], "1"
is probably the culprit (it's no longer present in the config after that change) 14:39
Infinoid Whiteknight: The caller is VTABLE_morph(interp, dest, SELF->vtable->pmc_class); (bigint.pmc:1143)
jonathan pmichaud: Parsing/precedence question. Should these two be the same:
ok (my Num::Multiple $d = 10), "creating a new Num::Multiple";
Infinoid that should be a Class PMC, right?
jonathan ok my Num::Multiple $d = 10, "creating a new Num::Multiple";
pmichaud jonathan: yes, but Rakudo doesn't know how to do item assignment yet.
jonathan OK.
Whiteknight Infinoid: I believe it should be
pmichaud s/do/parse/
jonathan I thought so.
Whiteknight although for a built-in type like BigInt, it might not be 14:40
Infinoid Right, so that class object has overridden a vtable it shouldn't have
jonathan The test is actually testing someone else, rather than that, and will pass if it put in the parens.
*if I
Infinoid Whiteknight: Well, you know this stuff far better than I :)
pmichaud I'm fine with adding the parens to the test. Reads better, also.
Whiteknight can you replace that line with pmc_reuse(interp, dest, SELF->vtable->base_type, 0); ?
Infinoid will do, one moment
Whiteknight thanks Infinoid++ 14:41
I'm wondering why I didn't see that failure myself on this machine
Infinoid Whiteknight: ok, that crashed in a different place 14:42
Whiteknight yay!
can you email me the patches you have and I can just play with it locally?
because apparently there is much more work to do
Infinoid in fact, it got a *lot* farther
Can do. Expect an Official-Looking Stgit Patch Series 14:43
14:45 rurban_ joined
Coke ponders highlighting a ticket each week in TWIP 14:50
rg like perl's todo of the week? 14:51
i was wondering if they had any success with that
moritz they had some (limited) success
Infinoid Whiteknight: sent. 14:52
bbl &
Whiteknight thanks!
dalek kudo: cad0468 | jnthn++ | src/classes/Grammar.pir:
Implement .parsefile method on Grammar.
 14:55
shorten dalek's url is at xrl.us/befujz
Coke rakudo folks: just moved 61744 into your queue. 14:59
pmichaud Coke: Thanks. I suspect it's just a build problem that has since been fixed. 15:02
moderator Parrot 0.9.0 | parrot.org/ | 468 RTs remain 15:05
15:17 NotFound joined
NotFound hi 15:17
purl salut, NotFound.
dalek kudo: 8b8095c | jnthn++ | src/classes/Grammar.pir:
Avoid an infinite exception handler loop by popping a handler before calling Rakudo's 'die'. Resolves RT#62700.
 15:21
shorten dalek's url is at xrl.us/befuno
dalek kudo: 1a2f50c | jnthn++ | t/spectest.data:
Add S05-grammar/parse_and_parsefile.t to spectests.
 15:23
shorten dalek's url is at xrl.us/befunq
Whiteknight I like having all the rakudo commits coming through here. It's cool to see what other people are doing 15:27
15:27 iblechbot joined
jonathan tries to decide if 8b8095c reveals a Parrot bug or not... 15:28
szabgab jonathan, pmichaud ping
pmichaud szabgab: pong (more)
szabgab hmm, why do I ping when you are here talking?
pmichaud szabgab: I received your email -- will write a reply soon 15:29
szabgab great
jonathan szabgab: Same here.] 15:30
pmichaud szabgab: my talk abstracts are www.perlworkshop.no/npw2009/talk/1741 and www.perlworkshop.no/npw2009/talk/1742
szabgab just wanted to say that if you want to discuss it on chat that's great too, I am here
jonathan pmichaud: In 63154 did you mean to change RT ticket status to rejected? 15:31
pmichaud jonathan: is that the :lang(Perl6) ticket?
jonathan pmichaud: aye
szabgab: I will upload my slides from Bulgarian Perl Workshop soon.
pmichaud jonathan: no, I'm going to leave it open for now, so that I'll remember to do the PGE/HLL stuff.
jonathan Essentially though, one of them is basically a kinda Perl 6 tutorial.
Though more in the "run-through of lots of cool stuff" than the "hands on" sense. But it essentially goes from the basics through lots of stuff. 15:32
pmichaud I think having a one-day Perl 6 training course would be excellent.
szabgab those two of pmichaud don't seem to have much overlap with what I would teacg
maybe the the tutorials of jonathan 15:33
pmichaud and no, my talks would not overlap. Since jonathan was already doing "cool things with Perl 6" I didn't submit that
jonathan: how long is your tutorial talk for NPW?
jonathan Checking...
szabgab I am not sure I would (or even can) do cool things with Perl 6
just simple tasks
jonathan It's different lengths in various places I'm giving it! 15:34
Duration: 90 minutes
purl i think 90 minutes is a long time
pmichaud anyway, I think there's room for both a one day tutorial and a shorter 90-minute talk
jonathan szabgab: My talk is not hands on at all.
pmichaud but yes, there'd be some overlap.
jonathan: I'm eager to see your talk slides, btw.
jonathan I'm not even trying to give people time to try stuff - I just want to cover too much ground etc. 15:35
szabgab yeah I am quite sure, on the other hand I have more material than what I need for one day
or I'll have more by that time
pmichaud my frozen perl slides are www.pmichaud.com/2009/pres/fp-perl6
szabgab so I can skip stuff jonathan already covers
jonathan szabgab: I expect we'd overlap a lot, but the audience may be different.
People who want to sit down and play with Perl 6 and be able to have time to try lots of stuff during the tutorial, would be better served by what you're doing.
Mine is more, "here's lots of the cool stuff that you can do today in Rakduo" 15:36
pmichaud yes, that's what mine was.
I did things with hyperoperators and reduction operators and the like.
oh, and hash sorting/output :-)
jonathan But I do go through basic syntax-y stuff too.
Basically so people can follow what comes later. 15:37
I'll get the slides off my laptop and uploaded later on today...
szabgab so I think what I can do is really give them lots of hands-on time with short explanations
pmichaud oh, would this tutorial be during the hackathon?
szabgab yes, it would be one of the days
pmichaud because one of the purposes of my talk is to get people up-to-speed on hacking on Rakudo itself 15:38
(that's also why it's 90 mins :-)
jonathan If szabgab's thing is more exploratory then it'd perhaps get people to the hackathon to learn and play with Perl 6 more, who wouldn't come if it was just being sold as a "hacking on the guts" event, perhaps.
pmichaud it would be better if a Perl 6 tutorial occurred on the first day of the hackathon, then, since by that time I expect we'll be writing settings (prelude) in P6 15:39
szabgab yeah so I thought to do it on the first day so they can go a lot deeper in Perl 6 and then let them out to the hackathon for the 2 other days
Coke for the cool stuff talk, would be nice if the abstract said "and here's how you can have an up to date copy of perl6 on your laptop while you're sitting in here watching me type."
jonathan Coke: I did try this before, but people found it was more a distraction, in a fast-paced talk like the one I was giving.
szabgab I'll cover that in the hands-on 15:40
jonathan Right.
szabgab I might even hand out virtual box images ready made with everything
jonathan Nice!
pmichaud speaking of "have an up-to-date copy" -- anyone have any more thoughts about our recommended "get a copy of parrot" procedure should be for Rakudo? 15:41
Coke (virtual box images) that's a todo for jhorwitz at some point.
pmichaud: fix parrot so that you can build rakudo from an installed parrot.
pmichaud Coke: I have my doubts that this will happen in a timely manner. 15:42
szabgab I can prepare such virtual box right now
in fact I'll need those next week already
particle1 szabgab: trac.parrot.org/parrot/wiki/Parrot...lAppliance
Coke barring that, either doing it as a subdir of parrot or having parrot as a subdir of rakudo is fine.
(though I would just pick one.)
pmichaud Coke: yes, but I'm thinking more of "how does one get parrot", not "where does it go" 15:43
szabgab they won't even need to know that as their already configured IDE will run their code :-)
Coke pmichaud: provide a make target that does an svn checkout of the version you want, along with a diagnostic output if someone doesn't have the svn command line (like for tortoise) 15:44
szabgab let me see how much of that virtual box I can prepare till GPW
pmichaud Coke: but in general I don't have a Makefile until _after_ we have a built Parrot
particle aargh. -0 changes to fix again.
jonathan -O ?
purl well, -O is the logging info
jonathan Oh, -0. 15:45
purl -0
pmichaud szabgab: if you could write up a procedure (or script) that describes how to create the virtual box, we could possibly do virtual box versions as part of Rakudo releases.
Coke pmichaud: then make it part of your Config process?
"I see you don't have parrot... grabbing a copy..."
szabgab pmichaud, I'll do that as much as I can
pmichaud maybe it should be --grab-parrot option to Configure 15:46
Coke if parrot's not in the expected location, die and suggest that option?
pmichaud yeah, that works.
Coke if it is in the expected place, perhaps optionally check that 'svn info' is what you expect. 15:47
(I'd just make that a warning, though.)
pmichaud I'll probably check the 'revision' value of parrot_config
Coke as long as you don't mind building parrot before checking the version is right, that works. 15:48
pmichaud we have to build parrot before we can complete Configure, yes.
but yes, we could do the check before building parrot.
Coke can always do the easy parrot_config check now and make it check earlier if folks complain. 15:49
pmichaud jonathan: is Configure.pl working now for you on Win? 15:51
jonathan: i.e., can I chop out the 'reconfigure.pl' commented-out stuff?
jonathan pmichaud: Yes.
And yes.
pmichaud excellent.
jonathan Took a couple of small patches. 15:52
rakudo: our $x = 42; eval('our $x; say $x;')
polyglotbot OUTPUT[42ā¤]
Coke rakudo: our $x = 42; eval('say $x') 15:55
polyglotbot RESULT[undef]
15:55 Tene joined
jonathan rakudo: module Foo { our $x = 42; eval('our $x; say $x;') } 15:55
polyglotbot OUTPUT[Use of uninitialized valueā¤ā¤Null PMC access in set_pmc_keyed()ā¤current instr.: 'eval' pc 17000 (src/builtins/control.pir:338)ā¤called from Sub 'parrot;Foo;_block20' pc 129 (EVAL_20:59)ā¤called from Sub 'parrot;PCT;HLLCompiler;evalpmc' pc 888 (src/PCT/HLLCompiler.pir:494)ā¤called from Sub
..'parrot;PCT;HLLCompiler;compile' pc 428 (src/PCT/HLLCo...
Coke rakudo: our $x = 42; eval('our $x = 3.14'); say $x
polyglotbot OUTPUT[3.14ā¤]
pmichaud wow, $800 round trip airfare to Oslo. 16:01
I think I should probably book now. :-)
jonathan Wow! 16:03
That's almost cheaper than a beer in Oslo. ;-) 16:04
Whiteknight rakudo: say (1, 2, 3, 4, 5, 6) >>+>> (10, 20);
polyglotbot OUTPUT[112223242526ā¤]
pmichaud I can't imagine that the fares will go much lower than that.
Whiteknight so a hyper operator on the sharp side will extend the last element in the array outward? 16:05
rakudo: say (1, 2, 3, 4, 5, 6) <<+<< (10, 20);
polyglotbot OUTPUT[Non-dwimmy hyperoperator cannot be used on arrays of different sizes or dimensions.ā¤current instr.: 'die' pc 16844 (src/builtins/control.pir:204)ā¤called from Sub '!HYPEROP' pc 15991 (src/builtins/assign.pir:373)ā¤called from Sub '_block14' pc 137 (EVAL_15:56)ā¤called from Sub '!UNIT_START' pc
..18229 (src/builtins/guts.pir:321)ā¤called from Su...
Coke wonders if polyglotbot would look nicer if it actually rendered [NL] as a newline. 16:06
jonathan Whiteknight: Yes. We also have a ticket for that last bug there. :-)
Coke (perhaps only if there was more than one in the send)
pmichaud it's kind of nice that .say for 1..20 doesn't produce 20 lines of flood, though. 16:07
rakudo: .say for 1..10
polyglotbot OUTPUT[1ā¤2ā¤3ā¤4ā¤5ā¤6ā¤7ā¤8ā¤9ā¤10ā¤]
16:11 bkuhn joined
particle rurban: ping 16:14
i may need to create a new vm and install msvc6.
dalek kudo: 45cf376 | jnthn++ | src/builtins/op.pir:
++ and -- in both their prefix and postfix forms now use infix:<=>, which means they do read-only checking properly. This corrects RT#60380, but does cause some failures in for.t since <-> is not implemented, but accidentally worked before; will fix that in my next commit.
 16:16
shorten dalek's url is at xrl.us/befurf
dalek kudo: c66322e | pmichaud++ | src/builtins/match.pir:
Add 'make' function (partial RT #63152, chrisdolan++)
 16:21
shorten dalek's url is at xrl.us/befuru
16:25 davidfetter joined
rurban particle: yes 16:25
16:27 kj joined
pmichaud oh, the hackathon went to three days? 16:28
I thought it was only two.
jonathan Me too
pmichaud oh well, I'm missing the third day now. 16:29
since I just booked my flight to return on the 20th.
jonathan Ah.
I thought it was only 2, but didn't book a flight yet...
pmichaud 2 days of hackathon is probably all I can handle anyway. :-P 16:31
jonathan Exhaustion is good, no? ;-)
szabgab sjn, you should send email to everyone that the hackathon is 3 days long!
particle rurban: seems you've marked todo some passing tests with msvc. i have a feeling it's msvc6-only that they should be skipped on 16:35
i'm working on a patch, but would appreciate a sanity check
rurban: can you tell me how t/op/arithmetics.t failed for Inf? 16:36
rurban trac.parrot.org/parrot/changeset/36579/ ? msvc6 perl Configure.pl && nmake test 16:44
But it's enterily msvcrt.dll specific (the shared libc on windows) 16:46
nopaste "particle" at 76.121.106.245 pasted "rurban: arith patch for msvc6 testing" (78 lines) at nopaste.snit.ch/15582
rurban You think it's the compiler version, not msvcrt? will check 16:47
particle yes, those were todo-passes here
rurban I saw your change enabling the failing -0 in r36173 16:48
I'll check both, the compiler version and the msvcrt version. If we have to workaround the print -0 we have to get at the msvcrt version on Configure anyway.
particle yes, because it didn't fail :)
yeah, right. 16:49
thank you.
dalek kudo: bb2cdb7 | jnthn++ | src/ (2 files):
Implement <-> (lambda that makes things rw), which gets S04-statements/for.t passing again.
rurban but you had a newer msvc or msvcrt
particle i'll review the shared blib patch
shorten dalek's url is at xrl.us/befuvd
rurban I have to buy some food for 20 mins
particle yes, i'm sure i do, running vista x64 and msvc2008
~~
pmichaud jonathan: does the <-> affect only those parameters that don't already have an 'is' decl? 16:50
Infinoid Whiteknight: I'm working through the bigint failures by applying the same fix to other places in bigint.pmc, it's going pretty easily. 16:51
Whiteknight that's good. It should be pretty smooth
16:51 Theory joined
rurban particle, I remember now: It canot be the msvc6 comnpiler because I get the very same results for mingw also 16:51
jonathan pmichaud: No, all...
Hmm.
particle ah, hrmm. msvcrt it is, then. that should be fun to fix :( 16:52
jonathan pmichaud: Though we don't have a way to differentiate the two.
(In the signature, we always pass along :readtype('readonly')
pmichaud how do you mean?
16:52 mikehh joined
Infinoid I'm starting to wonder if I should just do a search and replace all instances in this file, though. That way I won't have to worry about incomplete test coverage 16:52
pmichaud anyway, that's why I hadn't implemented <-> yet.
jonathan OK
pmichaud we should at least add a (failing) test for that so we come back and fix it. 16:53
jonathan I only did it because for.t started failing. ;-)
(After I fixed ++ and --)
Yeah, let me see what other tests we have...
pmichaud right-- that's why I hadn't done that fix for ++/-- yes
*yet
jonathan Heh, it's one big heap of avoidance. ;-)
pmichaud well, I didn't really like the approach of "make everything rw" 16:54
jonathan It's closer than "do nothing". :-)
pmichaud agreed.
(phone) 16:55
jonathan hmmm...I figured we'd have some tests explicitly for pointy blocks somewhere...
Hmm, maybe not
Infinoid Whiteknight: Would fixing Parrot_default_morph() to use base_type be reasonable? Or would it break other things? 16:56
Whiteknight maybe. If it's a Class, it should use the class type. Otherwise it could probably use the basetype 16:57
NotFound Calling 'abort' will be the most reasonable way X-) 16:58
Infinoid Yeah. Because crashing gracefully is so much more important than *working* :)
NotFound Interesting concept of 'gracefully" 16:59
Infinoid if you're gonna segfault, you might as well do it on purpose 17:00
particle you're checking base_type rather than isa or can or does?
HCF
NotFound particle: checking what? isa Cloneable? 17:02
particle just making sure it's correct. base_type was historically used for things it shouldn't have been 17:03
NotFound isa Morphable?
What things do that? Some PMC? 17:04
particle it was in imcc and in pmcs, yes 17:05
much has been rewritten and improved, though. hopefully corrected, too :)
NotFound Then the correct way IMHO is to override morph in that PMCs to throw "Cannot morph" or something
Infinoid in this case, I'm using it to get the Class object for bigint and rational PMCs.
ask Whiteknight why :) 17:07
NotFound Whiteknight: why?
I'm obedient X-)
kj nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl well, nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
NotFound why?
nopaste "kjs" at 193.1.104.7 pasted "nmake realclean && perl Configure.pl && nmake: no good here." (31 lines) at nopaste.snit.ch/15583 17:08
NotFound purl: why is 42
kj I have a link error on windows, I think because there's spaces in the folder name. 17:09
NotFound Silly not
bo
kj: I think that this problem is already reported
kj NotFound: oki
just wanted to check here
NotFound And the answer is: autotools have problems too, we're not alone! 17:10
jonathan pmichaud: Got something that I think will fix it, as well as a test case...smoking. 17:11
rurban particle: we should really write a Configure check for the print -0.0 win32 issue 17:16
NotFound There is some reason for the several Parrot_str_not_equal(....) == 0 or they are just an artifact of search and replace? 17:17
rurban kj: sorry. double quoting introduced again
jonathan The latter, I believe.
Infinoid I'm getting negative zero failures on linux in trunk, now. 17:18
pmichaud jonathan: if you don't end up with an easy fix, I think I can get to it. I'm thinking perhaps we shouldn't default readtype when no read trait is set.
afk for a bit 17:19
17:19 bacek joined
nopaste "rurban" at 212.183.57.78 pasted "test msvc fix tt276-msvc-linking.patch" (157 lines) at nopaste.snit.ch/15584 17:20
jonathan pmichaud: That's what I've done, and it seems to work. Passed all S06...
Infinoid rurban: r36579 gives me failures in t/op/arithmetics.t on linux/x86-64, was this expected or should I provide more info? 17:21
Whiteknight the whole morph thing is a mess <---- That's why
rurban nope, not expected
Infinoid, can you nopaste?
nopaste "Infinoid" at 96.238.213.50 pasted "t/op/arithmetics.t output on x86-64 linux" (62 lines) at nopaste.snit.ch/15585 17:22
rurban whoa! attempt to access code outside of current code segment. that was not me! 17:24
Infinoid reverting it causes the test to pass
rurban the failing test 8 is my failure 17:25
Infinoid maybe the test was rewritten in a way to reveal some other issue, I dunno
rurban ok. so itļæ½s mine. wait a sec
Infinoid I'm clueless about negative zero
dalek kudo: 2e70f2d | jnthn++ | src/ (2 files):
Improve handling of <-> so any traits explicitly set in the signature are not overridden with rw.
shorten dalek's url is at xrl.us/befuy9
rurban It's a posix math thingy. We require to print -0.0 as -0
jonathan OK, I need to take a break...back later. 17:26
NotFound thinks about developping a floating point format with negative NaN
Infinoid how could you tell the difference between that and positive NaN?
NotFound Infinoid: that's the beauty of that design 17:27
Infinoid you could use negative NaN the way some perl 5 code uses "0 but true"
NotFound Will look nice: a = NaN but negative :) 17:28
Infinoid "They're just like normal NaN! Except they're EVIL."
NotFound Wait, NaN is already evil enough :D
Infinoid Well, this is the anti-NaN 17:29
It looks just like normal NaN. Except you spell it in reverse
NotFound SuperNaN, the number of steel
not ok 7 - negate -0.0 not ok 8 - negate a native number 17:32
pmichaud jonathan++ # excellent 'is rw' patch
rurban particle: see smolder.plusthree.com/app/public_pr...ails/17922 for the same mingw error in the -0 test. so it's not compiler specific. 17:33
shorten rurban's url is at xrl.us/befuz6
rurban Infinoid: you are not alone, win32 reports the same error on smolder 17:34
17:36 davidfetter joined
mikehh I just did a svn up from r36575 to r36579 17:40
rurban particle: did you see my tt238-install-devel.patch for you? 17:41
particle is back
mikehh Query do I need to do anything re make or such as the only files affected are in t and languages/pipp
rurban just make
particle Infinoid, rurban: that failing test is missing some code, and an 'end' statement, so you fall off the code segment 17:42
rurban oops
particle my previously nopasted patch fixes that
rurban ah, I see!
I'll write the configure check now to finalize this mess. What should the HAVE_PRINT_NEG_ZERO name be? 17:45
particle HAS_NEGATIVE_ZERO? 17:47
rurban okay
particle think that can fit in with an existing configure step? 17:48
dalek kudo: d44d19c | pmichaud++ | src/parser/grammar.pg:
Add parsing of $/ as a param_var (RT #63152).
shorten dalek's url is at xrl.us/befu3h
Infinoid particle: somehow I think that needs a "CAN_" prefix 17:51
CAN HAS NEGATIVE ZERO? 17:52
moritz had the same idea, but managed to keep quiet ;-)
Infinoid often fails at that. 17:53
davidfetter QUIET FAIL
rurban look at config_lib.pasm: there are just HAS_stuff definitions
particle you'll need to check LOLCONFIG.pasm 17:54
Infinoid Whiteknight: Ok, tests are passing and I think this is ready to merge. Are you fiddling with the patch series I sent you, or can I commit?
rurban I'm more for lowercase, like has_socklen_t: has_neg_zero or has_neg_0 17:55
Whiteknight you can commit if you're comfortable with it
thanks Infinoid++
particle has_negative_zero is perfectly clear 17:56
and does match has_dynamic_linking etc 17:57
rurban and the .pm would be auto:neg_0
Infinoid merge complete in r36585.
dalek rrot: r36580 | Infinoid++ | trunk/src:
Apply r36396 from vtable_morph_change branch.
 17:58
rrot: r36581 | Infinoid++ | trunk/src:
Fix some fallout from r36396, related to upgrading data types through morphing, bigint pmcs and rational dynpmcs.
 17:59
particle i'd prefer auto::neg_zero to not confuse people with o, O, and 0
dalek rrot: r36582 | Infinoid++ | trunk:
Apply r36514 from vtable_morph_change branch.
rrot: r36583 | Infinoid++ | trunk/src/pmc/undef.pmc:
Apply non-merge portion of r36517 from vtable_morph_change branch.
rrot: r36584 | Infinoid++ | trunk/src/pmc:
Apply r36540 from vtable_morph_change branch.
 18:01
rrot: r36585 | Infinoid++ | trunk/src/pmc:
Apply r36562 from vtable_morph_change branch.
 18:02
moritz is that manually merging single commits from a branch? 18:03
Infinoid svn updating the branch against trunk screwed things up entirely, so I had to cherrypick it. After that, I kept the patches separate in stgit, because it makes them easier for me to understand. 18:04
I realize committing them separately is not the normal procedure, but I really *really* hate when I'm doing a bisect to find some issue and end up staring at some huge incomprehensible branch-merge commit 18:06
if it bothers people, I can summarize in the future.
Whiteknight it's fine by me 18:07
I'm just happy to have the damn thing merged
Infinoid now we can move on to breaking bigger and better things :)
rg infinoid: usually you still have the separate commits in the branch, but i admit they're harder to find and probably even harder for bisect to figure out. 18:08
Infinoid rg: Yeah, it basically means you have to start bisecting all over 18:09
18:14 Phurl joined
Phurl hey all 18:14
i have started to branch the parror/pipp into code.google.com/p/rdfintrospector/s...uages/pipp 18:15
shorten Phurl's url is at xrl.us/befu6g
Phurl so I can make changes
but is it just the xslt 18:17
Coke . 18:18
particle Phurl++ 18:20
Phurl :)
NotFound Someone is planning to make something with ecmascript?
Coke last change to suggest a name more clever than "apl-parrot"
Infinoid A Parrot Language
Coke "invalid project name" 18:21
Phurl hey, how many of these parrot languages have an xml interface?
NotFound Coke: don't liked my sugggestion of some days ago?
Phurl is is possible to program parrot directly from xml?
Coke NotFound: resend?
purl resend is probably the thingy that handles incoming messages to the list.
NotFound Coke: apalot
Coke hurm. no. =-) 18:22
Phurl so my idea is quite simple 18:23
to have an xml interface to write parrot code
at the lowest level
basically an xml assembler
NotFound travelingluck.com/Asia/Philippines/...palot.html
shorten NotFound's url is at xrl.us/befu78
Coke I think that's a hammer in search of a nail. 18:24
Phurl Coke: yes of course
Infinoid Phurl: ok, so you use xml instead of pir?
Whiteknight Coke, where you moving apl to? Squawk?
Phurl in a way
Coke but you could certainly do that.
NotFound Coke: seems that's a beautiful place
Phurl right now there is an xslt from phc to something
Coke Whiteknight: no, I'm creating a new repository for it. I don't like the idea of squawk. =-)
Whiteknight Coke: Well it doesn't like you either
Coke (it's not that hard to setup an individual project on googlecode) 18:25
Coke proffers: "par apl egic".
Phurl It generates an XML representation of a PAST data structure.
according to the docs
Infinoid Coke: hah!
Phurl and the XML from the PAST is then transformed to perl or something
i just think it would be good to have an native standard xml for parrot 18:26
particle coke++
Infinoid APLeptic
Phurl we can talk about this wehn I have a better example
Coke Infinoid: parapleptic is a word too.
Infinoid ooo
particle P
NotFound Phurl: no need to be declared as standard to be done.
particle maybe that's what i'll call the parrot port of R
(which is an open-source version of S)
Infinoid someone else can have Q 18:27
NotFound And the we can add a Q&A
then
Whiteknight particle: you should call it ArrrrR, and the icon can be a picture of a pirate with a parrot on his shoulder
Coke goes with paraplegic.
kj ArrrrR++
Infinoid Coke: it seems unlikely that anyone else would have taken it :) 18:28
NotFound apl plus enhanced professional edition
Infinoid APL2009
NotFound apl vista
particle pipp svn? 18:29
Coke code.google.com/p/paraplegic/
particle pipp repo?
hrmm, we need to move pipp out someday
Whiteknight aplsaus
particle i guess that's waiting to follow rakudo's lead
partcl?
purl rumour has it partcl is tcl on parrot or code.google.com/p/partcl or slow and a memory pig and pretty much not usable
Whiteknight haha, purl is pretty negative about partcl 18:31
particle november?
purl november is at www.november-wiki.org/ or use.perl.org/~masak/journal/37212 or github.com/viklund/november/
18:31 ask joined
Phurl NotFound: well lets take a look at this 18:32
particle perl6-examples?
Phurl code.google.com/p/rdfintrospector/s...st_nqp.xsl
shorten Phurl's url is at xrl.us/befu9d
Phurl this is the past xml standard
"It generates a PIR-script that creates 18:33
a PAST data structure and runs it with the help of a PCT::HLLCompiler."
i mean the transformation
so it would be nice to either :
1. have a native parrot xslt language
2. have the ability to write this past directly as a language input and not use xslt
just an idea i had today
plus you can see it is very primitive 18:34
the xslt is 50 lines
particle prophet?
purl well, prophet is a distributed property database or fsck.com/~jesse/talks/2008/yapc.asi...rophet.pdf or syncwith.us
NotFound Phurl: looks like egypcic hyaerogliphs to me
Phurl haahh 18:35
particle has set up an ubuntu vm with mod_parrot parrot perl6-examples pugs sd november partcl prophet rakudo repositories 18:38
Phurl code.google.com/p/rdfintrospector/s...p/past.out 18:41
shorten Phurl's url is at xrl.us/befva9
Phurl here is the past created atm
it is just perl
i am working on porting the mediawiki parser to parrot
so that we dont need to deal with this gawdauwfull php
so, i think that when parrot has a very optimized repreentation of the program 18:42
we should be able to emit c and then compile that again using a profile driven compiler for more optimization 18:43
particle parrot doesn't emit c
Phurl not yet
particle i don't know that it ever will
Phurl ok
Coke (partcl) most of those factoids came from me.
Phurl who is particle? 18:44
particle particle?
purl The most abundant particle in the universe is the moron. or spin 1/2, charge 2/3 or jerry gay or a boson. or a bozon. or a bogon or one bad mobo. or full of lies or mailto:jerry.gay@gmail.com or thinking that others are boring
Phurl are you a person or bot?
particle not a bot
Phurl good
particle pets purl 18:45
purl bites!
particle bots don't like me.
Infinoid I am not a bot, no matter how many perl scripts I may be running.
Phurl i just think that in the end, any jit or runtime could be optimized again with profile driven compilation
particle yes, when we finally have profiling tools 18:46
rurban Interesting, first write of has_negative_zero check works okay on all platforms. need a test now 18:47
Coke or a jit.
Tene is a bot.
Coke tene, fix my partcl bugs. :P 18:48
particle sheena is a punk rocker
Tene svn rm partcl
Phurl ok
particle that's a big hammer!
Phurl well lets just get first things first
jonathan back from nomming and shopping 18:49
Coke has a nagging suspicion jonathan has an RT ticket that is closable. 18:52
jonathan has closed a double figure number of them today. ;-) 18:53
Maybe just not in the queue you're thinking of. 18:54
Coke yah, this was a parrot bug. ah well, it'll come to me.
nopaste "Infinoid" at 96.238.213.50 pasted "4 places in the bigint pmc and the rational dynpmc sources that are not properly tested (if tested they would have crashed during the morph vtable branch stuff)" (45 lines) at nopaste.snit.ch/15586 18:55
jonathan Coke: Got an ID? 18:56
Or you just want me to review those that were assigned to me?
Infinoid In the above nopaste, those changes were committed along with r36581, but I had to use grep to find them, because make test didn't hit them.
particle steps away for yet another interview & 18:57
dalek rrot: r36586 | whiteknight++ | trunk/docs/book/ch03_pir_basics.pod:
[Book] More detail about filehandle PMCs and their methods.
 19:00
Infinoid ooh, release in 6 days. 19:01
dalek rrot: r36587 | Infinoid++ | branches/vtable_morph_change:
This branch was merged back into trunk; kill it.
Whiteknight Infinoid++. I can't say that enough today
I would so much rather be writing code then fighting with revision control software 19:02
Infinoid Whiteknight: I don't mind, but in this case, I did it now only because I forgot earlier
Whiteknight this kind of stuff always makes me hesitant to create new branches 19:04
Infinoid I usually just branch locally. It's part of my overarching strategy of pretending git-svn (and by extension, svn) don't really exist. 19:05
Whiteknight Well la de da mr super computer man
Coke jonathan: no, I don't have an id. 19:07
jonathan Coke: OK.
Will glance over my assigned tickets later on.
Coke but yes, please review any parrot ones you have assigned. =-)
(even if only to give them up if you're not going to get back to them.)
dalek tracwiki: v50 | coke++ | WikiStart 19:14
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...version=50
tracwiki: v1 | coke++ | SmolderTaskList
tracwiki: trac.parrot.org/parrot/wiki/Smolde...?version=1 19:15
shorten dalek's url is at xrl.us/befvfd
19:19 rurban_ joined
Infinoid driving around today is like halfway between playing spy hunter and playing asteroids 19:20
rurban BTW: adougherty came with two more floattypes to support for cross-platform native_pbc. I found also one more. 0-6 for now. See trac.parrot.org/parrot/ticket/308 19:23
Infinoid Yeah. Wouldn't it be nice if pbc had a standard type, so you only had to worry about converting to and from that, instead of worrying about converting from 5 other platform types to your own? 19:25
Coke ... isn't that whatever's in $N ?
rurban stringification might be needed 19:26
Infinoid That works for me. Picking the highest precision type and using that works too
rurban but maybe stringification only as fallback when not on the same platform
too keep the reader speed.
Infinoid Wouldn't that mean you have to store both the native type and the stringified one when you generate the .pbc file?
rurban yes 19:27
Infinoid ok.
rurban just an idea.
Infinoid It works
rurban For now I just print a "unsupported floatval conversion" error or such
pmichaud Coke: I'd like a commitbit for APL.
Infinoid I'm not an expert in floating point stuff anyway, I would just prefer converting to/from a "standard" type rather than converting from *every* type 19:28
NotFound BTW, what if a pbc contains an 64 bit INTVAL that does not fit in 32 bits and we are converting to a 32 bit INTVAL platform?
Infinoid If any of the high bits were set, converting it to a bigint would seem nicer than hacking off the extra bits 19:30
I don't know what's currently done.
NotFound Converting to a big int a thing assigned to an integer register is not a possibility.
dalek kudo: 4367761 | jnthn++ | src/ (2 files):
If optional parameter not supplied, don't do type checks. Resolves RT#61528 and RT#63048.
 19:31
shorten dalek's url is at xrl.us/befvh4
dalek kudo: 50a61ae | jnthn++ | src/parser/grammar.pg:
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/befvh6
jonathan commit message fail 19:33
Coke NotFound++ 19:35
rurban currently we fetch the 64bit in the right endian style, and pick it apart, to get our native IEEE 754 number
In true libc-hacker style. Hard to support
19:35 chromatic joined
rurban see sr/packfile/pf_items.c 19:36
well, 64bit not yet, but you get the idea.
NotFound 32 bit must ne enough for everyone X-) 19:37
Coke rurban: you might be a good person to look at: 19:38
rt.perl.org/rt3/Ticket/Display.html?id=44317
rurban Ah, thanks. This maybe explain some weird alignment problems 19:40
I steal it.
19:44 maettu joined
dalek rrot: r36588 | coke++ | trunk/DEPRECATED.pod:
Add another notice so we can rip this out before 1.0
 19:44
rurban I also want to rename readbc and loadbc to pbc_read pbc_load, to be added to DEPRECATED.pod. Who decides this? 19:47
trac.parrot.org/parrot/ticket/266 19:48
Coke consensus decision. 19:49
not Parrot_pbc_* ?
19:50 Eevee joined
Coke rurban: you also might want 41893 19:51
Infinoid PDD13 means those are going to change at some point anyway
Parrot_pbc_* +1 19:52
Coke pmichaud: ping.
or jonathan: ping
jonathan Coke: pong
Coke (is rt.perl.org/rt3/Ticket/Display.html?id=43419 closable now?)
(and the corresponding TT)
rurban yes, we can close RT#41893 soon. 19:53
dalek rrot: r36589 | allison++ | branches/kill_pccinvoke:
[pcc] Bringing the kill_pccinvoke branch up-to-date with trunk r36588.
rurban But I'll test it with the release
jonathan Coke: I'll let pmichaud confirm it, but given it now has a trac ticket, one would guess so...
rurban its the same as the FHS ticket I submitted. RT#56996 19:54
Coke if it's a duplicate, we can merge the tickets.
jonathan: just because there's a TT doesn't mean the issue is resolved.
rurban not yet, it's a little bit different 19:55
jonathan Coke: OK, but if there's a TT tracking it instead, do we keep it in both ticket systems?
rurban and allison changed a bit lately so it became fragile. I really want to test it properly
Coke I'd rather just confirm it's closed and close it in both places. =-)
jonathan Coke: OK. Well, pmichaud can answer that more than I can since he filed it originally. :-) 19:56
rurban But now my big negative_zero changes cause other tests to fail. I'll nopaste.
nopaste "rurban" at 212.183.50.58 pasted "HAS_NEGATIVE_ZERO print fails with -0, why?" (28 lines) at nopaste.snit.ch/15587 20:00
rurban I'll disassemble this...
pmichaud Coke: checking RT #43419 20:02
dalek rrot: r36590 | whiteknight++ | trunk/src/multidispatch.c:
[MMD] Tweak the tuple generation code to accept invocant adverbs, in anticipation of some Parrot_PCCINVOKE unifications
pmichaud Let's close it. I did re-run the test program and it appeared to work. (more)
if I run into more issues, I'll file a new ticket with more details.
dalek rrot: r36591 | coke++ | trunk:
Move bug report from RT here in preparation for operation LeaveTheNest
 20:04
kudo: b2e7ac9 | jnthn++ | src/parser/actions.pm:
If we use is also, we need to check the class we're trying to extend already exists.
 20:06
shorten dalek's url is at xrl.us/befvqw
Coke pmichaud: danke. 20:07
jonathan pmichaud: Think getting down to 250 tickets is within reach now. :-) 20:08
(Not today, but soonish.) 20:09
pmichaud jonathan: excellent. I have a batch to attack also, as soon as I can get the build process back up to speed.
jonathan perl6: role A::B {}; A 20:10
polyglotbot OUTPUT[invoke() not implemented in class 'NameSpace'ā¤current instr.: '_block14' pc 59 (EVAL_19:38)ā¤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)ā¤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)ā¤called from Sub 'parrot;PCT;HLLCompiler;evalfiles'
..pc 1275 (src/PCT/HLLCompiler.pir:688)ā¤called fr...
rurban Parrot_pbc_: Okay, now I only have to check how to properly deprecate a func (macro I know)
jonathan pmichaud: What should happen here?
dalek rrot: r36592 | fperrad++ | trunk/compilers/pirc:
[pirc] svn ignore pirc.exe
 20:11
pmichaud jonathan: I don't know -- I'm thinking we need a spec clarification.
jonathan Right.
pmichaud however, it should be smart enough to recognize 'A' as a namespace instead of a listop.
and thus treat it as a term 20:12
jonathan pmichaud: STD.pm recognizes it as an undefined name but that's a warning...
Aye.
Invoking it is wrong.
But that'd mean we probably need to register it or detect it in some way.
Coke rurban; open a ticket if one doesn't exist already. Add an entry to deprecated.pod pointing back to the ticket.
jonathan (But we don't want to treat it as a type name, so that won't fly.) 20:13
rurban The ticket is TT#266
jonathan writes to p6l
rurban Didn't want to note the old name also somewhere? 20:14
20:14 ask joined 20:15 ask_ joined
Coke hopes tt #316 is a duplicate. 20:15
jonathan pmichaud: Written.
Coke rurban: your note should mention the old one that is going away and the new one that is replacing it.
For bonus points, we should add the new one NOW and make the old one just invoke the new one. 20:16
that eases the upgrade pain slightly.
rurban #316 is mine. I'm just working on the fix.
Coke (presuming of course that there's consensus in the first place.)
NotFound rurban: take ownership, then 20:17
jonathan yawns and ponders that perhaps that's enough bugs quashed for one day 20:18
rurban I'll fix the symptom now first. 20:19
NotFound I'm looking at TT #300 but don't see any clear path to work on it. It is easy to mark the exception handler as been in the process of catching, but don't know how to unset it. Any ideas? 20:22
s/been/being
dalek rrot: r36593 | rurban++ | trunk/t/op/arithmetics.t:
[t] Fix the previous syntax error (forgot end) and the wrong test.

Change print to say.
purl dalek: that doesn't look right
rrot: r36594 | whiteknight++ | trunk:
[DEPRECATED] Add note about deprecating .HLL_map so we can have it ripped out by 1.0
rurban p_u_r_l: what does not look right there? 20:24
Infinoid Change purl to broken. 20:25
purl Infinoid: that doesn't look right
Infinoid Funny, looks good to me.
rurban who knows this beast? 20:26
Infinoid purl, owner? 20:28
purl i think owner is Masque
rg notfound: i still think raising an exception should remove all handlers up to and including the called one from the handler stack
Infinoid rurban: t/op/arithmetics....ok 20:29
chromatic prove -l t/op/arithmetics.t
rg i've discussed this with tene some time ago, but i guess he never got around to doing anything.
chromatic Sorry, I mean prove -v t/op/arithmetics.t
NotFound rg: given that the handler is the continuation that does the handling, removing then before his usage is not easy
Tene rg: if you remove the exception handlers, how would they be added back when someone resumes that exception?
We even use exceptions for warnings... 20:30
Should a warning wipe out all exception handlers in place? 20:31
rg imho the continuation would have to know about that. my problem is i don't know the code, just what i think would be right.
rurban I just attached my big neg_0 patch to TT# 313. trac.parrot.org/parrot/attachment/...eg_0.patch
shorten rurban's url is at xrl.us/befvw2
Tene rg: I've looked into it quite a bit, but I haven't been able to come up with a non-horrible solution.
NotFound rg: to know about what? 20:32
rg the continuation that is stored with the exception would need to know which exception handlers need to be restored
tene: do you know any other language that has resumable exceptions?
NotFound rg: the continuation is not stored with the exception, as far as I know 20:33
Tene NotFound: it is.
exception['resume']
NotFound Do we talk about the ExceptionHandler continuation or about the resume continuation? 20:34
rg the resume continuation. is the handler implemented as a continuation aswell?
Tene rg: I have no idea how to construct a continuation that can do that.
Maybe a special subclass of continuation, possibly... 20:35
NotFound Most languages don't have resumable exceptions because they want to avoid to care about all those things.
Tene We also use exceptions for loops. Those EHs are called repeatedly without resuming, so the resume continuation can't be what does it. 20:36
NotFound The ExceptionHandler isa Continuation
Tene Unless we require every handler there to know about every other handler inside it and generate code to reconstruct it every time it catches something. 20:37
NotFound pmclass ExceptionHandler extends Continuation need_ext {
Tene Which is absurd. We shouldn't require EHs to reconstruct other EHs just to not break.
rg i'm getting the impression we're using exceptions for too many things 20:38
Infinoid ETOOUSEFUL
Tene They're the generic mechanism for handling exceptional flow control. 20:39
jonathan use.perl.org/~JonathanWorthington/journal/38463 # rakudo day report
NotFound A possible hackish solution: store a pointer to the ExceptionHandler in the Exception, and mark it as finished when getting the 'resume' (assuming that is getted in order to invoke it)
Tene 'return' is a special case of exception
rg return, break, continue and a number of other things, i know :/
NotFound Maybe we must rename ExceptionHandler as TaskHandler, or something 20:40
Tene tasks are different
erm.. nm
NotFound Because a lot of the things it does are not exceptional at all.
ThingHandler X-) 20:41
rg FlowHandler maybe?
Tene they're exceptions to normal program flow
Coke control flow exceptions 20:42
rurban hmm: mingw x == -0.0 uses fucompp. FPU code, looks okay to me.
Coke Doesn't need a rename, IMO. 20:43
dalek rrot: r36595 | allison++ | trunk:
[pcc] Merging the kill_pccinvoke branch into trunk for r36508 to r36588. Simple
NotFound I don't see his exceptionality, they are continuations like almost any other part or parrot flow control.
20:44 maettu left
Tene I'm still not sure exactly how rg is wanting things to work. 20:44
rurban my -0.0 error is earlier, not in print.
dalek rrot: r36596 | allison++ | branches/kill_pccinvoke:
Removing calling conventions refactor branch from the repository
Tene All of his proposals seems vague to me, and the interpretations I come up with seem to break many things. 20:45
Tene rg: can you create some example PIR with explanations of how you would want it to work?
What you're needing to do?
rg still i believe any handler that is being skipped in the search for the handler of the current exception (be that flow control, user or internal exceptional condition) is not relevant to any exception thrown later on, so it can be removed from the search/stack. the only problem we're having is what to do with the exception's continuation
Tene if you remove it, what will put it back? 20:46
dalek rrot: r36597 | allison++ | branches/pcc4:
Creating branch for refactoring calling conventions, removing the old PCCINVOKE and streamlining the rest.
rg if we disregard the continuation: nothing ever.
Tene I really think that having an exception mutate its call stack is a bad idea. 20:48
Still thinking, though.
rg i could try to find the time to come up with some examples, but it could be hard to do in pir. 20:49
NotFound Probably will make more sense to kill the handler stack entirely, not just until the current. 20:50
rg notfound: no, you don't want an exception inside a handler terminate your whole script ;) 20:51
NotFound rg: handler stacks are contextual, not for the whole script
rurban I see that ruby uses it own vsnprintf.c for this win32 -0.0 issue: redmine.ruby-lang.org/issues/show/6
rg oh so you meant the current context's stack. that may be ok. 20:52
NotFound But the problem is that this way will complicate the resume 20:53
Tene NotFound: resume isn't the only case. also look at loops. 20:54
you don't want "next" to remove your loop handlers.
rg actually i think you might. 20:55
NotFound You will need to re-push them... doable, but surely slower.
rg you definitely want it for break and return, therefor for next you could just jump *before* the push_eh
Tene That's horrible. 20:56
rg s/break/last/ to stay in perl lingo ;)
Tene And what if you have a loop inside of a try block?
rg what about that? 20:57
Tene you'll remove that EH too?
NotFound Tene: there are noy such things at pir level, they aren't?
Tene NotFound suggested removing all EHs in the call chain. 20:58
NotFound: it's just another EH.
rg if you throw an exception that would make you leave the loop, you definitely want the loop's handlers removed. for a next you wouldn't get as far as your custom exception handler, so it won't be removed.
NotFound Tene: if is in an inner sub, they have his own context
Tene so you're removing all the handlers in the current PIR sub? So refactoring an inner loop in PIR into a separate sub will change the behavior of the outer EH? 21:00
NotFound If I understand well, the wat to implment that type of things in HLL will be that the try block handlers and the loop handlers will be in different levels of inners
s/wat/way 21:01
Anyway I don't like much that approach, just say that will be cleaner to remove the whole context handlers rather than just until the current. 21:03
Tene This sounds horrible and hackish to me, and rather significantly breaks resumable exceptions.
And "Many langauges don't use resumable exceptions" isn't a very good argument to me for breaking it.
NotFound Yes, we have it and we must handle it well. 21:04
rg can anyone point me at some documentation how continuations work? i.e. what happens when a continuation is passed to (and called in) a different context?
NotFound It continuates ;)
Tene There's a related problem right now in that when you return a continuation and invoke it later, the EHs aren't there anymore. 21:05
rg so you're saying it already doesn't work right? ;) 21:06
Tene I had a vague idea once for fixing that with a significant refactor, but I don't remember it anymore.
rg: so your solution is to break it even more?
rg no, just in a different way
NotFound Tene: there is some test for that?
Tene NotFound: I think that rg posted an example to the list a while back that helped me notice that while fixing it. I'm not sure if it's in a test. 21:07
rg but no, i'm not suggesting to break it
rather i'm thinking the fix may be the same for both problems 21:08
Tene But you're not actually proposing a fix thought, right? Just suggesting that there might be one? 21:09
rg all i did so far was write a short example here in irc, sorry.
Tene Not trying to be confrontational. I just don't much trust my memory. Trying ot keep things straight.
Coke tickets are cheap. open one. 21:10
rg wonders if there wasn't one already
rg can't find one. 21:13
pmichaud Coke: ping
NotFound I'll try the hackish way of storing a pointer to the current handler in the exception
Tene NotFound: "current handler"? Explain more? 21:14
Coke pmichaud: pong
NotFound Tene: The ExceptionHandler that is running
Tene NotFound: where are you going to get that information?
NotFound Tene: storing it while throwing 21:15
Tene NotFound: from the throw opcode, where are you going to get the "current handler"?
it's not in the interpreter, it's not in the context, it's not stored anywhere afaict. 21:16
NotFound Tene: will be shorter to write and show the code than to explain it ;)
rg i was also thinking that HLLs could maybe use pushmark/popmark to keep track of their handlers, but i didn't get around to checking that and it assumes that the generated code is correct (i.e. won't help when coding the HLL)
Tene If you can get the "current handler", it would be easier to just modify exceptionhandler.pmc's can_handle to decline to do anything if it's the "current handler"
NotFound Tene: yes, and precisely because I don't have it in any part, I must to store it somewhere 21:17
Tene NotFound: but where are you going to get it from to store it? 21:18
NotFound Tene: the code that choose the handler know the exception and the handler it selects.
Tene NotFound: do you mean that when you decide to invoke a handler with an exception as its argument, you'll store the handler in that exception? 21:19
That won't help.
rg notfound: what are you working on?
Tene The problem is when we throw a *new* exception.
NotFound rg: I look for a fix to TT #300
Tene try { throw A; } CATCH { throw B; }
pmichaud Coke: are you moving pynie out of the parrot repo? if so, I think I'd like to move it to github.
Tene Storing the handler in A doesn't help when we're throwing B 21:20
rg notfound: yes, but what do you need that for? can you wait for a more general solution? 21:21
NotFound Tene: It needs to help in that case?
Tene NotFound: there are no problems with rethrowing an exception.
NotFound rg: sure, I can wait for a few seconds...
Timeout X-) 21:22
Tene NotFound: in that case, A stores the same iterator that was originally used when looking for a handler, and just picks up where it left off.
rg :P
Tene but when we throw B, it looks in the same place that A first looked at.
NotFound Tene: I don't have any problem with that, the problem I'm trying to fix now is TT #300 21:23
Tene it's the *second* throw that has problems.
Tene looks
Yes, exactly! 21:24
purl i guess exactly! is it not awesome?
Coke pmichaud: nope. that was just so I could close the RT.
feel fre.
e.
Tene you'd be storing a reference to the catchall: handler in $P0
but then the handler does something broken, and get_results makes a *NEW* exception to throw 21:25
this new exception isn't the same as the one stored in $P0
Putting the reference in the exception stored in $P0 doesn't help.
NotFound Tene: yes, but the problem is that I need a way to know the handler at exception resume time, in order to clear the way used to mark it as active. 21:26
Without that, fixin TT #300 break a lot of other things
Tene ... what? 21:27
purl quietly listens while the crickets chirp
Tene ... oh.
so you're disabling it... and then reenabling it when the resume continuation is invoked? 21:28
NotFound A less hackish approach will be better, but I'm not found one for the moment.
Tene: that is the way I'm about to try, yes
Tene I don't see how you could even do that. Are you creating a subclass of continuation that enables a handler when it's invoked?
You resume like: resume = exception['resume']; resume() 21:29
the resume continuation is just a continuation. It doesn't know anything about the exception it was stored in.
NotFound Tene: no, the simpler idea is marking the handler as inactive when asked for 'resume'. If that works, we can think how to make it less hackish and more robust. 21:30
Tene you mean mark it active again.
NotFound Eh, yes 21:31
Tene and what about when the exception has been rethrown? It won't work there either...
Does this issue actually come up often enough to justify this hack?
Is it causing pain for anyone? 21:32
NotFound Tene: IMO yes. When it fails, it takes lots of time to figure how, why, and where
At least on all tickets I looked at that were related, it tooked 21:34
Tene have you tried looking in the exception's backtrace yet? 21:35
NotFound Mmmm...... no. I'll look at it. 21:36
cotto seen whiteknight 21:38
purl whiteknight was last seen on #parrot 2 hours, 32 minutes and 14 seconds ago, saying: Well la de da mr super computer man
pmichaud wonders if we'll someday have "Rakudo Python."
Tene EHs *should* appear in the backtrace. (If they don't now, it's probably wrong, IMO)
the solution I was thinking about before was something like making a clone of the contexts some undefined way up the stack, and storing that alternate chain of contexts in the continuation instead of the "real" one, so that when the EHs were freed from the real contexts through pop_eh, they'd still be referenced by the cloned contexts in the continuation. Something like that. 21:45
doing that for continuations in general, not just for exceptions.
No idea what the consequences of that would be. It wasn't really fully thought out yet.
rg is it possible that there's not much documentation about continuations anyway? 21:47
not many tests either :( 21:50
21:51 davidfetter joined
Coke ponders a seen update for purl that provides fuzzy time. 21:56
"about 2.5 hours ago..." 21:57
masque?
purl masque is figuratively speechless. or COOL WITH BURRITOS EVEN IF MINE DON'T SAY TOMMY HILBURRITO or Masquenfusion on AIM - USE THIS TO FIND HIM, IRC SUCKS or totally in love with warningsToBrowser, but forgetting to turn that off is something I fear. or awake. or Masquenfusion and Euqsam. or DJ Fresh Catnip or pleased with Masque's copy. or (see masque 2) or fond of used things that work. or a herring
cotto "less than a month ago"
Coke a leeeetle less fuzzy than that.
masque 2?
purl masque 2 is You sass that hoopy Masque? There's a frood who really knows where his towel is. or hellyeah sysop IIRC (or knows who is) or avocado-powered, baby
cotto That absolutely didn't make anything clearer. 21:58
except that last one
Coke ok, tickets are cheap, but they're not as cheap as your mom. 22:01
(search before opening, just to be nice.)
(apologies for obligatory mom joke)
22:02 allison joined
GeJ good morning everyone 22:09
davidfetter evenin', GeJ 22:10
GeJ heya davidfetter. Congrats on the latest set of releases.
davidfetter ? 22:11
GeJ wasn't there some postgresql releases a few days ago? 22:12
dalek rrot: r36598 | cotto++ | trunk/src/global.c:
[pcc] revert an apparently unintentional commit from r36594
 22:13
allison cotto++
(had just reached the same conclusion myself, after a binary search) 22:14
dalek rrot: r36599 | cotto++ | trunk:
[gc] change pt_DOD_* to pt_gc_*
GeJ allison: do you know who's in charge in handling PaFo's CLA applications? 22:15
allison GeJ: yes, the board handles them. emailing the address on the CLA will get you a reply from anyone in the board (myself included) 22:16
Tene allison: can you look at the discussion earlier about EHs? specifically rg's request and NotFound's proposed workaround? 22:18
allison Tene: will check the Piper-log. is there a ticket?
Tene trac.parrot.org/parrot/ticket/300 is the ticket NotFound was producing a workaround for. 22:19
GeJ allison: Oh, ok. Just to say that I sent one a few weeks back per suggestions of several people in here. But unfortunately, I can already predict that my contributions to Parrot will be very limited for some time as $job doesn't seem to be willing to allow me some free time.
Tene I don't know if there's a ticket for the EH stuff.
NotFound Tene: I'm not sure having proposed a workaround for something :?
dalek rrot: r36600 | cotto++ | trunk:
[gc] change interp->DOD_registry to gc_registry
Tene NotFound: your "mark the handler inactive, then mark it active again when someone asks for the resume attribute from an exception" thing? 22:20
allison GeJ: the CLA is just a legal document to cover your contributions to Parrot, it doesn't matter how many or few you make
Infinoid cotto++ # my git-svn only updates once every 10 minutes, you're hard to keep up with
NotFound Tene: ah, yes, but that is not for rg request, is for TT #300
Tene NotFound: that's related to what rg was asking about. 22:21
GeJ I was wondering, would anyone be interested in having a Data::Dumper that returns data instead of just dumping it on STDOUT?
NotFound Tene: but I asked first ;)
Infinoid GeJ: definitely
Tene NotFound: eh?
NotFound No matter
Infinoid (returning a string)++ 22:22
NotFound Can't you just use a StringHandler?
rg i don't think there is (i couldn't find one a few minutes ago). i'll try and write a new ticket one of these days unless someone beats me to it ;) 22:23
NotFound And dumping on a handler, not in hardcoded stdout, of course
Tene I'll make one now.
Infinoid NotFound: returning a string would make it as useful as the perl5 version of the module 22:24
GeJ Infinoid: ok, well, I'll give it a try. Can I forward you patches for review as I make progress? (as I said earlier, don't expect a constant flow of them for the foreseeable future)
Infinoid You don't *always* want to print it directly. Maybe you want to print it more than once, or compress it and send it over a network, or whatever.
cotto Infinoid, should I hold off for a while?
Infinoid GeJ: No problem. In return, I can't promise to respond with particularly useful messages :) 22:25
cotto: No, it was a compliment. By all means, keep kicking ass.
NotFound Infinoid: a StringHandler is printing it to a string, no loss of functionality
Infinoid Yeah. Or you could just return it, the easy way.
cotto roger
allison Tene: in general, TT #300 is just an example of legacy exception handlers. The first thing every exception handler should do is check if the exception is one it can handle. If it can't handle the exception, it should rethrow it. 22:26
NotFound Infinoid: but slower and memory hungry when you want to use a Handler
22:26 Whiteknight joined
Tene That's what I thought. 22:27
GeJ For the record, the idea came to me while pursuing my Perl-to-PIR tests conversion quest. Some tests use Data::Dumper to output data structures, and I couldn't figure out a way to catch that in a string and use it in a is() call.
allison Tene: we don't remove exception handlers, ever (that's what the old code did, and it was fundamentally broken)
NotFound GeJ: there is a way: redirect stdout to a stringhandler
rg allison: can you elaborate? i find the current aproach fundamentally broken aswell.
allison Tene: exception handlers live in the context, so when you leave the context you don't see them anymore
rg: with resumable exceptions, you can't remove handlers, because you may resume within the scope of an existing handler (in which case deleting the handler would produce the wrong semantics) 22:28
GeJ NotFound: I think I tried it at the time and failed. I probably did it wrong or things have improved since then. If you have a working syntax to recommend me, I'd be happy to apply it to the tests I'm trying to convert. 22:29
allison rg: instead, you leave handlers in place, but scoped to the context rather than scoped globally
nopaste "NotFound" at 213.96.228.50 pasted "Redirect strout to a StringHandle" (35 lines) at nopaste.snit.ch/15588
allison rg: so they naturally pass out of scope when you leave the scope
chromatic Or Data::Dumper could just not print by default, instead of building up a string and then printing it. 22:30
rg allison: how do you propose to solve the exception inside the handler results in recursion problem?
NotFound GeJ: I wrote that test some days ago
allison rg: that's caused by old exception handlers that aren't properly checking the type of the exception they're passed
by default, in Parrot, and exception handler will examine all exception types 22:31
s/and/an/
dalek rrot: r36601 | whiteknight++ | branches/rename_pccinvoke:
Creating a branch to rename the Parrot_PCCINVOKE function and unify it with Parrot_pcc_invoke_method_from_c_args
allison rg: most HLLs declare an exception handler for a specific type or set of types it can handle
rg: calling the same exception handler multiple times isn't a problem if that exception handler actually knows how to handle the exception 22:32
rg: the problem we're getting is exception handlers trying to handle exceptions of the wrong type 22:33
NotFound allison: the problem is when the exceptionhandler accidentally throws something it can handle
allison rg: so, the code makes assumptions about the exception it's passed, which turn out to be wrong, and cause exceptions
NotFound And does it before doing a pop_eh
allison NotFound: no, that's fine, if the handler actually know how to handle it 22:34
knows
NotFound allison: yes, in a perfect world... in the current world, is a bud difficult to catch
bug
allison NotFound: I'd generally argue it's a case of user error, but sometimes it's possible to change syntax in order to discourage a common user error 22:35
NotFound: what if... the default answer to "can_handle" were "No" instead of "Yes", and defining an exception handler *required* declaring what types it can handle? 22:36
chromatic ... and the exception handler dispatcher checked those types before dispatching to exception handlers, instead of requiring exception handlers to get this right themselves?
NotFound allison: I'm trying to find a way to catch current problems faster, short term 22:37
allison NotFound: it makes declaring exception handlers more verbose, but it means people don't run into these problems unless they explicitly ask for them
chromatic: in fact, it already checks them, just no one is bothering to set them
NotFound Call them legacy if you want
Tene allison: rakudo uses them
allison: PCT uses them for handling 'return' 22:38
allison Tene: that's good. Progress
chromatic I'm sure PCT could set them.
Tene pct-generated loops use them
rakudo's gather/take
rakudo's CONTROL
cardinal uses them
rg pct is not doing to well with the try/catch, though 22:39
s/to/too/
Tene defaulting to 'no' would be fine with me.
allison: the problem with defaulting to 'no' is exceptions without any type set. Should we disallow that too? 22:40
Or just "don't do that"?
chromatic We could warn.
allison Tene: yup, make the answer to 'can_handle' false if the handler doesn't have a type set
Tene: and maybe even warn on initialization if no type is set 22:41
Tene allison: this will need a deprecation cycle, yes?
allison though, type is often set in a subsequent call
Tene: yes, and it will break all the legacy exception handlers in the system
Tene allison: we can warn on throw if there's no type set.
rg that might work. at least there wouldn't be as much recursion. 22:42
allison Tene: so, big code update (or at least scattered update, touching many files)
Tene It can happen in a branch.
allison Tene: yes
Tene: if we deprecate it now, it can still get in before 1.0
Tene It can go in after the Feb. release? 22:43
NotFound So we are going to deprecate push_eh LABEL ?
allison NotFound: no 22:44
Tene allison: are we requiring type, or type|severity?
allison: if we default to no, then EH's created by push_eh LABEL will never catch anything. 22:45
NotFound Tene: well, at least that will completely solve #300 :D
allison Tene: I'd require type, with severity optional 22:47
Tene "catch all warnings" seems like a reasonable sort of handler. 22:48
allison Tene: good point on push_eh LABEL, so it would need to be "push_eh LABEL, INT"
NotFound allison: so we're deprecating it and cretaing a new one
allison Tene: yes, we need special virtual types for "all exceptions" and "all warnings" 22:49
NotFound: yes, but mainly keeping the shortcut of a label (where the actual exception handler object is created for you behind the scenes)
NotFound That is how is implemented the current version 22:50
allison NotFound: aye, that abstraction was changed in the big exception refactor (I just kept the same interface) 22:51
NotFound TT #295 is a recent example of bugs caused for that thing. I catched it fast just because I was working at related problems and know what to search for 22:52
Well, not caused for it, but without clean diagnostic because of it. 22:55
allison NotFound: yes, it seems that people *expect* their exception handlers to only handle the specific exception they're looking for, and not try to handle every exception 22:58
NotFound: so, perhaps we can make it behave more like they expect
NotFound allison: yes, but even in that case you can be actually trying to catch the same type of exception you accidentally throws. 22:59
rg i don't think this will quite solve the try { throw a; } catch { throw b; } case, but maybe we can get pct to help with that? 23:00
allison NotFound: if your handler is designed to handle those types of exceptions, then it shouldn't be a problem 23:01
rg: that's all about scope
rg: parrot doesn't currently support scopes smaller than a .sub 23:02
NotFound allison: if the excption handler is perfect no problem, but I'm talking about mistakes that lead to difficult to catch bugs
allison NotFound: no virtual machine can prevent users from making errors
NotFound: the best you can hope for is discouraging them 23:03
NotFound allison: a way to discouraging completely is that a handler does not catchs exceptions thrown inside himself. 23:04
allison NotFound: but with exceptions as labels within the scope of the sub, all handlers set within the sub semantically belong to that code 23:05
NotFound allison: then skip the sub and search handlers outside, no problem 23:06
allison NotFound: and if you make a special exception for a handler at the bottom of the chain, what if the problem is actually with a handler farther out the chain?
NotFound: that is, the same problem can occur if you're invoking a handler 5 levels outside the current sub 23:07
NotFound Same thing, search for handlers in the outside
Tene NotFound: with handler-as-label, you also can't detect the difference between an exception thrown outside of the handler and inside it.
allison NotFound: because the invocation context for the handler is the point where the exception was thrown
NotFound Tene: actually not, that's the reason why I was looking for one. 23:08
allison (a handler is just a sub)
rg i thought parrot didn't support a real sub as a handler yet
allison NotFound: arbitrarily deciding to skip the first handler doesn't eliminate recursive handlers, it just bumps it back a level
rg: exception handlers are continuations, which are subs 23:09
NotFound allison: not the first, the handler that is running
allison NotFound: all that does is screw up your exception hierarchy
exception handler hierarchy 23:10
rg which gets me back to the lack of documentation on continuations *sigh*
23:11 TiMBuS joined
allison rg: hey, the best person to write it is the person who doesn't understand it yet :) 23:11
(writing documentation is an *excellent* way to learn)
(possibly the best)
dalek rrot: r36602 | cotto++ | trunk:
[gc] change all occurances of "early_DOD" to "early_gc"
 23:15
rg ah there, whiteknight++ did it already. we really need an online version of docs/book ;)
rrot: r36603 | cotto++ | trunk:
[gc] change all occurances of "high_priorty_DOD" to "high_priorty_gc"
 23:18
rrot: r36604 | cotto++ | trunk:
[gc] change DOD_flags to gc_flags
 23:22
rg is trying to wrap his head around the scope definition. 23:30
is it possible to push_eh a handler that doesn't have itself in scope? 23:31
Whiteknight rg: we DO need an online version of docs/book/, I've been bitching and moaning about that for a while now 23:32
dalek rrot: r36605 | cotto++ | trunk:
[gc] rename PROF_DOD_* to PROF_GC_*
Whiteknight but yeah, the book has lots of surprises. If you have any questions about anything, that's a good starting point
NotFound rg: you can push_eh anything that is an ExceptionHandler 23:33
rg whiteknight: i was avoiding it because my perldoc was complaining about a lot of markup in there. what do i need to install to get that right? 23:34
chromatic Pod::PseudoPod 23:35
dalek rrot: r36606 | whiteknight++ | branches/rename_pccinvoke/src/global.c:
[rename_pccinvoke] make the first change, everything compiles. That's a good start.
 23:37
rg notfound: sure, but can i set_addr something that is a different scope? 23:38
cotto What's the difference between DOD_RUNS and COLLECT_RUNS? 23:40
and would it be accurate to change DOD_RUNS to GC_RUNS? 23:41
rg and also, what can i do at the end of that handler if i don't want to call the return continuation
Tene you can do whatever you want.
another common choice is .return() 23:42
or goto
23:42 rdice joined
dalek rrot: r36607 | allison++ | branches/load_language:
Creating branch for testing the load_language opcode.
 23:44
nopaste "tene" at 97.117.56.92 pasted "sub exception handler example for rg" (30 lines) at nopaste.snit.ch/15589 23:46
Tene the first two 'say's are lies that I was too lazy to change.
NotFound rg: you mean in pir? You even not have access to labels out of scope. 23:47
Tene That example works fine.
Is there not a test of that?
rg tene: thank you, i was just trying to get that to work 23:49
Tene rg: no problem
NotFound Ah, you mean a sub. That makes more sense.
rg now let's try that with .return() ;)
Tene I don't think it's quite the right way to do it, with find_name and such.
NotFound And if we have a nice implementation of invoke, we can even use an ExceptionHandler object as his own handler sub 23:51
chromatic is tempted to reject all tickets about failing tests which don't provide the diagnostics of those tests. 23:52
NotFound And gives his senders to the Spanish Inquisition 23:53
Tene If that was the only way to do EHs, it's a pretty simple patch to give you the "don't catch exceptions thrown from the EH" behavior you want.
I'm certainly not going to be the one to migrate all existing use of EHs, though. 23:54
;)
rg aha, .return() returns to the calling sub, not quite unexpected. 23:56
dalek rrot: r36608 | allison++ | trunk/src/call:
[cage] Adding svn:ignore property for .str files.
rg tene/allison: how would we deprecate that in a backwards compatible way anyway? 23:58
Tene rg: we wouldn't.
NotFound What 'that'? The push_eh LABEL unconditional? 23:59
Tene NotFound: using labels instead of subs for EHs.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!