Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
00:04 davidfetter joined 00:08 AndyA joined
cotto eew. Good luck with that one. 00:10
chromatic It's doable, but first I have to mock something. 00:12
bacek_at_work hi again. 00:22
purl oh, you're back!
pmichaud wonders what/who chromatic will mock this time :-)
chromatic The DarkPAN. 00:25
purl rumour has it the darkpan is the 90% of modules that you can't see, because they're not on CPAN. The dark matter of the Perl world
00:32 skids joined
pmichaud chromatic: so far the patch in TT #800 is working great for rakudo (without ICU) 00:42
also, all parrot tests pass (without ICU)
so I think it's good, provided we don't need a deprecation cycle for it :-) 00:43
chromatic I can't imagine why we would.
pmichaud <p5p> Well, there could be some applications out there that expect the command line arguments to come in as fixed_8, so we can't change it </p5p>
chromatic Oh, don't tempt me.
pmichaud :-P 00:44
anyway, I'm happy with the patch; +1 from me.
chromatic "My code has to run on several different major versions of Perl; I can't take advantage of these new features."
"You have a change management problem. Not me."
00:46 kid51 joined
dalek rrot: r39863 | chromatic++ | trunk/src/embed.c:
[src] Changed Parrot's command-line argument processing to treat command-line

See TT #800. (This needs a test case.)		 00:47
01:03 nopaste joined
dalek rrot: r39864 | Infinoid++ | trunk/t/op (2 files):
[t] Un-TODO some tests on openbsd per report in TT #758. reezer++
 01:04
chromatic Okay, making the JIT work there is trickier. 01:17
For primitive out parameters, we have to save the pointers we may have converted to the primitives, then after the call perform the assignments back to let argument conversion handle them again. Lovely. 01:18
japhb is hoping that by some magic chromatic's work will make OpenGL and NCI JIT get along again ... 01:21
chromatic I doubt it.
01:21 smash joined
smash hello everyone 01:22
kid51 Howdy, smash, you fine fellow!
.... as purl used to say :-)
smash hehe 01:23
davidfetter wonders whether rsrsrs is also a portuguese thing 01:57
chromatic INCOMING 01:59
purl i guess INCOMING is pause.perl.org/incoming/
dalek rrot: r39865 | chromatic++ | trunk (2 files):
[NCI] Revised tools/build/nativecall.pl so that src/nci.c only builds the NCI

build call frames. This reduces the size of src/nci.o by 86.65% and the size of libparrot by 5.58%.		 02:01
02:04 silug joined
jdv79 chromatic: what tools do you use when you profile and/or trace parrot? 02:22
chromatic callgrind and kcachegrind 02:24
02:39 zak_ joined 02:42 mikehh joined
cotto Heh. Slashdot is broken. 02:51
I may have to find something productive to do.
and it's back 02:52
smash & 03:13
03:16 Theory joined 03:17 Zak joined
dalek ose: r37 | Austin++ | trunk/src/ (4 files):
Added 'clone' builtin
 03:24
03:31 japhb joined
dalek ose: r38 | Austin++ | trunk/ (9 files):
Moved PCT::Node stuff, started on test cases
 03:34
ose: r39 | Austin++ | trunk/t/library/PCT:
Dropped PCT
 03:44
ose: r40 | Austin++ | trunk/t/library/pct (4 files):
Re-added PCT one level down
 03:49
04:05 Andy joined 04:07 cognominal joined 04:53 Andy joined
dalek TT #778 closed by allison++: Make FileHandle Subclassable 04:58
05:50 Austin joined
Austin Howdy. 05:50
pmichaud: ping? 05:51
05:51 uniejo joined
Austin bug bug bug 05:55
06:14 clunker3 joined
cotto where? where? where? 06:18
too late
06:27 barney joined 06:30 flh joined
Tene Aw, he's gone 06:55
dalek tracwiki: v6 | cotto++ | RewritingPMCsInNQP 07:00
tracwiki: change existing example to minimize changes to nqp, add pmc_new
purl dalek: that doesn't look right
dalek tracwiki: trac.parrot.org/parrot/wiki/Rewrit...ction=diff
cotto < purl-- > 07:02
purl, dalek is a bot 07:03
purl ...but dalek is #parrot's spammy little rss bot or (see: dalek plugins)...
cotto purl, sudo dalek is a bot
purl OK, cotto.
cotto <3 parallel testing 07:04
is META.yml of any further use? 07:08
dalek rrot: r39866 | cotto++ | trunk (10 files):
[ops2c] remove OpTrans::Compiled, which was only used by a tool removed back in r28978
 07:09
