#parrot Parrot 2.2.0 "Like Clockwork" Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: Fix compact_pool shenanigans | Fix HLL bugs (TT #389, #1040) | Prioritize Rakudo Needs
Set by moderator on 20 March 2010.
Whiteknight it looks to me like compact_pool is allocating a new uber-block, copies all existing strings into it, then frees the other blocks 00:02
so assuming that algorithm is true, it shouldn't be growing without bound
sorear copying collector? :(
Whiteknight sorear: for string storage, yes
sorear What's the status of pluggable GC? 00:06
I could write an in-place compacting collector, that could be a big win for certain workloads
darbelo sorear: ask bacek, he was plugging bohem some time back. 00:07
chromatic Except that the uber-block doesn't take into account dead storage space, because those numbers are wrong, so it doesn't shrink as much as it should.
Also, copying around known-constant memory is silly and wrong.
sorear (Do we still want to eliminate stack walking?) 00:09
Whiteknight chromatic: any idea what PObj_is_movable_TESTALL is checking?
ah, nevermind. There's a comment near there with an explanation 00:10
Where are constant strings allocated from?
sorear: eliminating stack-walk would be fantastic 00:17
it's the last thing keeping us from being precise
sorear it is also a Fairly Big Undertaking 00:18
purl okay, sorear.
sorear purl, forget it
purl sorear: I forgot it
Whiteknight sorear: yes it is, which is why nobody has tackled it yet
What I think we need is a GC that is a little bit more tolerant. So newly allocated items can't be collected in the first GC run 00:19
sorear two unrelated ideas just clicked together in my mind
Whiteknight then, most objects never need to worry about it
sorear if we rewrite most of Parrot in a slightly higher level language *cough Lorito*, eliminating stack walk will be trivial
Whiteknight then, we need to make sure everything else is anchored or registered somewhere
sorear: yes, that's one of the planned benefits
because then everything will be anchored in the context 00:20
sorear have there been any updates on L?
cotto_work L? 00:23
purl i heard L was "lowercase one character" or POUND
sorear L is also sorear being lazy talking about "Lorito" 00:24
purl okay, sorear.
Whiteknight sorear: no updates recently
00:30 kthakore joined
kthakore dukeleto: is this good? www.perlfoundation.org/perl5/index.cgi?gsoc 00:30
dukeleto: anything more? 00:31
purl i think anything more is a gaming box, or penis envy
00:36 lucian joined 00:41 hercynium joined
dukeleto purl, forget anything more 00:42
purl dukeleto: I forgot anything more
dukeleto kthakore: thanks
kthakore dukeleto: ok
dalek kudo: e8b8da3 | jonathan++ | src/Perl6/ (3 files):
Correct handling of attributes during the compile so we don't lose ordering, thus dealing with the intermittent instance.t fejls.
 00:46
00:50 lucian_ joined 00:59 abqar joined 01:08 frzntoz joined
dalek kudo: 26ba8bf | (Solomon Foster)++ | (3 files):
Merge branch 'master' of git://github.com/unobe/rakudo
 01:26
kudo: 208fcab | (Solomon Foster)++ | src/Perl6/ (3 files):
Merge branch 'master' of git@github.com:rakudo/rakudo
01:33 Patterner joined 01:40 theory joined 01:44 ash_ joined 01:47 frzntoz left 01:56 bacek joined
cotto oh noes! It's bacek. 02:09
02:23 lucian joined 03:01 Hunger joined 03:09 dalek joined
dalek kudo: f7d3461 | (Solomon Foster)++ | src/core/Any-list.pm:
Quick implementation of Any.pairs.
 03:27
kudo: 1882918 | (Solomon Foster)++ | t/spectest.data:
Turn on S32-array/pairs.t.
03:48 janus joined
dalek kudo: b2f995a | (Solomon Foster)++ | t/spectest.data:
Turn on split.t.
 04:13
04:13 contingencyplan joined 04:29 snarkyboojum joined
cotto Is it likely that nqp-rx will ever implement any()? 05:50
05:51 contingencyplan joined 05:52 AndyA joined 05:57 AndyA_ joined
dalek rrot: r45190 | petdance++ | trunk (10 files):
converted some NOTNULLs to the more accurate ARGIN
 06:02
rrot: r45191 | petdance++ | trunk/include/parrot/packfile.h:
rmeoved reference to non-existent functions and source file
sorear argh 06:09
it looks like it's not quite possible to use parrot.h and perl.h in the same translation unit
they stomp on each other's macro space and I'm losing my ability to keep order
plobsing sorear: do you need both of the conflicting macros? can you just #undef one of them? 06:24
sorear plobsing: That's what blizkost currently does, and it just bit me 06:29
Apparently if you #undef HASATTRIBUTE_WARN_UNUSED_RESULT at the wrong time, PARROT_WARN_UNUSED_RESULT never gets defined, not even to the empty string
causing a very confusing syntax error later
(also, who defines macros named '_'. Most. Generic. Name. Ever.) 06:30
plobsing yeah, those shouldn't really escape core. unfortunately, there's no good way to make PMCs without using core headers.
*I assume that's where you're running into problems 06:31
sorear Actually, I'm using PARROT_WARN_UNUSED_RESULT in my own code
I did not realize that was a secret symbol
sorear thought /^PARROT_|Parrot_/ was exported 06:32
06:32 chromatic joined
plobsing then the official line is that as an extender, you shouldn't include parrot.h 06:32
sorear Is there an official list of what headers and symbols I *can* use? 06:33
plobsing extend.h, embed.h, extend_vtable.h
for symbols, see docs/embed.pod for a (likely outdated, incomplete) list 06:35
sorear looks like PARROT_WARN_UNUSED_RESULT is defined via extend.h 06:36
plobsing ok, so no luck there, but I'm betting it doesn't export _() to you 06:37
sorear how am I supposed to NOT import parrot.h... pmc2c inserts an #include "parrot/parrot.h" 06:38
plobsing that's what I was getting at in my gripe about PMCs 06:39
sorear _ is defined in parrot.h
it's also defined in CORE.h (p5)
er, CORE/config.h
plobsing worst case, write function wrappers around the macros you need and compile separately 06:40
sorear :/ I guess 06:41
jonathan was apparantly managing fine
I'll have to ask his secret
plobsing please share it with me once you find out. I've had problems with Parrot's core macros before 06:42
sorear oh wow, Perl 5 still supports prototypeless C compilers?! 06:44
chromatic If we need to remove parrot.h from PMCs, we should. 06:47
sorear Does that mean removing the ability of extensions to interact with Parrot in nontrivial ways? 06:49
sorear has a mostly-hate relationship with #ifdef PERL_CORE 06:50
Perl: TIMTOWDY perl: We know better than you do, deal
"marshal" is systematically misspelled, no wonder my code doesn't compile 06:54
chromatic Mostly it's removing the ability of extensions to interact with Parrot in ways we don't support. 06:55
plobsing chromatic: I think we might need it in core PMCs. but taking it out of dynpmcs seems like a good idea 06:57
sorear What's so special about core PMCs? 06:59
(Why do core PMCs exist? Couldn't stuff like bignums be library code?)
plobsing sure, bignums could move out of core. Some PMC types are required for parrot to run. Example: PCC can't work without FIAs (IIUC) 07:00
OO is pretty useless without Class and Object 07:01
chromatic Breakfast isn't breakfast without Waffle.
sorear wonders what to do with the code he cargo culted from nci.pmc 07:02
plobsing you managed to salvage anything from that wreck?
sorear I'm not sure. But it looked important, so I took it 07:03
plobsing makes a note to randomly mark sections of code with /* XXX Important */ 07:05
sorear pastie.org/887899
plobsing: The correct spelling is /* ... ... You are not expected to understand this. */ 07:06
purl Hmm. No matches for that, sorear.
sorear ^^^ function may be apropos to current discussion
chromatic Huh. I understand that. I wonder what that says about... things. 07:07
sorear I don't.
I don't understand what makes tail calls Hard, that is 07:08
chromatic Nothing, if you understand CPS. 07:09
sorear I remember tail calls being something you got for free with CPS; why does Parrot have special code for them? 07:10
plobsing sorear: this is a level lower than the "you get tailcalls for free" level 07:11
chromatic Yeah, you get tailcalls for free if something does the hard work to give you tailcalls, and this is that something. 07:13
sorear I wonder if it's because of the NCI
plobsing It sort of is. In normal cases, the jump would be handled by the return sequence. 07:16
but there's no Parrot return sequence in a VTABLE
perhaps this should get refactored into a function. It seems like anyone wanting to make a new type of invokable should be doing the exact same thing. 07:18
chromatic Exactly.
07:35 payload joined 07:48 allison joined
sorear jonathan-- *.c *.h in a make clean rule 07:52
sorear-- not completely reading makefiles
dalek izkost: f15e868 | sorear++ | (6 files):
Factor marshal logic out of p5invocation
 08:01
08:02 riffraff joined 08:11 dalek joined 08:15 fperrad joined 08:16 iblechbot joined 08:40 dalek joined 08:57 AndyA joined 09:34 clinton joined 09:38 cotto joined 09:59 payload joined 10:19 eternaleye joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32855), fulltest) at r45191 - Ubuntu 9.10 amd64 (g++ with --optimize) 11:28
dalek rdinal: f6213ec | fperrad++ | setup.pir:
refactor with inc_pir
 11:41
