www.parrot.org | planet.parrot.org | 1.5.0 "TEH PARROTZ!" Released! | Feature freeze over, coders start your engines!
Set by moderator on 18 August 2009.
00:18 dukeleto_ joined 00:29 dukeleto joined 00:39 mokurai joined 00:40 jsut joined 00:53 delta left 01:08 MoC joined 01:22 Andy joined 01:24 bacek joined
bacek o hai 01:24
dalek rrot: r40694 | bacek++ | branches/context_pmc2 (2 files):
Add Parrot_ctx_get_attributes function to avoid NULL pointer dereference
 01:27
rrot: r40695 | bacek++ | branches/context_pmc2 (13 files):
Use PMC_get_context instead of PARROT_CONTEXT macro
cotto hi bacek 01:37
bacek hi cotto 01:42
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
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
dalek rrot: r40696 | bacek++ | branches/context_pmc3:
Yet another branch to convert Context to PMC
 01:51
Tene allison: ping. I have a patch for pcc_arg_unify that needs review before applying. 02:10
cotto Tene++ 02:14
Tene Unless someone else is willing and able?
cotto (assuming that a trivial fix wouldn't need review)
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.
Tene I'd trust you if you said "I'll do it."
Just act confident, then say "Yes, apply it" 02:16
Then I can apply without hesitation and uncertainty!
cotto puts on phb hat. 02:17
looks good. Go for it. 02:18
cotto takes off hat
Tene Wow, you're such a good manager. You didn't even see the patch and you just knew!
cotto I'm a decider.
Tene committed! 02:19
r40697
Now to look at the :slurpy return stuff.
cotto++ # The Decider 02:20
cotto keeps his hat handy in case anyone starts looking for the responsible party.
dalek rrot: r40697 | tene++ | branches/pcc_arg_unify/src/pmc/cpointer.pmc:
[pcc] Create a new String PMC when returning a constant string into an empty PMC register.
 02:21
cotto purl, me? 02:26
purl you are Christoph Otto <mailto:christoph@mksig.org> or a cooked salami
cotto cotto is also The Decider 02:27
purl okay, cotto.
02:27 Andy joined 02:29 mokurai joined
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:30
Tene: do you have more details on the failure you were resolving? 02:31
Tene Yes. 'sec
nopaste "tene" at 24.10.252.130 pasted "Example failure for allison++" (14 lines) at nopaste.snit.ch/17636
02:31 theory joined
Tene a sub returning a string constant into a PMC register fails. 02:32
erm.
a previously-unused PMC register.
prefix that with: "msg = new 'String'", and it works.
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
allison The place to fix it will be in Parrot_pcc_fill_returns_from_op in src/call/pcc.c 02:36
Tene Okay.
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?
That's the next task I was going to work on.
allison at the moment, it's not doing any checking that the type returned matches the type expected
Tene: yes, and also Parrot_pcc_fill_returns_from_c_args 02:38
one deals with a varargs list, the other deals with args in an op pointer
(neither checks the slurpy flag yet) 02:39
Tene But that's the function that should.
02:40 beta joined
dalek rrot: r40698 | tene++ | branches/pcc_arg_unify/src/pmc/cpointer.pmc:
Revert "[pcc] Create a new String PMC when returning a constant string into an empty PMC register."
 02:42
Tene allison: will result_item in Ppfrfo always be a CPointer? 02:43
allison Tene: yes 02:44
Tene: CallSignature creates all the entries in the returns list 02:45
Tene: and they have to be CPointers so they're modifiable
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)
Tene: you really don't want to poke into the internals, but you don't have to
Tene: what you really need to know is the signature of the CPointer
Tene Ah.
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. :)
allison The same for I and N into P
02:48 TiMBuS joined
Tene how to check STRING equality? 02:49
Parrot_str_equal 02:51
02:52 michel joined
nopaste "tene" at 24.10.252.130 pasted "So... like this? for allison++" (42 lines) at nopaste.snit.ch/17637 02:55
"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 nopaste.snit.ch/17638 02:58
Tene I like that much better. 02:59
allison Tene: I'm off to read a bedtime story to my kid, will look it over in about an hour 03:03
Tene: thanks!
Tene np
Now to figure out how to get flags out of a sig...
allison Tene: there's a function that converts a sig to flags 03:08
Tene Yeah. I just found fill_params
which checks it.
dalek rrot: r40699 | tene++ | branches/pmc_sans_unionval/t/pmc/complex.t:
[pmc_sans_unionval] Uncomment a complex test
 03:09
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 03:52 mokurai joined 04:00 cotto joined
allison Tene: looks great, thanks! 04:13
Tene: it's a nicely elegant fix
Tene allison: that should hll_map instead, though, right? 04:16
allison Tene: instead of the change to CPointer? 04:17
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:18
allison Tene: yes, to be on the safe side 04:19
Tene: (that's all changing, but using the existing functions will make sure we updated it whenever it changes)
dalek rrot: r40700 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Autobox return args when appropriate.
 04:20
Tene committed a changing doing that. 04:21
Okay, pretty sure I know how to handle slurpy return params now. Want me to do that too? 04:22
dalek rrot: r40701 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Use HLL mappings in return argument autoboxing
 04:24
allison Tene: sure, give it a whirl 04:40
I'm working on the test builder failure
Tene allison: you want me to keep bugging you for review, or want me to just commit? 04:52
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.
allison It looks like I need to modify the same section for the Test builder failure, but dealing with invocant arguments
the changes are likely distinct enough that it's not a problem 04:54
04:54 cotto joined 05:02 theory joined
chromatic thought *he* was The Decider. 05:11
Tene allison: I'm having trouble figuring out where the result_flags are. 05:13
allison Tene: they're in the short_sig
after ->
but, they're never parsed out into an array
(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?
allison parse the signature
Tene parse_signature_string 05:16
allison If the sub was called from PIR, then the return signature is stored in return_flags ATTR of CallSignature 05:17
yup, parse_signature_string 05:19
Tene Hmm. The contents of return_flags doesn't seem to make sense. 05:33
allison Tene: it won't unless the call was made from at op 05:39
(it's not set otherwise) 05:40
Tene so that's not going to be the case in Parrot_pcc_fill_returns_from_op ?
I thought it would be.
05:45 mokurai joined
Tene Ah, yeah, I'm just screwing it up. :) 05:48
allison Tene: fill returns from op means that the sub that was called was a PIR sub 05:51
Tene: but, it could have been called from C
Tene: you're trying to check if the :slurpy modifier was set on the call signature of the caller? 05:52
when Parrot_fill_returns_* only has the call signature of the callee?
Tene No, it's actually there. I was wrong. 05:56
Hmm. To do this properly, it almost looks like I want to duplicate the entire switch statement below. :( 05:59
I could make it work without repetition by using goto... but that's allegedly evil. 06:00
allison why repeat the switch?
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
Oh, hmm, maybe...
allison well, at least put it in a function 06:08
Parrot_fill_slurpy_param_from_op, or something
Tene It actually doesn't need to be repeated.
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.
and just swap out the variable the switch is storing into. 06:10
06:17 bacek joined
allison Tene: lovely 06:19
Tene 'sec, just about done.
dalek rrot: r40702 | bacek++ | branches/context_pmc3 (59 files):
"Small" refactoring of handling contexts.

  * Change all stored contexts to use Context PMC.
  * Added a couple macros to access context fields.		 06:22
rrot: r40703 | bacek++ | branches/context_pmc3/src (2 files):
[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
rrot: r40704 | bacek++ | branches/context_pmc3/src (2 files):
Fix couple of bugs during initalising
cotto allison, do you know why some but not all methods in a ns would be using the same context? 06:25
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.
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 nopaste.snit.ch/17639 06:27
cotto That's just so I can see how control flow works between methods. What the methods do isn't of great interest. 06:28
nopaste "tene" at 24.10.252.130 pasted "return properly into slurpy lists for allison++" (94 lines) at nopaste.snit.ch/17640 06:32
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:34
dalek rrot: r40705 | bacek++ | branches/context_pmc3/src/pmc/context.pmc:
[pmc] Set custom mark flag in Context PMC.
 06:39
rrot: r40706 | bacek++ | branches/context_pmc3/src/pmc/lexpad.pmc:
[pmc] Fix LexPad to use Context PMC
allison Tene: aye, the problem with unification is that they're doing different things 06:40
Tene: same basic logic (as near as possible to identical), but completely different effect 06:41
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.
I'm not certain it's worth the trouble, though.
allison Tene: and, yes, I haven't put in any handling for named returns yet 06:43
Tene: if it was more than two, it would begin to be, but for two it's not
Tene Agreed.
how does that patch look to you?
allison cotto: do you mean using the same context inside method1 and second_method? or inside main? 06:44
Tene: looking over it now 06:45
Tene: I'm going to have to work on the usage of return_ and result_, it's entirely inconsistent 06:46
Tene: (not your problem, you followed what was there)
cotto the same context in method1 and second_method. The context of main seems to be unique.
allison cotto: each method should have a unique context 06:47
cotto: none should share
cotto: alright, I say that, but contexts are recycled
cotto So it's a bug?
allison cotto: yes
Tene allison: Yes, I was going to recommend that you do that also.
allison cotto: that is, do they have the same pointer, or do they actually have the same registers? 06:48
cotto: having the same pointer isn't a problem, it just means the context structure has been reclaimed and reused
Tene: actually, if you change the name to something like "caller_return_flags" that could help here 06:49
Tene: or something that means "caller"
Tene: since that's what we're really distinguishing, caller signature and callee signature
dalek rrot: r40707 | bacek++ | branches/context_pmc3 (2 files):
Decorate context related functions with PARROT_EXPORT
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:51
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
cotto: right, but, contexts are just a linked list of structs
nopaste "bacek" at 114.73.13.155 pasted "coretest failures on context_pmc3 branch for Whitenight" (11 lines) at 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.
allison cotto: they're recycled
Tene if (filling_slurpy) { ... } else { return_list_index++ }
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
cotto: (or method call) 06:54
cotto That makes my world slightly more sane.
Thanks.
bacek msg Whiteknight can you take a look at context_pmc3 branch? I've got some failures nopaste.snit.ch/17641
purl Message for whiteknight stored.
allison cotto: if something holds onto a context (because a continuation was taken from it), then the context won't be recycled
cotto: which could explain the third case
dalek rrot: r40708 | bacek++ | branches/context_pmc3/t/native_pbc (4 files):
Rebuild native pbcs.
 06:56
allison Tene: okay, makes sense 06:57
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 06:59
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
Tene: (looking at original code in context)
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. :)
cotto allison, why is "pops" in quotes? 07:02
bacek cotto: because there is no stack
allison bacek: well, there sort of is here
cotto: because it doesn't actually remove anything, it just changes the pointer to the "top" context 07:03
cotto: the no-longer-used context is still there, ready to be moved back to when another context is needed 07:04
This will all be much saner after contexts are really PMCs :)
bacek allison: they are :) Almost
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.
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)
Tene Looking into doing it for from_c_args, but having more reading comprehension troubles. :) 07:07
committed.
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
Tene Well, okay, I kinda do, but officially I shouldn't.
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.
allison (I'm running with the corevm changes as a patch)
Tene: hangs in PGE?
Tene No hangs.
allison Tene: well, segfaults in PGE
Tene Both of the commits I've made so far were fixing failues in building PGE. 07:10
no segfaults so far either.
dalek rrot: r40709 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Return into slurpy result params from fill_returns_from_op. needs to be done for _from_c_args also.
rrot: r40710 | allison++ | branches/pcc_arg_unify/src/ops/core.ops:
[pcc] A new sub call should never use an existing call signature.
allison with the corevm patch, you can at least run the core tests
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
(and PGE is just an enormous pain to debug)
Tene: my most recent commit added a few thousand failing tests, because it finally got Test::Builder to print out the plan information 07:12
Tene "make coretests"? 07:14
ah, "coretest"
allison Tene: you get "shift_string() not implemented in class 'String'" ? 07:15
Tene allison: i did before my most-recent patch.
allison: that means that on your system, it's using fill_returns_from_c_args 07:16
so port my most-recent commit over there, and it will continue to a really weird error.
allison Tene: okay, svn up and now get "FixedIntegerArray: index out of bounds!"
Tene ah
nm then. :)
allison That's when I run 'make' 07:17
so it actually reaches PGE
Tene ah, so do I.
I must have been seeing the same problem that TestBuilder was.
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
Tene: it could be caused by your patch
Tene: but, it could also be unrelated
Tene allison: this failure is farther along in PGE than it got before my patch.
allison Tene: would need to track down if it's caused by the same call that was broken before
okay, then different 07:19
but, still could be caused by the logic for incrementing return_list_index++
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.
'sec
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 nopaste.snit.ch/17642
Tene When there's no result to return into, those things don't exist. 07:23
allison Tene: ah, yes, good
Tene so we move their initialization to after the 'break'
allison: go get some sleep. Also, looking forward to seeing you in Seattle next week. 07:24
07:24 cotto joined
allison Tene: yup, definitely 07:25
and glad to get your gf and particle's wife together too :)
Tene okay, it's inappropriately returning a slurpy somehow... :(
I'll keep working for a bit. 07:26
Thanks for the help tonight. :)
allison happy to help 07:27
dalek rrot: r40711 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Tweak initialization time to account for the return value of a sub call not being used.
allison I'll be on tomorrow too, if you want to drop patches my way
Tene you might find some applied to the branch while you're sleeping.
allison Tene: sure, I'll look through the revision log tomorrow 07:28
cotto allison, is ctx->recursion_depth how far along the list of contexts the current one is? 07:29
allison cotto: in general, yes, but it's not an exact match 07:30
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
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
cotto: the lexicals shouldn't, the continuation case will 07:33
cotto: essentially, you can't use recursion_depth as a context counter
cotto: it more accurately reflects "number of continuations in the current call chain" 07:35
allison offline
07:40 jaffa8 joined, cotto joined
jaffa8 hi 07:40
How can I use a 1 byte integer in parrot? 07:41
cotto jaffa8, in PIR? What are you trying to accomplish? 07:45
jaffa8 I was thinking on implementing a small language 07:46
languages use different types
what if I want to determine what type I want exactly
in PIR
or anywhere 07:47
purl rumour has it anywhere is fine :-)
dalek rrot: r40712 | bacek++ | branches/context_pmc3 (16 files):
Change similar to initial commit in context_pmc2 branch.

  * Initialisation of contexts simplified.
  * Freshly added PMCCTX macros gone.
  * Parrot_Context structure isn't passed around anymore.
