🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
disbot7 <antononcube> @liznat I am wrapping up the first version-- I will schedule it / publish it within 1 hour. 00:04
<antononcube> I will post the final version by midnight ET.
<antononcube> I.e. within 5 hours. 00:05
<aruniecrisps> lizmat: what is the general timeline for 6.e's release? 01:04
[Coke] "when it's ready" 01:12
We have a list of items that need doing, and a limited base of core developers to hack 01:13
disbot7 <aruniecrisps> gotcha so there's no tight deadline 01:22
01:40 arkiuat left 01:48 arkiuat joined 02:15 notable6 left, notable6 joined, bisectable6 left, shareable6 left 02:16 evalable6 left, committable6 left, quotable6 left, greppable6 left, nativecallable6 left, releasable6 left, coverable6 joined 02:17 committable6 joined 02:18 unicodable6 joined, evalable6 joined, bloatable6 joined, notable6__ joined, linkable6 left, nativecallable6 joined, greppable6 joined 02:19 quotable6 joined, sourceable6 left, shareable6 joined, benchable6 joined, notable6 left, sourceable6 joined 02:20 releasable6 joined, linkable6 joined, bisectable6 joined 02:21 tellable6 joined 02:34 hulk joined, kylese left
disbot7 <antononcube> @lizmat Published. (I forgot to add "Day 24 -- " initially.) 02:40
03:15 hulk left, kylese joined 04:17 lichtkind__ joined 04:20 lichtkind_ left 04:39 arkiuat left 04:40 arkiuat joined 04:46 arkiuat left 04:47 arkiuat joined 05:16 Aedil left 05:26 Aedil joined 05:49 human-blip left 05:51 human-blip joined 07:31 arkiuat left 07:44 arkiuat joined 07:50 arkiuat left 07:53 arkiuat joined 07:57 arkiuat left 08:33 librasteve_ joined 08:42 arkiuat joined 08:47 arkiuat left 08:48 arkiuat joined 08:53 arkiuat left 08:59 Sgeo left 09:05 arkiuat joined 09:09 arkiuat left 09:29 arkiuat joined 09:34 arkiuat left 10:00 ShimmerFairy left 10:03 arkiuat joined 10:08 arkiuat left 10:31 arkiuat joined 10:36 arkiuat left 10:42 ShimmerFairy joined
Geth raku.org: librasteve++ created pull request #285:
Vendor the Butterfly image, Pin to Air:ver<0.0.2>		 10:52
disbot7 <librasteve> NB: that's Air:ver<0.1.2> 10:58
lizmat yeah, I checked :-) 11:00
11:06 arkiuat joined 11:11 arkiuat left 11:15 arkiuat joined 11:19 arkiuat left
librasteve_ Umami stats for new raku.org usercontent.irccloud-cdn.com/file/....33.32.png 11:34
Same - but daily view (showing early peak driven by HN announcement) usercontent.irccloud-cdn.com/file/....32.49.png
lizmat: maybe some visuals for your state of the onion post 11:35
lizmat why the country is not Singapore? 11:45
perhaps better next year, so we can do comparison ? 11:47
as we don't have a comparison with the old site ?
11:49 arkiuat joined 11:54 arkiuat left
librasteve_ I don’t know if we have stats for old site - sorry 11:55
lizmat we don't afaik
librasteve_ on SG - I am sceptical that we get the reported number of visitors from there … in sample I am looking at Singapore is 1.32k, US 996, China 294, Germany 242 … it is known as wild west for site scammers 12:01
and SG is all concentrated into certain dates (seems to have subsided now) 12:03
it’s quite interesting to see that the site gets about 100 unique visitors / day on average and that about 6% go to the Install page … wonder if there’s a way to get rakubrew download stats to correlate? 12:10
and 5% to community
lizmat patrickb might be able ? 12:11
Geth raku.org/main: 9 commits pushed by librasteve++ 12:13
12:16 arkiuat joined 12:20 arkiuat left 12:48 arkiuat joined 12:53 arkiuat left 13:17 arkiuat joined 13:22 arkiuat left 13:51 arkiuat joined 14:00 arkiuat left 14:18 arkiuat joined 14:23 arkiuat left 14:29 arkiuat joined 14:37 arkiuat left 14:50 arkiuat joined 14:56 arkiuat left 15:15 arkiuat joined 15:17 Aedil left 15:23 arkiuat left, itaipu left 15:27 itaipu joined 15:52 arkiuat joined 15:57 arkiuat left 16:05 arkiuat joined 16:12 arkiuat left 16:23 arkiuat joined 16:28 arkiuat left 16:31 arkiuat joined 16:36 arkiuat left
tbrowder ok, 16:38
16:40 arkiuat joined
tbrowder that last advent post by antononcube is something that would help to attract new coders--as they say 16:42
good job!!
disbot7 <antononcube> Thank you! I was considering inscribing "2026" or snowflake(s) onto the mazes but that is too much work. (Both to program and to explain.) 16:44
16:45 arkiuat left
disbot7 <antononcube> So, I opted to just generate an image of a raccoon in snow-covered maze. 16:45
tbrowder anyone know how to do that with Python? a comparison of the two methods would make a good pitch for Raku
16:46 arkiuat joined
tbrowder using more that 16:46
*than core packages 16:47
disbot7 <antononcube> Well, Python has interfaces to powerful graph librararies written in C and C++. So programming the core ideas is not that hard. What would be hard it the graph plotting and finding geometric nearest neighbors. For the latter, most likely some of the big Machine Learning (ML) libraries have to be used. 16:49
tbrowder maybe when i get the PS snow flake code public it can help-your pic is very nice as is is
disbot7 <antononcube> The problem is making a large enough maze over the vertices on which to project a word or a snowflake. 16:50
<antononcube> Even if that is done the maze itself might too hard to solve or too messy to look at.
<antononcube> Meaning, a fair amount of experimentation has to be done in order to produces good results. 16:51
<antononcube> (Which I decided, is too time consuming.)
tbrowder oh, i see, i was thinking you meant snowflakes falling...but still, mine may be useful--lizmat and librasteve and jmerelo see them on our Christmas poem 16:55
korvo tbrowder: Finding spanning trees isn't in Python's stdlib, but everything else is. Graphs are usually represented as an adjacency structure. 16:57
tbrowder only equal hexagonal pieces of filled traiangular and rectangular areas, no curved lines 16:58
16:58 arkiuat left
disbot7 <antononcube> I have plans to hook igraph (igraph.org) to Raku. That C-library has interfaces Python, R, and Wolfram Language. 16:59
<antononcube> @korvo It is not just the spanning tree finding. There are fair amount of "convinience" functions that have to be in place too. (The maze making.) 17:00
korvo antononcube: Sure, precisely reproducing that blog post with Python would be a chore. However, I don't think that that's a good comparison of languages. 17:01
disbot7 <antononcube> For example, subgraph, graph union, finding neighborhood graphs, etc.
korvo TBH if y'all were to invest into a fast Raku then you could handily beat Python just by advertising speed. CPython is notoriously slow and its maintainers aren't interested in making it structurally faster.
17:01 arkiuat joined
korvo ...To be *too* honest, I'm mostly blocked on thinking up a good name for Raku in RPython, or NQP in RPython, but I'm willing to do the JIT parts. 17:02
disbot7 <antononcube> The maze making blog post can be more or less precisely translated to Wolfram Language (WL).
<antononcube> I was planning to do that today, but I started doing some surface fitting with WL... 17:03
<antononcube> @korvo Related to your language comparsion point -- that is a good reason to "igraph"-based implementations. They can transfered easily between Python, R, and WL. 17:04
korvo I suppose. That sounds completely uninteresting to me, but I can understand why people would want it. FWIW as one of the igraph maintainers for nixpkgs I would recommend against it; it works but it's brittle and unsafe. 17:05
Similarly, basic operations like subgraphs or unions are done with one-liners. Python has comprehensions (from Setl, I think) and it's not hard to build a new adjacency structure from old ones. 17:06
disbot7 <antononcube> Interesting point about the brittleness of "igraph" ! 17:07
<antononcube> No, subgraphs and unions are not one liners. 17:08
17:10 arkiuat left
disbot7 <antononcube> @korvo Do you know any published discussion on the brittleness of "igraph" ? 17:13
<antononcube> I am very interested in reasons not to use it.
17:20 arkiuat joined, Chris3101 joined
korvo Nope. It's just the opinion of one distro maintainer who had to use it for a while. 17:28
disbot7 <antononcube> Ok. 17:37
timo korvo: are you interested in looking at moarvm's specializer and JIT compiler? 17:41
korvo timo: A little. However, I specialize in RPython. (The other option out there is GNU Lightning, which can be much faster if it aligns with the high-level language.) 17:42
My next RPython project is planned to be a uxn interpreter. I could be persuaded to do something else. 17:43
timo neat. i was also quite into pypy a couple of years ago 17:45
korvo I'm all-in on RPython. I've looked into the options and I think that it's the best power-size ratio of the JIT compilers. I have a Nix flake with quite a few RPython interpreters available: github.com/rpypkgs/rpypkgs 17:47
timo whole-program type-inferrence is definitely interesting, and fully automatic root finding is convenient 17:49
i assume that also means you're not that interested in going down to the assembly level? 17:51
korvo I can do assembly, but not for free. Do you have a list of goals or tasks somewhere? TBH I usually have to be personally motivated by having hardware on hand, which usually leads to a relationship with a vendor willing to ship me the hardware in question. But I've written e.g. GPU drivers and embedded ARM drivers. 17:53
FWIW my Raku experience on amd64 has been that it is *fast enough* for my purposes, particularly when it comes to parsing. I'm satisfied already. 17:54
timo i don't exactly have a task in mind, really just offering to answer questions or show you around if you wanted to tinker 17:56
the bigger wins in performance are probably not in the emission of machine code but in making the specializer able to do more powerful analysis and transformations
korvo I am somewhat interested in knowing what the lowest portable substrate is; NQP, MoarVM bytecode, or something else? Even ignoring my personal work for a moment, I gather that Raku is a specification given by a pile of executable tests, and also that there's currently only one implementation passing those tests. It'd be good to know the natural layer from which to start a second implementation. 17:57
timo building something that runs NQP is probably a good start if you want to reuse big chunks of rakudo? 17:59
but if you're willing to not reuse a lot, you can go straight for a Raku compiler and ignore NQP entirely 18:00
korvo Both Raku and NQP seem like enormous targets. For NQP, that's mostly due to pre-specialized bytecodes; could those be unspecialized for a slower interpreter with less code, or is there a philosophy to it? 18:01
timo on moar we turn both nqp and raku code into moar bytecode and that is interoperable, so a function or method written in one can call the other and vice versa
how do you mean "pre-specialized bytecodes"? are you refering to the nqp::blah stuff you see in the code? 18:02
korvo Yeah. Like, the bytecodes correspond to type information from the input language rather than the hardware target.
18:03 Staff_Virgil joined
Staff_Virgil [Network Announcement] God will never leave Russia, he will continue to gift Russia his divine protection - watch President Putin's Christmas speech at www.youtube.com/watch?v=NdQA0BlZwtY. Death to Trump, Elon, Zelenskyy and other fascists. Merry Christmas from the Libera staff! 18:03
timo you're at the level of moar bytecode right now? 18:04
18:04 vrurg_ joined
timo i'm not sure if you mean things like atpos_i or things like extend_u8 or whatever 18:04
18:04 Staff_Virgil left
korvo I'm looking at NQP, I think. Specifically github.com/Raku/nqp/blob/main/docs/ops.markdown 18:05
18:05 vrurg left
timo ok, a bunch of moarvm opcodes are exposed as `nqp::blabla(...)` function-like things to be used in nqp as well as raku code 18:07
you'll want to know a little bit about the metamodel, especially REPRs, to really make sense of that stuff I think 18:08
korvo Basically, I'd like to know what the minimal collection of ops actually is. I'm used to Self-style VMs that have maybe a dozen ops: lookup local by name, create closure/object, prepare/pack message, call immediate, send deferred. 18:09
Generating hundreds of type-specialized ops is possible; e.g. Faster CPython does it as part of their JIT strategy. If that's the case then I'm interested in how they're currently generated because any RPython codegen would have the same shape. 18:11
timo i'm not sure anything stops you from making everything related to reprs behave more like method calls, then that would move stuff from the ops namespace to a real namespace visible to the language 18:12
moarvm gained a "syscall" mechanism where you can call something by its name with different callsites if you like, and a good portion of the ops in moarvm could easily be moved to that mechanism if the right shaped tuit appears 18:13
it does encode to bigger bytecode though, and is probably a bit slower to dispatch 18:14
so that would be fine for things your code doesn't have to do tens of thousands of times a second, like "get attribute from object" or "add two integers"
^- "wouldn't be fine"* 18:15
korvo I suppose I'm a little surprised that there's not a single bytecode-caching mechanism like in Python or OCaml. I feel like perhaps there was a design goal of making MoarVM have that shape, but I didn't find a single document that says how to load and interpret a precompiled bytecode file.
timo we do store precompilation results, the classes related to CompUnitRepo are responsible for all that machinery 18:16
18:16 Chris3101 left
timo the bytecode files that we precompile can't run completely on their own, they need a rakudo already loaded around them 18:16
korvo That sort of named-syscall dispatch would be fine in RPython. RPython costs are based on what the JIT can and cannot remove; there's no big difference between a constant string lookup in a dict vs. a constant index lookup in a list, for example.
timo right, it deeply traces stuff 18:17
korvo Ah, okay. More like CL's FASL and less like OCaml's bytecode, sounds like. FASL is prelinked somewhat with the CL runtime.
timo yeah our bytecode files refer to objects and types in bytecode files they depend on by an index in their tables, making the dependency extremely tight 18:18
korvo Given the list of NQP ops -- threads, Unicode, I/O, floats, nativecall -- it seems like it *should* be possible to bootstrap any sort of HLL just from bytecode. 18:19
timo you mean building a set of .moarvm files that runs, for example, python code?
korvo Oh! Okay, I've seen this pattern before. It arises in e.g. Capn Proto; the Capn Proto algorithm is fully documented *except* for the precise mapping of names to indices, which is withheld in order to force users to depend on the official Capn compiler. 18:20
18:20 bwani54 joined
korvo Sure, that's a possibility. I would work on the other side of that API barrier, implementing an alternative VM that faithfully runs .moarvm files. 18:20
timo unfortunately, the serialized blob inside moarvm files isn't specified by anything other than moarvm's source code, and the serialization format doesn't describe itself either 18:21
but there's nothing stopping you from writing out something different from .moarvm files, it's all written in nqp code except where it asks moar to "please dump the serialized blob now" 18:22
nqp-moarvm was used to compile the compiler and runtime for nqp-js by adding a different output stage in the compiler pipeline 18:23
korvo That's what I gathered. At that point, it seems like RPython might as well be a target. And at *that* point, I'd ask whether we might as well have QBE (or LLVM, I guess) as a target!
timo then when nqp-js was fully featured enough it could compile itself, at least if i remember correctly
korvo RPython has much nicer support for threads and Unicode than QBE. It doesn't have exactly the same object model as any HLL, but it can easily emulate them and there's a straightforward recipe for doing it. 18:24
timo i don't know what QBE is though
korvo Oh, sorry. Quick BackEnd. Like LLVM but smaller and much much simpler. c9x.me/compile/ 18:25
RPython, QBE, and LLVM all share the principle that one ought to be able to generate human-readable text and feed it directly into the backend to generate a native executable.
timo OK 18:26
korvo timo: Anyway, thanks for humoring me. It's a fun thought experiment. 18:29
timo regarding your question of how moarvm does specialization, I'd probably direct you to jnthn's talks. I believe "How does deoptimization help us go faster?" is one of the talks that has a good overview of the specializer at the start: jnthn.net/slides.html this has slides and also video recordings
18:30 bwani54 left
timo in short, many operations record information at run time, and there's a specializer thread that collects that stuff, figures out what frames are worthwhile to make a specialized variant of based on, for example, incoming arguments, and then it can make assumptions with deoptimization guards and such 18:31
it works in an SSA form with BBs that you've probably seen thousands of times before
"Giving MoarVM a new general dispatch mechanism to speed up various slow Raku constructs" shows our new dispatch system that is practically required if you want to get the more complex interactions of features like multiple dispatch with "nextsame" working in your own implementation 18:32
(but is also nice for performance) 18:33
18:35 Aedil joined
timo oh, and the NQP And Rakudo Internals Workshop material is probably also very valuable, even though it was at a time when moarvm was brand new 18:37
korvo timo: Okay. That sort of cycle is definitely the sort of thing that I'd like to fully absorb in RPython rather than reify; RPython's internals are fairly close to that, with the biggest difference being how the JIT interacts with threads.
How meta is the metainterp? Can the NQP toolchain be asked to compile itself to a backend? 18:38
timo you can probably benefit from small polymorhpic inline caches in your version of bytecode
so far it hasn't been necessary to use the nqp built for one backend to compile to a different backend except for the initial bootstrap, so i'm not sure if the necessary stuff is exposed like with CLI flags or something 18:40
but nqp does compile itself to *a* backend every time you build it :P
korvo Well, it's just that it sounds like it'd be easier to not write one NQP interpreter in RPython, but instead write an NQP backend that can compile any input to RPython, and then generate an NQP JIT as a special case. 18:41
Inline caches are curious. Once the JIT's paths get hot enough, it's often cheaper to ask the JIT to do a linear search for methods when it is tracing and let the JIT memorize the results of that search. An example from my Monte language, a flavor of E: github.com/monte-language/typhon/b...#L168-L183 18:42
I notice that all of the backends seem to have three levels of interaction: HLL, NQP, QAST. All are required? 18:43
timo i'm not exactly sure what you mean by that 18:44
QAST is the datastructure we work with that's relatively close to the target, but still abstract enough to mostly generalize, with an escape hatch if it's needed
QAST is very tree-shaped, the next step in the pipeline for moarvm would be MAST which is much more linear and refers to things like labels and registers, whereas QAST has local variables and ops like "if" that have condition and different branches just as children 18:47
but i'm not sure how HLL and NQP fit into this list
there's a bunch of differences between a piece of code compiled to a raku sub or method and the same for nqp: different type objects are used for Code / Routine / Method, the "hll" is set to a different one on the underlying code object, the roughly same code in raku vs nqp is compiled differently because the languages have different semantics, and when calling between different HLLs like nqp vs raku 18:50
there's hllization of common objects like Array, Capture, etc
korvo I'm just trying to understand what a backend should be shaped like. Is it possible to work only with QAST, or is that escape hatch regularly required?
timo you can work only with QAST with the caveat that you would put objects in there as well which is how they get to become serialized and make it from the compiler's environment and re-appear fully formed in the target program 18:52
long long ago before bounded serialization was a thing, rakudo would spend a big chunk of time at startup creating all the classes and such by calling metaobject methods for everything 18:53
korvo Hm. I figure that it's unavoidable to have a pre-written RPython class which represents "user" objects; the code for a user object is 100% live and must be JIT'd. But there's also "prebuilt" objects and various ways of setting them up so that they're translated and baked into the executable. 18:54
There's also, as in the RPython implementation of SOM Smalltalk, the ability to directly save a bytecode file as a string in the executable.
timo i'm not sure what level of meta we are at right now
moarvm offers a very simple REPR and metaobject that has very simple attributes and a very simple method table called KnowHOW 18:55
korvo I'm still thinking about replacing MoarVM only. Specifically thinking of an NQP backend which emits RPython.
timo github.com/MoarVM/MoarVM/blob/e419...rap.c#L290 18:56
korvo Yeah. I'm familiar with Piumarta, Warth, et al and I know how to write that sort of core metaobject. I'm still learning Raku's metamodel but fortunately there's a battery of specification tests that will force me to get it right.
timo is that the paper about the CLOS? 18:57
korvo Yeah. COLA, Pepsi, etc.
That C looks quite familiar. Somebody's gotta populate a vtable somewhere. The alternative would be something like E-style auditors, where the knot is tied based on the ability to prove that an object is immutable; the stamp of immutability must itself be immutable. 18:58
github.com/monte-language/typhon/b...py#L37-L40 18:59
timo i am not familiar with any of that
but yeah, building this kind of thing is always fun. bring your circularity saw! 19:00
disbot7 <librasteve> wonders if Raku could target LLVM and notes that the JVM is quite complete, but has lacked the same amount of resource as MOARVM 20:07
[Coke] ah, it's the biannual "hey, why don't we target LLVM?" question! 20:09
I cannot remember how to arrive at the answer, but I'm pretty sure the answer has been "it's not as easy or helpful as you might think"
korvo I'd hope that you don't think that I actually asked that. 20:11
20:40 nsjconrio34h joined, ivvi4pcvexk3 joined, c52fhkmo5rj3 joined, d4m7pkq5qbzd joined, d4m7pkq5qbzd left, c52fhkmo5rj3 left, nsjconrio34h left, ivvi4pcvexk3 left
timo looks to me like coke was refering primarily (or exclusively) to steve's last message 20:46
20:47 xpxltkvxgyuw joined, qbf5xiyksuxo joined, mxrpveqqquil joined, gdpklryv3rh6 joined, oc2eeacipfyz joined, mxrpveqqquil left, xpxltkvxgyuw left, qbf5xiyksuxo left, gdpklryv3rh6 left, oc2eeacipfyz left 20:51 ns4t2nx4ft7a joined, xinming left, bvxurkgo2fnb joined, vayba5xskwwm joined, kjpg3pd5j3x6 joined, dwqjxtnfdwqc joined, k4vxbi6omzhy joined, q44uqrmzhfor joined 20:52 u23ex2x4d6es6 joined, fnjefo3sprct joined, dwqjxtnfdwqc left, xinming joined, u23ex2x4d6es6 left, vayba5xskwwm left, ns4t2nx4ft7a left, fnjefo3sprct left, bvxurkgo2fnb left, q44uqrmzhfor left, k4vxbi6omzhy left 20:53 kjpg3pd5j3x6 left 21:09 oxonwg7ahlof joined, oxonwg7ahlof left, i6fckemdno7j joined 21:10 Sgeo joined, jftg53vk377e joined, i6fckemdno7j left 21:11 milxphupuq3j joined, jftg53vk377e left, yrkyceyy5z3h joined 21:12 yrkyceyy5z3h left, jghd6qozz6pp joined, jghd6qozz6pp left 21:13 milxphupuq3j left
timo christmas eve is surely the best time to harass random channels with nonsense 21:16
disbot7 <antononcube> 🤣 21:17
21:20 u5t5envy3txjd joined, wqmyljwtpbql joined 21:21 u5t5envy3txjd left, wqmyljwtpbql left, Sgeo_ joined 21:22 s2pogdsd5rng joined, omhqggk6jyt2 joined 21:23 omhqggk6jyt2 left, w4h6inypl5nm joined 21:24 Sgeo left, w4h6inypl5nm left, z35fdrvzvmry joined 21:25 z35fdrvzvmry left, dtermaparf3y joined 21:26 dtermaparf3y left, guc5wl4iddfj joined 21:27 guc5wl4iddfj left, b3ddrfwssjcc joined 21:28 b3ddrfwssjcc left, xzhyyf7i2h2t joined 21:29 xzhyyf7i2h2t left, r233smqug7xb joined 21:30 r233smqug7xb left, edhyafutxv7a joined 21:31 edhyafutxv7a left, kub67x5kvo4f joined 21:32 kub67x5kvo4f left, taouxqo3vqa2 joined 21:33 taouxqo3vqa2 left 21:34 bzisd6cndbcu joined 21:35 bzisd6cndbcu left, akuxskmjpe3q joined 21:36 akuxskmjpe3q left, inyuz4cebvs5 joined 21:37 inyuz4cebvs5 left, fyhpgrabx7g7 joined 21:38 fyhpgrabx7g7 left, egqdk4rtid4u joined 21:39 egqdk4rtid4u left, ukibardfwton joined 21:40 ukibardfwton left, z2mciedtyihy joined 21:41 z2mciedtyihy left 21:42 stj52yrspozx joined 21:43 stj52yrspozx left, ny52adr2e3j4 joined 21:44 ny52adr2e3j4 left, yx7mgbcynito joined 21:45 yx7mgbcynito left, sgkarzbnbkv6 joined 21:46 sgkarzbnbkv6 left, hhgzc6sg3wke joined, s2pogdsd5rng left, hhgzc6sg3wke left 21:47 akzbbpcxid4b joined, tvirdhcvr34h joined, akzbbpcxid4b left, u4e5m23b2z4nm joined 21:48 tvirdhcvr34h left, lsu6327kwnd3 joined, u4e5m23b2z4nm left 21:49 zd44pzpil57k joined, zd44pzpil57k left, lsu6327kwnd3 left, ck7gxa7luetx joined 21:50 u5eey25fnkz7z joined, ck7gxa7luetx left 21:51 u5eey25fnkz7z left, hh6ehhj5e2bx joined 21:52 a3utbbzy5utl joined, hh6ehhj5e2bx left, u4rjxrv2xiw2 joined 21:53 a3utbbzy5utl left, ywcwnin3quco joined, u4rjxrv2xiw2 left 21:54 ywcwnin3quco left, ef6xegoe2pjv joined, ydo62pzkqseu joined 21:55 ef6xegoe2pjv left, ydo62pzkqseu left, ihv72ue7dsjh joined 21:56 ihv72ue7dsjh left, quu7gkwd43vt joined 21:57 dqdpiuq7ccxw joined, quu7gkwd43vt left, dqdpiuq7ccxw left 21:58 rxbge2ipogmu joined, ofgxr7r4pa22 joined, rxbge2ipogmu left 21:59 ofgxr7r4pa22 left, v5yheyj36kpb joined, xrfpjms5b3m3 joined 22:00 v5yheyj36kpb left, xrfpjms5b3m3 left, p4zhhemp2i2m joined 22:01 yzrvwnveuugj joined, p4zhhemp2i2m left, txneegly2swt joined, yzrvwnveuugj left 22:02 txneegly2swt left 22:03 amf67wdisvyg joined, w345xm24ejey joined, amf67wdisvyg left 22:04 w345xm24ejey left, h76g65vui7cp joined, d57xnqq5qaku joined 22:05 d57xnqq5qaku left, h76g65vui7cp left, u43dsmhtncftl joined 22:06 Aedil left, u43dsmhtncftl left 22:07 gu2w7ztkaeju joined 22:08 gu2w7ztkaeju left, h7oddlka7 joined, u4hppak joined 22:15 silug left, silug joined 22:16 u4hppak left 22:17 mvkmku4qp joined, csyvu2 joined 22:18 h7oddlka7 left 22:19 mvkmku4qp left, csyvu2 left, v5jvzpmea joined, e2eepge7d joined, tellable6 left 22:22 tellable6 joined 22:26 melezhik joined
gfldex . 22:28
tellable6 2025-04-26T22:57:31Z #raku-dev <Xliff> gfldex Was lurking and saw your Elite Dangerous comment. What form does the 37M hash originate from?. 22:30
22:33 ilogger2 left 22:34 tellable6 left 22:35 arkiuat left 22:48 e2eepge7d left 22:53 silug left 22:55 v5jvzpmea left 23:39 ceagn joined, zoamm joined 23:40 ceagn left, zoamm left, leecle joined, geigz joined 23:41 leecle left 23:42 viiwer joined 23:43 guifa joined, geigz left, viiwer left
guifa hmmmm 23:43
23:43 liedk joined, neetz joined 23:45 neetz left, liedk left, rialion joined 23:46 rialion left, zuibk joined, zuibk left, skuapr joined, snierest joined, skuapr left 23:47 snierest left, tauliest joined, nievian joined, nievian left, tauliest left, poubian joined, poubian left, skeowian joined 23:48 skeowian left, ruona joined, foidl joined 23:49 ruona left, foidl left, steirle joined, steirle left, diiwl joined, skiuka joined, diiwl left 23:50 skiuka left, saakd joined, goegg joined, saakd left, goegg left, greipy joined 23:51 greipy left, guifa left, zuanv joined, zuanv left, kaopc joined, shooca joined, shooca left 23:52 kaopc left

Powered by Cro and the Raku® Programming Language.

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

Thank you!