cotto That "Compiled" runcore is an interesting idea. It doesn't sound entirely unlike what we're aiming to do with L1 jitting. 07:10
07:18 iblechbot joined
bacek_at_work cotto: how is you ops2c groking going? 07:37
cotto bacek_at_work, I have a basic idea of how it works and am starting to think about what the architecture for the replacement should look like. 07:40
I still don't have a good name. 07:41
"cops" has potential for puns, but doesn't have much flair.
bacek_at_work grok - Gready Ops Kompiler
cotto I'd prefer not to incorporate misspellings into the name 07:42
and an infinite recursion would be nice
but that's secondary and I'm not at the point where I have to start writing code anyway. 07:43
bacek_at_work ok. Remember, you promised to put something before next #ps :) 07:44
cotto I said I hoped to do that. 07:45
but yeah, that's part of my goal 07:46
bacek_at_work ok-ok. Wanna grammar for current ops? As starting point.
cotto Heh. The grammar is probably the easiest part.
I'm actually looking forward to writing it. 07:47
bacek_at_work That's why I offer it ;)
cotto NO. IS MINE. YUO NOT CAN HAS.
bacek_at_work nopaste? 07:48
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 somebody said nopaste was 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/
nopaste "bacek" at 211.29.157.151 pasted "ops grammar for cotto" (43 lines) at nopaste.snit.ch/17088 07:49
cotto That's a lot less than 43 lines.
bacek_at_work :) 07:50
There is 41 empty lines for you to fill
cotto um... thanks?
bacek_at_work YOU WELCOME 07:51
cotto btw, how's your nick pronounced? 07:54
bacek_at_work pronounced own nick loudly, hoping cotto can hear it 07:55
cotto listens carefully but doesn't hear anything 07:56
bacek_at_work Can you give me idea how to explain it? :) 07:57
cotto Just use sounds from other English words. 07:58
bacek_at_work b as in buck 07:59
a close to "u" in buck 08:00
c as in "cent"
e as in "cent"
k is just k
cotto that works. Thanks. 08:01
bacek_at_work paid 15K to Tax Officce recently...
cotto ouch
szbalint australian dollars?
purl australian dollars are nearly at par with Canadian dollars.
szbalint it's still a nice pile...
bacek_at_work szbalint: is there any other dollars?
cotto lots 08:02
bacek_at_work and they somehow useful???
szbalint I wouldn't mind paying 15k in taxes if it's in zimbabwean dollars
bacek_at_work "k" in zimbabwe stays for "kilograms"
cotto bacek_at_work, en.wikipedia.org/wiki/Dollar#Nation...2dollar.22 08:03
I think catpenny is my favorite measurement of currency
www.bash.org/?743428 08:04
08:04 mikehh joined
cotto catpenny? 08:05
purl i think catpenny is your favorite measurement of currency
cotto catpenny is also www.bash.org/?743428
purl okay, cotto.
cotto catpenny? 08:07
purl well, catpenny is your favorite measurement of currency or www.bash.org/?743428
bacek_at_work ok, time to go home and make some dinner 08:08
cotto yay food 08:09
bacek_at_work yay, I missed my lunch today...
cotto Wow. ops code gets mangled into some impressive ugliness.
bacek_at_work erm... I expected it should' be just some wrapping around without touching c-body... 08:11
cotto saying that the c-body gets touched is an understatement 08:12
bacek_at_work I've got naming idea. 08:13
cotto but I think that the code can be much simplified by making the parser aware of the ops-specific constructs
do tell 08:14
bacek_at_work "COCK" is Ops Crushed and Killer
afk &
cotto so...many...puns... 08:15
yet so inappropriate
chromatic Yeah, that one's on my "Keep Looking" list. 08:16
cotto If he snuck in Russian profanity we might not know until it was too late. 08:18
chromatic That's why we have Jonathan. 08:19
szbalint I know one thing, never try to find a dermatologist in russia 08:20
:)
cotto ? 08:21
szbalint for the same reason democrats are sometimes spelled dermocrats 08:23
mikehh make fulltest PASS at r39866 - also pre/post config, smolder - Ubuntu 9.04 Amd64 08:37
08:42 bacek joined 08:43 janus joined
bacek hi again 08:44
purl oh, you're back!
janus howdy 08:46
bacek Howdy, janus, you fine fellow! 08:52
purl: see! Why I have to your job, stupid girl?
purl i haven't a clue, bacek
cotto Does anyone know offhand what the purpose of src/ops/ops.num is? 08:53
bacek cotto: make your life harder? 08:54
cotto It seems intuitively that ops could be sorted and numbered without the need for an extra file (especially since it needs to be updated manually), but I haven't dug deeply enough to figure it out either way. 08:56
08:57 zak_ joined
bacek ops.num is mapping between op name and pbc/switch statement in generated code. 08:59
basically - useless from my pov
cotto That's what I'm thinking too, but I definitely don't have the brainpower to remove it.
bacek, feel free to do it if you want to, otherwise I'll tackle it tomorrow. 09:00
It's nice to simplify existing code.
night 09:01
bacek night
jonathan ops.num is to do with PBC compat - it lets us keep opcodes having the same number, and means new ops can be given numbers greater than those of existing ones. 09:02
bacek jonathan: # - deleting/changing/inserting existing ops in ops.num 09:11
It's from PBC_COMPAT.
So adding/removing ops will give incompatible PBC with older version anyway
jonathan OK, but the assumption isn't that Parrot will only ever be able to handle bytecode files of one version, or at least that we'll have tools. 09:15
And they'll be vastly easier to write if new opcodes just go on the end of the existing set.
bacek Agreed. But looks like L1 approach will make it deprecated. 09:17
09:25 masak joined 09:35 MoC joined 11:32 bacek joined 12:17 Whiteknight joined
afk_coke msg cotto if you're not sure how it works, you can still make sure it compiles. (same trick as we use in pod examples.) 12:33
purl Message for cotto stored.
Coke L1 is also magical unicorns and flying puppies. 12:52
purl okay, Coke.
13:01 skids joined 13:05 Andy joined
Coke sees a "let's blame Larry Wall" thread in the cfeclipse-users mailing list. 13:18
Coke ponders enabling a kibo-by.
13:21 mikehh joined 13:23 ruoso joined 13:31 ruoso joined 13:33 szabgab joined 13:38 ruoso joined 13:40 ruoso joined 14:17 ruoso joined 14:25 eiro joined 14:27 eiro joined 14:32 mikehh joined
Whiteknight allison++ # kicking ticket ass 14:33
14:36 amuck_ joined 14:48 Theory joined 14:59 davidfetter joined 15:02 maettu joined
dalek TT #802 created by mberends++: freeze opcode segfaults on working bytecode from Rakudo 15:21
kudo: ec68db8 | jnthn++ | src/pmc/perl6multisub.pmc:
When we're analysing a candidate, record at that point whether we can make a purely nominal type decision or if we'll have to do a bindability check. (Later we can probably use this as a cache criteria.)
 15:27
