00:06 librasteve_ left 00:08 arkiuat joined 00:12 arkiuat left
disbot7 <antononcube> Has 24th Day been claimed? 00:24
lizmat not to my knowledge.... fwiw, I have a backup post I could put in there, but would be glad to leave it to someone else :-) 00:25
00:35 arkiuat joined 00:40 arkiuat left
tbrowder if interested i have a snow flake in PostScript code which can be converted to other formats. 00:43
disbot7 <antononcube> SVG? 00:44
tbrowder i’m sure ChatGPT can do it. 00:45
i created it many years ago following the examples in one of Adobe’s printed books which i still have, 00:47
the book described in clear Adobe style all the PS functions with examples 00:49
00:50 arkiuat joined 01:24 arkiuat left 01:27 arkiuat joined 01:38 arkiuat left 01:44 arkiuat joined 02:34 hulk joined 02:36 kylese left 03:15 hulk left, kylese joined 03:37 sibl joined 04:18 lichtkind_ joined 04:21 lichtkind left 04:25 Aedil joined 06:55 phogg` joined, phogg left 06:56 arkiuat left 07:08 arkiuat joined 07:14 arkiuat left 07:30 sibl left 07:35 sibl joined 07:44 arkiuat joined 07:50 arkiuat left 07:52 sibl left, sibl joined 08:01 arkiuat joined 08:06 arkiuat left
disbot7 <simon_sibl> I just did a quick benchmark for an exercise I made with colleague for interview, he made it in Python and I made it in Raku, the speed difference is huge and I would like to know if thats expected or if my code is simply much less optimized: termbin.com/mgru 08:06
<simon_sibl> also the memory usage seems to be huge for Raku compared to Python 08:08
08:28 Sgeo left
ab5tract vushu: amazing!! Great to see you here again btw 08:31
08:33 arkiuat joined
ab5tract tbrowder: any chance that it is a dynamically generated snowflake? It would be amazing to have a .eps file that resolves to a new snowflake every time it is embedded :) 08:34
08:39 arkiuat left 08:43 arkiuat joined 08:47 arkiuat left 09:06 sibl left 09:14 donaldh joined 09:16 arkiuat joined, librasteve_ joined 09:21 arkiuat left 09:50 arkiuat joined 09:55 arkiuat left 10:27 arkiuat joined 10:33 arkiuat left 10:42 tejr left
tbrowder hm, probably so, i’m slammed right now but i could gist it here later. i’m getting ChatGPT to help organize my PS file collection and it will eventually be on my public github repo 10:54
10:55 arkiuat joined
tbrowder it’s created so the rotation angle and diam can be randomized. 10:56
lizmat simon_sibl OOC< how does it time with the printf() replaced by just interpolation, so: say $j<title> (prio $j<priority>): Submits at $j<submit>, starts at $time, ends at $ends. Wait time = $wait."
rather: say "$j<title> (prio $j<priority>): Submits at $j<submit>, starts at $time, ends at $ends. Wait time = $wait." 10:57
printf is notoriously slow because it runs a grammar *every time* it is called
also, it feels that the jobs has should be a proper class to reduce the number of hash lookups 11:00
11:00 arkiuat left
lizmat also, maybe raku.land/zef:lizmat/Concurrent::PriorityQueue ? :-) 11:00
11:05 tejr joined 11:10 ShimmerFairy left 11:15 arkiuat joined 11:21 arkiuat left 11:33 arkiuat joined
Geth advent/main: 2d07fe7b24 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | raku-advent-2025/authors.md
Update, slot 24 still open!
 11:39
ab5tract .vushu: next step may just be to add texture rotation based on the wind :) 11:40
11:42 arkiuat left 11:49 arkiuat joined
disbot7 <.vushu> @ab5tract maybe you can finish your up your project 😄 11:49
<.vushu> @grondilu thanks for the fix --force-install isn't necessary I just didn't bother uninstalling before installing. 11:50
11:53 arkiuat left 12:04 librasteve_ left 12:20 arkiuat joined
Voldenet simon_sibl: raku code allocates gigantic hash for every single element, so it's slow and memory hungry as expected 12:20
I mean, the hash is probably bigger than things it contains 12:21
12:24 arkiuat left
Voldenet `priority_stats[priority][0]` vs `%result{$j<priority>}` 12:25
on top of it, priority_stats uses int-based dictionary, hashes in raku allow only strings
that python is just a lot stricter about performance, raku code is stricter about readability 12:29
`priority_stats[priority][1] += 1` yeah totally :)
`%result{$j<priority>} += $wait;` uses <op>= metaop which adds some overhead too 12:30
12:32 arkiuat joined
Voldenet also, I'm not sure why none of these code snippets simply use classes for jobs if performance is important 12:33
classes are always huge win both in readability and performance, because they give code optimization opportunities 12:35
12:46 arkiuat left
Voldenet btw, I've looked at benchmark and it's ridiculous – you're comparing runtime of processes that take 5ms 12:53
ab5tract Great points, but I want to clarify that object hashes do exist
Voldenet using that methodology can lead to enlightening thought that js is faster than rust :>
since compilation would take time
ab5tract: by "object hashes" you mean hashes that contain object's data or hashes that are shaped like an array by some optimization? 12:58
ab5tract m: my %h is Hash[Int,Int]; dd %h{121} = 42 13:00
camelia Int = 42
ab5tract m: my %h is Hash[Int,Int]; dd %h{“121”} = 42 13:01
camelia Type check failed in binding to parameter 'key'; expected Int but got Str ("121")
in block <unit> at <tmp> line 1
disbot7 <antononcube> @simon_sibl Well, thanks for putting the benchmark together. I hear that Raku can do it (or some of it) faster, which — hopefully — means that someone can re-write it.
13:02 ShimmerFairy joined
disbot7 <antononcube> @librasteve Is there a performance page in raku.org ? Some of the points @Voldenet made above might be good to be there… 13:04
13:06 arkiuat joined
Voldenet ab5tract: is that implemented on nqp level? Because if not it wouldn't beat python's dictobject (which uses C) 13:09
in nqp I can only find string-based hash
13:11 arkiuat left
lizmat there is only a string based hash 13:14
all other hash types, such as object hashes, under the hood revert to a string 13:15
a hash with keys limited to Int, is basically an object hash with a constraint on the key
so slower 13:16
Voldenet though in theory it is possible to implement hashtable in pure raku 13:20
and in theory it doesn't have to be slower than C 13:21
lizmat my reference to "so slower" is about the current implementation :-) 13:24
13:24 arkiuat joined
lizmat now if objects of value types would share their unique values, we could use the object id as a key in the hash 13:25
but unfortunately, they don't
Voldenet you can expect boring equality contract to be implemented 13:26
hashCode + equals
disbot7 <librasteve> @antononcube there is no performance page on raku.org --- the goal of raku.org is to convert new potential raku users, so doesn't really belong there imo --- I would support a Performance page in the docs (docs.raku.org/introduction) with an emphasis on how to avoid the pitfalls listed above. 13:27
Voldenet I remember TypedHash using .WHICH which usually requires some serialized string, I'm not sure if that's still valid
disbot7 <librasteve> oh - there is one already => docs.raku.org/language/performance..._your_code 13:28
<librasteve> so - suggest we gather anything missing and apply as a PR to that docs page 13:29
<librasteve> @simon_sibl - note the performance page in the docs ^^
13:29 arkiuat left
lizmat Voldenet: that's how object hashes work 13:29
disbot7 <librasteve> may help to improve, I have used the profiler from time to time
13:30 librasteve_ joined
Voldenet …wait, so does that mean that typed int hash is slower than regular hash? 13:30
m: my %h is Hash[Int,Int]; for ^100 { %h{$_} = $_ + 2; }; say now - BEGIN now
camelia 0.0347615
Voldenet m: my %h is Hash; for ^100 { %h{$_} = $_ + 2; }; say now - BEGIN now 13:31
camelia 0.015954565
lizmat yup
I once wrote raku.land/zef:lizmat/Hash::int
Voldenet yeah, I remember, it was wildly faster because of nqp ops
lizmat but I'm afraid the performance advantage has largely evaporated after the new dispatch 13:32
Voldenet I'm starting to wonder if `role Equatable` and regular list-based hashtable wouldn't be fast enough to beat string-based Hash for ints 13:35
lizmat I vaguely remember trying that... I think as soon as you hit 10+ keys, hashes were actually faster 13:38
disbot7 <antononcube> @librasteve The profiler has been pretty useless for me, lately. 13:39
lizmat the overhead of the MoarVM runloop quickly kicks in compared to C code that goes to the metal
13:39 arkiuat joined
Voldenet eh so the only "sane" option would be having actual nqp objecthash 13:40
or nativecall one 13:41
lizmat well, the expensive thing is still the .WHICH calculation
which is HLL
Voldenet .WHICH is actually not HASHCODE
it can't has collisions, hashcode can - this is actually big requirement for performance here 13:42
s/has/have/
lizmat well, a collision in .WHICH just means that two objects are going to be considered identical, even if they maybe aren't because of a deficiency in the .WHICH creation 13:43
Voldenet and that contract is insane for hashcode imo, this can never work well 13:44
erm, for typed hash
13:45 arkiuat left
Voldenet WHICH basically does string serialization, so resulting strings has to be bigger and more inefficient 13:49
it could be faster in case where object would do a lot of dereferencing to get into data and all those pointers are non-cached anyhow 13:50
though I wouldn't bet on it being faster and smaller 13:51
13:54 arkiuat joined
Voldenet hm, I'm going to test my assumptions and see if I can make it faster Hash using raku only 13:55
lizmat yeah: I've done a lot of (perhaps premature) optimization in that area in the core
++Voldenet looking forward to the results, even if they turn out to be negative!
Voldenet if they turn out negative, I see if I can implement nqp::hashcode or something to make it fast enough 13:56
I could also use tiny wrapper over std::unordered_map 13:58
I'm betting I can beat hashes if I punch the problem with enough C/C++
13:59 arkiuat left 14:24 arkiuat joined
disbot7 <antononcube> @lizmat I nominate the packages (1) "Math::NumberTheory" and (2) "LLM::Graph". 14:25
<antononcube> I am wanted to nominate "App::samaki" -- I really like the described idea and functionalities -- but I cannot install it. 14:26
<antononcube> I assume "App::samaki" would be nominated by someone who has already installed and used it. 14:27
lizmat antononcube thanks, added 14:31
14:31 arkiuat left 14:32 arkiuat joined 14:37 arkiuat left 14:41 arkiuat joined 14:45 arkiuat left
disbot7 <antononcube> @lizmat and @librasteve I am going to propose a few posts: 1. Labyrinth making (with graphs) 2. LLM generated images over code of this year's advent posts 3. Who has the better highlighter (again) 15:04
<antononcube> They are given in preference order, but I am open to suggestions. 15:05
<antononcube> The 2nd one would have been "easy" if all of the posts had links to Markdown sources. (I know it is not how many of were written.) 15:07
15:07 arkiuat joined
disbot7 <jubilatious1_98524> @lizmat Raku doesn't have an Int -based hash? (not that I would be able to write one... ). 15:11
lizmat raku.land/zef:lizmat/Hash::int is the closest thing 15:12
15:12 arkiuat left
disbot7 <jubilatious1_98524> @lizmat Cool, thanks! 15:12
<jubilatious1_98524> Ruminating... Would a 1-indexed Int-based hash make sense. Basically that would reserve the 0-index to signify Empty hash. Any hash experts around? 15:15
<aruniecrisps> I do wonder if it wouldn't be useful to have a changemark function that allows you to change the mark on a character 15:33
lizmat please note that 6.e already provides a .nomark method 15:37
m: use v6.e.PREVIEW; say "élève".nomark; 15:38
camelia eleve
15:41 arkiuat joined
disbot7 <aruniecrisps> Do you think I could use that to make the changemark or samebase function? 15:47
15:49 arkiuat left
lizmat I'd say, it's a start? 15:50
15:50 phogg` is now known as phogg
lizmat m: use v6.e.PREVIEW; .say for "élève".comb>>.nomark 15:50
camelia e
l
e
v
e
lizmat antononcube does that mean I'm off the hook for tomorrow ? If so, thanks! :-) 15:57
the overview is becoming slightly monstruous in size :-) 15:58
16:18 arkiuat joined 16:23 arkiuat left
disbot7 <antononcube> @lizmat Yes. I will finish 24th Day within few hours. 16:26
lizmat antononcube great, means I have more time for the review! 16:27
16:37 arkiuat joined
tbrowder antononcube: i don’t understand exactly how you define a “happy number”. could you explain a simple one for a math dummy? thnx 17:06
ok, i see it now… 17:10
i didn’t grok where the first (e.g) starting number came from until i stared at it a while—duh 17:17
17:24 librasteve_ left
Geth Papers/main: 50323551c2 | (Elizabeth Mattijsen)++ | minutes/20251220.md
Minutes of the 20 Dec meeting
 17:46
