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', pre-release testing.
Set by moderator on 8 July 2010.
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:04
ping Coke 00:05
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
then it doesn't require the llvm
and it would make creating the llvm version that does it at runtime easier 00:07
00:18 dduncan joined
kid51_at_dinner make fulltest PASS on both linux/i386 and darwin/ppc at r48075 trunk 00:38
dalek rtcl-nqp: 5fefe08 | Coke++ | (3 files):
basic [upvar]
 00:42
tcurtis pynie? 00:45
purl somebody said pynie was code.google.com/p/pynie/ or a Python implementation for the Parrot virtual machine or not on nqp-rx
Mark tcurtis: thnx for the heads-up 01:15
tcurtis Mark: I'm also going to try and go through the tutorial and update it for NQP-rx. 01:16
cotto_work It's all kinds of fun to think about the code behind this: www.kivasystems.com/demo/index.html 01:19
Note that the bots follow bar code stickers. The tracks incidental effects of their bacek-like precision. 01:20
s/tracks/tracks are/ 01:21
tcurtis almost wants to work in warehouse automation now. 01:26
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:30
cotto "little or no worker training" = very yes 01:42
tcurtis Soon, they will replace the workers with more robots. 01:43
cotto "Go away before I replace you with a robot and some Perl." 01:45
01:55 plobsing joined 01:58 jsut_ joined 02:35 eternaleye joined 02:47 janus joined
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 03:18 Chandon joined 03:27 khairul joined
khairul cotto: ping 03:34
cotto khairul, pong 03:36
dalek rrot: r48076 | khairul++ | branches/gsoc_instrument (7 files):
Added documentation.
 03:45
rrot: r48077 | khairul++ | branches/gsoc_instrument/src/dynpmc/instrumentvtable.pmc:
Lowercased vtable groups.
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:47
Also, winxed programs can be as faster as hand-written pir. 05:49
cotto Shouldn't the generated code be the same speed? 05:53
NotFound cotto: should, but the self-hosted compiler has more optimizations. 05:54
cotto is tcurtis to blame?
NotFound No, winxed generates pir, doesn't uses past or post. 05:55
cotto I guess it wouldn't.
NotFound Stage 0 is not parrot based, so it's the only way. 05:57
05:58 uniejo joined
cotto though you'll get some for free once PIRATE is viable 06:01
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
s/too/tool
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:06
06:28 baest joined 06:48 jsut joined 07:20 fperrad joined
dalek rrot: r48078 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] more links
 07:35
07:50 rv2733 joined 08:10 arnsholt joined 08:39 arnsholt joined 08:53 muixirt joined 09:01 clinton joined
bacek aloha, humans 09:10
muixirt hi bacek 09:16
bacek hi, muixirt 09:17
nopaste "muixirt" at 192.168.1.3 pasted "splint warning: false alarm?" (11 lines) at nopaste.snit.ch/21984 09:23
muixirt bacek for you :-)
bacek muixirt, false alarm. Strings are allocated from GC and doesn't require explicit deallocation. 09:27
muixirt bacek so bufstart is freed/reused by the GC? 09:28
bacek muixirt, yes
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.
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.
nopaste "muixirt" at 192.168.1.3 pasted "pir string test memory/gc issues" (15 lines) at nopaste.snit.ch/21985 10:49
10:51 jsut_ joined
muixirt bacek: that is interesting! in the middle of the loop of the pasted example emory usage drops significantly (according to top). explanation? 10:52
s/emory/memory/ 10:53
bacek "pool compacting" 10:54
$S0 = $S0 . $S1
parrot's string are immutable. 10:55
So there is allocation of new string for lhs $S0.
But!
GC compacting is kind of independent
so, you can't "predict" when GC will be kicked off 10:56
muixirt and the loop seems to slow down 10:57
11:00 jan joined 11:27 AndyA joined 11:34 gaz joined 11:35 bkuhn joined
dalek kudo: ae4538a | moritz++ | src/core/Bool.pm:
Bool.Str
 11:40
