Camelia, the Perl 6 bug

IRC log for #parrot, 2009-08-22

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:18 dukeleto_ joined #parrot
00:29 dukeleto joined #parrot
00:39 mokurai joined #parrot
00:40 jsut joined #parrot
00:53 delta left #parrot
01:08 MoC joined #parrot
01:22 Andy joined #parrot
01:24 bacek joined #parrot
01:24 bacek o hai
01:27 dalek parrot: r40694 | bacek++ | branches/context_pmc2 (2 files):
01:28 dalek parrot: Add Parrot_ctx_get_attributes function to avoid NULL pointer dereference
01:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40694/
01:28 dalek parrot: r40695 | bacek++ | branches/context_pmc2 (13 files):
01:28 dalek parrot: Use PMC_get_context instead of PARROT_CONTEXT macro
01:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40695/
01:37 cotto hi bacek
01:42 bacek hi cotto
01:43 bacek seen whiteknight
01:43 purl whiteknight was last seen on #parrot 2 hours, 54 minutes and 48 seconds ago, saying: allison: thanks for the link! fun article
01:45 bacek msg whiteknight I sligtly screwed context_pmc2 branch... Removal of Parrot_Context structure was... erm... premature
01:45 purl Message for whiteknight stored.
01:46 quek left #parrot
01:51 dalek parrot: r40696 | bacek++ | branches/context_pmc3:
01:51 dalek parrot: Yet another branch to convert Context to PMC
01:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40696/
02:10 Tene allison: ping.  I have a patch for pcc_arg_unify that needs review before applying.
02:14 cotto Tene++
02:14 Tene Unless someone else is willing and able?
02:14 cotto (assuming that a trivial fix wouldn't need review)
02:15 Tene cotto: I don't actually understand the part I'm changing, but the trivial failure case that I found works after the fix.
02:15 cotto I wouldn't trust me to review a pcc_args_unify change.
02:15 Tene I'd trust you if you said "I'll do it."
02:16 Tene Just act confident, then say "Yes, apply it"
02:16 Tene Then I can apply without hesitation and uncertainty!
02:17 * cotto puts on phb hat.
02:18 cotto looks good.  Go for it.
02:18 * cotto takes off hat
02:18 Tene Wow, you're such a good manager.  You didn't even see the patch and you just knew!
02:18 cotto I'm a decider.
02:19 Tene committed!
02:19 Tene r40697
02:19 Tene Now to look at the :slurpy return stuff.
02:20 Tene cotto++ # The Decider
02:20 * cotto keeps his hat handy in case anyone starts looking for the responsible party.
02:21 dalek parrot: r40697 | tene++ | branches/pcc_arg_unify/src/pmc/cpointer.pmc:
02:21 dalek parrot: [pcc] Create a new String PMC when returning a constant string into an empty PMC register.
02:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40697/
02:26 cotto purl, me?
02:26 purl you are Christoph Otto <mailto:christoph@mksig.org> or a cooked salami
02:27 cotto cotto is also The Decider
02:27 purl okay, cotto.
02:27 Andy joined #parrot
02:29 mokurai joined #parrot
02:30 allison Tene: thanks! uh, not quite right though. CPointer only stores values, it doesn't create them. So, if something is failing to store a value the problem is there, not in CPointer.
02:31 allison Tene: do you have more details on the failure you were resolving?
02:31 Tene Yes.  'sec
02:31 nopaste "tene" at 24.10.252.130 pasted "Example failure for allison++" (14 lines) at http://nopaste.snit.ch/17636
02:31 theory joined #parrot
02:32 Tene a sub returning a string constant into a PMC register fails.
02:32 Tene erm.
02:32 Tene a previously-unused PMC register.
02:32 Tene prefix that with: "msg = new 'String'", and it works.
02:35 allison so, it's an autoboxing problem
02:35 Tene I'm not confident that I know how to answer that question. :)
02:35 janus joined #parrot
02:36 allison The place to fix it will be in Parrot_pcc_fill_returns_from_op in src/call/pcc.c
02:36 Tene Okay.
02:37 allison (autoboxing in that it needs to know to convert the string return to a PMC before it returns it)
02:37 Tene allison: is Parrot_pcc_fill_returns_from_op also the place that should be handling :slurpy return parameters?
02:37 Tene That's the next task I was going to work on.
02:37 allison at the moment, it's not doing any checking that the type returned matches the type expected
02:38 allison Tene: yes, and also Parrot_pcc_fill_returns_from_c_args
02:38 allison one deals with a varargs list, the other deals with args in an op pointer
02:39 allison (neither checks the slurpy flag yet)
02:39 Tene But that's the function that should.
02:40 beta joined #parrot
02:42 dalek parrot: r40698 | tene++ | branches/pcc_arg_unify/src/pmc/cpointer.pmc:
02:42 dalek parrot: Revert "[pcc] Create a new String PMC when returning a constant string into an empty PMC register."
02:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40698/
02:43 Tene allison: will result_item in Ppfrfo always be a CPointer?
02:44 allison Tene: yes
02:45 allison Tene: CallSignature creates all the entries in the returns list
02:45 allison Tene: and they have to be CPointers so they're modifiable
02:46 Tene Okay.  I didn't see a method in CPointer.pmc to check if ->data is PMCNULL, so I wanted to check if it was okay to poke into the internals.
02:46 allison Tene: (that is, not just modifiable by value, but modifiable by container)
02:46 allison Tene: you really don't want to poke into the internals, but you don't have to
02:46 allison Tene: what you really need to know is the signature of the CPointer
02:46 Tene Ah.
02:47 allison Tene: that is, if you've got an S value, and you're trying to stuff it into a P CPointer, then you know you need to create a new String PMC first
02:47 Tene I can do that. :)
02:47 allison The same for I and N into P
02:48 TiMBuS joined #parrot
02:49 Tene how to check STRING equality?
02:51 Tene Parrot_str_equal
02:52 michel joined #parrot
02:55 nopaste "tene" at 24.10.252.130 pasted "So... like this? for allison++" (42 lines) at http://nopaste.snit.ch/17637
02:58 nopaste "tene" at 24.10.252.130 pasted "So... like this? (Now with more Parrot_pcc_fill_returns_from_c_args!) for allison++" (74 lines) at http://nopaste.snit.ch/17638
02:59 Tene I like that much better.
03:03 allison Tene: I'm off to read a bedtime story to my kid, will look it over in about an hour
03:03 allison Tene: thanks!
03:03 Tene np
03:03 Tene Now to figure out how to get flags out of a sig...
03:08 allison Tene: there's a function that converts a sig to flags
03:08 Tene Yeah.  I just found fill_params
03:08 Tene which checks it.
03:09 dalek parrot: r40699 | tene++ | branches/pmc_sans_unionval/t/pmc/complex.t:
03:09 dalek parrot: [pmc_sans_unionval] Uncomment a complex test
03:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40699/
03:10 Tene purl: msg WhiteKnight t/pmc/complex.t passes cleanly for me after I uncommented that test in the pmc_sans_unionval branch.
03:10 purl Message for whiteknight stored.
03:18 mokurai joined #parrot
03:52 mokurai joined #parrot
04:00 cotto joined #parrot
04:13 allison Tene: looks great, thanks!
04:13 allison Tene: it's a nicely elegant fix
04:16 Tene allison: that should hll_map instead, though, right?
04:17 allison Tene: instead of the change to CPointer?
04:18 Tene allison: I mean, instead of pmc_new(interp, enum_class_Integer), I should pmc_new a Parrot_get_ctx_HLL_type(interp, enum_class_Integer), right?
04:19 allison Tene: yes, to be on the safe side
04:19 allison Tene: (that's all changing, but using the existing functions will make sure we updated it whenever it changes)
04:20 dalek parrot: r40700 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
04:20 dalek parrot: [pcc] Autobox return args when appropriate.
04:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40700/
04:21 Tene committed a changing doing that.
04:22 Tene Okay, pretty sure I know how to handle slurpy return params now.  Want me to do that too?
04:24 dalek parrot: r40701 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
04:24 dalek parrot: [pcc] Use HLL mappings in return argument autoboxing
04:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40701/
04:40 allison Tene: sure, give it a whirl
04:40 allison I'm working on the test builder failure
04:52 Tene allison: you want me to keep bugging you for review, or want me to just commit?
04:53 allison at the moment it's probably easier if I review, if for no other reason than to make sure I'm not tromping over your changes
04:53 * Tene nods.
04:53 allison It looks like I need to modify the same section for the Test builder failure, but dealing with invocant arguments
04:54 allison the changes are likely distinct enough that it's not a problem
04:54 cotto joined #parrot
05:02 theory joined #parrot
05:11 * chromatic thought *he* was The Decider.
05:13 Tene allison: I'm having trouble figuring out where the result_flags are.
05:13 allison Tene: they're in the short_sig
05:13 allison after ->
05:13 allison but, they're never parsed out into an array
05:14 allison (the flag array is for backward compatibility anyway, doesn't exist for calls from C
05:14 Tene So how can I check for a flag on a result?
05:14 allison parse the signature
05:16 Tene parse_signature_string
05:17 allison If the sub was called from PIR, then the return signature is stored in return_flags ATTR of CallSignature
05:19 allison yup, parse_signature_string
05:33 Tene Hmm.  The contents of return_flags doesn't seem to make sense.
05:39 allison Tene: it won't unless the call was made from at op
05:40 allison (it's not set otherwise)
05:40 Tene so that's not going to be the case in Parrot_pcc_fill_returns_from_op ?
05:40 Tene I thought it would be.
05:45 mokurai joined #parrot
05:48 Tene Ah, yeah, I'm just screwing it up. :)
05:51 allison Tene: fill returns from op means that the sub that was called was a PIR sub
05:51 allison Tene: but, it could have been called from C
05:52 allison Tene: you're trying to check if the :slurpy modifier was set on the call signature of the caller?
05:52 allison when Parrot_fill_returns_* only has the call signature of the callee?
05:56 Tene No, it's actually there.  I was wrong.
05:59 Tene Hmm.  To do this properly, it almost looks like I want to duplicate the entire switch statement below. :(
06:00 Tene I could make it work without repetition by using goto... but that's allegedly evil.
06:00 allison why repeat the switch?
06:01 Tene To fill the slurpy return param, I need to do the same logic that the big switch statement uses to fetch the result from the appropriate place.
06:01 Tene Oh, hmm, maybe...
06:08 allison well, at least put it in a function
06:08 allison Parrot_fill_slurpy_param_from_op, or something
06:08 Tene It actually doesn't need to be repeated.
06:09 allison is it clean enough to use the same switch, but store the value in the slurpy instead?
06:09 Tene i can put an if statement before and after the switch.
06:10 Tene and just swap out the variable the switch is storing into.
06:17 bacek joined #parrot
06:19 allison Tene: lovely
06:19 Tene 'sec, just about done.
06:22 dalek parrot: r40702 | bacek++ | branches/context_pmc3 (59 files):
06:22 dalek parrot: "Small" refactoring of handling contexts.
06:22 dalek parrot: * Use thin wrapper Context PMC for Parrot_Context structure.
06:22 dalek parrot: * Change all stored contexts to use Context PMC.
06:22 dalek parrot: * Added a couple macros to access context fields.
06:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40702/
06:22 dalek parrot: r40703 | bacek++ | branches/context_pmc3/src (2 files):
06:23 dalek parrot: [context_pmc3] fix some order-of-initialization issues in creating the first context. running into a segfault now whwere it appears a context is being freed prematurely
06:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40703/
06:23 dalek parrot: r40704 | bacek++ | branches/context_pmc3/src (2 files):
06:23 dalek parrot: Fix couple of bugs during initalising
06:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40704/
06:25 cotto allison, do you know why some but not all methods in a ns would be using the same context?
06:26 cotto I'd expect one or the other.
06:26 Tene allison: this won't properly handle named or named+slurpy result params, but it will be closer.
06:27 nopaste "cotto" at 74.61.2.46 pasted "pir-level methods: method1 and second_method use the same context, method_number_four uses a different one" (65 lines) at http://nopaste.snit.ch/17639
06:28 cotto That's just so I can see how control flow works between methods.  What the methods do isn't of great interest.
06:32 nopaste "tene" at 24.10.252.130 pasted "return properly into slurpy lists for allison++" (94 lines) at http://nopaste.snit.ch/17640
06:34 Tene allison: I've been tempted several times so far to unify the logic of fill_returns_from_op and fill_returns_from_c with function pointers.  Successfully resisted so far. :)
06:39 dalek parrot: r40705 | bacek++ | branches/context_pmc3/src/pmc/context.pmc:
06:39 dalek parrot: [pmc] Set custom mark flag in Context PMC.
06:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40705/
06:39 dalek parrot: r40706 | bacek++ | branches/context_pmc3/src/pmc/lexpad.pmc:
06:39 dalek parrot: [pmc] Fix LexPad to use Context PMC
06:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40706/
06:40 allison Tene: aye, the problem with unification is that they're doing different things
06:41 allison Tene: same basic logic (as near as possible to identical), but completely different effect
06:42 allison Tene: the advantage of this update, is that the logic is only duplicated twice (at the entry point and exit point from the call), instead of a dozen times littered through the system
06:42 Tene Right.  There are only a couple of places where they differ, though, so could pass the same args and a couple of function pointers to a helper function that has the common logic.
06:42 Tene I'm not certain it's worth the trouble, though.
06:43 allison Tene: and, yes, I haven't put in any handling for named returns yet
06:43 allison Tene: if it was more than two, it would begin to be, but for two it's not
06:43 Tene Agreed.
06:43 Tene how does that patch look to you?
06:44 allison cotto: do you mean using the same context inside method1 and second_method? or inside main?
06:45 allison Tene: looking over it now
06:46 allison Tene: I'm going to have to work on the usage of return_ and result_, it's entirely inconsistent
06:46 allison Tene: (not your problem, you followed what was there)
06:46 cotto the same context in method1 and second_method.  The context of main seems to be unique.
06:47 allison cotto: each method should have a unique context
06:47 allison cotto: none should share
06:47 allison cotto: alright, I say that, but contexts are recycled
06:47 cotto So it's a bug?
06:47 allison cotto: yes
06:47 Tene allison: Yes, I was going to recommend that you do that also.
06:48 allison cotto: that is, do they have the same pointer, or do they actually have the same registers?
06:48 allison cotto: having the same pointer isn't a problem, it just means the context structure has been reclaimed and reused
06:49 allison Tene: actually, if you change the name to something like "caller_return_flags" that could help here
06:49 allison Tene: or something that means "caller"
06:49 allison Tene: since that's what we're really distinguishing, caller signature and callee signature
06:49 dalek parrot: r40707 | bacek++ | branches/context_pmc3 (2 files):
06:49 dalek parrot: Decorate context related functions with PARROT_EXPORT
06:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40707/
06:51 cotto It's the same pointer, but I get the same result if I call a, b, a, b, so the context is clearly in use by both subs afaict.
06:52 allison Tene: you deleted several return_list_index++ statements, I'll have to look at it in context, but what changed that they're no longer  needed?
06:52 allison cotto: right, but, contexts are just a linked list of structs
06:53 nopaste "bacek" at 114.73.13.155 pasted "coretest failures on context_pmc3 branch for Whitenight" (11 lines) at http://nopaste.snit.ch/17641
06:53 Tene allison: return_list_index should only be updated when we're not getting items to fill a :slurpy, so there's a single return_list_index++ in the else branch of the conditional that follows the case statement.
06:53 allison cotto: they're recycled
06:53 Tene if (filling_slurpy) { ... } else { return_list_index++ }
06:53 allison cotto: so, if it calls one method, finishes with the context and "pops" it, it may validly reuse the same context structure for the next subroutine call
06:54 allison cotto: (or method call)
06:54 cotto That makes my world slightly more sane.
06:54 cotto Thanks.
06:54 bacek msg Whiteknight can you take a look at context_pmc3 branch? I've got some failures http://nopaste.snit.ch/17641
06:54 purl Message for whiteknight stored.
06:54 allison cotto: if something holds onto a context (because a continuation was taken from it), then the context won't be recycled
06:54 allison cotto: which could explain the third case
06:56 dalek parrot: r40708 | bacek++ | branches/context_pmc3/t/native_pbc (4 files):
06:56 dalek parrot: Rebuild native pbcs.
06:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40708/
06:57 allison Tene: okay, makes sense
06:59 allison Tene: last question: the results are being stored directly in destination registers, but those destination registers don't exist, because there's a slurpy destination instead of individual destinations
07:00 Tene allison: they're repeatedly being temporarily stored in the register that the slurpy list eventually gets stored in.
07:00 allison Tene: nope, answered my own question
07:00 allison Tene: (looking at original code in context)
07:01 allison Tene: it's not storing into a register, it's pulling the value from a register
07:01 Tene Okay, I must have misunderstood the question. :)
07:02 cotto allison, why is "pops" in quotes?
07:02 bacek cotto: because there is no stack
07:02 allison bacek: well, there sort of is here
07:03 allison cotto: because it doesn't actually remove anything, it just changes the pointer to the "top" context
07:04 allison cotto: the no-longer-used context is still there, ready to be moved back to when another context is needed
07:04 allison This will all be much saner after contexts are really PMCs :)
07:04 bacek allison: they are :) Almost
07:05 allison bacek: yes, I've seen you're working on that, looking forward to reviewing that work :)
07:05 bacek allison: I need couple oh hours more to finish it.
07:06 allison Tene: it looks good, and won't be affected by anything I'm working on, so go ahead and apply
07:06 bacek anyway, I didn't change semantic of anything. Just wrapped Parrot_Context into PMC (for now)
07:07 Tene Looking into doing it for from_c_args, but having more reading comprehension troubles. :)
07:07 Tene committed.
07:08 Tene I also don't know how to test Parrot_pcc_fill_returns_from_c_args, and don't trust myself to do it right without tests.
07:08 allison bacek: aye, a step in the right direction
07:08 Tene Well, okay, I kinda do, but officially I shouldn't.
07:09 allison well, the previous fix caused 21 more test failures, but I still considered it progress
07:09 Tene I can't run tests because 'make' doesn't complete.
07:09 allison (I'm running with the corevm changes as a patch)
07:09 allison Tene: hangs in PGE?
07:09 Tene No hangs.
07:09 allison Tene: well, segfaults in PGE
07:10 Tene Both of the commits I've made so far were fixing failues in building PGE.
07:10 Tene no segfaults so far either.
07:10 dalek parrot: r40709 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
07:10 dalek parrot: [pcc] Return into slurpy result params from fill_returns_from_op.  needs to be done for _from_c_args also.
07:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40709/
07:10 dalek parrot: r40710 | allison++ | branches/pcc_arg_unify/src/ops/core.ops:
07:10 dalek parrot: [pcc] A new sub call should never use an existing call signature.
07:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40710/
07:10 allison with the corevm patch, you can at least run the core tests
07:11 allison I'm not bothering with PGE until I've got it passing the core tests, figuring there's a good chance I'll fix it in the process
07:11 allison (and PGE is just an enormous pain to debug)
07:12 allison Tene: my most recent commit added a few thousand failing tests, because it finally got Test::Builder to print out the plan information
07:14 Tene "make coretests"?
07:14 Tene ah, "coretest"
07:15 allison Tene: you get "shift_string() not implemented in class 'String'" ?
07:15 Tene allison: i did before my most-recent patch.
07:16 Tene allison: that means that on your system, it's using fill_returns_from_c_args
07:16 Tene so port my most-recent commit over there, and it will continue to a really weird error.
07:16 allison Tene: okay, svn up and now get "FixedIntegerArray: index out of bounds!"
07:16 Tene ah
07:16 Tene nm then. :)
07:17 allison That's when I run 'make'
07:17 allison so it actually reaches PGE
07:17 Tene ah, so do I.
07:17 Tene I must have been seeing the same problem that TestBuilder was.
07:18 allison Tene: that likely means the counting is off, since fixed integer arrays are what's used for the param and results flags
07:18 allison Tene: it could be caused by your patch
07:18 allison Tene: but, it could also be unrelated
07:18 Tene allison: this failure is farther along in PGE than it got before my patch.
07:18 allison Tene: would need to track down if it's caused by the same call that was broken before
07:19 allison okay, then different
07:19 allison but, still could be caused by the logic for incrementing return_list_index++
07:21 * allison off for the night, piano practice starts in 6.5 hours, and there's no sleeping through Bach played at full volume at 7am
07:21 Tene ah, I see what it is.
07:21 Tene 'sec
07:22 allison Tene: 'k, I'll be around for a few more minutes
07:22 nopaste "tene" at 24.10.252.130 pasted "This helps" (27 lines) at http://nopaste.snit.ch/17642
07:23 Tene When there's no result to return into, those things don't exist.
07:23 allison Tene: ah, yes, good
07:23 Tene so we move their initialization to after the 'break'
07:24 Tene allison: go get some sleep.  Also, looking forward to seeing you in Seattle next week.
07:24 cotto joined #parrot
07:25 allison Tene: yup, definitely
07:25 allison and glad to get your gf and particle's wife together too :)
07:25 Tene okay, it's inappropriately returning a slurpy somehow... :(
07:26 Tene I'll keep working for a bit.
07:26 Tene Thanks for the help tonight. :)
07:27 allison happy to help
07:27 dalek parrot: r40711 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
07:27 dalek parrot: [pcc] Tweak initialization time to account for the return value of a sub call not being used.
07:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40711/
07:27 allison I'll be on tomorrow too, if you want to drop patches my way
07:27 Tene you might find some applied to the branch while you're sleeping.
07:28 allison Tene: sure, I'll look through the revision log tomorrow
07:29 cotto allison, is ctx->recursion_depth how far along the list of contexts the current one is?
07:30 allison cotto: in general, yes, but it's not an exact match
07:31 allison pmichaud put in a lexicals patch last november that means some contexts are outside the usual chain
07:31 cotto It doesn't work exactly like I'd expect for coroutines, probably among others
07:32 cotto will those contexts ever appear in CONTEXT(interp)?
07:32 allison and, if something stores a context beyond the life of the call chain it was created in (a continuation, for example) then it will also not match
07:33 allison cotto: the lexicals shouldn't, the continuation case will
07:33 allison cotto: essentially, you can't use recursion_depth as a context counter
07:35 allison cotto: it more accurately reflects "number of continuations in the current call chain"
07:35 * allison offline
07:40 jaffa8 joined #parrot
07:40 cotto joined #parrot
07:40 jaffa8 hi
07:41 jaffa8 How can I use a 1 byte integer in parrot?
07:45 cotto jaffa8, in PIR?  What are you trying to accomplish?
07:46 jaffa8 I was thinking on implementing a small language
07:46 jaffa8 languages use different types
07:46 jaffa8 what if I want to determine what type I want exactly
07:46 jaffa8 in PIR
07:47 jaffa8 or anywhere
07:47 purl rumour has it anywhere is fine :-)
07:47 dalek parrot: r40712 | bacek++ | branches/context_pmc3 (16 files):
07:47 dalek parrot: Change similar to initial commit in context_pmc2 branch.
07:47 purl dalek: that doesn't look right
07:47 dalek parrot: * Interp_Context gone.
07:47 dalek parrot: * Initialisation of contexts simplified.
07:47 dalek parrot: * Freshly added PMCCTX macros gone.
07:47 dalek parrot: * Parrot_Context structure isn't passed around anymore.
07:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40712/
07:48 cotto You could have an integer-like PMC that doesn't allow values outside a certain range, but there's no native support for specific-width native integers in PIR.
07:48 jaffa8 what is the size of integer anyway<
07:48 jaffa8 ?
07:49 cotto It's platform-dependent.
07:49 cotto I think so, at least.
07:49 jaffa8 You have a virtual machine with platform dependent size????
07:50 jaffa8 So what is the size of it on Windows?
07:51 cotto look in include/parrot/config.h.
07:51 jaffa8 Do you think this is alright?
07:54 cotto The value comes from config/auto/sizes.pm, which I think comes from Perl, but I don't fully understand the configure system.
07:55 cotto I assume it's done that way to ensure that whatever INTVAL is defined to is consistent.
08:00 dalek parrot: r40713 | bacek++ | branches/context_pmc3/src (2 files):
08:00 dalek parrot: Fix using contexts in jit definition.
08:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40713/
08:02 jaffa8 I wonder if type such as Parrot_Int4 can be used in Pir?
08:03 bacek jaffa8: no. It will add too much complexity to internals
08:05 cotto not as it stands.  There's just int, float, string and pmc.
08:06 cotto If you need to, you can create a ManagedStruct and make one of the fields a 1-byte int.
08:06 cotto but that's intended for interaction with external C code
08:07 jaffa8 bacek,you mean it would add....
08:08 jaffa8 Is compiling into exe supposed to work?
08:09 bacek jaffa8: yes, it works afaik
08:09 jaffa8 Is it possible to call perl func in Parrot
08:09 jaffa8 ?
08:09 jaffa8 Are they implemented for Parrot too?
08:10 bacek jaffa8: I don't quite understand your question about "perl functions".
08:10 cotto Perl 5 runs on a completely different vm.
08:11 jaffa8 perl has many in-built functions
08:11 jaffa8 substr,open,close,index... etx
08:11 jaffa8 pack, unpack
08:12 bacek jaffa8: there is similar functions in Perl6.
08:12 cotto If you wanted to you could use NCI to call any functions that are part of Perl 5's C API, but Perl 5's builtin functions aren't available to Parrot.
08:12 bacek and Rakudo (which is Perl6 implementation on top of Parrot)
08:12 cotto (There are likely to be equivalent, though.)
08:13 cotto s/equivalent/equivalents/
08:13 bacek Yay! Rakudo's make test passed on context_pmc3 branch!
08:13 bacek Unfortunately this branch broke backward compatibility...
08:15 cotto bacek, it changes the API or just internal stuff that Rakudo depends on but shouldn't?
08:16 bacek there is no "API" for contexts in trunk. It just struct floating around.
08:16 bacek So, answer is "yes"/"yes"
08:16 bacek or "no"/"no"
08:16 bacek depends on point of view
08:18 cotto Since it'd mean no deprecation, I vote for no/no.
08:21 bacek actually... I can try to preserve backward compatibility with few tweaks
08:26 quek joined #parrot
08:32 cotto even better
08:42 bacek done.
08:42 bacek done!
08:42 bacek DONE!
08:42 bacek 3 small failures.
08:43 bacek Rakudo's spectest running seamlessly!
08:44 bacek Bah... No, latest commit is not enough to restore compatibility...
08:44 dalek parrot: r40714 | bacek++ | branches/context_pmc3 (29 files):
08:44 dalek parrot: Restore behavior of CONTEXT macro to avoid deprecation cicle.
08:44 dalek parrot: * CONTEXT(interp) returns underlying Parrot_Context pointer.
08:44 dalek parrot: * New CURRENT_CONTEXT macro returns Context PMC.
08:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40714/
08:46 bacek clock
08:46 bacek clock?
08:46 purl bacek: LAX: Sat 1:46am PDT / CHI: Sat 3:46am CDT / NYC: Sat 4:46am EDT / LON: Sat 9:46am BST / BER: Sat 10:46am CEST / IND: Sat 2:16pm IST / TOK: Sat 5:46pm JST / SYD: Sat 6:46pm EST /
08:52 cotto bacek, why not make CURRENT_CONTEXT take an argument?  Having it just sit there silently depending on interp strikes me as surprising, even if it'll always work.
08:53 bacek Because it is CURRENT_CONTEXT. Not CONTEXT(interp)
08:54 bacek And I'm too lazy to type interp every time :)
08:55 cotto It looks odd to me, but I'll trust your experience and laziness.
08:56 chromatic What if we need the current context of a different interpreter?
08:56 cotto I was wondering if you'd show up.
08:57 bacek This macros can be changed anyway.
08:58 bacek It was quickest way to switch from Parrot_Context to PMC.
08:59 chromatic Eventually we'll want the argument I think.
08:59 HG` joined #parrot
09:00 bacek Eventually this macros should be gone in favour of normal API functions.
09:01 chromatic Fine by me.
09:01 bacek But I can add "interp" parameter for time being
09:02 chromatic Consistency's sake and all that.
09:02 bacek deal :)
09:02 bacek I'll do it tomorrow (matter of time)
09:08 bacek chromatic: what about backward compatibility?
09:08 chromatic What's the specific change?
09:09 jaffa8 What is the state of Rakudo?
09:10 bacek Parrot_Context* -> PMC*
09:10 bacek jaffa8: It works. Passing 70% of spectest
09:10 jaffa8 Can I write programs?
09:10 jaffa8 safely?
09:11 jaffa8 What function do not work?
09:11 bacek jaffa8: I don't think that KGB will pursue you for using Rakudo. So yes, safely.
09:12 chromatic Does poking into Context struct members directly now not work the same way?
09:12 quek left #parrot
09:12 jaffa8 bacek, I would like to avoid mysterious bugs.
09:12 chromatic There are mysterious bugs.
09:13 jaffa8 Have you watched too many X-files?
09:13 cotto Life is uncertain.
09:13 cotto but you can ask the #perl6 folks if something is a bug and someone will most likely tell you.
09:14 jaffa8 not always
09:14 moritz btw #perl6 is on irc.freenode.net
09:14 moritz not irc.perl.org
09:16 jaffa8 can you remind me where is the result of the test suite?
09:17 moritz http://rakudo.org/status has a chart
09:18 cotto That page is was really good idea.
09:18 moritz thanks :)
09:18 chromatic The bottom half always reads stale to me though; am I misreading?
09:19 moritz embedded comments have a different syntax now
09:20 TiMBuS if i have two multi methods that you cant distinguish between, does trying to call that method cause an error? i mean rakudo doesnt error it just picks one, but is it meant to error?
09:21 TiMBuS i should probably be on #perl6 for this one
09:23 jaffa8 I tried to run the precompile perl6.exe
09:23 jaffa8 I get an error
09:23 jaffa8 pct.pbc not found
09:24 chromatic Did you install parrot with 'make install-dev'?
09:24 jaffa8 no, I download the binary from parrot-win32 at sourceforge
09:28 chromatic No idea then.  fperrad may know more.
09:29 bacek https://trac.parrot.org/parrot/ticket/936
09:31 dalek parrot: r40715 | bacek++ | branches/context_pmc3 (54 files):
09:31 dalek parrot: [cage] Add interp to CONTEXT macros.
09:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40715/
09:35 jaffa8 I have idea
09:35 jaffa8 I guess it cannot find the library
09:35 jaffa8 How can I set the path to the library?
09:36 bacek msg Whiteknight Good news :) Only 2 test failing on context_pmc3. Ignore t/op/gc (it just miscount recursion depth). But I can't fix exceptionhandler.t. Apart from this two we have Context PMC with blackja^W^W
09:36 purl Message for whiteknight stored.
09:38 TiMBuS jaffa8, parrot probably should have placed itself in the PATH when it installed.. open a command prompt and type 'parrot', see if that works
09:38 jaffa8 I am not talking about that path
09:38 jaffa8 it cannot find a library
09:38 jaffa8 there must be a path to the library
09:41 TiMBuS hmm. well it might be set in a config file, i doubt it uses a registry key
09:41 jaffa8 It seems to use an exe
09:42 jaffa8 parrot_config.exe
09:47 TiMBuS looking at my parrot_config, id take a guess that windows probably has a very different setup since mine just points to /usr/local/lib
09:47 TiMBuS sop i cant really help you out =/
09:49 flh joined #parrot
10:03 Whiteknight joined #parrot
10:07 dalek rakudo: e83932a | (Martin Berends)++ | tools/test_summary.pl:
10:07 dalek rakudo: tools/test_summary.pl: code cleanup, more result output, added comments
10:07 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​83932a438a028c6365876316d5afcb9d323f868
10:13 payload joined #parrot
10:15 HG` joined #parrot
10:19 Whiteknight bacek++
10:41 HG` joined #parrot
11:09 darbelo joined #parrot
11:13 quek joined #parrot
11:24 payload1 joined #parrot
11:50 rdice joined #parrot
12:12 joeri left #parrot
12:37 rdice joined #parrot
13:10 fperrad joined #parrot
13:11 payload joined #parrot
13:14 fperrad NotFound, why an empty destroy() is in integer.pmc (since auto_attrs) ?
13:27 quek left #parrot
13:37 Limbic_Region joined #parrot
13:38 JimmyZ joined #parrot
13:39 NotFound fperrad: maybe just by mistake, let me check...
13:43 HG` joined #parrot
13:45 mikehh testr FAIL, all others PASS (pre/post-config, smoke, nqp_test, rest of fulltest) at r40715 - Ubuntu 9.04 amd64 (g++)  (see TT #939)
13:54 mikehh rakudo (e83932a) builds on parrot r40715 - make test/make spectest (up to 28048) PASS - Ubuntu 9.04 amd64 (g++)
14:18 cotto joined #parrot
14:19 marius joined #parrot
14:25 kjeldahl joined #parrot
14:29 Psyche^ joined #parrot
14:42 Snooby joined #parrot
14:43 Snooby Hi, can anyone give me some clues how to setup/run Parrot under win32?
14:43 mikehh cotto: ping
14:45 jonathan Snooby: Easiest is to grab the binaries produced by fperrad++ from http://sourceforge.net/projects/parrotwin32/
14:47 Snooby ok, nvm
14:48 mikehh nvm?
14:49 mikehh nevermind?
14:50 mikehh oh - he's gone
14:50 dalek parrot: r40716 | NotFound++ | trunk/src/pmc/integer.pmc:
14:50 dalek parrot: [cage] delete destroy vtable function in Integer PMC, fperrad++
14:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40716/
14:50 jonathan ...I'm not quite sure how nevermind is an answer to "here's how"... :-)
14:51 mikehh unless he had already figgured it out :-}
14:54 ewilhelm joined #parrot
14:56 dalek lua: 1e13a77 | fperrad++ | src/pmc/lua (6 files):
14:56 dalek lua: use auto_attrs
14:56 dalek lua: review: http://github.com/fperrad/lua/commit/1e​13a775685eb989fae421ac9b0dfc08a10f896c
14:56 dalek lua: e5a25d8 | fperrad++ | src/pmc/lua (4 files):
14:56 dalek lua: remove empty VTABLE destroy()
14:56 dalek lua: review: http://github.com/fperrad/lua/commit/e5​a25d84e0ace05a1a031bc9e8dbb22dafa4cb8a
15:09 fperrad left #parrot
15:38 beta joined #parrot
15:41 theory joined #parrot
15:44 JimmyZ joined #parrot
15:46 MoC joined #parrot
16:10 braceta joined #parrot
16:11 braceta joined #parrot
16:26 payload joined #parrot
16:34 Tene Okay, I've been able to figure out why named params aren't working in pcc branch, but I don't know what they *should* be doing.
16:36 urkle joined #parrot
16:40 urkle joined #parrot
16:47 urkle left #parrot
16:59 Tene Anyone around feeling opinionated about changes to PMCs?
17:00 Tene for the PCC work, I could either add set_*_keyed_str to Capture.pmc or I could create a new String PMC for every function invocation.... okay, when put like that, the former sounds much better.
17:05 mikehh sounds better - the former  :-}
17:07 HG` joined #parrot
17:07 mikehh Tene: I really don't know enough about it but what is the overhead involved for the former vs the latter?
17:08 Tene the overhead looks like one pmc creation.
17:09 payload joined #parrot
17:18 flh joined #parrot
17:23 jonathan Tene: No, we don't want one PMC creation per thingy. :-)
17:23 Tene for all definitions of 'thingy'
17:33 mikehh_ joined #parrot
17:34 Coke bacek++ # contexts
17:38 jonathan Tene: How's the pcc branch going? It's awesome you're hacking on it...
17:40 Tene something a little weird is happening...
17:40 Tene I'm pretty comfortable with it.  Just churn through and work out all the issues.
17:40 Tene I'm working on named parameters right no.
17:41 Tene I'm running into what look like pretty basic C issues, but my C-fu isn't sufficient to recognize them.
17:42 Tene Right now, 'break' seems to be exiting a for loop instead of continuing to the next iteration.
17:42 Whiteknight joined #parrot
17:43 Tene I added an eprintf of the arguments to the 'for' loop right before the 'break', and if it's incremented like the 'for' declaration claims, it should still satisfy the conditional...
17:43 mikehh rakudo (e83932a) builds on parrot r40716 - make test/make spectest (up to 28049) PASS - Ubuntu 9.04 amd64 (gcc)
17:45 jonathan Tene: That's what break in C does
17:45 jonathan Tene: You need continue.
17:45 Tene ... ><
17:46 Tene I bet that explains several other failures in the pcc branch.
17:50 Tene Great, now we can pass named params!
17:50 Tene jonathan++
17:53 Tene slurpies don't work yet, though.
17:53 jonathan w00t
17:53 jonathan Tene++
17:54 dalek parrot: r40717 | tene++ | branches/pcc_arg_unify/src (2 files):
17:54 dalek parrot: [pcc] First draft of support for named params.
17:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40717/
17:57 Tene 'make coretest' doesn't give a number of pass/fail tests. :(
17:59 Tene I'm passing about half of t/op/calling.t, though
17:59 Tene t/op/calling.t                     (Wstat: 14848 Tests: 94 Failed: 58)
17:59 Tene Failed tests:  4-6, 15, 17-19, 21-22, 24-25, 29-30, 33-40
17:59 Tene 44-45, 47-50, 52-54, 57-59, 61-65, 67, 70-77
17:59 Tene 80-88, 91-92
18:02 mikehh testr FAIL, all others PASS (pre/post-config, smoke, nqp_test, rest of fulltest) at r40716 - Ubuntu 9.04 amd64 (gcc)  (see TT #939)
18:03 mikehh let me test on i386 - have to reboot - bbiab
18:07 payload joined #parrot
18:14 dalek parrot: r40718 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
18:14 dalek parrot: [pcc] More s/break/continue/.  Reclaim more tests.
18:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40718/
18:24 chromatic joined #parrot
18:24 Tene HI CHROMATIC
18:24 chromatic morning
18:31 cotto good almost afternoon
18:32 Whiteknight hello
18:34 mikehh joined #parrot
18:36 cotto mikehh, pong
18:36 Tene Whiteknight: I saw your blog post about a failure in t/pmc/complex.t, so I looked at it and found that the failure was a plan mismatch due to a commented-out test.
18:36 Tene So I uncommented it, and it runs fine for me.
18:45 Whiteknight okay
18:46 kjeldahl joined #parrot
18:46 Whiteknight Tene: what system are you on?
18:46 Tene linux x86_64
18:49 Tene Creepy... passing arguments to a sub makes the return failw
18:50 Whiteknight Tene: ah, I rolled back the merge
18:50 Whiteknight so the test wouldn't have been failing
18:51 Whiteknight I need to remerge and see if the problem appears again
18:51 Tene Yes, that's the commit that the test was commented in.
18:51 Ron joined #parrot
18:52 Tene unless I want to get some caffeine, I think this failure is a bit beyond me right now.
18:53 Ron joined #parrot
18:53 mikehh cotto: hi - when running make testr (usually as part of make fulltest) it generates .pbc files which are not removed from t/dynpmc by make realclean
18:54 mikehh looking at the config.in file for dynpmc you were the last person to modify it
18:56 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40716 - Ubuntu 9.04 i386 (g++)
18:56 mikehh looks like the testr failures are on amd64 only
18:57 cotto that sounds unrelated to my changes (plus I don't think files in t/dynpmc are config/gen/makefiles/dynpmc.in's responsibility)
18:57 cotto I suspect that the test harness needs to be fixed.
18:58 michel joined #parrot
18:58 cotto unless it's by design
19:01 mikehh cotto: that file -> # $Id: dynpmc.in 40313 2009-07-28 20:39:11Z cotto $
19:02 mikehh all the other .pbc files generated in t/pmc for example are removed but not in t/dynpmc
19:04 mikehh the only ones not to be removed are in the native_pbc directory
19:05 mikehh in the file we have:
19:05 mikehh testclean :
19:05 mikehh $(RM_F) "../../t/dynpmc/*.pir"
19:05 cotto easy fix
19:06 cotto just let me confirm some stuff
19:07 mikehh I am just not 100% how the config.in files are used to generate the makefile - 90% maybe but not 100%
19:08 joeri joined #parrot
19:08 darbelo mikehh: tools/dev/gen_makefile.pl IIRC
19:11 mikehh darbello: yeah - but I am not sure how testclean: gets into clean: (yet - looking ;-})
19:12 cotto mikehh, committed
19:12 dalek parrot: r40719 | cotto++ | trunk/config/gen/makefiles/root.in:
19:12 dalek parrot: [t] delete t/dynpmc/*.pbc as part of test-clean, mikehh++ for noticing
19:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40719/
19:13 mikehh they only get generated if make testr is run - but I have been doing that every test run
19:13 mikehh with make fulltest
19:14 cotto there's no harm in trying to delete files that aren't there
19:15 mikehh rakudo (e83932a) builds on parrot r40718 - make test/make spectest (up to 28049) PASS - Ubuntu 9.04 i386 (g++)
19:37 treed Githeads!
19:37 treed How can I make a branch that I created locally and then pushed to github track the github branch?
19:38 treed I can only find directions for making a new branch which tracks a remote one.
19:45 whoppix treed, git push origin branchname?
19:45 whoppix if thats what you want
19:49 cotto joined #parrot
19:55 treed whoppix: That's how you push, yes, but it won't make it track.
19:56 joeri You could edit it in .git/config
19:57 joeri [branch "..."]\n    remote = origin
19:58 treed Thanks, that works.
20:08 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40719 - Ubuntu 9.04 i386 (gcc)
20:14 mikehh rakudo (e83932a) builds on parrot r40719 - make test/make spectest (up to 28050) PASS - Ubuntu 9.04 i386 (gcc)
20:22 allison Tene: I'm getting "Unable to fetch PMC value, the pointer is not a PMC" on a test that was passing yesterday
20:26 nopaste "tene" at 24.10.252.130 pasted "small case that produces that error for allison++" (12 lines) at http://nopaste.snit.ch/17643
20:27 Tene allison: if you don't pass arguments to the sub, it doesn't fail like that.
20:27 Tene So, something is very broken, likely my fault. :)
20:35 allison Tene: thanks for the simple test case, I'll take a look
20:36 allison Tene: attempting a bisect to see which revision is failing
20:36 braceta joined #parrot
20:40 allison Tene: it's r40709
20:40 allison Tene: the slurpy args
20:44 Tene I was afraid of that.
20:45 mikehh ok - heading back to amd64 - and to see if I can get Virtualbox to work with my wireless connection
20:46 mikehh bbiab
20:48 allison Tene: rather than getting bogged down in debugging, probably makes sense to revert that change and try it again
20:48 Tene allison: committing a revert...
20:50 Tene committed
20:52 dalek parrot: r40720 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
20:52 dalek parrot: [pcc] revert the slurpy return patch.  It wasn't right.
20:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40720/
20:54 allison Tene: that fixes it. Back to debugging test builder.
20:54 allison Tene: (I can look into the slurpy patch later, if you'd like, but you seem to be doing quite well)
20:58 Whiteknight Tene: check out the branch in r40721 to see the test failure in t/pmc/complex.t
21:00 mikehh joined #parrot
21:00 dalek parrot: r40721 | whiteknight++ | failed to fetch changeset:
21:00 dalek parrot: [pmc_sans_unionval] update to trunk -r40530:40718. Two test failures appear
21:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40721/
21:10 Tene Is there any way to get the test harness to run just one file?
21:11 Tene ah, found it.
21:16 Tene allison: available to clarify desired parrot behavior?
21:16 allison Tene: sure
21:17 Tene There are some tests that are failing in a different way than the tests expect.
21:17 allison Tene: for one file, just do prove 't/foo/bar.t'
21:17 Tene passing one named arg to a sub that has two named params
21:17 allison 'prove t/foo/bar.t'
21:17 Tene what should happen in that case?
21:18 allison depends on if you're running with argument number checking turned on
21:18 allison if it is turned on and neither named parameter is optional, it should throw an exception
21:18 beta joined #parrot
21:19 Tene Yes, with arg checking turned on.
21:19 Tene what error should be thrown specifically?
21:19 allison Tene: I'd stick to the text of the old system for now
21:20 allison Tene: see the static functions 'too_many' and 'too_few' in src/call/pcc.c
21:20 allison Tene: (the logic will be completely different, but the text the same
21:24 dalek parrot: r40722 | tene++ | branches/pcc_arg_unify (2 files):
21:24 dalek parrot: [pcc] Correct order of operations on a conditional and update some test messages
21:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40722/
21:24 allison Tene: I'm reverting part of r40717, named arguments shouldn't be set in the array interface of the CallSignature
21:24 allison Tene: they should only be set on the hash interface
21:25 Tene allison: I don't actually understand what you're saying there.  Maybe I misunderstand how CallSignature is supposed to work.
21:26 allison Tene: CallSignature contains both a hash and an array
21:26 allison the hash stores named arguments, the array stores positional arguments
21:26 allison the change in r40717 made it so the array stores both positional and named arguments
21:26 Tene allison: The issue I was addressing there was that Context, which CallSignature inherits from, has accessors for set_*_keyed, but not set_*_keyed_str.
21:27 allison The function 'extract_named_arg_from_op' took care of storing named ops already
21:27 Tene It was failing because CallSignature didn't have set_*_keyed_str
21:27 allison Tene: yeah, not reverting that part
21:28 Tene The functions that I added assigned to the hash, not the array.
21:28 allison it's the change to src/call/pcc.c that's not right
21:28 Tene ah
21:28 allison https://trac.parrot.org/parrot/chan​geset/40717/branches/pcc_arg_unify
21:28 Tene I understand now.
21:30 Tene Yes, you're right.
21:32 Tene I'm down to 38 failures in t/op/calling.t, and many of those are just not failing properly. :)
21:32 Tene Those kind ar eless-satisfying to fix, though. :(
21:32 * Tene afk food
21:33 allison Tene: 40722 looks fine, the new error messages are clearer, so I'm fine with updating the tests for those cases, rather than forcing the exceptions to have the same old unclear messages
21:37 dalek parrot: r40723 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
21:37 dalek parrot: [pcc] Reverting part of r40717, named arguments aren't stored in
21:37 dalek parrot: positional arg array, only in named arg hash.
21:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40723/
21:48 dalek parrot: r40724 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
21:48 dalek parrot: [pcc] Fetch an integer value into an integer variable (instead of
21:48 dalek parrot: fetching a PMC into an integer variable). Fix up some code line wrapping.
21:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40724/
21:51 Tene allison: those weren't actually the tests I was talking about.
21:52 dalek cardinal: e1abfa0 | (Joeri Samson)++ |  (2 files):
21:52 dalek cardinal: Enable trailing whitespace
21:52 dalek cardinal: Also add trailing whitespace to sanity test as a primitive regression test
21:52 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/e1abfa064ce2091506909f88d42c9a95bdef09c2
21:52 allison Tene: okay
21:59 jonathan allison: Does a CallSignature PMC hold an array of things, where each element could be a string, int, num of PMC? And the signature tells you what it is?
22:00 jonathan s:2nd/of/or/
22:01 Tene jonathan: an array and a hash.  callsignature isa capture.
22:01 jonathan Tene: OK, my point was that if you have a sub with a .param int foo and we call it 'the_sub'(42)
22:01 jonathan What does that look like in the call signature?
22:05 Tene the array attribute of the callsignature has a single item, 42
22:06 jonathan Tene: Stored as an C int, or as a PMC?
22:06 allison jonathan: yes
22:06 Tene it's actually an array of CPointer PMCs
22:06 allison positionals are in an array, named in a hash
22:07 allison returns are CPointers
22:07 jonathan allison: OK, but it's a hash of PMCs?
22:07 jonathan or and array of PMCs?
22:07 jonathan (for the caller side)?
22:07 allison jonathan: yes
22:07 chromatic All returns, even to PIR code, go through CPointers?
22:07 jonathan allison: Erm.
22:07 jonathan allison: So
22:07 allison chromatic: yes, all returns go through CPointers
22:07 jonathan foo(a,b,c) will construct a CallSignature PMC and then 3 CPointer PMCs?
22:07 chromatic Even when it's PIR code invoking PIR code?
22:08 jonathan Where a, b and c are, .local int a, b, c?
22:08 allison jonathan: no
22:08 allison (a, b, c) = foo(d, e, f) would be a CallSignature PMC and 3 CPointers
22:08 allison (CPointers are only for returns)
22:09 jonathan allison: OK, so the positionals array of the CallSignature would literally contain 3 integers?
22:09 jonathan Rather than 3 pointers?
22:09 jonathan It's sort of a union-ish thing?
22:09 allison the returns are CPointers because the returning code has to be able to set the contents of the PMC register
22:09 allison so, it takes a pointer to the register
22:09 jonathan (That is, rather than 3 pointers to PMCs of STRINGs.)
22:10 allison jonathan: the positionals array would contain 3 PMCs
22:10 jonathan allison: Erm?
22:10 purl Erm is it bat shit crazy?  It's just unprovable right?
22:10 allison Parrot doesn't have a typed array yet
22:10 allison as in, a multi-typed array
22:10 jonathan allison: So we box everything?
22:10 allison so, the positionals are a ResizablePMCArray
22:11 jonathan How the f**k is that meant to be performant?
22:11 allison it's meant to work, and be modified later
22:11 chromatic Do we not have return calling conventions anymore?
22:11 chromatic As in "First arg goes in this reg, second arg in this reg, third arg in this reg..."?
22:11 jonathan allison: *sigh* I used to hope this branch would actually improve performance...
22:11 allison it's perfectly possible to create a typed array, that stores multi types
22:11 jonathan allison: Since we already have the signature, is that not trivial?
22:12 allison jonathan: it's the storage that's non trivial
22:12 allison jonathan: we could do it now with 4 arrays, one for ints, one for nums, one for strings, and one for PMCs
22:12 allison jonathan: but between the two options, that's not saving much
22:13 chromatic We already have four typed arrays in Parrot_Context_t.
22:13 jonathan allison: Why not an array of some union?
22:13 allison chromatic: the problem is, the last revamp of the calling conventions changed it so 'get_results' is called *before* invoke, so the calling conventions for returns are not like the calling conventions for calls
22:14 Tene so what we want eventually is a FixedTypedArray, that has a signature and a C array of pointers?
22:14 allison Tene: yes on the FixedTypedArray
22:14 jonathan allison: Also, CallSignature from what I think you're saying does not construct just itself, it requires a ResizablePMCArray and a Hash PMC too, if there's nameds and positionals?
22:14 allison Tene: what's the C array of pointers?
22:14 chromatic As I understand it, get_results has to create a return context from which it can read returned values.
22:15 jonathan chromatic: get_results specifies where in a given context to put the results.
22:15 jonathan chromatic: As in, which registers.
22:15 allison chromatic: remember that we can't treat all calls as direct register manipulation, because calls from C don't use registers
22:15 chromatic Yes, but we don't have to treat all calls as if they were calls *from* C because 1) most calls *aren't* from C and 2) calls *from* C already have to go through functions to process incoming and outgoing parameters
22:15 jonathan We can't, but I'm not sure that a PMC per return value is the best solution to that.
22:15 allison chromatic: one of the biggest performance hits in the old code was all the added cruft to create fake register sets so the args and returns could be stuffed into them and immediately retrieved
22:16 chromatic Yes, because see reason #1 I just mentioned.
22:17 bacek joined #parrot
22:17 allison chromatic: the goal is to make *both* fast
22:17 bacek Good morning
22:17 purl And good moroning to you, bacek.
22:17 Tene hi bacek
22:17 chromatic You're not going to make PIR -> PIR -> PIR work fast by treating it like C -> PIR -> C.
22:17 allison chromatic: this is the *first* stage of a series of refactors
22:17 bacek Tene: hi
22:17 purl que tal, bacek.
22:18 allison chromatic: we have to get away from the old crufty code before we can start streamlining it
22:18 jonathan Привет, bacek
22:18 chromatic I fully support getting rid of old, crufty code.
22:18 bacek jonathan: Доброе утро :)
22:19 jonathan утро? здес нет!
22:22 jonathan ...wow, cyrillic has a strange quietening effect.
22:23 MoC joined #parrot
22:23 bacek .oO( Did I say something shocking? )
22:24 bacek jonathan: "здесь"
22:24 jonathan bacek: Meh. The Slovaks cope with me writing their language in ASCII and missing all the soft markers. :-P
22:24 bacek jonathan: :)
22:25 jonathan (And yes, I know full well that mixing up my мат and мать is a bad idea. ;-))
22:26 jonathan allison: tbh, while the inefficiency you're introducing for non-(pmc|string) args will probably be crappy for our benchmarks that are using I/N registers, Rakudo passes pretty much everything around as PMCs.
22:26 jonathan So in terms of figures that at first glance people think matter vs figures that actually do matter, it may not be *so* bad.
22:27 Tene jonathan: the current approach can be optimized by writing a TypedArray PMC without any algorithmic changes.
22:27 jonathan Tene: I'm curious why we need another PMC.
22:27 jonathan Tene: Why can't CallSignature have a C array?
22:28 Tene Sure, that would be a possibility.
22:28 jonathan Normally I'd not advocate such things but on something that we have to build *every call*...
22:29 chromatic I still don't understand why we need a TypedArray PMC.
22:29 Tene There are a few things that push onto a callsignature.
22:29 chromatic We already have a C data structure which can hold elements of our four fundamental types.
22:37 jonathan I can handle the idea that we create PMC per call OK. I think we've opportunities for caching there. But multiple worries me a bit more.
22:38 jonathan *a PMC
22:38 jonathan I guess we'll be able to optimize down to 1 in the future though.
22:39 jonathan From where I am, the most important things are 1) a consistent way of getting at the args being passed and 2) the :call_sig flag.
22:39 jonathan Well, 1 on the passing side.
22:39 jonathan The return side is kinda more, well, awkard.
22:39 chromatic Don't forget 3) cleaner call internals.  I can't optimize what we have currently.
22:40 jonathan chromatic: nod
22:40 jonathan I'm holding out some hope that once we get to an architecture that's right, even if it isn't that performant, the performance people can then come and optimize the heck out of it within the parameters of the design.
22:41 rg joined #parrot
22:41 jonathan Thing is, in Rakudo we're going to be unpacking the signature object ourselves.
22:42 jonathan Which makes me nervous since it looks like optimizations are going to change the nature of it.
22:42 jonathan (the CallSignature object, I mean)
22:42 jonathan Nervous in the sense of, I'm going to get something I have to actively track rather than is as it's going to be from the start.
22:43 jonathan OTOH, I can probably do a bunch of macros to minimize the pain of that.
22:43 jonathan Though if I as a compiler developer am going to need to do such things, I have to wonder if other HLLs will want to do the same too.
22:44 allison btw, after a suitable deprecation cycle, we can change 'get_results' back to following the call to invoke, and then we can get rid of CPointers entirely
22:44 allison it just has to work the old way for now, for backward compatibility
22:44 jonathan allison: That'll be a silent change for anyone using PIR, yes?
22:45 allison jonathan: as long as they're using the syntactic sugar for sub/method calls, yes
22:45 jonathan allison: Yes, that was my assumptiong.
22:45 jonathan *assumption
22:45 allison exeption handling, unfortunately, uses get_results directly (and wrongly)
22:45 allison at the moment
22:45 purl hmmm... at the moment is just goes BZZZZZZZT if you do anything slightly wrong or learning how to use it
22:45 allison that will be a user-visible change
22:45 jonathan allison: Does it not always use .get_results, which is more macro-ish?
22:45 chromatic Exception handling we still need to figure out our whiteboard design for delimiting handler scope.
22:46 jonathan allison: Or does that macro also get used in other places?
22:46 allison jonathan: the PASM uses get_results directly
22:46 jonathan allison: Ah. :-/
22:47 allison it should be 'get_params' at the very least, and really it should be something more like .param
22:47 allison (abstract away the details from the user)
22:48 jonathan May be worth going further and using a completely different syntax like .exception_object or so (pref. shorter...)
22:49 jonathan So we aren't tying getting the exception object to parameter passing.
22:49 allison jonathan: the internal nature of CallSignature will change, but the interface won't
22:49 allison jonathan: (catching up on earlier comment)
22:50 allison jonathan: that is, you'll be able to get the signature string with 'get_string' and access positional args through the array interface and named args through the hash interface
22:50 jonathan allison: OK, and the interface is all v-table calls?
22:50 allison and, returns will be an attribute on the CallSignature object
22:50 allison jonathan: yes, all vtable calls
22:51 jonathan allison: OK, that stands a chance of performing reasonably.
22:52 jonathan (Performance being one of the key things I have to worry about in the upcoming Rakudo refactors.)
22:59 * jonathan -> sleep
23:12 mikehh excuse my ignorance but exactly do we mean by a signature here - are we refering to function/method types to be used in multi-dispatch?
23:14 chromatic Even single dispatch; what parameters does a function take.
23:14 mikehh so the signature specifies the parameter types and return type?
23:15 chromatic Yes.
23:16 mikehh I thought so but sometimes I get really confused with the terminology
23:18 mikehh a lot of the jargon has changed since I first started using computers, a long, long time ago (certainly in computer terms)
23:19 mikehh maybe ieven in real terms :-}
23:19 mikehh even
23:27 braceta joined #parrot
23:29 quek joined #parrot
23:48 cotto joined #parrot
23:55 cotto joined #parrot

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

Parrot | source cross referenced