šŸ¦‹ Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
00:00 seanrobert joined, seanrobert left 00:01 seanrobert joined 00:09 simcop2387 left 00:10 simcop2387 joined 00:11 simcop2387 left, simcop2387 joined 00:15 mowcat left 00:18 Chi1thangoo left 00:24 simcop2387 left 00:26 simcop2387 joined, simcop2387 left, simcop2387 joined 00:30 pecastro left 00:52 aborazmeh left 00:55 Noisytoot left 01:01 lucasb left 01:11 Sgeo_ joined 01:14 Sgeo left 01:23 seanrobert left 01:26 seanrobert joined 01:46 seanrobert left 01:47 thundergnat left 01:51 wamba left 02:04 simcop2387 left 02:06 simcop2387 joined 02:09 ben__ left, simcop2387 left 02:10 simcop2387 joined 02:11 ben__ joined 02:16 simcop2387 left 02:18 simcop2387 joined 02:31 simcop2387 left 02:33 simcop2387 joined 02:38 perlbot left 02:42 perlbot joined 02:55 simcop2387 left 02:57 simcop2387 joined 03:01 perlbot left 03:03 sav_Dab joined 03:04 sav_Dab left 03:11 perlbot joined, perlbot left 03:12 perlbot joined 03:24 perlbot left 03:30 perlbot joined 03:35 simcop2387 left 03:36 simcop2387 joined, simcop2387 left, simcop2387 joined 03:37 perlbot left, perlbot joined 03:46 ben__ left 03:47 ben__ joined 03:51 perlbot left 03:52 simcop2387 left 03:53 simcop2387 joined, simcop2387 left, simcop2387 joined 03:56 perlbot joined 03:58 MilkmanDan left 03:59 perlbot left 04:00 perlbot joined 04:03 simcop2387 left 04:05 simcop2387 joined 04:10 simcop2387 left 04:11 simcop2387 joined, simcop2387 is now known as simcop238 04:13 perlbot left 04:17 simcop238 left 04:18 simcop2387 joined 04:20 perlbot joined 04:27 yuplushi left 04:32 perlbot left 04:33 perlbot joined 04:36 MilkmanDan joined 04:46 simcop2387 left, perlbot left 04:49 simcop2387 joined, simcop2387 left, simcop2387 joined 04:52 perlbot joined 04:58 perlbot left 04:59 cooper joined 05:02 simcop2387 left 05:04 simcop2387 joined 05:15 simcop2387 left 05:16 simcop2387 joined, simcop2387 left, simcop2387 joined 05:20 parabolize left 05:27 BenGoldberg left 05:30 simcop2387 left 05:32 simcop2387 joined 05:35 frost-lab joined 05:39 simcop2387 left 05:41 spycrab0 left 05:42 simcop2387 joined 05:43 spycrab0 joined, cooper left 05:44 simcop2387 left, simcop2387 joined 05:55 simcop2387 left 05:56 simcop2387 joined, simcop2387 left, simcop2387 joined 05:59 simcop2387 left 06:00 simcop2387 joined, simcop2387 left, simcop2387 joined 06:03 xinming joined 06:06 xinming_ left 06:13 pilne left 06:14 silug left 06:31 cpan-raku_ left 06:32 cpan-raku joined, cpan-raku left, cpan-raku joined 06:33 jmerelo joined 06:41 simcop2387 left, simcop2387 joined 06:42 simcop2387 left, simcop2387 joined 06:46 pilne joined 06:47 hacktor joined 06:50 simcop2387 left, silug joined, wamba joined 06:51 simcop2387 joined 07:02 simcop2387 left 07:03 simcop2387 joined 07:05 simcop2387 left, simcop2387 joined 07:10 simcop2387 left 07:12 simcop2387 joined 07:13 simcop2387 is now known as simcop238 07:20 stoned75 joined
Geth_ doc/io-path-parts: 6ffd37d4de | (Stoned Elipot)++ | 6 files
Document IO::Path::Parts

  ... and its relation with IO::Path and IO::Spec::*		 07:24