11:51 he joined 11:52 whiteknight joined 11:53 kid51 joined
whiteknight good morning, #parrot 12:00
moritz Good morning, Mr. Withworth
bacek moritz, +1 :) 12:11
12:11 lucian joined 12:24 fperrad joined
whiteknight good morning moritz, bacek 12:25
how are you guys today?
moritz I've had better days 12:26
12:37 ruoso joined 12:56 particle joined 13:00 Essobi joined 14:01 bubaflub joined 14:06 gbacon joined 14:08 whiteknight joined 14:13 plobsing joined 14:21 tcurtis joined 14:26 bubaflub joined
dalek nxed: r546 | NotFound++ | trunk/winxedst0.cpp:
minimal support for float in stage 0
 14:44
nxed: r547 | NotFound++ | trunk/winxedst1.winxed:
optimize + for float const in stage 1
 14:54
rrot: r48079 | khairul++ | branches/gsoc_instrument (7 files):
Code changes as suggested by cotto++.
 15:02
cotto_work ~~ 15:08
dalek nxed: r548 | NotFound++ | trunk/winxedst1.winxed:
optimize == and != for string const in stage 1
 15:13
nxed: r549 | NotFound++ | trunk/winxedst1.winxed:
codingstd fix
cotto_work nice diff, khairul 15:22
sorry. misspelled khairul++ ;)
khairul :) 15:23
15:26 patspam joined
dalek nxed: r550 | NotFound++ | trunk/ (2 files):
optimize / for int and float const in stage 1
 15:28
