|
🦋 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. |
|||
|
00:03
Inline_ joined
00:04
Inline left,
Inline_ is now known as Inline
00:28
yewscion_ joined
00:33
Inline left,
yewscion_ left
00:43
Inline joined
00:53
yewscion_ joined
01:33
maylay left
01:36
maylay joined
01:47
jpn joined
01:51
jpn left
01:55
yewscion_ left
02:08
hulk joined,
kylese left
02:10
Inline left
02:14
yewscion_ joined
02:19
yewscion_ left
03:15
hulk left,
kylese joined
03:46
yewscion_ joined
03:53
yewscion_ left,
eseyman left
03:55
eseyman joined
03:56
jpn joined
04:00
jpn left
04:20
stanrifkin_ left
04:30
kylese left
04:33
kylese joined
04:37
Aedil joined
04:42
Sgeo_ joined
04:46
Sgeo left
04:56
JimmyZhuo joined
05:14
yewscion_ joined
05:19
yewscion_ left
05:41
JimmyZhuo left
06:00
derpydoo joined
06:12
derpydoo left
06:42
jpn joined
06:47
jpn left
06:49
derpydoo joined
06:51
stanrifkin joined
07:06
wayland76 joined
07:10
Sgeo_ left
07:59
vrurg joined
08:00
vrurg_ left
08:04
derpydoo left
08:35
jpn joined
08:45
jpn left
08:55
jpn joined
08:59
jpn left
09:18
dakkar joined
09:23
jpn joined
09:25
jpn left
09:43
jpn joined
|
|||
| librasteve | looks like umami will win the FOSS analytics race with tinylytics a close 2nd | 09:59 | |
| wonders what is used on raku.org? | 10:00 | ||
| (for analytics) | |||
| lizmat | I'm not sure anything is used | 10:01 | |
| apart from access logs ? | |||
| librasteve | yeah - well logs is another option and better in many ways - but my markating brain wants to see pretty dashboard widgets ;-( | 10:02 | |
| lizmat | I wouldn't be against that... it's just that nobody's done that for raku.org afaik | 10:04 | |
|
10:12
sena_kun joined
10:20
lichtkind joined
10:35
grondilu joined
|
|||
| grondilu | Hello | 10:35 | |
| tellable6 | 2025-02-25T12:11:45Z #raku <melezhik> grondilu: looks like you forgot to declare some deps for chess - sparky.sparrowhub.io/report/grondi...hess/23616 | ||
| 2025-02-25T12:28:00Z #raku <melezhik> grondilu: bitcoin-raku-tools ci fails - sparky.sparrowhub.io/report/grondi...ools/23618 | |||
| grondilu | m: say reduce { my uint64 $ = $^a +^ $^b }, my uint64 @ = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; | 10:36 | |
| camelia | Cannot unbox negative bigint into native unsigned integer in block <unit> at <tmp> line 1 |
||
| librasteve | hi | ||
| grondilu | m: say map 0 < * < 2**64, 14256035878013490812, 8879459831392612329, 0, 17930561480947107081 | ||
| camelia | (True True False True) | ||
| grondilu | m: say map 0 <= * < 2**64, 14256035878013490812, 8879459831392612329, 0, 17930561480947107081 | 10:37 | |
| camelia | (True True True True) | ||
| grondilu | seems like a bug tbh | ||
| librasteve | m: say map (0 <= * < 2**64), [14256035878013490812, 8879459831392612329, 0, 17930561480947107081] | 10:38 | |
| evalable6 | (True True True True) | ||
| Raku eval | (True True True True) | ||
| lizmat | which is the wrong value you think? | ||
| grondilu | the initial reduce should not fail, should it? | 10:39 | |
| m: say reduce [+^] my uint64 @ = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; | |||
| camelia | Cannot resolve caller reduce(Int:D); none of these signatures matches: (&with, +list) in block <unit> at <tmp> line 1 |
||
| grondilu | m: say reduce [+^] |my uint64 @ = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; | ||
| camelia | Cannot resolve caller reduce(Int:D); none of these signatures matches: (&with, +list) in block <unit> at <tmp> line 1 |
||
| grondilu | m: say [+^] my uint64 @ = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; | 10:40 | |
| camelia | -13385940437226619748 | ||
| grondilu | an negative output, wth? | ||
| FYI I was trying to implement this : hgm.nubati.net/book_format.html | 10:41 | ||
|
10:42
Inline joined
|
|||
| grondilu | it works on seven out of the nine examples. | 10:43 | |
| the example above is an attempt at debugging on of the failures. | 10:44 | ||
| librasteve | lools like you are adding the bitwise negation of all the uint64s, right | 10:45 | |
| grondilu | it's not the bitwise negation, it's bitwise xor | ||
| I really don't get why it should produce a bigint at any point. | 10:46 | ||
| let alone a negative one. | |||
| m: say reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, my uint64 @ = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; | 10:47 | ||
| camelia | 5060803636482931868 | ||
| grondilu | oh that works better | ||
|
10:48
Inline left
|
|||
| librasteve | oh yeah I just looked at the unary form of the operator | 10:48 | |
| grondilu | still fails the tests, though. | ||
| librasteve | Integer bitwise XOR operator: Coerces both arguments to Int and does a bitwise XOR (exclusive OR) operation. | 10:50 | |
| ^^ this looks a bit worrying | |||
| (maybe the doc is wrong) docs.raku.org/routine/%2B%5E#(Oper...)_infix_+^ | 10:52 | ||
|
10:57
jpn left
10:58
librasteve_ joined
|
|||
| yeah, the doc is wrong | 10:58 | ||
| librasteve_ | www.irccloud.com/pastebin/Mz6KKWSK | ||
| grondilu | well, I've just verified with a C program and 5060803636482931868 is the correct xor, at least for the four literal values above. | 10:59 | |
| librasteve | ok - not sure why its failing some of tests then... | 11:00 | |
| grondilu | damn I may have to write the full C program to see at what point it differs from the raku one :( | 11:01 | |
| librasteve | maybe the failing ones are -ve in 2s-complement and the raku "say" (or whatever you are using to do the test comparison) does speak uint64 | ||
| does NOT | 11:02 | ||
|
11:02
jpn joined
|
|||
| grondilu | the actual output I use has a *.fmt("%016x") last stage. | 11:03 | |
| uint16 fits in 16 characters in hexadecimal, right? | |||
| librasteve | unit64 ;-) | 11:04 | |
| uint64 | |||
| grondilu | yeah that's what I meant, sorry | ||
| librasteve | yeah | 11:05 | |
| hmmm - I would be a bit surprised if fmt was broken since that is likely just C under the hood ... would have to go look at the source to be sure | 11:07 | ||
| if you can find a short sequence (ie the four uints) that fail, I can help to double check | 11:08 | ||
|
11:12
JimmyZhuo joined
|
|||
| grondilu | m: say Blob[uint64].new: 14256035878013490812, 8879459831392612329, 0, 17930561480947107081 | 11:15 | |
| camelia | Blob[uint64]:0x<C5D79D196E37D67C 7B3A2DABD781AFE9 0000000000000000 F8D626AAAF278509> | ||
| grondilu | ^that seems fine | ||
| but: | |||
| m: dd Blob[uint64].new: 14256035878013490812, 8879459831392612329, 0, 17930561480947107081 | |||
| camelia | uint64 = Blob[uint64].new(-4190708195696060804,8879459831392612329,0,-516182592762444535) | ||
| grondilu | what's with these negative numbers?? | ||
| m: my $blob = Blob[uint64].new: 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; say $blob[0] | 11:16 | ||
| camelia | 14256035878013490812 | ||
| librasteve | i suspect that they come from some kind of "print" or "parse" operation that does understand unit64 | ||
| m: my uint64 $z = 14256035878013490812; | 11:18 | ||
| evalable6 | |||
| Raku eval | |||
| librasteve | m: my uint64 $z = 14256035878013490812; say $z | 11:19 | |
| Raku eval | 14256035878013490812 | ||
| evalable6 | 14256035878013490812 | ||
| grondilu | I don't think that's the issue. I keep getting a "Cannot unbox negative bigint into native unsigned integer" even though I only feed uint64 values. | 11:20 | |
| besides I use the very verbose reduce : C<reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }> | 11:21 | ||
| librasteve_ | www.irccloud.com/pastebin/GNGeJ4Pf | 11:22 | |
| grondilu | that first line is ridiculous | ||
| librasteve | i tried this in the repl (Welcome to Rakudo™ v2024.10.) and as you can see the repl 'echo' has the same "bug" that you report | ||
| grondilu | what method is the repl using to display a value, if not gist? | 11:23 | |
| pretty? | |||
| librasteve | yeah - I agree that there may be an issue here ... maybe the repl and your code (unknowlingly) depend on the same method | 11:24 | |
|
11:25
jpn left
|
|||
| lizmat | by default .gist: docs.raku.org/programs/03-environm...rint_loop) | 11:27 | |
| grondilu | so what's happening then? | 11:28 | |
| m: 14256035878013490812.fmt("%064b") | 11:29 | ||
| camelia | ( no output ) | ||
| grondilu | m: say 14256035878013490812.fmt("%064b") | ||
| camelia | 1100010111010111100111010001100101101110001101111101011001111100 | ||
| lizmat | m: my uint64 $a = -4190708195696060804; say $a | ||
| camelia | Cannot unbox negative bigint into native unsigned integer in block <unit> at <tmp> line 1 |
||
| grondilu | msb is 1, so maybe that's the issue but it shouldn't be since it's unsigned. | 11:30 | |
| librasteve | so the code path is going to invoke big int only if the msb is 1 | ||
| grondilu | m: say map *.fmt("%064b").substr(0, 1), 14256035878013490812, 8879459831392612329, 0, 17930561480947107081 | ||
| camelia | (1 0 0 1) | ||
| librasteve | yes, so the negative number issue only kicks in with msb set | 11:31 | |
| ah, so the raku literal invokes big int first ... and does not consider that uint64 is the type of the scalar | 11:34 | ||
| (an induction, not tested) | |||
| lizmat | ok, I think there's an issue with Buf.join, and an issue with nqp::arpos_u | ||
| *atpos_u | 11:35 | ||
|
11:35
jpn joined
|
|||
| librasteve | so the workaround is to not use raku literal parser to make a uint64 | 11:35 | |
| lizmat | m: my uint @a = 14256035878013490812; use nqp; nqp::atpos_u(@a,0) | ||
| camelia | ( no output ) | ||
| lizmat | m: my uint @a = 14256035878013490812; use nqp; dd nqp::atpos_u(@a,0) | ||
| camelia | -4190708195696060804 | ||
| grondilu | what else could I use if not literals? | 11:36 | |
| librasteve | looks like lizmat is on the case, I may be wrong | 11:37 | |
| lizmat | well, trying to golf the issue at the moment | ||
| m: my uint @a = 14256035878013490812; use nqp; my uint64 $a = nqp::atpos_u(@a,0); say $a # appears to be the base of a workaround | 11:40 | ||
| camelia | 14256035878013490812 | ||
| JimmyZhuo | patrickb: C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '-z' | 11:42 | |
| C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: use the --help option for usage information | |||
| collect2.exe: error: ld returned 1 exit status | |||
| gmake: *** [makefile:158: win-runner.exe-tmpl] Error 1 | |||
|
11:42
jpn left
|
|||
| grondilu | m: my uint64 ($a, $b, $c, $d) = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; say reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, $a, $b, $c, $d; | 11:47 | |
| camelia | 5060803636482931868 | ||
| grondilu | hum, not sure why that works here and not in my function :/ | ||
|
11:54
jpn joined
|
|||
| lizmat | github.com/rakudo/rakudo/commit/01369236da # fix for dd Buf[uint64]... | 11:58 | |
| grondilu | m: my uint64 ($a, $b, $c, $d); $a +^= 14256035878013490812; $b +^= 8879459831392612329; $c = 0; $d +^= 17930561480947107081; say reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, $a, $b, $c, $d; | 12:11 | |
| camelia | 5060803636482931868 | ||
| grondilu is very confused | |||
| again I don't get why I can't reproduce the mistake. oh well | 12:12 | ||
| wow if I copy paste the exact same line above into my function, I still get the error. | 12:16 | ||
| m: sub foo() { my uint64 ($a, $b, $c, $d) = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; say reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, $a, $b, $c, $d }; say foo | |||
| camelia | Cannot unbox negative bigint into native unsigned integer in sub foo at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| grondilu | ^here see? | 12:17 | |
| it's the exact same code except it is into a function now. | |||
| let me try to golf it even more | |||
| m: sub () { my uint64 ($a, $b) = 14256035878013490812, 17930561480947107081; say reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, $a, $b }() | 12:18 | ||
| camelia | 4396001092002927477 | ||
| grondilu | damn | ||
| m: sub () { my uint64 ($a, $b, $c, $d) = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; say reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, $a, $b, $c, $d }() | |||
| camelia | Cannot unbox negative bigint into native unsigned integer in sub at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| grondilu | m: sub () { my uint64 ($a, $b, $c, $d) = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081; reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, $a, $b, $c, $d }() | 12:19 | |
| camelia | Cannot unbox negative bigint into native unsigned integer in sub at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| grondilu | m: sub () { reduce -> uint64 $a, uint64 $b { my uint64 $ = $a +^ $b }, my uint64 ($a, $b, $c, $d) = 14256035878013490812, 8879459831392612329, 0, 17930561480947107081 }() | 12:21 | |
| camelia | Cannot unbox negative bigint into native unsigned integer in sub at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| grondilu | lizmat: ^ | ||
|
12:35
maylay left
12:37
maylay joined
12:41
jpn left
13:04
dakkar left
13:05
dakkar joined
13:16
maylay left
13:19
maylay joined,
maylay left
13:26
maylay joined,
JimmyZhuo left
13:28
Inline joined,
maylay left
13:34
vrurg_ joined,
maylay joined
13:36
vrurg left
14:02
Inline_ joined,
Inline is now known as Guest8877,
Guest8877 left,
Inline_ is now known as Inline
|
|||
| grondilu | Well, it turns out I was not processing the en-passant rule properly. It works now. | 14:05 | |
|
14:08
Inline left
14:09
yewscion_ joined
|
|||
| [Coke] | If someone is looking for a way to help out with the release that doesn't require writing any code, I have a list of things found in blin that need tickets opened on various modules. | 14:15 | |
| Please reach out if you'd like to volunteer some time and help improve the ecosystem. | |||
| anton - raku.land/zef:antononcube/LLM::Ret...Generation has a cyclic dependency, per blin | 14:16 | ||
| so we can't test it. | |||
|
14:17
yewscion_ left
|
|||
| [Coke] | (I don't see anything obvious using zef-deps) | 14:18 | |
|
14:22
Aedil left
14:23
jpn joined
14:28
jpn left
14:33
Aedil joined
|
|||
| [Coke] | e.g. one ticket is a missing dep from this meta6.json: codeberg.org/1-1sam/raku-ebread/sr...on#L16-L22 | 14:36 | |
| If that's a valid syntax, I need to update the blin instructions - if it's not, that package needs a ticket opened to clean up their dep list | 14:37 | ||
|
14:39
yewscion_ joined
14:44
yewscion_ left
14:47
jpn joined
|
|||
| ugexe | it is valid - github.com/ugexe/zef/blob/f924b1fb...#L124-L127 | 15:03 | |
| [Coke] | excellent, thanks. | 15:09 | |
| Perl6::Tracer so old zef complains about missing a META6.json file | 15:20 | ||
| ... would it be appropriate to remove that from rea at this point? | |||
|
15:22
codesections joined
15:23
codesections left,
codesections joined
|
|||
| [Coke] | * `Learn::Raku::With` : test-depends on `CORE:ver<6.d>:auth<perl>` | 15:41 | |
| Not sure what that's supposed to mean. | |||
| (the CORE...) | |||
| ugexe | that is the name of the "distribution" containing Test, NativeCall, etc | 15:49 | |
|
15:50
sena_kun left
|
|||
| [Coke] | ok, but zef can't find it. | 15:53 | |
|
15:53
sena_kun joined
|
|||
| [Coke] | let me double check | 15:53 | |
| Yup: ===> Failed to find dependencies: CORE:ver<6.d>:auth<perl> | 15:54 | ||
| that's with 'zef install Learn::Raku::With' | |||
| ugexe | yeah for a couple of reasons | 15:59 | |
| [Coke] | (Also do we want to, in general, encourage dependency on Test, NativeCall explicitly? That could be another Blin report we could eventually use to drive updates from module owners) | 16:01 | |
| ugexe | first, the versioning of the core modules was changed at some point to something more useful in one way and less useful in (as we see here) another. the other is auth was also changed | ||
| [Coke] | ok - if you can tell me the new, desired way, I can open the ticket with that. (if the desired way is "don't do that", that is also fine) | 16:02 | |
| ugexe | m: say Compiler.new.version; say say Compiler.new.auth; | 16:03 | |
| camelia | v2025.02.326.gcbc.4.af.86.f Yet Another Society True |
||
| ugexe | so i'd probably remove the version since the scheme was changed entirely | ||
| and auth would be changed to "Yet Another Society" although its probably fine to just drop that too | 16:04 | ||
| [Coke] | And so that will verify we have Test and NativeCall - but isn't that implied with all the versions of Rakudo so far? | ||
| ugexe | to put another way: we don't have a good way to pin our dependencies on core modules | ||
| no | 16:05 | ||
| [Coke] | (and most modules don't declare a dependency on "Test", I think) | ||
| ugexe | zef uninstall CORE | ||
| well it doesn't matter much what most modules do if they are doing the non-ideal thing | 16:06 | ||
| [Coke] | Ok - so anyone with 'use Test' should be declaring that dependency. | ||
| ... I'm trying to document the ideal thing. | |||
| and enforce it (or at least warn) in blin | |||
| ugexe | yeah, per the original design docs any module that is used should be listed. however where it gets a bit messy is people have shown they generally want to list distribution names and not module names | 16:07 | |
| [Coke] | so either depend on Test/NativeCall directly, or use CORE - what's the preferred way to refer to CORE now? | ||
| where in this case Test isa module and CORE isa distribution, aye? | |||
| ugexe | well ideally rakudo breaks all the core distributions into multiple distributions | ||
| otherwise whatever i tell you is working around that | 16:08 | ||
| because yeah listing CORE in your depends is kind of dumb | |||
| listing Test or NativeCall is better and means theoretically we can pin each of them (and provide dual life versions in the far future) | |||
| [Coke] | So is it OK in your opinion for this particular instance to ask them to just remove it for now? | ||
| OK - will do that. | 16:09 | ||
| ugexe | fwiw i list Test and NativeCall in my depends | ||
| github.com/rakudo/rakudo/pull/5756 | |||
| [Coke] | and I will see about adding some blin logic to note when someone has 'use Test' but didn't declare it. | ||
| ugexe | that is some bit rotting PR to break the core dists up | ||
|
16:14
Sgeo joined
16:21
yewscion_ joined
16:26
yewscion_ left
16:28
yewscion_ joined
16:36
yewscion_ left
16:37
yewscion_ joined
16:42
yewscion_ left
16:46
Guest26 joined,
Geth left,
jpn left,
Geth joined
16:53
codesections left
17:20
yewscion_ joined
17:22
swaggboi left
17:26
swaggboi joined
17:32
dakkar left
17:33
jpn joined
17:41
human_blip left,
yewscion_ left
17:43
human_blip joined
17:44
yewscion_ joined
17:46
jpn left
17:50
Guest26 left
18:07
jpn joined
18:16
PipStuart left
18:35
Guest24 joined
18:39
Guest24 left
18:51
apac joined
18:53
jpn left
19:01
jpn joined
19:05
jpn left
19:43
maylay left
19:45
maylay joined
19:53
codesections joined
20:11
abraxxa-home joined
20:12
abraxxa-home left
20:13
abraxxa-home joined
20:28
jpn joined,
[Coke] left
20:31
codesections left,
codesections joined
20:32
jpn left
20:35
abraxxa-home left
20:36
[Coke] joined
20:37
abraxxa-home joined
20:48
librasteve_ left
20:58
yewscion_ left,
jpn joined
21:06
codesections left,
codesections joined
21:23
abraxxa-home left
22:06
wayland76 left
22:08
yewscion_ joined
22:10
yewscion_ left
22:33
wafflus joined
22:34
wafflus left
22:52
codesections left
23:11
wbooze joined
23:22
sena_kun left
23:49
Aedil left
23:53
lichtkind left
|
|||