Camelia, the Perl 6 bug

IRC log for #parrot, 2010-03-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:02 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 Whiteknight so assuming that algorithm is true, it shouldn't be growing without bound
00:02 sorear copying collector? :(
00:02 Whiteknight sorear: for string storage, yes
00:06 sorear What's the status of pluggable GC?
00:06 sorear I could write an in-place compacting collector, that could be a big win for certain workloads
00:07 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.
00:07 chromatic Also, copying around known-constant memory is silly and wrong.
00:09 sorear (Do we still want to eliminate stack walking?)
00:09 Whiteknight chromatic: any idea what PObj_is_movable_TESTALL is checking?
00:10 Whiteknight ah, nevermind. There's a comment near there with an explanation
00:10 Whiteknight Where are constant strings allocated from?
00:17 Whiteknight sorear: eliminating stack-walk would be fantastic
00:17 Whiteknight it's the last thing keeping us from being precise
00:18 sorear it is also a Fairly Big Undertaking
00:18 purl okay, sorear.
00:18 sorear purl, forget it
00:18 purl sorear: I forgot it
00:18 Whiteknight sorear: yes it is, which is why nobody has tackled it yet
00:19 Whiteknight 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
00:19 Whiteknight then, most objects never need to worry about it
00:19 sorear if we rewrite most of Parrot in a slightly higher level language *cough Lorito*, eliminating stack walk will be trivial
00:19 Whiteknight then, we need to make sure everything else is anchored or registered somewhere
00:19 Whiteknight sorear: yes, that's one of the planned benefits
00:20 Whiteknight because then everything will be anchored in the context
00:20 sorear have there been any updates on L?
00:23 cotto_work L?
00:23 purl i heard L was "lowercase one character" or POUND
00:24 sorear L is also sorear being lazy talking about "Lorito"
00:24 purl okay, sorear.
00:24 Whiteknight sorear: no updates recently
00:30 kthakore joined #parrot
00:30 kthakore dukeleto: is this good? http://www.perlfoundation.org/perl5/index.cgi?gsoc
00:31 kthakore dukeleto: anything more?
00:31 purl i think anything more is a gaming box, or penis envy
00:36 lucian joined #parrot
00:41 hercynium joined #parrot
00:42 dukeleto purl, forget anything more
00:42 purl dukeleto: I forgot anything more
00:42 dukeleto kthakore: thanks
00:42 kthakore dukeleto: ok
00:46 dalek rakudo: e8b8da3 | jonathan++ | src/Perl6/ (3 files):
00:46 dalek rakudo: Correct handling of attributes during the compile so we don't lose ordering, thus dealing with the intermittent instance.t fejls.
00:46 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​8b8da3d934ac92b34414af8ddd8c7db9cf6e195
00:50 lucian_ joined #parrot
00:59 abqar joined #parrot
01:08 frzntoz joined #parrot
01:26 dalek rakudo: 26ba8bf | (Solomon Foster)++ |  (3 files):
01:26 dalek rakudo: Merge branch 'master' of git://github.com/unobe/rakudo
01:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​6ba8bf81279ec9c558dbb230d2607dd3e30c2b0
01:26 dalek rakudo: 208fcab | (Solomon Foster)++ | src/Perl6/ (3 files):
01:26 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
01:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​08fcab42bcdb0e4ab8d3d987625bd267b80e5d3
01:33 Patterner joined #parrot
01:40 theory joined #parrot
01:44 ash_ joined #parrot
01:47 frzntoz left #parrot
01:56 bacek joined #parrot
02:09 cotto oh noes!  It's bacek.
02:23 lucian joined #parrot
03:01 Hunger joined #parrot
03:09 dalek joined #parrot
03:27 dalek rakudo: f7d3461 | (Solomon Foster)++ | src/core/Any-list.pm:
03:27 dalek rakudo: Quick implementation of Any.pairs.
03:27 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​7d3461c23f165eb1816f45f31947571da118df1
03:27 dalek rakudo: 1882918 | (Solomon Foster)++ | t/spectest.data:
03:27 dalek rakudo: Turn on S32-array/pairs.t.
03:27 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​8829184bf0a7c40671822841f25296c83af7e03
03:48 janus joined #parrot
04:13 dalek rakudo: b2f995a | (Solomon Foster)++ | t/spectest.data:
04:13 dalek rakudo: Turn on split.t.
04:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​2f995aaaadc4c04774d49eaeee5ca1ec1919a9d
04:13 contingencyplan joined #parrot
04:29 snarkyboojum joined #parrot
05:50 cotto Is it likely that nqp-rx will ever implement any()?
05:51 contingencyplan joined #parrot
05:52 AndyA joined #parrot
05:57 AndyA_ joined #parrot
06:02 dalek parrot: r45190 | petdance++ | trunk (10 files):
06:02 dalek parrot: converted some NOTNULLs to the more accurate ARGIN
06:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45190/
06:02 dalek parrot: r45191 | petdance++ | trunk/include/parrot/packfile.h:
06:02 dalek parrot: rmeoved reference to non-existent functions and source file
06:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45191/
06:09 sorear argh
06:09 sorear it looks like it's not quite possible to use parrot.h and perl.h in the same translation unit
06:09 sorear they stomp on each other's macro space and I'm losing my ability to keep order
06:24 plobsing sorear: do you need both of the conflicting macros? can you just #undef one of them?
06:29 sorear plobsing: That's what blizkost currently does, and it just bit me
06:29 sorear 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
06:29 sorear causing a very confusing syntax error later
06:30 sorear (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.
06:31 plobsing *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
06:31 sorear I did not realize that was a secret symbol
06:32 * sorear thought /^PARROT_|Parrot_/ was exported
06:32 chromatic joined #parrot
06:32 plobsing then the official line is that as an extender, you shouldn't include parrot.h
06:33 sorear Is there an official list of what headers and symbols I *can* use?
06:33 plobsing extend.h, embed.h, extend_vtable.h
06:35 plobsing for symbols, see docs/embed.pod for a (likely outdated, incomplete) list
06:36 sorear looks like PARROT_WARN_UNUSED_RESULT is defined via extend.h
06:37 plobsing ok, so no luck there, but I'm betting it doesn't export _() to you
06:38 sorear how am I supposed to NOT import parrot.h... pmc2c inserts an #include "parrot/parrot.h"
06:39 plobsing that's what I was getting at in my gripe about PMCs
06:39 sorear _ is defined in parrot.h
06:39 sorear it's also defined in CORE.h (p5)
06:39 sorear er, CORE/config.h
06:40 plobsing worst case, write function wrappers around the macros you need and compile separately
06:41 sorear :/  I guess
06:41 sorear jonathan was apparantly managing fine
06:41 sorear I'll have to ask his secret
06:42 plobsing please share it with me once you find out. I've had problems with Parrot's core macros before
06:44 sorear oh wow, Perl 5 still supports prototypeless C compilers?!
06:47 chromatic If we need to remove parrot.h from PMCs, we should.
06:49 sorear Does that mean removing the ability of extensions to interact with Parrot in nontrivial ways?
06:50 * sorear has a mostly-hate relationship with #ifdef PERL_CORE
06:50 sorear Perl: TIMTOWDY  perl: We know better than you do, deal
06:54 sorear "marshal" is systematically misspelled, no wonder my code doesn't compile
06:55 chromatic Mostly it's removing the ability of extensions to interact with Parrot in ways we don't support.
06:57 plobsing chromatic: I think we might need it in core PMCs. but taking it out of dynpmcs seems like a good idea
06:59 sorear What's so special about core PMCs?
06:59 sorear (Why do core PMCs exist?  Couldn't stuff like bignums be library code?)
07:00 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:01 plobsing OO is pretty useless without Class and Object
07:01 chromatic Breakfast isn't breakfast without Waffle.
07:02 * 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?
07:03 sorear I'm not sure.  But it looked important, so I took it
07:05 * plobsing makes a note to randomly mark sections of code with /* XXX Important */
07:05 sorear http://pastie.org/887899
07:06 sorear plobsing: The correct spelling is /* ... ... You are not expected to understand this. */
07:06 purl Hmm.  No matches for that, sorear.
07:06 sorear ^^^ function may be apropos to current discussion
07:07 chromatic Huh.  I understand that.  I wonder what that says about... things.
07:07 sorear I don't.
07:08 sorear I don't understand what makes tail calls Hard, that is
07:09 chromatic Nothing, if you understand CPS.
07:10 sorear I remember tail calls being something you got for free with CPS; why does Parrot have special code for them?
07:11 plobsing sorear: this is a level lower than the "you get tailcalls for free" level
07:13 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
07:16 plobsing It sort of is. In normal cases, the jump would be handled by the return sequence.
07:16 plobsing but there's no Parrot return sequence in a VTABLE
07:18 plobsing 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 #parrot
07:48 allison joined #parrot
07:52 sorear jonathan-- *.c *.h in a make clean rule
07:52 sorear sorear-- not completely reading makefiles
08:01 dalek blizkost: f15e868 | sorear++ |  (6 files):
08:01 dalek blizkost: Factor marshal logic out of p5invocation
08:01 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​f15e8686689ec3336142854f474e391d05c11eb7
08:02 riffraff joined #parrot
08:11 dalek joined #parrot
08:15 fperrad joined #parrot
08:16 iblechbot joined #parrot
08:40 dalek joined #parrot
08:57 AndyA joined #parrot
09:34 clinton joined #parrot
09:38 cotto joined #parrot
09:59 payload joined #parrot
10:19 eternaleye joined #parrot
11:28 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32855), fulltest) at r45191 - Ubuntu 9.10 amd64 (g++ with --optimize)
11:41 dalek cardinal: f6213ec | fperrad++ | setup.pir:
11:41 dalek cardinal: refactor with inc_pir
11:41 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/f6213ec8e4b2c97585a125889b254623b0cf641a
11:46 lucian_ joined #parrot
11:46 whiteknight joined #parrot
11:48 lucian_ joined #parrot
11:49 whiteknight good morning, #parrot
12:17 GodFather joined #parrot
12:22 mj41 joined #parrot
12:37 mikehh joined #parrot
12:41 ruoso joined #parrot
12:42 theory joined #parrot
12:53 snarkyboojum joined #parrot
12:54 riffraff joined #parrot
13:11 Mokurai joined #parrot
13:12 payload joined #parrot
13:13 Mokurai1 joined #parrot
13:14 mikehh joined #parrot
13:14 atrodo joined #parrot
13:17 Austin joined #parrot
13:31 Austin Well, good morning parrot-nam!
13:42 ash_ joined #parrot
13:43 mikehh_ joined #parrot
13:54 davidfetter joined #parrot
13:59 mikehh_ joined #parrot
14:01 whiteknight good morning, Austin
14:02 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:03 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.
14:04 Austin 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:06 whiteknight wonderful
14:09 Austin So naturally, I'm going to go work on something else.
14:16 Coke ... there is something quite awesome about going to wikipedia.com to fact check something I'm putting on my resume.
14:17 Austin Heh
14:17 Austin "Coke's resume: as trustworthy as Wikipedia..."
14:18 Austin And I was worried about *me* getting some work this year..
14:19 khairul joined #parrot
14:21 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
14:22 ash_ whiteknight: http://blog.fallingsnow.net/2008​/05/23/simple-vm-jit-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
14:22 whiteknight yeah, I've read that
14:24 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
14:25 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?
14:25 lucian whiteknight: i'd google, but you can go on irc.freenode.net #pypy and ask
14:26 lucian 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
14:26 whiteknight ash_: Yeah, I think that's the way we are going. If lorito is separate, we can conceivably "plug" in other JIT backends
14:26 lucian whiteknight: from what i've heard/read, llvm is great but right now it's too focused on static languages
14:27 whiteknight lucian: depends what that focus means. At the lowest level, Parrot still compiles to normal machine code
14:27 whiteknight and machine code is not dynamic at all
14:27 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
14:27 lucian whiteknight: but pir is much more dynamic than that
14:27 whiteknight lucian: but PIR is written in C
14:28 whiteknight 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 #parrot
14:28 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
14:28 lucian whiteknight: dynamic languages need specialised versions of functions depending on argument types for example
14:29 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 whiteknight it would be a huge waste of time, but it wouldn't be any slower to execute
14:29 lucian whiteknight: if you left it dynamic, it wouldn't be any faster
14:30 lucian 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
14:30 lucian whiteknight: unless you restrict types of certain things
14:30 whiteknight that's where the savings are: large-scale optimization potential
14:30 lucian whiteknight: that would be possible if llvm understood perl/python objects
14:30 lucian whiteknight: i mean it's still possible, but llvm makes it harder
14:31 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
14:31 whiteknight and better yet, a good compiler could cache those pointers between calls, or do constant folding
14:31 lucian whiteknight: you better talk to people smarter than me about this
14:32 whiteknight the benefit of dynamic languages has never been performance. You can always write faster software in C
14:32 whiteknight the benefit to dynamic languages is more efficient use of developer time
14:32 lucian whiteknight: i know. but you want them to be fast, so you write a jit
14:33 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 whiteknight 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
14:34 whiteknight 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
14:34 Austin Mmmm..build rakudo with distutils
14:34 whiteknight and the only time JIT is faster is if the overhead of compilation is outweighed by long-term optimization savings
14:34 Austin I wonder how long *that* takes...
14:34 ash_ if a PIR op is simple enough it may be able to do things like inline the whole op dynamically, saving you overhead
14:34 whiteknight ash_: exactly.
14:34 lucian it may be possible that with a middle layer between C and a HLL you could achieve that
14:34 lucian but i'm sceptical
14:35 lucian 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
14:35 lucian i know what a jit does
14:36 lucian what i'm saying is that with llvm it's hard to build a fast jit for a dynamic language
14:36 lucian it's almost like writing a jit that generates C code and compiles that
14:36 lucian but with a smaller compilation overhead
14:36 whiteknight I don't see how it would be any harder, since all our code is already written in C
14:37 whiteknight 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
14:38 lucian 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
14:38 * lucian is looking for those links
14:38 * atrodo is curious as well
14:38 Austin Whiteknight: consider the case of an Integer.
14:39 Austin I write a sub in nqp:   sub bump($i) { $i++; }
14:39 Austin How does that go to llvm?
14:39 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
14:40 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.
14:40 whiteknight exactly
14:40 Austin But there's no type information available, so you don't get to assume it's an Integer pmc.
14:41 Austin 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++; }
14:41 whiteknight in this case, we can cache the value of the function pointer and inline it twice
14:41 Austin Yes...
14:41 Austin Nope.
14:42 whiteknight sure you can, the value of $i between those two is invariant
14:42 whiteknight and the value of $i->vtable between those two damn well better be invariant
14:42 Austin The value of $i is invariant. But the rest may not be.
14:42 whiteknight and $i->vtable->increment should be, etc
14:43 Austin But even if it *is* invariant, you still can't look inside the vtable function, except at runtime.
14:43 Austin *runtime  = execution time.
14:43 mj41_ joined #parrot
14:43 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.
14:44 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.
14:45 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.
14:45 Austin There are some solid arguments in favor of lorito. And they mainly involve the inferior runloop problems.
14:46 whiteknight Austin: yes, Lorito solves many issues besides JIT
14:46 lucian whiteknight: all i could find so far http://mail.python.org/pipermail/​python-dev/2004-April/044002.html
14:46 Austin But I don't see moving closer to the machine as any kind of performance improvement.
14:46 whiteknight in fact, I really think JIT is one of the least of it's merits
14:46 whiteknight the real benefit we get is that if everything is lorito we can completely avoid expensive context switching
14:47 whiteknight 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:48 whiteknight ...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.
14:49 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...
14:49 purl Message for fperrad stored.
14:49 ash_ brb changing classrooms
14:50 whiteknight I think we can cut PCC overhead down by half or more with some simplifications and cleanups to the system
14:50 whiteknight but that's off-tpic
14:54 atrodo Bizzare questions> can PMC change their vtable and basically become a different PMC mid stream?
14:54 ash_ joined #parrot
14:55 Coke es.
14:55 Coke "yes"
14:55 Coke see the C<morph> opcode.
14:56 Coke could let you implement "readonly", or perl's 'tie', or tcl's 'trace'
14:57 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 whiteknight it's certainly never used "well"
14:57 atrodo so in Whiteknight's doublebump example above, the vtable could change between the two operations?
14:58 whiteknight atrodo: "technically", yes
14:58 whiteknight but like I mentioned: nobody really uses morph and I suggest that nobody should
14:59 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?
14:59 Coke so, please don't go ripping stuff out. =-)
14:59 Coke (I am not sure if rakudo is using it but it would not surprise me at all.)
14:59 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
15:00 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.
15:00 whiteknight none of the core types implement working versions of morph, at least not as far as I am aware
15:00 dalek joined #parrot
15:01 Coke whiteknight: try assigning a string to a Float.
15:01 Coke (yes, that doesn't use either the morph vtable or the morph opcode)
15:02 whiteknight_ joined #parrot
15:02 Coke but there are uses of morph in src/pmc/* - and even if there were not... that doesn't mean it's removable.
15:03 Coke (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
15:03 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
15:03 lucian so you'd have to fix llvm on some points
15:03 lucian unladen swallow folk had to fix tail recursion for example
15:04 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:05 ash_ 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 :)
15:06 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:07 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.
15:08 Coke (it would increase memory usage by several pointers per tcl PMC, but that is probably noise compared to PCC)
15:09 lucian ash_: http://code.google.com/p/unlade​n-swallow/wiki/GarbageCollector
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.
15:10 lucian ash_: good, so you're smarter and more informed than me :)
15:10 Coke Hey, anyone want to review my resume? =-)
15:12 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 ash_ did unladen swallow ever get merged back into trunk python?
15:13 ash_ 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
15:14 lucian ash_: and some of their changes have been merged already
15:14 ash_ cool
15:24 patspam joined #parrot
15:25 mikehh_ joined #parrot
15:31 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:32 fperrad joined #parrot
15:33 fperrad purl ?
15:33 purl yes, fperrad?
15:33 fperrad ttbot ?
15:33 purl ttbot is TapTinder build bot owned by mj41 and reporting http://tt.taptinder.org/bui​ldstatus/pr-Parrot/rp-trunk build errors.
15:36 Andy joined #parrot
15:37 Coke heh. I saw the ttbot link and freaked out that the build was broken. =-)
15:50 mikehh_ joined #parrot
15:59 TiMBuS joined #parrot
16:10 mikehh_ joined #parrot
16:24 Psyche^ joined #parrot
16:43 cosimo joined #parrot
16:47 cotto_work fperrad, iwbn if ./setup.nqp help show the specific options available for a given project.  Is that planned?
16:48 cotto_work also, fperrad++ for the Rakudo setup.nqp
16:49 dukeleto 'ello
16:51 fperrad cotto_work, already exist with :
16:51 fperrad usage => "your own message"
17:02 whiteknight joined #parrot
17:12 mikehh_ joined #parrot
17:15 dalek rakudo: 4a5a252 | moritz++ | src/core/operators.pm:
17:15 dalek rakudo: fix infix:<Z> to work with non-lists, as suggested by jnthn++. Fixes RT #73836
17:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​a5a252df1d31c372424b175b92c31fe1f84a3ae
17:29 jan joined #parrot
17:33 dukeleto if anyone in here would like to register as a Mentor for this years Google Summer of Code, please go to http://socghop.appspot.com/ and apply to be a mentor for TPF. I will then accept it :)
17:36 cotto_work done
17:40 dukeleto cotto_work: accepted
17:41 payload joined #parrot
17:41 cotto_work acceptance accepted
17:43 contingencyplan joined #parrot
17:49 Coke what, the organization code isn't "dukeleto" this year!?
17:49 atrodo It should be
17:49 darbelo It makes you show up higher in the sorted list.
17:50 darbelo Now you're all the way down there with the other T's
17:52 whiteknight dukeleto: applied
17:55 dukeleto whiteknight: accepted
17:55 whiteknight w00t!
17:55 whiteknight ...and the teachers in highschool said I would never amount to anything
17:58 dukeleto whiteknight: we don't need no education ..... teachers! leave them kids alone!
17:59 whiteknight you can't have any pudding if you don't eat your meat!
18:00 whiteknight I can't wait till the proposals start coming in. I think we are going to have some nice ones
18:03 bermie joined #parrot
18:03 dukeleto whiteknight: indeed. much thanks to you and your many good gsoc ideas blog posts
18:03 dukeleto whiteknight++
18:05 whiteknight They aren't my ideas. I just write them on the blog
18:09 khairul hi, i wrote to the dev list a couple of days ago regarding implementing an instrumentation framework for parrot.
18:09 khairul i've written up a more detailed proposal at http://www.mangkok.com/parrot/parrot_proposal.pdf .
18:09 khairul i'd appreciate it if i can get more feedback on it.
18:13 dukeleto khairul: i will take a look. it would be good to mail the list again with that link
18:14 joeri joined #parrot
18:14 khairul dukeleto: thank you. i'll do it tomorrow when i'll have a bit more to add.
18:15 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:17 khairul dukeleto: thank you, i'll keep that in mind
18:17 cotto_work hi khairul
18:17 dukeleto khairul: if it is possible to figure out "who calls this method on this object", that would be valuable
18:17 cotto_work I was hoping you'd show up here.
18:18 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
18:19 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
18:19 dukeleto khairul: that would be awesome!
18:20 dukeleto 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.
18:21 dukeleto khairul: also, a trigger for PMC creation would be very valuable
18:22 dukeleto khairul: ah, i just got the to timeline in the PDF :)
18:22 dukeleto khairul: yes, a few sentences for each week would be preferrable
18:22 whiteknight khairul: Do you have a general list of hooks you are planning to implement?
18:23 dukeleto whiteknight: yes, some are listed in the PDF
18:23 khairul whiteknight: generally, the list of hooks are those listed under proposed triggers
18:23 whiteknight hmmm...I don't think I saw a PDF
18:23 dukeleto khairul: in general, the proposal is looking strong. It is very good that you are starting early. That is a very good sign.
18:23 dukeleto whiteknight: http://www.mangkok.com/parrot/parrot_proposal.pdf
18:23 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.
18:23 whiteknight dukeleto++
18:24 khairul dukeleto: thanks for the encouragement.
18:24 cotto_work khairul++
18:24 khairul cotto_work: i'll keep that in mind
18:24 whiteknight dukeleto: some of these hooks look like they would be extremely interesting for security sandboxing
18:24 dukeleto khairul: yes, comparison to the profiling runcore would be very useful.
18:24 dukeleto whiteknight: yes indeed, i thought the same
18:25 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.
18:25 cotto_work dukeleto++ made me legit recently
18:25 khairul yea, i saw. thanks for the offer
18:25 PacoLinux joined #parrot
18:25 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:26 whiteknight so you can do lookups with VTABLE_find_method
18:26 khairul there's actually a few ways i was considering doing.
18:26 khairul one is by scanning, as done in the proof
18:26 khairul another is by PMC
18:26 cotto_work I love gsoc season.
18:26 khairul and last is by NCI
18:27 khairul i'll need to look into each of those
18:27 khairul so, thats why i put 1 week to prototype API
18:28 chromatic joined #parrot
18:28 whiteknight khairul: do you plan to do this work in the parrot repo directly, or start a separate project?
18:29 khairul i'm not sure. it can be either i suppose.
18:33 dngor joined #parrot
18:34 * particle suggests a branch in the parrot repo
18:34 particle we can help keep it close to trunk
18:35 particle however, a git branch based on dukeleto's parrot git mirror may be easier to work with
18:37 dukeleto khairul: i think you may want to look at using a dynpmc
18:38 whiteknight dukeleto: we don't have support yet for pluggable runcores
18:38 whiteknight 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
18:38 dukeleto whiteknight: yes, indeed
18:38 dukeleto whiteknight: what stands in the way up pluggable runcores right now?
18:39 whiteknight just hasn't been implemented, to my understanding
18:39 whiteknight cotto and chromatic have done all the necessary encapsulation and prettification wok
18:39 chromatic We needed pluggable runcores to make the profiling runcore work, but we didn't need dynloadable runcores so we didn't implement that.
18:40 whiteknight right, there wasn't a use-case until now
18:40 whiteknight arguably we could just jam this thing into trunk
18:40 whiteknight we have to figure out as a community how we want to handle it
18:40 cotto_work yes
18:41 dukeleto whiteknight: shall we make a new ticket for dynloadable runcores?
18:41 cotto_work +1
18:41 purl 1
18:41 whiteknight +1
18:41 purl 1
18:44 cotto_work +one
18:44 purl 1
18:44 cotto_work +two
18:44 purl 2
18:44 cotto_work +seventy five
18:44 cotto_work +seventy-five
18:44 cotto_work stupid bot
18:44 purl Bad programmer, no cookie!
18:44 cotto_work dtwt
18:45 khairul lol
18:45 khairul i'm going to call it a night, its almost 3 am here.
18:45 khairul thanks for all the suggestions.
18:45 cotto_work what's your timezone
18:45 cotto_work night
18:45 khairul +8 GMT
18:45 cotto_work nm.  singapore
18:45 khairul yep
18:46 khairul i'll update my proposal tomorrow then with your suggestions.
18:46 khairul thanks and good nite/morn/aft.
18:49 ash_ joined #parrot
18:50 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
18:50 cotto_work Yeah.  I'm excited.
18:50 whiteknight I do wonder if it will fill a whole summer, considering how capable his proof-of-concept is already
18:50 cotto_work That too.
18:51 cotto_work Maybe we should make him implement pluggable runcores to pad it out a bit. ;)
18:51 cotto_work s/pluggable/dynamically loadable/
18:51 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
18:51 whiteknight dukeleto: yeah, in my case the code took up less than half
18:51 dukeleto whiteknight: a project that takes less than a summer is much better than one that take a lot longer
18:52 dukeleto whiteknight: one is called passing, the other failing :)
18:52 whiteknight debugging and cursing at the computer took the other half
18:52 dukeleto whiteknight: as it should :)
19:22 * Coke ponders blocking out time for YAPC.
19:26 cotto_work We still need to get a yay+time or nay on another PVMW
19:27 cotto_work I'd have booked my tickets long ago if not for that.
19:33 whiteknight I'm going to miss yapc this year
19:33 whiteknight was a lot of fun last year
19:34 chromatic You'll never wash your car again.
19:34 whiteknight I don't think I have
19:34 whiteknight I put the child seat where Larry was sitting so it will be protected forever
19:35 whiteknight or, at least until the kid turns 5
19:36 cotto_work You could bring your get.  Get him started early.
19:36 cotto_work s/get/kid/
19:37 whiteknight drool + keyboards don't mix well
19:37 chromatic Neither does powdered sugar.
19:37 cotto_work There's a keyboard for that.
19:37 atrodo Am I reading this right that YAPC is in Columbus?
19:38 whiteknight chromatic: that may be, but I refuse to give up my donuts
19:38 whiteknight the kid can be left with relatives for a weekend, but donuts are forever
19:39 whiteknight atrodo: I believe so
19:39 atrodo Hmmmm, I may have to think about attending
19:39 whiteknight when do we find out where YAPC will be in 2011?
19:40 whiteknight because if it's Pittsburg or anywhere further east, I will come
19:40 whiteknight further than that, and my probability decreases
19:40 dukeleto i think we should have a Parrot Dev summit this year
19:41 whiteknight that would be nice
19:43 Coke Austin: how do you break out of a loop in nqp-rx?
19:43 whiteknight He added a "last" keyword, methinks
19:44 whiteknight http://www.gitorious.com/kakapo/kakap​o/blobs/master/src/Syntax.nqp#line19
19:46 Coke danke.
19:47 whiteknight Coke: you using Kakapo?
19:48 muixirt joined #parrot
19:48 muixirt hi
19:50 Coke whiteknight: nope.
19:50 Coke but I already have tcl's break() which does pretty much the same thing, so I'll use that for now.
19:50 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?
19:52 Coke whiteknight, Austin : see anything wrong with this line:
19:52 whiteknight muixirt: no, not really
19:52 Coke pir::chopn__vsi $string, 1;
19:52 Coke ARGH.
19:52 Coke (the parens.)
19:52 whiteknight muixirt: everything is an INTVAL, to sort of make the programmer less aware of the limitations of the hardware
19:53 whiteknight muixirt: I'm sure something could be written up very quickly if you needed something better
19:54 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
19:55 Austin Coke: You throw a control exception. Kakapo calls it 7 last()
19:57 whiteknight muixirt: do you have a need of a way to specify a bytesize?
19:58 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
19:59 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
19:59 whiteknight muixirt: I think it would be relatively easy to put together a dynpmc library with a variety of fixed-size types
19:59 plobsing muixirt: if there is a dire need for smaller (or possibly larger) int types, a ManagedStruct could be made to work
20:00 whiteknight ah, ManagedStruct could work, yes. Would not be pretty
20:00 plobsing and wouldn't deal *well* with larger int types
20:00 Coke Austin: pir::chopn__vSi($string, 1) doesn't actually chop $string.
20:00 whiteknight would probably just be easier to put together a quick dynpmc library. Maybe I'll throw one together tonight or tomorrow
20:01 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)
20:01 Austin Heh.
20:01 Austin Which is why you might want the SSI version.
20:01 Austin $string := pir::chopn__SSI($string, 1)
20:01 whiteknight Coke: that does't sound good. File a bug report?
20:01 Coke .. even though there isn't a chopn_s_s_i opcode?
20:01 Austin inline op chopn(out STR, in STR, in INT) :base_core {
20:02 Coke ... dammit.
20:02 Coke I mean, thank you!
20:02 Austin line 77, string.ops
20:02 Austin whiteknight: It's not a bug, per se.
20:03 Austin NQP will "make" a string ($S0) out of the PMC $string, and then pass that to chopn.
20:03 Austin But that won't affect the original PMC...
20:03 whiteknight oh, maybe I misread what coke said
20:04 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
20:04 Austin :)
20:05 Austin PIR has evolved in a language that really is better for hand coding than compiling.
20:05 Austin So last night one of my fillings escaped.
20:06 Austin I just got back from the "NASCAR dentist"
20:06 Coke Austin: that sucks.
20:06 purl The rock is now off.
20:06 Austin I swear I'm not in the chair 7 seconds before he starts with "That 'uns got to come out..."
20:06 Coke austin; if you're bored, you could probably remove Q:PIR from this file. =-)
20:06 Coke http://github.com/partcl/partcl-nqp/blo​b/master/src/Partcl/commands/string.pm
20:06 Austin And then out comes the "big pocking wrench"
20:07 Coke ... were you given a chance to veto?
20:07 Austin Dude, WTF is that?
20:07 Coke wtf is what?
20:08 Coke my url?
20:08 Austin A 373 line function?
20:08 Austin Even my enormous monitors, in vertical orientation, cannot accomodate your enormous should-be-a-switch-but-isn't ...
20:09 payload joined #parrot
20:09 Coke it's implementing (part of) http://www.tcl.tk/man/tcl8.5/TclCmd/string.htm
20:09 davidfetter joined #parrot
20:10 Austin Heh
20:10 Coke Hey, if you want a commit bit and wish to go crazy, I'm happy with that. =-)
20:11 Austin What does the select_option function do?
20:11 Austin Is this one of those "just type enough to identify the command" things?
20:11 Coke yes!
20:11 davidfetter oh hai
20:11 Coke OH HAI
20:11 Coke Austin: tcl is fun! especially when written in nqp-rx!
20:12 * Austin quotes, "The first thing I'm gonna do when I get to California, is punch John Osterhout right in the mouth!"
20:12 Austin Is it John?
20:12 Coke yes. =-)
20:12 Coke nice guy, please don't do that. =-)
20:12 Coke I'd hate to start some kind of bloods/crips thing with him and larry.
20:12 davidfetter well, you could hurt your fist on his teeth
20:12 Austin Pssh
20:13 dalek joined #parrot
20:13 Austin Larry ain't in it. He's doing Electric Commander, now - he's in my field.
20:13 Austin But that "you don't really have to type the whole keyword if you don't want to" stuff went out with Commodore basic...
20:14 Coke it's still in the most recent tcl. <shrug>
20:14 Coke I'm just an implementor, not a designer.
20:14 Coke and that part's already written. you wouldn't have to touch it!
20:15 Austin github--
20:15 Austin Show the damn url...
20:15 davidfetter so i have this awful question
20:15 Coke git@github.com:partcl/partcl-nqp.git ?
20:15 Austin Yeah, I'm cloning it now.
20:15 Coke WHEE
20:15 Coke commit bit? (same terms as parrot)
20:16 Coke I trust you not to break anything. =-)
20:16 davidfetter o/` when you're a kid, and you wanna go weeeeee o/`
20:16 Austin Don't you depend on the C compiler?
20:16 Coke for partcl, yes. partcl-nqp doesn't have any pmcs yet.
20:16 Coke trying to see if I can avoid them.
20:16 Austin Ahh
20:16 Austin Good for you.
20:17 Austin You know anything about multi-sub dispatch?
20:17 Coke enough to use it, occasionally.
20:17 Austin Heh. Me too.
20:17 Austin But now I've got a problem.
20:17 davidfetter so about the parrot code...is everything handled under a CLA?
20:17 Coke CLA?
20:17 purl i heard CLA was Contributor License Agreement or http://www.perlfoundation.org/​contributor_license_agreement or http://www.parrot.org/foundation/legal or http://www.parrot.org/files/parrot_cla.pdf
20:18 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:19 Austin 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:20 Coke Austin: can you duplicate the error without the tramplines?
20:20 Coke *O*
20:20 Austin No.
20:20 Austin If I put the trampoline code into a .pir file with a bunch of dummy hooks, everything works okay.
20:20 Austin I think it has something to do with the dynamic compilation.
20:21 Coke do you do the dynamic compilation in the same scope as the compilation of the scope of the invocation?
20:21 Austin Scope?
20:21 purl somebody said Scope was same.
20:21 Coke (I would expect the multi stuff to figure the dispatch at runtime, not compiletime, though.
20:22 Austin Me too. I've got .namespace directives in the compiled code.
20:22 Austin And it's finding *one* of the subs. Just the wrong one.
20:22 Coke if you can write up a short code snippet and open a ticket, I can take a look. (no promises)
20:23 Austin Hell, if I could write up a *short* code snippet, I wouldn't have a problem.
20:23 Coke mmhehe
20:23 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 #parrot
20:27 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?
20:28 Coke http://github.com/partcl/partcl-n​qp/blob/master/src/options.pm#L45
20:28 Coke (yes, it handles it.)
20:29 dngor joined #parrot
20:29 pmichaud Austin: I haven't had any experiences like what you describe.
20:30 Austin pmichaud: Neither have I :(
20:34 davidfetter CLA as in contributor license agreement
20:35 davidfetter ("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.
20:37 Austin Why would you need to do that, Tene?
20:37 Tene Hmm.  Maybe I'm misremembering.
20:37 davidfetter so about the CLA, i've run across something in pl/parrot that might lead to my asking for another license for parrot :/
20:37 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?
20:38 Coke davidfetter: yes, i was giving you the URL to the cla. =-)
20:38 Coke Austin:             @args.shift; # assuming -nocase here.
20:39 Coke it's a todo, yah.
20:39 Austin Should it just do a plain old cmp?
20:39 davidfetter Coke, thanks. looks like it has what we'd need :)
20:39 particle davidfetter: email parrot-directors@lists.parrot.org about that
20:40 davidfetter particle, thanks :)
20:40 Coke Austin: in the case of not -nocase?
20:40 Austin right
20:40 Austin And, should I validate -nocase in any way, or is 3 args enough of an indicator?
20:41 Coke Austin: there's a much more complete PIR-based implementation in partcl's partcl project, in runtime/builtin/string.pir
20:42 Coke and the docs for [string] are at the tcl.tk URL I posted previously.
20:42 Coke (and a bunch of tests just out of reach in t/cmd_string.)
20:42 Coke and thank you!
20:42 Coke =-)
20:43 lucian joined #parrot
20:47 Coke that was the long version. the short version is "yes, you have to validate, because there's more than just -nocase)
20:54 nopaste "Austin" at 68.39.12.202 pasted "Some progress" (59 lines) at http://nopaste.snit.ch/20109
21:00 Coke Austin: woot.
21:01 Austin my sub equal(*@args) {
21:01 Austin compare(|@args, :op_name<equal>) == 0;
21:01 Austin }
21:03 particle 289+91+30
21:03 purl 410
21:03 particle 15*7
21:03 purl 105
21:05 Coke Austin: still need to do the args checking.
21:05 Coke (and insure that the sub-sub names don't bleed out to user-visible land.)
21:06 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.
21:06 Coke Austin: wrong args checking.
21:06 Austin -nocase -length int ?
21:06 Coke what if someone says [string equal a b c d e f g] ?
21:06 Austin Fails.
21:06 Coke wrong # args: should be "string equal ?-nocase? ?-length int? string1 string2"
21:07 Austin [ -nocase ] [ -length int ] a b
21:07 Austin Right
21:07 Coke does yours say "equal" or "compare" ?
21:07 Austin It says "$op_name"
21:07 Austin :)
21:07 Coke wfm.
21:08 Austin What does $haystack.getIndex() do?
21:08 Coke converts a tcl-style index into a parrot-style index.
21:09 Austin Oh, boy.
21:09 Coke so, "end-1" is "whatever the length is minus one"
21:09 Coke there's similar indexing on lists & strings.
21:09 Austin So "end - 1" is [-2] ?
21:09 Coke ... yes. except since I already know the length at that point, I just use positive #'s.
21:10 Austin Okay. I think I'm going to just give that code a pass for now.
21:10 Coke here's the valid indices:
21:10 Coke http://www.tcl.tk/man/tcl8.5/TclCmd/string.htm#M9
21:10 Austin Yeah, I saw them.
21:11 Coke (yes, end+20 is a valid index.)
21:11 Austin I just didn't make the connection ...
21:11 Austin Sure, but what does it do?
21:11 Austin The web page suggests that end-1 and end+1 are the same.
21:11 Coke no, end-1 and end+-1 are.
21:11 Austin Ahh, yeah
21:11 Austin Missed the -
21:12 Austin So what does end+1 return?
21:12 Coke end+1 is after the end, and string index would return empty string there.
21:12 Austin Segmentation fault, core dumped?
21:12 Austin Hoo.
21:12 Coke ->
21:12 Austin Walking a mile for negative numbers..
21:12 Coke (have fun.)
21:20 dalek parrot: r45192 | petdance++ | trunk/src/dynpmc/gdbmhash.pmc:
21:20 dalek parrot: consting
21:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45192/
21:24 Austin Coke: What's with the parrot-revision thing?
21:35 darbelo Austin: set it to 0 and you'll be fine.
21:36 Austin darbelo++
21:36 Austin wfm
21:37 darbelo It enforces a minimum svn rev. But releass don't report a svn rev, so...
21:41 * Austin sings, "Never be rude to an Irishman, no matter what you do..."
21:48 Austin Coke: when trimright says "whitespace is removed (spaces, tabs, ...)" do I take it literally, or do I trim off unicode whitespace?
21:52 Austin literally, I guess.
21:56 AndyA joined #parrot
22:21 sorear joined #parrot
22:26 riffraff joined #parrot
22:29 tcurtis joined #parrot
22:35 kid51 joined #parrot
22:54 tcurtis joined #parrot
23:23 ruoso joined #parrot
23:52 hercynium joined #parrot
23:54 dngor joined #parrot

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

Parrot | source cross referenced