15:30 whiteknight joined
cotto_work khairul, is there any reason you're using pir::set__IP($x) instead of +$x? 15:43
Instrument::Probe has a couple instances 15:44
khairul there were some that didn't work when i used +$x instead.
cotto_work really
khairul those should be in probe.nqp
cotto_work I'll have to dig into that
15:47 theory joined 16:13 eternaleye joined 16:15 whiteknight joined 16:19 skv_ joined 16:25 hercynium joined 16:43 zostay joined
cotto_work khairul: it looks like the build broke in your branch 16:44
khairul i'll try rebuilding. 16:45
cotto_work actually it may be a dependency issue 16:48
the serial build looks ok
khairul rebuilding works find on my mac. 16:49
cotto_work make sure that src/dynpmc/instrumentgc.dump and src/dynpmc/instrumentvtable.dump depend on src/dynpmc/instrumentstubbase.dump 16:57
khairul done. 17:08
tcurtis Does PGE-style "{*} #= key" work with NQP-rx? 17:12
moritz tcurtis: I think so, but it's deprecated 17:13
cotto_work yes
nqp uses it internally in one place
well, two
tcurtis is trying to rewrite the Squaak tutorial for NQP-rx. 17:14
cotto_work tcurtis++
that's much needed
dalek rrot: r48080 | khairul++ | branches/gsoc_instrument/src/dynpmc/Rules.in:
Added .dump file dependencies.
cotto_work I'd put that on my todo list if my tuits weren't shot this week.
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
moritz tcurtis: if you do, please don't mention #= key 17:16
it's gone from Perl 6, so in time it will go from nqp-rx too
tcurtis moritz: alright. I'll just use proto.
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:17
17:18 AndyA_ joined
moritz tcurtis: if you need any help with the squaak tutorial, shout 17:18
(not that I know PCT any better than you do... but maybe Perl 6, in parts) 17:19
speakiing of which... I have a problem in Perl 6 + PIR which is the same in NQP, so I better ask here 17:29
I want to get an attribute for an object at a particular class level 17:30
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
I know that in PIR I can do that with a key 17:31
a la $P0 = getattribute $P1, ['A'], '$!foo'
can I do the same with pir::getattribute__MAGIC(...) somehow?
cotto_work the MAGIC is documented in compilers/pct/src/PAST/Compiler.pir 17:32
moritz so I guess I need some kind of Q 17:34
or is Q only for (set|get)_pmc_keyed? 17:35
Coke pir::getattribute__PQsS($P1, 'A', '$!foo') ?
Q is for anything that takes a key, I thought, but Iunno.
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.
*too
if Regex::Match is really ['Regex'; 'Match'], e.g.
moritz yes, it is
Coke: thanks, I'll try it... but first I have to unbreak what I broke right now... :( 17:37
pmichaud I'm concerned about jnthn/bacek's fix for TT #1631 17:39
17:55 theory joined 17:58 patspam joined
atrodo whiteknight> ping 17:59
whiteknight pong 18:03
how are you today, atrodo?
atrodo I'm doing fine, how about yourself?
18:03 hercynium joined
pmichaud Coke: ping 18:05
whiteknight atrodo: I am doing well 18:06
atrodo Good. I just wanted to ping you real quick to make sure you had seen my take on allison's lorito email ( github.com/atrodo/lorito ) 18:07
whiteknight no, no I had not
I'll look it over now. Thanks! 18:08
tcurtis atrodo++
atrodo Sure. I was going to send a note to parrot-dev, but I hadn't had time yet
cotto_work I'd encourage you to weigh in. The discussion seems to have died down. 18:09
atrodo I will, it's getting enough time to sit down to actually write the response, which should be soon 18:11
pmichaud 17:35 <Coke> Q is for anything that takes a key, I thought, but Iunno. 18:16
Not exactly.
Q is for "keyed aggregates"
(which is why I didn't choose 'k', which would be for "keys") 18:17
Coke pmichaud: pong
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
Q is for the latter. we don't have one for the former yet.
Coke k. 18:18
pmichaud but that's not the source of my ping :)
moritz what I want is getattribtute ["Some";"Class"], $P0, '$!foo' with pir:: syntax
pmichaud moritz: afaik, PCT doesn't support that syntax yet except via :inline
because we don't have a good mechanism for supporting ["Some";"Class"] 18:19
moritz :(
Coke if we're going to keep keys, we really need literal & dynamic keys. 18:20
pmichaud Coke: Agreed.
Coke at least then we could construct a Key at runtime to pass in.
pmichaud and we really need to decide if Key is something Parrot is going to keep.
there's been discussion that ['Some';'Class'] would really end up being a constant RSA
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.
which would leave only the bare case, and those are almost always constants. Anything else can be better constructed using non-keys. 18:22
18:22 cosimo joined
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 :)
Coke shoot.
pmichaud (multilevel keys -- because it was expected to be faster)
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
pmichaud however, the fix changes a fundamental behavior of exception handlers in PCT
whiteknight if we were better about storing array literals as constants, they would be faster
18:23 Andy joined
pmichaud by my reading, we should have a deprecation notice for that 18:23
worse...
purl worse is, like, better
whiteknight purl forget worse 18:24
purl whiteknight: I forgot worse
pmichaud the "fix" is actually incorrect. PCT before r48074 was exhibiting the correct (and designed behavior)
whiteknight purl worse is <reply>worse? Worse? I can't possibly get any worse!!
purl OK, whiteknight.
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". :-|
whiteknight pmichaud: wrong in what way?
(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.
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.
pmichaud I don't know if the fix causes other breakage.
I do know that it's very possible that there would be languages or systems that would rely on the correct "unfixed" behavior.
Tene pmichaud: it breaks resuming from a handled exception.
looks like, at least.
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.
Coke I'd rather not argue from the DarkPan, but provide a sample of code that fails to work properly with the patch.
pmichaud I suspect I can do that relatively quickly. 18:28
just a moment.
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.
pmichaud jnthn++ on #perl6 said to go ahead and revert.
Coke 14:27 <@jnthn> Go ahead and revert it
heh. 18:29
there you go. =-)
pmichaud he had been looking at it as a bugfix, but it's not a bugfix.
Tene If you want to pass through exceptions of some sort, that's what we have rethrow for.
pmichaud Tene: right
jnthn I guess I don't grok the design.
Tene also what we have can_handle or whatever method on exception handlers for, but iirc, subclassed exception handlers don't work right?
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.
purl hmmm... warnings is just a magical bitmask, iirc
Tene Warnings are automatically resumed.
jnthn pmichaud: Yes, that bit makes sense.
pmichaud: I meant the bigger picture though.
Tene So you catch a warning and ignore it by resuming, or logging, or whatever.
pmichaud Tene: correct
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.
pmichaud Tene++
anyway, I'll revert.
jnthn Introspecting the continuation to find out if we threw from there feels wrong to me too.
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.
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. ;)
Tene We could even guard it with a flag in the EH that you have to enable, to keep compatibility.
jnthn Tene: Is there a case that breaks?
Coke pmichaud: speaking of exceptions; any way to farm out the NQP-RX update that would eliminate parrot-style control exceptions?
pmichaud Coke: well, whatever ends up in Parrot is what ends up in Rakudo Star :-)
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
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.
Coke pmichaud: yes.
Tene Ah. I misread, then.
Coke (partcl-nqp has some breakage pending resolution of that issue.)
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.
pmichaud Coke: that's going to need to be post-Rakudo Star, I think.
jnthn Tene: Yes, that's what I was asking about. :-)
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.
Tene I'm not confident at all that I'm exhaustively aware of all possibilities and use cases, though.
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.
Coke pmichaud: wfm. (that's why I asked about the farming out instead of just asking you to do it. =-)
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.
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.
pmichaud and prevent the return handlers from catching any exceptions other than the lexically nested ones.
Coke note that this isn't just [return], but also [break] and [continue] 18:38
pmichaud Coke: yes, same issue there (for lexical-ness)
Coke but let's wait until next month. =-)
pmichaud we'll also want a way to handle "next LABEL" and "redo LABEL" in Perl 6, which also needs this same mechanism.
Tene I have a proof of concept for that working on my old laptop somewhere, if it's of use to anyone... 18:39
18:39 mikehh joined
Tene I wonder if I can find it... :( 18:39
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
18:40 davidfetter joined
jnthn pmichaud: On the topic of deprecation notices for this supported Parrot release... 18:41
pmichaud: Worth considering a possible blanket notice on p6object? 18:42
pmichaud jnthn: I wouldn't plan for p6object to go away yet
jnthn pmichaud: I'm not sure on timescales, thus the "possible"
pmichaud: I guess p6object needn't go. (more)
pmichaud p6object will certainly still be around after the October release 18:43
the earliest it could possible disappear would be January
jnthn pmichaud: My point is more whether nqp-rx would be using it, for example.
pmichaud and I suspect it'll be around even then
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?
jnthn pmichaud: OTOH, nqp-rx has its own repo and deprecation policy.
pmichaud I'm hoping that whatever you/we come up with will be able to work with p6object as well (more)
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
(thinking) 18:45
jnthn pmichaud: I'm not far enough along yet to have anything too solid.
pmichaud jnthn: right. and since we're on 3-month deprecation cycles, I think we're likely to be okay.
Unless you think nqp-rx will be switching to the new system before October.
jnthn pmichaud: Not so - if I work to the grant schedule it would be.
pmichaud which, I suppose is very possible.
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
purl 1
pmichaud (or however you want to phrase it)
jnthn
.oO( /kick purl )
pmichaud most people aren't likely to be having to deal with things at that level anwyay.
jnthn pmichaud: Right, I agree.
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.
jnthn OK, thanks, will do so.
pmichaud updated TT#1631 18:52
dalek rrot: r48081 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
Revert "[pct] Emit a missing pop_eh to fix TT#1631."

  (CATCH block) should not automatically remove the block from
catching future exceptions. This reverts commit 946fbea64de09972e47576accba82cfe479a8ebc.		 18:54
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
just fyi.
cotto_work +1
purl 1
tcurtis See the recent dynops change and the chaos that ensued. 18:56
pmichaud Coke: ideally, "this is how you write code" will be unchanged in the new world order 18:57
Coke: but at this time we can't exactly guarantee that
PerlJam jnthn: blog about the new meta-object API and its advantages when you get a chance :) 18:59
pmichaud PerlJam: see news.perlfoundation.org/2010/07/hag...eta-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.
tcurtis doesn't want his code to break.
pmichaud NQP will continue to have multiple inheritance.
PerlJam oh! jnthn++ pmichaud++ (Ian Hague)++ :-)
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?
tcurtis: Anyway, what pmichaud++ said
Maybe it wasn't you who asked. :-)
pmichaud: #phasers ;-) 19:02
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:06
jnthn tcurtis: Ah, I was not quite complete enough then. :-) 19:08
tcurtis: I shoulda then defined NQP as a language that wnated it. ;-)
tcurtis: I expect the level that doesn't handle it will rarely be used by folks directly, fwiw.
tcurtis: And it's still speculative that it won't anyway. :_) 19:09
19:13 LoganLK joined
tcurtis has a segfault. 19:33
nopaste "tcurtis" at 192.168.1.3 pasted "ooh... segfault." (18 lines) at nopaste.snit.ch/21994
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 19:45 chromatic joined
bacek ~~ 19:56
Good morning, humans.
cotto_work ~~ 'bacek' 19:57
chromatic aloha
bacek tcurtis, GC vs C stack issue.
chromatic, aloha
tcurtis, PObj_mark is recursive. And you created a veery-long CallContext chain with .tailcall. 19:58
tcurtis bacek: why does it work with intvals? 20:02
bacek tcurtis, because intvals aren't GCable.
tcurtis, increase loop length by about factor 100.
or try to put "sweep 1" just before .return. 20:03
tewk_ GC shouldn't use the c stack for its mark stack.
chromatic It shouldn't, but migrating to a non-recursive (and a resumable) GC is a lot of work. 20:04
dalek kudo: f0dbe32 | moritz++ | (3 files):
get rid of match-bool cheat
 20:06