kudo: dcf4c6d | jnthn++ | src/ (3 files):
Part one of an extensive refactor of multiple dispatch. This fixes various issues with binding more compex signatures. On Win32 at least, a few more tests trip up on the Parrot GC heisenbug. Also regress one C<is default> test that I suspect may be dubious anyway.
 15:33
16:05 Austin joined
Coke rakudo: 3??1::0 16:07
polyglotbot OUTPUT[ResizablePMCArray: Can't pop from an empty array!ā¤in Main (src/gen_setting.pm:3279)ā¤]
Coke pmichaud: (for you.)
Austin pmichaud: ping?
Coke pmichaud: (yes, I know that's invalid syntax)
pmichaud: moving to #p6, nevermind. =-) 16:08
16:26 darbelo joined
Tene Austin: ping? 16:27
pmichaud Austin: pong
afk, lunch 16:32
16:35 chromatic joined 16:38 Psyche^ joined 16:45 davidfetter joined
Austin Tene: pong 16:50
16:50 Andy joined
Austin msg pmichaud Sorry, I was slaving away on a new ticket. 16:50
purl Message for pmichaud stored.
dalek TT #803 created by Austin_Hastings++: PCT emits bogus code for getattribute on named register variable
16:53 Austin_Hastings joined
Austin_Hastings Tene: pong? 16:56
Austin moo. 16:57
dalek ose: r41 | Austin++ | trunk/build/Makefile.in:
Added script for running tests
 16:58
cotto Do we still need META.yml? 17:01
messages erase
darbelo cotto: delete it and see what breaks. 17:03
dalek cnum-dynpmcs: r98 | darbelo++ | trunk/t/ (4 files):
Switch some tests to use IEEE 754 comparisons.
 17:07
rrot: r39867 | cotto++ | trunk (2 files):
[examples] move PGE demo to examples where it'll be tested for compilability automatically
 17:12
Coke hurls rt.perl.org/rt3/Ticket/Display.html?id=63592 for a pure PIR segfault. 17:24
enjoy.
chromatic META.yml is for the CPAN/PAUSE.
cotto istr that we're not doing CPAN releases anymore. 17:26
Coke we are. 17:27
just on stable. 17:28
s/stable/supported/
cotto Coke, I don't see anything about that in the release manager guide. 17:30
Coke cotto: based on conversations with allison.
NotFound Coke: RT #63592 is not a bug, is a feature ;) 17:32
jonathan Coke: At a quick glance under the debugger, looks like stack overflow.
cotto Coke, could you update the guide?
NotFound Is just the way we handle exceptions from C, together with the fact that the majority of exceptions are thrown from C 17:34
BTW, Parrot_str_substr perldoc says nothing about what does on error conditions. 17:37
17:37 Austin left
Coke cotto: no, but I can open a ticket to make someone else do it. 17:39
NotFound Neither pdd28
Coke I do find it interesting that the original while loop isn't checking that it's just generating an infinite amount of FAIL. 17:40
NotFound What perl6 substr is supposed to do?
Coke rakudo: 0.substr(-10)
polyglotbot RESULT[undef]
pmichaud darn, Austin left again.
Coke but that undef is really a Failure, which creates a new Exception. 17:41
so that perl6 sample code is just a way to show off memory leaks. =-)
NotFound Is not a memory leak.
Ah, you mean, if it worked. 17:42
Coke ?
it's a do nothing loop. just generates undef each time through.
you're right, it's not blowing the memory, my bad. 17:43
jonathan: if it's stack overflow, doesn't parrot already trap for that? 17:44
NotFound Let me rephrase it another way: What rakudo substr expects parrot substr will be doing?
Coke and, given that code... what stack?
NotFound: that doesn't impact the bug in the pir.
I presume they're expecting it to fail.
(given those params.) 17:45
jonathan Coke: C stack
NotFound Coke: no, but given that parrot documentation says nothing, doing what a rakudo expects can be a good guide.
Coke NotFound: we're already doing that.
NotFound Coke: then there is no bug X-)
Coke *sighs*
jonathan If continually throwing and catching a C exception eventually leads to us filling up the C stack, there *is* a bug. 17:46
NotFound jonathan: continually throwing a exception *from C* and cathcing it *in pir* 17:47
jonathan OK, but still.
pmichaud looks like a code needs a way to unwind from the exception handler. 17:48
NotFound Well, a solution is to not throwing the exception from C. To do that, I need to know what we want it to do.
pmichaud s/a/the/ 17:49
NotFound pmichaud: there is no way, or we don't have the inferior runloop problem.
jonathan That's not a general solution.
If in the long run throwing lots of C exceptions hurts us, then we're gonna have issues with long-running apps. 17:50
pmichaud it's "throwing lots of C exceptions and never exiting the routine that throws them", though.
jonathan Ah.
Tene How does this change with the pcc rewiring? 17:51
pmichaud in the case of
while 1 { 0.substr(-10) }
I would expect the exits from the .substr() method to clean things up a bit
NotFound The general solution is to redesign the way we catch exceptions.
pmichaud and if not there, then the exits from the inner block
NotFound: actually, I think it's more that we need explicit "leave" semantics. 17:52
NotFound The problem is, I think: the exception handler is run in an inner runloop, and the handler can't know or handle that fact. 17:54
pmichaud that sounds a bit like a problem as well, yes. 17:55
NotFound And the fact is caused by the fact that throw_from_c and throw_from_op do very different things.
So the non general solution for the substr thing is to find a way to throw from op. 17:57
dalek kudo: b9e87d4 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 412 files, 11629 passing, 6 failing

   S02-whitespace_and_comments/unicode-whitespace.t aborted 1 test(s)
   S12-enums/basic.rakudo 27 - short name of the enum without parenthesis is an enum
   S32-num/rand.rakudo aborted 4 test(s)		 18:05
