Parrot 1.8.0 Zygodactyly released | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
Set by moderator on 5 December 2009.
00:06 Khisanth joined
cotto rather, it complains that things that are there aren't 00:08
sadly not annoying enough to be worth patching, though
00:32 mikehh joined 00:49 jhelwig joined
japhb chuffs in frustration at the inadequacy of email as a medium of communication 00:51
dukeleto japhb: yeah, it sucks 00:54
japhb Sometimes I feel like adding a .sig that says "Did my email piss you off? Try rereading it, this time assuming I'm NOT an idiot." 00:55
In person, I'm not exactly known for idiocy ... but I have yet to make that stick in text. 00:56
dukeleto i run benchmarks to give parrot devs info. do with it what ye will. i think it got a little too serious on list, but it is good to talk about. we need a policy for how to deal with benchmark results 00:58
00:58 abqar joined 01:02 mj41 joined
Coke ETOOMUCHPOLICY 01:15
01:17 colomon__ joined
dalek rrot-linear-algebra: 9437eab | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
support get_pmc_keyed_int
 01:29
rrot-linear-algebra: 3b4cd5a | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
add some sanity tests for indices
dukeleto Coke: i mean "policy" very loosely, in the sense of "what do we do when stuff gets really slow, OR how slow do things have to get for us to care?"
Coke dukeleto: very good. 01:30
also: we're already too slow. =-)
(so thank you for running benchmarks) 01:32
Coke realizes the irony of trying humor over text after recent complaints about text-based communications. 01:33
01:38 colomon_ joined
Whiteknight how do we turn off argument counting error checking 01:46
?
dukeleto Whiteknight: never even heard of it before 01:48
Whiteknight there is a way, I just don't know how
bacek_at_work Whiteknight, errorsoff .PARROT_ERRORS_PARAM_COUNT_FLAG 01:51
you have to include errors.pasm
(for constant definitions)
Whiteknight thanks bacek++ 01:54
02:09 kid51 joined
kid51 If there's any one who can comment on trac.parrot.org/parrot/ticket/1267#comment:6, I would appreciate that. 02:21
Coke is this the "configure is checking for a library one way, but the test file is checking a different way" bug?
dukeleto kid51: i think it may be broke and i may be partly to blame, is that good?
the test checks the value of Config['gmp'] or somesuch 02:22
Coke that seems reasonable.
kid51 If you could post in the ticket itself, that would be great. 02:23
dukeleto kid51: which platform does it happen to you on? 02:34
kid51: i put my 2 cents in 02:35
kid51 dukeleto: As reported in ticket, it happens to me on Linux and Darwin 02:38
02:39 lucian joined
kid51 must sleep 02:39
purl $kid51->sleep(8 * 3600);
dalek parrot: 05d3f14 | (David Fetter)++ | HOWTO:
The changes in src/handler/Makefile mean PGXS is the default, so no
 02:47
dukeleto ooh, i like the bxors() opcode 02:52
k:q 02:53
darn, this is not vim
02:53 JimmyZ joined 02:55 bacek joined
Coke do we really need another LICENSE in the ops files? 02:59
or is that cargo culted from a perl5 cargo cul?
*t
dukeleto how do i count set bits in PIR? 03:01
Coke: what talketh you about?
meh: The opcode 'length_i_p' (length<2>) was not found. 03:24
do we really not have min(), max() opcodes for ints? 03:29
Coke points at LICENSE at the end of the file containing bxors. 03:35
dukeleto: what does length of a Hash mean?
dukeleto Coke: length of a PMC. like a String
Coke right. what if it's not a string? 03:36
dukeleto Coke: i don't know. but $I0 = length $P0 for a String seems reasonable
Coke yes, but $I0 = length $P0 for a Hash does nt. =-)
dukeleto Coke: length of a Hash can be # of keys
Coke ok. length of a CallSig? Coroutine? 03:37
my point being that if you want string length, you can be explicit about it.
dukeleto Coke: does an opcode have to be valid for every permutation of input values? I think not.
Coke dukeleto: ... that borks HLL compatibility.
plobsing_ we already have an op that gets boxed string length: elements 03:38
Coke you then have to worry about wrapping every opcode in an exception handler.
dukeleto Coke: why do you want people to have to code more, when Parrot is perfectly able to say "hey this is string, this is what you want" as well as "d00d, that is some random PMC, i don't know what the length of that is"
Coke dukeleto: so what should it do? throw an exception?
dukeleto plobsing_: elements, you say?
Coke: sure. length() of FooBaz not implemented
plobsing_ check src/pmc/string.pmc 03:39
Coke dukeleto: ok. then I have to wrap EVERY opcode I invoke if I want to not barf all the time. (assuming I am operating on pmcs handed to me, not PMCs I have generated)
one more opcode is not a lot more code.
s/EVERY/most every/ , anyway.
*sigh*. nevermind. I can, of course, just use the string register version myself. I'll let your code explode, though. =-) 03:43
I do stand by my assertion that an extra opcode to cast is not onerous, however. 03:44
on a tangent, I hate IE6. hate it.
JimmyZ msg kid51 I had uploaded new patch to TT #1357 and it passed the tests. Welcome to test it again. 03:51
purl Message for kid51 stored.
pmichaud good evening, #parrot
JimmyZ good evening, pmichaud
03:58 naypalm joined
plobsing_ hey, if anyone cares to comment on TT #1359, I'd appreciate the input. 03:59
Coke wtf. I go to trac.parrot.org; I type in '#' to the search bar, it hangs. 04:03
(my /browser/)
pmichaud plobsing_: I don't understand all of the internal details/ramifications of TT #1359, but from my perspective it looks really useful. Would thawing a string cause it to execute any :load subs as well? 04:08
04:08 Essobi joined
plobsing_ looking in eval.pmc ... 04:08
right now, yes. I don't think it should though 04:09
eventually
purl eventually we'll all be dead
plobsing_ purl, forget eventually 04:11
purl plobsing_: I forgot eventually
plobsing_ IMHO, thawing shouldn't execute arbitrary code. it should give you the option to examine first. 04:12
and thats how I thought it worked now. but after a little poking, it turns out thats not quite what happens. 04:13
pmichaud if thawing causes subs to be loaded into namespaces, I think it should also honor the :load flag 04:15
at least, that's what load_bytecode does
I'd be okay if there's a method on Eval PMCs that says "process all :load subs" though. 04:16
one thing I like about the #1359 proposal is that we still have a way of executing the first sub of the Eval, which load_bytecode doesn't currently provide (and I've needed on several occasions)
plobsing_ looking at things, it might not solve all your loading problems right now, but with a few tweaks to Eval.pmc, it should be pretty nifty 04:19
I'll try to put together a patch this week and see how it goes. 04:20
pmichaud +1 04:21
purl 1
pmichaud dukeleto: ping 04:39
dalek parrot: 786c8e4 | dukeleto++ | HOWTO:
Improve HOWTO
 04:47