kudo: b196d2d | moritz++ | src/core/Mu.pm:
A Mu.perl which dumps attributes of custom classes

because it doesn't quite work, and because Rakudo doesn't understand initialization of parent attributes anway.
kudo: 66ca1a7 | moritz++ | docs/ChangeLog:
add some ChangeLog entries
20:08 khairul joined 20:11 lucian joined
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:20
cotto_work that's pretty easy 20:21
tcurtis Coke: looks like PAST::Var.new(:scope<parameter>, :isdecl(1), :slurpy(1)); 20:22
20:23 AndyA joined
dalek nxed: r551 | NotFound++ | trunk/winxedst1.winxed:
predef two args atan in stage 1
 20:23
Coke tcurtis: how do I name it? =-)
dalek kudo: 97c91c6 | moritz++ | (2 files):
remove Safe.pm. It was not working anyway, and screwed up innocent programs
Coke actually, that doesn't matter. danke.
bacek Coke, *@arg? 20:24
tcurtis Coke: :name<somename>
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)
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.
bacek: does that let me override the error message when the sub is invoked with the wrong # of args?
tcurtis Coke: I don't there is a wrong # of args if you do call_sig. 20:26
It gets all the args to the sub IIRC.
bacek Coke, yes. Basically parrot will give up and put responsibility on arg passing to HLL
cotto_work :call_sig is more like "Here, you deal with it."
chromatic #ps in 5
Coke bacek: "how"?
purl "how" is probably different for different languages
bacek .param pmc sig :call_sig 20:27
it will be CallContext object available for introspection.
Coke bacek - ok. is that substantially different that just taking in a .param pmc args :slurpy ? 20:28
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)
bacek: ok. so no difference. =-)
bacek :)
chromatic #ps in 1 20:30
Coke grabs a koohii and hurries back.
20:34 wendar joined, wendar left, eternaleye joined
moderator 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:42
Coke ARGH. trac.parrot.org is overcaching again. 20:43
moritz any objections to removing the GSOC Students: start here to from the topic? 20:44
I hope they've already started :-)
moderator 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
atrodo 23 seconds is long enough these days?
moritz atrodo: depends :-)
Coke particle: edit a page. save your changes. taken to a page with no login creds with your changes not visible. 20:49
it's their caching tool, they're probably overaggressively caching portions of trac.
particle varnish--
dalek tracwiki: v172 | coke++ | WikiStart 20:56
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
tracwiki: v173 | coke++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
tracwiki: v1 | coke++ | ResolveExperimentals
tracwiki: trac.parrot.org/parrot/wiki/Resolve...ction=diff
tracwiki: v2 | coke++ | ResolveExperimentals
tracwiki: trac.parrot.org/parrot/wiki/Resolve...ction=diff
tracwiki: v3 | coke++ | ResolveExperimentals
tracwiki: convert some from pod to wiki
purl I don't know how to convert some from pod to wiki.
dalek tracwiki: trac.parrot.org/parrot/wiki/Resolve...ction=diff
particle coke: trac-side or drupal-side?
dalek kudo: 615dfc9 | (Timothy Totten)++ | (6 files):
Temporal/Date modifications and refactoring.