Papers/main: b60b6dc8e2 | (Elizabeth Mattijsen)++ | announcements/20251223.md
Announce Stefan Seifert stepping down from RSC and CAT
 17:48
disbot7 <antononcube> @tbrowder " i didn’t grok where the first [...]" -- common experience when one reads mathematical papers... 😎 18:04
lizmat github.com/Raku/problem-solving/issues/508 18:06
Make $ sigil optional for scalar variables in 6.e
18:13 arkiuat left 18:16 arkiuat joined 18:21 arkiuat left 18:31 Pixi left 18:39 Pixi joined 18:50 arkiuat joined 18:55 arkiuat left
Voldenet lizmat: so, trivial linear probing hashtable beats 19:11
erm, I was about to finish the message
trivial linear probing hashtable beats Hash[Str, Foo] for very large values
I had to add "trivial" because the implementation doesn't use any particular tricks (maybe apart from not handling the fact where linear probing fails) 0x0.st/Pzjf.raku 19:13
output on my box is `LinearHashMap[262144] ADD 1.205950509 GET 0.53381213 MEM 601 // Hash[Str,Foo][262144] ADD 1.748837529 GET 0.720105764 MEM 15479` 19:14
of course, it only works for very specific conditions and removal is going to be extremely poor with collisions 19:16
lizmat actually... maybe the typecache can be abused for a quick integer lookup
an nqp::istype under the hood, is nothing more than an integer match on an integer array, containing the object IDs of all classes / roles involved 19:17
I wonder whether it would make sense to create an nqp op for this kind of fast lookup, rather than abusing the typecache for this 19:19
timo ^^ does that make sense ?
deletion could be just zeroing out the entry
Voldenet if hash could be used directly for HASHCODE it would be major win, but then you have to deal with EQUALS as well sadly 19:20
nqp::atkey(%h<>, "foo") and nqp::atkey(%<>, "colliding-foo") work in string case, because atkey handles it 19:22
lizmat not sure what you mean 19:23
Voldenet nevermind, I re-read that
19:23 arkiuat joined
Voldenet I was too deep in the problem and thought about nqp::atkey_numeric which is wrong in the context 19:24
19:28 arkiuat left
lizmat I was thinking about an nqp::isin_i(int $needle, int @haystack) returning the index where needle was found, or nqp::elems(@haystack) if not 19:29
disbot7 <aruniecrisps> lizmat: I have a counterargument to the no sigils default: the dollar sign sigil doesn't seem to be a deterrent for PHP 19:32
lizmat well... perhaps: but please leave these comments in the issue (if you can :-) 19:33
Voldenet I have tried doing `role HashMap[$cap] { … }` but native arrays are slower 19:34
…?! 19:35
lizmat native arrays can be slower if they need repetitive HLLizing of value
s
Voldenet Ah: 0x0.st/PzjD.raku
lizmat if you're using Ints instead of int, they don't need HLLizing 19:36
Voldenet I'm storing `Foo` as key and `Str` as value, so I'm assuming no HLL needed
lizmat have you tried has str @!keys instead of has @!keys; ?
also, return comes at an exception throwing cost 19:37
in many cases in the core, I use the trick of a loop variable being incremented, and then exit when a condition is met, and then do a ternary on the value of the loop variable 19:38
Voldenet m: role N[::TValue] { has TValue @!x; }; N[Int].new 19:39
camelia MoarVM panic: Memory allocation failed; could not allocate 131072 bytes
Voldenet …should it do that?
lizmat that feels wrong and worthy of an issue 19:40
Voldenet issue issued github.com/rakudo/rakudo/issues/6056 19:45
lizmat Voldenet++ 19:46
Voldenet if parametrized role was performing better, maybe resize could be implemented by storing role inside a class 19:49
19:50 arkiuat joined 19:59 arkiuat left 20:12 arkiuat joined 20:17 arkiuat left 20:36 arkiuat joined
timo it's infini-recursing on from src/Perl6/Metamodel/GenericHOW.nqp:24 it looks like (instantiate_generic) 21:05
doesn't need the `N[Int].new` either, it already explodes in the parse stage when it encounters the declaration of @!x 21:08
gist.github.com/timo/77a790d0f0f9e...b56a541e0d last couple of lines of the backtrace 21:11
committable6: releases role N[::TValue] { has TValue @!x; }; say "success"; 21:13
committable6 timo, gist.github.com/168c67f4c1cc5533b2...7ea183b3e5 21:17
timo bisectable6: good=2023.11 bad=2023.12 role N[::TValue] { has TValue @!x; }; say "success"; 21:18
bisectable6 timo, Bisecting by exit signal (old=2023.11 new=2023.12). Old exit signal: 0 (None)
21:18 bisectable6 left 21:22 bisectable6 joined
arkiuat I just discovered github.com/Raku/raku-most-wanted but it hasn't been touched in two years, and most of the content is older than that. What's the story? 22:39
23:22 Sgeo joined
lizmat antononcube I don't see a draft yet for the advent post, is that correct ? 23:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!