11:46 lucian_ joined, whiteknight joined 11:48 lucian_ joined
whiteknight good morning, #parrot 11:49
12:17 GodFather joined 12:22 mj41 joined 12:37 mikehh joined 12:41 ruoso joined 12:42 theory joined 12:53 snarkyboojum joined 12:54 riffraff joined 13:11 Mokurai joined 13:12 payload joined 13:13 Mokurai1 joined 13:14 mikehh joined, atrodo joined 13:17 Austin joined
Austin Well, good morning parrot-nam! 13:31
13:42 ash_ joined 13:43 mikehh_ joined 13:54 davidfetter joined 13:59 mikehh_ joined
whiteknight good morning, Austin 14:01
Austin Whiteknight, today is one of those days where I'm glad there's no "you're not smart enough to be a programmer" feature built into compilers.. 14:02
whiteknight Austin: the desirability of that feature is inversely proportional to the amount of code you are reading that you wrote yourself 14:03
Austin I guess.
I changed some stuff in P6metaclass to accomodate role attributes, and now the Mock stuff is failing tests, but *only* if the tests are run in the tap harness - they don't fail from the command line. :( 14:04
whiteknight wonderful 14:06
Austin So naturally, I'm going to go work on something else. 14:09
Coke ... there is something quite awesome about going to wikipedia.com to fact check something I'm putting on my resume. 14:16
Austin Heh 14:17
"Coke's resume: as trustworthy as Wikipedia..."
And I was worried about *me* getting some work this year.. 14:18
14:19 khairul joined
khairul hi there 14:21
ash_ whiteknight: maybe in addition to my current GSoC work, i can try experimenting with other ways of taking advantage of the llvm? like taking advantage of their exception handling system, or more complicated code generation using clang/llvm-gcc/dragonegg to generate other parts of code in the llvm-ir format that might be able to make other optimizations
whiteknight: blog.fallingsnow.net/2008/05/23/sim...with-llvm/ has a good example of what I am talking about if your not familiar (kinda long blog post, but it shows what i mean fairly well i think) 14:22
whiteknight ash_: that would definitely be nice
yeah, I've read that
lucian whiteknight: if parrot were to commit to llvm, opcodes could be llvm ir, no need for lorito 14:24
whiteknight lucian: yes, we've considered that too
lucian whiteknight: but i've heard so many complaints about llvm, especially when used for dynamic languages, that i would not think it's a good idea 14:25
whiteknight lucian: do you have links to those complaints?
lucian whiteknight: i'd google, but you can go on irc.freenode.net #pypy and ask
whiteknight: the unladen swallow folk also have some tales to tell 14:26
ash_ i think it would be better to keep lorito seperate, you can always do what I was saying and have the lorito ops in llvm form and let llvm run optimizations on them
whiteknight ash_: Yeah, I think that's the way we are going. If lorito is separate, we can conceivably "plug" in other JIT backends
lucian whiteknight: from what i've heard/read, llvm is great but right now it's too focused on static languages
whiteknight lucian: depends what that focus means. At the lowest level, Parrot still compiles to normal machine code 14:27
and machine code is not dynamic at all
ash_ the llvm is really just a way to make C code dynamically, its almost like making dynamic portable assembly that you can move between computers and it can optmize it before it runs, its not supposed to do a lot of higher level stuff
lucian whiteknight: but pir is much more dynamic than that
whiteknight lucian: but PIR is written in C
anything you can write in PIR you can write in C 14:28
lucian whiteknight: for example, you can't patch generated code in LLVM, you have to recompile
14:28 mikehh_ joined
lucian anything you can write in python you can write in C, but that doesn't mean it'll be fast 14:28
whiteknight lucian: why would we want to patch generated code? You can't really patch generaed parrot bytecode
lucian whiteknight: dynamic languages need specialised versions of functions depending on argument types for example
whiteknight lucian: If I substituted python code with the underlying logic in C, and compiled it, it would be just as fast if not faster 14:29
it would be a huge waste of time, but it wouldn't be any slower to execute
lucian whiteknight: if you left it dynamic, it wouldn't be any faster
whiteknight: cython can compile most pure python code, but it ends up being a bit slower most of the time 14:30
whiteknight lucian: it *could* be faster because we could pass the whole program to the C compiler and optimize it as a large block
lucian whiteknight: unless you restrict types of certain things
whiteknight that's where the savings are: large-scale optimization potential
lucian whiteknight: that would be possible if llvm understood perl/python objects
whiteknight: i mean it's still possible, but llvm makes it harder
whiteknight lucian: there's nothing to understand. We have function pointers for our VTABLEs, and we can call those function pointers 14:31
ash_ lucian: you can get the llvm to understand perl objects, or pmc's
whiteknight and better yet, a good compiler could cache those pointers between calls, or do constant folding
lucian whiteknight: you better talk to people smarter than me about this
whiteknight the benefit of dynamic languages has never been performance. You can always write faster software in C 14:32
the benefit to dynamic languages is more efficient use of developer time
lucian whiteknight: i know. but you want them to be fast, so you write a jit
whiteknight PIR ops are written in C. If I compile that C to LLVM-IR and cache that, a JIT can look up the LLVM-IR for each PIR op, string them together into a complete Sub, optimize the whole block, compile it, and cache it for later use 14:33
the only way JIT makes it any faster is if we can optimize the code. Otherwise, we are already running code that we've written in C
JIT works by stringing together the C code into predefined blocks and optimizing the large blocks. 14:34
lucian whiteknight: that's a simple patching jit
Austin Mmmm..build rakudo with distutils
whiteknight and the only time JIT is faster is if the overhead of compilation is outweighed by long-term optimization savings
Austin I wonder how long *that* takes...
ash_ if a PIR op is simple enough it may be able to do things like inline the whole op dynamically, saving you overhead
whiteknight ash_: exactly.
lucian it may be possible that with a middle layer between C and a HLL you could achieve that
but i'm sceptical
i'm quite certain you'll never beat luajit for example 14:35
whiteknight JIT also saves the overhead of op dispatch. We inline the functions together and avoid having to call each through a table lookup and function pointer indirect dispatch
lucian i know what a jit does
what i'm saying is that with llvm it's hard to build a fast jit for a dynamic language 14:36
it's almost like writing a jit that generates C code and compiles that
but with a smaller compilation overhead
whiteknight I don't see how it would be any harder, since all our code is already written in C
that is, what can LLVM do for a static language that it cannot do for a dynamic one? Or, how does it determine that our C code implements a dynamic language, and their C code mplements a static one? 14:37
lucian it doesn't determine, it simply can't optimise it properly
your C code that implements a dynamic language is an interpreter 14:38
whiteknight that's something I would like a lot more information about
lucian is looking for those links
atrodo is curious as well
Austin Whiteknight: consider the case of an Integer.
I write a sub in nqp: sub bump($i) { $i++; } 14:39
How does that go to llvm?
ash_ see, IMO, the goal of using the LLVM is to get each parrot op to be as close as possible to a single assembly op on your system, the llvm has tools that let us get a little bit close to that goal
whiteknight Austin: depends on a variety of factors. Assuming $i is an Integer PMC, it would essentially inline a call to VTABLE_increment 14:40
Austin The problem with PIR, as pmichaud has bemoaned, is that you can't make any assumptions about $i. You have to call the increment vtable.
whiteknight exactly
Austin But there's no type information available, so you don't get to assume it's an Integer pmc.
You're stuck with optimizing the preamble and postamble of the sub, and then calling get_pmc($i).vtable_increment() 14:41
whiteknight Austin: True. But consider a similar example: sub doublebump($i) { $i++; $i++; }
in this case, we can cache the value of the function pointer and inline it twice
Austin Yes...
Nope.
whiteknight sure you can, the value of $i between those two is invariant 14:42
and the value of $i->vtable between those two damn well better be invariant
Austin The value of $i is invariant. But the rest may not be.
whiteknight and $i->vtable->increment should be, etc
Austin But even if it *is* invariant, you still can't look inside the vtable function, except at runtime. 14:43
*runtime = execution time.
14:43 mj41_ joined
whiteknight Austin: conversely, if we do know the type of $i at runtime, we can still make good guesses 14:43
Austin So double-bump gets to optimize the table lookup, call, table lookup, call sequence into table lookup, call, call.
whiteknight and that's more than we get to optimize now 14:44
Austin Well, actually, the find_method code caches the lookup, so it doesn't totally suck. But it still pays a hash-lookup for the second one.
whiteknight look, I'm not saying it's perfect or that we're going to get maximum performance where all our dynamic overhead evaporates into a fine mist of unicorn farts 14:45
Austin No.
There are some solid arguments in favor of lorito. And they mainly involve the inferior runloop problems.
whiteknight Austin: yes, Lorito solves many issues besides JIT 14:46
lucian whiteknight: all i could find so far mail.python.org/pipermail/python-de...44002.html
Austin But I don't see moving closer to the machine as any kind of performance improvement.
whiteknight in fact, I really think JIT is one of the least of it's merits
the real benefit we get is that if everything is lorito we can completely avoid expensive context switching
packing variadic C arguments into a call signature PMC, passing it to the runloop, and unpacking those arguments into PIR context registers is hugely expensive 14:47
...not that we save on that process completely, we're still likely to serialize calls into a call object, but much of the management overhead can go away 14:48
Austin You know, I completely fail to understand how that can be expensive.
whiteknight It's more expensive right now than it needs to be because of a lot of legacy bullshit 14:49
Coke msg fperrad - your email to rakudo about distutils almost makes me want to switch partcl; The only thing stopping me is that I still depend on the c compiler. Maybe once I eliminate all the pmcs...
purl Message for fperrad stored.
ash_ brb changing classrooms
whiteknight I think we can cut PCC overhead down by half or more with some simplifications and cleanups to the system 14:50
but that's off-tpic
atrodo Bizzare questions> can PMC change their vtable and basically become a different PMC mid stream? 14:54
14:54 ash_ joined
Coke es. 14:55
"yes"
see the C<morph> opcode.
could let you implement "readonly", or perl's 'tie', or tcl's 'trace' 14:56
whiteknight atrodo: technically yes, through morph (like Coke++ mentioned). In practice, it's rarely used and I would like it to be deprecated 14:57
it's certainly never used "well"
atrodo so in Whiteknight's doublebump example above, the vtable could change between the two operations?
whiteknight atrodo: "technically", yes 14:58
but like I mentioned: nobody really uses morph and I suggest that nobody should
Coke whiteknight: morph is needed for p5 and tcl. 14:59
atrodo Okay. But as long as it's available, LLVM can't assume that $i's vtable is invariant, right?
Coke so, please don't go ripping stuff out. =-)
(I am not sure if rakudo is using it but it would not surprise me at all.)
whiteknight Coke: I'm not ripping anything out. But I would be very interested to hear how morph--as it's currently conceived and implemented--is needed
ash_ atrodo: at compile time maybe, but at runtime i think you can make that assumption, if you know more about the objects 15:00
Coke ash_: not true.
whiteknight none of the core types implement working versions of morph, at least not as far as I am aware
15:00 dalek joined
Coke whiteknight: try assigning a string to a Float. 15:01
(yes, that doesn't use either the morph vtable or the morph opcode)
15:02 whiteknight_ joined
Coke but there are uses of morph in src/pmc/* - and even if there were not... that doesn't mean it's removable. 15:02
(and I don't mind not using morph as long as I have a way to implement [trace] without it. (more) 15:03
ash_ rakudo/src/pmc/objectref.pmc implements morph, but i don't know what its used for, its just there
lucian whiteknight: ash_: i really hope a fast llvm backend for parrot is possible, but my point is that llvm as it is now may not be entirely suited
so you'd have to fix llvm on some points
unladen swallow folk had to fix tail recursion for example
ash_ well, my GSoC i wasn't going to do as much indepth work as the unladen swallow folks tried to do, i was more looking towards the way MacRuby does it 15:04
they only replaced the stack frame builder essentially, all the rest of the code is still from the main trunk of ruby 15:05
lucian ash_: right. then good luck :)
ash_ but thats, imo, is only an initial entry point, there are still other things the llvm offers that might be useful/helpful/offer a speedup 15:06
lucian ash_: yes, it might be useful. my point was that you should be mindful of its limitations and it's extreme focus on low-level static languages 15:07
Coke I'm currently also using it to morph between all the non-Array types in tcl. I could migrate this to be a single TclScalar type, so that's not a blocker on my end.
(it would increase memory usage by several pointers per tcl PMC, but that is probably noise compared to PCC) 15:08
lucian ash_: code.google.com/p/unladen-swallow/w...eCollector 15:09
ash_ lucian: yeah, i know, i am aware of its limitations, its almost just dynamically generated C, it doesn't do anything fancy like overloading or garbage collection, it only has 3 base types (fundamentally), just integers, floats and pointers . granted you can make a string out of that (array of size 8 ints) or a bool (size 1 int), etc.
lucian ash_: good, so you're smarter and more informed than me :) 15:10
Coke Hey, anyone want to review my resume? =-)
ash_ lucian: the llvm does 1 really well, IMO, it makes C code dynamically, which in a dynamic language would be useful, i know its very static oriented right now, but it still could be useful to parrot 15:12
did unladen swallow ever get merged back into trunk python?
i heard they were trying to get some of their changes merged, never heard if it happened or not 15:13
lucian ash_: they're trying to merge into python 3.2 i think
ash_: and some of their changes have been merged already 15:14
ash_ cool
15:24 patspam joined 15:25 mikehh_ joined
ash_ i wonder what was causing unladen swallow to have so many problems, i haven't heard much from the macruby blog complaining about the llvm, or the rubinius blog really 15:31
15:32 fperrad joined
fperrad purl ? 15:33
purl yes, fperrad?
fperrad ttbot ?
purl ttbot is TapTinder build bot owned by mj41 and reporting tt.taptinder.org/buildstatus/pr-Parrot/rp-trunk build errors.
15:36 Andy joined
Coke heh. I saw the ttbot link and freaked out that the build was broken. =-) 15:37
15:50 mikehh_ joined 15:59 TiMBuS joined 16:10 mikehh_ joined 16:24 Psyche^ joined 16:43 cosimo joined
cotto_work fperrad, iwbn if ./setup.nqp help show the specific options available for a given project. Is that planned? 16:47
also, fperrad++ for the Rakudo setup.nqp 16:48
dukeleto 'ello 16:49
fperrad cotto_work, already exist with : 16:51
usage => "your own message"
17:02 whiteknight joined 17:12 mikehh_ joined
dalek kudo: 4a5a252 | moritz++ | src/core/operators.pm:
fix infix:<Z> to work with non-lists, as suggested by jnthn++. Fixes RT #73836
 17:15
17:29 jan joined
dukeleto if anyone in here would like to register as a Mentor for this years Google Summer of Code, please go to socghop.appspot.com/ and apply to be a mentor for TPF. I will then accept it :) 17:33
cotto_work done 17:36
dukeleto cotto_work: accepted 17:40
17:41 payload joined
cotto_work acceptance accepted 17:41
17:43 contingencyplan joined
Coke what, the organization code isn't "dukeleto" this year!? 17:49
atrodo It should be
darbelo It makes you show up higher in the sorted list.
Now you're all the way down there with the other T's 17:50
whiteknight dukeleto: applied 17:52
dukeleto whiteknight: accepted 17:55
whiteknight w00t!
...and the teachers in highschool said I would never amount to anything
dukeleto whiteknight: we don't need no education ..... teachers! leave them kids alone! 17:58
whiteknight you can't have any pudding if you don't eat your meat! 17:59
I can't wait till the proposals start coming in. I think we are going to have some nice ones 18:00
18:03 bermie joined
dukeleto whiteknight: indeed. much thanks to you and your many good gsoc ideas blog posts 18:03
whiteknight++
whiteknight They aren't my ideas. I just write them on the blog 18:05
khairul hi, i wrote to the dev list a couple of days ago regarding implementing an instrumentation framework for parrot. 18:09
i've written up a more detailed proposal at www.mangkok.com/parrot/parrot_proposal.pdf .
i'd appreciate it if i can get more feedback on it.
dukeleto khairul: i will take a look. it would be good to mail the list again with that link 18:13
18:14 joeri joined
khairul dukeleto: thank you. i'll do it tomorrow when i'll have a bit more to add. 18:14
dukeleto khairul: i like your "Benefits to the Perl/Open Source Community" section. more examples about what is possible would make it rock solid 18:15
khairul dukeleto: thank you, i'll keep that in mind 18:17
cotto_work hi khairul
dukeleto khairul: if it is possible to figure out "who calls this method on this object", that would be valuable
cotto_work I was hoping you'd show up here.
khairul cotto_work: hi there, i was actually lurking here somewhere but distracted with other stuffs 18:18
dukeleto khairul: also, are you familiar with any version control systems? it would be nice to have your code examples on github or launchpad or whatever is your poison of choice
khairul dukeleto: hrm, i'll look into those when i have the time. the code examples i'll try to put into github. 18:19
dukeleto khairul: also, you should include a timeline that details what you will work on each week. everybody knows it will change, but having a good+clear plan makes it easy to see problems
khairul: that would be awesome!
khairul: and by detailing each week, mentors can more easily assess if the project is too big/too small for the alotted time 18:20
khairul dukeleto: yup, i already have a tentative schedule in there. it needs a bit more details on it i agree.
dukeleto khairul: also, a trigger for PMC creation would be very valuable 18:21
khairul: ah, i just got the to timeline in the PDF :) 18:22
khairul: yes, a few sentences for each week would be preferrable
whiteknight khairul: Do you have a general list of hooks you are planning to implement?
dukeleto whiteknight: yes, some are listed in the PDF 18:23
khairul whiteknight: generally, the list of hooks are those listed under proposed triggers
whiteknight hmmm...I don't think I saw a PDF
dukeleto khairul: in general, the proposal is looking strong. It is very good that you are starting early. That is a very good sign.
whiteknight: www.mangkok.com/parrot/parrot_proposal.pdf
cotto_work khairul, I'd definitely mention how this project is different from the current profiling runcore. It's fairly obvious to someone who knows the profiling runcore, but I don't think most people do.
whiteknight dukeleto++
khairul dukeleto: thanks for the encouragement. 18:24
cotto_work khairul++
khairul cotto_work: i'll keep that in mind
whiteknight dukeleto: some of these hooks look like they would be extremely interesting for security sandboxing
dukeleto khairul: yes, comparison to the profiling runcore would be very useful.
whiteknight: yes indeed, i thought the same
whiteknight if a disallowed operation were attempted, the hook would be engaged to crap out 18:25
cotto_work Also, feel free to list me as a possible mentor.
dukeleto++ made me legit recently
khairul yea, i saw. thanks for the offer
18:25 PacoLinux joined
whiteknight khairul: One point I thought of was that the instruments should be an object, and the hooks should be methods on that object 18:25
so you can do lookups with VTABLE_find_method 18:26
khairul there's actually a few ways i was considering doing.
one is by scanning, as done in the proof
another is by PMC
cotto_work I love gsoc season.
khairul and last is by NCI
i'll need to look into each of those 18:27
so, thats why i put 1 week to prototype API
18:28 chromatic joined
whiteknight khairul: do you plan to do this work in the parrot repo directly, or start a separate project? 18:28
khairul i'm not sure. it can be either i suppose. 18:29
18:33 dngor joined
particle suggests a branch in the parrot repo 18:34
we can help keep it close to trunk
however, a git branch based on dukeleto's parrot git mirror may be easier to work with 18:35
dukeleto khairul: i think you may want to look at using a dynpmc 18:37
whiteknight dukeleto: we don't have support yet for pluggable runcores 18:38
maybe that's something we need to work on between now and then if we're going to be entertaining projects that create new runcores
dukeleto whiteknight: yes, indeed
whiteknight: what stands in the way up pluggable runcores right now?
whiteknight just hasn't been implemented, to my understanding 18:39
cotto and chromatic have done all the necessary encapsulation and prettification wok
chromatic We needed pluggable runcores to make the profiling runcore work, but we didn't need dynloadable runcores so we didn't implement that.
whiteknight right, there wasn't a use-case until now 18:40
arguably we could just jam this thing into trunk
we have to figure out as a community how we want to handle it
cotto_work yes
dukeleto whiteknight: shall we make a new ticket for dynloadable runcores? 18:41
cotto_work +1
purl 1
whiteknight +1
purl 1
cotto_work +one 18:44
purl 1
cotto_work +two
purl 2
cotto_work +seventy five
+seventy-five
stupid bot
purl Bad programmer, no cookie!
cotto_work dtwt
khairul lol 18:45
i'm going to call it a night, its almost 3 am here.
thanks for all the suggestions.
cotto_work what's your timezone
night
khairul +8 GMT
cotto_work nm. singapore
khairul yep
i'll update my proposal tomorrow then with your suggestions. 18:46
thanks and good nite/morn/aft.
18:49 ash_ joined
whiteknight really is a nice proposal. The tool has plenty of merit 18:50
dukeleto whiteknight: indeed. i think it would make chromatic's + others lives easier, because you could code something up that looks for exactly what you want to know, instead of wading through valgrind output
cotto_work Yeah. I'm excited.
whiteknight I do wonder if it will fill a whole summer, considering how capable his proof-of-concept is already
cotto_work That too.
Maybe we should make him implement pluggable runcores to pad it out a bit. ;) 18:51
s/pluggable/dynamically loadable/
dukeleto whiteknight: i find that if a project will take at least half the summer, in actual coding, that is a great fit. the other half of the summer can be spend on writing more tests/docs and adding other features
whiteknight dukeleto: yeah, in my case the code took up less than half
dukeleto whiteknight: a project that takes less than a summer is much better than one that take a lot longer
whiteknight: one is called passing, the other failing :) 18:52
whiteknight debugging and cursing at the computer took the other half
dukeleto whiteknight: as it should :)
Coke ponders blocking out time for YAPC. 19:22
cotto_work We still need to get a yay+time or nay on another PVMW 19:26
I'd have booked my tickets long ago if not for that. 19:27
whiteknight I'm going to miss yapc this year 19:33
was a lot of fun last year
chromatic You'll never wash your car again. 19:34
whiteknight I don't think I have
I put the child seat where Larry was sitting so it will be protected forever
or, at least until the kid turns 5 19:35
cotto_work You could bring your get. Get him started early. 19:36
s/get/kid/
whiteknight drool + keyboards don't mix well 19:37
chromatic Neither does powdered sugar.
cotto_work There's a keyboard for that.
atrodo Am I reading this right that YAPC is in Columbus?
whiteknight chromatic: that may be, but I refuse to give up my donuts 19:38
the kid can be left with relatives for a weekend, but donuts are forever
atrodo: I believe so 19:39
atrodo Hmmmm, I may have to think about attending
whiteknight when do we find out where YAPC will be in 2011?
because if it's Pittsburg or anywhere further east, I will come 19:40
further than that, and my probability decreases
dukeleto i think we should have a Parrot Dev summit this year
whiteknight that would be nice 19:41
Coke Austin: how do you break out of a loop in nqp-rx? 19:43
whiteknight He added a "last" keyword, methinks
www.gitorious.com/kakapo/kakapo/blo...nqp#line19 19:44
Coke danke. 19:46
whiteknight Coke: you using Kakapo? 19:47
19:48 muixirt joined
muixirt hi 19:48
Coke whiteknight: nope. 19:50
but I already have tcl's break() which does pretty much the same thing, so I'll use that for now.
muixirt newbie question: is there a simple method for dealing with integers of a specific size like 64-bit int oder a byte platform-indepedently on Parrot?
Coke whiteknight, Austin : see anything wrong with this line: 19:52
whiteknight muixirt: no, not really
Coke pir::chopn__vsi $string, 1;
ARGH.
(the parens.)
whiteknight muixirt: everything is an INTVAL, to sort of make the programmer less aware of the limitations of the hardware
muixirt: I'm sure something could be written up very quickly if you needed something better 19:53
muixirt whiteknight: but INTVAL depends on what is an int for a particular platform 19:54
whiteknight yes. It's the wordsize of the current machine
Austin Coke: You throw a control exception. Kakapo calls it 7 last() 19:55
whiteknight muixirt: do you have a need of a way to specify a bytesize? 19:57
Austin Coke: pir::chopn__vSI($string, 1) should work fine, as should an SSI form, if you need it. 19:58
muixirt whiteknight: nothing concrete, but i wondered about how someone implements languages which have a variety of integer types
Coke Austin: right, I was hoping for a p6 native version. 19:59
muixirt whiteknight: but of course this is rarely the case for dynamic typed languages
whiteknight muixirt: I think it would be relatively easy to put together a dynpmc library with a variety of fixed-size types
plobsing muixirt: if there is a dire need for smaller (or possibly larger) int types, a ManagedStruct could be made to work
whiteknight ah, ManagedStruct could work, yes. Would not be pretty 20:00
plobsing and wouldn't deal *well* with larger int types
Coke Austin: pir::chopn__vSi($string, 1) doesn't actually chop $string.
whiteknight would probably just be easier to put together a quick dynpmc library. Maybe I'll throw one together tonight or tomorrow
Coke it appears to chop a copy of it, leaving $string unchanged. 20:01
muixirt whiteknight: and i wonder how this is managed with external C-libs (nci)
Austin Heh.
Which is why you might want the SSI version.
$string := pir::chopn__SSI($string, 1)
whiteknight Coke: that does't sound good. File a bug report?
Coke .. even though there isn't a chopn_s_s_i opcode?
Austin inline op chopn(out STR, in STR, in INT) :base_core {
Coke ... dammit. 20:02
I mean, thank you!
Austin line 77, string.ops
whiteknight: It's not a bug, per se.
NQP will "make" a string ($S0) out of the PMC $string, and then pass that to chopn. 20:03
But that won't affect the original PMC...
whiteknight oh, maybe I misread what coke said
Austin $P0 = find_lex '$strnig' ; $S0 = $P0 ; chopn $S0, 1 ; ... 20:04
Coke Austin: yah. I had dropped into Q:PIR for a few cases like this, where the original PIR was using opcode-that-changed-things-in-place
Austin :)
PIR has evolved in a language that really is better for hand coding than compiling. 20:05
So last night one of my fillings escaped.
I just got back from the "NASCAR dentist" 20:06
Coke Austin: that sucks.
purl The rock is now off.
Austin I swear I'm not in the chair 7 seconds before he starts with "That 'uns got to come out..."
Coke austin; if you're bored, you could probably remove Q:PIR from this file. =-)
github.com/partcl/partcl-nqp/blob/m.../string.pm
Austin And then out comes the "big pocking wrench"
Coke ... were you given a chance to veto? 20:07
Austin Dude, WTF is that?
Coke wtf is what?
my url? 20:08
Austin A 373 line function?
Even my enormous monitors, in vertical orientation, cannot accomodate your enormous should-be-a-switch-but-isn't ...
20:09 payload joined
Coke it's implementing (part of) www.tcl.tk/man/tcl8.5/TclCmd/string.htm 20:09
20:09 davidfetter joined
Austin Heh 20:10
Coke Hey, if you want a commit bit and wish to go crazy, I'm happy with that. =-)
Austin What does the select_option function do? 20:11
Is this one of those "just type enough to identify the command" things?
Coke yes!
davidfetter oh hai
Coke OH HAI
Austin: tcl is fun! especially when written in nqp-rx!
Austin quotes, "The first thing I'm gonna do when I get to California, is punch John Osterhout right in the mouth!" 20:12
Is it John?
Coke yes. =-)
nice guy, please don't do that. =-)
I'd hate to start some kind of bloods/crips thing with him and larry.
davidfetter well, you could hurt your fist on his teeth
Austin Pssh
20:13 dalek joined
Austin Larry ain't in it. He's doing Electric Commander, now - he's in my field. 20:13
But that "you don't really have to type the whole keyword if you don't want to" stuff went out with Commodore basic...
Coke it's still in the most recent tcl. <shrug> 20:14
I'm just an implementor, not a designer.
and that part's already written. you wouldn't have to touch it!
Austin github-- 20:15
Show the damn url...
davidfetter so i have this awful question
Coke git@github.com:partcl/partcl-nqp.git ?
Austin Yeah, I'm cloning it now.
Coke WHEE
commit bit? (same terms as parrot)
I trust you not to break anything. =-) 20:16
davidfetter o/` when you're a kid, and you wanna go weeeeee o/`
Austin Don't you depend on the C compiler?
Coke for partcl, yes. partcl-nqp doesn't have any pmcs yet.
trying to see if I can avoid them.
Austin Ahh
Good for you.
You know anything about multi-sub dispatch? 20:17
Coke enough to use it, occasionally.
Austin Heh. Me too.
But now I've got a problem.
davidfetter so about the parrot code...is everything handled under a CLA?
Coke CLA?
purl i heard CLA was Contributor License Agreement or www.perlfoundation.org/contributor_..._agreement or www.parrot.org/foundation/legal or www.parrot.org/files/parrot_cla.pdf
Austin I'm dynamically compiling a set of trampolines, to wrap some NQP subs as a multisub. (That is, I've got subs like foo__int, foo__string, and I'm compiling a set of strings defining subs foo :multi(int) and foo:multi(string)) 20:18
For whatever reason, the subs compile okay, and they update the multisub array foo[], but dispatch goes wrong - I pass in a subclass of a class that's handled by one of the signatures, and the sub for a totally different signature gets called. 20:19
Coke Austin: can you duplicate the error without the tramplines? 20:20
*O*
Austin No.
If I put the trampoline code into a .pir file with a bunch of dummy hooks, everything works okay.
I think it has something to do with the dynamic compilation.
Coke do you do the dynamic compilation in the same scope as the compilation of the scope of the invocation? 20:21
Austin Scope?
purl somebody said Scope was same.
Coke (I would expect the multi stuff to figure the dispatch at runtime, not compiletime, though.
Austin Me too. I've got .namespace directives in the compiled code. 20:22
And it's finding *one* of the subs. Just the wrong one.
Coke if you can write up a short code snippet and open a ticket, I can take a look. (no promises)
Austin Hell, if I could write up a *short* code snippet, I wouldn't have a problem. 20:23
Coke mmhehe
Austin I was kind of hoping the description would remind you of when you tried that thing, with the other thing, back when you were working on the earlier thing...
20:26 darbelo joined
Coke other than "MMD doesn't work when I try to do foo", no. 20:27
Austin Coke: What happens if the subcommand is not in the list? Or does the select_option handle that?
Coke github.com/partcl/partcl-nqp/blob/m...ons.pm#L45 20:28
(yes, it handles it.)
20:29 dngor joined
pmichaud Austin: I haven't had any experiences like what you describe. 20:29
Austin pmichaud: Neither have I :( 20:30
davidfetter CLA as in contributor license agreement 20:34
("licence" in the UK ;) 20:35
Tene I'm moving to a new job sometime soon. I think I'll need to re-do the CLA thing.
Austin Why would you need to do that, Tene? 20:37
Tene Hmm. Maybe I'm misremembering.
davidfetter so about the CLA, i've run across something in pl/parrot that might lead to my asking for another license for parrot :/
Austin Coke: The string::compare that I see doesn't do anything if you do (string compare a b), returning ''. It only returns something if you give it three args: (string compare -nocase? a b). Is that a NYI, or expected behavior?
Coke davidfetter: yes, i was giving you the URL to the cla. =-) 20:38
Austin: @args.shift; # assuming -nocase here.
it's a todo, yah. 20:39
Austin Should it just do a plain old cmp?
davidfetter Coke, thanks. looks like it has what we'd need :)
particle davidfetter: email parrot-directors@lists.parrot.org about that
davidfetter particle, thanks :) 20:40
Coke Austin: in the case of not -nocase?
Austin right
And, should I validate -nocase in any way, or is 3 args enough of an indicator?
Coke Austin: there's a much more complete PIR-based implementation in partcl's partcl project, in runtime/builtin/string.pir 20:41
and the docs for [string] are at the tcl.tk URL I posted previously. 20:42
(and a bunch of tests just out of reach in t/cmd_string.)
and thank you!
=-)
20:43 lucian joined
Coke that was the long version. the short version is "yes, you have to validate, because there's more than just -nocase) 20:47
nopaste "Austin" at 68.39.12.202 pasted "Some progress" (59 lines) at nopaste.snit.ch/20109 20:54
Coke Austin: woot. 21:00
Austin my sub equal(*@args) { 21:01
compare(|@args, :op_name<equal>) == 0;
}
particle 289+91+30 21:03
purl 410
particle 15*7
purl 105
Coke Austin: still need to do the args checking. 21:05
(and insure that the sub-sub names don't bleed out to user-visible land.)
Austin Compare does the args checking. And the whole :op_name<> thing is to print the right error message. 21:06
Coke but yah, being able to write subcommands in terms of others, +1.
Austin: wrong args checking.
Austin -nocase -length int ?
Coke what if someone says [string equal a b c d e f g] ?
Austin Fails.
Coke wrong # args: should be "string equal ?-nocase? ?-length int? string1 string2"
Austin [ -nocase ] [ -length int ] a b 21:07
Right
Coke does yours say "equal" or "compare" ?
Austin It says "$op_name"
:)
Coke wfm.
Austin What does $haystack.getIndex() do? 21:08
Coke converts a tcl-style index into a parrot-style index.
Austin Oh, boy. 21:09
Coke so, "end-1" is "whatever the length is minus one"
there's similar indexing on lists & strings.
Austin So "end - 1" is [-2] ?
Coke ... yes. except since I already know the length at that point, I just use positive #'s.
Austin Okay. I think I'm going to just give that code a pass for now. 21:10
Coke here's the valid indices:
www.tcl.tk/man/tcl8.5/TclCmd/string.htm#M9
Austin Yeah, I saw them.
Coke (yes, end+20 is a valid index.) 21:11
Austin I just didn't make the connection ...
Sure, but what does it do?
The web page suggests that end-1 and end+1 are the same.
Coke no, end-1 and end+-1 are.
Austin Ahh, yeah
Missed the -
So what does end+1 return? 21:12
Coke end+1 is after the end, and string index would return empty string there.
Austin Segmentation fault, core dumped?
Hoo.
Coke ->
Austin Walking a mile for negative numbers..
Coke (have fun.)
dalek rrot: r45192 | petdance++ | trunk/src/dynpmc/gdbmhash.pmc:
consting
 21:20
Austin Coke: What's with the parrot-revision thing? 21:24
darbelo Austin: set it to 0 and you'll be fine. 21:35
Austin darbelo++ 21:36
wfm
darbelo It enforces a minimum svn rev. But releass don't report a svn rev, so... 21:37
Austin sings, "Never be rude to an Irishman, no matter what you do..." 21:41
Coke: when trimright says "whitespace is removed (spaces, tabs, ...)" do I take it literally, or do I trim off unicode whitespace? 21:48
literally, I guess. 21:52
21:56 AndyA joined 22:21 sorear joined 22:26 riffraff joined 22:29 tcurtis joined 22:35 kid51 joined 22:54 tcurtis joined 23:23 ruoso joined 23:52 hercynium joined 23:54 dngor 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!