purl dalek: that doesn't look right
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<
?
cotto It's platform-dependent. 07:49
I think so, at least.
jaffa8 You have a virtual machine with platform dependent size????
So what is the size of it on Windows? 07:50
cotto look in include/parrot/config.h. 07:51
jaffa8 Do you think this is alright?
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:54
I assume it's done that way to ensure that whatever INTVAL is defined to is consistent. 07:55
dalek rrot: r40713 | bacek++ | branches/context_pmc3/src (2 files):
Fix using contexts in jit definition.
 08:00
jaffa8 I wonder if type such as Parrot_Int4 can be used in Pir? 08:02
bacek jaffa8: no. It will add too much complexity to internals 08:03
cotto not as it stands. There's just int, float, string and pmc. 08:05
If you need to, you can create a ManagedStruct and make one of the fields a 1-byte int. 08:06
but that's intended for interaction with external C code
jaffa8 bacek,you mean it would add.... 08:07
Is compiling into exe supposed to work? 08:08
bacek jaffa8: yes, it works afaik 08:09
jaffa8 Is it possible to call perl func in Parrot
?
Are they implemented for Parrot too?
bacek jaffa8: I don't quite understand your question about "perl functions". 08:10
cotto Perl 5 runs on a completely different vm.
jaffa8 perl has many in-built functions 08:11
substr,open,close,index... etx
pack, unpack
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.
bacek and Rakudo (which is Perl6 implementation on top of Parrot)
cotto (There are likely to be equivalent, though.)
s/equivalent/equivalents/ 08:13
bacek Yay! Rakudo's make test passed on context_pmc3 branch!
Unfortunately this branch broke backward compatibility...
cotto bacek, it changes the API or just internal stuff that Rakudo depends on but shouldn't? 08:15
bacek there is no "API" for contexts in trunk. It just struct floating around. 08:16
So, answer is "yes"/"yes"
or "no"/"no"
depends on point of view
cotto Since it'd mean no deprecation, I vote for no/no. 08:18
bacek actually... I can try to preserve backward compatibility with few tweaks 08:21
08:26 quek joined
cotto even better 08:32
bacek done. 08:42
done!
DONE!
3 small failures.
Rakudo's spectest running seamlessly! 08:43
Bah... No, latest commit is not enough to restore compatibility... 08:44
dalek rrot: r40714 | bacek++ | branches/context_pmc3 (29 files):
Restore behavior of CONTEXT macro to avoid deprecation cicle.

  * New CURRENT_CONTEXT macro returns Context PMC.
