Camelia, the Perl 6 bug

IRC log for #parrot, 2009-07-02

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:04 davidfetter joined #parrot
00:08 AndyA joined #parrot
00:10 cotto eew.  Good luck with that one.
00:12 chromatic It's doable, but first I have to mock something.
00:22 bacek_at_work hi again.
00:22 purl oh, you're back!
00:22 * pmichaud wonders what/who chromatic will mock this time :-)
00:25 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 #parrot
00:42 pmichaud chromatic: so far the patch in TT #800 is working great for rakudo (without ICU)
00:42 pmichaud also, all parrot tests pass (without ICU)
00:43 pmichaud 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.
00:43 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>
00:43 chromatic Oh, don't tempt me.
00:44 pmichaud :-P
00:44 pmichaud anyway, I'm happy with the patch; +1 from me.
00:44 chromatic "My code has to run on several different major versions of Perl; I can't take advantage of these new features."
00:44 chromatic "You have a change management problem.  Not me."
00:46 kid51 joined #parrot
00:47 dalek parrot: r39863 | chromatic++ | trunk/src/embed.c:
00:47 dalek parrot: [src] Changed Parrot's command-line argument processing to treat command-line
00:47 dalek parrot: arguments as Unicode by default, not ASCII.  This works with and without ICU.
00:47 dalek parrot: See TT #800.  (This needs a test case.)
00:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39863/
01:03 nopaste joined #parrot
01:04 dalek parrot: r39864 | Infinoid++ | trunk/t/op (2 files):
01:04 dalek parrot: [t] Un-TODO some tests on openbsd per report in TT #758.  reezer++
01:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39864/
01:17 chromatic Okay, making the JIT work there is trickier.
01:18 chromatic 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:21 * 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 #parrot
01:22 smash hello everyone
01:22 kid51 Howdy, smash, you fine fellow!
01:22 kid51 .... as purl used to say :-)
01:23 smash hehe
01:57 * davidfetter wonders whether rsrsrs is also a portuguese thing
01:59 chromatic INCOMING
01:59 purl i guess INCOMING is https://pause.perl.org/incoming/
02:01 dalek parrot: r39865 | chromatic++ | trunk (2 files):
02:01 dalek parrot: [NCI] Revised tools/build/nativecall.pl so that src/nci.c only builds the NCI
02:01 dalek parrot: thunks that JIT can't handle.  This has no effect unless the build's JIT can
02:01 dalek parrot: build call frames.  This reduces the size of src/nci.o by 86.65% and the size
02:01 dalek parrot: of libparrot by 5.58%.
02:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39865/
02:04 silug joined #parrot
02:22 jdv79 chromatic: what tools do you use when you profile and/or trace parrot?
02:24 chromatic callgrind and kcachegrind
02:39 zak_ joined #parrot
02:42 mikehh joined #parrot
02:51 cotto Heh.  Slashdot is broken.
02:51 cotto I may have to find something productive to do.
02:52 cotto and it's back
03:13 * smash &
03:16 Theory joined #parrot
03:17 Zak joined #parrot
03:24 dalek close: r37 | Austin++ | trunk/src/ (4 files):
03:24 dalek close: Added 'clone' builtin
03:24 dalek close: review: http://code.google.com/p/close/source/detail?r=37
03:31 japhb joined #parrot
03:34 dalek close: r38 | Austin++ | trunk/ (9 files):
03:34 dalek close: Moved PCT::Node stuff, started on test cases
03:34 dalek close: review: http://code.google.com/p/close/source/detail?r=38
03:44 dalek close: r39 | Austin++ | trunk/t/library/PCT:
03:44 dalek close: Dropped PCT
03:44 dalek close: review: http://code.google.com/p/close/source/detail?r=39
03:49 dalek close: r40 | Austin++ | trunk/t/library/pct (4 files):
03:49 dalek close: Re-added PCT one level down
03:49 dalek close: review: http://code.google.com/p/close/source/detail?r=40
04:05 Andy joined #parrot
04:07 cognominal joined #parrot
04:53 Andy joined #parrot
04:58 dalek TT #778 closed by allison++: Make FileHandle Subclassable
05:50 Austin joined #parrot
05:50 Austin Howdy.
05:51 Austin pmichaud: ping?
05:51 uniejo joined #parrot
05:55 Austin bug bug bug
06:14 clunker3 joined #parrot
06:18 cotto where? where? where?
06:18 cotto too late
06:27 barney joined #parrot
06:30 flh joined #parrot
06:55 Tene Aw, he's gone
07:00 dalek tracwiki: v6 | cotto++ | RewritingPMCsInNQP
07:00 dalek tracwiki: change existing example to minimize changes to nqp, add pmc_new
07:00 purl dalek: that doesn't look right
07:00 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Rewr​itingPMCsInNQP?version=6&amp;action=diff
07:02 cotto < purl-- >
07:03 cotto purl, dalek is a bot
07:03 purl ...but dalek is #parrot's spammy little rss bot or (see: dalek plugins)...
07:03 cotto purl, sudo dalek is a bot
07:03 purl OK, cotto.
07:04 cotto <3 parallel testing
07:08 cotto is META.yml of any further use?
07:09 dalek parrot: r39866 | cotto++ | trunk (10 files):
07:09 dalek parrot: [ops2c] remove OpTrans::Compiled, which was only used by a tool removed back in r28978
07:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39866/
07:10 cotto That "Compiled" runcore is an interesting idea.  It doesn't sound entirely unlike what we're aiming to do with L1 jitting.
07:18 iblechbot joined #parrot
07:37 bacek_at_work cotto: how is you ops2c groking going?
07:40 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:41 cotto I still don't have a good name.
07:41 cotto "cops" has potential for puns, but doesn't have much flair.
07:41 bacek_at_work grok - Gready Ops Kompiler
07:42 cotto I'd prefer not to incorporate misspellings into the name
07:42 cotto and an infinite recursion would be nice
07:43 cotto but that's secondary and I'm not at the point where I have to start writing code anyway.
07:44 bacek_at_work ok. Remember, you promised to put something before next #ps :)
07:45 cotto I said I hoped to do that.
07:46 cotto but yeah, that's part of my goal
07:46 bacek_at_work ok-ok. Wanna grammar for current ops? As starting point.
07:46 cotto Heh.  The grammar is probably the easiest part.
07:47 cotto I'm actually looking forward to writing it.
07:47 bacek_at_work That's why I offer it ;)
07:47 cotto NO.  IS MINE.  YUO NOT CAN HAS.
07:48 bacek_at_work nopaste?
07:48 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
07:48 purl somebody said nopaste was at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/
07:49 nopaste "bacek" at 211.29.157.151 pasted "ops grammar for cotto" (43 lines) at http://nopaste.snit.ch/17088
07:49 cotto That's a lot less than 43 lines.
07:50 bacek_at_work :)
07:50 bacek_at_work There is 41 empty lines for you to fill
07:50 cotto um... thanks?
07:51 bacek_at_work YOU WELCOME
07:54 cotto btw, how's your nick pronounced?
07:55 * bacek_at_work pronounced own nick loudly, hoping cotto can hear it
07:56 * cotto listens carefully but doesn't hear anything
07:57 bacek_at_work Can you give me idea how to explain it? :)
07:58 cotto Just use sounds from other English words.
07:59 bacek_at_work b as in buck
08:00 bacek_at_work a close to "u" in buck
08:00 bacek_at_work c as in "cent"
08:00 bacek_at_work e as in "cent"
08:00 bacek_at_work k is just k
08:01 cotto that works.  Thanks.
08:01 * bacek_at_work paid 15K to Tax Officce recently...
08:01 cotto ouch
08:01 szbalint australian dollars?
08:01 purl australian dollars are nearly at par with Canadian dollars.
08:01 szbalint it's still a nice pile...
08:01 bacek_at_work szbalint: is there any other dollars?
08:02 cotto lots
08:02 bacek_at_work and they somehow useful???
08:02 szbalint I wouldn't mind paying 15k in taxes if it's in zimbabwean dollars
08:02 bacek_at_work "k" in zimbabwe stays for "kilograms"
08:03 cotto bacek_at_work, http://en.wikipedia.org/wiki/Dol​lar#National_currencies_called_.22dollar.22
08:03 cotto I think catpenny is my favorite measurement of currency
08:04 cotto http://www.bash.org/?743428
08:04 mikehh joined #parrot
08:05 cotto catpenny?
08:05 purl i think catpenny is your favorite measurement of currency
08:05 cotto catpenny is also http://www.bash.org/?743428
08:05 purl okay, cotto.
08:07 cotto catpenny?
08:07 purl well, catpenny is your favorite measurement of currency or http://www.bash.org/?743428
08:08 bacek_at_work ok, time to go home and make some dinner
08:09 cotto yay food
08:09 bacek_at_work yay, I missed my lunch today...
08:09 cotto Wow.  ops code gets mangled into some impressive ugliness.
08:11 bacek_at_work erm... I expected it should' be just some wrapping around without touching c-body...
08:12 cotto saying that the c-body gets touched is an understatement
08:13 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
08:14 cotto do tell
08:14 bacek_at_work "COCK" is Ops Crushed and Killer
08:14 bacek_at_work afk &
08:15 cotto so...many...puns...
08:15 cotto yet so inappropriate
08:16 chromatic Yeah, that one's on my "Keep Looking" list.
08:18 cotto If he snuck in Russian profanity we might not know until it was too late.
08:19 chromatic That's why we have Jonathan.
08:20 szbalint I know one thing, never try to find a dermatologist in russia
08:20 szbalint :)
08:21 cotto ?
08:23 szbalint for the same reason democrats are sometimes spelled dermocrats
08:37 mikehh make fulltest PASS at r39866 - also pre/post config, smolder - Ubuntu 9.04 Amd64
08:42 bacek joined #parrot
08:43 janus joined #parrot
08:44 bacek hi again
08:44 purl oh, you're back!
08:46 janus howdy
08:52 bacek Howdy, janus, you fine fellow!
08:52 bacek purl: see! Why I have to your job, stupid girl?
08:52 purl i haven't a clue, bacek
08:53 cotto Does anyone know offhand what the purpose of src/ops/ops.num is?
08:54 bacek cotto: make your life harder?
08:56 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:57 zak_ joined #parrot
08:59 bacek ops.num is mapping between op name and pbc/switch statement in generated code.
08:59 bacek basically - useless from my pov
08:59 cotto That's what I'm thinking too, but I definitely don't have the brainpower to remove it.
09:00 cotto bacek, feel free to do it if you want to, otherwise I'll tackle it tomorrow.
09:00 cotto It's nice to simplify existing code.
09:01 cotto night
09:01 bacek night
09:02 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:11 bacek jonathan: # - deleting/changing/inserting existing ops in ops.num
09:11 bacek It's from PBC_COMPAT.
09:11 bacek So adding/removing ops will give incompatible PBC with older version anyway
09:15 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 jonathan And they'll be vastly easier to write if new opcodes just go on the end of the existing set.
09:17 bacek Agreed. But looks like L1 approach will make it deprecated.
09:25 masak joined #parrot
09:35 MoC joined #parrot
11:32 bacek joined #parrot
12:17 Whiteknight joined #parrot
12:33 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.
12:52 Coke L1 is also magical unicorns and flying puppies.
12:52 purl okay, Coke.
13:01 skids joined #parrot
13:05 Andy joined #parrot
13:18 * 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 #parrot
13:23 ruoso joined #parrot
13:31 ruoso joined #parrot
13:33 szabgab joined #parrot
13:38 ruoso joined #parrot
13:40 ruoso joined #parrot
14:17 ruoso joined #parrot
14:25 eiro joined #parrot
14:27 eiro joined #parrot
14:32 mikehh joined #parrot
14:33 Whiteknight allison++ # kicking ticket ass
14:36 amuck_ joined #parrot
14:48 Theory joined #parrot
14:59 davidfetter joined #parrot
15:02 maettu joined #parrot
15:21 dalek TT #802 created by mberends++: freeze opcode segfaults on working bytecode from Rakudo
15:27 dalek rakudo: ec68db8 | jnthn++ | src/pmc/perl6multisub.pmc:
15:27 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​c68db89f36d9c9437ca60b1273010e5dbc96c9a
15:33 dalek rakudo: dcf4c6d | jnthn++ | src/ (3 files):
15:33 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​cf4c6d8343f7f3a8cf1ba11fc20b67d425ede5b
16:05 Austin joined #parrot
16:07 Coke rakudo: 3??1::0
16:07 polyglotbot OUTPUT[ResizablePMCArray: Can't pop from an empty array!␤in Main (src/gen_setting.pm:3279)␤]
16:07 Coke pmichaud: (for you.)
16:07 Austin pmichaud: ping?
16:07 Coke pmichaud: (yes, I know that's invalid syntax)
16:08 Coke pmichaud: moving to #p6, nevermind. =-)
16:26 darbelo joined #parrot
16:27 Tene Austin: ping?
16:27 pmichaud Austin: pong
16:32 pmichaud afk, lunch
16:35 chromatic joined #parrot
16:38 Psyche^ joined #parrot
16:45 davidfetter joined #parrot
16:50 Austin Tene: pong
16:50 Andy joined #parrot
16:50 Austin msg pmichaud Sorry, I was slaving away on a new ticket.
16:50 purl Message for pmichaud stored.
16:50 dalek TT #803 created by Austin_Hastings++: PCT emits bogus code for getattribute on named register variable
16:53 Austin_Hastings joined #parrot
16:56 Austin_Hastings Tene: pong?
16:57 Austin moo.
16:58 dalek close: r41 | Austin++ | trunk/build/Makefile.in:
16:58 dalek close: Added script for running tests
16:58 dalek close: review: http://code.google.com/p/close/source/detail?r=41
17:01 cotto Do we still need META.yml?
17:01 cotto messages erase
17:03 darbelo cotto: delete it and see what breaks.
17:07 dalek decnum-dynpmcs: r98 | darbelo++ | trunk/t/ (4 files):
17:07 dalek decnum-dynpmcs: Switch some tests to use IEEE 754 comparisons.
17:07 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=98
17:12 dalek parrot: r39867 | cotto++ | trunk (2 files):
17:12 dalek parrot: [examples] move PGE demo to examples where it'll be tested for compilability automatically
17:12 dalek parrot: Coke++ for the suggestion
17:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39867/
17:24 * Coke hurls http://rt.perl.org/rt3/Tic​ket/Display.html?id=63592 for a pure PIR segfault.
17:24 Coke enjoy.
17:24 chromatic META.yml is for the CPAN/PAUSE.
17:26 cotto istr that we're not doing CPAN releases anymore.
17:27 Coke we are.
17:28 Coke just on stable.
17:28 Coke s/stable/supported/
17:30 cotto Coke, I don't see anything about that in the release manager guide.
17:30 Coke cotto: based on conversations with allison.
17:32 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.
17:32 cotto Coke, could you update the guide?
17:34 NotFound Is just the way we handle exceptions from C, together with the fact that the majority of exceptions are thrown from C
17:37 NotFound BTW, Parrot_str_substr perldoc says nothing about what does on error conditions.
17:37 Austin left #parrot
17:39 Coke cotto: no, but I can open a ticket to make someone else do it.
17:39 NotFound Neither pdd28
17:40 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?
17:40 Coke rakudo: 0.substr(-10)
17:40 polyglotbot RESULT[undef]
17:40 pmichaud darn, Austin left again.
17:41 Coke but that undef is really a Failure, which creates a new Exception.
17:41 Coke so that perl6 sample code is just a way to show off memory leaks. =-)
17:41 NotFound Is not a memory leak.
17:42 NotFound Ah, you mean, if it worked.
17:42 Coke ?
17:42 Coke it's a do nothing loop. just generates undef each time through.
17:43 Coke you're right, it's not blowing the memory, my bad.
17:44 Coke 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?
17:44 Coke and, given that code... what stack?
17:44 Coke NotFound: that doesn't impact the bug in the pir.
17:44 Coke I presume they're expecting it to fail.
17:45 Coke (given those params.)
17:45 jonathan Coke: C stack
17:45 NotFound Coke: no, but given that parrot documentation says nothing, doing what a rakudo expects can be a good guide.
17:45 Coke NotFound: we're already doing that.
17:45 NotFound Coke: then there is no bug X-)
17:45 * Coke *sighs*
17:46 jonathan If continually throwing and catching a C exception eventually leads to us filling up the C stack, there *is* a bug.
17:47 NotFound jonathan: continually throwing a exception *from C* and cathcing it *in pir*
17:47 jonathan OK, but still.
17:48 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.
17:49 pmichaud s/a/the/
17:49 NotFound pmichaud: there is no way, or we don't have the inferior runloop problem.
17:49 jonathan That's not a general solution.
17:50 jonathan 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.
17:50 jonathan Ah.
17:51 Tene How does this change with the pcc rewiring?
17:51 pmichaud in the case of
17:51 pmichaud while 1 { 0.substr(-10) }
17:51 pmichaud I would expect the exits from the .substr() method to clean things up a bit
17:51 NotFound The general solution is to redesign the way we catch exceptions.
17:51 pmichaud and if not there, then the exits from the inner block
17:52 pmichaud NotFound: actually, I think it's more that we need explicit "leave" semantics.
17:54 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:55 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.
17:57 NotFound So the non general solution for the substr thing is to find a way to throw from op.
18:05 dalek rakudo: b9e87d4 | pmichaud++ | docs/spectest-progress.csv:
18:05 dalek rakudo: spectest-progress.csv update: 412 files, 11629 passing, 6 failing
18:05 dalek rakudo: Failure summary:
18:05 dalek rakudo:     S02-whitespace_and_comments/unicode-whitespace.t aborted 1 test(s)
18:05 dalek rakudo:     S12-enums/basic.rakudo 27 - short name of the enum without parenthesis is an enum
18:05 dalek rakudo:     S32-num/rand.rakudo aborted 4 test(s)
18:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​9e87d4ad59dc75806f93bd0c76b7708282415ee
18:08 NotFound The problem is in src/eceptions.c:387 - Parrot_runops_fromc_args(interp, handler, "vP", exception); - This never returns
18:11 NotFound There is a possible solution that I don't think people want: ban push_eh label
18:12 NotFound Or clearly document that you are never supposed to loop on it.
18:13 chromatic allison and I discussed a change to exception syntax in PIR to make this possible.
18:13 abesapien joined #parrot
18:14 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 chromatic We came up with some ideas to denote the scope of execution of exception handlers in PIR.
18:14 chromatic She agreed to write them up, but that was a while back.
18:14 chromatic I still have three short notes on my whiteboard right *rap rap* here.
18:18 NotFound And semantic on what to do in that case?
18:19 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:22 NotFound So the longjmp already present at the end of Parrot_ex_throw_from_c is supposedly doing the right thing?
18:23 chromatic Yes.
18:23 chromatic The intent is correct anyway.  I won't speak to the implementation.
18:23 zak_ joined #parrot
18:24 NotFound Will not be easier then to directly do that, after setting the exception args, instead of invoking a runloop?
18:24 mberends joined #parrot
18:25 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.
18:26 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
18:27 NotFound The actual case is a exception thrown from C and catched in pir
18:42 zak_ joined #parrot
18:44 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:46 NotFound Yes, that is RT #63592 shows
18:47 chromatic I can't think of a good way to handle that.
18:47 chromatic 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.
18:48 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:53 NotFound A new field in parrot_runloop_t, maybe.
19:08 jdv79 joined #parrot
19:12 dalek rakudo: fb21797 | jnthn++ | src/ (2 files):
19:12 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​b217978a68eeb93b4e41e8f3787b2d63073f8b2
19:12 dalek rakudo: 7041eb1 | jnthn++ | :
19:12 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
19:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​041eb18b9d6f74e4988e7785fb6e6a54e355546
19:15 nopaste "NotFound" at 213.96.228.50 pasted "A possible soution to exceptions throw from C - RT #63592 - Uncleaned code" (89 lines) at http://nopaste.snit.ch/17093
19:15 NotFound chromatic: Can you take a look at this?
19:16 chromatic Looking.
19:16 chromatic +    address = VTABLE_invoke(interp, handler, NULL);
19:17 chromatic Will that ever invoke an NCI PMC?
19:18 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.
19:19 NotFound I'll clean up it and open a trac ticket, mentioning the RT ticket on it.
19:28 particle it just occurred to me that dalek should be renamed to knit
19:28 particle then our two favorite bots would be knit and purl
19:31 iblechbot joined #parrot
19:33 NotFound Will you kill me with a chainsaw if I add a goto?
19:33 dalek parrot: r39868 | cotto++ | trunk/lib/Parrot/OpTrans (2 files):
19:33 dalek parrot: [ops2c] make the source of some #defines easier to trace - no functional changes
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39868/
19:35 chromatic It's hard to manage this without a goto.
19:36 NotFound The alternative can be using other setjmp, which can be costly
19:37 NotFound The cleaned version pass all parrot tests
19:37 chromatic How about the RT?
19:37 purl well, the RT is just RT (http://bestpractical.com/rt) or (:rt3) or (: rt bugs) or Obra's trouble ticketing system or the first IBM RISC workstation (http://www.contrib.andrew.c​mu.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
19:38 NotFound The RT runs a lot of time without eating the stack
19:39 NotFound The pir version, that is. I don't have a rakudo tree ATM
19:39 cotto NotFound, just don
19:39 cotto 't do this: http://thedailywtf.com/Articl​es/Longjmp--FOR-SPEED!!!.aspx
19:40 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:41 NotFound The speed concern, yes, surely impacts negatively, but we don't enter runloops with a high frequency, I suppose.
19:43 NotFound But I pefer the goto anyway, sure.
19:51 cotto it was more an excuse to post a link to that site than serious advice
19:52 cotto 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 ;)
19:56 NotFound 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 #parrot
20:34 dalek decnum-dynpmcs: r99 | darbelo++ | trunk/t/multiply.t:
20:34 dalek decnum-dynpmcs: Kill tests that requere more that 512 digits.
20:34 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=99
20:40 cotto bacek_at_work, ping
20:47 maettu left #parrot
20:55 bacek joined #parrot
20:57 cotto bacek, pign
20:57 cotto (I guess that's the non-kosher version of ping)
21:03 Whiteknight joined #parrot
21:19 cotto bacek, reping
21:19 bacek cotto: pong
21:19 bacek good morning, #parrot
21:20 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 cotto From what I can see, it seems like it's a better idea to do the following:
21:20 cotto * go ahead with pmcc, get it emitting C similar to pmc2c
21:20 cotto * get it working with L1 and emitting C
21:20 cotto * switch all PMCs over to L1 (this can be done incrementally with frequent tests)
21:20 cotto * do all of the above steps, except for ops
21:20 cotto * officially deprecate C-based PMCs and ops and write tutorials for HLLs on how to switch to new L1-based equivalents
21:20 cotto * after the deprecation takes effect, make whatever major internal changes Parrot requires for pure L1-defined ops and PMCs
21:20 cotto - this is the hard part since we won't be able test anything until all of Parrot is updated
21:20 cotto - we may figure out a better way as we approach this point
21:20 cotto * take a vacation, because anyone working on this project will need it by the time the conversion is done
21:20 cotto 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
21:21 cotto ake massive changes without being able to test them incrementally.
21:24 bacek erm...
21:25 bacek Why do you think my approach will require converting all PMCs in one shot?
21:26 cotto I'm assuming that whatever code allows for pure L1 PMCs will exclude the C-based PMCs.
21:27 bacek how that?
21:27 bacek We will be able to call C from L1.
21:27 bacek C PMC is bunch of C functions
21:28 cotto You're right.  That should have been obvious.
21:28 bacek So, we can convert PMC one-by-one
21:28 bacek Did I missed the point?
21:29 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.
21:29 chromatic Any PMC that's too big to do that in one swoop is too big.
21:29 cotto agreed
21:29 Whiteknight cotto: you had mentioned that you didn't think NQP was the right tool for rewriting PMCs?
21:30 cotto I'm not convinced of that yet.
21:31 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.
21:32 cotto It's certainly not its original purpose.
21:32 Whiteknight things like the "has" keyword could be repurposed to specify ATTRs for instance
21:32 jonathan What will L1 look like?
21:32 particle and method
21:32 particle we need to add vtable
21:32 jonathan Or more to the point (more)
21:32 Whiteknight we add a keyword "vtable" to specify those
21:33 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.
21:33 jonathan Whiteknight: OK, so what would we write the PMC bodies in?
21:33 cotto jonathan, what PMC?  It might be a good example to look at.
21:33 jonathan Or is that still open for discussion yet?
21:34 jonathan cotto: See perl6multisub.pmc.
21:34 particle Q:C { ... } ;)
21:34 Whiteknight jonathan: that's the question we're talking about now. I think a variant of NQP would do nicely
21:34 chromatic jonathan, I think it's open for discussion.  Certainly a language that compiles down to L1 would be sufficient.
21:34 cotto also, we expect *very* little L1 to be written directly.
21:34 Whiteknight or something C-like to expedite the transition, like Austin's "close" language
21:34 jonathan OK, I'd misunderstood and thought the expectation was we'd write them in L1. Now I'm a whole lot less concerned.
21:34 particle why don't you compile c to l1?
21:34 jonathan Probably because of the memory model.
21:35 Whiteknight yeah, we're really trying to divorce ourselves from the C semantics
21:35 jonathan .oO( what memory model? )
21:35 particle sure, but you can convert as you go
21:35 cotto particle, do you want to write a C parser and compiler?
21:35 particle cotto: those exist already
21:35 Whiteknight true. I don't think the conversion is going to be as big a deal as some people are thinking it will be
21:35 particle emit l1 from gcc
21:36 particle i'm kidding, folks.
21:36 Whiteknight that's a wasted effort, to write an entire GCC backend for a one-time translation
21:36 jonathan Phew!
21:36 cotto jonathan, ditto
21:37 cotto Whatever language we use, it shouldn't have :=
21:38 cotto 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.
21:39 particle just start writing them in nqp-like pseudocode
21:39 particle nqp is as good as any language for a start
21:40 particle it has blocks, loops, and declarators
21:40 * Whiteknight feels a blog post coming on...
21:40 bacek particle: same for PIR
21:40 cotto but not types/structs, which are of some importance to the C code we've got
21:40 particle loops? pir?
21:41 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 jonathan (Getting assignment right on Parrot has been non-trivial.)
21:42 cotto I understand the reason behind it, but it's still irritating.
21:42 jonathan The syntax or the semantics?
21:42 Whiteknight both
21:43 cotto what he said
21:44 jan joined #parrot
21:46 particle sd++ # i have a local copy of parrot bug queue now
21:46 particle sd clone --from trac:https://trac.parrot.org/parrot # it's that easy
21:51 preflex joined #parrot
21:52 cotto What about using a subset of C?
21:54 cotto 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:56 Zak joined #parrot
22:02 Infinoid happy Thursday all
22:06 bacek O NOES... It was Fryday few minutes ago!!!
22:08 jonathan Huh, but...it was Thursday a few minutes ago?!?!
22:08 skids joined #parrot
22:09 jonathan Ooh, Friday means end of the week. :-)
22:10 Coke joined #parrot
22:16 bacek Looks like expand_hash loosing one new item on each expand...
22:16 bacek (gdb) p hash->entries
22:16 bacek $4 = 12
22:16 bacek (gdb) p old_size
22:16 bacek $5 = 16
22:16 bacek (gdb) p new_size
22:16 bacek $6 = 32
22:20 Limbic_Region joined #parrot
22:22 Whiteknight losing an item? wtf?
22:22 Whiteknight that's not happening in trunk is it?
22:22 jonathan wtf really?
22:23 jonathan 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...
22:26 bacek jonathan: can you reproduce rakudo's "fault"?
22:26 bacek I suspect reducing initial hash site to 4 triggered GC issue.
22:27 jonathan bacek: I can reproduce it, yes
22:27 jonathan It moves with each commit
22:27 jonathan that is, each small change I make
22:27 jonathan So looks very much like corruption.
22:27 jonathan Where is the initial hash size setting?
22:27 bacek Try to change src/hash.c
22:28 jonathan I can change it to 8 and test.
22:28 bacek top of the file
22:28 bacek It was 16 afair
22:28 jonathan #define INITIAL_BUCKETS  4
22:28 jonathan that one?
22:28 bacek yes
22:28 jonathan I'll give it a teste.
22:29 jonathan s/te\.//
22:29 bacek Changing it back to 16 isn't "solution" anyway...
22:29 bacek jonathan: "tes"??? :)
22:29 jonathan oh bollocks!
22:29 jonathan ;-)
22:29 * jonathan woulda written it in Russian if only he knew that word
22:30 jonathan re-building now..
22:30 jonathan And will try one of the spectests that I know blew up.
22:30 bacek ok
22:31 jonathan Well, what'd you know, that test runs now.
22:31 jonathan Let me run make spectest
22:31 jonathan And see how that goes
22:31 bacek ooookeeeey...
22:32 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!
22:32 jonathan They'd be stored in a hash.
22:32 jonathan bacek: Let's run the suite rather than just one test before jumping to that. :-)
22:32 jonathan But if it is that, then, well...
22:33 Whiteknight well holy shit
22:33 purl only in the Vatican, my friend.
22:33 jonathan purl++
22:33 Whiteknight who woulda thought that hashes were TEH SUXXOR?
22:33 bacek Whiteknight: it's no "hash" by it self...
22:33 jonathan Parrot uses hashes intensively, Rakudo too.
22:34 jonathan If hashes are f*%ked, it's hardly surpsising there's issue.
22:34 bacek In Soviet Russia hashed f%@#k you!
22:34 bacek hashes
22:35 jonathan In Soviet Parrot too.
22:35 * jonathan watches the spectests run by
22:35 rg joined #parrot
22:36 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 skids erm hashbuckets=4 that is
22:37 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 clunker9__ joined #parrot
22:37 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:38 * jonathan should find the tuits to run the benchmark suite regularly on Rakudo and graph it over time.
22:38 chromatic How recently?
22:38 jonathan chromatic: I'm not exactly sure, I'm afraid. :-(
22:38 jonathan chromatic: I ran the benchmarks today to see my multi dispatch refactor hadn't made that crazily slow compared to normal dispatch.
22:39 jonathan chromatic: It could still be related to that.
22:39 jonathan But I'm not convinced.
22:39 jonathan Last time I ran them was before I went to Italy.
22:39 jonathan Which is a huge time ago (couple of weeks).
22:40 jonathan But we're looking at like factor of four change.
22:40 bacek skids: commit number?
22:40 chromatic Nothing comes to mind as a likely culprit in the past couple of weeks.
22:41 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:42 jonathan chromatic: I'll try and eliminate the dispatch stuff as a factor before digging any more.
22:42 jonathan I hugely refactored multi dispatch today. But then, I'm still surprised the single dispatch test is hit so much.
22:43 skids bacek: looking.
22:44 bacek wtf is "#define N_BUCKETS(n) ((n) - (n)/4)"???
22:45 skids https://trac.parrot.org/parrot/ticket/636
22:45 skids bacek: N_BUCKETS is loading factor, I think.
22:49 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...
22:50 pmichaud (timing)  -- I did that graph just earlier today -- let me reproduce it
22:51 jonathan tmave pivo mam! :D
22:51 jonathan oops, ww
22:51 bacek Too early for beer!
22:51 jonathan 1am?
22:51 purl Bedtime!
22:51 jonathan ;-)
22:51 jonathan no purl, 1am is beertime!
22:51 purl okay, jonathan.
22:54 pmichaud http://pmichaud.com/sandbox/snapshot1.png
22:54 pmichaud red line is time to do "make spectest" in seconds
22:55 pmichaud blue line is number of spectests we're running
22:55 pmichaud tick marks along the bottom are days
22:56 chromatic It'd be nice to compare their slopes.
22:56 pmichaud well, the first few days would skew it
22:56 pmichaud we'd want to omit them
22:56 chromatic Sure.  I have a feeling I know what that was.
22:57 chromatic 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
22:58 pmichaud anyway, whatever caused the increase that jonathan is seeing happened either in the last 3 days or in the last 7
22:58 pmichaud (or both)
22:59 pmichaud 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 pmichaud for example, 7 days ago we were running 405 spectest files
22:59 pmichaud 6 days ago we were running 406 (whatever got added added a bunch of tests)
22:59 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).
23:00 pmichaud 4 days later we increased to 412
23:01 pmichaud 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.
23:01 bacek jonathan: well...
23:01 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 #parrot
23:02 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 pmichaud for example, non-pmc registers are just
23:02 pmichaud my int $foo
23:02 pmichaud my str $bar
23:02 pmichaud vtable declarations are just
23:03 pmichaud 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
23:03 jonathan pmichaud: I was talking about the time taking to run tools/benchmark.pl
23:03 pmichaud jonathan: oh.
23:04 pmichaud jonathan: *that* would definitely represent a better measure of parrot and rakudo performance
23:04 pmichaud at least for the core simple operations
23:04 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.
23:05 jonathan 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
23:05 jonathan That could be interesting.
23:07 NotFound orderedhash.pmc:584 That -1 must not be +1?
23:09 pmichaud jonathan: is a rakudo or parrot commit in queue in the next hour or so?
23:09 pmichaud (e.g., to bump buckets to 16)
23:09 jonathan I can commit my bump up to 16.
23:09 jonathan But are folks are working on figuring out the real underlying issue?
23:10 pmichaud I just wanted to know, as I'm looking to bump PARROT_REVISION
23:10 jonathan NotFound/bacek: What would you prefer?
23:10 pmichaud to me,  slow-but-working trumps fast-but-failing
23:10 bacek jonathan: -1 to commit. It's just hiding original issue...
23:11 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.
23:11 pmichaud (hiding original issue)  I don't mind if the original issue stays unhidden if there's a chance someone will actually fix it
23:11 pmichaud but otherwise I'm currently looking at (nopasting)
23:12 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 http://nopaste.snit.ch/17094
23:12 bacek NotFound: if you are interested I have "easy" way to recreate this issue.
23:13 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
23:14 bacek NotFound: on tt761_keys_revamp branch, src/pmc/hash.pmc, line 135.
23:14 NotFound bacek: I'm looking at runk
23:14 jonathan bacek: On ther other hand, it is affecting folks, and I'm not sure what timeline for a fix is going to be.
23:14 pmichaud We _really_ don't want 1.4 shipping with gc errors.
23:14 bacek NotFound: uncommenting "old" code causing EPIC FAIL in compiling PGE.
23:15 jonathan pmichaud: Agree.
23:15 bacek pmichaud: agree.
23:15 jonathan We're a bit off 1.4 yet mind.
23:15 pmichaud 2.5 weeks
23:15 purl 2.5 weeks is not enough.
23:15 jonathan But the current bunch of GC bugs are hindering Rakudo development.
23:15 pmichaud or is it 3.5 weeks?
23:16 pmichaud 2.5 weeks.
23:16 purl hmmm... 2.5 weeks is not enough.
23:16 jonathan We ain't had a Tuesday yest this month.
23:16 jonathan *yet
23:16 pmichaud right
23:16 pmichaud release is July 21
23:16 pmichaud today is July 2
23:16 pmichaud so less than 3 weeks
23:16 jonathan aye
23:17 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.
23:17 skids bacek: what's the easy way to replicate it?
23:18 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.
23:18 pmichaud maybe we should put a ticket in the roadmap/critical path that calls for a decision to be made on July 14
23:19 bacek skids: comment out "ret = (void *)key;", uncomment "ret = (void *)Parrot_str_new_COW(interp, key);"
23:19 bacek skids: try to build parrot. For me it consistently fail on compiling PGE.
23:20 * skids wonders if it works with buckets=8...
23:21 nopaste "bacek" at 114.73.175.1 pasted "Premature collected keys in hash (bt)" (71 lines) at http://nopaste.snit.ch/17095
23:22 bacek skids: tweaking initial hash size is just trigger some underlying problem...
23:22 bacek ok, time for $dayjob.
23:22 skids Yeah but just wondering because it might be a clue.
23:28 nopaste "NotFound" at 213.96.228.50 pasted "Simple test for OrderedHash clone" (14 lines) at http://nopaste.snit.ch/17096
23:29 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:30 patspam joined #parrot
23:31 Zak joined #parrot
23:43 Whiteknight pmichaud++
23:43 Whiteknight (thanks for the hints on the blog)
23:46 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:50 Infinoid I sincerely hope L1 will be too low level to care about that.
23:58 Whiteknight yes, I suspect L1 will be playing with PMC* and STRING* pointers directly

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

Parrot | source cross referenced