Parrot 3.6.0 "Pájaros del Caribe" released | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 23 July 2011.
00:01 soh_cah_toa left 00:02 soh_cah_toa joined 00:10 theory left 00:19 bubaflub joined
bubaflub ~ 00:19
whiteknight hello bubaflub
bubaflub hello whiteknight
00:20 dmalcolm left
dalek rrot/m0-prototype: 823bed4 | cotto++ | t/m0/integration/m0_hash.m0:
make debugging output for hashing test easier to enable
 00:23
bubaflub jay: good work on getting that stuff compiled and running 00:24
00:25 kid51 is now known as kid51_at_dinner 00:26 daniel-s joined
dalek rrot/whiteknight/imcc_tag: 8229ddd | Whiteknight++ | / (3 files):
Add in some code to imcc.y (not used yet) to replace :load and :init with :tag. Fix Parrot_pf_subs_by_flag to treat :init and :load together with :tag seamlessly.
 00:31
jay ~~ hey bubaflub, thanks, whiteknight++ on that one. 00:49
00:50 soh_cah_toa left 01:02 soh_cah_toa joined 01:09 darbelo left 01:13 kid51_at_dinner is now known as kid51
kid51 bubaflub: I quoted you in my FOSSCON talk in Philadelphia on Saturday: thenceforward.net/parrot/fosscon201107/ 01:14
bubaflub kid51: wow. i'm reading it now. 01:17
dalek rrot/whiteknight/frontend_parrot2: 7c91174 | Whiteknight++ | frontend/parrot (3 files):
Prototype for a new alternate frontend. The new frontend intends to bootstrap into PIR as early as possible, using new packfile and compiler features.
 01:20
kid51 So, the command I was ignorant of was: git remote prune origin 01:32
Felipe I didn't knew it either 01:33
01:34 bubaflub left
kid51 Now, locally: 'git branch -r | wc -l' shows 67 ... which is the number of branches shows in the github drop-down 01:35
kid51 happy
Felipe :D 01:36
01:42 kid51 left 01:45 woosley joined
cotto ~~ 01:45
dalek rrot/whiteknight/frontend_parrot2: 8b85ecc | Whiteknight++ | frontend/parrot2/main.c:
A few small speculative changes and some TODO notes
 01:49
01:57 whiteknight left 02:06 soh_cah_toa left
cotto parrot 2: This time it's personal. 02:34
02:37 d4l3k_ joined 02:39 tempire_ joined 02:40 pmichaud_ joined, pjcj_ joined, sorear_ joined, ascent_ joined, PerlPilot joined 02:41 tewk__ joined 02:44 ascent left, tewk_ left, pjcj left, slavorg left, dalek left, sorear left, pmichaud left, PacoLinux left, tempire left, PerlJam left, knewt left, tempire_ is now known as tempire 02:45 d4l3k_ is now known as dalek 02:52 knewt joined 02:55 soh_cah_toa joined 02:56 PacoLinux joined 03:13 soh_cah_toa left 03:14 theory joined 03:24 soh_cah_toa joined 03:27 sorear_ is now known as sorear
dalek rrot/m0-prototype: 093802e | cotto++ | t/m0/integration/m0_hash.m0:
fix test so that it can pass
 03:37
04:27 daniel-s left 04:33 bluescreen joined 04:41 theory left 04:43 dafrito left
dalek rrot: 97e3693 | soh_cah_toa++ | runtime/parrot/library/osutils.pir:
Added perldoc to osutils.pir. Also cleaned up source code so I could figure what each function was doing more clearly.
 04:52
rrot: 9efc5f9 | soh_cah_toa++ | runtime/parrot/library/osutils.pir:
Removed a few trailing whitespaces in osutils.pir that were causing t/codingstd/trailing_space.t to fail. Also added some perldoc corrections that were missing because of a delinquent vim swap file.
05:16 soh_cah_toa left
dalek umage: 0f7da31 | soh_cah_toa++ | / (2 files):
Created a manpage and added steps after 'install' and 'uninstall' for installing/uninstalling it. Took it off the TODO list.
 06:02
06:04 TiMBuS left
dalek umage: 7576138 | soh_cah_toa++ | docs/man/plumage.1.gz:
Forgot to actually track the new manpage from the previous commit.
 06:04
