Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2008-10-07

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

All times shown according to UTC.

Time Nick Message
14:02 davidfetter joined #parrotsketch
15:50 tewk_ joined #parrotsketch
16:35 Wknight8111 joined #parrotsketch
17:04 jhorwitz joined #parrotsketch
17:17 cotto joined #parrotsketch
17:48 PacoLinux joined #parrotsketch
17:48 kj joined #parrotsketch
18:04 pmichaud joined #parrotsketch
18:05 moritz joined #parrotsketch
18:22 NotFound joined #parrotsketch
18:27 allison joined #parrotsketch
18:29 rurban joined #parrotsketch
18:30 moritz hi
18:30 rurban hi!
18:30 cotto hi!!
18:30 chromatic joined #parrotsketch
18:30 NotFound H
18:30 particle hi-o
18:30 Wknight8111 hello
18:30 kj hiya
18:31 jhorwitz hi
18:31 chromatic good $localtime
18:32 allison hi
18:33 Tene Hi Allison!
18:33 allison hi tene
18:33 TimToady joined #parrotsketch
18:33 chromatic Shall we begin?
18:34 moritz aye
18:34 chromatic allison?
18:35 chromatic chromatic?
18:35 chromatic I fixed a couple of bugs, and I increased the warning level locally for type conversions in C code.
18:36 chromatic I want to be somewhat stricter about type widths and signedness, so I fixed some conversions in IMCC and am working through PMCs.
18:36 chromatic There are some questions about auxiliary functions called from ops that we should eventually resolve.
18:36 chromatic I'll poke at any bugs or crashes that block anyone, if you let me know.
18:36 chromatic EOR
18:36 chromatic cotto?
18:36 cotto * have PhpArrays mostly implemented
18:36 cotto * working on making iterators play nice
18:36 cotto * iterators, stringification (var_dump, print_r, etc) and general cleanup are all that remain to be done
18:36 cotto * queue 2 questions
18:36 cotto StopIteration
18:36 chromatic japhb?
18:38 chromatic allison?
18:38 allison - I merged the pdd27mmd branch into trunk. This is a significant cleanup of the multiple dispatch subsystem, merging two (conflicting) MMD subsystems into one.
18:38 allison - Fixed language test failures before and after the merge. A few more left.
18:38 allison - Created a branch for a cleanup of the calling conventions. Andrew Whitworth will be doing some work on this, continuing work we started in the multiple dispatch branch.
18:38 allison - Also starting a branch for the I/O milestone (the next on the list). The primary part of this milestone is shifting I/O over to being a regular object, instead of the old "layers" implementation.
18:38 allison EOR
18:38 chromatic jhorwitz?
18:39 jhorwitz segfault in #58368 continues to be a blocker for mod_perl6.  narrowed it down to the PAST generation phase, but can't get much further than that.  if we can fix this in time for the workshop this weekend, beer will be distributed.  :)
18:39 jhorwitz began work on binding mod_parrot interpreters to connections, which is necessary in a threaded apache mpm to preserve state across the entire request lifecycle.
18:39 jhorwitz EOR
18:39 chromatic kj?
18:39 particle jhorwitz++
18:40 kj == work on pirc:
18:40 kj * fixed some parsing issues; most seem to be resolved now.
18:40 kj * 3 major tasks left (in pirc/new) are:
18:40 kj - convert all LABEL operands into offsets (integer constants)
18:40 kj - convert keylists, such as ['a';'b'] into PMC constants
18:40 kj .eor
18:40 chromatic moritz?
18:40 moritz Nothing interesting to report, just usual testing stuff.
18:40 moritz EOR
18:41 chromatic NotFound?
18:41 NotFound * more pirric improvements
18:41 NotFound * reviewing some old tickets, closed a few
18:41 NotFound * fixing some bugs
18:41 NotFound * queue one question
18:41 NotFound EOR
18:41 chromatic particle?
18:41 particle yay! finally some hacking time, after too long without any
18:41 particle mainly because i got my msdn subscription
18:41 particle i have the latest tools now running (microsoft++)
18:41 particle rakudo:
18:41 particle ~ added <apostrophe> and <identifier> tokens to grammar
18:41 particle ~ added 'package' declarator
18:41 particle ~ added $*OS, $*OSVER, $*EXECUTABLE_NAME (azawawi++ for initial code)
18:41 particle ~ some refactorings and other cleanups
18:41 particle parrot:
18:41 particle ~ fixed a few bugs, applied some patches from contributors
18:41 particle .end
18:42 chromatic pmichaud?
18:42 pmichaud ** Rakudo spectest_regression: 205 files, 4363 passing, 74 failing
18:42 pmichaud == PCT stuff
18:42 pmichaud : Worked with Tene++ to get rid of legacy 'Foo::Bar' classnames in Parrot
18:42 pmichaud : Everything in PCT (including PGE) is moving to ['Foo';'Bar'] form internally
18:42 pmichaud == Rakudo stuff
18:42 pmichaud : answered questions about package, 'is export', compiler variables, etc.
18:42 pmichaud : 74 failures in spectest_regression are primarily due to Complex PMC issues
18:42 pmichaud .end
18:42 chromatic rurban?
18:42 rurban allison++
18:42 rurban rurban's report:
18:42 rurban * I'm live at the frankfurt.pm meeting. They are all saying hi!
18:42 rurban * Released parrot-0.7.1 for parrot and updated pdd30_install branch with the new findings.
18:42 rurban * One remaining problem with tools/dev/install_files.pl then I can merge. Simply files overwriting each other. No ticket yet.
18:42 rurban * 1 q
18:42 rurban EOR
18:42 chromatic Wknight8111?
18:42 Wknight8111 * Added lots of function-level documentation to files that needed it.
18:42 Wknight8111 * Looking over more of the calling convention stuff, preparing to work on that.
18:42 Wknight8111 * Not a lot of time for much else yet.
18:42 Wknight8111 EOR
18:42 chromatic Did I miss anyone?
18:43 Tene Me!
18:43 chromatic My apologies; go ahead.
18:43 Tene * Blocks are based as named positions instead of positional to functions in cardinal
18:43 Tene * All blocks accept an optional block argument in cardinal
18:43 Tene * Little bit of work on control exceptions in PCT
18:43 Tene * Lots of progress with pmichaud++ on migrating everything to use ['real';'parrot';'namespaces'] instead of 'Fake::Namespaces'
18:43 Tene * Curry  is delicious
18:43 Tene KTHXBAI
18:43 chromatic cotto, you had a question.
18:43 cotto Allison, you suggested a change to some code that depended on the old mmd_dispatch_* function.  I changed some phparray code to use VTABLE_cmp before I saw your post, and it seemed to work fine.  When should one vs. the other be used?
18:44 allison A direct vtable call is fine.
18:44 allison In fact, a direct vtable call is preferable
18:44 allison because it allows an individual PMC to do single dispatch instead of the default multiple dispatch
18:45 allison (a good speedup for frequently used vtable functions like 'cmp')
18:45 allison The multiple dispatch versions are in the 'default' PMC's implementations of the vtable functions.
18:46 allison So, they'll only be called in PMCs that don't implement the vtable function.
18:46 allison EOA
18:46 chromatic cotto, next question.
18:46 cotto In PHP, arrays of the same size with different keys are not considered comparable, and such a comparison returns null.
18:46 cotto Since the cmp VTABLE only returns an INTVAL, would it be a good idea to throw an exception so the HLL code can catch it and return the expected null?
18:46 cotto If so, should I add something like EXCEPTION_ARRAYS_NOT_COMPARABLE to include/parrot/exception.h
18:46 cotto eoq
18:47 allison so, arrays of the same size with different keys return a different "not equal" value than other comparisons?
18:47 cotto yes
18:49 cotto I know
18:49 allison So the PHP comparison operator or function is a wrapper around the bare parrot cmp, and will handle returning the different values.
18:50 cotto that's what I was thinking
18:50 allison you could do it by throwing an exception from within CMP, but that might cause problems for any other language using PHP's arrays, because PHP doesn't throw an exception on that condition
18:50 cotto (see example #1 http://us.php.net/manual/en/lan​guage.operators.comparison.php)
18:50 allison we have talked about creating variants of the basic integer-returning 'cmp' vtable functions that return a PMC instead
18:51 allison cmp_pmc, or something like that
18:51 cotto That'd solve the problem nicely
18:51 allison which could then return PMCNULL
18:51 allison (or if they're equal, a PMC boolean value)
18:52 allison write a patch for that, and we'll review it on the list
18:52 cotto ok.  Thanks.
18:53 allison (likely pretty simple, touching src/vtable.tbl and src/pmc/default.pmc, plus your PMCs)
18:53 chromatic NotFound, you have the next question.
18:54 NotFound I'm testing a way to get rid of string_cstring_free by using a pmc that takes care of free the C string when garbage collected.
18:54 NotFound The question is if this will be a good design.
18:54 allison what are the advantages of making it a PMC over just using a Parrot string?
18:54 NotFound This is whay I have done: http://nopaste.snit.ch/14245 The PMC, a helper function, and some usages
18:55 chromatic pinnable
18:55 allison strings are pinnable
18:55 NotFound Parrot string is already too complex IMO
18:56 allison I'm not arguing against it, it's just a straight question of where and why we'd use the PMC instead of a Parrot string
18:57 allison if there are enough reasons, then it's a worthwhile addition
18:57 NotFound string have no vtables, use for this purpose will require access to string internals.
18:58 allison NotFound: right, we'll be simplifying the strings implementation in the strings milestone, but I didn't mean adding more code to strings, I meant just using the existing strings
18:58 allison use for what purpose?
18:58 NotFound The intended usage is just to store the C string and free it when garbage collected
18:59 NotFound Avoid memory leaks on exceptions before the strinc_ctring_free
18:59 chromatic How is that different from what Parrot_string does now?
18:59 allison where do you store the PMC that stores the C string?
18:59 pyrimidine joined #parrotsketch
19:00 NotFound In cases I tested, in any part. They are all short life.
19:01 allison NotFound: It sounds like you've spent some time thinking through this already, while we're just jumping into the idea mid-stream.
19:01 allison NotFound: Take some time to write up an email for parrot-dev.
19:01 allison NotFound: The you can describe the problem, and why this is a good solution for the problem.
19:02 NotFound This is another question I have: what will be the way to store temprary PMC when the function call things that possible can enter a runloop?
19:02 NotFound Pushing a context will be fine?
19:02 chromatic In theory, stack and register scanning will find it.
19:02 chromatic CPU register scanning, that is.
19:02 NotFound We do that thing?
19:03 allison NotFound: is this a temporary PMC only used within C code?
19:03 Wknight8111 In theory, I wouldn't rely on our current stack and register scanning capabilities
19:03 NotFound allison: yes
19:04 allison NotFound: that's dod_register_pmc and dod_unregister_pmc when you're done
19:04 NotFound allison: but we can unregister if some thing called throws.
19:04 NotFound can't
19:04 allison it's exactly the same problem as freeing C strings, yes
19:05 allison but, that's unavoidable
19:05 Wknight8111 What if we maintained a separate registry for objects that are temps and need to be cleared if there is a throw?
19:05 NotFound I was thinking about using a context: creatng it, frreing it if all goes well, and let the exception system take care otherwise.
19:06 Wknight8111 like a dod_temp_register_pobj, etc
19:06 NotFound I mean, pushing and popping, not creating and freeing
19:06 chromatic Attaching temps to a context makes fair sense to me.
19:06 allison still the same problem, how do you free the context if an exception is thrown and you never return to this bit of code?
19:06 chromatic Don't non-resumed exceptions unwind the context graph?
19:07 NotFound chromatic: that is I was wondering.
19:07 allison chromatic: if an exception handler is invoked, it will modify the context stack
19:08 allison but, presumably this context isn't on the stack, otherwise it would mess up the execution order
19:08 chromatic As soon as a context is unreachable, it should get cleared.
19:08 NotFound allison: I explained bad, the ida is to use push_context and pop_context
19:08 allison but contexts aren't PMCs (yet)
19:09 chromatic We don't leak contexts now, so I assume that *something* clears them.
19:09 allison NotFound: okay, if you're doing that it will cause problems, because an exception handler only stupidly pops the context, it won't know to pop your extra context
19:10 Wknight8111 do we know that we don't leak contexts? Maybe they've never been used in the way NotFound is thinking
19:10 allison chromatic: yes, they're pushed and popped through the flow of executions
19:10 allison ideally (this is a partial patch not yet committed) contexts will be PMCs
19:11 allison stored in the linked list of continuations for CPS
19:11 allison and then they will be garbage collected when unreachable
19:12 NotFound Then we have the same problem of premature mortality if we create a context attached to nothing.
19:12 allison but, that doesn't give leeway for an extra place to store "internal" PMCs
19:12 chromatic Why?  I can see why a context could represent the context into C code.
19:13 allison but where is the context stored so it'll be reachable for GC mark?
19:13 allison it's not associated with a continuation, because it's not part of the control flow
19:13 chromatic Why is it not part of the control flow?  Control has already flowed to it.
19:14 NotFound If we use push and pop, is a part of a chain while it exists. I assume this chain is marked.
19:14 Wknight8111 If you want to mark a PMC live, use pobject_lives. That will spare it through the next GC cycle
19:14 allison it's an extra context, created to store extra variables
19:14 chromatic If you're calling into non-Parrot C code and you don't have multiple interpreters, you're not going to run GC until that C code returns.
19:14 Wknight8111 keep it alive when you are using it, and after a throw, nothing will be keeping it alive anymore
19:14 allison Wknight8111: yes, but that'll only last until the next GC cycle, so not reliable
19:15 chromatic If you're calling into non-Parrot C code and you do have multiple interpreters, you have to anchor the current context somehow anyway.
19:15 NotFound Wknight8111: but if we call a function that maybe enter another runloop, we don't know how many GC cicles he must survive.
19:15 allison NotFound: right
19:15 NotFound And if we have a multithreaded GC; even worse
19:15 allison okay, <pause>
19:16 allison let's take this to the mailing list
19:16 allison definitely important questions here
19:16 chromatic rurban, you had a question.
19:16 rurban May I merge pdd30_install? At first with my suggested layout variant 1, which is in the branch and has the least needed changes, but we can change it later.
19:16 rurban and my battery is running out in 15min
19:16 allison rurban: it needs a code review, but potentially yes
19:17 NotFound Ups, forget one question (is short, I promise)
19:17 chromatic kj has the next question.
19:17 rurban who will over it?
19:18 rurban look over it
19:18 allison rurban: IIRC from looking at it before, it involved some design questions, so I should look it over
19:19 allison rurban: I can do that quickly tonight, and let you know if there are things we need to talk through further
19:19 rurban ++
19:19 allison has it been kept in sync with trunk?
19:19 allison or, should I do an update from trunk?
19:19 rurban tommorrow
19:20 allison tomorrow?
19:20 rurban promised
19:20 allison not following. you mean you'll do an update from trunk tomorrow?
19:21 rurban I'll prepare the merge tomorrow to tomorrows trunk
19:22 allison okay, let's talk tomorrow
19:23 chromatic kj?
19:23 kj alrighty, my question is not so complex:
19:23 kj My question consists of 2 subquestions, a and b:
19:23 kj 1.a: Some Parrot ops do not exist, but are faked. For instance, the opcode add_i_ic_ic (e.g. add $I0, 2, 3) is in IMCC replaced by 'set_i_ic'.
19:23 kj I understand this was a design decision, as this saves # of ops (which is fine), but I wonder how far this should be taken. AFAICT, the same is done
19:23 kj for 'lt_ic_ic_ic', e.g. 'lt 10, 20, L1': jump to L1 if 10 is less than 20; in other words, always jump to L1.
19:23 kj While I can see the usefulness of 'add_i_ic_ic', I wonder to what extent the same trick should be used for non-math ops (as it is currently done for lt),
19:23 kj as it add complexity to the PIR compiler (whether that be IMCC or PIRC)
19:24 allison maybe just a little complex ;)
19:24 kj well, long, yes; not complex :-)
19:24 * pmichaud has a Complex question.  :-)
19:24 kj :-)
19:25 kj Basically, IMCC (and I'm working to implement that in pirc) fakes some instructions, so that it allows 'instrucitons' that don't exist
19:25 NotFound BTW, actually the machanic used to implement that things force a change in optimization level
19:26 kj my question is: to what extent is this desirable? I think, if the instruction does not exist, then the compiler (writer) should not generate it.
19:26 kj (or the PIR programmer should not use it)
19:26 allison kj: I've just ripped out a large number of "fake" instructions and replaced them with real opcodes in the MMD branch
19:26 NotFound Or we must create it
19:26 pmichaud speaking from the code generator perspective....
19:27 allison I'm not a huge fan of making fake instructions
19:27 pmichaud assuming I have an AST node where the operation is "add" and the operands are two constant nodes
19:27 kj so, for instance add_i_ic_ic does not exist. I can see it's a Good Thing from the perspective of Parrot (and number of ops)
19:27 kj pmichaud: imcc currently precomputes this
19:27 kj (and pirc does too ;-) )
19:27 allison on the other hand, there's a good question whether we even need separate "i" and "ic" variants of the opcodes
19:27 pmichaud there is some advantage in being able to generate     add $I0, 2, 3     and have it work.
19:28 kj allison: i vs ic: I don't know about that; don't know (yet) about inner workings of ops in so much detail.
19:28 pmichaud on the other hand, given that nearly everything ends up in PMCs from an HLL perspective, the places where one could reasonably expect to see   add $I0, 2, 3  being used are pretty small at this point.
19:29 allison the 'i' variant does a register lookup
19:29 pmichaud right now PAST::Compiler force the first IN operand to always be a register, just to avoid this sort of thing.
19:30 allison and if we fake up 'add_i_ic_ic', why don't we fake up 'add_i_ic_i' or 'add_i_i_ic'?
19:30 kj anyway, this doesn't need an answer right now.. just wanted to give it some attention.
19:30 kj why would one do that?
19:31 kj the faking of _ic_ic is because we can precompute the result, so add_i_ic_ic --> set_i_ic
19:31 rdice joined #parrotsketch
19:32 allison a basic form of inlining, yes
19:32 kj yes
19:32 kj exactly
19:32 NotFound kj: this is another problem, that type of op sintetizing does not involve register creation.
19:32 allison I don't see the need to require that of all PIR compilers
19:33 kj well, it's not a problem to do it, but I was working on it, and found it clutters up my neat code :-)
19:33 allison heh :)
19:33 NotFound The ones that creates register have the additional problem of changing optimization level, in the current implementation.
19:33 allison so benchmark with and without
19:33 kj so before I continue and finish it, just wanted to know if it's worht it
19:34 allison see if the clutter actually buys anything in practical terms
19:34 kj well it won't slow down the pir compiler that much
19:34 chromatic The problem is that we're optimizing in the wrong place.
19:34 kj (I suspect)
19:34 kj I know that at the time it was a design decision to remove (or not add, not sure if it ever existed) add_i_ic_ic
19:34 allison that's my guess, that the optimization of inlining integer addition won't actually buy us much speed
19:35 pmichaud I'd be willing to bet that the add_i_ic_ic instruction is very rarely generated.
19:35 kj well, maybe a bit; but on average, how many add_i_ic_ic instruction would a program use?
19:35 allison add_i_i_ic is far more common
19:35 kj yes
19:36 allison opcodes are cheap, code clutter is expensive (over the long term)
19:36 pmichaud my suggestion would be to not support it, and see what breaks.
19:37 kj how high are the costs of having a larger opset?
19:37 kj ehm, instruction set?
19:37 kj I mean, there's about 1250 right now I think
19:37 kj how much would it cost, runtime cycles, to have an opset of, say, 1500 ?
19:37 kj is it just memory we're talking here?
19:37 allison kj: depends on the runcore
19:38 kj let's say the switch
19:38 chromatic The bigger the set, the more cache pressure for ops.
19:38 kj it's the slow one
19:39 allison well, for the switch, it potentially has to run through 1500 alternatives before hitting the right one
19:39 allison (that's why it's the slow one)
19:39 kj oh ok
19:39 kj well if it runs through 1200 or 1500, shouldn't matter that much
19:39 allison yes, it's a small percentage addition
19:40 kj Ok, well. Just so you know how this is done  :-)
19:40 kj Then question b: i found that div_i_ic_ic /is/ a valid opcode
19:40 kj (and same for fdiv)
19:40 allison yeah, keep them
19:40 kj I wondered why these are still there.
19:40 allison add the other i_ic_icz
19:41 allison i_ic_ic's
19:41 kj well, we can see whether they're ever used first...
19:41 allison likely a partial conversion
19:41 allison well, if they're *never* used, then sure, delete them, and don't add the other i_ic_ic's
19:41 kj right.
19:42 kj and 'being used' I take it that tests don't count?
19:42 allison I'm in favor of deleting the i_ic_i's while we're at it
19:42 allison (at least for the symmetrical ones like add)
19:42 kj you mean sub is asymmetrical?
19:42 pmichaud fwiw, at present  PAST can never generate   i_ic_*
19:42 NotFound Non commutative
19:42 pmichaud or n_nc_*
19:43 kj NotFound: right.
19:43 allison kj: yes, tests don't count (since they mostly were created because of the features)
19:43 pmichaud it's possible that PGE or other hand-written code is making use of the i_ic_i opcodes, though.
19:43 allison for 'add' it's not needed
19:43 kj pmichaud: I think the variants with only 1 'ic' should be kept, right?
19:44 NotFound pmichaud: we can cut that hands
19:44 allison for 'div', you might want to divide a constant by a register variable
19:44 kj I was only talking about _ic_ic variants.
19:44 kj not at all about i_ic_i or i_i_ic
19:45 allison yeah, I'm adding to it: while we're getting rid of i_ic_ic, consider getting rid of many i_ic_i variants
19:45 kj .. in favor of using i_i_ic?
19:46 allison kj: yes, where the order is not semantically significant
19:46 kj right, I get it.
19:47 kj ok. well I won't get to this on short term, still trying to finish pirc as far as possible...
19:47 allison (if we're going to work on trimming extra opcodes, trim the really useless ones)
19:47 allison yup, not urgent
19:47 chromatic NotFound?
19:48 NotFound I added support to get the min and max values of INTVAL and make them available from sysinfo
19:48 NotFound The problem is that it requires availability of limits.h or a platform hint
19:49 NotFound What will be the way to enforce this, and we want to enforce it?
19:49 allison if we don't enforce it, then we can't really use it for tests (which is the driving purpose of it)
19:50 allison but, how reliable will it be across platforms?
19:50 NotFound allison: as reliable as the people wirting the platform hint make it.
19:51 allison well, our platform hints aren't that fine-grained
19:51 NotFound I mean, if the limits.h is not reliable, the hint must be added, the same as if it had not.
19:51 allison we don't have "linux 64bit" separated from "linux 32 bit"
19:52 NotFound Yes, but the hint can define the symbols based in other symbols that platform can have.
19:53 allison more reliable would be to detect it during configure
19:53 NotFound Some like: #include <something> #define INT_MAX MAXINT
19:53 NotFound allison: I thinked about that, but puts more problems in the way to make parrot cross-compilable
19:54 allison not any more than the current strategy for picking which hints file to use
19:55 NotFound allison: yes, but that can be easily solved with command-line options.
19:55 allison (and if you make that selectable for cross-compilation, you can make the int size selectable too)
19:55 NotFound Mmmmm... yes.
19:56 NotFound I'll think and test that way, don't lose next episode.
19:57 NotFound In the meantime the sysinfo returns 0 when unknown in the current implementation, FYI
19:57 allison that's reasonable
19:58 NotFound And there is a test skipped except in linux that checks are not 0
19:59 NotFound Unskipping for other platforms well tested well be welcomed.
19:59 NotFound will
20:00 allison does that wrap up the questions?
20:01 NotFound For me yes
20:01 kj me too
20:02 allison ok, that's a wrap, thanks everybody!
20:02 chromatic Talk to you all next week.
20:02 kj bye.
20:03 NotFound Hasta la vista
20:04 pmichaud left #parrotsketch
20:05 NotFound left #parrotsketch
20:05 jhorwitz left #parrotsketch
20:06 moritz left #parrotsketch
20:12 chromatic left #parrotsketch
20:13 PacoLinux left #parrotsketch
20:17 cotto left #parrotsketch
20:29 allison left #parrotsketch
20:30 rdice joined #parrotsketch
20:54 pyrimidine joined #parrotsketch
21:49 pyrimidine joined #parrotsketch
21:49 pyrimidine left #parrotsketch
22:25 Whiteknight joined #parrotsketch

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