Added DateTime::strftime to Makefile.in Changed time-zone to timezone as per spec. Changed DateTime.parse() to DateTime.new() as per spec. Temporal => DateTime, and simplified changes. Signed-Off-By: Moritz Lenz <moritz@faui2k3.org>		 20:59
kudo: 6ab7415 | moritz++ | build/Makefile.in:
build everything before we start testing

a 'make' or 'make install' builds modules.
21:02 cognominal joined
Coke particle: trac., not www. 21:09
particle thanks
21:10 whiteknight joined 21:41 bubaflub joined
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 21:59
tcurtis atrodo: such as? 22:00
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:03
tcurtis atrodo: one option for dealing with that is to have a default lookup scheme implemented at the C level. e.g., piumarta.com/software/id-objmodel/objmodel2.pdf 22:07
Also, I think using symbols(i.e., strings with interning) as the keys for method dispatch might be preferable to strings. 22:11
Particularly since we want to get rid of the vtable/method and pmc/object distinction. 22:14
whiteknight atrodo: if you don't have strings, you can do lookup with any PMC key which provides a hashing algorithm 22:16
22:17 AndyA joined
chromatic symbols for dispatch and named attribute access is the right approach 22:18
whiteknight symbols?
purl symbols are often combined in strange way
whiteknight purl forget symbols 22:19
purl whiteknight: I forgot symbols
sorear whiteknight: lisp symbols
interned strings in Java-speak
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
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
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
$x."foo$bar" is a pretty rare op 22:22
chromatic True.
whiteknight PIC should take care of many of those cases, if we can ever get that project off the ground 22:23
tcurtis PIC?
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
chromatic We could populate most PICs at compile time, if we have a good expiration strategy. 22:24
tcurtis I'm guessing that polymorphic inline cache is the meaning we're using? 22:25
chromatic yes 22:26
atrodo note to self, don't start a conversation right before you have to leave. sorry 22:43
22:44 gbacon joined
Tene I find that very useful, actually. That way, you have a conversation to read when you get back. 22:47
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?
chromatic 2.9, I think.
jnthn k
chromatic or 2.7?
jnthn Wait, what is the current release going to be?
chromatic Post-lunch brainpower lull here.
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
chromatic 2.6
jnthn oh yeah, it's June 22:49
FAIL :-)
chromatic July!
jnthn Oh yes 22:50
...I haven't even post-meal to blame this on.
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.
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
jnthn
.oO( Dependence day )
 22:53