06:06 bluescreen left
cotto ~~ 06:14
06:51 dalek left 06:55 dalek joined 07:19 d4l3k_ joined, dalek left 07:20 d4l3k_ is now known as dalek 07:29 mj41 joined 07:39 preflex joined 07:43 preflex_ left 07:50 particle left 08:01 daniel-s joined
cotto msg dukeleto I'm running into surprising behavior with Perl's pack and unpack functions. Does gist.github.com/1106278 look like a familiar issue? 08:34
aloha OK. I'll deliver the message.
moritz how do I extend parrot's library loading path (say, in PIR)? 08:38
I want the same effect as I wrote parrot -L somePath 08:39
and where would I find such things in the docs? 08:41
cotto moritz, look for IGLOBALS_LIB_PATHS
moritz nqp: say(pir::const::IGLOBALS_LIB_PATHS) 08:44
p6eval nqp: OUTPUT«9␤»
moritz nqp: say(pir::getinterp__P()[pir::const::IGLOBALS_LIB_PATHS])
p6eval nqp: OUTPUT«5␤»
moritz nqp: say(nqp::join(' ', pir::getinterp__P()[pir::const::IGLOBALS_LIB_PATHS])) 08:45
p6eval nqp: OUTPUT«[ "./", "/home/p6eval/nqp/install/lib/parrot/3.6.0-devel/include/", "/home/p6eval/nqp/install/lib/parrot/3.6.0-devel/include/" ] [ "./", "/home/p6eval/nqp/install/lib/parrot/3.6.0-devel/library/", "/home/p6eval/nqp/install/lib/parrot/3.6.0-devel/library/" ] [ "dynext/", "/ho…
moritz nqp: say(nqp::join(' ', pir::getinterp__P()[pir::const::IGLOBALS_LIB_PATHS][1]))
p6eval nqp: OUTPUT«./ /home/p6eval/nqp/install/lib/parrot/3.6.0-devel/library/ /home/p6eval/nqp/install/lib/parrot/3.6.0-devel/library/␤»
moritz cotto++
09:04 woosley left 09:46 slavorg joined 09:57 pjcj_ is now known as pjcj 10:07 contingencyplan left 10:44 preflex_ joined 10:49 preflex left
dalek p: 1b06d16 | jonathan++ | / (24 files):
Eliminate the REPR PMC, which wrapped around the REPR function pointer table; after a previous refactor that table is now always a singleton. Makes things simpler, and removes a level of indirection for every REPR operation.
 11:15
kudo/nom-install: 9da32b2 | moritz++ | / (2 files):
compile a lot more things in blib/ instead of src/gen

That way we have a more consistent layout between source tree and installation tree		 11:48
kudo/nom-install: f74a171 | moritz++ | / (3 files):
be more consistent with build locations
kudo/nom-install: bcb8d70 | moritz++ | src/Perl6/ (2 files):
simplify module loading
12:18 jsut joined
dalek p: e9244ec | jonathan++ | src/HLL/SerializationContextBuilder.pm:
Get an SC to track those others it ends up referencing.
 12:21
p: 3279ea7 | jonathan++ | src/ (2 files):
Add a way to give an SC a friendly description.
p: 95fbb94 | jonathan++ | src/ (3 files):
Improve detection of wrong version of pre-compiled code being used, and include the filename in the error rather than a weird SC identifier.
12:23 jsut_ left
dalek kudo/nom: c19671d | jonathan++ | / (2 files):
Bump NQP revision and chase 6model API updates.
 12:41
kudo/nom: d0ce251 | jonathan++ | src/Perl6/Grammar.pm:
Add description to SC if available, so we can get the better dependency out of date errors.
12:45 bluescreen joined
dalek p: 4a314bf | moritz++ | t/nqp/58-attrs.t:
fix 58-attrs.t
 12:50
12:51 whiteknight joined 12:52 whiteknight left, whiteknight joined
whiteknight good morning, #parrot 12:52
tadzik good morning whiteknight 12:53
whiteknight hello tadzik
msg soh_cah_toa that "verbose" named parameter should cause the chmod function to output a record to stdout. Take a look at the cp() function for an example. I would rather the behavior be properly implemented instead of being removed 12:54
aloha OK. I'll deliver the message.
atrodo =~ 12:58
whiteknight !!! 13:04
whiteknight finally fixed a terrible bug at work
moritz as terrible as dropbox's "any password accepted" bug? 13:05
whiteknight not quite that bad
inside a stored proc called from a stored proc called from a stored proc, called from extremely convoluted C# code, there was a field varchar(20) that should have been varchar(5) 13:06
er, varchar(50)
and the overflow warning was helpfully being converted to a fatal error, then rethrown with a less helpful error message
moritz ah, failing at failing
the good old favorite
atrodo Ah, the rethrow but don't tell you original exception bug. I hate that 13:07
whiteknight I love this construct: try { ... } catch(exception_with_helpful_details) { throw new Exception("Generic error message"); }
atrodo (generic excpetions)-- 13:08
13:11 daniel-s left, bubaflub joined
whiteknight Actually, the SQL exception wasn't particularlyl helpful either. It told me that a field was overflowing, but wouldn't tell me which field, which table, or in which of the millions of nested stored procs 13:11
13:13 daniel-s joined 13:14 particle joined
atrodo whiteknight> I take it you work at a place that puts most of it's business logic in stored procedures? 13:14
whiteknight surprisingly, no. 13:15
13:15 bubaflub_ joined
whiteknight stored procs are mostly just for data access, but there is a lot of complicated "optimization" going on 13:15
bubaflub_ ~
13:15 bubaflub left, bubaflub_ is now known as bubaflub
dalek kudo/nom: 10d4051 | (Solomon Foster)++ | src/core/ (2 files):
Start to implement sign.
 13:16
atrodo whiteknight> premature optimizations? 13:17
whiteknight in some places, maybe. They're very careful about trying not to load more data at any point than is strictly necessary
atrodo whiteknight> Doesn't sound too bad 13:18
whiteknight so the DB does a heck of a lot of filtering and limiting
Selecting data sets into temporary tables, and then selecting subsets from temporary tables, etc
13:19 TiMBuS joined 13:36 bubaflub left, bubaflub joined 13:38 RobertLJ joined 13:51 bubaflub left 13:52 bubaflub joined
jay ~~ 14:19
tadzik hey jay
jay morning tadzik, all
whiteknight good morning jay, tadzik 14:20
14:21 smash joined
smash hello everyone 14:21
whiteknight good morning smash. How are you doing today?
smash whiteknight: fine thank you, and you?
Felipe good morning all 14:22
whiteknight smash: I'm doing well, thanks. Packing up, moving to a new place at the end of the week. Staying very very busy
hello Felipe
Felipe: The weekly design meeting is today in #parrotsketch at 19:30 UTC. You should come 14:23
Felipe okay 14:24
smash whiteknight: good luck with movings :) 14:30
14:30 bubaflub left, bubaflub joined 14:44 fperrad joined
dalek kudo/nom: 9c39731 | (Solomon Foster)++ | src/core/Real.pm:
Add Real.sign(Real:U:).
 14:44