doc: stoned++ created pull request #3695:
Document IO::Path::Parts
07:33 Sgeo_ left 07:34 simcop238 left 07:38 simcop2387 joined, simcop2387 is now known as simcop238 07:43 simcop238 left 07:45 simcop2387 joined 07:52 simcop2387 left 07:56 simcop2387 joined 07:57 pecastro joined 08:01 Merfont left, Merfont joined 08:08 aborazmeh joined, aborazmeh left, aborazmeh joined 08:10 domidumont joined 08:18 BenGoldberg joined 08:19 kensanata joined 08:20 ufobat joined 08:25 Doc_Holliwood joined 08:27 simcop2387 left, simcop2387 joined 08:28 simcop2387 left, simcop2387 joined 08:29 Kaeipi joined, Merfont left 08:30 patrickb joined 08:31 abraxxa joined 08:33 dakkar joined 08:43 abraxxa left 08:44 abraxxa joined 08:47 frost-lab left 08:48 skids joined 08:49 frost-lab joined 08:51 patrickb left 08:52 simcop2387 left, BenGoldberg left 08:53 gdonald left
Geth_ doc: 9829605de9 | (Stoned Elipot)++ (committed by Juan JuliĆ”n Merelo GuervĆ³s) | 6 files
Document IO::Path::Parts

  ... and its relation with IO::Path and IO::Spec::*		 08:57