NotFound The problem is in src/eceptions.c:387 - Parrot_runops_fromc_args(interp, handler, "vP", exception); - This never returns 18:08
There is a possible solution that I don't think people want: ban push_eh label 18:11
Or clearly document that you are never supposed to loop on it. 18:12
chromatic allison and I discussed a change to exception syntax in PIR to make this possible. 18:13
18:13 abesapien joined
chromatic It's impossible to detect when an exception handler has ended and resumed control flow elsewhere, at least without syntax to mark it. 18:14
We came up with some ideas to denote the scope of execution of exception handlers in PIR.
She agreed to write them up, but that was a while back.
I still have three short notes on my whiteboard right *rap rap* here.
NotFound And semantic on what to do in that case? 18:18
chromatic The only change to semantics is that they explicitly mark where the exception handler's control flow ends so that Parrot can exit the inferior runloop. 18:19
NotFound So the longjmp already present at the end of Parrot_ex_throw_from_c is supposedly doing the right thing? 18:22
chromatic Yes. 18:23
The intent is correct anyway. I won't speak to the implementation.
18:23 zak_ joined
NotFound Will not be easier then to directly do that, after setting the exception args, instead of invoking a runloop? 18:24
18:24 mberends joined
chromatic This gets complicated if you expect also to have exception handlers written in C, I believe. 18:25
NotFound Exceptions handlers in C already follow a different path.
chromatic The only way I've ever understood all of the corner cases is to draw a matrix of all invocation/handling/leaving paths. 18:26
NotFound search his blue and red pills
The actual case is a exception thrown from C and catched in pir 18:27
18:42 zak_ joined
chromatic Catch enough of those, and you run out of C stack, because you never longjmp back to the spot of the thrown exception? 18:44
NotFound Yes, that is RT #63592 shows 18:46
chromatic I can't think of a good way to handle that. 18:47
That is, without calling setjmp on every trip through a runloop or rewriting the system never to throw exceptions from C or rewriting the system not to use C.
NotFound I'm taking a look at a possible solution: doing the same as throw_from_op does, just needs a way to pass the continuation address to a setjmp to the runloop 18:48
A new field in parrot_runloop_t, maybe. 18:53
19:08 jdv79 joined
dalek kudo: fb21797 | jnthn++ | src/ (2 files):
Get us handling named arguments more correctly in multiple dispatch. A type-match fail on a named or a missing required named parameter can now cause a candidate to not be considered.
 19:12