kudo/nom: bbde437 | (Solomon Foster)++ | t/spectest.data:
Turn on sign.t.
 14:50
jay whiteknight: followup on the compilation issue, simple pure PIR example where I'm not getting any gains to compiling to bytecode (and you can probably tell me why): gist.github.com/1106928 14:54
whiteknight jay: The PIR compilation process is pretty speedy. I also suspect some inefficiencies in bytcode loading 14:56
I would expect to see some kind of improvement. So it's weird that it isn't the case
jay Ok... I also found the following www.parrot.org/wiki/how-convert-pir-c 14:57
This seems to imply that we wouldn't expect to be able to do as well as compiled C code in an HLL like I'm building... and that ultimately performance would need to be obtained by moving certain things back to C?
whiteknight hmm I haven't seen that before
we would never expect to do as well as compiled C code. There's no way 14:58
jay I plead ignorance... I just don't know what is "reasonable" to expect for performance in a Parrot HLL compared to R's interpreter (it doesn't yet have JIT or anything).
whiteknight moving certain operations to be written in C instead of PIR can bring speedups in certain cases, but not all. There is overhead in switching between the two contexts
jay: Are you running an optimized Parrot? 14:59
jay Er... um.... I did the configure and build as recommended, running Ubuntu. No special things, no.
tadzik you can also go full hardcore and try --debugging=0 :) 15:00
whiteknight jay: Okay, when you configure, use "perl Configure.pl --optimize"
That will cut out all the debugging nonsense. Should be a significant speedup
tadzik it is
whiteknight well, not all the debugging stuff, just the various assertions, it inlines some code, etc
jay Ah -- so your defaults are "developer defaults" rather than some "stable end-user defaults". 15:01
whiteknight jay: It only sounds stupid if you say it like that
:)
jay lol Different worlds. I tend to explain my work to end-users, not to developers.
whiteknight Eventually, we probably want to invert that. --optimize should be the default and would need to be turned off for internals development 15:02
jay Interesting philosophical issues here, to do with how you see Parrot now, and how you see it in 1 year, 5 years, etc... and outreach to the "real world".
whiteknight jay: Definitely try to rebuild Parrot with --optimize. You will see improvements, but still won't be as good as C
jay Doing it now, will report back on the differences. 15:03
whiteknight awesome
whiteknight makes a mental note to document that somewhere, in big bold letters
whiteknight loses a few other mental notes, trying to find space for that new one
jay My advisor used to say, 'if you don't write it down, it never happened.' 15:06
whiteknight yeah, I'm a walking example of that
atrodo I need a midget on my back to act as my stenographer. 15:09
jay Looks like about a 5x speedup. Still no performance improvement by compiling to bytecode. gist.github.com/1106928 15:12
moritz what about making --optimize the default, and requiring a --debug to disable it?
whiteknight moritz: that's what I'm thinking 15:13
tadzik jay: maybe pir compiler is fast enough
(to not make compilation visible)
jay: how about --optimize --debugging=0 ?
whiteknight jay: 5x? Not bad. I'm flummoxed by the lack of performance improvements with compiling to bytecode
It may be that for such a small program, the overhead of compilation is as small as the overhead in packfile loading 15:14
as program size increases, I would expect the differences between the two to manifest
dalek rrot: 66e6aee | moritz++ | README:
recommend Configure.pl --optimize
moritz not the best solution, but better than doing nothing for now, IMHO
jay Maybe. I'll redo my NQR (HLL) benchmarks now, unless there is interest in tadzik's addition of --debugging=0? Easy enough while I'm doing this I suppose, give me a few minutes.
moritz jay: that won't make much of a difference, IME 15:15
tadzik it was quite significant last time I was doing that
(which was a year ago)
jay I'll do it. Give me a few more minutes and I'll report back.
tadzik but that was the whole Rakudo I think, not a short PIR file
15:21 daniel-s left 15:23 dmalcolm joined
jay No change adding --debugging=0. I'll go redo by NQR benchmarks next. 15:24
tadzik I see
jay But like you say, that was pretty plain-vanilla PIR, nothing fancy at all. 15:25
tadzik how about the whole NQR in some case?
jay Yes, that is what I'll do next. Though what do you mean by "the whole NQR" ? 15:26
tadzik oh, the pir is the pir generated from nqr code?
did the non-precompiled case sped up with --debugging=0?
jay No, this PIR was just my own simple PIR to get a handle on native Parrot speed. --debugging=0 didn't make a difference either in the .pir or the .pbc. 15:27
My NQR version will have all the overhead of the full HLL. Will take me a few minutes.
tadzik that's where --debugging=0 might make a difference 15:28
jay Ok, cool. I'll work on a plot to summarize the results, but old NQR --> NQR after --optimize --debugging=0 gives a 2.5x increase, and compiling to bytecode gives about an addition 10% speed gain, for a total of roughly 3x speed increase over the old NQR interpreted benchmarks. 15:36
whiteknight www.unlimitednovelty.com/2011/07/tr...hetto.html Interesting read about Erlang 15:46
jay: 3x is certainly nothing to sneeze at 15:49
jay Nope. I have a PDF... nice slope improvement as a result of the optimization, but still (as I think you would expect) not in the same ballpark as R. 15:50
www.stat.yale.edu/~jay/while.pdf 15:51
Thanks -- this was a big help whiteknight++ tadzik++ moritz++ 15:52
I suppose I could add a line for the straight PIR loop... the intercept would be around 0.02, and the slope very shallow, like the green or even shallower. R's green intercept is high because of the startup overhead of course. 15:56
whiteknight jay: It's good to see the improvement. I am going to suspect from the graph that R has a JIT
jay The problem is that nobody would actually think straight PIR is a fair comparison to an end-user package. No, R has no JIT. That is the interpreter working on a script.
whiteknight hmm... That's weird. I would have to see what they are doing 15:57
I don't see what else would explain having so much startup overhead, and so shallow a curve
jay They load various packages on startup and handle a lot of accounting to support the user I'm sure. As for shallow: it's only shallow compared to the alternatives... and maybe NQR is just really bad. 15:58
whiteknight NQR is going to generate unoptimized PIR code that is much more verbose than any PIR code you or I would write by hand 15:59
jay Fair enough... but there is no way around that, right? 16:00
whiteknight At the moment, no. We have an optimization framework, but I don't think anybody has written any optimizations for it yet
so that's sort of a non-starter
jay I'll grab some lunch and then see how my other benchmarks change. They are equally interesting, not quite as trivial. 16:01
whiteknight ok 16:02
At the moment you are probably going to have to live with some bad performance. We're working on improving things
jay I'm not interested in performance per se, only in coming to terms with this as a possibly viable alternative to R for future development. You have interoperability advantages that R can't touch, and scalable advantages that R can't touch. Wins and losses, obviously. 16:04
back in a bit...
16:15 benabik joined
benabik ~~ 16:16
whiteknight hello benabik 16:32
16:35 mj41 left
benabik o/ whiteknight 16:36
16:47 Kulag left 16:54 Kulag joined
jay If I do parrot foo.pir does that compile to bytecode and then run? I.e. is it really equivalent to the two-step process of parrot -o foo.pbc foo.pir ; parrot foo.pbc ? 16:55
whiteknight jay: basically, yes 16:56
Parrot runs bytecode, so the PIR compiler generates a bytecode PackFile structure in memory from the input code 16:57
when you do it with a .pbc, Parrot reads in the .pbc file and creates a PackFile structure in memory also
jay Ah. That explains why my "compiled" runs are just faster by a fixed speed -- the fixed speed of compilation. Not really interesting.
whiteknight right
Like I said, I suspect there are some inefficiencies in the .pbc file loading sequence 16:58
but that would only shave some time off the top, not fix overall complexity
jay www.stat.yale.edu/~jay/meanexp.pdf similar gains to before. Here, I'm using GSL for the mean of a vector of values: should be very fast. NQR will be slower than R because the random number generation involves PIR looping, rather than C code generating a vector of random values simultaneously (as would happen in R). 16:59
whiteknight okay, that's a much better graph. I still can't imagine why the R performance curve is shaped like that
benabik jay: "optimized" NQR? 17:00
whiteknight how can it be almost flat across that entire range?
jay So this is very interesting: I hypothesize that the NQR performance could match the R performance if I created a vectorized random number generator in C... the difference for this benchmark would only be the intercept, not the slope.
"optimized" by building Parrot with --optimize as whiteknight++ recommended.
benabik Ah, yes, that helps a lot.
jay It only looks flat... it's very shallow... just much faster than NQR, nothing more. 17:01
whiteknight it's flat enough to be disconcerting
jay Yeah, sorry about that. R is pretty good.
whiteknight Do you know much about the R interpreter internals? 17:02
jay In this benchmark, almost everything is compiled C code, though.
whiteknight ok
jay The interpreter is a nightmare of C code I think.
There are about 300,000 lines of C code in the src/ tree, plus another 70,000 lines in the header files. 17:03
So actually the slope difference is due entirely to the difference between looping in PIR for the random number generation vs looping in C with a vectorized random number generator. 17:04
Coke it's not surprising that R is faster than NQR. I think tcl8.5 was some several hundred times faster than partcl. 17:07
whiteknight I would need to look at the implementation again to see, but I think our random number generator is simplistic
I think it falls back to system rand()
jay Off-topic: gist.github.com/1107238 This is from Dan Adler, who is in Germany I think, a very sharp guy who does lots of different things (not just R stuff). This project of his might actually have some value to Parrot (but I don't know enough to guarantee it). Worth a 3-minute glance for one of you.
whiteknight: I used the R random number generator, not yours. 17:08
So I'm really controlling for as many differences as possible.
whiteknight jay: Yes, that rdyncall does look interesting. Same thing as our NCI system. Maybe better
jay: Oh, you were calling the R random number generator through NCI? 17:09
jay Dan Adler is *really* sharp. Trust me on that one, I don't say it much. One of the best I've met.
whiteknight: yes.
whiteknight Any time you call C code from PIR code, there's a context switch which is non-trivial. I've done benchmarks of programs where I've seen significant speedups by rewritting particular bits of C code into PIR 17:10
there are no hard rules, but sometimes the overhead is prohibitive. I suspect calling it in a tight loop exacerbates the problems
jay whiteknight: so I would be looping in PIR making repeated calls to the random number generator via NCI... so as I said I could probably match R by writing a vectorized random number generator wrapper in C.
whiteknight: yes, we agree.
17:11 mj41 joined
jay Actually, if you guys got Dan Adler interested in some aspect of Parrot, it would be huge for you. Maybe I could help there, I know Dan pretty well. 17:11
benabik whiteknight: PIR->C has a large cost? I thought the cost hit when we went C->PIR...
atrodo Pretty sure it's either way
benabik Is PIR->C slow due to FFI problems? Is it faster if you make a custom PMC? 17:13
whiteknight cost is either way. PIR -> C is expensive. C -> PIR is even worse 17:14
atrodo My understanding is that the transition in/out of the VM is expensive
benabik Hence the desire to get as much into the VM as possible in M0? Also hopefully decrease that barrier. 17:15
whiteknight When you call an NCI function, you need to invoke the NCI wrapper PMC, pull the parameters out of the calling context with PCC, and then call the C function. Then, if there are return values, it's the reverse
wrap the C returns in Parrot types, put them in the return continuation, continue
17:16 RobertLJ left
benabik Hm. Most of that is difficult to avoid. Pity. 17:17
whiteknight Well, that's exactly what M0 is designed to overcome 17:19
I think there is a lot of room to optimize here as well
dalek R: 1a1d830 | (Jay Emerson)++ | STATUS:
Benchmarks updated
 17:20
jay Would M0 eventually allow "compiling" C code into the VM directly, avoiding the overhead of the NCI? I'm just trying to see the big picture. 17:26
whiteknight jay: M0 is going to allow easier JIT, which will compile bytecode down to C code, optimizing along the way 17:34
M0 also will have integrated FFI, so much of the overhead of NCI could disappear if we were clever about it 17:35
jay ok, thanks. 17:36
cotto_work ~~ 17:41
Felipe ~~ 17:43
dalek TT #2164 created by Andy Dougherty <doughera@…>++: Error detecting attributes (g++-3.3) 17:58
TT #2164: trac.parrot.org/parrot/ticket/2164
TT #1047 closed by jkeenan++: pf_items assumes sizeof(INTVAL) == sizeof(opcode_t)
TT #1047: trac.parrot.org/parrot/ticket/1047
dukeleto jay: M0 will be written in C, but it won't know anything about compiling C code, if that clarifies things 17:59
benabik dukeleto: But it will know very deeply about talking to C code, yes? 18:00
dukeleto benabik: FFI/NCI will be in M0, but libffi does most of the heavy lifting 18:01
jay Yes, I think I'm in the ballpark. And it does seem to related to previous benchmark results this AM where the NCI may explain much of the differences.
cotto_work dukeleto: how familiar are you with pack/unpack in perl 5? 18:02
dukeleto jay: our NCI system most probably has some dog-slow codepaths that have not been optimized at all, or behavior you didn't ask for is assumed and unnecessary work is being done
cotto_work: a few notches on my stick. why?
cotto_work dukeleto: I'm having platform-specific issues - gist.github.com/1106278
jay dukeleto: We may have covered that... --optimize and rebuilding Parrot gave a pretty damn impressive speedup. 18:03
dukeleto jay: ah, yes. That will do it :)
jay: optimized builds are much harder to debug, but they are much faster :)
cotto_work: i means something different to each perl. I think you need to be more specific 18:04
cotto_work: like specifying the "width" of the integer
cotto_work dukeleto: I was using "l", but that seemed to be at least 32 bits rather than exactly 32 bits. 18:06
18:07 lucian joined
dukeleto jay: dyncall looks very interesting 18:07
jay I don't know enough to know if it would be helpful, but I have the highest opinion of Dan Adler. He's not a statistician, he's more of a computer science jock/hacker. He only works on things that he finds cool. I think you would like him! 18:08
dukeleto jay: dyncall looks very similar to libffi 18:09
jay Well, libffi saved my bacon playing around with GSL... though bubaflub seems to have a workaround with the thunks. 18:10
atrodo cotto_work> Did you try N? 18:16
dalek kudo/nom: eb38b99 | jonathan++ | src/Perl6/Actions.pm:
Fix thunk building, so BEGIN say 1 + 2 will work.
18:17 rurban joined
rurban Will rakudo-star-2011.07 the next and when? Maybe someone knows 18:18
Because it might be the last one with these packaging rules and I want to provide it for cygwin 18:21
cotto_work rurban: the #perl6 folks could probably answer that better than we can 18:28
rurban thanks. yes, it's today. pmichaud already working on it. 18:29
18:29 rurban left 18:52 jay left 19:00 NotFound left 19:01 NotFound joined 19:18 soh_cah_toa joined 19:19 PerlPilot is now known as PerlJam
dalek kudo/nom: 08c2f9c | jonathan++ | src/Perl6/Metamodel/RoleToClassApplier.pm:
Be more consistent on quoting in an error (TimToady++).
 19:22
