🦋 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 | ||
00:07
vrurg left
00:13
dogbert11 joined
00:17
dogbert17 left
00:21
vrurg joined
00:41
pecastro left
00:55
_jrjsmrtn joined
00:58
__jrjsmrtn__ left
00:59
mowcat left
01:09
HarmtH left
01:10
HarmtH joined
01:17
xinming_ joined
01:19
xinming left
01:21
[Sno] joined
01:23
sno left
01:34
kvw_5_ joined
01:37
kvw_5 left
01:49
monkey__ joined
01:59
monkey__ left
02:06
Manifest0 joined
02:30
muffindrake left
02:32
muffindrake joined
02:38
berber44 joined
02:48
moony left
02:51
moony joined
03:51
kurahaupo is now known as hyper_
03:52
hyper_ is now known as kurahaupo
04:10
berber44 left
04:41
rindolf joined
05:22
guifa2 left
05:53
moony left
05:57
moony joined
06:09
benkolera left
06:12
parabolize left
06:23
Sir_Ragna joined
06:58
wamba joined
|
|||
MasterDuke | leont: some discussion about that here colabti.org/irclogger/irclogger_lo...-03-27#l31 | 07:16 | |
07:31
gurmble joined
07:35
gurmble is now known as grumble
07:50
sena_kun joined
08:14
berber44 joined,
wamba left
08:30
RaycatWhoDat joined
08:44
RaycatWhoDat left
08:50
Xliff joined,
Xliff left
08:52
wamba joined
09:00
tejr left,
tejr joined
09:08
Sgeo left
09:11
squashable6 left
09:14
squashable6 joined
09:26
[Sno] left
09:51
pecastro joined
10:02
eseyman joined
10:16
murari joined
10:17
murari left,
murari joined,
murari left
10:18
murari joined,
murari left
10:44
sno joined
10:54
xinming_ left
10:56
xinming_ joined
11:14
tom joined,
tom is now known as Guest41442
|
|||
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 | |
11:48
Black_Ribbon left
|
|||
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 | ||
12:26
monkey__ joined
12:55
Guest41442 left
13:23
monkey__ left
13:37
rindolf left
|
|||
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 | ||
14:17
parabolize joined
14:29
patrickb joined
|
|||
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 | ||
14:55
wamba left
14:56
judd7 left
15:33
wamba joined
15:54
domidumont joined
|
|||
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 | ||
16:40
Kaiepi joined
|
|||
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 | |||
16:52
guifa2 joined
|
|||
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 | ||
17:03
stux|RC joined
|
|||
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 | |
17:11
stux|RC left
|
|||
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 | ||
17:14
stux|RC joined
|
|||
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 | |||
17:22
mowcat joined
17:23
Manifest0 left
|
|||
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 | |||
17:34
Manifest0 joined
|
|||
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 | ||
17:41
oneeggeach joined
|
|||
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 | |||
17:49
domidumont left
|
|||
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 | ||
17:58
DiffieHellman left
17:59
DiffieHellman joined
18:01
wamba left
18:04
wamba joined
18:07
berber44 left
18:10
mowcat left
18:15
mowcat joined
18:19
dataangel joined
18:36
Sgeo joined
18:51
oneeggeach left
18:55
rindolf joined
19:06
patrickb left
19:09
patrickb joined
19:18
lichtkind joined
19:29
bonz060 left
19:31
bonz060 joined
19:52
patrickb left
20:04
judd7 joined
|
|||
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 | ||
20:34
bonz060 left
20:35
bonz060 joined
20:37
bonz060 left
20:38
bonz060 joined
20:40
bonz060 left,
bonz060 joined
20:42
wamba left
|
|||
lizmat | tbrowder: if you make that :$epoch-type! (aka the named arg mandatory), that should dispatch to your new method ? | 20:45 | |
20:48
gordonfish left
|
|||
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 | |
20:50
gordonfish joined
|
|||
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 | ||
21:12
guifa2 left
|
|||
lizmat | in the above example, the "later" logic would *also* need to know about that extra attribute | 21:13 | |
21:14
guifa2 joined
|
|||
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 | ||
21:24
epony left
|
|||
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 | |
21:28
epony joined
|
|||
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 | |
21:49
sena_kun left
|
|||
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...) | |||
21:56
demostanis joined
|
|||
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 | |
22:07
HarmtH_ joined,
HarmtH left
|
|||
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 | ||
22:10
demostanis left
|
|||
MasterDuke | and lizmat is a machine with the way she pumps out rakudo optimizations | 22:11 | |
22:11
demostanis joined
|
|||
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 | |||
22:14
demostanis left
22:15
demostanis joined
|
|||
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 :^ | |||
22:16
neshpion joined
|
|||
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 | |
22:19
HarmtH joined,
demostanis left
|
|||
summerisle | horrible to reverse engineer, horrible to compile, horrible to integrate with, etc... | 22:19 | |
22:19
demostanis joined,
HarmtH_ left
|
|||
summerisle | i'd reckon that many C++ bindings for HLLs take the form of C glue using `extern "C"` | 22:20 | |
22:20
demostanis left,
aluaces left
22:21
demostanis joined
|
|||
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 | |
22:22
HarmtH_ joined
22:23
demostanis left,
demostanis[m] joined,
HarmtH left
|
|||
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 | ||
22:41
rindolf left
22:44
lichtkind left
22:45
monkey__ joined
23:22
dogbert17 joined
23:26
dogbert11 left
23:41
monkey__ left
23:48
pecastro left
23:54
neshpion left
|
|||
leont | Raku doesn't have buf literals, does it? | 23:59 | |
(currently very much needing them) |