half-pie" released! | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
Set by moderator on 5 October 2009.
darbelo coverage? 00:02
purl well, coverage is cv.perl6.cz
dalek TT #1095 created by geraud++: [PATCH] un-TODO unconditionally some tests in t/op/io.t
00:04 bacek joined
GeJ regarding TT#1095, my bad. I should have filled a TT when I reported it on IRC. 00:05
G'Day bacek
darbelo GeJ: Not a problem. Do we know the NetBSD status now?
bacek_at_work G'Day GeJ 00:06
nopaste "darbelo" at 200.49.154.173 pasted "src/library.c: Now strstart free!" (33 lines) at nopaste.snit.ch/18236 00:10
darbelo Can I get a win32 test of nopaste.snit.ch/18236 00:11
I'd rather not bother ttbot this late :)
GeJ darbelo: no info on NetBSD but I can try to subvert a NetBSD user to make a run. However, I'd bet that the tests will pass there as well. 00:17
darbelo That's my guess as well, but it doesn't hurt to check ;) 00:18
GeJ Eventually, I'll try to get a shell on a NetBSD box tonight and see if I can run it myself.
darbelo Do we have any regular NetBSD smokers? 00:20
Or is it smolderers now?
smolder? 00:22
purl somebody said smolder was sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8
darbelo smolder slooooooow. 00:24
GeJ smolder.plusthree.com/app/public_pr.../28566/106 00:25
shorten GeJ's url is at xrl.us/bfqmw6
GeJ smolder.plusthree.com/app/public_pr...ails/28566 (for the big picture) 00:26
shorten GeJ's url is at xrl.us/bfqmxg
GeJ it looks like the latest smoke test from a NetBSD user.
Ryan52 so in a chroot rakudo segfaults. the gdb traceback shows all parrot stuff, so...how can I debug this?
GeJ both TODO tests are ok.
darbelo Yeah, found it. But the way they're being TODOed doen't leave room for a TODO PASS result, which is what I wanted to check. 00:27
00:28 Zak joined
darbelo GeJ: Ok, commited. We'll see how much smoke pours in after this. 00:31
dalek rrot: r41731 | darbelo++ | trunk/t/op/io.t:
Unconditionally un-TODO tests in t/op/io.t, they PASS everywhere now.
00:33 cotto joined
GeJ darbelo++ 00:33
thanks
00:37 bacek_at_work joined
dalek TT #1095 closed by darbelo++: [PATCH] un-TODO unconditionally some tests in t/op/io.t 00:38
00:48 rhr joined
japhb Should an exception handler include a pop_eh? 01:37
I'm getting mixed signals from the docs
Tene japhb: Um... it depends on exactly what you mean. 01:38
>.>
japhb: that is, on what your code is saying.
darbelo japhb: Ideally, yes.
Tene They mean different things, so it varies.
japhb Tene, explain please. What are the cases?
Tene japhb: you should pop_eh if you want the EH to be gone, and don't pop_eh if you don't want the EH tob e gone. 01:39
many EHs, after handling the exception, jump back into some kind of loop.
japhb ah! OK.
darbelo If you push_eh, you should pop_eh once you no longer need the 'eh'.
Tene some EHs, after handling the exception, terminate and go off somewhere else.
japhb yep, the latter is the case I'm dealing with.
So I should do pop_eh right after .get_results, yes? 01:40
Tene japhb: yeah, that will be fine.
japhb OK, cool, thanks.
02:00 darbelo left 02:01 rhr joined 02:35 janus joined
dalek ose: r180 | Austin++ | trunk/ (25 files):
Got more visitors working object-style.
02:41
02:52 cottoo joined 02:54 cotto joined
Ryan52 slexy.org/raw/s228rtU4Y1 03:03
this is with the latest released parrot and latest release rakudo in a minimal chroot. 03:04
any ideas or steps to debug better?
if there's anybody else who actually has a clue what they're doing who would be willing to debug it, I can give you access to the system. 03:07
03:09 kjeldahl__ joined 03:27 TonyC joined 03:30 napalm joined 04:10 nopaste joined, TonyC joined 04:48 baest joined 06:24 uniejo joined 06:28 xenoterracide joined 06:36 mokurai left 06:53 mberends joined
moritz tonight I dreamt that the pcc-rewire branch passed all tests. Really. 07:00
07:07 fperrad joined 07:08 Zak joined 07:09 kurahaupo joined
cotto I hardly ever get to think about code enough that I dream about it, though I think I did have a dream involving the profiling runcore at one point. 07:14
moritz well, I didn't even touch any code (except a test regex) in that brnach 07:16
usually I just dream that stuff I checked in the previous night is horribly broken
07:20 bacek joined
bacek o hai 07:20
07:22 TiMBuS joined
bacek moritz: why you are dreaming about pcc-reapply branch? 07:23
moritz bacek: no idea
bacek moritz: :)
cotto clock? 07:28
purl cotto: LAX: Tue 12:28am PDT / CHI: Tue 2:28am CDT / NYC: Tue 3:28am EDT / LON: Tue 8:28am BST / BER: Tue 9:28am CEST / IND: Tue 12:58pm IST / TOK: Tue 4:28pm JST / SYD: Tue 6:28pm EST /
xenoterracide question... how easy would it be to create a 'template engine' in parrot vs one in perl5? 07:31
bacek xenoterracide: depends on "template engine". You can easily create some sort of DSL using PCT in parrot. 07:35
xenoterracide DSL? PCT? 07:36
cotto dls?
purl dls is the dalles oregon
cotto dsl?
purl i think dsl is digital subscriber line or a conspiracy to collect geeks near major cities so they'll be easier to round up when society collapses. or Dammit Slow Link or diesel in kewlt0k. or Dick Sucking Lips or LSD BACKWARDS or a Domain Specific Language or the Definitive Software Library or french for 'damn slow line'
cotto domain specific language
pct?
purl pct is probably the Parrot Compiler Toolkit
xenoterracide ah 07:37
dalek rrot: r41732 | bacek++ | branches/pcc_reapply/src/ops/core.ops:
Remove unused ccont from op set_returns
rrot: r41733 | bacek++ | branches/pcc_reapply/src/call/args.c:
Remove unused ctx in fill_returns.
cotto now you know 07:39
purl And knowing is half the battle.
moritz writing the parser is probably much easier with parrot 07:42
cotto we do have some unusually shiny parsing tools 07:44
moritz and they are going to become even more shiny real soon ;-)
cotto but not so shiny that it's going to keep me up any longer. good night all.
moritz 'night cotto 07:45
xenoterracide ... will parrot languages work with just mod_parrot? or do they require mod_parrot plus there own mod? 07:47
07:47 AndyA joined
xenoterracide or do they just need there own mod? 07:47
07:54 iblechbot joined
bacek xenoterracide: mod_parrot will probably enough 07:57
xenoterracide so then why is there a mod_perl6?
moritz I think it's more high level than mod_parrot 07:58
xenoterracide k 07:59
anyone know of any vim syntax highlighting files for parrot? 08:02
moritz xenoterracide: look in the editor/ dir 08:04
xenoterracide how do you know whether to write in pir/pasm/npq ? 08:15
moritz if I were to do such a thing, I'd write as much as possible in nqp, because it's most high level 08:16
actually I'd do it straight in Perl 6, with Rakudo :-) 08:17
bacek xenoterracide: you don't know. You just free your mind, put hands on the keyboard and at the end of the day watching beautiful state of art code written in unspeakable language
xenoterracide is code written in pir faster?
08:18 fperrad_ joined
moritz faster than perl 6, yes 08:18
xenoterracide well faster than npq
moritz has no idea 08:19
but nqp doesn't optimize, so it's propably a bit slower
xenoterracide err nqp
right
although technically I'm thinking of just using it as a template language I may end up just implementing the whole spec. or as usual I may end up doing nothing 08:21
moritz :-)
xenoterracide I'm just thinking that since I may end up implementing the whole language... it may not hurt to just start by writing it in parrot 08:22
another question how hard would it be to create multiple syntax's that do exactly the same thing? 08:25
would you create wrapper code?
moritz it depends on how similar the structure is
xenoterracide ah 08:26
moritz if the second version just uses different literals, you can write a set of common action methods, and re-use them for different syntaxes
but if they differ very much in the structure, you might have to do much more
xenoterracide hmm... well I'm thinking about implementing cfml on parrot... I sorta like the language but I hate it's obsessive use of cf at the beginning of everything... I'd rather just have <if> than <cfif> however, it'd be nice to support existing code... so I'd think supporting both syntax's would be key 08:28
moritz that looks not hard at all 08:30
mikehh All tests PASS (pre/post-config, smoke (#28611), fulltest) at r41731 - Ubuntu 9.04 amd64 08:31
xenoterracide however there's also cfscript which I believe uses a C style syntax but is otherwise doing the same things 08:32
dunno looked at cfml once and liked the syntax (at least to some degree) but I hate that all cfml runs on java
moritz if you structure your rules cleverly, you can make the <cfif> vs. <if> distinction by simply subclassing the grammar 08:33
xenoterracide wonders why parrot has its own irc server 08:41
szbalint it doesn't 08:46
if you mean this network that is
08:47 bacek joined 08:48 payload joined
moritz there is a separate irc.parrot.org, but I've never used it 08:49
xenoterracide moritz: that's what I'm connected to now 08:51
szbalint that's here
$ host irc.parrot.org
irc.parrot.org is an alias for irc.perl.org.
moritz oh
szbalint this is the trick :)
xenoterracide right 08:53
xenoterracide thinks ya'll should just be on freenode 08:54
moritz #perl6 is on freenode :-)
but you already found that 08:55
xenoterracide yep
I just don't see the need for perl or mozilla to have there own irc networks.... I think it'd be better if all of foss was on 1 network
moritz NIH-syndrome 08:56
xenoterracide prolly 08:57
or freenode wasn't around/awesome when it was created
moritz some things on freenode are also quite complicated 08:58
like recovering a "lost" channel
xenoterracide lost?
purl lost is the past tense of to lose or what we call those who are stuck on WINN'T. or "I fell on it in the shower"
xenoterracide lol
moritz on irc.perl.org one can just talk to one of the admins, and they'll give ops to a few people they know
xenoterracide moritz: I've been able to do that on freenode 08:59
of course I had connections
moritz "lost" == person who registered the channel went away
xenoterracide person who registered should have defined multiple contacts... and create multiple ops
moritz we have multiple ops, but can't add new ones (for #perl6) 09:00
xenoterracide huh
I don't know
'course if I have a problem on freenode serious enough I tend to slap christel w/ a fish 09:01
xenoterracide wonders why I'm up at 5am
mikehh pcc_reapply - revision make smolder_coretest #28614 09:05
revision r41733
10am for me :-} as for bacek ... 09:07
xenoterracide grr... why doesn't this just run... 09:11
bacek who called my name? 09:17
09:20 particle joined
xenoterracide is there any documentation for installing these .vim files 09:23
oh guess there's a pod
moritz it's called README so that nobody's ever going to read it :-) 09:24
xenoterracide readme's are overly complicated
09:24 masak joined
xenoterracide of course the fact that I had to download the source tarball to get these is kinda silly 09:25
09:43 riffraff joined 09:49 mberends joined 09:55 particle joined 10:29 kid51 joined 10:31 quek joined 10:34 riffraff joined 10:42 sri joined 10:43 cconstantine joined 11:30 ruoso joined 11:54 tetragon joined 12:12 preflex joined 12:15 whiteknight joined
whiteknight good 'morrow parrot 12:18
12:24 bluescreen joined
Util whiteknight: Is it tomorrow already? JIT! 12:28
whiteknight Util: It's always tomorrow somewhere
12:30 szabgab joined
Util Some people carry so much yesterday with them, that they cause tidal effects. 12:30
whiteknight pcc_reapply doesn't even build on win32 right now apparently 12:34
src/nci_test.c says undefined reference to PMCNULL 12:37
12:44 whiteknight joined 12:45 allison joined 12:47 bluescreen joined
jonathan oh hai 12:54
Need to check against latest Parrot, but just got back from vacation and the version Rakudo uses segfaults... :-S 12:55
In miniparrot.exe
whiteknight I was seeing some smoke failures in trunk I think. I haven' looked at it recently 12:59
I've been focusing much effort on the pcc_reapply branch
jonathan I'm trying latest now. If latest works, I'll go with that.
No, same. 13:00
*sigh*
Oh, Rakudo defaults to optimized build now. 13:02
Trying non-optimized.
ah 13:03
that gets further
moritz if that's the culprit, you change Configure.pl to only default to optimized build on non-windows platforms
jonathan moritz: yup, doing that 13:06
13:08 particle joined
dalek kudo: f845ccf | jonathan++ | Configure.pl:
On Win32, the optimized Parrot does not even build, so don't do --optimize on Win32 for now.
13:21
shorten dalek's url is at xrl.us/bfqpbn
13:22 iblechbot joined 13:24 AndyA joined
whiteknight something is definitely broken on win32. Needs us some fixin' 13:27
jonathan whiteknight: It blew up somewhere in pcc. 13:38
whiteknight: But that doesn't have to mean the problem is in there.
whiteknight right 13:39
13:54 PacoLinux joined 14:15 theory joined 14:20 Psyche^ joined 14:30 PacoLinux joined 14:37 ruoso joined 15:07 allison joined 15:16 pyrimidine joined
whiteknight good morning allison 15:19
15:19 mokurai joined
pyrimidine Odd, can't connect to #perl6 15:20
moritz pyrimidine: are you on irc.freenode.net (or .org)? 15:21
masak was just going to ask the same
pyrimidine moritz: irc.freenode.net
purl hmmm... irc.freenode.net is home of the mirror universe #perl that isn't full of assholes. or where you can find a #perl that's supposedly actually got something to do with perl
masak purl: talk a lot, do you? 15:23
purl masak: i haven't a clue
masak I guess that's part of the problem.
allison whiteknight: good morning
moritz pyrimidine: I'm removing a few bans now
pyrimidine: please try again 15:24
pyrimidine Can't connect via Colloquy, but I can comment via browser 15:25
15:26 coke joined
coke ~~ 15:26
Coke opbots, names 15:27
opbots, trust andya
slavorgn Ok
slavorg Ok
Coke opbots, names
(too slow)
Coke ~~ from the UK 15:28
pyrimidine moritz: ok, seems to be working now with colloquy. 15:29
thx
moritz you're welcome 15:30
dalek rrot: r41734 | japhb++ | trunk/config/auto/opengl.pm:
[OpenGL] Ancient and small doc patch that I'd forgotten to commit
15:38
15:39 jrtaylor joined 15:55 darbelo joined
mikehh hi Coke, y'all in Leeds? 16:05
16:08 davidfetter joined
dukeleto 'ello 16:31
whiteknight 'ello poppet 16:36
16:50 cotto_work joined
dalek rrot: r41735 | pmichaud++ | branches/pct-rx:
[pct-rx]: Removing branch, now developing in a github repository (pmichaud/nqp-rx).
17:16
darbelo slow day. 17:27
whiteknight yeah it is
darbelo did anyone test nopaste.snit.ch/18236 on win32? 17:28
17:30 Andy joined
darbelo whiteknight: ping. 17:36
whiteknight pong
darbelo You were doing some IO refactors a while back. What came out fo those? 17:37
whiteknight a long task list :) 17:38
There is much more IO work to do, but I got delayed and then distracted
dalek rrot: r41736 | Util++ | trunk (3 files):
Removed bogus properties from files: "svn", "mime-type", "snv:eol-style".
17:39
jonathan When is #ps? 17:40
50 mins?
darbelo Got a link to the task list? 17:41
cotto_work jonathan, yes
darbelo goes afk
Util darbelo: if you mean the milestone list: trac.parrot.org/parrot/report/14 17:42
jonathan cotto_work: thanks
<- away for a month, only just getting back into the swing of things
dalek rrot: r41737 | Util++ | trunk:
Removed bogus properties from root dir: "svn:mime-type", "svn:keywords", "Makefile.PL".
17:43
cotto_work Tene, if all you do is make fill_params work, feel free to call it a good week. 17:52
17:53 preflex joined 17:54 fperrad_ joined 17:55 jsut joined
darbelo Util: no, I meant whiteknight's io task list. 17:56
allison Tene: are you working on fill_params now? 17:57
Util darbelo: KTHX
darbelo But I found it on the wiki.
allison Tene: (I made changes to your patch last night, then reverted them, didn't like the direction it was heading)
Tene allison: I'm working on contacting HP support to deal with lab machines that have spontaneously gone offline.
So... no. :) 17:58
allison Tene: no worries
Tene: I'm going to go ahead and check your patch back in
Tene :)
I'll look at it when I get home tonight.
allison Tene: I know it breaks tests, but it'll be easier to check in fixes as small modifications
Tene: (and easier for both of us to work on it that way) 17:59
cotto_work It's a branch. The whole point is that the rest of us don't have to worry too much if it breaks tests.
Tene I'd branch the branch, but I don't want anyone sending me a mail bomb. ;) 18:00
18:07 kurahaupo joined
dalek rrot: r41738 | Util++ | branches/autoprops:
TT#994 Creating a private, temporary branch of trunk/editor to test git-svn autoprops.
18:12
Coke mikehh: yes, in leed.s 18:13
just got some extremely yummy thai takeaway. mmmm.
I could get used to this. 18:14
ps? 18:18
purl ps is postscript or process status or see "parrotsketch" or non-vector?! or annoying.
Coke parrotsketch?
purl rumour has it parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
Coke clcok?
purl clcok is clock or cock
Coke clock?
purl Coke: LAX: Tue 11:18am PDT / CHI: Tue 1:18pm CDT / NYC: Tue 2:18pm EDT / LON: Tue 7:18pm BST / BER: Tue 8:18pm CEST / IND: Tue 11:48pm IST / TOK: Wed 3:18am JST / SYD: Wed 5:18am EST /
darbelo PDT == Parrot Developer's Time? 18:19
Coke parrotsketch in 70?
cotto_work Coke, closer to 10 18:20
18:20 barney joined
Coke ah, right, LON NE GMT. 18:20
er, NE UTC 18:21
mikehh UTC +1
dalek rrot: r41739 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Reapplying r41721, Tene's work on return handling, so we can work on the
mikehh summer time or whatever
allison depending on daylight saving time
whiteknight I am very interested to see what makes this work
because I really don't understand the returns algorithm
dalek rrot: r41740 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] A few quick fixes to return/result handling.
18:28
allison whiteknight: it's largely the same as the args/params algorithm, just the storage is different 18:31
whiteknight Seems then that we could use fill_params with different accesor function pointers 18:32
darbelo #ps in 0
whiteknight but I'm getting ahead of myself
18:33 bacek joined
darbelo Hello bacek 18:33
18:33 chromatic joined
jdv79 i remember someone suggesting a hw parrot vm implementation. just curious - has anyone ever seen a hw jvm or .net vm or any vm? 18:34
cotto_work jdv79, there are some partial hardware jvm implementations. 18:35
chromatic I've seen JVM hardware -- the Java Ring.
whiteknight jdv79: Yes, I've looked at them closely
chromatic A lot of ARM processors have hardware support for some JVM operations.
Azul systems has a Java processor.
whiteknight I would love to to a PBC-based processor hardware, if I were still doing hardware stuff 18:36
jdv79 did it really provide sufficient value?
chromatic Azul's stuff seems to. 18:37
They have hardware support for GC and JVM memory management.
whiteknight I was looking at an HDL design that would integrate a few picoblaze sub-cores to handle things like GC that would be hard to do in hardware 18:39
chromatic Even merely read/write barrier support in hardware would be a huge improvement. 18:40
whiteknight we don't read/write barrier in trunk now though
dalek rrot: r41741 | pmichaud++ | trunk/runtime/parrot/library/PGE/Perl6Grammar.pir:
[pge]: Add ability for PGE::Perl6Grammar to handle category:sym<...> names.
18:41
18:41 jrtaylor joined
chromatic Lorito will make read/write barriers easier. 18:41
particle a microkernel code, named seL4, has been proven correct, and will soon be available as a hypervisor. nicta.com.au/news/current/world-fir...eliability 18:42
shorten particle's url is at xrl.us/bfqq4b
jrtaylor chromatic, how so?
chromatic If we know that all "Store this!" operations go through a single opcode, we can annotate that opcode. 18:43
jrtaylor oh, I see. 18:44
thanks
whiteknight being able to write certain operations only once means that when we need to make a change, we only need to make it once 18:47
chromatic Or if we need to swap it out for profiling....
jdv79 yes, L1 sounds too good to be true. 18:50
japhb dukeleto, want Plumage commit bit? 18:52
dukeleto japhb: surely
japhb: it is on gitorious? 18:53
japhb Have signed PaFo CLA sent in?
dukeleto, yup
dukeleto i haven't used that yet
japhb: yes, I am a parrot committer
japhb It's github with less social and more stable.
dukeleto japhb: that is a good, concise description of it
japhb: do I need to make a gitorious account?
japhb: or do you just need a key from me? 18:54
japhb dukeleto, yup. Just send me the gitorious nick once you have it set up, and I'll add you to the project.
dukeleto japhb: okely dokely
japhb (y)
18:56 cconstantine left 18:59 joeri joined
Coke aigh. SG:U is on sky 1... and I only have sky 3 here. curses. 19:03
japhb has to wait for Netflix for SG anyway ... 19:04
Coke And I apparently missed it in the states last friday. 19:05
coises.
chromatic Given how they handled the end of Atlantis, were you *really* anticipating it? 19:09
Coke chromatic: you're talking to the guy who watched every episode of andromeda because he watched part of the first season. 19:14
and I have lot invested into SG:1. =-)
chromatic Oh yeah, Andromeda. Sigh. 19:15
I liked the Gaheris Rhade episodes.
japhb Rhade++ 19:16
whiteknight MMV?
japhb I miss "Excalibur", the follow-on to Babylon 5. The cast was just beginning to gel when they got cancelled. 19:17
chromatic Excalibur or Crusade?
japhb Maybe I got mixed up. The one based on the ship that looked kinda like a sword from the side, and could only fire its main gun every few minutes (the ship being dead in space for a while after it fired) 19:18
Coke crusade. I think excalibur was the ship
whiteknight allison: what's the status of pynie? Where is it hosted now? 19:19
kurahaupo I've had a nagging feeling for the last week about the ResizableXXXArray PMCs' lack of memory initialization. I was told that the lack of initialization is because they're "low level", yet they have push/pop/shift/unshift implemented in ways that bespeak being intended as a higher-level construct than the corresponding FixedXXXArray.
(If we really care about them being fast for push/pop etc they'd be done with ring-buffer counters, not by shifting memory blocks.) 19:20
whiteknight all the array types are in desperate need of an overhaul, yes 19:21
japhb I thought bacek was working on that? Or did he get sidetracked? 19:22
whiteknight kurahaupo: create a page like "ArrayTasklist" on the wiki where we can start putting ideas
allison whiteknight: on google code 19:24
pmichaud Util: (re STD.pm and protoregexes) protoregexes and ltm aren't the only blockers to STD.pm, but they're the major ones atm 19:26
Util pmichaud: OK, thanks.
pmichaud Util: I think it's also the case that once Rakudo and NQP have protoregexes and ltm, we'll see a convergence of grammars more than "Rakudo adopting STD.pm"
chromatic Convergence seems most likely to me as well; Rakudo's parser pulls in more and more of STD. 19:27
pmichaud I can't speak for TimToady++, but my feeling is that this round of implementation is going to affect STD.pm about as much as STD.pm is affecting Rakudo
19:27 payload joined
dalek tracwiki: v105 | whiteknight++ | WikiStart 19:28
tracwiki: +tasklist page for cleanups of Array-like PMCs
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/bfqq95
pmichaud so, my feeling is that the next round of rakudo grammar will be _very_ STD.pm like but not entirely STD.pm 19:29
moderator half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview 19:35
dalek tracwiki: v1 | kurahaupo++ | ArrayTasklist 19:45
tracwiki: new page. open question about lack of initialization of resizable arrays
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
shorten dalek's url is at xrl.us/bfqrcu
bacek Good morning 19:48
whiteknight kurahaupo: We should look through the tickets list to find any array-related tickets and add them to the tasklist 19:50
dalek tracwiki: v2 | whiteknight++ | ArrayTasklist 19:51
tracwiki: + two tasklist items concerning arrays
whiteknight #1089 and #1072 are good candidates
dalek tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
shorten dalek's url is at xrl.us/bfqrdv
whiteknight #1039, #809, #879, #218, #159 19:55
dalek tracwiki: v3 | kurahaupo++ | ArrayTasklist 19:58
tracwiki: Make multiple variants for different purposes?
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
shorten dalek's url is at xrl.us/bfqres
kurahaupo whitenight: #1089 has contributions already. 19:59
whitenight: #1089 has my contributions already. 20:00
whiteknight could still be listed on the tasklist
20:05 jan joined
dalek tracwiki: v4 | kurahaupo++ | ArrayTasklist 20:08
tracwiki: Links to related tickets
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
shorten dalek's url is at xrl.us/bfqrgf
whiteknight leaves. Later 20:10
cotto_work clock? 20:13
purl cotto_work: LAX: Tue 1:13pm PDT / CHI: Tue 3:13pm CDT / NYC: Tue 4:13pm EDT / LON: Tue 9:13pm BST / BER: Tue 10:13pm CEST / IND: Wed 1:43am IST / TOK: Wed 5:13am JST / SYD: Wed 7:13am EST /
chromatic thinks he may have fixed line numbering in IMCC. 20:14
darbelo chromatic 20:16
chromatic++
cotto_work thinks me may be impressed
chromatic, as in completely fixed or just significantly less broken? 20:17
chromatic Less broken.
I'm chasing an off-by-one in macros that I think I know how to fix.
cotto_work still impressive given imcc's code
Tene chromatic++ 20:20
cotto_work yes. chromatic++
20:20 zerhash joined
dalek tracwiki: v5 | kurahaupo++ | ArrayTasklist 20:21
tracwiki: more related tickets, plus details
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
shorten dalek's url is at xrl.us/bfqrhc
dukeleto i am all about rallying and getting pcc_reapply merged in for 1.7 . let me know what I can do to make this happen. 20:26
cotto_work hands dukeleto a whip and points at Tene
dukeleto so, we are down to 58 failed tests in coretest? 20:29
Tene dukeleto: please feel free to harass me daily or more to work on pcc. I'm at work right now, so don't have the concentration, but I should be home in 3 or 4 hours.
pmichaud hugme help 20:30
hugme: help
oops, wrong chan
dukeleto hugs pmichaud anyway 20:32
Tene: ok, you asked for it :)
cotto_work dukeleto, I imagine that understanding the algorithm that fill_returns is trying to implement would be helpful too, in case Tene++ needs another set of eyes. 20:36
Tene cotto_work: the alg is on the wiki, approximately.
cotto_work yup
dukeleto which page on the wiki?
the calling convention overview? 20:37
cotto_work dukeleto, yes
I wonder why we're implementing all these fancy calling conventions when we know they won't be sufficient for our poster child Rakudo. 20:38
dukeleto cotto_work: good question. care to expand? Why are they not sufficient?
cotto_work I don't know the details, but I remember pmichaud saying something to that effect recently. 20:39
jonathan Actually, all Rakudo really wants is raw access to the CallSignature.
moritz there's one thing that isn't supported by parrot right now which rakudo needs: calling a positional argumet by name
jonathan (And in the long run, that the CallSignature doesn't put the nameds into a hash.) 20:40
moritz consider sub foo($a, $b, $c). in Perl 6 you're allowed to call foo(1, 3, b => 2)
jonathan moritz: We're going to have a custom binder for Rakudo anyway, so it's now irrelevant to Rakudo whether Parrot does this or not.
moritz and that will mean $a => 1, $b => 2, $c => 3
jonathan It may be interesting to other HLLs.
But Rakudo is very much going its own way. 20:41
The main important thing about the refactor is that all calls populate a common data structure (the CallSignature) that Rakudo can then take and process as it wishes.
I the end, I've concluded it's just unrealistic to expect Parrot to support all of the ins and outs of Perl 6 signature binding. 20:42
cotto_work I know Pipp won't care in the slightest, but that's just because PHP only supports positionals iirc. 20:43
mikehh pcc_reapply - there have been 123 commits to the branch since it was created (inclusive) as follows: 20:46
20:49 bluescreen joined
dukeleto msg japhb my gitorious username is 'leto' 20:50
purl Message for japhb stored.
Tene cotto_work: embrace and extend? ;)
dukeleto if I am going to add new tests to CallSignature, should it be done in trunk or pcc_reapply ? 20:53
moritz I think pcc_reapply makes more sense (but IANARPH) 20:54
dukeleto moritz: i think i figured out your TLA :) 20:57
ug
not TLA, but acronym
moritz "I Am Not A Real Parrot Hacker"
dukeleto moritz: but you are :) 20:58
20:58 Whiteknight joined
darbelo dukeleto: Have you met him? How do you know he's real? 20:58
japhb dukeleto, welcome to plumage
moritz dukeleto: not really; I committed some tests, coding standard fixes and doc fixes, but I never touched the "real iron"
dukeleto japhb: shweet. i am assuming I need to set up some ssh keys on gitorious to start committing 20:59
20:59 joeri left
japhb dukeleto, It's been a while since I set up my account, but I would assume the same thing. ;-) 21:00
allison cotto: that's a good question, since many of them were added for Rakudo
dukeleto moritz: well, I still consider you a parrot hacker as well, but I understand. i have mostly only worked on the perl 6 test suite, not the real iron. I wrote the roots() builtin for rakudo, but that got refactored :)
allison reading scrollback
dukeleto allison: where is the best place for new CallSignature tests? trunk or pcc_reapply ? 21:01
allison cotto: I'd say the chances of most languages using named, slurpy, optional, etc returns are pretty slim
dukeleto: t/pmc/callsignature.t
oh, pcc_reapply
since, there are more features implemented there than in trunk, and we want all of them tested 21:02
cotto_work allison, they're mostly for internal (i.e. pct) use then?
dukeleto allison: thanks
allison cotto: well, they were added for Perl 6, back in the day
mikehh I forgot to post the numbers - for pcc_rrapply branch - commits to date:
allison cotto: but, if Rakudo isn't using them, maybe we can just rip them out 21:03
mikehh bacek (49). allison (32), whiteknight (15), mikehh (11), jkenan(9), tene (3), NotFound(2) and 1 each by dukeleto and moritz
allison cotto: it would substantially simplify our calling conventions
pmichaud pct and pge still want them
allison cotto: (cleaner, faster, more maintainable code)
mikehh I think I got everyone
dukeleto mikehh: do you have a script for that?
allison pmichaud: all of them, even on the returns? 21:04
NotFound mikehh: There is some prize for the most commiter?
mikehh not really - just collected the commits to the branch and counted
pmichaud allison: we certainly want :slurpy and :optional
allison pmichaud: returns or calls? 21:05
pmichaud returns
jonathan I'm think Rakudo may be using slurpy named returns.
pmichaud sometimes we don't know how many values are being returned, we need to collect them all into a pmc
allison pmichaud: fair enough (though I'm really curious what the code is doing)
dukeleto moritz: your blog post perlgeek.de/blog-en/perl-6/parse-tree.html says "Mosse" instead of "Moose"
mikehh just that there were a lot of commits to that branch since last week - not counting what allison did before 21:06
chromatic Macro line numbers work right now, per my tests. 21:07
allison pmichaud: once we merge calls and returns into one code set, we get all those options for free, so it's not really a big deal
darbelo chromatic++
pmichaud allison: that's what I would hope for, yes. :) 21:08
mikehh NotFound: we need to find something for bacek++ 21:09
NotFound bacek++ 21:10
chromatic I'm pondering a branch to add STRINGNULL. 21:11
dukeleto chromatic++ # i loves me some correct line numbers
chromatic: go for it
darbelo +1
purl 1
dalek TT #1016 closed by chromatic++: PIR line number wrong in stacktrace.
chromatic We need it, no question.
The only question is "Yow, PCC refactoring!"
dalek rrot: r41742 | chromatic++ | trunk (8 files):
[IMCC] Improved IMCC line number tracking, especially in macros and other

Fixes TT #1016. Note that macros have slightly more tests now, because they're the tricky part. POD and heredocs may need more testing too.
21:12
mikehh chromatic: I forgot to mention - what can we do about STRING_CONST - breaks all linelength restrictions?
chromatic Beg and plead with stupid C compiler vendors to consider supporting C99 sometime this millennium. 21:13
mikehh I meant to ask in #ps but forgot
chromatic The problem is (and you'll love the irony of synchronicity) that some C compilers don't understand the #line directive in macros. 21:14
mikehh its M$ mainly afaik
chromatic By "understand" I mean "Know how to track line numbers in".
Clang had trouble there too, but there's a chance of getting that fixed.
japhb chromatic: Does this fix tools/util/dump_pbc.pl 's problem listed in the BUGS section in the POD at the top?
s/this/the IMCC line numbering fixes/
chromatic japhb, I haven't checked.
If not, can you work up some test cases? 21:15
japhb Would be nice if it did.
chromatic, once upon a time, I had some notes on examples, but I have since lost those notes.
I could try a before and after and see if I can catch it.
chromatic That would be very helpful. 21:16
I fixed a bug (well, removed a workaround) where the line number for certain opcodes in certain situations would be one line too low.
japhb That sounds like it might match. It was causing the opcodes to appear just before the source line rather than just after. 21:17
chromatic Heredocs and macros are two big culprits. POD may have an effect too. 21:18
21:20 nopaste joined
japhb OK, the "before" case with r41734 was still showing the old problem. Compiling r41742 now to test "after". 21:21
allison Tene: some logic fixes and an explanation of the reasoning in r41743 21:22
dalek rrot: r41743 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Some logic fixes to the returns handling. Even though args==returns and

substitution, because the logic is reversed for return/result handling. So, fill_results needs to iterate over the array of results and the flags from the returns. (This is the reverse of arg/param handling, which iterates over the array of args and the flags of the params.) The fill_results function currently also has to track the flags of the results, to detect slurpy results. It would be better to mark "slurpy" on the CPointer, so we don't have to track two data structures to get the result information.
allison Tene: that's all from me tonight, so I'll hand it off to you 21:23
Coke chromatic: holy. crap. 21:24
chromatic You saw me beat up a scarecrow? 21:25
Coke no, you closed an issue I opened on 08/16/06
chromatic I can revert if you want to reopen it.... 21:27
masak hm, PIR's local_branch/local_return are like BASIC's GOSUB/RETURN, right? except within the same sub. 21:28
bacek_at_work Good morning again 21:30
japhb chromatic, I don't think it's fully fixed. Comparing before and after, I see some numbering better, and some worse. 21:32
chromatic I'm not surprised. 21:33
japhb chromatic, I used ./parrot -o triangle.pbc examples/opengl/triangle.pir to generate a pbc file before and after, ran perl tools/util/dump_pbc.pl triangle.pbc > dump-triangle on both, and then did a diff --side-by-side.
Clearly better is the construction: .const 'Sub' foo = 'foo', which now seems exactly right. 21:34
One of the 'clearly worse' is: .local pmc foo; foo = new 'Integer'; foo = ... 21:35
chromatic Which line in triangle.pir?
japhb And .param isn't changed at all, I think.
Let's see. lines 37-40 21:36
lines 54-56
21:36 bluescreen joined
japhb that kind of stuff 21:36
On the flip side, lines 59-62 were a big improvement 21:37
chromatic 37-40 look correct for me.
japhb Lemme nopaste what I see
nopaste?
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) 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) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
nopaste "japhb" at 76.191.190.8 pasted "Lines 37-40 in examples/opengl/triangle.pir disassembly" (13 lines) at nopaste.snit.ch/18241 21:39
japhb (Mind you, I'm coming back to this bug from a lot of months not looking at it, so I could have my neurons crossed.) 21:40
chromatic I'm comparing the dissasembly to the .pir file itself.
Everything I've looked at matches.
japhb So you think the weave is fubar? 21:41
chromatic Oh.
Hm.
I wasn't even looking at the right thing. 21:42
japhb :-)
chromatic I was reading the annotations only and they all matched, for obvious reasons.
21:42 Whiteknight joined
chromatic How certain are you that the weave is correct? 21:43
japhb About 70%.
The entire weaver is only a few dozen lines, though, so it's not like a rat's nest. 21:45
chromatic If you want to add some tests to t/compilers/imcc/syn/regressions.t (or start a new file), I'll do my best to make them pass. 21:46
My best approach so far is to make deliberate syntax errors and check the line number there.
japhb chromatic, I'll see what I can manage. I've got some $day_job stuff to do before I can throw serious tuits at it, though. 21:47
21:51 jsut_ joined
chromatic Me too. 21:52
cotto_work clearwire-- 22:06
dukeleto can someone suggest a very simple test case that I could write for CallSignature ? 22:12
cotto_work "Will it float?" 22:13
chromatic Does it work? 22:14
purl i guess Does it work is it used? =-)
chromatic Is there pie?
darbelo Will it blened?
cotto_work PMC smoke. Don't breathe this. 22:15
dukeleto wow, i haven't gotten that many snarky answers in a row in while :) 22:16
chromatic We know you're not Chuck Norris. Drop the fake beard.
japhb Yes, but is he Bruce Schneier? 22:17
dukeleto chromatic: what is the simplest possible thing that I can test CallSignature for, from PIR?
chromatic: other than instantiation 22:18
cotto_work maybe call a sub in raw mode and test that the CallSignature has what you expect?
chromatic Getting and setting short_sig.
Getting and setting type_tuple.
There's not much else in the PMC.
cotto_work has the rest of it. 22:19
22:19 kid51 joined
dukeleto chromatic: ok, that give me some direction 22:19
s/give/gives/ 22:20
allison dukeleto: also integer keyed access to positional arguments and string keyed access to named arguments 22:21
dukeleto allison: gotcha
cotto_work btw, what's the proper name for raw mode?
:call_sig?
GeJ Good morning everyone 22:22
everyone Good morning GeJ 22:23
allison cotto: not defined yet (and won't be implemented in this branch), but something like :call_sig
cotto: it would be nice to have a name that's more immediately obvious what it's doing
cotto: but haven't thought of one yet 22:24
cotto_work Thanks. I was curious if there was some code I could look at now.
allison cotto: (admittedly I haven't spent more than 5 minutes thinking about the name yet)
cotto_work we can just ask TimToady when the time comes 22:25
allison cotto: it's something along the lines of "let me look at the guts" 22:26
chromatic :eviscerate
:abattoir 22:27
:tripe
:divine
NotFound :anything
chromatic :meteorology
cotto_work :raaw
chromatic (subtle)
:velociraptor
allison chromatic: eviscerate would be a good replacement for :flat :) 22:28
chromatic stifles the question "How offensive, on a scale of one to ten?"
cotto_work I'd like to see some more colorful language in pir.
NotFound :asyouwish
allison chromatic: so far, I'm favoring 'dissect'
(for :flat) 22:29
NotFound :catchfire
chromatic You could go the Thomas Friedman route and mistake :flat for :hasuniformsizedshippingcontainers, but that's more of an :autounbox (very subtle). 22:30
allison :)
chromatic Maybe not that subtle; I suspect most people in here did not fail geometry. 22:31
cotto_work We could go the surrealist route with :giraffe 22:32
allison :escher
NotFound :bycommitee 22:33
chromatic :derrada
NotFound :finnegans
dukeleto :iwanttoknowhowparrotsausageismade 22:34
NotFound :xkcd
dukeleto gets hungry thinking about Parrot sausage.
bacek_at_work :twofingers
NotFound What about just :pcc ? 22:35
jonathan allison: Does the branch still have the nameds going into a hash in the call signature PMC?
Or more useful for me to know: is fixing that a post-branch task, or an "in this branch" task? 22:36
cotto_work NotFound, it's basically bypassing most of pcc.
allison nameds go into a hash
jonathan It seems like it'd be easier to get right in the beginning, but if it's going to delay the branch, I can deal with that.
allison what's the fix?
purl i think the fix is " return @_ if $self->{PERL_SRC};" as the second line of MM_Win32::arch_check - but I'll mail a patch unless I forget
dukeleto purl, forget the fix 22:37
purl dukeleto: I forgot fix
NotFound cotto_work: Is just :makeyourownpcc abreviated ;)
jonathan allison: nameds going into a hash don't allow custom argument processors that can do something useful/interesting with multiple named arguments with the same name.
allison jonathan: that is, I don't have any plans to move named args out of a hash
jonathan allison: OK. What are the semantics of a call with multiple arguments of the same name? 22:38
allison well, you'll have the option of passing in your own call signature object and pulling it out on the other side
as far as parrot arg processing is concerned, that's an error
dukeleto i am getting "FixedIntegerArray: index out of bounds!" all over the place on the pcc_reapply branch, is that normal?
jonathan When is it an error though?
allison dukeleto: that's from return handling, which is in active development
jonathan I mean, at the moment that's a binding time error, afaik, not a call signature construction time error. 22:39
(e.g. callee side, not caller side)
allison jonathan: it's an error right from the start
jonathan It seems the change would make it caller side?
Today, or in the branch?
allison jonathan: what change?
purl change is, like, very minimal as you can see in the js, so what you suggests seems like a good alternative
jonathan allison: IIRC, today it's not an error until the callee does get_args. 22:40
allison: Anyway, what's really behind this is that if all the nameds go into a hash rather than a list of "name, value, name, value, ..." like trunk has it today, then Parrot's CallSignature gets rather less useful for Rakudo. 22:41
dukeleto allison: i get that error when loading test_more.pir, so that is kind of a blocker
jonathan So not only will we have to process the CallSignature ourselves, but also we'll have to build our own one.
allison jonathan: that's because Parrot currently doesn't do any processing at all until get_params
it just holds on to the opcode pointer or varargs list until the parameter setting 22:42
nopaste "dukeleto" at 70.102.219.22 pasted "Simple program complains about "FixedIntegerArray: index out of bounds!" on pcc_reapply" (11 lines) at nopaste.snit.ch/18242
jonathan allison: Yes, indeed.
allison dukeleto: yes, it's a known failure in work in progress, and we checked it in so we can work on it together
dukeleto allison: ok, just trying to get up to speed 22:43
jonathan allison: I'm fine with that changing, for the most part.
allison jonathan: as far as I can tell, you're planning on doing all your own argument processing anyway
jonathan allison: My concern is that building a hash rather than a "name, value, name, value" style list will cause some pain.
allison jonathan: you realize, of course that I only put them in a hash in the first place because that's what Rakudo wanted 22:44
jonathan allison: Yes, but I was expecting to just be able to process the default Parrot CallSignature.
allison: I'm kinda confused. Yes, a capture *does* (I agree) expose a hash interface to the parameters. 22:45
However, it's also spec'd as preserving the original call information.
allison jonathan: you can't have it both ways
either you have quick access to parameters by name 22:46
or you have a strict preservation of original order
jonathan Yeah, true.
dukeleto does anybody have any ideas about how to get test_more.pir to work on pcc_reapply? It is hard to write tests without it ...
jonathan Trouble is, Perl 6 cares about knowing the original order.
Which is kinda irritating. 22:47
(It also cares about binding in signature, not calling, order.)
chromatic rejects the default assumption that hashes are quick
allison well, talk to Patrick about it and decide what's most important
dalek tracwiki: v22 | dukeleto++ | CallingConventionsOverview
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
allison then get back to me
shorten dalek's url is at xrl.us/bfqrzj
allison and, it may make the most sense for you to just do your own call signatures for a while until the ideas mature
if something good comes out of it, we can always work it into core parrot later 22:48
jonathan allison: Will there be a way to do :call_sig on the caller side too?
Tene dukeleto: I can look at it when I go home in about an hour.
jonathan Or whatever the name is...
allison jonathan: yes, it works on both sides
jonathan allison: OK, that makes doing our own thing more workable.
allison just foo(myarg :callsig)
or whatever
jonathan allison: OK, I can likely work with that somewhat.
allison jonathan: that's the goal 22:49
(making doing your own thing workable)
jonathan I do worry that the default being a hash may be trick for language interop though.
*tricky
allison jonathan: very few languages use named parameters anyway
jonathan Generally, I'd expect the restrictions on arguments to be something the callee cares about, not the caller.
allison and the ones that do are pretty basic about it
jonathan: we don't guarantee that we'll always use a hash for storage internally
jonathan Perl 6 and pretty basic rarely go in the same sentence. ;-) 22:50
allison: OK, that makes me feel a tad easier too, if it's not API that we do it that way.
allison jonathan: we only guarantee that we'll provide a hash interface on the call sig
jonathan OK.
allison (and ask that you do the same on your custom call sigs for anything that might be exposed outside Perl 6)
Tene allison: curious... if we can get pcc merged, how much longer before you get :vtable('invoke') working in PIR classes?
allison in PIR subclasses? 22:51
Tene I remember you saying that PCC was a requirement before you could start working on that.
in any PIR classes.
jonathan allison: OK. I think if :call_sig can land not too long after the branch merge (I can likely help get that in place, or get it added myself, since in theory it's simple) then I think I'm set. :-)
allison it's not on my list, but IIRC, the big obstacle was providing access to all the right arguments from within the user defined code 22:52
Tene: so it should be pretty straightforward
Tene Okay.
jonathan I do feel that hash as the default isn't going to be the right way to go. But since that's not API, and I really, really don't want to hold this branch up by suggesting more changes now, I'm happy to settle with the fact that I'll be able to build my own call signature. 22:53
And/or that it may change in the future.
Tene allison: have you looked at the problem in build_sig_returns when specifying named returns in pcc branch?
allison Tene: not yet, but I'm pretty sure there's no code there to handle named returns 22:54
dukeleto Tene: that would be awesome. as long as I can write tests, I can be useful on pcc_reapply. If not, I am not so sure.
allison Tene: (at the time I wrote that code I was thinking "Hey, it'd be interesting to have named and slurpy returns eventually", instead of "we have to support this because trunk does") 22:55
Tene: I'm off for the evening (up for classes in 7 hours)
Tene goodnight, allison.
allison Tene: if you check in any changes you make, I'll start up where you left off tomorrow
Tene allison: confirm, fill-returns is currently in pcc branch, or no?
allison Tene: yes, it's checked in, and I've checked in further fixes 22:56
Tene Okay, great. exactly what I wanted.
22:56 TiMBuS joined
allison Tene: if you want to give dukeleto some relief, you could make the choice between the old and new code an ifdef inside fill_returns_from_op 22:57
Tene Oh, true. I might try that.
allison (i.e. it either does all the old code (which was pretty basic), or it calls fill_results
chromatic Is that a temporary workaround? 22:58
22:58 tetragon joined
dukeleto 'make coretest' currently goes into an infinite loop in t/pmc/namespace-old.t for me. has anybody else seen this? 22:58
on pcc_reapply, that is
allison chromatic: yes, just for a day or two so dukeleto can write tests while we finish the last feature
Tene chromatic: Yes. The new code still doesn't work in some pretty basic cases.
chromatic Thanks for confirming. 23:00
23:08 cotto joined
cotto_work wb, cotto 23:08
23:08 jsut joined
cotto_work .o0(I really need to find a better ISP.) 23:09
dukeleto jsut: howdy 23:11
Whiteknight missed a lot of good chat. Backlogging 23:14
Tene: :vtable('invoke') should be much easier after this
I have a few ideas, but want to wait for the dust to settle first
Tene rather.
dukeleto Whiteknight: yeah, busy day 23:15
Whiteknight the biggest issue from the PIR perspective is getting access to the "self" variable 23:16
Of course, there is a semantic issue about what "self" should refer to inside VTABLE_invoke
Because "$P0()" has the same invocant as "$P0.'method'()", but a different Sub 23:17
23:17 coke joined
coke (named parameters) tcl's are "positional with names"... but I pretty much have to hand roll all my argument processing because parrot won't let me create my own error message if the args are wrong. 23:18
(we even have a slurpy mode.)
jonathan Whiteknight: I did an epic hack to make invoke overridable in Rakudo, while waiting for the Real Answer. :-) 23:21
dalek kudo: 41bc84f | jonathan++ | (6 files):
Extensive re-working of the way we generate signatures in actions.pm. Now we build an object representing the signature at compile time, and then use a method on it to do the code generation. This neatens up actions.pm a little, but also means it'll be easier to change signature building later (since only one method will need to change, in theory).
23:22
kudo: d39a7de | jonathan++ | src/parser/ (2 files):
Fix a couple of readtype bugs, which deals with many of the failures from the signature changes.
kudo: 0f4d0cd | jonathan++ | (4 files):
Couple of other extra fixes to get us handling the spectests again.
shorten dalek's url is at xrl.us/bfqr45
shorten dalek's url is at xrl.us/bfqr47
dalek's url is at xrl.us/bfqr49
Whiteknight jonathan: awesome. I'm sure it's going to be an epic hack to make it work right in Parrot too 23:23
chromatic How's Rakudo startup with that? 23:26
23:27 TonyC joined
jonathan chromatic: This is the change that will let me more easily do the change that should make startup better. :-) 23:28
chromatic: In this, I isolated signature code generation in one place. 23:29
23:29 Austin joined
jonathan chromatic: So now the next step should be easier. 23:29
23:30 Ruiloff-on-off joined
chromatic Very nice. 23:31
Austin PIR question: Is there a difference between calling 7 find_method $S0 and just using the 7 object.$S0(args...) syntax?
Tene Austin: I'm really starting to like you use of color to denote quotes on IRC.
Austin :)
Thanks. 23:32
Tene :P
cotto_work You go too far, sir. 23:33
Austin Reverse doesn't show up for me. :| Probably for the best.
dalek kudo: 8d63378 | jonathan++ | (2 files):
Stub in P6LowLevelSig PMC.
shorten dalek's url is at xrl.us/bfqr6x
GeJ allison: Just so you know : `make coretest` in latest pcc_reapply hangs indefinitely in t/compilers/imcc/syn/regressions.t 23:34
cotto_work GeJ, it's known goofy atm 23:35
GeJ Ah, okay. Sorry for the noise then. 23:36
cotto_work GeJ, no worries.
Austin What word is the opposite of :flat in an arg-expression? 23:37
That is, if I have 7 sub foo(*@args) , the args parameter is slurpy. But the array itself is ... "slurped", "collected", ...? 23:38
darbelo the slurpee? 23:39
chromatic Splattened
Austin darbelo: I'm looking for a state, not a pronomial.
darbelo Oh, my bad. Slurpificated, then. 23:40
Austin So I would have 7 sub foo_splattened(@args) as the alternative target? 23:41
There's a certain symmetry there, I guess: flattened and splattened.
dukeleto GeJ: i emailed parrot-dev about pcc_reapply looping on "make coretest" 23:54
23:55 patspam joined