bacek clock 08:46
clock?
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 /
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:52
bacek Because it is CURRENT_CONTEXT. Not CONTEXT(interp) 08:53
And I'm too lazy to type interp every time :) 08:54
cotto It looks odd to me, but I'll trust your experience and laziness. 08:55
chromatic What if we need the current context of a different interpreter? 08:56
cotto I was wondering if you'd show up.
bacek This macros can be changed anyway. 08:57
It was quickest way to switch from Parrot_Context to PMC. 08:58
chromatic Eventually we'll want the argument I think. 08:59
08:59 HG` joined
bacek Eventually this macros should be gone in favour of normal API functions. 09:00
chromatic Fine by me. 09:01
bacek But I can add "interp" parameter for time being
chromatic Consistency's sake and all that. 09:02
bacek deal :)
I'll do it tomorrow (matter of time)
chromatic: what about backward compatibility? 09:08
chromatic What's the specific change?
jaffa8 What is the state of Rakudo? 09:09
bacek Parrot_Context* -> PMC* 09:10
jaffa8: It works. Passing 70% of spectest
jaffa8 Can I write programs?
safely?
What function do not work? 09:11
bacek jaffa8: I don't think that KGB will pursue you for using Rakudo. So yes, safely.
chromatic Does poking into Context struct members directly now not work the same way? 09:12
09:12 quek left
jaffa8 bacek, I would like to avoid mysterious bugs. 09:12
chromatic There are mysterious bugs.
jaffa8 Have you watched too many X-files? 09:13
cotto Life is uncertain.
but you can ask the #perl6 folks if something is a bug and someone will most likely tell you.
jaffa8 not always 09:14
moritz btw #perl6 is on irc.freenode.net
not irc.perl.org
jaffa8 can you remind me where is the result of the test suite? 09:16
moritz rakudo.org/status has a chart 09:17
cotto That page is was really good idea. 09:18
moritz thanks :)
chromatic The bottom half always reads stale to me though; am I misreading?
moritz embedded comments have a different syntax now 09:19
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:20
i should probably be on #perl6 for this one 09:21
jaffa8 I tried to run the precompile perl6.exe 09:23
I get an error
pct.pbc not found
chromatic Did you install parrot with 'make install-dev'? 09:24
jaffa8 no, I download the binary from parrot-win32 at sourceforge
chromatic No idea then. fperrad may know more. 09:28
bacek trac.parrot.org/parrot/ticket/936 09:29
dalek rrot: r40715 | bacek++ | branches/context_pmc3 (54 files):
[cage] Add interp to CONTEXT macros.
 09:31
jaffa8 I have idea 09:35
I guess it cannot find the library
How can I set the path to the library?
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.
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
it cannot find a library
there must be a path to the library
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
parrot_config.exe 09:42
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
sop i cant really help you out =/
09:49 flh joined 10:03 Whiteknight joined
dalek kudo: e83932a | (Martin Berends)++ | tools/test_summary.pl:
tools/test_summary.pl: code cleanup, more result output, added comments
 10:07
10:13 payload joined 10:15 HG` joined
Whiteknight bacek++ 10:19
10:41 HG` joined 11:09 darbelo joined 11:13 quek joined 11:24 payload1 joined 11:50 rdice joined 12:12 joeri left 12:37 rdice joined 13:10 fperrad joined 13:11 payload joined
fperrad NotFound, why an empty destroy() is in integer.pmc (since auto_attrs) ? 13:14
13:27 quek left 13:37 Limbic_Region joined 13:38 JimmyZ joined
NotFound fperrad: maybe just by mistake, let me check... 13:39
13:43 HG` joined
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:45
rakudo (e83932a) builds on parrot r40715 - make test/make spectest (up to 28048) PASS - Ubuntu 9.04 amd64 (g++) 13:54
14:18 cotto joined 14:19 marius joined 14:25 kjeldahl joined 14:29 Psyche^ joined 14:42 Snooby joined
Snooby Hi, can anyone give me some clues how to setup/run Parrot under win32? 14:43
mikehh cotto: ping
jonathan Snooby: Easiest is to grab the binaries produced by fperrad++ from sourceforge.net/projects/parrotwin32/ 14:45
Snooby ok, nvm 14:47
mikehh nvm? 14:48
nevermind? 14:49
oh - he's gone 14:50
dalek rrot: r40716 | NotFound++ | trunk/src/pmc/integer.pmc:
[cage] delete destroy vtable function in Integer PMC, fperrad++
jonathan ...I'm not quite sure how nevermind is an answer to "here's how"... :-)
mikehh unless he had already figgured it out :-} 14:51
14:54 ewilhelm joined
dalek a: 1e13a77 | fperrad++ | src/pmc/lua (6 files):
use auto_attrs
 14:56