08:58 simcop2387 joined 09:00 simcop2387 left 09:02 simcop2387 joined 09:05 simcop2387 left 09:08 simcop2387 joined
tib Hello, with profiling, is there a way to have an idea of how many time was spent for allocation of a type of objects ? There is a link to routine that made the allocation but the time spent in the routine is includes more than only the allocation. 09:13
(and after checking the profile.json, the allocations { } blocks only contains type and number of allocs) 09:14
09:15 eater left 09:16 Henry151 left, eater joined 09:18 Henry151 joined
MasterDuke tib: i don't think so. but timotimo++ probably knows the profiler the best 09:18
hm. have you checked if there's a new() for that type in the rountines tab? and if so, does the number of times it's been called match the count of allocations? 09:19
looks like there can be a match between the two, but only for higher-level types (i.e., works for something like Rakudo::Iterator, but not BOOTHash) 09:21
tib nothing match :/ 09:22
MasterDuke timotimo: any other ideas? 09:24
tib: is there any particular types you're interested in? 09:26
timotimo some REPRs do more work to initialize than others 09:32
i.e. some are just allocated, and some have a little extra function
tib Actually, I wanted to see the cost of allocation, I have a case where I allocate a lot of Int versus another where I allocate nothing at all. Both performs the same when optimization are enabled. 09:34
timotimo interesting
tib Probably because allocation time is very small and there is autoboxing.
But that's just a supposition
timotimo allocation cost gets amortized by the GC kicking in whenever a limit is reached
so if you record the allocation time for types, whether a given type will have a lot or almost nothing depends entirely on luck of the draw 09:35
09:37 simcop2387 left
tib There are some hints in this talk www.jnthn.net/papers/2011-tcpw-optimization.pdf (page 51, 52) that make me feel that time is spent elsewhere than alloc 09:40
and if I disable moarvm optims, of course the version with a lot of Int allocs becomes much much longer (as "expected") 09:41
09:42 simcop2387 joined, simcop2387 left, simcop2387 joined
timotimo you can get the exact code that moarvm makes for your functions 09:42
the env var MVM_SPESH_LOG set to a filename will spit that out 09:43
tib oh, thank you
Since we are talking about profiling, do you know if there is a way to have better routines names in profiler ? I tried to name loops (MYLOOP: loop ...) but it is "lost" later in report 09:45
timotimo you can use subs, other than that it'll unfortunately just be line numbers and filenames 09:46
09:49 simcop2387 left, aborazmeh left, skids left, cpan-raku left 09:51 simcop2387 joined 09:52 simcop2387 left, simcop2387 joined
tib ok thank you 09:52
09:53 cpan-raku joined, cpan-raku left, cpan-raku joined 09:59 sena_kun joined 10:02 marcusr left 10:03 simcop2387 left 10:06 marcusr joined 10:07 maggotbrain left 10:08 simcop2387 joined 10:11 simcop2387 left 10:12 simcop2387 joined, simcop2387 left, simcop2387 joined 10:17 simcop2387 left 10:18 simcop2387 joined 10:19 simcop2387 left, simcop2387 joined 10:34 simcop2387 left
JJAtria[m] moritz: Is the version of your book in www.apress.com/gp/book/9781484232279 the latest one? Since the title is pre-rename, I'm not sure I'm looking at the right entry šŸ˜… 10:35
10:35 simcop2387 joined 10:36 simcop2387 left, simcop2387 joined 10:41 simcop2387 left 10:42 simcop2387 joined
moritz JJAtria[m]: yes, it's the latest. There isn't a Raku revision of that book yet 10:55
nor do I think there will be one, given the sales numbers 10:56
JJAtria[m] Well, you're about to get a new one šŸ’ø
10:57 simcop2387_ joined 11:00 simcop2387 left, simcop2387_ is now known as simcop2387 11:02 simcop2387 left, simcop2387 joined 11:11 simcop2387 left 11:12 simcop2387 joined 11:18 telex left 11:20 telex joined 11:28 MasterDuke left, aborazmeh joined, aborazmeh left, aborazmeh joined 11:29 simcop2387 left 11:30 simcop2387 joined 11:31 simcop2387 is now known as simcop238 11:35 rindolf joined 11:36 simcop238 left 11:39 simcop2387 joined, simcop2387 left, simcop2387 joined 11:43 BenGoldberg joined 11:45 simcop2387 left 11:49 simcop2387 joined 11:50 simcop2387 left, simcop2387 joined
Geth_ doc: hythm7++ created pull request #3696:
Make user aware of the risk of using qqx		 11:58
11:58 simcop2387 left 11:59 simcop2387 joined 12:07 simcop2387 left 12:08 simcop2387 joined 12:10 Altai-man joined 12:13 sena_kun left 12:17 BenGoldberg left 12:20 simcop2387 left 12:22 simcop2387 joined, simcop2387 left, simcop2387 joined 12:29 domidumont left 12:30 domidumont joined 12:31 simcop2387_ joined, simcop2387 left, simcop2387_ is now known as simcop2387 12:35 Doc_Holliwood left 12:37 simcop2387 left 12:38 simcop2387 joined, simcop2387 left, simcop2387 joined 12:42 simcop2387 left 12:43 simcop2387 joined 12:44 simcop2387 left, simcop2387 joined 12:47 simcop2387 left 12:51 simcop2387 joined 12:52 simcop2387 left, simcop2387 joined 12:54 ufobat_ joined 12:58 ufobat left 13:08 simcop2387 left 13:09 simcop2387 joined 13:10 simcop2387 left, simcop2387 joined 13:17 abraxxa left 13:18 simcop2387 left, abraxxa1 joined 13:19 simcop2387 joined, simcop2387 left, simcop2387 joined 13:26 aborazmeh left 13:28 simcop2387 left 13:31 simcop2387 joined 13:32 simcop2387 left, simcop2387 joined 13:34 jmerelo left 13:44 simcop2387 left 13:45 tejr left, tejr joined 13:47 simcop2387 joined, simcop2387 left, simcop2387 joined 13:56 wamba left, simcop2387 left, Sgeo joined 13:58 simcop2387 joined, simcop2387 is now known as simcop238
tib Hello again, I'm experiencing very bad performances with unshift (and probably reproducible with prepend), is it "by design" or does it deserves a report (if yes to rakudo ? moarvm ?). It's especially obvious when comparing to "push". 14:04
timotimo can you give us a little benchmark perhaps? and some numbers? 14:05
tib yep
i.imgur.com/Vmk7AnJ.png 14:06
with this code gist.github.com/thibaultduponchell...02a5d1f649 14:08
14:09 simcop238 left
tib x is number of iterations, and y is seconds. 14:10
14:11 simcop2387 joined
timotimo if you'd like to make this better, you could have a look at moarvm's VMArray.c in src/6model/reprs/ 14:11
vmarrays have a start index and length on top of allocated size, and it's meant to handle situations where you mix pushing/unshifting and popping/shifting 14:12
14:14 simcop2387 left 14:15 aindilis left
lizmat timotimo: is there a HLL / nqp way to get at these VMArray attributes ? for debugging I mean 14:15
tib timotimo: if I understand correctly, you think that unshift operation is supposed to performs better ? I was wondering if unshift was doing some sort of costly realloc (by design) whereas push is not. 14:16
(In comparison perl 5 has poor perfs but push and unshift seems similar and "stable")
14:19 simcop2387 joined
lizmat fwiw, doing the same kind of benchmark with nqp ops, shows it's the nqp::unshift that is causing this, not any HLL issue 14:19
timotimo i think with the debugserver you can read these attributes 14:20
lizmat /* If we don't have room at the beginning of the slots, 14:22
* make some room (8 slots) for unshifting */
so that may be a bit too conservative
14:23 frost-lab left 14:24 jmerelo joined
lizmat /* We need more slots. If the current slot size is less 14:24
* than 8K, use the larger of twice the current slot size
* or the actual number of elements needed. Otherwise,
* grow the slots to the next multiple of 4096 (0x1000). */
so the other direction it's increasing with 4K increments 14:25
which would explain the difference in performance I guess
timotimo well, 4k after we have 8k elements 14:26
lizmat yeah, which we would get at pretty quickly in that benchmark :-) 14:28
timotimo right
14:29 simcop2387 left, Geth_ left, aborazmeh joined, aborazmeh left, aborazmeh joined, Geth joined 14:30 simcop2387 joined 14:31 epony left, hobbs left, phogg left, dotdotdot left, hobbs joined, hobbs left, hobbs joined, phogg joined, phogg left, phogg joined 14:32 dotdotdot joined 14:33 simcop2387 left, simcop2387 joined 14:38 simcop2387 left, Chi1thangoo joined
tib Great to see you have an idea on how to improve it :) 14:40
14:41 simcop2387 joined
tib lizmat timotimo do you want me to open an issue (I feel not capable for a PR) with bench chart + code snippets ? 14:41
14:41 simcop2387 left, simcop2387 joined
lizmat tib yes please 14:41
in moarvm 14:42
tib ok :)
lizmat thanks!
14:44 simcop2387 left 14:45 simcop2387 joined 14:47 simcop2387 left, simcop2387 joined 14:50 simcop2387 left 14:53 simcop2387 joined, simcop2387 left, simcop2387 joined 14:58 parabolize joined 15:03 simcop2387_ joined, simcop2387 left, simcop2387_ is now known as simcop2387 15:06 simcop2387 left 15:08 simcop2387 joined 15:09 BenGoldberg joined 15:10 lucasb joined
Geth doc: dumarchie++ created pull request #3698:
Improve documentation of Map.new		 15:14
15:18 simcop2387 left, guifa joined 15:22 simcop2387 joined 15:23 simcop2387 left, simcop2387 joined 15:27 simcop2387 left 15:28 simcop2387 joined, simcop2387 left, simcop2387 joined
tib rakudo + jvm seems to have a similar behaviour 15:31
15:32 simcop2387 left 15:34 simcop2387 joined 15:36 simcop2387 left, simcop2387 joined
Geth doc: da246d0b1d | (Peter du Marchie van Voorthuysen)++ (committed by Juan JuliĆ”n Merelo GuervĆ³s) | doc/Type/Map.pod6
Improve documentation of Map.new