kudo: 7041eb1 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
nopaste "NotFound" at 213.96.228.50 pasted "A possible soution to exceptions throw from C - RT #63592 - Uncleaned code" (89 lines) at nopaste.snit.ch/17093 19:15
NotFound chromatic: Can you take a look at this?
chromatic Looking. 19:16
+ address = VTABLE_invoke(interp, handler, NULL);
Will that ever invoke an NCI PMC? 19:17
NotFound Good question. I don't think we have a test of using a NCI as exception handler. 19:18
chromatic Nothing jumps out at me about that being wrong; it seems worth testing.
NotFound I'll clean up it and open a trac ticket, mentioning the RT ticket on it. 19:19
particle it just occurred to me that dalek should be renamed to knit 19:28
then our two favorite bots would be knit and purl
19:31 iblechbot joined
NotFound Will you kill me with a chainsaw if I add a goto? 19:33
dalek rrot: r39868 | cotto++ | trunk/lib/Parrot/OpTrans (2 files):
[ops2c] make the source of some #defines easier to trace - no functional changes
chromatic It's hard to manage this without a goto. 19:35
NotFound The alternative can be using other setjmp, which can be costly 19:36
The cleaned version pass all parrot tests 19:37
chromatic How about the RT?
purl well, the RT is just RT (bestpractical.com/rt) or (:rt3) or (: rt bugs) or Obra's trouble ticketing system or the first IBM RISC workstation (www.contrib.andrew.cmu.edu/~shadow/ibmrt.html) or the bombsquad or the Right Thing or very very capable and open-source or an application framework that bundles a ticketing system or obra's baby or SOOOO slow :-S or email mailto:perlbug-owner@perl.org for access
NotFound The RT runs a lot of time without eating the stack 19:38
The pir version, that is. I don't have a rakudo tree ATM 19:39
cotto NotFound, just don
't do this: thedailywtf.com/Articles/Longjmp--F...ED!!!.aspx
NotFound cotto: not sure is appliable, one more setjmp in a C function that already heavily depends on one, is not much more risk. 19:40
The speed concern, yes, surely impacts negatively, but we don't enter runloops with a high frequency, I suppose. 19:41
But I pefer the goto anyway, sure. 19:43
cotto it was more an excuse to post a link to that site than serious advice 19:51
You're more than smart enough not to put a setjmp or longjmp in a tight loop like that. 19:52
NotFound Don't worry, I don't take seriously any advice ;)
TT #804 created with the cleaned patch 19:56
dalek TT #804 created by NotFound++: Avoid entering inner runloop when catching a exception thrown from C with ...
20:33 jdv79 joined
dalek cnum-dynpmcs: r99 | darbelo++ | trunk/t/multiply.t:
Kill tests that requere more that 512 digits.
 20:34