parrot: e9c2eae | (Joshua Tolley)++ | CREDITS:
Lay claim to a piecs of the world domination pie
 04:53
dukeleto pmichaud: pong 04:54
pmichaud dukeleto: was just wondering where the source was for the array_access benchmark... but just found it.
dukeleto jut wrote a small string benchmark for parrot. let's see how the benchmark sharks like it
pmichaud: :) 04:55
pmichaud for the gist.github.com/250599 results, did the benchmark only get run once? 04:56
dukeleto pmichaud: hmmmm 04:57
pmichaud if so, the differences look like they might be timer noise
if array access did get significantly slower between 1.8.0 and HEAD, though, that's significant.
dukeleto pmichaud: i will do that benchmark again. i just found a bug in euler_bench. arg! 04:58
pmichaud: running array_access.pir again, results shortly 05:00
pmichaud: i run --count=1 first to see if stuff segfaults/parses. i must have gist'ed the wrong output
pmichaud afk, sleep 05:03
dukeleto pmichaud: night
pmichaud++ for noticing --count=1 05:04
cotto Cool. It looks like we may get an unexpected benefit from the RTEMS work. wtg dukeleto++ 05:15
dukeleto cotto: the RTEMS peeps are pretty cool
what I wouldn't give for ||= in PIR 05:17
cotto dukeleto, isn't that what vivify is for? 05:18
dukeleto cotto: is that one of them new-fangled opcodes that pmichaud asked for?
cotto nm. that's only for keyed access 05:19
but yes, they're in src/ops/experimental.ops
dukeleto cotto: close, but not exactly what i want
cotto no cigar for me 05:20
how much would it save you?
dukeleto cotto: it would abstract away the need for a label and a goto whenever you want to default something that is not truthfully defined 05:23
cotto you could always propose something on parrot-dev
dukeleto cotto: in my current situation, i am pulling out command line args, and if then are not defined, set them to a default
cotto but that's useful in a lot of places
dukeleto cotto: this requires an if/goto/label for each arg. i should be using Getopt::Obj, but this issue is more general. and I am writing a benchmark, so no Getopt::Obj 05:24
05:36 DrForr_ joined
cotto between a pointer and an INTVAL, can I say for certain that one will always be larger if they're not the same size? 05:54
dukeleto cotto: no 05:56
cotto: that stuff usually needs a configure-time check 05:57
cotto goodie
dukeleto cotto: what are you trying to do?
cotto make a static array where I can store both intvals and pointers 05:58
s/static//
06:02 chromatic joined
dukeleto chromatic: hola 06:09
incoming
purl duck!
chromatic Those array_access.pir numbers confuse me. 1.8 looks like it's in there twice, with different numbers. 06:10
dukeleto chromatic: that is 0.8.0 06:12
chromatic Oh. Hm. Maybe I shouldn't be reading now. 06:14
dalek rrot: r42921 | dukeleto++ | trunk (2 files):
[examples] Add a benchmark geared towards strings which computes the Hamming distance between two strings
dukeleto chromatic: :) you gave me a scare for a moment. i have been staring at the output of euler_bench too long...
chromatic It'd be nice to figure out at which commit array access turned so much slower. 06:15
dukeleto chromatic: git bisect hooked up to a benchmark test. interesting.
chromatic I have no small fear that it's the GC tuning. 06:17
dukeleto chromatic: i have a gc benchmark going to parrot-dev in a few
dukeleto is running stress1.pasm now 06:18
my --count=1 run made trunk look pretty good
06:20 theory joined 06:22 dan joined
dukeleto chromatic: gist.github.com/250669 stress1.pasm 06:43
chromatic GC's not substantially better in trunk. 06:48
dukeleto chromatic: wishful thinking 06:54
chromatic I'd like to think some of the tuning has had an effect. 06:56
JimmyZ hello chromatic 06:58
chromatic Hi JimmyZ. I saw that kid51 tested some of your patches.
JimmyZ chromatic: yes
chromatic What's left to review, everything? 06:59
JimmyZ chromatic: he wants others could review it again. 07:00
chromatic Okay, I can do that. 07:01
cotto I'll take one or two too.
I'll do 1346. 07:02
dukeleto should i report benchmarks that look OK or do y'all only want the bad news?
JimmyZ chromatic: I had a question for capture.pmc. :) why it must do CAPTURE_array_CREATE when modifies it's attr, not just like other PMCs, using init()?
cotto nm. My parrot's goofy from profiling work. 07:03
nm the nm. That doesn't actually affect anything.
JimmyZ chromatic: Did I describe correctly? 07:04
chromatic I think it's autovivifying an attribute which may not yet exist. 07:05
I haven't read the code today, but I think that's the idea.
cotto It looks like an optimization to avoid creating Hash and RPAs that won't be used. 07:07
JimmyZ chromatic: I think so, it always need check capture.pmc's attr whether it exists or not.
It's a bit different from other PMCs.
07:08 uniejo joined
JimmyZ cotto: yep 07:08
cotto: sometimes re-ordering codes is useful, I think. 07:09
cotto the args.c changes (TT #1346) are committed. 07:10
JimmyZ, TT #1280 needs your comments. 07:13
JimmyZ cotto: I think old var doesn't need. 07:16
cotto: It's unused tmp var. :)
cotto: maybe I am wrong? But I couldn't find it's useful. 07:18
cotto examining TT #1348
dalek rrot: r42922 | cotto++ | trunk/src/call/args.c:
[PCC] reorder some code to avoid unnecessary execution, patch courtesy of JimmyZ++
 07:19
TT #1346 closed by cotto++: [patch]Removed unused macro in pobj.h, reordered codes in args.c 07:22
JimmyZ cotto: already added comment to #1280 07:24
cotto TT #1354 closed 07:28
I'll need sleeps soon.
JimmyZ cotto: good night. 07:30
cotto night, JimmyZ 07:31
chromatic I almost want standard deviation in those benchmarks.
dukeleto chromatic: i have already been wanting that for 2 days. i am close to implementing it in euler_bench :) 07:32
chromatic The cluster for the Hamming distance benchmark could go lots of directions post 1.2. 07:33
dalek rrot: r42923 | cotto++ | trunk/lib/Parrot/Vtable.pm:
[vtable] don't emit the now-unused PARROT_VTABLE_FOO_METHNAME macros in vtable.h
 07:36