There are two ways to ensure that a literal pair is not interpreted as a named argument. Quoting the key is arguably the clearest.		 15:38
linkable6 Link: docs.raku.org/type/Map
15:38 simcop2387 left 15:39 simcop2387 joined 15:41 simcop2387 left, simcop2387 joined 15:43 BenGoldberg left 15:52 aluaces left
cpan-raku New module released to CPAN! Config (3.0.3) by 03TYIL 15:53
15:54 epony joined 15:56 aborazmeh left 16:00 _jrjsmrtn left 16:01 aborazmeh joined, aborazmeh left, aborazmeh joined 16:03 __jrjsmrtn__ joined 16:04 simcop2387 left 16:05 simcop2387 joined 16:06 aborazmeh left 16:08 simcop2387 left 16:11 sena_kun joined, simcop2387 joined, simcop2387 left, simcop2387 joined
guifa Is it possible to pass a capture without needing to slip its values as arguments to another routine? 16:12
16:12 Altai-man left
guifa e.g. sub foo (|c) {Ā bar |c }; sub bar ($a, $b, $c) {Ā ā€¦Ā }; foo 1, 2, 3; 16:12
Directly passing c without the slip will pass it as a literal single argument 16:13
But breaking it down only to reconstruct it feels weird
lizmat m: sub a(|c) { b c }; sub b(\cap) { dd cap }; a 42, :foo
camelia \(42, :foo)
lizmat just pass it along without the prefix |
guifa okay weird 16:15
I swear when I tried this last night I couldnā€™t deconstruct the capture correctly on the second sub
But I think I was trying to make a sort of anonymous capture doing like sub b(\($a, $b)) or something like that 16:16
thanks lizmat++ 16:19
lizmat m: sub a(|c) { b c }; sub b($cap) { dd @$cap }; a 42, :foo 16:20
camelia (42,)
lizmat note you can just get the positionals or the nameds like that
m: sub a(|c) { b c }; sub b($cap) { dd %$cap }; a 42, :foo
camelia Map.new((:foo))
guifa Yeah. This is kind of a weird situation, I guess. Iā€™m doing method new(|c) {Ā self.bless!actual-new: c } 16:21
because subclasses of Hash donā€™t have TWEAK or BUILD called
lizmat ah, they don't ? 16:23
that could be considered a bug
probably *is* a bug 16:24
guifa github.com/rakudo/rakudo/issues/2716
lizmat we've had a similar situation with subclasses of Date / DateTime
ah, good point 16:25
16:25 Sgeo_ joined
guifa Oof, subclassing Date/DateTime. 16:25
I tried that for timezones, not a fun route (mainly because itā€™s not pervasive)
lizmat so you think the timezone value on DateTime should be a special class, so it can be subclassed? 16:26
rather than just an Int ?
guifa I used an allomorph in my module 16:28
16:28 Sgeo left
guifa and I return a intstr (or strint or whatever it is) 16:28
[Coke] lizmat: you see the stackoverflow with a hand-rolled cache?
guifa That way stuff just works
lizmat [Coke] ??
guifa: yeah, that should work 16:29
guifa With DateTime at least I managed to do it all via some pretty cool wrapping + mixins. (Iā€™ve got a big advent day post about that)
16:30 MasterDuke joined
guifa lizmat: stackoverflow.com/questions/64851261/ 16:31
lizmat are the wrappings and mixins still necessary ?
[Coke] stackoverflow.com/questions/648512...han-python 16:32
[Coke] rants about the old multi-booked meeting problem.
guifa Eh, likely. The problem is when you do math with timezones. Either you subclass (but then break compatibility with other modules) or you do the wraps and mixins 16:33
Honestly though, I have some performance testing, and you take a pretty minimal hit in creating a new DateTime object, and then after that working with them has virtually no perf hit beyond the extra math for calculations 16:34
[Coke] lizmat: I had added a comment about trying the cached/experimental item, it was deleted.
ah. I added an answer, not a comment. fair.
lizmat Yeah, I have no idea why some SO reviewers that do *not* know anything about Raku would do that
Geth doc: dumarchie++ created pull request #3699:
Improve documentation of Hash.push		 16:35
lizmat a similar event caused Wendy to give up on SO entirely: it was not nice as a first experience on SO
guifa sticks around on SO for Raku only
16:36 simcop2387_ joined 16:37 simcop2387 left, simcop2387_ is now known as simcop2387 16:38 aindilis joined 16:39 natrys joined, simcop2387 left 16:40 simcop2387 joined, simcop2387 left, simcop2387 joined
[Coke] rewrites it as a comment. 16:41
lizmat [Coke]: using cached does *not* improve that
16:43 simcop2387 left 16:46 simcop2387 joined
jmerelo Just a reminder we need the advent calendar articles ASAP, so that we can schedule it without a problem. So submit yours via PR to the advent calendar repo ASAP. 16:46
lizmat notable6: weekly 16:47
notable6 lizmat, No notes for ā€œweeklyā€
Geth doc: 6ed24973db | (Peter du Marchie van Voorthuysen)++ (committed by Juan JuliĆ”n Merelo GuervĆ³s) | doc/Type/Hash.pod6
Improve documentation of Hash.push

  * correct signature
  * sub push throws if it receives an unexpected named argument
