🦋 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.
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
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
jdv79 MoarVM panic: Internal error: zeroed target thread ID in work pass 01:42
what in the world...
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)...
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 :-)
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
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
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
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
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
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
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
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
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)
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
Xliff . 06:42
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
cpan-raku New module released to CPAN! Math::Libgsl::Permutation (0.0.6) by 03FRITH 09:40
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
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
jdv79 guifa: fix for what? i was looking for precision fixes not perf opti. Rat is better. 13:07
SmokeMachine m: grammar Bla { rule num { \d+ } }; say 42 ~~ /<num=.Bla::num>/ # this is ok 13:41
camelia ｢42｣
num => ｢42｣
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
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
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: *%_)
SmokeMachine I’ve tried even with .assuming... with no luck... 13:59
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 ?
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
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⁻⁶)
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
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
lizmat guifa: could you make a ticket for that? DateTime.now and DateTime.new(now) should be the same 15:58
cpan-raku New module released to CPAN! FDF (0.0.2) by 03WARRINGD 16:34
cpan-raku New module released to CPAN! PDF::Class (0.4.6) by 03WARRINGD 18:21

Powered by Cro and the Raku® Programming Language.

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

Thank you!