bubaflub ping dukeleto 19:25
whiteknight aloha: time? 19:28
aloha whiteknight: time is a lion, where i am a lamb.
whiteknight aloha: clock?
aloha whiteknight: LAX: Tue, 12:28 PDT / CHI: Tue, 14:28 CDT / NYC: Tue, 15:28 EDT / UTC: Tue, 19:28 UTC / LON: Tue, 20:28 BST / BER: Tue, 21:28 CEST / TOK: Wed, 04:28 JST / SYD: Wed, 05:28 EST
whiteknight #ps in 2
Let's see some last-minute reports!
cotto_work there you go 19:31
whiteknight #ps in now 19:32
benabik aloha: time is also you probably meant clock 19:34
aloha benabik: Okay.
benabik aloha: time?
aloha benabik: time is a lion, where i am a lamb. or you probably meant clock
19:36 contingencyplan joined
ingy hi benabik o/ 19:40
benabik o/ ingy
ingy :)
dukeleto bubaflub: pong 19:47
tcurtis ~~
dalek rrot: 8cc26e4 | fperrad++ | runtime/parrot/library/Archive/ (2 files):
[Archive] add some documentation
dukeleto soh_cah_toa: pong
bubaflub dukeleto: i'm looking at jitterbug stuff - do you have an instance running by any chance?
dukeleto bubaflub: yep, a few 19:48
bubaflub dukeleto: great. can i take a peek? i may actually use this for work...
dukeleto bubaflub: here is the newest one, which i know is working currently: dev.cashmusic.org:3000/
bubaflub: i had one at jitterbug.leto.net:3000, but i think something borked it 19:49
bubaflub dukeleto: ok
cotto_work dukeleto: #ps? 19:50
bubaflub dukeleto: what i'm looking for is a dashboard that could track number of test failures per test run. also, our test suite takes ~24hrs to run, so i'm looking for something that can run via cron and not post commit-hook
dukeleto bubaflub: sure, doable 19:51
bubaflub dukeleto: great. 19:53
dukeleto: saves me from having to do my own... i started doing it in Catalyst but started feeling real lazy real quick
dukeleto bubaflub: basically, you would run builder.pl in cron, and don't add a github hook 19:54
bubaflub dukeleto: great. and what about charting / report type stuff. already there / easily extensible so i could add something in?
dukeleto bubaflub: it is a dancer app, reasonably easy to start hacking on 19:57
bubaflub dukeleto: great. i'm thinking for work i'd need a reports section (probably with jQuery charting) and user/login stuff.
dukeleto bubaflub: jitterbug.pl 19:58
bubaflub: sounds like much of the stuff you want would be nice to have in jitterbug
bubaflub dukeleto: yep. i'm angling to get paid to hack on open source :-) 19:59
dukeleto bubaflub: there ya go!
20:01 fperrad left 20:09 ambs joined
benabik whiteknight: If I use Packfile.view, I have to run some kinds of sub manually, yes? I'm thinking of :load and :init here, but not sure if there are other kinds. 20:10
whiteknight benabik: at the moment, the ones you can get at manually are :main, :load, and :init 20:11
I have a new branch in the works where you can create and fetch subs by any arbitrary tag name
benabik whiteknight: Right. And nothing in the Packfile{,View} PMCs will run :load and :init for me, right? So I need to run them manually? 20:12
whiteknight PackfileView certainly will not. I don't think Packfile and friends will either
benabik :immediate and :postcomp both seem like a bad idea. 20:15
20:16 NotFound_b joined 20:17 NotFound left 20:18 NotFound_b is now known as NotFound
whiteknight :immediate and :postcomp both run during compilation or immediately thereafter. Those are tags for teh compiler only, and it doesn't make sense to keep that data around after compilation 20:18
cotto_work aloha: PDS Q2 2011 is Saturday July 30 at 2100 UTC 20:19
aloha cotto_work: Okay.
benabik whiteknight: Those are specifically for IMCC, so I don't need to worry about them for PCT? 20:20
whiteknight Depends what you mean by "worry about them"
current PCT generates :immediate subs. I don't know if it also generates :postcomp 20:21
20:21 bluescreen left
whiteknight Felipe++ 20:33
Coke Felipe: welcome aboard. 20:37
Felipe thanks
tadzik . o O ( Felipe gets Felipe++ for joining. Send some to mom! ) 20:40
20:41 perlite_ joined
Felipe whiteknight++ 20:44
20:44 perlite left, perlite_ is now known as perlite
whiteknight Felipe: That pull request looks good to me. I haven't tested it yet, but you can merge it in if you want 20:45
20:45 jay joined
dalek R: 690825b | (Jay Emerson)++ | / (4 files):
Revised bracket set operations [] for atomic set... not