cotto bacek_at_work, ping 20:40
20:47 maettu left 20:55 bacek joined
cotto bacek, pign 20:57
(I guess that's the non-kosher version of ping)
21:03 Whiteknight joined
cotto bacek, reping 21:19
bacek cotto: pong
good morning, #parrot
cotto bacek, the more I think about it, the more I become convinced that Parrot will need some significant internal changes to support pure L1 ops and PMCs, and that an PCT-based pmc2c and ops2c will be necessary but not sufficient. (NOTE: When I say "L1", I mean anything that compiles to L1.) (lots more) 21:20
From what I can see, it seems like it's a better idea to do the following:
* go ahead with pmcc, get it emitting C similar to pmc2c
* get it working with L1 and emitting C
* switch all PMCs over to L1 (this can be done incrementally with frequent tests)
* do all of the above steps, except for ops
* officially deprecate C-based PMCs and ops and write tutorials for HLLs on how to switch to new L1-based equivalents
* after the deprecation takes effect, make whatever major internal changes Parrot requires for pure L1-defined ops and PMCs
- this is the hard part since we won't be able test anything until all of Parrot is updated
- we may figure out a better way as we approach this point
* take a vacation, because anyone working on this project will need it by the time the conversion is done
This can be done gradually with only one major invasive change. In the new approach you suggested, we'd have an additional major transition where we'd need to convert all C-based PMCs to L1-based at once without the possibility of incremental change or testing. I think it's a much better idea to use the original plan, even if pmcc and the ops compiler are only temporary, because it'll mean that we'll only have one place where we need to m
ake massive changes without being able to test them incrementally. 21:21
bacek erm... 21:24
Why do you think my approach will require converting all PMCs in one shot? 21:25
cotto I'm assuming that whatever code allows for pure L1 PMCs will exclude the C-based PMCs. 21:26
bacek how that? 21:27
We will be able to call C from L1.
C PMC is bunch of C functions
cotto You're right. That should have been obvious. 21:28
bacek So, we can convert PMC one-by-one
Did I missed the point?
cotto I still prefer being able to convert PMCs function-by-function, but I was making an incorrect assumption. 21:29
chromatic PMC-by-PMC seems reasonable enough.
Any PMC that's too big to do that in one swoop is too big.
cotto agreed
Whiteknight cotto: you had mentioned that you didn't think NQP was the right tool for rewriting PMCs?
cotto I'm not convinced of that yet. 21:30
Whiteknight we'd obviously need to add some extensions that aren't part of the Perl6 spec 21:31
cotto It seems like nqp doesn't have the right model for low-level PMC implementation.
It's certainly not its original purpose. 21:32
Whiteknight things like the "has" keyword could be repurposed to specify ATTRs for instance
jonathan What will L1 look like?
particle and method
we need to add vtable
jonathan Or more to the point (more)
Whiteknight we add a keyword "vtable" to specify those
jonathan I have the odd PMC that does really rather complex stuff. Re-writing it in an assembly-ish language could make it a killer to maintain. 21:33
Whiteknight jonathan: that's really up in the air. I don't see any reason why we would need any more then a basic human-readable format. We won't be hand-writing L1.
jonathan Whiteknight: OK, so what would we write the PMC bodies in?
cotto jonathan, what PMC? It might be a good example to look at.
jonathan Or is that still open for discussion yet?
cotto: See perl6multisub.pmc. 21:34
particle Q:C { ... } ;)
Whiteknight jonathan: that's the question we're talking about now. I think a variant of NQP would do nicely
chromatic jonathan, I think it's open for discussion. Certainly a language that compiles down to L1 would be sufficient.
cotto also, we expect *very* little L1 to be written directly.
Whiteknight or something C-like to expedite the transition, like Austin's "close" language
jonathan OK, I'd misunderstood and thought the expectation was we'd write them in L1. Now I'm a whole lot less concerned.
particle why don't you compile c to l1?
jonathan Probably because of the memory model.
Whiteknight yeah, we're really trying to divorce ourselves from the C semantics 21:35
jonathan
.oO( what memory model? )
particle sure, but you can convert as you go
cotto particle, do you want to write a C parser and compiler?
particle cotto: those exist already
Whiteknight true. I don't think the conversion is going to be as big a deal as some people are thinking it will be
particle emit l1 from gcc
i'm kidding, folks. 21:36
Whiteknight that's a wasted effort, to write an entire GCC backend for a one-time translation
jonathan Phew!
cotto jonathan, ditto
Whatever language we use, it shouldn't have := 21:37
Actually, I think it may be more productive to go through some existing PMCs and make a list of what language features are needed than to say how nqp could be made to work. 21:38
chromatic Maybe so.
particle just start writing them in nqp-like pseudocode 21:39
nqp is as good as any language for a start
it has blocks, loops, and declarators 21:40
Whiteknight feels a blog post coming on...
bacek particle: same for PIR
cotto but not types/structs, which are of some importance to the C code we've got
particle loops? pir?
jonathan cotto: := is in NQP because it wants to be a subset of Perl 6, and binding semantics are a good bit easier to deal with than assignment semantics. 21:41
(Getting assignment right on Parrot has been non-trivial.)
cotto I understand the reason behind it, but it's still irritating. 21:42
jonathan The syntax or the semantics?
Whiteknight both
cotto what he said 21:43
21:44 jan joined
particle sd++ # i have a local copy of parrot bug queue now 21:46
sd clone --from trac:trac.parrot.org/parrot # it's that easy
21:51 preflex joined
cotto What about using a subset of C? 21:52
Hmm. I think I'll go look at PMCs and see what language features they need. That'll give us a better basis for any language decisions. 21:54
21:56 Zak joined
Infinoid happy Thursday all 22:02
bacek O NOES... It was Fryday few minutes ago!!! 22:06
jonathan Huh, but...it was Thursday a few minutes ago?!?! 22:08
22:08 skids joined
jonathan Ooh, Friday means end of the week. :-) 22:09
22:10 Coke joined
bacek Looks like expand_hash loosing one new item on each expand... 22:16
(gdb) p hash->entries
$4 = 12
(gdb) p old_size
$5 = 16
(gdb) p new_size
$6 = 32
22:20 Limbic_Region joined
Whiteknight losing an item? wtf? 22:22
that's not happening in trunk is it?
jonathan wtf really?
If that *is* happening in trunk, and its losing them in the "no longer GC referenced" sense, that could easily explain some of the "GC" faults Rakudo is hitting. 22:23
bacek I'm still investigating what's going on...
jonathan: can you reproduce rakudo's "fault"? 22:26
I suspect reducing initial hash site to 4 triggered GC issue.
jonathan bacek: I can reproduce it, yes 22:27
It moves with each commit
that is, each small change I make
So looks very much like corruption.
Where is the initial hash size setting?
bacek Try to change src/hash.c
jonathan I can change it to 8 and test. 22:28
bacek top of the file
It was 16 afair
jonathan #define INITIAL_BUCKETS 4
that one?
bacek yes
jonathan I'll give it a teste.
s/te\\.// 22:29
bacek Changing it back to 16 isn't "solution" anyway...
jonathan: "tes"??? :)
jonathan oh bollocks!
;-)
jonathan woulda written it in Russian if only he knew that word
re-building now.. 22:30
And will try one of the spectests that I know blew up.
bacek ok
jonathan Well, what'd you know, that test runs now. 22:31
Let me run make spectest
And see how that goes
bacek ooookeeeey...
jonathan I was getting methods of all things prematurely collected earlier on today. 22:32
bacek Whiteknight: I told ya! It's GC collecting hash keys prematurely!
jonathan They'd be stored in a hash.
bacek: Let's run the suite rather than just one test before jumping to that. :-)
But if it is that, then, well...
Whiteknight well holy shit 22:33
purl only in the Vatican, my friend.
jonathan purl++
Whiteknight who woulda thought that hashes were TEH SUXXOR?
bacek Whiteknight: it's no "hash" by it self...
jonathan Parrot uses hashes intensively, Rakudo too.
If hashes are f*%ked, it's hardly surpsising there's issue. 22:34
bacek In Soviet Russia hashed f%@#k you!
hashes
jonathan In Soviet Parrot too. 22:35
jonathan watches the spectests run by
22:35 rg joined
skids Well, the orderedhash off-by-one I fixed to let hash_buckets not crash rakudo build was more unpredicatable to trace down than one would expect for that kind of thing, so maybe undoing that fix might aggravate things to make the heisenbug more huntable. 22:36
erm hashbuckets=4 that is
jonathan Also, something that has happened recently in Rakudo or Parrot (don't know which) has made the dispatch benchmarks run a bunch slower. 22:37
22:37 clunker9__ joined
jonathan (single, not just multiple...if just multiple I'd know to point the finger straight at me, since I've been doing stuff on that today) 22:37
jonathan should find the tuits to run the benchmark suite regularly on Rakudo and graph it over time. 22:38
chromatic How recently?
jonathan chromatic: I'm not exactly sure, I'm afraid. :-(
chromatic: I ran the benchmarks today to see my multi dispatch refactor hadn't made that crazily slow compared to normal dispatch.
chromatic: It could still be related to that. 22:39
But I'm not convinced.
Last time I ran them was before I went to Italy.
Which is a huge time ago (couple of weeks).
But we're looking at like factor of four change. 22:40
bacek skids: commit number?
chromatic Nothing comes to mind as a likely culprit in the past couple of weeks.
jonathan chromatic: OK. It's very possible it's something that has happened in Rakudo rather than in Parrot, that's had a surprising effect. 22:41
chromatic: I'll try and eliminate the dispatch stuff as a factor before digging any more. 22:42
I hugely refactored multi dispatch today. But then, I'm still surprised the single dispatch test is hit so much.
skids bacek: looking. 22:43
bacek wtf is "#define N_BUCKETS(n) ((n) - (n)/4)"??? 22:44
skids trac.parrot.org/parrot/ticket/636 22:45
bacek: N_BUCKETS is loading factor, I think.
jonathan fwiw, down to S06 tests and no sign of the GC related issues now. 22:49
bacek skids: current implementation of hashes in parrot doesn't require loading factor...
pmichaud (timing) -- I did that graph just earlier today -- let me reproduce it 22:50
jonathan tmave pivo mam! :D 22:51
oops, ww
bacek Too early for beer!
jonathan 1am?
purl Bedtime!
jonathan ;-)
no purl, 1am is beertime!
purl okay, jonathan.
pmichaud pmichaud.com/sandbox/snapshot1.png 22:54
red line is time to do "make spectest" in seconds
blue line is number of spectests we're running 22:55
tick marks along the bottom are days
chromatic It'd be nice to compare their slopes. 22:56
pmichaud well, the first few days would skew it
we'd want to omit them
chromatic Sure. I have a feeling I know what that was.
I want the slope of the red line to increase less than the slope of the blue line. 22:57
chromatic casts L.5 Summon Mathemetician
pmichaud anyway, whatever caused the increase that jonathan is seeing happened either in the last 3 days or in the last 7 22:58
(or both)
but in each of those cases we had an increase in the number of spectests that we were attempting -- i.e., we added new test files to the spectest suite that we weren't running previously 22:59
for example, 7 days ago we were running 405 spectest files
6 days ago we were running 406 (whatever got added added a bunch of tests)
jonathan OK, spectest results with buckets increased to 16: massively better (don't see any of the GC related fails I was seeing with it set to 4).
pmichaud 4 days later we increased to 412 23:00
so part of the slowdown is simply that we're running 150 more tests than we were previously 23:01
chromatic Ah, so the numbers might look better now.
bacek jonathan: well...
skids bacek: hash "size" is based on the mask, power of two. Number of bucket slots available to be mapped to indices is N_BUCKETS... I'd call that a loading factor, personally, but I can see where opinions might differ on that.
23:01 Theory joined
pmichaud (NQP syntax) -- note that I think most of the things people have described can be added to NQP while retaining Perl 6 syntax 23:02
for example, non-pmc registers are just
my int $foo
my str $bar
vtable declarations are just
method get_integer() is vtable { ... } 23:03
NotFound With all that games with +1 and -1 on the mask/size is no wonder that the code is prone to off-by-one errors
jonathan pmichaud: I was talking about the time taking to run tools/benchmark.pl
pmichaud jonathan: oh.
jonathan: *that* would definitely represent a better measure of parrot and rakudo performance 23:04
at least for the core simple operations
jonathan pmichaud: Right, but I ran it today for first time since I got back from my trip, it's it's 3-4 times more time to run now.
Granted it could be the dispatch fiddling I did today, but it doesn't explain single dispatch cost being so much higher really. 23:05
pmichaud I could probably update my daily spectest script to run benchmark.pl for each day over the past couple of months
jonathan That could be interesting.
NotFound orderedhash.pmc:584 That -1 must not be +1? 23:07
pmichaud jonathan: is a rakudo or parrot commit in queue in the next hour or so? 23:09
(e.g., to bump buckets to 16)
jonathan I can commit my bump up to 16.
But are folks are working on figuring out the real underlying issue?
pmichaud I just wanted to know, as I'm looking to bump PARROT_REVISION 23:10
jonathan NotFound/bacek: What would you prefer?
pmichaud to me, slow-but-working trumps fast-but-failing
bacek jonathan: -1 to commit. It's just hiding original issue...
NotFound jonathan: I'd prefer to have a test that fails if the number in that line is wrong. 23:11
jonathan NotFound: It's a more general hash issue than OrderedHash, I think.
pmichaud (hiding original issue) I don't mind if the original issue stays unhidden if there's a chance someone will actually fix it
but otherwise I'm currently looking at (nopasting)
NotFound jonathan: anyway, if I can change that line without breaking any test, then we don't have enough tests. 23:12
nopaste "pmichaud" at 72.181.176.220 pasted "latest spectest run against parrot trunk" (13 lines) at nopaste.snit.ch/17094
bacek NotFound: if you are interested I have "easy" way to recreate this issue.
jonathan bacek: I agree it's a workaround/avoidance patch rather than a solution patch. 23:13
NotFound And yes, changing it all test pass
bacek NotFound: on tt761_keys_revamp branch, src/pmc/hash.pmc, line 135. 23:14
NotFound bacek: I'm looking at runk
jonathan bacek: On ther other hand, it is affecting folks, and I'm not sure what timeline for a fix is going to be.
pmichaud We _really_ don't want 1.4 shipping with gc errors.
bacek NotFound: uncommenting "old" code causing EPIC FAIL in compiling PGE.
jonathan pmichaud: Agree. 23:15
bacek pmichaud: agree.
jonathan We're a bit off 1.4 yet mind.
pmichaud 2.5 weeks
purl 2.5 weeks is not enough.
jonathan But the current bunch of GC bugs are hindering Rakudo development.
pmichaud or is it 3.5 weeks?
2.5 weeks. 23:16
purl hmmm... 2.5 weeks is not enough.
jonathan We ain't had a Tuesday yest this month.
*yet
pmichaud right
release is July 21
today is July 2
so less than 3 weeks
jonathan aye
pmichaud if it's going to be fixed, it probably needs to be fixed not later than july 18 23:17
jonathan I guess we either a) wait to see if there's a fix or b) apply patch, file a ticket and once it gets resolved we can tweak initial buckets down again.
skids bacek: what's the easy way to replicate it?
pmichaud I'm okay with waiting if people are actively going to work on it. 23:18
bacek skids: tt761_keys_revamp branch, check src/pmc/hash.pmc line 135. There is comment about fail.
pmichaud maybe we should put a ticket in the roadmap/critical path that calls for a decision to be made on July 14
bacek skids: comment out "ret = (void *)key;", uncomment "ret = (void *)Parrot_str_new_COW(interp, key);" 23:19
skids: try to build parrot. For me it consistently fail on compiling PGE.
skids wonders if it works with buckets=8... 23:20
nopaste "bacek" at 114.73.175.1 pasted "Premature collected keys in hash (bt)" (71 lines) at nopaste.snit.ch/17095 23:21
bacek skids: tweaking initial hash size is just trigger some underlying problem... 23:22
ok, time for $dayjob.
skids Yeah but just wondering because it might be a clue.
nopaste "NotFound" at 213.96.228.50 pasted "Simple test for OrderedHash clone" (14 lines) at nopaste.snit.ch/17096 23:28
NotFound This program crash in a few iterations if I modify the line I mentioned in clone. However, the test suite pass. So is clear we need to add some test. 23:29
23:30 patspam joined 23:31 Zak joined
Whiteknight pmichaud++ 23:43
(thanks for the hints on the blog)
pmichaud (use of = versus := ) if L1 ends up supporting a true assignment operation, then I think '=' is fine; but I'd prefer not to repeat PIR's mistake of confusing assignment with binding 23:46
Infinoid I sincerely hope L1 will be too low level to care about that. 23:50
Whiteknight yes, I suspect L1 will be playing with PMC* and STRING* pointers directly 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!