dalek rrot: r48082 | chromatic++ | trunk/src/call/args.c:
[pcc] Reordered switch to improve branch predicts.
 23:02
rrot: r48083 | chromatic++ | trunk/docs/project/support_policy.pod:
Explained experimental features more explicitly.
23:03 cotto_work joined
GeJ Bonjour everyone. 23:12
chromatic ca va 23:15
dukeleto NOTE: GSoC midterms are due this Friday July 16th at 19:00 UTC. Mentors can submit them at socghop.appspot.com
GeJ Good evening chromatic. 23:16
dukeleto 'ello
GeJ Heya dukeleto. 23:17
purl dukeleto is mentoring a few peeps. can't remember everyone. sure.
dalek rrot: r48084 | jonathan++ | trunk/DEPRECATED.pod:
Add deprecation notice on PCT's usage of P6object.
 23:18
tcurtis Hello, GeJ. 23:19
GeJ Hi tcurtis. 23:21
Coke jnthn: did you mean to remove TT#868 from the DEP? 23:41
also, 2.9 is a supported release. it's either eligible to be removed in 2.7, or 2.10 23:43
jnthn Coke: ? 23:48
Coke: Didn't intend to remove anything, just add.
*confused look* 23:49
Coke: What is the correct "eleigible" line?
*eligible
2.10 or 2.7?
jnthn doesn't know latest dep pol
Coke 19:18 <+dalek> parrot: r48084 | jonathan++ | trunk/DEPRECATED.pod:
you deleted an entry. did you mean to do that?
jnthn No 23:50
gah, how'd I manage that 23:51
Coke jnthn: if I look at the diff, you removed an entry.
Iunno. =-)
jnthn Coke: added back
Coke: Is 2.7 too soon?
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.
jnthn Should it be 2.10?
Coke yes, 2.7 is too soon, because we need a notice in a supported version. 23:52
jnthn Right.
So 2.10
Coke er.
wait. I haven't had any beer yet.
jnthn ETOOLATE # has had beer, just commits crap :-) 23:53
Coke ... I think you can say 2.7.
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.
Coke yah. that sounds vaguely right. AIGH NO BEER.
Coke switches to dewer's. 23:55
23:56 Psyche^ joined
jnthn Thanks, updated. 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!