for matrixy examples.		 20:46
whiteknight I really do want to get back into matrixy at some point 20:50
I would love to get that fixed up and working again, with all the cool new tools and libraries that we've been building
jay Or else join the dark side and team up with me...
whiteknight I would love to do that too
jay At this point, the advice is greatly appreciated. Until I learn more, advice is more valuable than actually effort. 20:51
< actual effort >
where "actual effort" is not intended to belittle "advice"... "advice" is clearly effort... just not direct coding effort. Ai carumba. 20:52
whiteknight :) 20:53
My goal, if I can get matrixy running at least a reasonable subset of the M language, is to be able to use it as a nice high-level interface to PLA
jay I just got the basic bracket operator working, so v[5] <- 10000 works separately from a <- 10000. Subtle, but not terribly difficult. 20:54
whiteknight that's a nice step forward
jay If I had GSL bindings, would that supplant the need for PLA?
Felipe whiteknight: okay
whiteknight jay: I really need to learn R, if I want to be playing with it convincingly. You know of any good tutorials?
20:54 bluescreen joined
whiteknight jay: PLA is just matrices and BLAS. It stores matrices in a format that should be usable by GSL 20:54
jay: think of PLA like the data storage, GSL would be something to do with that data 20:55
Coke wonders if R is the language he remembers hearing about on Flowing Data.
jay whiteknight: Yup: ask me. I'm the best (ha). I know some things about the language that matter if you are trying to learn something of use for Parrot or Parrot HLLs.
No, seriously, just a sec, I'll give you a link. 20:56
Check out the PDF in this directory. Intended as an Intro for people with coding experience in other languages. www.stat.yale.edu/~jay/Brazil/Campinas/IntroToR/ 20:57
I need to get organized and keep better track of various talk material. That one was from a trip to Brazil last summer. 20:58
whiteknight jay: For an idea about what PLA does, check out this link: github.com/Whiteknight/parrot-line...nation.nqp
basically, it makes working with 2D matrices dirt simple. They just work the way you would expect, without having to play around with arrays and other not-quite-right stuff 21:00
jay Ok, so I remember seeing the NumMatrix2D class. Fundamentally, the underlying object should just be a Fixed*Array (or a Resizable*Array) -- R has classes vector, matrix, and array (and has no scalar... a "scalar" is a vector of length 1). But a matrix is just a 2D array for user-friendliness.
whiteknight right. Internally, NumMatrix2D is just an allocated block of memory, like an array. An [X,1] matrix is identical to an array of length X 21:01
jay Adding a class to NQR is way up near the top of my "todo" list. So far I just have vectors, and that was the right way to start. 21:02
whiteknight I'm heading home now. We can chat more later tonight 21:03
jay k... good luck packing!
whiteknight thanks! I need it!
jay not fun.
21:03 whiteknight left
jay Coke: Flowing Data? Not sure. I did some preliminary work on handling streaming data once... 21:09
Coke jay: flowingdata.com/ 21:11
Felipe brb 21:12
Coke yes, that was it. e.g.:
flowingdata.com/2011/05/11/how-to-m...t-circles/
jay Coke: actually pretty nice examples on that second page. The best-known visualization guy (in terms of the subject matter, independently of the software) is Edward Tufte. www.edwardtufte.com/tufte/ He has a few excellent books, and does the lecture circuit. 21:14
PerlJam Tufte++ 21:16
jay An amazing speaker, too. Worth doing one of his workshops just to observe him in action. 21:17
PerlJam wonders if Ed Tufte and Hans Rosling ever crossed paths. 21:20
jay jay think that is an excellent question. Ed is in the area, and I actually need to track him down... I'll try to ask. 21:21
21:23 bluescreen left 21:26 ambs left 21:31 mj41 left 21:32 lucian left 21:36 lucian joined 21:37 bluescreen joined 21:43 Psyche^ joined, theory joined 21:48 Patterner left, Psyche^ is now known as Patterner 22:01 bubaflub left 22:17 theory left 22:19 darbelo joined 22:30 theory joined 22:35 soh_cah_toa left
dalek lrskate: b1edb40 | tcurtis++ | src/LALR/DPDA.winxed:
Remove debugging lines.
 22:35
