00:13 guifa2 joined 00:37 Kaiepi left, Kaiepi joined 01:08 b2gills left 01:11 b2gills joined 01:45 lizmat_ joined 01:48 lizmat left 01:55 squashable6 left 01:57 squashable6 joined 02:09 hungrydonkey joined 02:20 hungryd23 joined 02:22 hungrydonkey left 02:35 hungryd23 left 02:39 hungrydonkey joined 04:41 nativecallable6 left, sourceable6 left, notable6 left, reportable6 left, benchable6 left, squashable6 left, coverable6 left, committable6 left, bisectable6 left, statisfiable6 left, releasable6 left, bloatable6 left, linkable6 left, shareable6 left, quotable6 left 04:42 bloatable6 joined, quotable6 joined, bisectable6 joined, notable6 joined, squashable6 joined, committable6 joined, shareable6 joined 04:43 statisfiable6 joined, sourceable6 joined, releasable6 joined 04:44 linkable6 joined, coverable6 joined, nativecallable6 joined, reportable6 joined, benchable6 joined 04:50 tellable6 joined 04:51 tellable6 left 04:52 tellable6 joined 04:53 unicodable6 joined, greppable6 joined, evalable6 joined 04:58 hungryd67 joined 04:59 hungrydonkey left 05:05 hungryd67 left 05:11 hungrydonkey joined 05:15 hungryd32 joined 05:16 hungrydonkey left, hungrydonkey joined 05:20 hungryd32 left 05:36 hungryd33 joined 05:39 hungrydonkey left 05:47 eater left 06:21 squashable6 left 06:23 squashable6 joined
nine patrickb: you put the precompiled script in the same place we pick when precompiling modules. Please don't invent your own logic there. 06:43
tellable6 nine, I'll pass your message to patrickb
07:11 guifa2_ joined 07:12 guifa2 left, guifa2_ is now known as guifa2
tyil pochi_: on precompiled script files, $XDG_CACHE_HOME/raku/precomp ? 07:39
pochi_: soz, was ment to highlight patrickb, but he quit already :( 07:40
.tell patrickb on precompiled script files, $XDG_CACHE_HOME/raku/precomp
tellable6 tyil, I'll pass your message to patrickb
lizmat_ Files=1306, Tests=111242, 216 wallclock secs (28.71 usr 8.36 sys + 3042.49 cusr 278.37 csys = 3357.93 CPU) 07:51
nine tyil: why would we treat precompiled scripts any different from precompiled modules? 07:52
tyil who knows, he just asked for a possible location 07:53
lizmat_ because scripts can live anywhere? but I guess SHAing the path also wouild fix that ?
tyil that's a standardized location to put cache
I personally don't think having .precomp directories all over my filesystem is that pretty 07:54
nine I see no reason to reinvent the wheel here. We'd only make the same mistakes as the first time round
tyil isn't making your own standardized cache when we already have one from the XDG spec "reinventing the wheel" 07:55
nine tyil: if you want to get rid of .precomp directories, fix it for modules. Scripts will then pick up the same fix.
The difference is: this wheel has already been reinvented and debugged.
tyil so it's not about reinventing wheels 07:56
its about debugging whatever wheel is chosen
nine So?
tyil I just gave a suggestion and got a reasonably aggressive response which in the end turned out to be about something different 07:57
I'm just reiterating what its about
08:00 tejr joined 08:03 Kaiepi left 08:04 Kaiepi joined
nine I wonder how pointing out, that we have already solved the same problem elsewhere and ought not to repeat ourselves because of the chance to introduce bugs is aggressive, while sending patrickb a message that directly contradicts mine without acknowledging my message is totally fine. 08:05
lizmat_ m: dd "⌊{say "foo"}⌉".uniname # this had me stumped for a moment 08:47
camelia foo
"LEFT FLOOR"
lizmat_ m: dd "⌊{say "foo"}⌉".uninames # actually
camelia foo
("LEFT FLOOR", "LATIN CAPITAL LETTER T", "LATIN SMALL LETTER R", "LATIN SMALL LETTER U", "LATIN SMALL LETTER E", "RIGHT CEILING").Seq
08:49 lizmat_ is now known as lizmat 09:14 lichtkind joined 09:37 Altai-man_ joined 10:18 lichtkind_ joined
nine Of course, I don't get any answer either 10:20
10:20 lichtkind left 10:32 timotimo left, literal left 10:33 timotimo joined, literal joined 10:40 sena_kun joined 10:41 Altai-man_ left
samcv is there a way i can do a backtrace inside of rakudo? I tried using Backtrace.new but i think that class is defined too late, since it says it doesn't exist. I am trying to add a backtrace to consume-exactly-chars in src/core.c/Encoding/Decoder/Builtin.pm6 10:43
nine Yeah, Backtrace comes after src/core.c/Encoding/Decoder/Builtin.pm6 in templates/6.c/core_sources. Easiest way around that is to make a forward declaration: class Backtrace { ... } 10:46
lizmat put a die() in there and run with --ll-exception ?
samcv so i found (sorta) the bug in readchars. When readchars(1) happens, apparently it ends up getting called 3 times on the same IO::Handle, so then .seek ends up in the wrong place. so that is a bit weird. hopefully with a backtrace i can see where it's being called 11:06
lizmat ++samcv 11:09
11:10 Geth left, discord6 left 11:13 sena_kun left 11:15 sena_kun joined
samcv well. Backtrace.new is unhelpful. i'll try and a die and --ll-exception 11:15
11:15 sena_kun left 11:26 sena_kun joined
lizmat so, weird dispatch issue: 11:35
m: multi a(Any:D $a, Whatever) { dd "Any" }; multi a(@a,Mu \end) { dd "multi" }; a (1,2,3), *
camelia Ambiguous call to 'a(List, Whatever)'; these signatures all match:
:(Any:D $a, Whatever $)
:(@a, Mu \end)
in block <unit> at <tmp> line 1
lizmat apparently, the second candidate needs a "is default"
m: multi a(Any:D $a, Whatever) { dd "Any" }; multi a(@a,Mu \end) is default { dd "multi" }; a (1,2,3), *
camelia "multi"
lizmat but without the "is default", this *does* work 11:36
m: multi a(Any:D $a, Whatever) { dd "Any" }; multi a(@a,Mu \end) { dd "multi" }; a 42, *
camelia "Any"
lizmat thank you for rubberducking :-)
11:50 hungrydonkey joined 11:53 hungryd33 left 12:05 lichtkind_ is now known as lichtkind
samcv ok it seems more complicated than i thought. So i guess tell is talking about where we are in the file. then the decoder has a character position as well. and these things don't match up. causing it so you can't use readchars and seek together. i will have to think more about the best solution. since there's even more moving parts than i originally thought 12:13
.tell is only looking at the raw filehandle location minus the number of bytes still in the decoder. but the decoder also holds characters. but this is not factored in anywhere (currently). And i'm not sure how/where it should. will have to revisit this after work 12:14
tellable6 samcv, I haven't seen is around, did you mean iv?
jnthn Yeah, I think .tell only made sense as a "sync point" when reading text. 12:17
(That is, after a \n for example)
Otherwise, all bets are off.
12:33 hungryd82 joined 12:35 hungrydonkey left
[Tux] Rakudo version 2020.02.1-356-g561076437 - MoarVM version 2020.02.1-153-g9bb7a1850
csv-ip5xs0.902 - 0.910
csv-ip5xs-209.851 - 10.134
csv-parser26.215 - 26.327
csv-test-xs-200.382 - 0.384
test8.009 - 8.245
test-t2.756 - 2.769
test-t --race1.129 - 1.147
test-t-2048.185 - 48.640
test-t-20 --race12.525 - 12.741
 12:37