linkable6 Link: docs.raku.org/type/Hash
16:51 simcop2387 left 16:55 wamba joined, simcop2387 joined
MasterDuke a profile of that SO code shows 33% of the time spent in GC 16:56
16:59 simcop2387 left
tib MasterDuke even more on my side, 50% 17:00
MasterDuke prob depends on the value for $L. i was using 500_000 17:01
17:01 simcop2387 joined, simcop2387 is now known as simcop238 17:05 simcop238 left
MasterDuke oh, and i'm also on a branch of moarvm i'm working on 17:05
17:05 simcop2387 joined, simcop2387 left, simcop2387 joined
guifa I tried redoing the code using a plain array but my code was taking even longer. But I probably edited it wrongly somewhere 17:09
[Coke] ls 17:18
$%;2~*
17:21 simcop2387 left 17:22 simcop2387 joined 17:25 simcop2387 left
cpan-raku New module released to CPAN! Memoize (0.0.7) by 03ELIZABETH 17:26
17:27 simcop2387 joined, simcop2387 left, simcop2387 joined 17:28 mowcat joined 17:32 aluaces joined 17:33 parabolize left 17:35 simcop2387 left 17:36 simcop2387_ joined, simcop2387_ is now known as simcop2387 17:39 dakkar left 17:40 simcop2387 left, simcop2387 joined 17:45 simcop2387 left 17:49 simcop2387 joined, simcop2387 left, simcop2387 joined 17:56 simcop2387 left 17:58 simcop2387 joined 17:59 simcop2387 is now known as simcop238 18:10 simcop238 left 18:12 simcop2387 joined 18:13 simcop2387 left, simcop2387 joined 18:14 jmerelo left 18:31 simcop2387 left 18:32 simcop2387 joined, simcop2387 left, simcop2387 joined 18:34 BenGoldberg joined 18:35 kensanata left 18:36 abraxxa1 left 18:37 abraxxa1 joined 18:40 simcop2387 left 18:42 simcop2387 joined 18:43 domidumont left 18:46 simcop2387_ joined 18:47 simcop2387 left, simcop2387_ is now known as simcop2387 18:49 simcop2387 left, simcop2387 joined, abraxxa1 left 18:50 abraxxa joined 18:59 simcop2387 left
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/11/16/2020-...n-renewed/ 19:03
19:03 simcop2387 joined, simcop2387 left, simcop2387 joined 19:04 abraxxa left 19:05 abraxxa joined
perryprog \o/ 19:06
Looks like some fun weekly challenges too. 19:08
19:08 BenGoldberg left 19:22 bocaneri left 19:25 bocaneri joined 19:26 Doc_Holliwood joined 19:31 MasterDuke left 19:32 jmerelo joined 19:34 bocaneri left, bocaneri joined, simcop2387 left 19:36 simcop2387 joined, simcop2387 left, simcop2387 joined 19:40 simcop2387 left 19:42 simcop2387 joined 19:43 aborazmeh joined, aborazmeh left, aborazmeh joined 19:48 jmerelo left 19:52 simcop2387 left 19:53 simcop2387 joined
Xliff Hi. If I want to add a :g to a regexp literal, will my $r = m:g/.../ work? 19:54
m: my $a = rule { . } 19:55
camelia ( no output )
Xliff m: my $a = rule { . }; $a.^name.say
camelia Regex
[Coke] m: my $r = / 'a' / ; say "banana" ~~ m:g/ <$r> /; 19:57
camelia (ļ½¢aļ½£ ļ½¢aļ½£ ļ½¢aļ½£)
[Coke] not sure you can put the :g on the $r 19:58
20:03 simcop2387 left 20:05 simcop2387 joined, simcop2387 left, simcop2387 joined 20:09 parabolize joined 20:10 Altai-man joined 20:11 skids joined 20:12 simcop2387 left, sena_kun left 20:14 simcop2387 joined, simcop2387 left, simcop2387 joined
Xliff [Coke]++ -- What you did there is fine, 20:16
guifa looks at weekly (lizmat++) 20:26
guifa hugs vrurg
guifa updates LanguageTag accordingly :D :D
20:49 simcop2387 left 20:51 simcop2387 joined
guifa is there any way to use a non-constant as the defined return value in a signature? 20:51
Iā€™m thinking mainly doing something like method foo (ā€”> self) for chaining, but I could see interesting applications if it could be a value createdd/modified in the block 20:52
20:56 natrys left 20:57 ufobat_ left
[Coke] guifa: doesn't work, looks like: 21:00
m: class a { method joe(--> self){"a"} } ; dd a.new.joe
camelia 5===SORRY!5=== Error while compiling <tmp>
Type 'self' is not declared
at <tmp>:1
------> 3class a { method joe(--> self7ā5){"a"} } ; dd a.new.joe
[Coke] m: class a { method joe(--> 3){"a"} } ; dd a.new.joe
camelia WARNINGS for <tmp>:
Useless use of constant string "a" in sink context (line 1)
3
guifa yeah I know ā€”Ā I didnā€™t know if there was a way to work around it or if thatā€™s set in stone itā€™s gotta be a value known at acompile time 21:01
21:08 natrys joined 21:09 simcop2387_ joined 21:10 simcop2387 left 21:11 simcop2387_ is now known as simcop2387
vrurg A code block is actually known at compile time. The problem is that there is no path in compiler code to implement it. 21:11
And no point in actually implementing it as routine body is that block anyway. 21:12
21:13 simcop2387 left, simcop2387 joined 21:20 simcop2387 left 21:22 simcop2387 joined 21:26 simcop2387 left 21:27 simcop2387 joined 21:30 simcop2387 left 21:32 stoned75 left 21:33 simcop2387 joined, simcop2387 left, simcop2387 joined 21:48 MasterDuke joined 21:54 simcop2387 left 21:58 simcop2387 joined 21:59 BenGoldberg joined 22:01 simcop2387 left 22:03 simcop2387 joined, simcop2387 left, simcop2387 joined 22:08 wildtrees joined 22:09 sftp left, sftp joined 22:11 simcop2387 left 22:13 simcop2387 joined 22:14 simcop2387 left, simcop2387 joined 22:16 natrys left 22:17 simcop2387 left 22:18 Xliff left, simcop2387 joined 22:21 simcop2387 left 22:22 simcop2387 joined 22:23 simcop2387 left, simcop2387 joined 22:28 Black_Ribbon joined 22:30 sono__ joined 22:33 BenGoldberg left 22:36 eater left, simcop2387 left 22:37 eater joined, tib left 22:38 tib joined, simcop2387 joined, Doc_Holliwood left 22:44 simcop2387 left 22:45 simcop2387 joined 22:47 wamba left 22:49 Doc_Holliwood joined 22:50 simcop2387 left 22:52 simcop2387 joined 23:00 simcop2387 left 23:01 simcop2387 joined, simcop2387 left, simcop2387 joined 23:04 simcop2387 left 23:05 MasterDuke left 23:06 simcop2387 joined, simcop2387 left, simcop2387 joined 23:11 mowcat left 23:15 simcop2387 left 23:17 simcop2387 joined, simcop2387 left, simcop2387 joined 23:19 Altai-man left 23:23 Doc_Holliwould joined 23:24 Doc_Holliwood left 23:26 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 23:30 cpan-raku left 23:35 rindolf left 23:45 simcop2387 left 23:46 simcop2387 joined, simcop2387 left, simcop2387 joined 23:47 simcop2387 left 23:49 simcop2387 joined 23:51 simcop2387 left 23:58 Doc_Holliwould left 23:59 simcop2387 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!