šŸ¦‹ 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.
00:00 Doc_Holliwould left 00:03 BenGoldberg joined 00:13 xinming left, xinming joined 00:16 approaching236 left 00:38 daxim left 00:46 daxim joined 00:52 daxim left
mid_laptop hello... I'm experiencing a weird behavior (in a special case) with `.=`... but I may have misunderstood something, thus before I go further, my question is: are the following expressions strictly equivalent: `my MyClass $i .= new;` and `my MyClass $i = MyClass.new;`? 00:53
00:56 daxim joined 01:04 leont left 01:07 gordonfish joined 01:18 molaf left, xinming left 01:19 xinming joined 01:30 molaf joined, Ben_Goldberg joined, BenGoldberg left, Ben_Goldberg is now known as BenGoldberg
jdv79 mid_laptop: should be quite close 01:32
you could try to dump ast to see if you can peek at any diffs maybe
01:40 BenGoldberg left, BenGoldberg joined
jdv79 MoarVM panic: Internal error: zeroed target thread ID in work pass 01:42
what in the world...
01:44 BenGoldberg left 01:45 vrurg joined 01:46 BenGoldberg joined 01:48 xinming left 01:50 xinming joined 01:52 Ben_Goldberg joined, BenGoldberg left, Ben_Goldberg is now known as BenGoldberg 01:57 xinming left 01:58 xinming joined 01:59 BenGoldberg left 02:04 Manifest0 left 02:06 Manifest0 joined
mid_laptop jdv79: yes there are differences in the AST... the most obvious is the call to `dispatch:<.=>`... but my question was more in the expected behavior of the 2 versions... I have a case where when I use the `.=` version (after the class has already been instanciated with any of the 2 versions), there is a runtime error... 02:06
to sum up: `my MyClass $i .= new; my MyClass $j .= new;` fails, but `my MyClass $i = MyClass.new; my MyClass $j = MyClass.new;` doesn't
The case that triggers this is when MyClass is a CPPStruct *and* the constructor is native. The error I get is Ā« Native call expected argument 1 with CPPStruct representation, but got a P6opaque (Scalar) Ā». I've have a patch on the test Ā« t/04-nativecall/11-cpp.t Ā» that aborts the script (and another that doesn't)...
02:08 mowcat left
jdv79 i'm no expert but afaik the expected behaviour should be the same 02:09
i have very little experience with native stuff. others will likely show up eventuall that can help. sorry. 02:12
mid_laptop ok, no problem, thanks anyway :-)
02:17 lucasb left 02:18 BenGoldberg joined
guifa mid_laptop: this is pure speculation, but when you do `my MyClass $i .= new`, itā€™s actually most directly equivalent to `my MyClass $i; $i = $i.new`, which uses a scalar container 02:27
whereas doing `my MyClass $i = MyClass.new`, the MyClass is being referenced directly, without a scalar intermediary
mid_laptop yes, possible... but then why does it work the first time? (the 1st time it works using any of the 2 versions) 02:29
guifa That Iā€™m not sure about. Perhaps NativeCall stuff is doing some things later than I would expect. 02:30
guifa doesnā€™t have a lot of experience with NativeCall
guifa . o O ( actually like zero ) 02:31
mid_laptop :-D ok, but thanks for the clarification 02:32
guifa Iā€™d try doing a few other ways to initialize it to narrow stuff down, and then potentially file a ticket
mid_laptop yes 02:33
02:38 lizmat left 02:39 lizmat joined
jdv79 wow, doing precise time, perhaps specifically datetime, math is basically impossible as things are implemented as of now 02:41
wonder if it makes sense to go harder with rats there or just use a seperate int for frac seconds 02:48
02:51 Kaiepi joined 03:01 xinming left 03:02 xinming joined
guifa jdv79: what are you needing to track at a fractional level? 03:04
jdv79 time:) 03:08
using it as the index in a queue/log so exact math is important 03:09
the current workarounds i have are not pretty - truncation, force to rat with higher prec conversion, cmps as strings:( 03:11
03:11 cpan-raku left 03:12 cpan-raku joined, cpan-raku left, cpan-raku joined 03:14 BenGoldberg left 03:16 BenGoldberg joined 03:18 BenGoldberg left, BenGoldberg joined 03:19 vrurg left 03:20 BenGoldberg left
guifa jdv79: as long as youā€™re not wanting actual correlation to realtime, and just need relative values, how about using an instant? 03:20
03:20 BenGoldberg joined 03:21 xinming left, xinming joined
jdv79 they are stored and manipulated as DateTimes. And the conversion from DateTime to and from Instant also suffers from floating point iirc. 03:23
the realtime being munged in the now()s is also not very nice 03:24
03:26 xinming left 03:27 vrurg joined, xinming joined
guifa Iā€™d guess that the fractional second value being given to Raku is a float 03:30
Ah, but weird, itā€™s being reported back as a Rat 03:32
jdv79 the math inside at least DateTime, maybe elsewhere, can cause errors 03:34
guifa can you give an example of such an error?
jdv79 there seems to be a lot of little places that could use refinement, its not just one or 2 places
guifa would be interested if the timezone aware datetimes also have the errors
jdv79 github.com/rakudo/rakudo/blob/mast...e.pm6#L211 is one 03:35
03:41 frost-lab joined
guifa Thatā€™s not an error, thatā€™s just design. Most DateTime classes in languages donā€™t take into account fractional seconds. Java has one of the most thorough Date/Time libraries and it has the distinction that Raku does (DateTime with second precision vs Instant with fractional precision) 03:41
s/one of/the most 03:42
the big difference is that it does return nano seconds as an int. Raku is getting values supposedly somewhere in there: 03:44
m: (now.to-posix.head.denominator xx 100000).max.say 03:45
camelia 199728
jdv79 so changing the fractional second value just through a type conversion is "by design"?
i can't think of a reason why that would be the case 03:47
guifa TBH, probably because everyone else does it that way. DateTime classes arenā€™t generally thought of as a high-precision class. DateTime calculations arenā€™t the fastest things in the world, and my guess is the general thinking is when time precision is critical, operations on those times are also time-critical, hence the birth of Instant-like representations that are normally a single number that will normally just require simple +/- 03:52
operations on it
I know thatā€™s probably not a satisfying answer lol
03:52 skids left
jdv79 no, its not. it could be better. even conversion to and fro instant and datetime incur fp errors 03:56
i encountered this just the other day when trying to do something else. i've got it bandaided enough to work for now. maybe some day i'll circle back and look into it more:) 03:57
04:07 xinming left 04:08 xinming joined 04:10 cpage left 04:11 cpage joined 04:14 xinming left
BenGoldberg m: dd now.to-posi 04:14
camelia No such method 'to-posi' for invocant of type 'Instant'. Did you mean
'to-posix'?
in block <unit> at <tmp> line 1
BenGoldberg m: dd now.to-posix
camelia (<796516498482/497>, Bool::False)
04:14 xinming joined 04:16 BenGoldberg left 04:21 vrurg_ joined 04:22 vrurg left
guifa jdv79: for what itā€™s worth, Iā€™ve done some more digging. DateTime actually can handle fractionals just fine (surprisingly). The issue is two fold 04:23
MoarVM returns fractional seconds as a float
Instant coerces them to a Rat 04:24
The easiest fix (which should provide some extremely minor speed optimizations) would be to simply have Instant use Num values instead
04:31 phogg left 04:32 xinming left, molaf left 04:33 xinming joined 04:53 xinming left 04:55 xinming joined 05:03 xinming left, phogg joined, phogg left, phogg joined 05:04 xinming joined 05:27 xinming left, zacts joined, xinming joined, zacts left 05:36 bocaneri joined 05:39 zacts joined 05:42 zacts left 05:49 xinming left, xinming joined 05:56 xinming left 05:58 xinming joined 06:05 ufobat__ joined 06:31 wamba joined 06:41 Xliff joined
Xliff . 06:42
06:48 zacts joined 06:50 domidumont joined
Xliff timotimo jnthn: How hard would it be to make nativecast handle Blob? 06:52
Consider repl.it/@Xliff/UnwrittenUniqueMono...#main.raku
I think it would be useful if it could go the other way around. Have the Buf cast into the allocated CArray. Especially when we need to take a buffer from C, manipulate it in raku and then resubmit it back to C. 06:53
The write-* functions in Buf would me extremely helpful!
Just a thought. Thanks for listening. 06:54
06:57 maettu joined 06:58 abraxxa left 06:59 abraxxa joined, abraxxa left 07:00 abraxxa joined, pecastro joined 07:04 Doc_Holliwould joined, abraxxa left 07:06 abraxxa joined 07:09 Altai-man joined 07:15 m_ left 07:22 maettu left 07:23 Sgeo left 07:25 ensamvarg left 07:29 dakkar joined 07:30 ensamvarg joined 08:16 zacts left 08:17 wamba left 08:22 Xliff left 08:24 wamba joined 08:44 zacts joined 08:54 maettu joined 08:58 dustinm` left, maettu left 08:59 dustinm` joined, perfi joined 09:14 maettu joined 09:18 nige left 09:19 nige joined 09:20 perfi is now known as hexsum 09:23 hexsum is now known as perfi 09:24 perfi left 09:25 perfi joined 09:40 Doc_Holliwould left
cpan-raku New module released to CPAN! Math::Libgsl::Permutation (0.0.6) by 03FRITH 09:40
09:43 sena_kun joined 09:44 Altai-man left 09:49 Doc_Holliwould joined 09:57 pecastro left 09:58 maettu left 10:17 wamba left 10:29 wamba joined 10:54 aborazmeh joined, aborazmeh left, aborazmeh joined 11:30 Doc_Holliwould left 11:34 aborazmeh left 11:43 maettu joined 11:45 nige_ joined, nige left 11:57 mid_laptop left 12:24 andrzejku joined
andrzejku hello what's the status of raku gaming? 12:24
is it better?
timotimo i haven't done anything in that space for a while 12:25
andrzejku timotimo: ok 12:26
timotimo my last contributions were related to sdl and cairo, fwiw 12:27
12:33 frost-lab left 12:40 MasterDuke left 12:53 skids joined 12:58 skids left
cpan-raku New module released to CPAN! Gnome::GObject (0.16.12) by 03MARTIMM 12:59
New module released to CPAN! Gnome::N (0.17.13) by 03MARTIMM
13:03 molaf joined 13:06 aborazmeh joined, aborazmeh left, aborazmeh joined
jdv79 guifa: fix for what? i was looking for precision fixes not perf opti. Rat is better. 13:07
13:10 perfi left 13:11 molaf left 13:21 leont joined 13:34 rindolf joined
SmokeMachine m: grammar Bla { rule num { \d+ } }; say 42 ~~ /<num=.Bla::num>/ # this is ok 13:41
camelia ļ½¢42ļ½£
num => ļ½¢42ļ½£
13:42 Altai-man joined
SmokeMachine m: grammar Bla { rule num($a) { \d+ } }; say 42 ~~ /<num=.Bla::num(13)>/ # how can I make this work? 13:42
camelia Too few positionals passed; expected 2 arguments but got 1
in regex num at <tmp> line 1
in block <unit> at <tmp> line 1
13:44 sena_kun left
lizmat m: grammar Bla { rule num($a) { \d+ } }; say 42 ~~ /<num=.Bla::num($/,13)>/ 13:44
camelia Too few positionals passed; expected 2 arguments but got 1
in regex num at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat hmmm
SmokeMachine lizmat: I've tried the too... :( 13:45
lizmat moritz might know more 13:46
13:47 aborazmeh left
lizmat I seem to recall that rules / tokens / regex are methods on the grammar, and take a cursor parameter 13:47
m: grammar Bla { rule num { \d+ } }; dd Bla.^find_method("num").signature # but that doesn't look like that
camelia :(Bla: *%_)
13:51 perfi joined 13:53 Sgeo joined 13:59 perfi left
SmokeMachine Iā€™ve tried even with .assuming... with no luck... 13:59
14:00 mid_laptop joined
guifa jdv79: I guess Iā€™m still struggling to understand to understand exactly what you want. DateTime handles fractional seconds with Rats and Nums. now() obtains Rats converted from Nums which is an operation that loses precision. Where are you expecting to get extra precision? (and remembering that precision != accuracy, as fractional time from now() is several orders of magnitude more inaccurate than a FP error) 14:02
lizmat guifa: I think TimToady looked beyond OS's that provided time information as inaccurate floating point values 14:03
and that's why he insisted on Instants being Rat (or even FatRat) even though that may not be very meaningful today 14:04
SmokeMachine moritz: any suggestion about the namespaces rule with arguments? 14:06
guifa lizmat: that I can get. Javaā€™s library effectively uses Rats by way of providing fractional seconds as integral nanoseconds (so always denominator = 1000000000). But DateTime will already keep the Rat from an instant. Hence my question of where the extra precision was supposed to come from 14:10
m: say now.DateTime.second.WHAT;
camelia (Rat)
lizmat the extra precision *could* be provided by DateTime.new ? 14:11
e.g. when working on a log of some RealTime tracking system that produces *millions* of events / second ?
14:12 xinming left, xinming joined 14:13 Xliff joined
guifa sure 14:13
m: say DateTime.new( year => 2020, second => 1 / 1000000000000).second.nude
camelia (1 1000000000000)
guifa m: say ( DateTime.new(:2020year, second => 3 / 1000000000000) - DateTime.new(:2020year, second => 1 / 1000000000000) ).Rat.nude 14:16
camelia (1 500000000000)
jdv79 right, precision and accuracy improvements are both things i'm interested in. 14:19
SmokeMachine .ask moritz Hi! Do you know if is thee a way of doing this work?`grammar Bla { rule num($a) { \d+ } }; say 42 ~~ /<num=.Bla::num(13)>/` 14:24
tellable6 SmokeMachine, I'll pass your message to moritz
14:26 maettu left 14:29 maettu joined, maettu left 14:30 maettu joined, maettu left 14:44 skids joined 14:46 mid_laptop left 14:49 epony left
guifa Accuracy and precision seem to be work okay based on the above example with DateTime, though. now() gets nanosecond values from MoarVM (and probably JVM, and only milisecond from JS), but realistically, its accuracy will be microsecond-ish. Thatā€™s an issue that libraries like std::chrono::high_resolution_clock have, too. The Instant created from now() is a Rat approximation, so math on those derived values will have inaccuracies of up 14:50
2Īµ or 0.000002 ā€” a FP error would be several orders of magnitude smaller.
So I guess Iā€™m just failing to see where we could make improvements (except make explicit that Instant is a Real, so that each implementation can provide values in the most accurate/precise way possible, which for Rakudo would be either not Ratā€™ing the float from MoarVM, or using Īµ = 10ā»ā¹āŗ instead of 10ā»ā¶)
14:51 maettu joined 14:58 epony joined
jdv79 guifa: i'll try to come up with concrete examples of what i'm talking about - maybe next week 15:03
thanks for pokin about
15:12 molaf joined, molaf left, Doc_Holliwould joined 15:14 molaf joined
guifa jdv79: yeah, I think examples will help. It may be that thereā€™s some over eager coercion somewhere, or places where behavior is inconsistent. (I already found, for instance, that DateTime.now is actually different from DateTime.new(now) which was surprising to me ā€”Ā the latter uses a Ratā€™ed value because of the intermediate Instant, but DateTime.now uses the raw float value) 15:19
jdv79 yes, there are a few, maybe a bunch, of things like that. 15:20
i would love to look/work on it but sadly other things call atm
15:25 maettu left 15:30 domidumont left 15:52 Doc_Holliwould left 15:54 mid_laptop joined 15:55 ufobat__ left
lizmat guifa: could you make a ticket for that? DateTime.now and DateTime.new(now) should be the same 15:58
16:15 suzusime[m] left
cpan-raku New module released to CPAN! FDF (0.0.2) by 03WARRINGD 16:34
16:37 dakkar left 16:40 molaf left 16:44 andrzejku left 16:56 approaching236 joined 17:23 Doc_Holliwould joined, natrys joined 17:32 pecastro joined 17:36 lichtkind joined 17:42 sena_kun joined 17:44 Altai-man left, pecastro left 17:51 approaching236 left 17:58 maettu joined 18:08 approaching236 joined
cpan-raku New module released to CPAN! PDF::Class (0.4.6) by 03WARRINGD 18:21
18:25 approaching236 left 18:28 bocaneri left 18:35 maettu left 18:39 skids left 18:49 mowcat joined 18:55 maettu joined 19:00 molaf joined 19:13 MasterDuke joined 19:16 maettu left 19:20 Manifest0 left 19:22 Manifest0 joined 19:36 rbt joined 19:41 rbt left, rbt joined 19:46 andrzejku joined 19:57 rindolf left 20:03 MasterDuke left 20:13 sena_kun left 20:14 zacts left 20:15 MasterDuke joined 20:20 wamba left 20:23 skids joined 20:58 squashable6 left 20:59 squashable6 joined 21:10 andrzejku left 21:23 aluaces left 21:35 natrys left, natrys joined, natrys left 21:39 pecastro joined 22:05 lichtkind left 22:08 dogbert17 left, dogbert17 joined 22:09 mrsolo left 22:10 mrsolo joined 22:25 oodani left 22:26 oodani joined 22:54 __jrjsmrtn__ joined 22:55 perryprog left 22:56 perryprog joined, _jrjsmrtn left 23:25 squashable6 left 23:26 pecastro left 23:27 squashable6 joined 23:32 Doc_Holliwould left 23:50 MasterDuke left 23:51 leont 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!