12:39 Altai-man_ joined 12:42 sena_kun left
hoelzro moritz: now that I think of it, I think there's only one real step - you just need to fork github.com/docker-library/official-images/, modify library/rakudo-star with the proper hash, tags, and revision information, and submit a PR 12:45
you can also remove me as the maintainer
[Coke] hoelzro: noooooooo 12:47
(ok)
hoelzro =( 12:55
I know...I want to make sure I hand off things so that they have a proper maintainer 12:56
too many things I've done are just on life support =(
moritz hoelzro: does that mean I need to push them as $my-own-user/rakudo-star first? 12:58
hoelzro moritz: yes
moritz ok, will try to do that soon
hoelzro sounds good, let me know if you have any more questions! 13:01
13:21 Kaiepi left
moritz hoelzro: one more thing -- what about the alpine image? do they get a different tag? or a different name 13:22
13:25 Kaiepi joined
hoelzro moritz: the alpine image? 13:56
moritz hoelzro: yes 13:57
the docker repo has an alpine/Dockerfile
and I can build that too
but I don't know how to publish it
hoelzro ah - I don't know anything about that
moritz ok, then it'll sit there, unpublished
hoelzro apparently it's on Docker Hub, so it *is* published
14:09 tejr left
moritz hoelzro: github.com/docker-library/official.../pull/7894 there you go 14:10
if you could leave a comment that you want to replaced as a maintainer by me, that might add credibility :D
14:16 tejr joined 14:30 squashable6 left, squashable6 joined 14:32 squashable6 left, squashable6 joined 14:38 eater joined 14:40 sena_kun joined 14:42 Altai-man_ left
hoelzro ok, will do! 14:42
moritz: thank you for taking perl6^H^H^H^H^Hraku-docker on! 14:43
lizmat hoelzro++ # for all the stuff they've done! 14:50
m: dd 1,2,3 ... *, 42, 666 # I think this should die saying it will never be able to produce 42,666 14:57
camelia (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65,…
moritz lizmat: if it can detect that, yes 14:59
lizmat yes, it can, at least in my re-implementation :-) 15:00
m: dd 1,2,*+1,7,6 ... 10 # should similarly die
camelia (1, 2, 3, 4, 5, 6, 7, 8, 9, 10).Seq
lizmat as it will never be able to produce the 7,6 15:01
timotimo i don't understand why it even works with the *+1 in the middle 16:13
i thought a generator can only appear directly before the ... operator 16:14
16:39 Altai-man_ joined 16:41 sena_kun left 17:01 maggotbrain left 17:46 guifa2 left
lizmat timotimo: yeah, that's the idea... but there is no check for it 17:47
18:03 hungryd82 left 18:40 sena_kun joined 18:41 Altai-man_ left
[Coke] is it ignoring everything between the generator and the *? 18:49
(and then again after the *?)
lizmat the 1,2,3, * + 1, 42, 666 ... 100 case, t would never reach the 42,666 part 18:55
the 1,2,3 ... *, 42,666 it would never reach the 42,666 part either 18:56
m: dd 1 ... 10, 42, 666 # perfectly od
camelia (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 42, 666).Seq
lizmat *ok
even if this feature is apparently not documented 18:57
but it *is* tested for in roast
MasterDuke nqp: say(nqp::tc("hello world")) # this is tested for, but why? 19:37
camelia HELLO WORLD
MasterDuke looks like it goes through and applies tc to all the graphemes. but method tc in rakudo just applies it to the first char and concats that with the rest of the chars. why don't we have nqp::tc do that? 19:46
lizmat m: dd "hello world".tc
camelia "Hello world"
lizmat that feels like a wrong result ?
MasterDuke seems like applying tc to every char in a string is likely to be a lot less common 19:47
lizmat I guess there's a subtle difference between uc and tc on all graphemes ? 19:48
MasterDuke maybe. but if you *really* want tc on all of them, i feel then you should have to do it manually 19:49
lizmat yeah, feels like that to me as well, and it would simplify the HLL version of .tc
MasterDuke but "hello world".tc eq "Hello world" is tested for in roast
lizmat which is what one would expect, no? 19:50
MasterDuke well, maybe "Hello World" 19:51
lizmat perhaps 19:52
MasterDuke and then "hello world".sc would eq "Hello world"
jnthn Isn't there wordcase if you want Hello World? 19:53
MasterDuke ah, there is. never saw that before 19:54
jnthn Thus demonstrating why it doesn't deserve a name so huffmanized as .tc :) 19:55
I belive .tc when first impl'd did titlecase every char, but that wasn't very useful, thus .tc now does nqp::tclc or some such
MasterDuke perl has ucfirst
jnthn I suspect .tc is the ucfirst successor 19:56
lizmat MasterDuke: yeah, but that's not the same
MasterDuke pretty similar
jnthn But yeah, there's a different between uc'ing the first char and tc'ing it
lizmat yeah, there is a subtle difference between titlecase and uppercase for a few unicode graphemes
MasterDuke "Returns the value of EXPR with the first character in uppercase (titlecase in Unicode)."
jnthn Ah, then maybe ucfirst does do titlecase afterall 19:57
lizmat there is no ucfirst in Raku 19:58
because it doesn't do the right thing
m: dd "DŽ".lc 19:59
camelia "dž"
MasterDuke github.com/rakudo/rakudo/blob/mast...3527-L3529
lizmat m: dd "DŽ".lc.uc
camelia "DŽ"
lizmat m: dd "DŽ".lc.tc
camelia "Dž"
lizmat m: dd "DŽ".chars 20:00
camelia 1
lizmat note the difference between uc and tc
even though it's a single grapheme 20:01
hmmm... did we lose Geth again ? 20:02
yep, looks like we lost Geth tyil ?
MasterDuke jnthn: btw, what started me on the path that ended at nqp::tc somehow. github.com/rakudo/rakudo/issues/3647 istr a similar problem coming up (if not an actual RT or github issue) and you had some commentary 20:03
but i don't remember what it was. is this just a case of DIHWIDT?
lizmat 5610416c87a95338c32f80
linkable6 (2020-04-28) github.com/rakudo/rakudo/commit/5610416c87 Make Str.tc about 10% faster
tyil lizmat: on it 20:08
lizmat tyil++
20:09 Geth joined 20:39 Altai-man_ joined 20:42 sena_kun left 20:43 Kaiepi left 20:44 Kaeipi joined 21:12 Altai-man_ left
MasterDuke when compiling CORE.c, in this branch github.com/Raku/nqp/blob/master/sr...136-L1176, `$list` ends up with 0 elems 1515563 times. also, 1075388 times $cselems is 1 (next most common values are 2 at 335871 and 3 at 73020) 22:22
does anyone have any optimization suggestions with this info? 22:23
22:48 lichtkind left 23:33 hungrydonkey 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!