🦋 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.
leont I want to asynchronously read from $*IO. So far the only way to do that I found was to do a $*IO.Supply(:1size) inside another thread. Is there a better way. 00:00
It sounds to me like we need a IO::Pipe::Async? 00:01
MasterDuke leont: some discussion about that here colabti.org/irclogger/irclogger_lo...-03-27#l31 07:16
Guest41442 hello I have a question about using Red :) 11:15
I have some code to post. I am wondering what is the best way to approach this - should I just go ahead and post it here? 11:23
sena_kun Guest41442, if there is a lot (more than 3 lines) you can post a sample somewhere and post the link here. Any paste service is fine. 11:25
Guest41442 ah ok I see. Actually I posted this on perlmonks already, so this is the link: perlmonks.org/?node_id=11130406
not so many people using raku on perlmonks it seems 11:26
sena_kun Guest41442, what if you do `model Vmail is table<vmail> { the definition goes here... }`? 11:30
instead of `model Vmail {...}`
Guest41442 I still get the same error actually 11:37
oh wait 11:39
sorry I see what you mean
sena_kun Guest41442, that's just a wild guess, sorry if I missed. 11:40
Guest41442 yes I still get the same error 11:41
sena_kun Guest41442, ok, let's check some other things. How are your files organized? E.g. your Schema.rakumod and the user script are in the same directory by chance? 11:43
Guest41442 Schema.rakumod is inside the 'lib' directory. The script is just in the document root 11:44
Guest41442 line 9 is the `^create` line - so it seems interesting that it complains about not being able to find `Vmail` when its actually trying to create a `User` entry 12:04
MasterDuke Guest41442: fyi, SmokeMachine is Red's author, so if you don't find an answer you could also .ask him a question 12:09
sena_kun Guest41442, can note it works when everything is in a single script.
Guest41442 sena_kun, so something to do with importing perhaps? I am not 100% sure how that works with use/need/import etc 12:14
sena_kun Guest41442, seems so, but I recreated it and don't see anything too suspicious. I am a novice though, sorry to not be of much help. 12:15
Guest41442 sena_kun you already helped:)  Appreciated 12:17
also thanks for the suggestion MasterDuke :) 12:18
SmokeMachine I’m too late… :( 13:59
It’s probably missing a :requires<Schema> on the relationship… :( 14:01
I'm going to answer on the perlmonks... 14:06
SmokeMachine perlmonks.org/? 14:30
sorry, I meant this: perlmonks.org/?node_id=11130511 (too long not using perlmonks...)
moritz_ perlmonks' UX is terrible. I spent a LOT of time there back in the days (around 2006-2010, maybe?), and back then I thought it was OK 14:33
after coming back some years ago to write an answer, I noticed who much it sucks when you aren't used to all its quirks 14:34
SmokeMachine same here 14:36
I've spent quite a long time trying to find how to answer that there now... 14:38
tbrowder hi, folks. i'm trying to create a subclass of DateTime to add a new named attribute but can't seem to do it. looking at the Raku source it seems inheriting from it may be impossible without some deeper contruction magic. 16:25
here is my simple attempt
m: class Foo is DateTime { has $.footime}; my $ft = Foo.new: :footime(0); say $ft.raku 16:27
camelia Failure.new(exception => X::AdHoc.new(payload => "Cannot call Foo.new with these named parameters: footime"), backtrace => Backtrace.new)
codesections tbrowder: guifa is the _perfect_ person to ask about that :D 16:29
If you haven't already, their Advent post was very much related: raku-advent.blog/2020/12/17/day-17...d-in-raku/ 16:30
tbrowder class Foo is DateTime { has $.footime}; my $f = Foo.new(DateTime.now, :$footime(0)); say $f.raku
ugexe tbrowder: it uses `new` instead of e.g. TWEAK -- thats why we typically encourage people to not implement `new` 16:31
tbrowder hm. is subclassing DaeTime possible? 16:32
ugexe if you can work around DateTime's `new` method, sure
tbrowder i looked into that a bit but got lost. so could a new "new" in a subclass be made to work? (and i'll go back and lo 16:34
look at guifa's article 16:35
ugexe m: class Foo is DateTime { has $.footime; multi method new(|c, :$footime!) { self.bless(|c, :$footime) } }; say Foo.new(footime => 42).footime 16:40
camelia 42
ugexe eh that won't work i dont think
codesections How do I check that all the elements in an Array are of the same type as one another?
(but let it be any type). Or, how/can I constrain an Array to take only elements of the same type? 16:41
tbrowder ugexe: why do you say that won't work? 16:42
ugexe tbrowder: i dont think the bless is going to fire the appropriate `new` in DateTime class as needed 16:43
tbrowder couldn't one do some TWEAKing to fill in missing blanks?
ugexe that will just break when DateTime gets changed 16:44
tbrowder you mean Raku change? i can maybe live with that 16:45
moritz_ m: my @a = 1, 2, 3; say [===] @a>>.WHICH
camelia False
ugexe may as well just c&p the `new` methods from DateTime then
moritz_ m: my @a = 1, 2, 3; say @a>>.WHICH
camelia [Int|1 Int|2 Int|3]
moritz_ erm no, .WHAT
m: my @a = 1, 2, 3; say [===] @a>>.WHAT
camelia True
moritz_ codesections: ^^
tbrowder well, couldn't i just somehow require a certain version of raku in the module? 16:46
codesections moritz_: aha, I *knew* there had to be something elegant like that! ty
ugexe tbrowder: people shouldnt be doing that. they should be writing *raku* code, not rakudo code
for example a c# based raku compiler probably doesn't know what version < 2021.05 means 16:47
tbrowder well, sometimes
ugexe speaking practically though yes you could do that. its just not something to encourage
tbrowder well most of my 16:48
ugexe and you'd have to constantly update it since you would be gating on existing features
not on some old version that doesnt work
tbrowder no i didn't mean version, i meant .c, ,d, etc.
ugexe ah, yeah *that* version is perfectly reasonable to work with
tbrowder ok, so the new new with tweaks should be a reasonable path forward? 16:49
i'll try that. thanks ugexe and codesections 16:50
ugexe probably, although it smells like you would be better off applying a role to a DateTime instance with the new logic 16:51
then again there might not be a really good solution just due to the design of DateTime
tbrowder i remember reading guifa's article about using the role but didn't follow all the problems with that method. 16:52
if the role is applied inside the class definition shouldn't that contain all the interactions with the parent DateTime class? 16:54
the role being defined inside and not being exported 16:55
ugexe if DateTime was a role sure, but you'd be writing the role
and applying it to DateTime 16:56
there would be no "class definition"
just the role definition
guifa2 FWIW, My method primarily wraps .new, picks out the attributes it needs to do its work, and then hands things back off to the built-in DateTime's new before mixing in a role
tbrowder gotcha. i'm gonna try the "new new" route. 16:57
guifa2 so I let most everything get handled inside of DateTime to minimize disruption to extant code
s / "handled inside of DateTime" / "handled by DateTime's original core code" /
tbrowder i'm trying to avoid the wrapper if possible, it hurts my head ;-D
guifa2 What attribute are you trying to add? 16:58
guifa2 is curious — the only one he knows needs adding at this point is "calendar" for when non-gregorian calendars get supported, but that's a ways off
tbrowder a juliandate value.
for astronomical calculations 16:59
i 17:00
guifa2 Ah. Okay, so there are a couple of ways to go about it
role JulianDatable { method julian-date { self.day + self.month … } } 17:01
that'll be the core of what you need. The next question is how to apply it
tbrowder my "real" module/class is called DateTime::Julian and it's unpublished but on github (tbrowder/DateTime-Julian) 17:02
guifa2 If you're in control of all the creation of all dates, I'd just write a quick maker sub
guifa2 sub get-julian-date( |c ) { DateTime.new( |c ) but JulianDatable }  17:03
ugexe there is also `use MONKEY-TYPING; augment class DateTime { method julian-date { self.day + self.month } };` >:) 17:04
tbrowder i really want the object to calculate the civil time from the input julian date.
guifa2 if you're wanting it to be retroactively applied to all DateTimes, you'll probably want to follow my time lord article fairly closely, or even C&P large parts of the Timezone code (which will be updated when the precompilation multidispatch bug gets fixed) 17:05
ugexe: honestly, probably the simplest. I just avoid augment because it breaks precompilation
tbrowder no, i'm not explaining this well at all. i want the child class to internally update the DateTime yr, mo, da, hr, mim, 17:06
min, sec when instantiated with a juliandate.
the TWEAK will do all the calculations needed, and the object remains immutable 17:07
the timezone will alway be zulu 17:09
guifa2 Okay, so let me make sure I've got this in how you want to interact with it (because that'll dictate the best ways to work with it). 17:10
guifa2 (a) you want to have a set of DateTimes (with their Gregorian calendar) and you want to be able to call a method on them to shift them to a Julian calendar 17:13
(b) you want to specify a flag on DateTime.new() to create a special DateTime that functions in the Julian calendar, but still be able to make Gregorian DateTimes
(c) you want all DateTimes (even ones you didn't make) to work with the Julian calendar.
(d) you want to be able to access the Julian d/m/y on a given DateTime (or all of them) but still access the Gregorian d/m/y too. 17:14
guifa2 I know that's a lot of possibilities, but just wanna makes ure I give advice for the right one and don't talk past you lol 17:14
tbrowder ok, thnx, got to go for a whilr but when i get back i will be able to explain use case a bit better. thanks so much 17:15
guifa2 Also, it probably won't be until this summer, but I will get multiple calendar support baked into DateTime (similar to Timezones) at some point this year 17:18
lizmat guifa2: you are aware of Jean Forget Calendar modules ? 17:22
Forget's
guifa2 lizmat: I am. His are separate classes, rather than mixins to DateTime, so a bit easier to make 17:23
guifa2 says "a bit easier" as if it were easy lol calendar stuff is *hard* 17:24
lizmat yeah... and making DateTime handle being subclassed is also tricky :-) 17:25
guifa2 Ideally, I'd like DateTime to get a new attribute .calendar, and allow easy conversions between calendars via either clone( calendar => 'chinese' ) or .in-calendar('japanese') etc, and also handle comparisons as best as possible 17:26
the trickiest part is that some conversions (*cough Islamic observational calendars cough*) can only have approximate conversions, and it's not entirely clear how to best handle the -Time part, when there's many different definitions for the start of a Date (6am, midnight, or noon being easy, but nightfall and sunrise being not very clear how best to handle unless you had geocoordinates too lol) 17:28
lizmat hmmm... 17:29
so if two DateTimes are the same, would they be different if part of different calendars ? 17:30
feels to me they should still be the same, no?
if that is the case, then maybe a Calendar should be a role with a DateTime attribute ? 17:31
guifa2 Do we currently consider two times that are the same POSIX time but in different timezone-offsets as the same?
guifa2 doesn't know....goes to check
guifa2 my $a = DateTime.new(:2020year, :1month, :1day, :22hour, :0minute, :0second, :3600timezone); my $b = DateTime.new(:2020year, :1month, :1day, :21hour, :0minute, :0second, :0timezone); $a == $b; say $a === $b; 17:34
evalable6 WARNINGS for /tmp/neaPZA4mse:
False
Useless use of "==" in expression "$a == $b" in sink context (line 1)
guifa2 err, whatever
they match on ==, but not on === (DateTimes aren't value typed, it seems)
tbrowder back...a julian date in astronomy is a real number with the integral part being the number of days since a defined instant before recorded history until some later event, such as the time a planet will appear at the prime meridian on a certain date. 17:39
so all my child class has to do is take the input julian date and convert it to civil time at tz=0. 17:41
lizmat hmmm... why isn't a DateTime not a value type
lizmat hmmm.. also looks like we don't have an infix:<eqv> for DateTimes or Dates either 17:42
guifa2 lizmat: perhaps for the timezone question. Should two dates referring to the same instant, but different timezone offsets, have the same WHICH value? 17:43
tbrowder i first started with a class that had a DateTime object as an attribute but guifa2 showed in the Advent art that subclassing DateTime is possible, so i've been working on that assumption,
lizmat guifa2: I would tend to say no
guifa2 I could easily see half of the people saying "yes, because same instance" but half say "no, because different timezone" and I can't argue with either reasoning lol
tbrowder now i'm ready to fit it all together. 17:44
guifa2 tbrowder: so I'm not subclassing DateTime. All I was doing was mixing in a role in a very fancy way to have my role it be retroactively applied to *all* DateTimes. I think you're best off writing a role like I showed above, and when you make your DateTime, apply it via "does" or "but". 17:47
or using ugexe's augment method
tbrowder ok, i'll head off in those directions. thanks do much guifa2 and ugexe! 17:49
guifa2 or you can also write a sub julian-date(DateTime $foo) { … } and call it like $date-time.&julian-date and not deal with roles or augmenting or anything ^_^ 17:50
tbrowder that's too much for my taste, i already have subs that turn 17:54
jd to dt or vice versa, i just want to encapsulate them a bit more for novice users 17:55
tbrowder back to chat about DateTime if guifa2 or ugexe are still here 20:27
i'm looking again at the guts of DateTime and see all the 20:28
the attrs and methods associated with the unix epoch and wonder why the class couldn't have one or more named attrs to modify the interpretation of the input epoch? 20:31
for example: multi method new(DateTime: Numeric:D $epoch, :$epoch-type = 'juliandate', ... 20:34
lizmat tbrowder: if you make that :$epoch-type! (aka the named arg mandatory), that should dispatch to your new method ? 20:45
tbrowder lizmat: i'm not sure yet, but without changing the current class code i think we could add another DateTime attr that could either be a multipurpose one or just named 'juliandate' that would only be defined if used to instantiate the DT object 20:49
tbrowder Curt Tilmes at NASA might be in favor of such 20:50
addind 20:51
adding using methods seems to be straight-forward
maybe calling a 'juliandate' method on an existing DT object without a defined 'juliandate' value could update the undefined attr. 20:55
there should be a one-to-one correspondance between the civil time and juliandate without regard to time zone 20:56
i would work on such a Rakudo mod if it would be considered. 20:58
a possibility
lizmat tbrowder: I understand the value, but please also know that DateTime has been highly optimized by popular demand
and adding another attribute means adding logic to make sure the attribute is copied whenever operations on a DateTime object are performed 20:59
tbrowder hm, maybe it can be done without the attr if a new signature could be invented somehow 21:04
brown121407 To subscribe to the Raku mailing lists do I need to just send an empty email to perl6-*-subscribe@perl.org? 21:05
Oh it says it on the site, sorry.
lizmat brown121407 yeah, that's it for now 21:06
tbrowder it looks like posix is handled that way almost except it sucks up the solo numeric positional
so whats the cost of copying an attr whose value is only used at instantiation? 21:08
it doesn't need to be copied
lizmat m: say DateTime.now.later(:1hour) 21:09
camelia 2021-03-29T00:09:09.253067+02:00
lizmat m: class Foo is DateTime { }; dd Foo.now.later(:1hour)
camelia Foo.new(2021,3,29,0,9,43.66354942321777,:timezone(7200))
lizmat you'd want that to return a Foo with all its additional attributes in tact? 21:10
tbrowder so, as i naively see it, any extra cost is paid when the user calls the juliandate method on a DT object
yes, they would be defined just like a posix input now defines them 21:11
lizmat in the above example, the "later" logic would *also* need to know about that extra attribute 21:13
tbrowder well, i'm saying, as a mod to DateTime, the only need for the addtional attr id 21:14
lizmat tbrowder: as an example, I suggest you look at DateTime's internal "move-by-unit" method 21:15
tbrowder is at DateTime instantiation if and only if it is to be instantiated by a juliandate value
it
lizmat but if it is instantiated with a juliandate value, you'd want .later in it to return an instance with that same juliandate value, would you not ? 21:16
tbrowder no, it can be calculated just like posix from the y,m.d,h.m.s 21:17
juliandate <=> y,m,d,h,m,s 21:18
lizmat no? then what use is it ?
tbrowder immutable
similar use as posix: time relation to an epoch 21:19
lizmat isn't DateTime already that then ?
internally, it has y m d h m s ?
as attributes ? 21:20
guifa2 TBH I think the best approach is to allow creating a DateTime from a Julian date, and then create a method (via a role, or augment, or add_fallback) that roundtrips it
tbrowder exactly, as i was fumbling trying to say
except i want to do it internally to the DateTime code which i don't see would hurt its performance copywise 21:22
lizmat m: say DateTime.new(2021,3,28,23,20,15)
camelia 2021-03-28T23:20:15Z
lizmat isn't that a Julian date ? 21:23
tbrowder no
tbrowder that's a date in the gregorian calendar, but a jd can be calculated from it 21:24
guifa2 lizmat: julian date is a single running number from an epoch. Similar to how POSIX time counts the seconds from epoch, Julian date counts days from epoch. (perhaps confusing things is the Julian calendar which is close to the Gregorian calendar)
(but the Julian calendar has nothing to do with the Julian date. Hooray clear naming lol)
lizmat m: say DateTime.new.daycount
camelia Cannot call DateTime.new with no parameters
in block <unit> at <tmp> line 1
tbrowder exactly. astronomers like to refer to it as a "juian day number"
lizmat m: say DateTime.now.daycount
camelia 59301
lizmat something like that ? 21:25
tbrowder except it's a real number, with the fractionsl part representing time of day
lizmat weekly: gitlab.com/jjatria/pop
notable6 lizmat, Noted! (weekly)
lizmat m: say now 21:26
camelia Instant:1616966817.050648
jjatria lizmat++
lizmat like that, but in days rather than seconds # tbrowder
tbrowder that's a posix seconds i think
different epoch 21:27
lizmat actually, no
Instant is *not* epoch
it's about 24 seconds off from that, due to leap seconds
tbrowder ok, but from unix epoch, though 21:28
lizmat yes, it's "real" number of seconds since epoch 21:28
guifa2 DateTime.^find_method('daycount').wrap: { my $days = callsame; my $fractional-day = #`[calculate with self.hour, etc]; return $days - $fractional-day }  21:29
err I guess it needs to be a method so
DateTime.^find_method('daycount').wrap: method ( ) { my $days = callsame; my $fractional-day = #`[calculate with self.hour, etc]; return $days - $fractional-day }
tbrowder so the same type of thing is defined for other epochs. i would like to instantiate a DateTime object from one other than unix 21:30
the DateTime class is a real boon, and i think if there were a clean, easyway 21:33
easy way to extend it others might find it useful as well 21:34
extend it at no cost to the original class of course 21:35
only the extending user to pay somehow 21:36
guifa2 tbrowder: if you can do your calculations from Y/M/D/daycount, you shouldn't have any performance problems. 21:37
MasterDuke fwiw, in my get_rid_of_nqp::time_n branch of rakudo i have a WIP change that adds a `from-posix-nanos(Duration:U: Int:D $nanos --> Duration:D) { nqp::p6bindattrinvres(nqp::create(Duration),Duration,'$!tai',$nanos) }`
and same for Instant 21:38
guifa2 Heck, even my timezone module which requires doing some guess-and-check bouncing around to figure out the timezone, at worst case only runs a teeny bit slower, and in a best case is almost imperceivably slower
lizmat but then I don't understand the "extra attribute" bit 21:39
if DateTime.from-juliandate would just be creating a standard DateTime object ? from differently mangled input values ?
tbrowder i was looking at the signatures for DateTime multi new and didn't see a clean way to do that without a named arg 21:47
which i though requires an attr (but which wouldn't need copying) 21:48
guifa2 so that's one thing that we could probably do… allow DateTime.new to ignore extra parameters 21:49
guifa2 right now it complains — I lucked out with timezones that both :timezone and :offset were available and I could force a distinction 21:49
lizmat but why not just add a DateTime.from-julian-date that would create a DateTime object
?
tbrowder i guess that would do... 21:51
codesections unrelated question: Is it a known bug that attempting to index into a list with two ranges hangs when at least one has a * endpoint? e.g.: (1, 2, 3, 4)[0..1, 2..*] 21:52
japhb There *was* a bug like that, I thought lizmat++ smushed that one some time back 21:54
lizmat yeah, that sounds familiar :-)
the 2020.02 release had that, hence the 2020.02.1 release ?
tbrowder but it seems kind of clunky compared to "DateTime.new: :juliandate(some BIG number)" 21:55
codesections hmmm, 20_20_, not 2021? I'm running into that loop on 2021.02 21:56
(which reminds me that I should update...)
japhb No, I think it was 2021. 21:56
lizmat m: multi method new(DateTime: :$juliandate) { dd $juliandate }; say DateTime.new(:juliandate(42))
camelia Potential difficulties:
Useless declaration of a has-scoped multi-method in mainline (did you mean 'my method new'?)
at <tmp>:1
------> 3multi method7⏏5 new(DateTime: :$juliandate) { dd $julia
Cannot call DateTime.new with th…
demostanis Why is Rakudo slower than Perl or other interpreted languages? 21:57
lizmat m: multi method DateTime::new(DateTime: :$juliandate) { dd $juliandate }; say DateTime.new(:juliandate(42))
camelia Potential difficulties:
Useless declaration of a has-scoped multi-method in mainline (did you mean 'my method DateTime::new'?)
at <tmp>:1
------> 3multi method7⏏5 DateTime::new(DateTime: :$juliandate) {
Cannot call DateTime.n…
lizmat hmmm
tbrowder ok, we have a winner, lizmat sees a challenge!! 21:58
life is good 21:59
lizmat hehe... not before newdisp lands though
codesections Aha! Indeed, it _has_ been fixed. Thanks for the bug squashing, lizmat++
lizmat well, I was the one who introduced it , so I'd better fix it then :-) 22:00
demostanis Was my message seen between all these chunks of code? lol
lizmat demostanis: because it hasn't been optimized as well as other languages
codesections So, if I use that code in a library, will it hang for uses on the wrong version?
demostanis lizmat: How can it be optimized? 22:01
codesections s/uses/users/
lizmat codesections: only if the user actually was on 2020.02.0 or on blead in the few weeks before the 2020.02.0 release
arrgghgjhghsa 22:02
codesections Thanks
lizmat 2021.02.0 and 2021.02.1
the issue was introduced between 2021.01 and 2021.02
and 2021.02.1 was introduced about a week after 2021.02.0 22:03
so if someone is using blead, they should be ok
only if they use the 2021.02.0 release (which was available for a week) then, yes
but all package managers are either up-to-date, or use an older version of raku :-) 22:04
codesections Well, good reason for me to get off it, then :D
demostanis Also is anyone else having an issue installing rakudo on OpenBSD -current? Something related to zstd5.0 not found
lizmat demostanis: may be a known issue, I seem to recall some issues with openBSD, but I thought they were fixed for 2021.03 22:06
demostanis I might try again tomorrow. And how can we optimize Rakudo? What needs to be changed? 22:08
MasterDuke you should be able to build without zstd. maybe the package is compiled with it though, but doesn't list it as a dependency? have you tried install libzstd-dev (i don't know what the name would actually be in openbsd)
demostanis: check out jnthn's blog posts about the new dispatcher work and new ast work, they give some good info about optimizations in progress 22:09
6guts.wordpress.com/ 22:10
MasterDuke and lizmat is a machine with the way she pumps out rakudo optimizations 22:11
demostanis Sorry my IRC client disconnected me... 22:12
MasterDuke: cvsweb.openbsd.org/cgi-bin/cvsweb/...web-markup
WANT_LIB =
summerisle anyone been doing anything with C++ and NativeCall? 22:13
because i'm loathe to write mangled names out myself 22:14
demostanis summerisle: I've read about it, C++ add _Z at the beginning of function names
Oh
summerisle demostanis: C++ has a really broken dispatch system because it's forever stuck pretending that smalltalk never existed, as such it encodes as much info about return type and params as it can into function names to avoid having to do lookups at rt 22:15
i'm sure you're probably aware of that though :^
summerisle i've been wanting to get back into working on my music manager, but i'm really not interested in writing bindings for each format, plus TagLib seems to be the only actively supported _native_ implementation of the ID3vWhatever tag spec. Of course, it's written in C++, making life more difficult for everyone 22:17
demostanis That sucks. 22:18
summerisle C++ is a great example of an actual bad meme (in the truest sense of the word) 22:19
summerisle horrible to reverse engineer, horrible to compile, horrible to integrate with, etc... 22:19
summerisle i'd reckon that many C++ bindings for HLLs take the form of C glue using `extern "C"` 22:20
MasterDuke demostanis: i see zstd there, but don't know anything about the *BSDs to help troubleshoot any further without just offering wild speculation. tyil uses a BSD, there are some other BSD users too, but i don't remember who 22:21
demostanis[m] Using IRC bridged on matrix might be better 22:24
I keep having connectivity issues
I'll try to troubleshoot Rakudo on OpenBSD tomorrow. I've gotta sleep now. 22:25
leont Raku doesn't have buf literals, does it? 23:59
(currently very much needing them)