TT #1354 closed by cotto++: [patch]removed unused codes from Vtable.pm 07:38
07:41 bacek joined
cotto Is it a bad idea to have a HUGEINTVAL[] and to cast to/from pointers and INTVALs when sticking data into the array? 07:44
dukeleto chromatic: what exactly do you mean by that? 07:45
cotto (considering 64-bit) 07:46
naypalm the PMCs resize to inf don't they?
chromatic dukeleto, I think you'd get a different ordering if you ran it again. The numbers in the top five are too close to mean much to me. 07:47
dukeleto chromatic: that was an ensemble of 300, but i hear ya. that is why i referred to a "fast" pack. everything since 1.2.0 is essentially the same
chromatic: which means we need better string benchmarks 07:48
chromatic: you want to throw some tuits at that?
cotto naypalm, the resizable array PMCs will automatically resize and can use as much memory as you care to throw at them. Is that what you mean?
naypalm it is indeed!
I worked out max int with powers of two and converting.. 07:49
dukeleto naypalm: ResizablePMCArrays can be resized. FixedPMCArrays cannot :)
naypalm what's the main problem with mutable? just that you have to be ready to increase the size?
dukeleto naypalm: huge performance differences between arrays that you know will never change in size 07:50
naypalm so we get them the same size and hey-presto!
-size+speed
dukeleto naypalm: what are you working on? 07:51
naypalm nothing at all, I was just on my travels and thought I'd look at parrot.. then fell in love with the data structure that is everything :
:| 07:52
cotto PMCs have their charms and their warts.
naypalm been reading through random scraps of code and writing little things here
just familiarizing myself :)
dukeleto naypalm: yes, PMC = Parrot Magic Cookie
chromatic I'm not sure what would make a good STRING benchmark. 07:53
cotto If you've got some wart remover, feel free to share. ;)
dukeleto naypalm: the examples/ directory may be interesting to you
chromatic: specifically a String PMC benchmark
naypalm you inject the strings straight into the bytecode, there's no need for them :P
dukeleto chromatic: our string core type seems pretty fast and stable
chromatic: unicode conversions? 07:54
chromatic: i am looking at this for a string benchmark: projecteuler.net/index.php?section=...&id=60 07:58
chromatic How would you do that with strings? 07:59
naypalm if you're looking to bench numbers more than 5 digits then no
dukeleto chromatic: it requires a bench of concatenation and prime-checking 08:00
08:00 JimmyZ joined
naypalm yeah, also you don't have very long strings either! 08:00
dukeleto chromatic: this requires reversing lots of strings and converting back and forth between string/ints projecteuler.net/index.php?section=...amp;id=125 08:01
chromatic I'd use STRINGs, not the String PMC. 08:02
String is a boxed wrapper around STRING, for the most part.
dukeleto chromatic: yeah, but we are trying to bench the String PMC
08:03 iblechbot joined
chromatic I suppose, but I don't see a lot of value in that. 08:03
It hasn't changed much in a long time. 08:04
naypalm codepad.org/beTC6TQr I did that to get my feet wet.. 08:05
not very helpful for anything, but we'll be beating C in a few months?
dukeleto chromatic: to be sure we aren't getting horribly slow for an unknown reason, i guess 08:07
chromatic I'd feel more comfortable if there were STRING and String versions of such a benchmark. 08:08
dukeleto chromatic: yes, i know. it just gets tedious writing so many versions of every benchmark. but you are right. 08:10
chromatic That one shouldn't be too difficult.
dukeleto chromatic: yes, i just got to the end of my writing-benchmarking-code rope for the day :) have at it 08:11
dukeleto self.'sleep'() 08:12
naypalm have you got a big main step planned? 08:18
cotto just cast a string literal to an INTVAL. 08:21
chromatic Hm, what if ExceptionHandler had an init_pmc() which took an Integer representing the single type of exception it can handle? 08:26
No more handle_types() method call for a common case.
20.473% improvement in the fib4.pir benchmark pmichaud convinced NQP-rx to emit, with the obvious PIR change. 08:27
Of course, constant exception handlers would be nice too. 08:28
I think he mentioned something about constant PMCs. 08:29
08:39 fperrad joined 08:47 fperrad_ joined
mikehh All tests PASS (pre/post-config, smoke (#30672), fulltest) at r42923 - Ubuntu 9.10 amd64 (gcc with --optimize) 09:33
dalek tracwiki: v3 | cotto++ | CottoTasklist 09:47
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
rrot: r42924 | chromatic++ | trunk/src/ops/pmc.ops:
[ops] Modified the new PMC, STRING ops to avoid creating or checking for a

fib4.pir benchmark (generated by NQP-rx) by 3.195%, and likely several others.
JimmyZ I found that many places that used SELF.foo() could be rewrite as STATICSELF.foo(). 09:54
in PMC
10:11 bacek joined
cotto chromatic, I'm off to bed, but I'd appreciate it if you could give this next commit a review. I'm mostly curious what the best way to accomplish what I did with the PPROF_DATA macro is. 10:13
night
I'll check the backscroll. 10:14
ttbot Parrot trunk/ r42925 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/167239.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 10:15
naypalm you can't use llvm can you? 10:16
chromatic Will review. 10:18
dalek rrot: r42925 | cotto++ | trunk (3 files):
[profiling] refactor profiling runcore output to make mulitple formats possible
 10:20
10:39 bacek joined 11:19 bacek joined
dalek nxed: r247 | julian.notfound++ | trunk/ (2 files):
yield in stage 1
 11:44
11:45 bacek joined 12:13 nopaste joined 12:29 gaz joined
Tene purl: msg chromatic Look at the pir for a CATCH or CONTROL block. 12:37
purl Message for chromatic stored.
12:49 ruoso joined
ttbot Parrot trunk/ r42926 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/167289.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 13:10
dalek rrot: r42926 | mikehh++ | trunk/src/runcore/profiling.c:
fix src/runcore/profiling.c so it builds with g++ - namespace -> pnamespace
 13:11
Patterner r42926 still fails at src/runcore/profiling.c:59 13:12
13:15 JimmyZ joined
mikehh Patterner: what platform? 13:15
Patterner amd64
mikehh I just built on Ubuntu 9.10 amd64 (g++ with --optimize) 13:16
Patterner 4.4.2 13:17
Patterner points to ttbot "I'm not alone :)"
mikehh I am on 4.4.1 13:20
13:24 payload joined
mikehh builds for me with both gcc (with --optimize) and g++ (with --optimize) 13:27
Patterner that is good for you... 13:29
13:33 plobsing_ joined 13:34 iblechbot joined 13:35 TonyC joined 13:51 lucian joined 14:21 davidfetter joined
dalek rrot-linear-algebra: 1a0f60f | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
add proper destroy() and mark() vtables to PMCMatrix2D, like we should have had.
 14:22
rrot-linear-algebra: e942886 | Whiteknight++ | t/pmc/pmcmatrix2d.t:
add a bunch of test stubs for the various vtables in PMCMatrix2D
rrot-linear-algebra: bc1c436 | Whiteknight++ | t/pmc/pmcmatrix2d.t:
add a bunch of basic tests for the PMCMatrix2D
rrot-linear-algebra: e63fd33 | Whiteknight++ | t/pmc/pmcmatrix2d.t:
a few issues with the tests prevented them from running. Temporary fix
rrot-linear-algebra: 76d299d | Whiteknight++ | (6 files):
Merge branch 'master' of github.com:Whiteknight/parrot-linear-algebra
14:31 whiteknight joined
whiteknight good morning #parrot 14:49
14:50 naypalm joined 15:04 Andy joined
Tene HI WHITEKNIGHT 15:05
whiteknight hey Tene 15:06
15:07 bubaflub joined 15:20 lucian joined 15:25 patspam joined 15:26 patspam joined 15:41 payload joined
whiteknight is freezing cold today 15:45
davidfetter it's 39F here in oakland 15:46
which doesn't sound too bad, except that almost nowhere has central heat
15:48 Psyche^ joined
ttbot Parrot trunk/ r42927 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/167335.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 15:53
dalek rrot: r42927 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add option ignore_error to system
 15:55
trixy: 30a0d82 | Whiteknight++ | matrixy.pir:
matrixy does not implicitly check for parameter counts. Turn that error off and leave the argument checking to explicit nargin checks
 16:03
trixy: 32c43e3 | Whiteknight++ | toolbox/ (3 files):
update the TAP functions to use nargin explicit argument checking. Comments are optional now
trixy: 611ac82 | Whiteknight++ | toolbox/ok.m:
small formatting change for the output of ok()
trixy: 1f866c4 | Whiteknight++ | (3 files):
fix feval to handle nargin correctly. Move tests from dispatch.t to dedicated file
trixy: ec3a907 | Whiteknight++ | (5 files):
update all the test_script files to use TAP functions and add a new syntax test for script dispatching
trixy: c9f6620 | Whiteknight++ | toolbox/nok.m:
some weird parsing bug is preventing nok from working correctly. Roll it back till I can figure out what's up
trixy: 3ab4e81 | Whiteknight++ | t/ (14 files):
Merge branch 'master' of github.com:Whiteknight/matrixy
trixy: 7fbdeff | Whiteknight++ | (2 files):
loadlibrary.t is premature. We'll test it when we have try/catch
16:05 particle joined
Tene pmichaud: feel free to add the handlers RPA optimization to a ticket and set me as the owner. 16:09
whiteknight build is broken? 16:11
src/runcore/profiling.c:59: error: nonnull argument references non-pointer operand (argument 1, operand 2) 16:12
moritz ttbot and Patterner (iirc) complained about that already
whiteknight ah, okay. I'll shut up then :)
dalek TT #1361 created by doughera++: src/runcore/profiling.c: Can't use attribute nonnull on a non-pointer ... 16:14
pmichaud Tene: I was thinking of doing that myself, but if you want to do it that'd be great. It should be pretty easy. 16:16
Patterner I didn't complain, I just confirmed... 16:17
16:18 darbelo joined
Tene pmichaud: I can't do it immediately, but I should have some parrot time tonight. 16:19
pmichaud Tene: okay. I'll go ahead and draft the ticket, and then whoever gets to it first can do it :)
actually, it doesn't look quite so simple. Apparently more than just handlers go into that RPA (see Parrot_cx_delete_handler_local) 16:25
(in src/scheduler.c)
Tene ah, also events 16:26
pmichaud okay, that means I definitely won't be doing that one, then :) 16:27
(but you're welcome to do it :)
but I had already done some preliminary timings with the optimizations chromatic++ suggested, and discovered that push_eh is a little on the expensive side as well. 16:28
(relative to other things in the fib benchmark) 16:29
Tene are PMCs saved via :immediate actually constant, or could we make constant EHs, and then just set_addr them before using them?
pmichaud I'm going to use the caching approach I described. I need it for more than just EHs 16:30
dalek TT #1362 created by wagnerf++: parrot does not build if library glfw is installed
pmichaud basically, something like <foo bar baz bat xyz abc> really ought to be cached instead of dynamically creating a List on each use
Tene Yes.
pmichaud also, cache on first use means we don't end up with EH pmcs for subs that are never called. 16:31
Tene Also good.
pmichaud but to answer your question -- I don't think the PMCs created via :immediate are truly constant -- they can still be modified. But I'm not certain of that. 16:32
dalek cnum-dynpmcs: r191 | darbelo++ | trunk/ (2 files):
Rename aux/ to tools/. Apparently windows dislikes directories named 'aux'.
 16:33
cnum-dynpmcs: r192 | darbelo++ | trunk/t/ (17 files):
Adjust paths in test after moving files.
 16:43
cnum-dynpmcs: r193 | darbelo++ | trunk/ (35 files):
Add svn props to files. I've never actually cared about this stuff, but some

Thanks to fperrad++ for pointing it out.		 16:52
fperrad ping darbelo 17:04
purl I can't find darbelo in the DNS. 17:05
whiteknight cotto: ping 17:12
darbelo fperrad: pong 17:13
17:13 guest1234 joined
fperrad darbelo, decnum tests fails, they contains load_bytecode 'aux/decTest/.../procs.pbc' 17:14
instead of load_bytecode 'tools/.../procs.pir'
darbelo Ouch. Missed that. I'll fix it in a bit.
guest1234 Just looking at the parrot languages page: parrot.org/languages . Would be great to have a little graphic "progress bar" associated with each language to give prospective users/developers a (very) rough idea of how far along the various implementations are.
Though, guess that would require emailing each implementor separately asking them, "could you please estimate about how far along your implementation is, percentage-wise, so we can put that up on our languages page?". Would actually be pretty simple to script that and have it go out every 3 months or so... 17:16
whiteknight guest1234: yeah, it would be a huge maintainability problem
and then difficult projects like Rakudo specifically refuse to give progress estimates 17:17
guest1234 Hm. Maybe not, if it could be automated. Have all replies sent to an email account set up for just that purpose.
@whiteknight: just a rough percentage?
whiteknight I can give a rough percentage about the projects I'm involved in 17:18
good luck with the rest
guest1234 Hm. Might make a neat project to set up over the coming xmas break...
whiteknight power to you 17:19
I'd be very happy to see the project statuses updated
dalek parrot: cac4d2b | (David Fetter)++ | HOWTO:
Changed < to the more helpful and PostgreSQL-ish -f, which will tell
 17:20
guest1234 I guess I could go through project-by-project and find contact emails.
17:20 eiro_ joined
guest1234 Set up a gmail account. 17:20
Hm.
@whiteknight: well, if a project refused to give at least an approx percentage, then they'd just show up on the plot as "no response" I suppose. 17:23
whiteknight yeah 17:24
guest1234 @whiteknight: ok, well, it sounds doable. Glad I stopped by anyway. Thanks. :)
whiteknight no problem. Good luck 17:25
17:25 guest1234 left
whiteknight anybody in here knowledgable about pmc2c? 17:26
nevermind, I think I have my issues sorted out 17:34
dalek rrot-linear-algebra: 0a18153 | Whiteknight++ | t/pmc/complexmatrix2d.t:
add tests for ComplexMatrix2D
 17:37
17:42 theory joined 17:43 davidfetter joined 17:44 Zak joined 17:58 simcop2387_ joined, payload joined 18:01 payload joined
whiteknight pmichaud: ping 18:03
dalek cnum-dynpmcs: r194 | darbelo++ | trunk/t (16 files):
Adjust more paths after more file moves.
 18:06
18:11 payload joined
pmichaud whiteknight: pong 18:32
whiteknight pmichaud: In PGE, is there any way to specify the namespace where the ops are defined? 18:33
cotto_w0rk whiteknight, pong
whiteknight at the moment, "infix:+" is in ".namespace []", but I would like it to be somewhere else (for instance)
cotto_w0rk: False alarm. It was a pmc2c question but I have it resolved 18:34
pmichaud whiteknight: your question doesn't sound like a pge question.
pge only does the parsing, it doesn't handle code generation
cotto_w0rk whiteknight, good to know
whiteknight okay, so... PCT?
in any case, do you know of a way?
pmichaud I'm a bit confused as to the context. 18:35
even PCT doesn't generate infix:+ or specify a namespace.
whiteknight no, it doesn't generate it. I have the functions. hold on.
github.com/Whiteknight/matrixy/blob...rators.pir 18:36
I want the functions in that file to be in a different namespace, not ".namespace []"
is that doable?
pmichaud sure
the question is, what's calling them?
whiteknight I don't know, normal code?
pmichaud looking 18:37
whiteknight PCT generates the calling code when I type "x + y"
pmichaud actually, it's actions.pm that generates it
src/parser/actions.pm:795 18:38
whiteknight ok, so how do I specify a namespace there?
pmichaud after parsing a + sign, it generates a PAST::Op node that has the name/pasttype/pirop/lvalue/etc that were defined in the operators 18:39
you want it to look in a namespace for all operators?
18:40 cognominal joined
whiteknight I want it to be in the ["Matrixy";"builtins"] namespace 18:40
pmichaud what about the operators that are currently defined as :pirop ?
should those remain as pir ops?
whiteknight none, I dont think
I don't think I'm going to want any pirops, ultimately 18:41
so safe to ignore them
pmichaud how about pasttype() ones? 18:42
like and/or ?
whiteknight I do have two of those, but they aren't important for now 18:43
I can (and should) reimplement those
the whole operators portion of my grammar is a mess and I need to hit it with a hammer 18:44
pmichaud (or use nqp-rx :-) 18:45
whiteknight I do want to do that too. How much effort will that take?
(lower priority, but still on the TODO list)
pmichaud a bit, but not too much
whiteknight oh, I found a NQP-RX bug this morniing that I need to report 18:46
along the lines of Q:PIR { $S0 = "{}" }
(actually, I don't know if it's a bug or if I'm just being stupid) 18:47
dukeleto good moroning
nopaste "pmichaud" at 66.25.4.52 pasted "handling ops from other namespaces, for whiteknight++" (13 lines) at nopaste.snit.ch/18992 18:48
whiteknight hello dukeleto
pmichaud I'm not sure that's an nqp bug.
It can't parse PIR, so it doesn't know that the } in the quotes isn't closing the block.
moritz do multiple braces work?
pmichaud try Q:PIR {{ $S0 = "{}" }} 18:49
moritz Q:PIR {{ $S0 = "{}" }}?
whiteknight I can try that later, I'm not even on the right machine for it
pmichaud++, pmichaud++
pmichaud I also think that any bracketing character now works, so that Q:PIR « $S0 = "{)" » is a possibility.
dukeleto whiteknight: good localtime() 18:51
so are classvtables actually our priority? 18:57
18:57 joeri joined
dukeleto i don't see anyone talking about or working on them. and I don't have any clue how to help with them, even after reading the wiki page 18:57
i FAIL us for our dev priority this week
bubaflub who should i hassle to see if parrot HQ received my CLA? 19:00
cotto_w0rk bubaflub, I know particle lives close to PaFo's office.
particle aye, i'll check today or tomorrow. 19:01
when was it sent, bubaflub?
bubaflub last Tuesday 19:02
19:03 bacek joined
whiteknight urg, I can't even test since parrot won't build and I can't install it! 19:03
particle: I snail mailed my CLA too. I would like to know if you got it 19:04
at your earliest convenience :)
cotto_w0rk ditto, but there's no rush
dukeleto whiteknight: make corevm ?
whiteknight cotto_w0rk: are you aware of the failure in src/runcore/profiling.c?
cotto_w0rk whiteknight, yes. The fix is pretty easy. Just change ARGIN to ARGIN_NULLOK in that file on line 419 and rerun headerizer. 19:05
gcc on my home laptop didn't care about that. 19:06
whiteknight trying now..
cotto_w0rk It's unfortunate that headerizer unnecessarily touches files without actually changing their contents, since that forces a bunch of unnecessary rebuilding. 19:07
whiteknight fixed it
cotto_w0rk happy
whiteknight it's unfortunate that headerizer *
you need to insert the wildcard for completeness 19:08
cotto_w0rk It's nice to avoid changing function definitions in several places, but it's not without its warts.
like basically everything in parrot
19:11 iblechbot joined 19:22 chromatic joined
dukeleto chromatic: good (cold) morning 19:24
chromatic I agree... windy here in Hillsboro, windy up in the West Hills the other day. Brr. 19:26
cotto_w0rk It's a good day to make ice cubes. 19:31
whiteknight pmichaud: ping 19:43
pmichaud whiteknight: pong 19:50
whiteknight pmichaud: nevermind, I just solved my own problem
needed to change :namespace("Matrixy::builtins") to :namespace("Matrixy", "builtins") 19:51
fperrad darbelo, "plumage install decnum-dynpmcs" works successfully on linux & Windows 19:55
darbelo fperrad++
fperrad: That reminds me. If you have a google id I can give you a commit bit for decnum-dynpmcs. 19:56
20:06 athomason joined 20:16 ascent joined
ttbot Parrot trunk/ r42928 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/167515.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 20:30
dukeleto cotto_w0rk: looks like you might have b0rked src/runcore/profiling.c tt.ro.vutbr.cz/file/cmdout/167515.txt 20:32
dukeleto gets ready to give another gold watch
cotto_w0rk dukeleto, yes. I posted the fix for whiteknight earlier today and will commit it when I get home if nobody beats me to it. 20:33
darbelo What was the fix?
cotto_w0rk It was apparently an incorrect function argument annotation. 20:34
dalek rrot: r42928 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add an option smolder_extra_properties
cotto_w0rk darbelo, irclog.perlgeek.de/parrot/2009-12-07#i_1810197
darbelo Ah, I see it now. 20:37
I thought he had fixed that already.
whiteknight I fixed it locally but didn't commit 20:38
committed
cotto_w0rk thanks
cotto_w0rk kicks dalek 20:47
darbelo He dead? 20:48
darbelo pokes the bot with a stick.
cotto_w0rk He's dead, Jim. 20:51
purl you really think you are the first one to think of that, don't you.
dalek rrot: r42929 | whiteknight++ | trunk (2 files):
fix for cotto++
cotto_w0rk not even close
whiteknight ...no? 20:52
WORKSFORME
cotto_w0rk whiteknight, I was referring to purl
the commit is fine
whiteknight oh, okay
dalek rrot-linear-algebra: c2324a4 | Whiteknight++ | (5 files):
lots of cleanups and rename attributes
 20:59
rrot-linear-algebra: bb447b4 | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
another small fix for PMCMatrix2D
rrot-linear-algebra: bfe860c | Whiteknight++ | t/pmc/complexmatrix2d.t:
Merge branch 'master' of github.com:Whiteknight/parrot-linear-algebra
trixy: d285f87 | Whiteknight++ | src/ (2 files):
operators are now in the _Matrixy::builtins namespace. In preparation for unification with the builtin functions
 21:00
trixy: 4063a56 | Whiteknight++ | (4 files):
start reworking indexing to be more sane, row-major
dukeleto really needs to play with matrixy 21:01
whiteknight i just broke the hell out of it, but it's really coming along nicely otherwise
I'm working on variadic input arguments now, which will open up a large array of new possibilities 21:03
dukeleto whiteknight: cool! i am trying to batton down the hatches on Tapir, so I can drop it into matrixy and a few other projects
whiteknight I would love that 21:04
anyway, I have to disappear for now. Talk to you later
21:10 davidfetter joined
dalek nxed: r248 | julian.notfound++ | trunk/t/ (2 files):
harness: check .t extension only in recursive search
 21:10
dukeleto davidfetter: hola 21:14
purl salut, dukeleto.
davidfetter hai dukeleto
dukeleto davidfetter: i hope to see dcolish tomorrow, perhaps we will have some time to hack on PL/Parrot 21:15
davidfetter shweet!
dukeleto davidfetter: and there will be other postgres peeps at calagator.org/events/1250457765 21:16
davidfetter wish i could make it
dcolish dukeleto: oh yes, you shall see me 21:17
I am emerging for one night before finishing finals
cotto_w0rk davidfetter, are you near portland too?
davidfetter about an hour and a half away
...by jet
cotto_w0rk which direction? 21:18
purl i heard which direction was rampant, anyway?
GeJ Good morning everyone 21:23
dukeleto dcolish: sweet! 21:25
dcolish i'm bringing cupcakes too
davidfetter pretty much north 21:26
dukeleto, any chance you'll be able to get in on tomorrow's SFPUG meeting?
we're doing video webcast :)
dukeleto davidfetter: interesting. info/link/time? 21:27
davidfetter postgresql.meetup.com/1/calendar/11928447/
lemme update with the video info...
media.postgresql.org/sfpug/streaming/ 21:30
dukeleto davidfetter: sounds cool, but will be at the winter coders social. the vcast element is very interesting though. perhaps PDX.pm should do something like that 21:34
davidfetter dukeleto, we got lucky. we have an actual professional film guy who brings his gear 21:35
cotto_w0rk davidfetter, make him come to the next yapc. 21:38
davidfetter heh
he's a bit of a python guy
cotto_w0rk Tell him it's "Yet Another Python Conference". 21:39
moritz lol
dukeleto LULZ 21:40
Perl 6 : The Next Version of Python ::ducks::
cotto_w0rk Just when you thought Python 3.x was a disruptive change. 21:41
davidfetter heh 21:42
dalek nxed: r249 | julian.notfound++ | trunk/winxedst1.winxed:
operator && in stage 1
 21:49
nxed: r250 | julian.notfound++ | trunk/Makefile:
more tests for stage 1
chromatic Perl 6: Python with features. 21:50
Tene chromatic: but what about batteries? do we have batteries? 21:56
chromatic First we need salt. 21:57
dalek rrot: r42930 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] recursive glob
22:08 payload joined
cotto_w0rk quick sanity check: Is it possible for a pir sub to be split across multiple files? 22:15
chromatic no
cotto_w0rk sanity prevails, for now
chromatic ... unless you play .include games. 22:17
cotto_w0rk The profiling runcore is definitely doing more work than it needs to. 22:20
It'll be nice to have something to fix when I get home.
It's calculating preop_line and preop_filename for each op but only using them when there's a context switch. 22:21
cotto_w0rk gets back to w0rk 22:22
chromatic Hm, moritz's IRC logger's search seems to have stuck. 22:49
moritz I've been wanting to redo it with a proper search index
but it's low on my priority list 22:50
cotto_w0rk moritz, which bot does your logging?
ooc 22:51
moritz
23:06 kid51 joined
dalek rrot: r42931 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] fix smolder with extra properties
 23:19
