Camelia, the Perl 6 bug

IRC log for #parrot, 2010-07-13

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 ash_ tcurtis: my original plan was to make an llvm based runcore that unrolls the runloop and runs the various llvm optimizations over that, but that is probably more than I can finish in the time we have left, so I am not sure of whats going to happen to that, i might start and just keep working on it after the GSoC ends
00:05 ash_ ping Coke
00:06 tcurtis ash_: sounds interesting.
00:06 ash_ i have been thinking, it might be easier, and along the same lines to do the same thing in pbc_to_exe
00:06 ash_ then it doesn't require the llvm
00:07 ash_ and it would make creating the llvm version that does it at runtime easier
00:18 dduncan joined #parrot
00:38 kid51_at_dinner make fulltest PASS on both linux/i386 and darwin/ppc at r48075 trunk
00:42 dalek partcl-nqp: 5fefe08 | Coke++ |  (3 files):
00:42 dalek partcl-nqp: basic [upvar]
00:42 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/5fefe08df19323b755b73529885564890326e3fd
00:45 tcurtis pynie?
00:45 purl somebody said pynie was http://code.google.com/p/pynie/ or a Python implementation for the Parrot virtual machine or not on nqp-rx
01:15 Mark tcurtis: thnx for the heads-up
01:16 tcurtis Mark: I'm also going to try and go through the tutorial and update it for NQP-rx.
01:19 cotto_work It's all kinds of fun to think about the code behind this: http://www.kivasystems.com/demo/index.html
01:20 cotto_work Note that the bots follow bar code stickers.  The tracks incidental effects of their bacek-like precision.
01:21 cotto_work s/tracks/tracks are/
01:26 * tcurtis almost wants to work in warehouse automation now.
01:30 tcurtis I like the subtle awesomeness of how when the inventory pod is there, a laser pointer indicates the item to be put in the shipping pod.
01:42 cotto "little or no worker training" = very yes
01:43 tcurtis Soon, they will replace the workers with more robots.
01:45 cotto "Go away before I replace you with a robot and some Perl."
01:55 plobsing joined #parrot
01:58 jsut_ joined #parrot
02:35 eternaleye joined #parrot
02:47 janus joined #parrot
03:06 cotto seen allison
03:06 purl allison was last seen on #parrot 4 days, 6 hours, 6 minutes and 38 seconds ago, saying: NotFound: that removes the roadblock, so someone can work on it when inclined  [Jul  8 20:59:36 2010]
03:13 hercynium joined #parrot
03:18 Chandon joined #parrot
03:27 khairul joined #parrot
03:34 khairul cotto: ping
03:36 cotto khairul, pong
03:45 dalek parrot: r48076 | khairul++ | branches/gsoc_instrument (7 files):
03:45 dalek parrot: Added documentation.
03:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48076/
03:45 dalek parrot: r48077 | khairul++ | branches/gsoc_instrument/src/​dynpmc/instrumentvtable.pmc:
03:45 dalek parrot: Lowercased vtable groups.
03:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48077/
05:47 NotFound cotto_work: actually winxed stage 0 written in C++ is a lot faster at compiling than the self-hosted stages, but the generated code is faster with the later.
05:49 NotFound Also, winxed programs can be as faster as hand-written pir.
05:53 cotto Shouldn't the generated code be the same speed?
05:54 NotFound cotto: should, but the self-hosted compiler has more optimizations.
05:54 cotto is tcurtis to blame?
05:55 NotFound No, winxed generates pir, doesn't uses past or post.
05:55 cotto I guess it wouldn't.
05:57 NotFound Stage 0 is not parrot based, so it's the only way.
05:58 uniejo joined #parrot
06:01 cotto though you'll get some for free once PIRATE is viable
06:04 NotFound Hope so, but anyway the stage 0 isn't feature complete, is mainly a bootstrap too, you are not supposed to use it for real programs.
06:04 NotFound s/too/tool
06:06 NotFound And stage 1 needs to do its own optimizations, to be able to know during compiling if expressions used to initialize consts can be optimized-out.
06:28 baest joined #parrot
06:48 jsut joined #parrot
07:20 fperrad joined #parrot
07:35 dalek parrot: r48078 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
07:35 dalek parrot: [distutils] more links
07:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48078/
07:50 rv2733 joined #parrot
08:10 arnsholt joined #parrot
08:39 arnsholt joined #parrot
08:53 muixirt joined #parrot
09:01 clinton joined #parrot
09:10 bacek aloha, humans
09:16 muixirt hi bacek
09:17 bacek hi, muixirt
09:23 nopaste "muixirt" at 192.168.1.3 pasted "splint warning: false alarm?" (11 lines) at http://nopaste.snit.ch/21984
09:23 muixirt bacek for you :-)
09:27 bacek muixirt, false alarm. Strings are allocated from GC and doesn't require explicit deallocation.
09:28 muixirt bacek so bufstart is freed/reused by the GC?
09:28 bacek muixirt, yes
09:35 muixirt bacek: is there a simple rule to differentiate these two types of pointers/chunks of memory?
09:35 bacek PMC and STRING are GCable.
09:36 muixirt and all other objects are not?
09:36 bacek Buffers too, but I would like to get rid of them. They are basically strings.
10:49 nopaste "muixirt" at 192.168.1.3 pasted "pir string test memory/gc issues" (15 lines) at http://nopaste.snit.ch/21985
10:51 jsut_ joined #parrot
10:52 muixirt bacek: that is interesting! in the middle of the loop of the pasted example emory usage drops significantly (according to top). explanation?
10:53 muixirt s/emory/memory/
10:54 bacek "pool compacting"
10:54 bacek $S0 = $S0 . $S1
10:55 bacek parrot's string are immutable.
10:55 bacek So there is allocation of new string for lhs $S0.
10:55 bacek But!
10:55 bacek GC compacting is kind of independent
10:56 bacek so, you can't "predict" when GC will be kicked off
10:57 muixirt and the loop seems to slow down
11:00 jan joined #parrot
11:27 AndyA joined #parrot
11:34 gaz joined #parrot
11:35 bkuhn joined #parrot
11:40 dalek rakudo: ae4538a | moritz++ | src/core/Bool.pm:
11:40 dalek rakudo: Bool.Str
11:40 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​e4538a4f92c455f9758732736e5f28ad0a806e6
11:51 he joined #parrot
11:52 whiteknight joined #parrot
11:53 kid51 joined #parrot
12:00 whiteknight good morning, #parrot
12:00 moritz Good morning, Mr. Withworth
12:11 bacek moritz, +1 :)
12:11 lucian joined #parrot
12:24 fperrad joined #parrot
12:25 whiteknight good morning moritz, bacek
12:25 whiteknight how are you guys today?
12:26 moritz I've had better days
12:37 ruoso joined #parrot
12:56 particle joined #parrot
13:00 Essobi joined #parrot
14:01 bubaflub joined #parrot
14:06 gbacon joined #parrot
14:08 whiteknight joined #parrot
14:13 plobsing joined #parrot
14:21 tcurtis joined #parrot
14:26 bubaflub joined #parrot
14:44 dalek winxed: r546 | NotFound++ | trunk/winxedst0.cpp:
14:44 dalek winxed: minimal support for float in stage 0
14:44 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=546
14:54 dalek winxed: r547 | NotFound++ | trunk/winxedst1.winxed:
14:54 dalek winxed: optimize + for float const in stage 1
14:54 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=547
15:02 dalek parrot: r48079 | khairul++ | branches/gsoc_instrument (7 files):
15:02 dalek parrot: Code changes as suggested by cotto++.
15:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48079/
15:08 cotto_work ~~
15:13 dalek winxed: r548 | NotFound++ | trunk/winxedst1.winxed:
15:13 dalek winxed: optimize == and != for string const in stage 1
15:13 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=548
15:13 dalek winxed: r549 | NotFound++ | trunk/winxedst1.winxed:
15:13 dalek winxed: codingstd fix
15:13 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=549
15:22 cotto_work nice diff, khairul
15:22 cotto_work sorry.  misspelled khairul++ ;)
15:23 khairul :)
15:26 patspam joined #parrot
15:28 dalek winxed: r550 | NotFound++ | trunk/ (2 files):
15:28 dalek winxed: optimize / for int and float const in stage 1
15:28 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=550
15:30 whiteknight joined #parrot
15:43 cotto_work khairul, is there any reason you're using pir::set__IP($x) instead of +$x?
15:44 cotto_work Instrument::Probe has a couple instances
15:44 khairul there were some that didn't work when i used +$x instead.
15:44 cotto_work really
15:44 khairul those should be in probe.nqp
15:44 cotto_work I'll have to dig into that
15:47 theory joined #parrot
16:13 eternaleye joined #parrot
16:15 whiteknight joined #parrot
16:19 skv_ joined #parrot
16:25 hercynium joined #parrot
16:43 zostay joined #parrot
16:44 cotto_work khairul: it looks like the build broke in your branch
16:45 khairul i'll try rebuilding.
16:48 cotto_work actually it may be a dependency issue
16:48 cotto_work the serial build looks ok
16:49 khairul rebuilding works find on my mac.
16:57 cotto_work make sure that src/dynpmc/instrumentgc.dump and src/dynpmc/instrumentvtable.dump depend on src/dynpmc/instrumentstubbase.dump
17:08 khairul done.
17:12 tcurtis Does PGE-style "{*} #= key" work with NQP-rx?
17:13 moritz tcurtis: I think so, but it's deprecated
17:13 cotto_work yes
17:13 cotto_work nqp uses it internally in one place
17:13 cotto_work well, two
17:14 * tcurtis is trying to rewrite the Squaak tutorial for NQP-rx.
17:14 cotto_work tcurtis++
17:14 cotto_work that's much needed
17:14 dalek parrot: r48080 | khairul++ | branches/gsoc_instrument/src/dynpmc/Rules.in:
17:14 dalek parrot: Added .dump file dependencies.
17:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48080/
17:14 cotto_work I'd put that on my todo list if my tuits weren't shot this week.
17:15 Coke tcurtis++
17:15 Coke tcurtis++
17:15 cotto_work but someone actually doing a thing is worth much more than a bunch of people with it on their todo lists
17:16 AndyA_ joined #parrot
17:16 moritz tcurtis: if you do, please don't mention #= key
17:16 moritz it's gone from Perl 6, so in time it will go from nqp-rx too
17:16 tcurtis moritz: alright. I'll just use proto.
17:17 moritz alternatives include 0) protos 1) smaller tokens that don't need that 2) <.helper> rules with their own action method 3) embedded NQP blocks that set contextual variables
17:18 AndyA_ joined #parrot
17:18 moritz tcurtis: if you need any help with the squaak tutorial, shout
17:19 moritz (not that I know PCT any better than you do... but maybe Perl 6, in parts)
17:29 moritz speakiing of which... I have a problem in Perl 6  + PIR which is the same in NQP, so I better ask here
17:30 moritz I want to get an attribute for an object at a particular class level
17:30 moritz so, for example if B inherits from A, and both have a '$!foo' attrib, I want to be able to obtain both the class A and class B level attribute
17:31 moritz I know that in PIR I can do that with a key
17:31 moritz a la   $P0 = getattribute $P1, ['A'], '$!foo'
17:31 moritz can I do the same with pir::getattribute__MAGIC(...) somehow?
17:32 cotto_work the MAGIC is documented in compilers/pct/src/PAST/Compiler.pir
17:34 moritz so I guess I need some kind of Q
17:35 moritz or is Q only for (set|get)_pmc_keyed?
17:35 Coke pir::getattribute__PQsS($P1, 'A', '$!foo') ?
17:35 Coke Q is for anything that takes a key, I thought, but Iunno.
17:36 moritz Coke: but will that work for class names with :: in it? like Regex::Match?
17:36 Coke moritz: if something else is turning that into a real key, you'll have to, to.
17:36 Coke *too
17:36 Coke if Regex::Match is really ['Regex'; 'Match'], e.g.
17:36 moritz yes, it is
17:37 moritz Coke: thanks, I'll try it... but first I have to unbreak what I broke right now... :(
17:39 pmichaud I'm concerned about jnthn/bacek's fix for TT #1631
17:55 theory joined #parrot
17:58 patspam joined #parrot
17:59 atrodo whiteknight> ping
18:03 whiteknight pong
18:03 whiteknight how are you today, atrodo?
18:03 atrodo I'm doing fine, how about yourself?
18:03 hercynium joined #parrot
18:05 pmichaud Coke: ping
18:06 whiteknight atrodo: I am doing well
18:07 atrodo Good.  I just wanted to ping you real quick to make sure you had seen my take on allison's lorito email ( http://github.com/atrodo/lorito )
18:07 whiteknight no, no I had not
18:08 whiteknight I'll look it over now. Thanks!
18:08 tcurtis atrodo++
18:08 atrodo Sure.  I was going to send a note to parrot-dev, but I hadn't had time yet
18:09 cotto_work I'd encourage you to weigh in.  The discussion seems to have died down.
18:11 atrodo I will, it's getting enough time to sit down to actually write the response, which should be soon
18:16 pmichaud 17:35 <Coke> Q is for anything that takes a key, I thought, but Iunno.
18:16 pmichaud Not exactly.
18:16 pmichaud Q is for "keyed aggregates"
18:17 pmichaud (which is why I didn't choose 'k', which would be for "keys")
18:17 Coke pmichaud: pong
18:17 pmichaud parrot really has two types of keys -- it has keys that can be standalone operands, and keys that are part of some other aggregate
18:17 pmichaud Q is for the latter.  we don't have one for the former yet.
18:18 Coke k.
18:18 pmichaud but that's not the source of my ping :)
18:18 moritz what I want is getattribtute ["Some";"Class"], $P0, '$!foo' with pir:: syntax
18:18 pmichaud moritz: afaik, PCT doesn't support that syntax yet except via :inline
18:19 pmichaud because we don't have a good mechanism for supporting ["Some";"Class"]
18:19 moritz :(
18:20 Coke if we're going to keep keys, we really need literal & dynamic keys.
18:20 pmichaud Coke: Agreed.
18:20 Coke at least then we could construct a Key at runtime to pass in.
18:20 pmichaud and we really need to decide if Key is something Parrot is going to keep.
18:20 pmichaud there's been discussion that ['Some';'Class']  would really end up being a constant RSA
18:21 Coke keys don't have to be strings, though, but sure, an RPA is fine.
18:21 pmichaud well, I suspect that $P0[key1;key2]  may not survive long.
18:22 pmichaud which would leave only the bare case, and those are almost always constants.  Anything else can be better constructed using non-keys.
18:22 cosimo joined #parrot
18:22 Coke I'm not sure why we support multilevel keys that way. (rather than just doing N single keyed entries)
18:22 pmichaud anyway, my question for Coke is in capacity as release manager :)
18:22 Coke shoot.
18:22 pmichaud (multilevel keys -- because it was expected to be faster)
18:23 pmichaud r48074 introduced a "fix" to resolve TT #1631
18:23 whiteknight multi-level keys are only "faster" because there is an easy mechanism for storing them as constants in bytecode
18:23 pmichaud however, the fix changes a fundamental behavior of exception handlers in PCT
18:23 whiteknight if we were better about storing array literals as constants, they would be faster
18:23 Andy joined #parrot
18:23 pmichaud by my reading, we should have a deprecation notice for that
18:23 pmichaud worse...
18:23 purl worse is, like, better
18:24 whiteknight purl forget worse
18:24 purl whiteknight: I forgot worse
18:24 pmichaud the "fix" is actually incorrect.  PCT before r48074 was exhibiting the correct (and designed behavior)
18:24 whiteknight purl worse is <reply>worse? Worse? I can't possibly get any worse!!
18:24 purl OK, whiteknight.
18:25 Andy Has anyone heard back from Coverity with scan credentials?
18:25 pmichaud I guess I'm trying to decide where I step in and say "too bad for Rakudo, this fix is wrong so I'm reverting it".  :-|
18:25 whiteknight pmichaud: wrong in what way?
18:26 whiteknight (I'm just coming in to this discussion, forgive the ignorance)
18:26 pmichaud whiteknight: no problem, it's new -- I only brought it up this morning.
18:26 Coke if the fix is causing other breakage, I'd revert it. If you can post some code that breaks post-patch-application, that would seem sufficient.
18:26 pmichaud I don't know if the fix causes other breakage.
18:26 pmichaud I do know that it's very possible that there would be languages or systems that would rely on the correct "unfixed" behavior.
18:26 Tene pmichaud: it breaks resuming from a handled exception.
18:26 Tene looks like, at least.
18:27 Coke (this would especially help decide if we're breaking existing behavior as opposed to fixing a bug slightly the wrong way.
18:27 pmichaud Tene: right, I meant any "actual" breakage.  I know that it breaks the design of PCT exception handlers -- I don't know if anyone was using that design.
18:27 Coke I'd rather not argue from the DarkPan, but provide a sample of code that fails to work properly with the patch.
18:28 pmichaud I suspect I can do that relatively quickly.
18:28 pmichaud just a moment.
18:28 Coke that said, if you think the fix is wrong, It's basically you vs. jonathan, which is basically a rakudo thing. I haven't heard any other hll folks asking after that ticket.
18:28 pmichaud jnthn++ on #perl6 said to go ahead and revert.
18:28 Coke 14:27 <@jnthn> Go ahead and revert it
18:29 Coke heh.
18:29 Coke there you go. =-)
18:29 pmichaud he had been looking at it as a bugfix, but it's not a bugfix.
18:29 Tene If you want to pass through exceptions of some sort, that's what we have rethrow for.
18:29 pmichaud Tene: right
18:29 jnthn I guess I don't grok the design.
18:29 Tene also what we have can_handle or whatever method on exception handlers for, but iirc, subclassed exception handlers don't work right?
18:30 pmichaud jnthn: you grok the notion that a Perl 6 CATCH block could be invoked multiple times within the same outer closure, yes?
18:30 Tene Oh.  Warnings.
18:30 purl hmmm... warnings is just a magical bitmask, iirc
18:30 Tene Warnings are automatically resumed.
18:30 jnthn pmichaud: Yes, that bit makes sense.
18:30 jnthn pmichaud: I meant the bigger picture though.
18:30 Tene So you catch a warning and ignore it by resuming, or logging, or whatever.
18:30 pmichaud Tene: correct
18:31 pmichaud but catching a warning cannot remove the exception handler -- it has to remain for other subsequent warnings from the same outer block
18:31 Tene That's a case where resumable exceptions are actually used.
18:31 pmichaud Tene++
18:31 pmichaud anyway, I'll revert.
18:31 jnthn Introspecting the continuation to find out if we threw from there feels wrong to me too.
18:32 Tene jnthn: we could add that behavior to the can_handle method of ExceptionHandler if we really want that to be a parrot default.
18:32 pmichaud I'd feel less bad about keeping the r48074 change if we were more than a week from a supported Parrot release.
18:33 jnthn Tene: It'd seem to me that if an exception is thrown from within an exception handler, that exception handler should be automatically excluded from consideration when looking for a handler.
18:33 Coke pmichaud: can always sneak it back in after. ;)
18:33 Tene We could even guard it with a flag in the EH that you have to enable, to keep compatibility.
18:33 jnthn Tene: Is there a case that breaks?
18:33 Coke pmichaud: speaking of exceptions; any way to farm out the NQP-RX update that would eliminate parrot-style control exceptions?
18:33 pmichaud Coke: well, whatever ends up in Parrot is what ends up in Rakudo Star :-)
18:34 Tene jnthn: If you want to catch warnings and log them your own way, you can only catch the first warning with this change.
18:34 pmichaud Coke: you mean eliminate the return exceptions?
18:34 joeri joined #parrot
18:34 jnthn Tene: No no, I wasn't asking what my patch breaks
18:34 Tene jnthn: if you want to exclude an EH from the search, that's what the can_handle method of EH is for; don't just remove the EH entirely.
18:34 Coke pmichaud: yes.
18:34 Tene Ah.  I misread, then.
18:34 Coke (partcl-nqp has some breakage pending resolution of that issue.)
18:35 Coke nothing super critical atm.
18:35 Tene jnthn: I can't think of any cases where you want an EH to catch exceptions thrown from itself, no.
18:35 pmichaud Coke: that's going to need to be post-Rakudo Star, I think.
18:35 jnthn Tene: Yes, that's what I was asking about. :-)
18:35 tcurtis It would be nice if there were pop_eh_i and push_eh_i ops. CATCH { } could pop and store the handler somewhere and resuming the exception would just push_eh first.
18:35 Tene I'm not confident at all that I'm exhaustively aware of all possibilities and use cases, though.
18:36 jnthn Me either, but it feels like at least a better default.
18:36 pmichaud I'm still not entirely convinced that eliminating the return exception is the correct thing to do, unless we can also properly pessimize it.
18:36 Coke pmichaud: wfm. (that's why I asked about the farming out instead of just asking you to do it. =-)
18:36 Coke pmichaud: doesn't have to be eliminated, I just know that that was one way to fix the issue that partcl-nqp has with nqp's usage/handling of those excpetions.
18:37 pmichaud Coke: the more likely fix is that we figure out how we want to attach return exceptions to the lexical routine in which they were created.
18:37 Tene pmichaud: gather/take is another use of resumable exceptions, fwiw.  I could imagine a control construct that intercepts take exceptions and does something with the payload, and then rethrows.
18:37 pmichaud and prevent the return handlers from catching any exceptions other than the lexically nested ones.
18:38 Coke note that this isn't just [return], but also [break] and [continue]
18:38 pmichaud Coke: yes, same issue there (for lexical-ness)
18:38 Coke but let's wait until next month. =-)
18:38 pmichaud we'll also want a way to handle  "next LABEL" and "redo LABEL" in Perl 6, which also needs this same mechanism.
18:39 Tene I have a proof of concept for that working on my old laptop somewhere, if it's of use to anyone...
18:39 mikehh joined #parrot
18:39 Tene I wonder if I can find it... :(
18:40 Tene Hmm.  Looks like old laptop is off at home, so can't get to it from here.  I'll try to look for it tonight.
18:40 davidfetter joined #parrot
18:41 jnthn pmichaud: On the topic of deprecation notices for this supported Parrot release...
18:42 jnthn pmichaud: Worth considering a possible blanket notice on p6object?
18:42 pmichaud jnthn: I wouldn't plan for p6object to go away yet
18:42 jnthn pmichaud: I'm not sure on timescales, thus the "possible"
18:42 jnthn pmichaud: I guess p6object needn't go. (more)
18:43 pmichaud p6object will certainly still be around after the October release
18:43 pmichaud the earliest it could possible disappear would be January
18:43 jnthn pmichaud: My point is more whether nqp-rx would be using it, for example.
18:43 pmichaud and I suspect it'll be around even then
18:43 Coke pmichaud: I was looking at [proc] in partcl-nqp, and wanted to update the args handling code. I think I'm going to write the args handling code in /tcl/ and just prepend it to the source of the procedure and avoid trying to do it all in past. evil?
18:43 jnthn pmichaud: OTOH, nqp-rx has its own repo and deprecation policy.
18:43 pmichaud I'm hoping that whatever you/we come up with will be able to work with p6object as well (more)
18:44 jnthn pmichaud: I am *very* worried that I'm going to run into deprecation policy stuff, anyway.
18:44 pmichaud i.e., someone could have p6objects and newp6objects and things would work out okay -- they're just two implementations of a similar API
18:45 pmichaud (thinking)
18:45 jnthn pmichaud: I'm not far enough along yet to have anything too solid.
18:45 pmichaud jnthn: right.  and since we're on 3-month deprecation cycles, I think we're likely to be okay.
18:45 pmichaud Unless you think nqp-rx will be switching to the new system before October.
18:45 jnthn pmichaud: Not so - if I work to the grant schedule it would be.
18:45 pmichaud which, I suppose is very possible.
18:46 pmichaud I'm fine with adding a notice that nqp-rx and pct may be switching to a new underlying metaobject api.
18:46 jnthn +1
18:46 purl 1
18:46 pmichaud (or however you want to phrase it)
18:46 jnthn .oO( /kick purl )
18:46 pmichaud most people aren't likely to be having to deal with things at that level anwyay.
18:46 jnthn pmichaud: Right, I agree.
18:47 jnthn pmichaud: And it'd be kinda sad not to have got a notice in that lets us move nqp-rx and PCT to a new underlying meta-object API and implementation, and not be able to reap the advantages I expect it can deliver.
18:47 pmichaud yes, add the notice.
18:47 jnthn OK, thanks, will do so.
18:52 pmichaud updated TT#1631
18:54 dalek parrot: r48081 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
18:54 dalek parrot: Revert "[pct] Emit a missing pop_eh to fix TT#1631."
18:54 dalek parrot: The pre-patch behavior is correct; invoking an exception handler
18:54 dalek parrot: (CATCH block) should not automatically remove the block from
18:54 dalek parrot: catching future exceptions.
18:54 dalek parrot: This reverts commit 946fbea64de09972e47576accba82cfe479a8ebc.
18:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48081/
18:55 Coke I haven't read the notice, but notices that "this will change" are vastly less helpful than "this is how you write code in the new world order."
18:55 Coke just fyi.
18:55 cotto_work +1
18:55 purl 1
18:56 tcurtis See the recent dynops change and the chaos that ensued.
18:57 pmichaud Coke: ideally, "this is how you write code" will be unchanged in the new world order
18:57 pmichaud Coke: but at this time we can't exactly guarantee that
18:59 PerlJam jnthn: blog about the new meta-object API and its advantages when you get a chance  :)
19:00 pmichaud PerlJam: see http://news.perlfoundation.org/2010/0​7/hague-grant-application-meta-m.html :-)
19:00 tcurtis jnthn: if your core meta-model implementation doesn't support multiple inheritance, please don't move NQP to it without implementing multiple inheritance on top of it for NQP.
19:00 * tcurtis doesn't want his code to break.
19:00 pmichaud NQP will continue to have multiple inheritance.
19:00 PerlJam oh!  jnthn++ pmichaud++ (Ian Hague)++  :-)
19:01 pmichaud the deep core may be single inheritance, but it'll have multiple inheritance on top
19:01 jnthn tcurtis: I thought I explained this yesterday?
19:01 jnthn tcurtis: Anyway, what pmichaud++ said
19:01 jnthn Maybe it wasn't you who asked. :-)
19:02 jnthn pmichaud: #phasers ;-)
19:06 tcurtis jnthn: It was me. But your responses yesterday sounded more like "languages that want multiple inheritance can implement it on top of it" than "Don't worry; your multiple inheriting P6object/NQP classes will still work." :)
19:08 jnthn tcurtis: Ah, I was not quite complete enough then. :-)
19:08 jnthn tcurtis: I shoulda then defined NQP as a language that wnated it. ;-)
19:08 jnthn tcurtis: I expect the level that doesn't handle it will rarely be used by folks directly, fwiw.
19:09 jnthn tcurtis: And it's still speculative that it won't anyway. :_)
19:13 LoganLK joined #parrot
19:33 * tcurtis has a segfault.
19:33 nopaste "tcurtis" at 192.168.1.3 pasted "ooh... segfault." (18 lines) at http://nopaste.snit.ch/21994
19:40 tcurtis On tracing, the last op the trace displays is "add P1, P2, 1". P2 being 60983 at that point.
19:40 cotto_work #ps in 50
19:41 bubaflub joined #parrot
19:45 chromatic joined #parrot
19:56 bacek ~~
19:56 bacek Good morning, humans.
19:57 cotto_work ~~ 'bacek'
19:57 chromatic aloha
19:57 bacek tcurtis, GC vs C stack issue.
19:57 bacek chromatic, aloha
19:58 bacek tcurtis, PObj_mark is recursive. And you created a veery-long CallContext chain with .tailcall.
20:02 tcurtis bacek: why does it work with intvals?
20:02 bacek tcurtis, because intvals aren't GCable.
20:02 bacek tcurtis, increase loop length by about factor 100.
20:03 bacek or try to put "sweep 1" just before .return.
20:03 tewk_ GC shouldn't use the c stack for its mark stack.
20:04 chromatic It shouldn't, but migrating to a non-recursive (and a resumable) GC is a lot of work.
20:06 dalek rakudo: f0dbe32 | moritz++ |  (3 files):
20:06 dalek rakudo: get rid of match-bool cheat
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​0dbe322c42b796711435d601f096db0de5ecf56
20:06 dalek rakudo: b196d2d | moritz++ | src/core/Mu.pm:
20:06 dalek rakudo: A Mu.perl which dumps attributes of custom classes
20:06 dalek rakudo: This also includes code for descending into parent classes, but it's disabled
20:06 dalek rakudo: because it doesn't quite work, and because Rakudo doesn't understand
20:06 dalek rakudo: initialization of parent attributes anway.
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​196d2de1c80f0ef8065148cf7a0e0e4be8a2eae
20:06 dalek rakudo: 66ca1a7 | moritz++ | docs/ChangeLog:
20:06 dalek rakudo: add some ChangeLog entries
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​6ca1a7c8d5f82796171f0a7ebca27aaa133d652
20:08 khairul joined #parrot
20:11 lucian joined #parrot
20:20 * Coke wonders what the best way to find the past for a sub with a single slurpy @args is. /me guess write it in NQP and run it through --target=past.
20:21 cotto_work that's pretty easy
20:22 tcurtis Coke: looks like PAST::Var.new(:scope<parameter>, :isdecl(1), :slurpy(1));
20:23 AndyA joined #parrot
20:23 dalek winxed: r551 | NotFound++ | trunk/winxedst1.winxed:
20:23 dalek winxed: predef two args atan in stage 1
20:23 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=551
20:23 Coke tcurtis: how do I name it? =-)
20:23 dalek rakudo: 97c91c6 | moritz++ |  (2 files):
20:23 Coke actually, that doesn't matter. danke.
20:23 dalek rakudo: remove Safe.pm. It was not working anyway, and screwed up innocent programs
20:23 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​7c91c6e0b2e55b931f6797389c629711c844a8f
20:24 bacek Coke, *@arg?
20:24 tcurtis Coke: :name<somename>
20:24 Coke bacek: yah. pretty much every tcl sub has to be *@args, because parrot's parameter error handling doesn't let me override what I need to. (so i have to take everything and sort it out inside the sub)
20:25 bacek Why not :call_sig (as in rakudo)?
20:25 Coke be nice if parrot gave a hook for a block that could be invoked on a sub if there was a signature mismatch.
20:25 Coke bacek: does that let me override the error message when the sub is invoked with the wrong # of args?
20:26 tcurtis Coke: I don't there is a wrong # of args if you do call_sig.
20:26 tcurtis It gets all the args to the sub IIRC.
20:26 bacek Coke, yes. Basically parrot will give up and put responsibility on arg passing to HLL
20:26 cotto_work :call_sig is more like "Here, you deal with it."
20:26 chromatic #ps in 5
20:26 Coke bacek: "how"?
20:26 purl "how" is probably different for different languages
20:27 bacek .param pmc sig :call_sig
20:27 bacek it will be CallContext object available for introspection.
20:28 Coke bacek - ok. is that substantially different that just taking in a .param pmc args :slurpy ?
20:29 bacek Coke, yes, it will contain named params as well
20:29 Coke (note that tcl doesn't really have non-positional named parameters, so that doesn't matter to me.) (they're named, but it's the position that matters)
20:29 Coke bacek: ok. so no difference. =-)
20:29 bacek :)
20:30 chromatic #ps in 1
20:30 * Coke grabs a koohii and hurries back.
20:34 wendar joined #parrot
20:34 wendar left #parrot
20:34 eternaleye joined #parrot
20:42 Topic for #parrotis now Parrot 2.5.0 Released! | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere | Priorities: review experimental features for promotion or removal, fix 'make html' (talk to Coke), update tutorial (talk to tcurtis), pre-release testing.
20:43 Coke ARGH. trac.parrot.org is overcaching again.
20:44 moritz any objections to removing the GSOC Students: start here to from the topic?
20:44 moritz I hope they've already started :-)
20:45 Topic for #parrotis now Parrot 2.5.0 Released! | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | Priorities: review experimental features for promotion or removal, fix 'make html' (talk to Coke), update tutorial (talk to tcurtis), pre-release testing.
20:45 * moritz waited long enough :-)
20:45 particle coke: if i know what's wrong, i can harrass #osuosl
20:45 atrodo 23 seconds is long enough these days?
20:45 moritz atrodo: depends :-)
20:49 Coke particle: edit a page. save your changes. taken to a page with no login creds with your changes not visible.
20:49 Coke it's their caching tool, they're probably overaggressively caching portions of trac.
20:49 particle varnish--
20:56 dalek tracwiki: v172 | coke++ | WikiStart
20:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=172&amp;action=diff
20:56 dalek tracwiki: v173 | coke++ | WikiStart
20:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=173&amp;action=diff
20:56 dalek tracwiki: v1 | coke++ | ResolveExperimentals
20:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Resolv​eExperimentals?version=1&amp;action=diff
20:56 dalek tracwiki: v2 | coke++ | ResolveExperimentals
20:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Resolv​eExperimentals?version=2&amp;action=diff
20:56 dalek tracwiki: v3 | coke++ | ResolveExperimentals
20:56 dalek tracwiki: convert some from pod to wiki
20:56 purl I don't know how to convert some from pod to wiki.
20:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Resolv​eExperimentals?version=3&amp;action=diff
20:56 particle coke: trac-side or drupal-side?
20:59 dalek rakudo: 615dfc9 | (Timothy Totten)++ |  (6 files):
20:59 dalek rakudo: Temporal/Date modifications and refactoring.
20:59 dalek rakudo: Changed how DateTime::strftime works.
20:59 dalek rakudo: Added DateTime::strftime to Makefile.in
20:59 dalek rakudo: Changed time-zone to timezone as per spec.
20:59 dalek rakudo: Changed DateTime.parse() to DateTime.new() as per spec.
20:59 dalek rakudo: Temporal => DateTime, and simplified changes.
20:59 dalek rakudo: Signed-Off-By: Moritz Lenz <moritz@faui2k3.org>
20:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​15dfc9a188bba6d6002b885ebcce1dbf539723b
20:59 dalek rakudo: 6ab7415 | moritz++ | build/Makefile.in:
20:59 dalek rakudo: build everything before we start testing
20:59 dalek rakudo: Behaves a bit weird otherwise: 'make spectest' seems to build Rakudo, but then
20:59 dalek rakudo: a 'make' or 'make install' builds modules.
20:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​ab7415762a5bc6269ddd8d4dae023e6f357a429
21:02 cognominal joined #parrot
21:09 Coke particle: trac., not www.
21:09 particle thanks
21:10 whiteknight joined #parrot
21:41 bubaflub joined #parrot
21:59 atrodo (catching up to the parrotsketch log) As I'm thinking it through, I'm guessing that  merging strings into pmc's will make some basic things more difficult
22:00 tcurtis atrodo: such as?
22:03 atrodo the main example I came up with was doing a lookup on a pmc.  If you don't have strings, it seems that the only way to do it is to either bootstrap another pmc (a String) or with an integer
22:07 tcurtis atrodo: one option for dealing with that is to have a default lookup scheme implemented at the C level. e.g., http://piumarta.com/softwar​e/id-objmodel/objmodel2.pdf
22:11 tcurtis Also, I think using symbols(i.e., strings with interning) as the keys for method dispatch might be preferable to strings.
22:14 tcurtis Particularly since we want to get rid of the vtable/method and pmc/object distinction.
22:16 whiteknight atrodo: if you don't have strings, you can do lookup with any PMC key which provides a hashing algorithm
22:17 AndyA joined #parrot
22:18 chromatic symbols for dispatch and named attribute access is the right approach
22:18 whiteknight symbols?
22:18 purl symbols are often combined in strange way
22:19 whiteknight purl forget symbols
22:19 purl whiteknight: I forgot symbols
22:19 sorear whiteknight: lisp symbols
22:19 sorear interned strings in Java-speak
22:20 sorear a symbol is like a string, but they're stored in a weak hash table, so two identical symbols will always be ref-identical
22:20 whiteknight ah, gotcha
22:20 sorear if the argument to getattribute is a symbol from the constant table, and objects are indexed by symbols, we only have to do an intptr_t comparison, not a strcmp
22:21 chromatic and we can use a sorted data structure for the index if we do a lot of comparison lookups.
22:21 sorear we shouldn't be doing many lookups
22:22 sorear $x."foo$bar" is a pretty rare op
22:22 chromatic True.
22:23 whiteknight PIC should take care of many of those cases, if we can ever get that project off the ground
22:23 tcurtis PIC?
22:23 purl i think PIC is a preprocessor for *roff, like tbl or eqn. or a language for drawing pictures and diagrams or pilot in command or MONKEY or Position Independant Code or Polymorphic Inline Cache or the popular line of Microcontrollers from Microchip or SHOW US THE PORN BITCH
22:24 chromatic We could populate most PICs at compile time, if we have a good expiration strategy.
22:25 tcurtis I'm guessing that polymorphic inline cache is the meaning we're using?
22:26 chromatic yes
22:43 atrodo note to self, don't start a conversation right before you have to leave.  sorry
22:44 gbacon joined #parrot
22:47 Tene I find that very useful, actually.  That way, you have a conversation to read when you get back.
22:48 atrodo Tene> That's true, I did, and I have some things to research
22:48 jnthn So adding to DEPRECATED.pod, it'll be "[eligible in 2.11]" for things I add now?
22:48 chromatic 2.9, I think.
22:48 jnthn k
22:48 chromatic or 2.7?
22:48 jnthn Wait, what is the current release going to be?
22:48 chromatic Post-lunch brainpower lull here.
22:48 atrodo I just don't have enough experience with not using strings as lookup keys to have a grasp of how that would work right now
22:48 chromatic 2.6
22:49 jnthn oh yeah, it's June
22:49 jnthn FAIL :-)
22:49 chromatic July!
22:50 jnthn Oh yes
22:50 jnthn ...I haven't even post-meal to blame this on.
22:51 jnthn Oh...months are normally indexed from 1 and releases are indexed from 0. :-)
22:51 chromatic I only remember because we celebrated US independence by blowing up small pieces of it.
22:52 jnthn The British sowed that habbit so that after long enough, it would all be blown up, and thus they didn't have to go to the cost of winning the independence war anyway.
22:52 particle i think we mostly blow up small pieces of china now
22:53 jnthn .oO( Dependence day )
23:02 dalek parrot: r48082 | chromatic++ | trunk/src/call/args.c:
23:02 dalek parrot: [pcc] Reordered switch to improve branch predicts.
23:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48082/
23:02 dalek parrot: r48083 | chromatic++ | trunk/docs/project/support_policy.pod:
23:02 dalek parrot: Explained experimental features more explicitly.
23:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48083/
23:03 cotto_work joined #parrot
23:12 GeJ Bonjour everyone.
23:15 chromatic ca va
23:15 dukeleto NOTE: GSoC midterms are due this Friday July 16th at 19:00 UTC. Mentors can submit them at http://socghop.appspot.com
23:16 GeJ Good evening chromatic.
23:16 dukeleto 'ello
23:17 GeJ Heya dukeleto.
23:17 purl dukeleto is mentoring a few peeps. can't remember everyone. sure.
23:18 dalek parrot: r48084 | jonathan++ | trunk/DEPRECATED.pod:
23:18 dalek parrot: Add deprecation notice on PCT's usage of P6object.
23:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48084/
23:19 tcurtis Hello, GeJ.
23:21 GeJ Hi tcurtis.
23:41 Coke jnthn: did you mean to remove TT#868 from the DEP?
23:43 Coke also, 2.9 is a supported release. it's either eligible to be removed in 2.7, or 2.10
23:48 jnthn Coke: ?
23:48 jnthn Coke: Didn't intend to remove anything, just add.
23:49 jnthn *confused look*
23:49 jnthn Coke: What is the correct "eleigible" line?
23:49 jnthn *eligible
23:49 jnthn 2.10 or 2.7?
23:49 * jnthn doesn't know latest dep pol
23:49 Coke 19:18 <+dalek> parrot: r48084 | jonathan++ | trunk/DEPRECATED.pod:
23:49 Coke you deleted an entry. did you mean to do that?
23:50 jnthn No
23:51 jnthn gah, how'd I manage that
23:51 Coke jnthn: if I look at the diff, you removed an entry.
23:51 Coke Iunno. =-)
23:51 jnthn Coke: added back
23:51 jnthn Coke: Is 2.7 too soon?
23:51 Coke as for eligibility release, it's basically "we can remove this from trunk any time after <supported release is cut>, which translate to the next non-supported release version.
23:51 jnthn Should it be 2.10?
23:52 Coke yes, 2.7 is too soon, because we need a notice in a supported version.
23:52 jnthn Right.
23:52 jnthn So 2.10
23:52 Coke er.
23:52 Coke wait. I haven't had any beer yet.
23:53 jnthn ETOOLATE # has had beer, just commits crap :-)
23:53 Coke ... I think you can say 2.7.
23:54 Coke because the notice will go out in 2.6, it's still /IN/ 2.6, and we don't support 2.7 or 2.8, so it doesn't matter. I think.
23:54 chromatic Sounds right to me, and I have Guinness in the fridge.
23:54 Coke yah. that sounds vaguely right. AIGH NO BEER.
23:55 * Coke switches to dewer's.
23:56 Psyche^ joined #parrot
23:56 jnthn Thanks, updated.

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

Parrot | source cross referenced