a: e5a25d8 | fperrad++ | src/pmc/lua (4 files):
remove empty VTABLE destroy()
15:09 fperrad left 15:38 beta joined 15:41 theory joined 15:44 JimmyZ joined 15:46 MoC joined 16:10 braceta joined 16:11 braceta joined 16:26 payload joined
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:34
16:36 urkle joined 16:40 urkle joined 16:47 urkle left
Tene Anyone around feeling opinionated about changes to PMCs? 16:59
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:00
mikehh sounds better - the former :-} 17:05
17:07 HG` joined
mikehh Tene: I really don't know enough about it but what is the overhead involved for the former vs the latter? 17:07
Tene the overhead looks like one pmc creation. 17:08
17:09 payload joined 17:18 flh joined
jonathan Tene: No, we don't want one PMC creation per thingy. :-) 17:23
Tene for all definitions of 'thingy'
17:33 mikehh_ joined
Coke bacek++ # contexts 17:34
jonathan Tene: How's the pcc branch going? It's awesome you're hacking on it... 17:38
Tene something a little weird is happening... 17:40
I'm pretty comfortable with it. Just churn through and work out all the issues.
I'm working on named parameters right no.
I'm running into what look like pretty basic C issues, but my C-fu isn't sufficient to recognize them. 17:41
Right now, 'break' seems to be exiting a for loop instead of continuing to the next iteration. 17:42
17:42 Whiteknight joined
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)
jonathan Tene: That's what break in C does 17:45
Tene: You need continue.
Tene ... ><
I bet that explains several other failures in the pcc branch. 17:46
Great, now we can pass named params! 17:50
jonathan++
slurpies don't work yet, though. 17:53
jonathan w00t
Tene++
dalek rrot: r40717 | tene++ | branches/pcc_arg_unify/src (2 files):
[pcc] First draft of support for named params.
 17:54
Tene 'make coretest' doesn't give a number of pass/fail tests. :( 17:57
I'm passing about half of t/op/calling.t, though 17:59
t/op/calling.t (Wstat: 14848 Tests: 94 Failed: 58)
Failed tests: 4-6, 15, 17-19, 21-22, 24-25, 29-30, 33-40
44-45, 47-50, 52-54, 57-59, 61-65, 67, 70-77
80-88, 91-92
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:02
let me test on i386 - have to reboot - bbiab 18:03
18:07 payload joined
dalek rrot: r40718 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] More s/break/continue/. Reclaim more tests.
 18:14
18:24 chromatic joined
Tene HI CHROMATIC 18:24
chromatic morning
cotto good almost afternoon 18:31
Whiteknight hello 18:32
18:34 mikehh joined
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.
So I uncommented it, and it runs fine for me.
Whiteknight okay 18:45
18:46 kjeldahl joined
Whiteknight Tene: what system are you on? 18:46
Tene linux x86_64
Creepy... passing arguments to a sub makes the return failw 18:49
Whiteknight Tene: ah, I rolled back the merge 18:50
so the test wouldn't have been failing
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
Tene unless I want to get some caffeine, I think this failure is a bit beyond me right now. 18:52
18:53 Ron joined
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:53
looking at the config.in file for dynpmc you were the last person to modify it 18:54
All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40716 - Ubuntu 9.04 i386 (g++) 18:56
looks like the testr failures are on amd64 only
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
I suspect that the test harness needs to be fixed.
18:58 michel joined
cotto unless it's by design 18:58
mikehh cotto: that file -> # $Id: dynpmc.in 40313 2009-07-28 20:39:11Z cotto $ 19:01
all the other .pbc files generated in t/pmc for example are removed but not in t/dynpmc 19:02
the only ones not to be removed are in the native_pbc directory 19:04
in the file we have: 19:05
testclean :
$(RM_F) "../../t/dynpmc/*.pir"
cotto easy fix
just let me confirm some stuff 19:06
mikehh I am just not 100% how the config.in files are used to generate the makefile - 90% maybe but not 100% 19:07
19:08 joeri joined
darbelo mikehh: tools/dev/gen_makefile.pl IIRC 19:08
mikehh darbello: yeah - but I am not sure how testclean: gets into clean: (yet - looking ;-}) 19:11
cotto mikehh, committed 19:12
dalek rrot: r40719 | cotto++ | trunk/config/gen/makefiles/root.in:
[t] delete t/dynpmc/*.pbc as part of test-clean, mikehh++ for noticing
mikehh they only get generated if make testr is run - but I have been doing that every test run 19:13
with make fulltest
cotto there's no harm in trying to delete files that aren't there 19:14
mikehh rakudo (e83932a) builds on parrot r40718 - make test/make spectest (up to 28049) PASS - Ubuntu 9.04 i386 (g++) 19:15
treed Githeads! 19:37
How can I make a branch that I created locally and then pushed to github track the github branch?
I can only find directions for making a new branch which tracks a remote one. 19:38
whoppix treed, git push origin branchname? 19:45
if thats what you want
19:49 cotto joined
treed whoppix: That's how you push, yes, but it won't make it track. 19:55
joeri You could edit it in .git/config 19:56
[branch "..."]\\n remote = origin 19:57
treed Thanks, that works. 19:58
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40719 - Ubuntu 9.04 i386 (gcc) 20:08
rakudo (e83932a) builds on parrot r40719 - make test/make spectest (up to 28050) PASS - Ubuntu 9.04 i386 (gcc) 20:14
allison Tene: I'm getting "Unable to fetch PMC value, the pointer is not a PMC" on a test that was passing yesterday 20:22
nopaste "tene" at 24.10.252.130 pasted "small case that produces that error for allison++" (12 lines) at nopaste.snit.ch/17643 20:26
Tene allison: if you don't pass arguments to the sub, it doesn't fail like that. 20:27
So, something is very broken, likely my fault. :)
allison Tene: thanks for the simple test case, I'll take a look 20:35
Tene: attempting a bisect to see which revision is failing 20:36
20:36 braceta joined
allison Tene: it's r40709 20:40
Tene: the slurpy args
Tene I was afraid of that. 20:44
mikehh ok - heading back to amd64 - and to see if I can get Virtualbox to work with my wireless connection 20:45
bbiab 20:46
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...
committed 20:50
dalek rrot: r40720 | tene++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] revert the slurpy return patch. It wasn't right.
 20:52
allison Tene: that fixes it. Back to debugging test builder. 20:54
Tene: (I can look into the slurpy patch later, if you'd like, but you seem to be doing quite well)
Whiteknight Tene: check out the branch in r40721 to see the test failure in t/pmc/complex.t 20:58
21:00 mikehh joined
dalek rrot: r40721 | whiteknight++ | failed to fetch changeset:
[pmc_sans_unionval] update to trunk -r40530:40718. Two test failures appear
 21:00
Tene Is there any way to get the test harness to run just one file? 21:10
ah, found it. 21:11
allison: available to clarify desired parrot behavior? 21:16
allison Tene: sure
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'
Tene passing one named arg to a sub that has two named params
allison 'prove t/foo/bar.t'
Tene what should happen in that case?
allison depends on if you're running with argument number checking turned on 21:18
if it is turned on and neither named parameter is optional, it should throw an exception
21:18 beta joined
Tene Yes, with arg checking turned on. 21:19
what error should be thrown specifically?
allison Tene: I'd stick to the text of the old system for now
Tene: see the static functions 'too_many' and 'too_few' in src/call/pcc.c 21:20
Tene: (the logic will be completely different, but the text the same
dalek rrot: r40722 | tene++ | branches/pcc_arg_unify (2 files):
[pcc] Correct order of operations on a conditional and update some test messages
 21:24
allison Tene: I'm reverting part of r40717, named arguments shouldn't be set in the array interface of the CallSignature
Tene: they should only be set on the hash interface
Tene allison: I don't actually understand what you're saying there. Maybe I misunderstand how CallSignature is supposed to work. 21:25
allison Tene: CallSignature contains both a hash and an array 21:26
the hash stores named arguments, the array stores positional arguments
the change in r40717 made it so the array stores both positional and named arguments
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.
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
allison Tene: yeah, not reverting that part
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
Tene ah
allison trac.parrot.org/parrot/changeset/4..._arg_unify
Tene I understand now.
Yes, you're right. 21:30
I'm down to 38 failures in t/op/calling.t, and many of those are just not failing properly. :) 21:32
Those kind ar eless-satisfying to fix, though. :(
Tene afk food
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:33
dalek rrot: r40723 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Reverting part of r40717, named arguments aren't stored in
 21:37
rrot: r40724 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Fetch an integer value into an integer variable (instead of
 21:48
Tene allison: those weren't actually the tests I was talking about. 21:51
dalek rdinal: e1abfa0 | (Joeri Samson)++ | (2 files):
Enable trailing whitespace
 21:52
allison Tene: okay
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? 21:59
s:2nd/of/or/ 22:00
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)
What does that look like in the call signature?
Tene the array attribute of the callsignature has a single item, 42 22:05
jonathan Tene: Stored as an C int, or as a PMC? 22:06
allison jonathan: yes
Tene it's actually an array of CPointer PMCs
allison positionals are in an array, named in a hash
returns are CPointers 22:07
jonathan allison: OK, but it's a hash of PMCs?
or and array of PMCs?
(for the caller side)?
allison jonathan: yes
chromatic All returns, even to PIR code, go through CPointers?
jonathan allison: Erm.
allison: So
allison chromatic: yes, all returns go through CPointers
jonathan foo(a,b,c) will construct a CallSignature PMC and then 3 CPointer PMCs?
chromatic Even when it's PIR code invoking PIR code?
jonathan Where a, b and c are, .local int a, b, c? 22:08
allison jonathan: no
(a, b, c) = foo(d, e, f) would be a CallSignature PMC and 3 CPointers
(CPointers are only for returns)
jonathan allison: OK, so the positionals array of the CallSignature would literally contain 3 integers? 22:09
Rather than 3 pointers?
It's sort of a union-ish thing?
allison the returns are CPointers because the returning code has to be able to set the contents of the PMC register
so, it takes a pointer to the register
jonathan (That is, rather than 3 pointers to PMCs of STRINGs.)
allison jonathan: the positionals array would contain 3 PMCs 22:10
jonathan allison: Erm?
purl Erm is it bat shit crazy? It's just unprovable right?
allison Parrot doesn't have a typed array yet
as in, a multi-typed array
jonathan allison: So we box everything?
allison so, the positionals are a ResizablePMCArray
jonathan How the f**k is that meant to be performant? 22:11
allison it's meant to work, and be modified later
chromatic Do we not have return calling conventions anymore?
As in "First arg goes in this reg, second arg in this reg, third arg in this reg..."?
jonathan allison: *sigh* I used to hope this branch would actually improve performance...
allison it's perfectly possible to create a typed array, that stores multi types
jonathan allison: Since we already have the signature, is that not trivial?
allison jonathan: it's the storage that's non trivial 22:12
jonathan: we could do it now with 4 arrays, one for ints, one for nums, one for strings, and one for PMCs
jonathan: but between the two options, that's not saving much
chromatic We already have four typed arrays in Parrot_Context_t. 22:13
jonathan allison: Why not an array of some union?
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
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
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?
allison Tene: what's the C array of pointers?
chromatic As I understand it, get_results has to create a return context from which it can read returned values.
jonathan chromatic: get_results specifies where in a given context to put the results. 22:15
chromatic: As in, which registers.
allison chromatic: remember that we can't treat all calls as direct register manipulation, because calls from C don't use registers
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
jonathan We can't, but I'm not sure that a PMC per return value is the best solution to that.
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
chromatic Yes, because see reason #1 I just mentioned. 22:16
22:17 bacek joined
allison chromatic: the goal is to make *both* fast 22:17
bacek Good morning
purl And good moroning to you, bacek.
Tene hi bacek
chromatic You're not going to make PIR -> PIR -> PIR work fast by treating it like C -> PIR -> C.
allison chromatic: this is the *first* stage of a series of refactors
bacek Tene: hi
purl que tal, bacek.
allison chromatic: we have to get away from the old crufty code before we can start streamlining it 22:18
jonathan ŠŸŃ€ŠøŠ²ŠµŃ‚, bacek
chromatic I fully support getting rid of old, crufty code.
bacek jonathan: Š”Š¾Š±Ń€Š¾Šµ утрŠ¾ :)
jonathan утрŠ¾? Š·Š“ŠµŃ Š½ŠµŃ‚! 22:19
...wow, cyrillic has a strange quietening effect. 22:22
22:23 MoC joined
bacek
.oO( Did I say something shocking? )
 22:23
jonathan: "Š·Š“ŠµŃŃŒ" 22:24
jonathan bacek: Meh. The Slovaks cope with me writing their language in ASCII and missing all the soft markers. :-P
bacek jonathan: :)
jonathan (And yes, I know full well that mixing up my Š¼Š°Ń‚ and Š¼Š°Ń‚ŃŒ is a bad idea. ;-)) 22:25
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
So in terms of figures that at first glance people think matter vs figures that actually do matter, it may not be *so* bad.
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.
Tene: Why can't CallSignature have a C array?
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*...
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.
chromatic We already have a C data structure which can hold elements of our four fundamental types.
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:37
*a PMC 22:38
I guess we'll be able to optimize down to 1 in the future though.
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
Well, 1 on the passing side.
The return side is kinda more, well, awkard.
chromatic Don't forget 3) cleaner call internals. I can't optimize what we have currently.
jonathan chromatic: nod 22:40
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
jonathan Thing is, in Rakudo we're going to be unpacking the signature object ourselves. 22:41
Which makes me nervous since it looks like optimizations are going to change the nature of it. 22:42
(the CallSignature object, I mean)
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.
OTOH, I can probably do a bunch of macros to minimize the pain of that. 22:43
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.
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
it just has to work the old way for now, for backward compatibility
jonathan allison: That'll be a silent change for anyone using PIR, yes?
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.
*assumption
allison exeption handling, unfortunately, uses get_results directly (and wrongly)
at the moment
purl hmmm... at the moment is just goes BZZZZZZZT if you do anything slightly wrong or learning how to use it
allison that will be a user-visible change
jonathan allison: Does it not always use .get_results, which is more macro-ish?
chromatic Exception handling we still need to figure out our whiteboard design for delimiting handler scope.
jonathan allison: Or does that macro also get used in other places? 22:46
allison jonathan: the PASM uses get_results directly
jonathan allison: Ah. :-/
allison it should be 'get_params' at the very least, and really it should be something more like .param 22:47
(abstract away the details from the user)
jonathan May be worth going further and using a completely different syntax like .exception_object or so (pref. shorter...) 22:48
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
jonathan: (catching up on earlier comment)
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?
allison and, returns will be an attribute on the CallSignature object
jonathan: yes, all vtable calls
jonathan allison: OK, that stands a chance of performing reasonably. 22:51
(Performance being one of the key things I have to worry about in the upcoming Rakudo refactors.) 22:52
jonathan -> sleep 22:59
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:12
chromatic Even single dispatch; what parameters does a function take. 23:14
mikehh so the signature specifies the parameter types and return type?
chromatic Yes. 23:15
mikehh I thought so but sometimes I get really confused with the terminology 23:16
a lot of the jargon has changed since I first started using computers, a long, long time ago (certainly in computer terms) 23:18
maybe ieven in real terms :-} 23:19
even
23:27 braceta joined 23:29 quek joined 23:48 cotto joined 23:55 cotto joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!