TT #1361 closed by darbelo++: src/runcore/profiling.c: Can't use attribute nonnull on a non-pointer ... 23:24
23:33 Whiteknight joined 23:38 wayland76 joined
wayland76 Hi all 23:38
Can I get some feedback on trac.parrot.org/parrot/ticket/873
I've attached a patch, but nothing has happened in 2 months. 23:39
Do I just ask here, or do I need to do something else?
chromatic Seems reasonable to me. 23:42
wayland76 Yay! :) 23:43
23:44 plobsing_ joined
Whiteknight agreed. Looks fine to me 23:45
chromatic I don't know much about RPM though.
wayland76 So do I apply to a particular person to get this patch applied to the tree?
Ah, well, I know about RPM
In fact, I know more about RPM than Parrot :) 23:46
Whiteknight you don't apply to anybody in particular
wayland76 I guess what I really mean is that, in the past, when I've wanted to make changes, people have said "That looks good, but only Allison can make the decision on that". Is that the case with this patch? 23:49
kid51 No, that's not the case here. 23:51
We just need someone who know about as much about RPMs as you do :-) 23:52
wayland76 Joy! :)
kid51 That person can vet the patch ... then any committer can commit it.
kid51 doesn't know squat about RPMs :-(
wayland76 Ah
cotto_w0rk neither 23:53
wayland76 Well, let me put it this way; each of the directories mentioned contains a single file called a "spec file". Without this file, an RPM cannot be built. So basically, if I want an RPM, I have to go to SVN instead of using the distribution. 23:54
chromatic I can see the drawback. 23:55
wayland76 ?
chromatic I mean, I see the value of your patch. 23:56
wayland76 Ah, ok :)
Of course, I've no objection to including other ports directories in the patch, but no-one's asked me for them :)
Basically, then, either Allison or Gerd has to review it, right? :) 23:57
chromatic Either of them would be good. 23:59
wayland76 I'll post on the mailing list then

Powered by Cro and the Raku® Programming Language.

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

Thank you!