Camelia, the Perl 6 bug

IRC log for #parrot, 2009-12-07

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:06 Khisanth joined #parrot
00:08 cotto rather, it complains that things that are there aren't
00:08 cotto sadly not annoying enough to be worth patching, though
00:32 mikehh joined #parrot
00:49 jhelwig joined #parrot
00:51 * japhb chuffs in frustration at the inadequacy of email as a medium of communication
00:54 dukeleto japhb: yeah, it sucks
00:55 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:56 japhb In person, I'm  not exactly known for idiocy ... but I have yet to make that stick in text.
00:58 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 abqar joined #parrot
01:02 mj41 joined #parrot
01:15 Coke ETOOMUCHPOLICY
01:17 colomon__ joined #parrot
01:29 dalek parrot-linear-algebra: 9437eab | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
01:29 dalek parrot-linear-algebra: support get_pmc_keyed_int
01:29 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/9437eab6f08ac372aa7c63847e2c4d80f14b945f
01:29 dalek parrot-linear-algebra: 3b4cd5a | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
01:29 dalek parrot-linear-algebra: add some sanity tests for indices
01:29 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/3b4cd5af13bbeeea8080ab9e1c2af9e14086341d
01:29 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?"
01:30 Coke dukeleto: very good.
01:30 Coke also: we're already too slow. =-)
01:32 Coke (so thank you for running benchmarks)
01:33 * Coke realizes the irony of trying humor over text after recent complaints about text-based communications.
01:38 colomon_ joined #parrot
01:46 Whiteknight how do we turn off argument counting error checking
01:46 Whiteknight ?
01:48 dukeleto Whiteknight: never even heard of it before
01:48 Whiteknight there is a way, I just don't know how
01:51 bacek_at_work Whiteknight, errorsoff .PARROT_ERRORS_PARAM_COUNT_FLAG
01:51 bacek_at_work you have to include errors.pasm
01:51 bacek_at_work (for constant definitions)
01:54 Whiteknight thanks bacek++
02:09 kid51 joined #parrot
02:21 kid51 If there's any one who can comment on http://trac.parrot.org/par​rot/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?
02:21 dukeleto kid51: i think it may be broke and i may be partly to blame, is that good?
02:22 dukeleto the test checks the value of Config['gmp'] or somesuch
02:22 Coke that seems reasonable.
02:23 kid51 If you could post in the ticket itself, that would be great.
02:34 dukeleto kid51: which platform does it happen to you on?
02:35 dukeleto kid51: i put my 2 cents in
02:38 kid51 dukeleto:  As reported in ticket, it happens to me on Linux and Darwin
02:39 lucian joined #parrot
02:39 * kid51 must sleep
02:39 purl $kid51->sleep(8 * 3600);
02:47 dalek plparrot: 05d3f14 | (David Fetter)++ | HOWTO:
02:47 dalek plparrot: The changes in src/handler/Makefile mean PGXS is the default, so no
02:47 dalek plparrot: need to specify it when invoking 'make'.
02:47 dalek plparrot: review: http://github.com/leto/plparrot/commit/0​5d3f14b9a8c08bf3c87925a250bc81eb32f8dca
02:52 dukeleto ooh, i like the bxors() opcode
02:53 dukeleto k:q
02:53 dukeleto darn, this is not vim
02:53 JimmyZ joined #parrot
02:55 bacek joined #parrot
02:59 Coke do we really need another LICENSE in the ops files?
02:59 Coke or is that cargo culted from a perl5 cargo cul?
02:59 Coke *t
03:01 dukeleto how do i count set bits in PIR?
03:01 dukeleto Coke: what talketh you about?
03:24 dukeleto meh: The opcode 'length_i_p' (length<2>) was not found.
03:29 dukeleto do we really not have min(), max() opcodes for ints?
03:35 * Coke points at LICENSE at the end of the file containing bxors.
03:35 Coke dukeleto: what does length of a Hash mean?
03:35 dukeleto Coke: length of a PMC. like a String
03:36 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
03:36 Coke yes, but $I0 = length $P0 for a Hash does nt. =-)
03:36 dukeleto Coke: length of a Hash can be # of keys
03:37 Coke ok. length of a CallSig? Coroutine?
03:37 Coke my point being that if you want string length, you can be explicit about it.
03:37 dukeleto Coke: does an opcode have to be valid for every permutation of input values? I think not.
03:37 Coke dukeleto: ... that borks HLL compatibility.
03:38 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.
03:38 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"
03:38 Coke dukeleto: so what should it do? throw an exception?
03:38 dukeleto plobsing_: elements, you say?
03:38 dukeleto Coke: sure. length() of FooBaz not implemented
03:39 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)
03:39 Coke one more opcode is not a lot more code.
03:39 Coke s/EVERY/most every/ , anyway.
03:43 Coke *sigh*. nevermind. I can, of course, just use the string register version myself. I'll let your code explode, though. =-)
03:44 Coke I do stand by my assertion that an extra opcode to cast is not onerous, however.
03:44 Coke on a tangent, I hate IE6. hate it.
03:51 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.
03:51 pmichaud good evening, #parrot
03:51 JimmyZ good evening, pmichaud
03:58 naypalm joined #parrot
03:59 plobsing_ hey, if anyone cares to comment on TT #1359, I'd appreciate the input.
04:03 Coke wtf. I go to trac.parrot.org; I type in '#' to the search bar, it hangs.
04:03 Coke (my /browser/)
04:08 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 Essobi joined #parrot
04:08 plobsing_ looking in eval.pmc ...
04:09 plobsing_ right now, yes. I don't think it should though
04:09 plobsing_ eventually
04:09 purl eventually we'll all be dead
04:11 plobsing_ purl, forget eventually
04:11 purl plobsing_: I forgot eventually
04:12 plobsing_ IMHO, thawing shouldn't execute arbitrary code. it should give you the option to examine first.
04:13 plobsing_ and thats how I thought it worked now. but after a little poking, it turns out thats not quite what happens.
04:15 pmichaud if thawing causes subs to be loaded into namespaces, I think it should also honor the :load flag
04:15 pmichaud at least, that's what load_bytecode does
04:16 pmichaud I'd be okay if there's a method on Eval PMCs that says "process all :load subs" though.
04:16 pmichaud 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)
04:19 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:20 plobsing_ I'll try to put together a patch this week and see how it goes.
04:21 pmichaud +1
04:21 purl 1
04:39 pmichaud dukeleto: ping
04:47 dalek plparrot: 786c8e4 | dukeleto++ | HOWTO:
04:47 dalek plparrot: Improve HOWTO
04:47 dalek plparrot: review: http://github.com/leto/plparrot/commit/7​86c8e4a1a98c096e7936d1e891a1663a3a7a323
04:53 dalek plparrot: e9c2eae | (Joshua Tolley)++ | CREDITS:
04:53 dalek plparrot: Lay claim to a piecs of the world domination pie
04:53 dalek plparrot: review: http://github.com/leto/plparrot/commit/e​9c2eae8ee4be63a0baaf021c88b2853ec7d1300
04:54 dukeleto pmichaud: pong
04:54 pmichaud dukeleto: was just wondering where the source was for the array_access benchmark... but just found it.
04:54 * dukeleto jut wrote a small string benchmark for parrot. let's see how the benchmark sharks like it
04:55 dukeleto pmichaud: :)
04:56 pmichaud for the http://gist.github.com/250599 results, did the benchmark only get run once?
04:57 dukeleto pmichaud: hmmmm
04:57 pmichaud if so, the differences look like they might be timer noise
04:57 pmichaud if array access did get significantly slower between 1.8.0 and HEAD, though, that's significant.
04:58 dukeleto pmichaud: i will do that benchmark again. i just found a bug in euler_bench. arg!
05:00 dukeleto pmichaud: running array_access.pir again, results shortly
05:00 dukeleto pmichaud: i run --count=1 first to see if stuff segfaults/parses. i must have gist'ed the wrong output
05:03 pmichaud afk, sleep
05:03 dukeleto pmichaud: night
05:04 dukeleto pmichaud++ for noticing --count=1
05:15 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
05:17 dukeleto what I wouldn't give for ||= in PIR
05:18 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?
05:19 cotto nm.  that's only for keyed access
05:19 cotto but yes, they're in src/ops/experimental.ops
05:19 dukeleto cotto: close, but not exactly what i want
05:20 cotto no cigar for me
05:20 cotto how much would it save you?
05:23 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
05:23 dukeleto cotto: in my current situation, i am pulling out command line args, and if then are not defined, set them to a default
05:23 cotto but that's useful in a lot of places
05:24 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:36 DrForr_ joined #parrot
05:54 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:56 dukeleto cotto: no
05:57 dukeleto cotto: that stuff usually needs a configure-time check
05:57 cotto goodie
05:57 dukeleto cotto: what are you trying to do?
05:58 cotto make a static array where I can store both intvals and pointers
05:58 cotto s/static//
06:02 chromatic joined #parrot
06:09 dukeleto chromatic: hola
06:09 dukeleto incoming
06:09 purl duck!
06:10 chromatic Those array_access.pir numbers confuse me.  1.8 looks like it's in there twice, with different numbers.
06:12 dukeleto chromatic: that is 0.8.0
06:14 chromatic Oh.  Hm.  Maybe I shouldn't be reading now.
06:14 dalek parrot: r42921 | dukeleto++ | trunk (2 files):
06:14 dalek parrot: [examples] Add a benchmark geared towards strings which computes the Hamming distance between two strings
06:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42921/
06:14 dukeleto chromatic: :) you gave me a scare for a moment. i have been staring at the output of euler_bench too long...
06:15 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.
06:17 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
06:18 * dukeleto is running stress1.pasm now
06:18 dukeleto my --count=1 run made trunk look pretty good
06:20 theory joined #parrot
06:22 dan joined #parrot
06:43 dukeleto chromatic: http://gist.github.com/250669 stress1.pasm
06:48 chromatic GC's not substantially better in trunk.
06:54 dukeleto chromatic: wishful thinking
06:56 chromatic I'd like to think some of the tuning has had an effect.
06:58 JimmyZ hello chromatic
06:58 chromatic Hi JimmyZ.  I saw that kid51 tested some of your patches.
06:58 JimmyZ chromatic: yes
06:59 chromatic What's left to review, everything?
07:00 JimmyZ chromatic: he wants others could review it again.
07:01 chromatic Okay, I can do that.
07:01 cotto I'll take one or two too.
07:02 cotto I'll do 1346.
07:02 dukeleto should i report benchmarks that look OK or do y'all only want the bad news?
07:02 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()?
07:03 cotto nm.  My parrot's goofy from profiling work.
07:03 cotto nm the nm.  That doesn't actually affect anything.
07:04 JimmyZ chromatic: Did I describe correctly?
07:05 chromatic I think it's autovivifying an attribute which may not yet exist.
07:05 chromatic I haven't read the code today, but I think that's the idea.
07:07 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.
07:07 JimmyZ It's a bit different from other PMCs.
07:08 uniejo joined #parrot
07:08 JimmyZ cotto: yep
07:09 JimmyZ cotto: sometimes re-ordering codes is useful, I think.
07:10 cotto the args.c changes (TT #1346) are committed.
07:13 cotto JimmyZ, TT #1280 needs your comments.
07:16 JimmyZ cotto: I think old var doesn't need.
07:16 JimmyZ cotto: It's unused tmp var. :)
07:18 JimmyZ cotto: maybe I am wrong? But I couldn't find it's useful.
07:18 cotto examining TT #1348
07:19 dalek parrot: r42922 | cotto++ | trunk/src/call/args.c:
07:19 dalek parrot: [PCC] reorder some code to avoid unnecessary execution, patch courtesy of JimmyZ++
07:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42922/
07:22 dalek TT #1346 closed by cotto++: [patch]Removed unused macro in pobj.h, reordered codes in args.c
07:24 JimmyZ cotto: already added comment to #1280
07:28 cotto TT #1354 closed
07:28 cotto I'll need sleeps soon.
07:30 JimmyZ cotto: good night.
07:31 cotto night, JimmyZ
07:31 chromatic I almost want standard deviation in those benchmarks.
07:32 dukeleto chromatic: i have already been wanting that for 2 days. i am close to implementing it in euler_bench :)
07:33 chromatic The cluster for the Hamming distance benchmark could go lots of directions post 1.2.
07:36 dalek parrot: r42923 | cotto++ | trunk/lib/Parrot/Vtable.pm:
07:36 dalek parrot: [vtable] don't emit the now-unused PARROT_VTABLE_FOO_METHNAME macros in vtable.h
07:36 dalek parrot: patch courtesy of JimmyZ++
07:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42923/
07:38 dalek TT #1354 closed by cotto++: [patch]removed unused codes from Vtable.pm
07:41 bacek joined #parrot
07:44 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:45 dukeleto chromatic: what exactly do you mean by that?
07:46 cotto (considering 64-bit)
07:46 naypalm the PMCs resize to inf don't they?
07:47 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
07:48 dukeleto chromatic: which means we need better string benchmarks
07:48 dukeleto chromatic: you want to throw some tuits at that?
07:48 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?
07:48 naypalm it is indeed!
07:49 naypalm I worked out max int with powers of two and converting..
07:49 dukeleto naypalm: ResizablePMCArrays can be resized. FixedPMCArrays cannot :)
07:49 naypalm what's the main problem with mutable? just that you have to be ready to increase the size?
07:50 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!
07:50 naypalm -size+speed
07:51 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 naypalm :|
07:52 cotto PMCs have their charms and their warts.
07:52 naypalm been reading through random scraps of code and writing little things here
07:52 naypalm just familiarizing myself :)
07:52 dukeleto naypalm: yes, PMC = Parrot Magic Cookie
07:53 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. ;)
07:53 dukeleto naypalm: the examples/ directory may be interesting to you
07:53 dukeleto chromatic: specifically a String PMC benchmark
07:53 naypalm you inject the strings straight into the bytecode, there's no need for them :P
07:53 dukeleto chromatic: our string core type seems pretty fast and stable
07:54 dukeleto chromatic: unicode conversions?
07:58 dukeleto chromatic: i am looking at this for a string benchmark: http://projecteuler.net/index.​php?section=problems&amp;id=60
07:59 chromatic How would you do that with strings?
07:59 naypalm if you're looking to bench numbers more than 5 digits then no
08:00 dukeleto chromatic: it requires a bench of concatenation and prime-checking
08:00 JimmyZ joined #parrot
08:00 naypalm yeah, also you don't have very long strings either!
08:01 dukeleto chromatic: this requires reversing lots of strings and converting back and forth between string/ints http://projecteuler.net/index.p​hp?section=problems&amp;id=125
08:02 chromatic I'd use STRINGs, not the String PMC.
08:02 chromatic String is a boxed wrapper around STRING, for the most part.
08:02 dukeleto chromatic: yeah, but we are trying to bench the String PMC
08:03 iblechbot joined #parrot
08:03 chromatic I suppose, but I don't see a lot of value in that.
08:04 chromatic It hasn't changed much in a long time.
08:05 naypalm http://codepad.org/beTC6TQr I did that to get my feet wet..
08:05 naypalm not very helpful for anything, but we'll be beating C in a few months?
08:07 dukeleto chromatic: to be sure we aren't getting horribly slow for an unknown reason, i guess
08:08 chromatic I'd feel more comfortable if there were STRING and String versions of such a benchmark.
08:10 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.
08:11 dukeleto chromatic: yes, i just got to the end of my writing-benchmarking-code rope for the day :) have at it
08:12 * dukeleto self.'sleep'()
08:18 naypalm have you got a big main step planned?
08:21 * cotto just cast a string literal to an INTVAL.
08:26 chromatic Hm, what if ExceptionHandler had an init_pmc() which took an Integer representing the single type of exception it can handle?
08:26 chromatic No more handle_types() method call for a common case.
08:27 chromatic 20.473% improvement in the fib4.pir benchmark pmichaud convinced NQP-rx to emit, with the obvious PIR change.
08:28 chromatic Of course, constant exception handlers would be nice too.
08:29 chromatic I think he mentioned something about constant PMCs.
08:39 fperrad joined #parrot
08:47 fperrad_ joined #parrot
09:33 mikehh All tests PASS (pre/post-config, smoke (#30672), fulltest) at r42923 - Ubuntu 9.10 amd64 (gcc with --optimize)
09:47 dalek tracwiki: v3 | cotto++ | CottoTasklist
09:47 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Co​ttoTasklist?version=3&amp;action=diff
09:47 dalek parrot: r42924 | chromatic++ | trunk/src/ops/pmc.ops:
09:47 dalek parrot: [ops] Modified the new PMC, STRING ops to avoid creating or checking for a
09:47 dalek parrot: PMCProxy when working with core types in the root HLL.  This speeds up the
09:47 dalek parrot: fib4.pir benchmark (generated by NQP-rx) by 3.195%, and likely several others.
09:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42924/
09:54 JimmyZ I found that many places that used SELF.foo() could be rewrite as STATICSELF.foo().
09:54 JimmyZ in PMC
10:11 bacek joined #parrot
10:13 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 cotto night
10:14 cotto I'll check the backscroll.
10:15 ttbot Parrot trunk/ r42925 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/167239.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
10:16 naypalm you can't use llvm can you?
10:18 chromatic Will review.
10:20 dalek parrot: r42925 | cotto++ | trunk (3 files):
10:20 dalek parrot: [profiling] refactor profiling runcore output to make mulitple formats possible
10:20 dalek parrot: also, report the full namespace of a sub, not just the last part
10:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42925/
10:39 bacek joined #parrot
11:19 bacek joined #parrot
11:44 dalek winxed: r247 | julian.notfound++ | trunk/ (2 files):
11:44 dalek winxed: yield in stage 1
11:44 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=247
11:45 bacek joined #parrot
12:13 nopaste joined #parrot
12:29 gaz joined #parrot
12:37 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 #parrot
13:10 ttbot Parrot trunk/ r42926 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/167289.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
13:11 dalek parrot: r42926 | mikehh++ | trunk/src/runcore/profiling.c:
13:11 dalek parrot: fix src/runcore/profiling.c so it builds with g++ - namespace -> pnamespace
13:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42926/
13:12 Patterner r42926 still fails at src/runcore/profiling.c:59
13:15 JimmyZ joined #parrot
13:15 mikehh Patterner: what platform?
13:15 Patterner amd64
13:16 mikehh I just built on Ubuntu 9.10 amd64 (g++ with --optimize)
13:17 Patterner 4.4.2
13:17 * Patterner points to ttbot "I'm not alone :)"
13:20 mikehh I am on 4.4.1
13:24 payload joined #parrot
13:27 mikehh builds for me with both gcc  (with --optimize) and g++ (with --optimize)
13:29 Patterner that is good for you...
13:33 plobsing_ joined #parrot
13:34 iblechbot joined #parrot
13:35 TonyC joined #parrot
13:51 lucian joined #parrot
14:21 davidfetter joined #parrot
14:22 dalek parrot-linear-algebra: 1a0f60f | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
14:22 dalek parrot-linear-algebra: add proper destroy() and mark() vtables to PMCMatrix2D, like we should have had.
14:22 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/1a0f60f4cb14a05b7ef77780f7d5c61020db226b
14:22 dalek parrot-linear-algebra: e942886 | Whiteknight++ | t/pmc/pmcmatrix2d.t:
14:22 dalek parrot-linear-algebra: add a bunch of test stubs for the various vtables in PMCMatrix2D
14:22 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/e9428862232c72ba915fe48c5921d37eeec4fd17
14:22 dalek parrot-linear-algebra: bc1c436 | Whiteknight++ | t/pmc/pmcmatrix2d.t:
14:22 dalek parrot-linear-algebra: add a bunch of basic tests for the PMCMatrix2D
14:22 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/bc1c43695316df55218fb9a4005f8d9033731c7b
14:22 dalek parrot-linear-algebra: e63fd33 | Whiteknight++ | t/pmc/pmcmatrix2d.t:
14:22 dalek parrot-linear-algebra: a few issues with the tests prevented them from running. Temporary fix
14:22 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/e63fd336708342000d357d77942e233405eaa6c9
14:22 dalek parrot-linear-algebra: 76d299d | Whiteknight++ |  (6 files):
14:22 dalek parrot-linear-algebra: Merge branch 'master' of github.com:Whiteknight/parrot-linear-algebra
14:22 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/76d299d476e2711696436b1d764d702c22ec7899
14:31 whiteknight joined #parrot
14:49 whiteknight good morning #parrot
14:50 naypalm joined #parrot
15:04 Andy joined #parrot
15:05 Tene HI WHITEKNIGHT
15:06 whiteknight hey Tene
15:07 bubaflub joined #parrot
15:20 lucian joined #parrot
15:25 patspam joined #parrot
15:26 patspam joined #parrot
15:41 payload joined #parrot
15:45 * whiteknight is freezing cold today
15:46 davidfetter it's 39F here in oakland
15:46 davidfetter which doesn't sound too bad, except that almost nowhere has central heat
15:48 Psyche^ joined #parrot
15:53 ttbot Parrot trunk/ r42927 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/167335.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
15:55 dalek parrot: r42927 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
15:55 dalek parrot: [distutils] add option ignore_error to system
15:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42927/
16:03 dalek matrixy: 30a0d82 | Whiteknight++ | matrixy.pir:
16:03 dalek matrixy: matrixy does not implicitly check for parameter counts. Turn that error off and leave the argument checking to explicit nargin checks
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/30a0d82cca04cfce0622776caa2add8a6bfb629e
16:03 dalek matrixy: 32c43e3 | Whiteknight++ | toolbox/ (3 files):
16:03 dalek matrixy: update the TAP functions to use nargin explicit argument checking. Comments are optional now
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/32c43e3160a6767eb3f7fa433045a1294341890f
16:03 dalek matrixy: 611ac82 | Whiteknight++ | toolbox/ok.m:
16:03 dalek matrixy: small formatting change for the output of ok()
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/611ac82c9a97f8d7a405f1feb270356c1f4437f4
16:03 dalek matrixy: 1f866c4 | Whiteknight++ |  (3 files):
16:03 dalek matrixy: fix feval to handle nargin correctly. Move tests from dispatch.t to dedicated file
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/1f866c485c4515e86ed08582da158bc09a702279
16:03 dalek matrixy: ec3a907 | Whiteknight++ |  (5 files):
16:03 dalek matrixy: update all the test_script files to use TAP functions and add a new syntax test for script dispatching
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/ec3a9075f97f72192478330f2ee3fb1efe127826
16:03 dalek matrixy: c9f6620 | Whiteknight++ | toolbox/nok.m:
16:03 dalek matrixy: some weird parsing bug is preventing nok from working correctly. Roll it back till I can figure out what's up
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/c9f6620dbc0d4f6b8fc646a5551d81b4874c37e0
16:03 dalek matrixy: 3ab4e81 | Whiteknight++ | t/ (14 files):
16:03 dalek matrixy: Merge branch 'master' of github.com:Whiteknight/matrixy
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/3ab4e81e0f390ef79278464efead01fab64ad8da
16:03 dalek matrixy: 7fbdeff | Whiteknight++ |  (2 files):
16:03 dalek matrixy: loadlibrary.t is premature. We'll test it when we have try/catch
16:03 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/7fbdeff525420673fa15642439f6834f5b87a0fe
16:05 particle joined #parrot
16:09 Tene pmichaud: feel free to add the handlers RPA optimization to a ticket and set me as the owner.
16:11 whiteknight build is broken?
16:12 whiteknight 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
16:12 whiteknight ah, okay. I'll shut up then :)
16:14 dalek TT #1361 created by doughera++: src/runcore/profiling.c:  Can't use attribute nonnull on a non-pointer ...
16:16 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:17 Patterner I didn't complain, I just confirmed...
16:18 darbelo joined #parrot
16:19 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 :)
16:25 pmichaud 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 pmichaud (in src/scheduler.c)
16:26 Tene ah, also events
16:27 pmichaud okay, that means I definitely won't be doing that one, then :)
16:27 pmichaud (but you're welcome to do it :)
16:28 pmichaud 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:29 pmichaud (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?
16:30 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
16:30 pmichaud basically, something like     <foo bar baz bat xyz abc>    really ought to be cached instead of dynamically creating a List on each use
16:30 Tene Yes.
16:31 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.
16:32 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:33 dalek decnum-dynpmcs: r191 | darbelo++ | trunk/ (2 files):
16:33 dalek decnum-dynpmcs: Rename aux/ to tools/. Apparently windows dislikes directories named 'aux'.
16:33 dalek decnum-dynpmcs: fperrad++ for pointing this out.
16:33 dalek decnum-dynpmcs: review: http://code.google.com/p/decnu​m-dynpmcs/source/detail?r=191
16:43 dalek decnum-dynpmcs: r192 | darbelo++ | trunk/t/ (17 files):
16:43 dalek decnum-dynpmcs: Adjust paths in test after moving files.
16:43 dalek decnum-dynpmcs: review: http://code.google.com/p/decnu​m-dynpmcs/source/detail?r=192
16:52 dalek decnum-dynpmcs: r193 | darbelo++ | trunk/ (35 files):
16:52 dalek decnum-dynpmcs: Add svn props to files. I've never actually cared about this stuff, but some
16:52 dalek decnum-dynpmcs: pople find it useful.
16:52 dalek decnum-dynpmcs: Thanks to fperrad++ for pointing it out.
16:52 dalek decnum-dynpmcs: review: http://code.google.com/p/decnu​m-dynpmcs/source/detail?r=193
17:04 fperrad ping darbelo
17:05 purl I can't find darbelo in the DNS.
17:12 whiteknight cotto: ping
17:13 darbelo fperrad: pong
17:13 guest1234 joined #parrot
17:14 fperrad darbelo, decnum tests fails, they contains load_bytecode 'aux/decTest/.../procs.pbc'
17:14 fperrad instead of load_bytecode 'tools/.../procs.pir'
17:14 darbelo Ouch. Missed that. I'll fix it in a bit.
17:14 guest1234 Just looking at the parrot languages page: http://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.
17:16 guest1234 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
17:17 whiteknight 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.
17:17 guest1234 @whiteknight: just a rough percentage?
17:18 whiteknight I can give a rough percentage about the projects I'm involved in
17:18 whiteknight good luck with the rest
17:18 guest1234 Hm. Might make a neat project to set up over the coming xmas break...
17:19 whiteknight power to you
17:19 whiteknight I'd be very happy to see the project statuses updated
17:20 dalek plparrot: cac4d2b | (David Fetter)++ | HOWTO:
17:20 dalek plparrot: Changed < to the more helpful and PostgreSQL-ish -f, which will tell
17:20 dalek plparrot: what line any error occurred on.
17:20 dalek plparrot: review: http://github.com/leto/plparrot/commit/c​ac4d2ba53a82c4cae2dcb149aa31238c50baf51
17:20 guest1234 I guess I could go through project-by-project and find contact emails.
17:20 eiro_ joined #parrot
17:20 guest1234 Set up a gmail account.
17:20 guest1234 Hm.
17:23 guest1234 @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:24 whiteknight yeah
17:24 guest1234 @whiteknight: ok, well, it sounds doable. Glad I stopped by anyway. Thanks. :)
17:25 whiteknight no problem. Good luck
17:25 guest1234 left #parrot
17:26 whiteknight anybody in here knowledgable about pmc2c?
17:34 whiteknight nevermind, I think I have my issues sorted out
17:37 dalek parrot-linear-algebra: 0a18153 | Whiteknight++ | t/pmc/complexmatrix2d.t:
17:37 dalek parrot-linear-algebra: add tests for ComplexMatrix2D
17:37 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/0a1815305a391e2e4993e66d83da3842cce9905b
17:42 theory joined #parrot
17:43 davidfetter joined #parrot
17:44 Zak joined #parrot
17:58 simcop2387_ joined #parrot
17:58 payload joined #parrot
18:01 payload joined #parrot
18:03 whiteknight pmichaud: ping
18:06 dalek decnum-dynpmcs: r194 | darbelo++ | trunk/t (16 files):
18:06 dalek decnum-dynpmcs: Adjust more paths after more file moves.
18:06 dalek decnum-dynpmcs: review: http://code.google.com/p/decnu​m-dynpmcs/source/detail?r=194
18:11 payload joined #parrot
18:32 pmichaud whiteknight: pong
18:33 whiteknight pmichaud: In PGE, is there any way to specify the namespace where the ops are defined?
18:33 cotto_w0rk whiteknight,  pong
18:33 whiteknight at the moment, "infix:+" is in ".namespace []", but I would like it to be somewhere else (for instance)
18:34 whiteknight 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.
18:34 pmichaud pge only does the parsing, it doesn't handle code generation
18:34 cotto_w0rk whiteknight, good to know
18:34 whiteknight okay, so... PCT?
18:34 whiteknight in any case, do you know of a way?
18:35 pmichaud I'm a bit confused as to the context.
18:35 pmichaud even PCT doesn't generate infix:+ or specify a namespace.
18:35 whiteknight no, it doesn't generate it. I have the functions. hold on.
18:36 whiteknight http://github.com/Whiteknight/matrixy/b​lob/master/src/internals/operators.pir
18:36 whiteknight I want the functions in that file to be in a different namespace, not ".namespace []"
18:36 whiteknight is that doable?
18:36 pmichaud sure
18:36 pmichaud the question is, what's calling them?
18:36 whiteknight I don't know, normal code?
18:37 pmichaud looking
18:37 whiteknight PCT generates the calling code when I type "x + y"
18:37 pmichaud actually, it's actions.pm that generates it
18:38 pmichaud src/parser/actions.pm:795
18:38 whiteknight ok, so how do I specify a namespace there?
18:39 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 pmichaud you want it to look in a namespace for all operators?
18:40 cognominal joined #parrot
18:40 whiteknight I want it to be in the ["Matrixy";"builtins"] namespace
18:40 pmichaud what about the operators that are currently defined as :pirop ?
18:40 pmichaud should those remain as pir ops?
18:40 whiteknight none, I dont think
18:41 whiteknight I don't think I'm going to want any pirops, ultimately
18:41 whiteknight so safe to ignore them
18:42 pmichaud how about pasttype() ones?
18:42 pmichaud like and/or ?
18:43 whiteknight I do have two of those, but they aren't important for now
18:43 whiteknight I can (and should) reimplement those
18:44 whiteknight the whole operators portion of my grammar is a mess and I need to hit it with a hammer
18:45 pmichaud (or use nqp-rx :-)
18:45 whiteknight I do want to do that too. How much effort will that take?
18:45 whiteknight (lower priority, but still on the TODO list)
18:45 pmichaud a bit, but not too much
18:46 whiteknight oh, I found a NQP-RX bug this morniing that I need to report
18:46 whiteknight along the lines of Q:PIR { $S0 = "{}" }
18:47 whiteknight (actually, I don't know if it's a bug or if I'm just being stupid)
18:47 dukeleto good moroning
18:48 nopaste "pmichaud" at 66.25.4.52 pasted "handling ops from other namespaces, for whiteknight++" (13 lines) at http://nopaste.snit.ch/18992
18:48 whiteknight hello dukeleto
18:48 pmichaud I'm not sure that's an nqp bug.
18:48 pmichaud It can't parse PIR, so it doesn't know that the } in the quotes isn't closing the block.
18:48 moritz do multiple braces work?
18:49 pmichaud try   Q:PIR {{ $S0 = "{}" }}
18:49 moritz Q:PIR {{ $S0 = "{}" }}?
18:49 whiteknight I can try that later, I'm not even on the right machine for it
18:49 whiteknight pmichaud++, pmichaud++
18:49 pmichaud I also think that any bracketing character now works, so that   Q:PIR « $S0 = "{)" »   is a possibility.
18:51 dukeleto whiteknight: good localtime()
18:57 dukeleto so are classvtables actually our priority?
18:57 joeri joined #parrot
18:57 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 dukeleto i FAIL us for our dev priority this week
19:00 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.
19:01 particle aye, i'll check today or tomorrow.
19:01 particle when was it sent, bubaflub?
19:02 bubaflub last Tuesday
19:03 bacek joined #parrot
19:03 whiteknight urg, I can't even test since parrot won't build and I can't install it!
19:04 whiteknight particle: I snail mailed my CLA too. I would like to know if you got it
19:04 whiteknight at your earliest convenience :)
19:04 cotto_w0rk ditto, but there's no rush
19:04 dukeleto whiteknight: make corevm ?
19:04 whiteknight cotto_w0rk: are you aware of the failure in src/runcore/profiling.c?
19:05 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:06 cotto_w0rk gcc on my home laptop didn't care about that.
19:06 whiteknight trying now..
19:07 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
19:07 cotto_w0rk happy
19:07 whiteknight it's unfortunate that headerizer *
19:08 whiteknight 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.
19:08 cotto_w0rk like basically everything in parrot
19:11 iblechbot joined #parrot
19:22 chromatic joined #parrot
19:24 dukeleto chromatic: good (cold) morning
19:26 chromatic I agree... windy here in Hillsboro, windy up in the West Hills the other day.  Brr.
19:31 cotto_w0rk It's a good day to make ice cubes.
19:43 whiteknight pmichaud: ping
19:50 pmichaud whiteknight: pong
19:50 whiteknight pmichaud: nevermind, I just solved my own problem
19:51 whiteknight needed to change :namespace("Matrixy::builtins") to :namespace("Matrixy", "builtins")
19:55 fperrad darbelo, "plumage install decnum-dynpmcs" works successfully on linux & Windows
19:55 darbelo fperrad++
19:56 darbelo fperrad: That reminds me. If you have a google id I can give you a commit bit for decnum-dynpmcs.
20:06 athomason joined #parrot
20:16 ascent joined #parrot
20:30 ttbot Parrot trunk/ r42928 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/167515.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
20:32 dukeleto cotto_w0rk: looks like you might have b0rked src/runcore/profiling.c http://tt.ro.vutbr.cz/file/cmdout/167515.txt
20:32 * dukeleto gets ready to give another gold watch
20:33 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?
20:34 cotto_w0rk It was apparently an incorrect function argument annotation.
20:34 dalek parrot: r42928 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
20:34 dalek parrot: [distutils] add an option smolder_extra_properties
20:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42928/
20:35 cotto_w0rk darbelo, http://irclog.perlgeek.de/p​arrot/2009-12-07#i_1810197
20:37 darbelo Ah, I see it now.
20:37 darbelo I thought he had fixed that already.
20:38 whiteknight I fixed it locally but didn't commit
20:38 whiteknight committed
20:38 cotto_w0rk thanks
20:47 * cotto_w0rk kicks dalek
20:48 darbelo He dead?
20:48 * darbelo pokes the bot with a stick.
20:51 cotto_w0rk He's dead, Jim.
20:51 purl you really think you are the first one to think of that, don't you.
20:51 dalek parrot: r42929 | whiteknight++ | trunk (2 files):
20:51 dalek parrot: fix for cotto++
20:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42929/
20:51 cotto_w0rk not even close
20:52 whiteknight ...no?
20:52 whiteknight WORKSFORME
20:52 cotto_w0rk whiteknight, I was referring to purl
20:52 cotto_w0rk the commit is fine
20:52 whiteknight oh, okay
20:59 dalek parrot-linear-algebra: c2324a4 | Whiteknight++ |  (5 files):
20:59 dalek parrot-linear-algebra: lots of cleanups and rename attributes
20:59 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/c2324a4d8ed23dbff99711eaccb43f5c8cc703f4
20:59 dalek parrot-linear-algebra: bb447b4 | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
20:59 dalek parrot-linear-algebra: another small fix for PMCMatrix2D
20:59 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/bb447b4b4cf732c56118a14bc9783bd75c3c9165
20:59 dalek parrot-linear-algebra: bfe860c | Whiteknight++ | t/pmc/complexmatrix2d.t:
20:59 dalek parrot-linear-algebra: Merge branch 'master' of github.com:Whiteknight/parrot-linear-algebra
20:59 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/bfe860c31c80f866adc8506703d7871a45e08a9f
21:00 dalek matrixy: d285f87 | Whiteknight++ | src/ (2 files):
21:00 dalek matrixy: operators are now in the _Matrixy::builtins namespace. In preparation for unification with the builtin functions
21:00 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/d285f875c27f4102b3ecf26781edfc88d241bbf9
21:00 dalek matrixy: 4063a56 | Whiteknight++ |  (4 files):
21:00 dalek matrixy: start reworking indexing to be more sane, row-major
21:00 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/4063a561c9530a0b82878c622c0f02d8f882d414
21:01 * 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
21:03 whiteknight 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
21:04 whiteknight I would love that
21:04 whiteknight anyway, I have to disappear for now. Talk to you later
21:10 davidfetter joined #parrot
21:10 dalek winxed: r248 | julian.notfound++ | trunk/t/ (2 files):
21:10 dalek winxed: harness: check .t extension only in recursive search
21:10 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=248
21:14 dukeleto davidfetter: hola
21:14 purl salut, dukeleto.
21:14 davidfetter hai dukeleto
21:15 dukeleto davidfetter: i hope to see dcolish tomorrow, perhaps we will have some time to hack on PL/Parrot
21:15 davidfetter shweet!
21:16 dukeleto davidfetter: and there will be other postgres peeps at http://calagator.org/events/1250457765
21:16 davidfetter wish i could make it
21:17 dcolish dukeleto: oh yes, you shall see me
21:17 dcolish I am emerging for one night before finishing finals
21:17 cotto_w0rk davidfetter, are you near portland too?
21:17 davidfetter about an hour and a half away
21:17 davidfetter ...by jet
21:18 cotto_w0rk which direction?
21:18 purl i heard which direction was rampant, anyway?
21:23 GeJ Good morning everyone
21:25 dukeleto dcolish: sweet!
21:25 dcolish i'm bringing cupcakes too
21:26 davidfetter pretty much north
21:26 davidfetter dukeleto, any chance you'll be able to get in on tomorrow's SFPUG meeting?
21:26 davidfetter we're doing video webcast :)
21:27 dukeleto davidfetter: interesting. info/link/time?
21:27 davidfetter http://postgresql.meetup.com/1/calendar/11928447/
21:27 davidfetter lemme update with the video info...
21:30 davidfetter http://media.postgresql.org/sfpug/streaming/
21:34 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:35 davidfetter dukeleto, we got lucky. we have an actual professional film guy who brings his gear
21:38 cotto_w0rk davidfetter, make him come to the next yapc.
21:38 davidfetter heh
21:38 davidfetter he's a bit of a python guy
21:39 cotto_w0rk Tell him it's "Yet Another Python Conference".
21:39 moritz lol
21:40 dukeleto LULZ
21:40 dukeleto Perl 6 : The Next Version of Python ::ducks::
21:41 cotto_w0rk Just when you thought Python 3.x was a disruptive change.
21:42 davidfetter heh
21:49 dalek winxed: r249 | julian.notfound++ | trunk/winxedst1.winxed:
21:49 dalek winxed: operator && in stage 1
21:49 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=249
21:49 dalek winxed: r250 | julian.notfound++ | trunk/Makefile:
21:49 dalek winxed: more tests for stage 1
21:49 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=250
21:50 chromatic Perl 6: Python with features.
21:56 Tene chromatic: but what about batteries?  do we have batteries?
21:57 chromatic First we need salt.
21:57 dalek parrot: r42930 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
21:57 dalek parrot: [distutils] recursive glob
21:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42930/
22:08 payload joined #parrot
22:15 cotto_w0rk quick sanity check: Is it possible for a pir sub to be split across multiple files?
22:15 chromatic no
22:15 cotto_w0rk sanity prevails, for now
22:17 chromatic ... unless you play .include games.
22:20 cotto_w0rk The profiling runcore is definitely doing more work than it needs to.
22:20 cotto_w0rk It'll be nice to have something to fix when I get home.
22:21 cotto_w0rk It's calculating preop_line and preop_filename for each op but only using them when there's a context switch.
22:22 * cotto_w0rk gets back to w0rk
22:49 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
22:50 moritz but it's low on my priority list
22:50 cotto_w0rk moritz, which bot does your logging?
22:51 cotto_w0rk ooc
22:51 moritz
23:06 kid51 joined #parrot
23:19 dalek parrot: r42931 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
23:19 dalek parrot: [distutils] fix smolder with extra properties
23:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42931/
23:24 dalek TT #1361 closed by darbelo++: src/runcore/profiling.c:  Can't use attribute nonnull on a non-pointer ...
23:33 Whiteknight joined #parrot
23:38 wayland76 joined #parrot
23:38 wayland76 Hi all
23:38 wayland76 Can I get some feedback on http://trac.parrot.org/parrot/ticket/873
23:39 wayland76 I've attached a patch, but nothing has happened in 2 months.
23:39 wayland76 Do I just ask here, or do I need to do something else?
23:42 chromatic Seems reasonable to me.
23:43 wayland76 Yay! :)
23:44 plobsing_ joined #parrot
23:45 Whiteknight agreed. Looks fine to me
23:45 chromatic I don't know much about RPM though.
23:45 wayland76 So do I apply to a particular person to get this patch applied to the tree?
23:45 wayland76 Ah, well, I know about RPM
23:46 wayland76 In fact, I know more about RPM than Parrot :)
23:46 Whiteknight you don't apply to anybody in particular
23:49 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:51 kid51 No, that's not the case here.
23:52 kid51 We just need someone who know about as much about RPMs as you do :-)
23:52 wayland76 Joy! :)
23:52 kid51 That person can vet the patch ... then any committer can commit it.
23:52 * kid51 doesn't know squat about RPMs :-(
23:52 wayland76 Ah
23:53 * cotto_w0rk neither
23:54 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:55 chromatic I can see the drawback.
23:55 wayland76 ?
23:56 chromatic I mean, I see the value of your patch.
23:56 wayland76 Ah, ok :)
23:56 wayland76 Of course, I've no objection to including other ports directories in the patch, but no-one's asked me for them :)
23:57 wayland76 Basically, then, either Allison or Gerd has to review it, right? :)
23:59 chromatic Either of them would be good.
23:59 wayland76 I'll post on the mailing list then

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

Parrot | source cross referenced