lrskate: f3c7281 | tcurtis++ | / (3 files):
Implement interpretation of read transitions.
lrskate: 1b3ef6a | tcurtis++ | / (2 files):
Add test and support for Top transitions.
lrskate: c62447f | tcurtis++ | t/dpda-interpreter.t:
Add test that input is actually removed from the input string by ReadTransitions.
lrskate: 11cc92a | tcurtis++ | src/LALR/DPDA/Interpreter.winxed:
Pop the read symbol when transitioning along a ReadTransition.
jay ./in 22:59
23:02 NotFound left 23:06 whiteknight joined
whiteknight good afternoon, #parrot 23:15
Coke gluten abend.
whiteknight sounds tasty 23:16
Felipe lol 23:25
whiteknight: weird, I tried the automerge, but it did nothing. 23:26
whiteknight hmm. weird
Felipe no notification either 23:27
I'll merge by hand
whiteknight ok
23:33 benabik left 23:35 benabik joined 23:39 benabik left 23:40 benabik joined 23:41 benabik left 23:42 kid51 joined 23:44 darbelo left
Coke THE AUTOMERGE, IT DOES NOTHING! 23:45
23:45 lucian left
Felipe I've used it in other project... 23:45
but It failed now :D 23:46
23:46 lucian joined 23:51 preflex joined 23:53 lucian left 23:54 preflex_ left, lucian joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!