🦋 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:43 jpn joined 00:48 jpn left 00:49 eseyman left 00:57 kst left 01:01 eseyman joined 01:09 hulk joined, kylese left 01:25 jpn joined, kst joined 01:30 jpn left 02:15 hulk left, kylese joined 02:22 jpn joined 02:26 jpn left 03:04 jpn joined 03:23 soverysour joined, soverysour left, soverysour joined 03:28 soverysour left 03:57 Chanakan left 03:59 Chanakan joined 05:30 Sgeo left 06:15 lizmat_ joined 06:19 lizmat left 06:36 jpn left
ab5tract Currently: $nodes.EVAL 06:37
07:47 lizmat_ left, lizmat joined 08:04 melezhik joined
melezhik . 08:05
08:05 wayland76 joined
melezhik Sparky 0.2.4 has just released with some cool goodies - raku.land/zef:melezhik/Sparky/changes?v=0.2.4 08:05
08:09 dakkar joined 08:18 thaewrapt left 08:29 thaewrapt joined 08:35 thaewrapt left 08:38 sena_kun joined 08:47 thaewrapt joined 08:52 thaewrapt left 08:53 melezhik left 09:04 thaewrapt joined 09:17 thaewrapt left 09:29 thaewrapt joined 09:34 thaewrapt left 09:46 thaewrapt joined 10:04 thaewrapt left 10:09 thaewrapt joined 10:16 thaewrapt left 10:28 thaewrapt joined 10:35 jpn joined 10:36 raiph joined 10:40 jpn left
raiph m: glot.io/snippets/gwnd0zkhjg 10:44
camelia ===SORRY!=== Error while compiling <tmp>
Confused
at <tmp>:1
------> https:⏏//glot.io/snippets/gwnd0zkhjg
expecting any of:
colon pair
raiph m: HEAD glot.io/snippets/gwnd0zkhjg 10:45
camelia ===SORRY!=== Error while compiling <tmp>
Confused
at <tmp>:1
------> HEAD https:⏏//glot.io/snippets/gwnd0zkhjg
expecting any of:
colon pair
raiph c: HEAD glot.io/snippets/gwnd0zkhjg
committable6 raiph, It looks like a URL, but mime type is ‘text/html; charset=utf-8’ while I was expecting something with ‘text/plain’ or ‘perl’ in it. I can only understand raw links, sorry.
10:49 thaewrapt left 11:01 thaewrapt joined 11:07 soverysour joined, soverysour left, soverysour joined
raiph Can I run an evalbot against a multi file program? 11:09
(I'm trying to test a `use` statement.)
lizmat I wouldn't know
raiph (So I've got _two_ file program, each with 3 lines.) 11:10
lizmat I guess the closest thing would be to create a gist with two files and the output your get and post that here ?
raiph Well I've got a glot.io link so folk can run the program: 11:11
glot.io/snippets/gwnd0zkhjg
But that's running a 2022 Rakudo.
11:11 soverysour left
lizmat raiph: do you want to export the lexical sub "show" ? 11:13
if so, then: Map.new: '&show' => &show
and get rid of the "is export" on the sub 11:14
as it's not needed
raiph lizmat: thx, and you're right, but that's not what I'm working on
lizmat: the glot program works fine
11:15 thaewrapt left
raiph lizmat: it gets the desired result 11:15
11:15 thaewrapt joined
raiph lizmat: but I don't trust it's good code (even with your fixes) 11:15
lizmat: and you are precisely the person I'm doing prep work for 11:16
lizmat: i wanted to clarify some things before approaching you
lizmat fwiw, code looks ok to me... |named-args first runs named-args(), which returns a Hash, and then flattens that as named arguments 11:17
raiph lizmat: yes, that's the desired evaluation 11:18
lizmat I just wouldn't call the helper sub EXPORT2
raiph lizmat: fair enough, but that's not what my concern is
lizmat: it's mostly about Rakudo and RakuAST 11:19
lizmat you worry whether that would stop working in RakuAST ? 11:20
I don't see why it wouldn't
raiph lizmat: Rakudo's non-RakuAST processing of `use` statement args appears to be a bit of a mess
lizmat ah, yes, it most definitely is, from an implementation point of view
"use" is very overloaded
raiph lizmat: but i'm hopeful you are taking the opportunity of the RakuAST work to simplify 11:21
lizmat I hope that at some time, we'll have a "pragma" directive
raiph lizmat: so I stumbled on to something that worked with a `use`
lizmat: but i don't trust it's wise to rely on it
m: use Test -> { :foo } 11:22
camelia ===SORRY!=== Error while compiling <tmp>
Error while importing from 'Test':
no EXPORT sub, but you provided positional argument in the 'use' statement
at <tmp>:1
------> use Test -> { :foo }⏏<EOL>
expecting any of:
…
lizmat i'm afraid we will have to support "use" with its current semantics into the far future
raiph m: use Test sub { :foo }
camelia ===SORRY!=== Error while compiling <tmp>
Error while importing from 'Test':
no EXPORT sub, but you provided positional argument in the 'use' statement
at <tmp>:1
------> use Test sub { :foo }⏏<EOL>
expecting any of:
…
raiph huh. that seems different from 2022 11:23
lizmat bisectable6: old=2022.02 use Test -> { :foo } 11:25
bisectable6 lizmat, Bisecting by output (old=2022.02 new=851aa49) because on both starting points the exit code is 1
raiph lizmat: i'm wrong
bisectable6 lizmat, bisect log: gist.github.com/425504c114ff03efbe...c327fea8e9 11:26
lizmat, (2024-01-10) github.com/rakudo/rakudo/commit/47...06d4e37e83
raiph lizmat: i confused myself (don't know how)
lizmat: also, to be clear, i view the "mess" as great in an important sense 11:27
lizmat the difference is a deprecation message for PERL6LIB
raiph lizmat: re "mess". my guess is it's related to trying extra hard to evaluate things at compile time, and catch signs of pairs, to err on the side of treating them as tags, and failing at comp time if things get too complicated 11:31
lizmat personally I still wonder whether using stashes as collections of things to export, was a wise choice 11:33
raiph lizmat: re "mess". and i could easily believe that's driven by thinking about P5 compatibility, and that's AOK. sometimes _works_ or bails is far more important than elegance.
lizmat agree
raiph lizmat: re stashes. interesting. why not? 11:34
lizmat: re stashes. and presumably you accept it's too late to revisit, right?
lizmat before 6.e most definitely 11:35
raiph lizmat: ah, wow. :)
lizmat: what's wrong with them? 11:36
lizmat: when u say "before 6.e" do you mean maybe change that aspect in 6.e.PREVIEW?
lizmat yes 11:38
raiph lizmat: 100% fearless, free thinking, committed, inspirational. thx. 11:44
lizmat: i'm going to go off and use what i learned from our exchange about `use` 11:47
lizmat safe travels! :-)
raiph lizmat: but i'm still curious to hear (another time/day) what's wrong with stashes for export!
lizmat: thx. <3 11:48
lizmat well, why not have $?EXPORT be a multi-level Map?
with tags at the first level
and things to export in there? 11:49
raiph lizmat: heh. i came back cuz i immediately realized i had more questions
lizmat possibly %?EXPORT
raiph lizmat: and then found u had more to teach me :) 11:50
lizmat: presumably ur last comments are about improvements over stashes 11:52
lizmat yes
raiph lizmat: so the issue is that returning a _single level_ map from `EXPORT` ( stash ) is inadequate
lizmat: yeah, that makes immediate sense to me 11:53
lizmat: but do you mean that the multi level map would then be flattened into stashes by the compiler? 11:54
lizmat well, no actually... I would like to see a more procedural interface actually, one that would also handle phasers and pragma
raiph lizmat: ahhh
lizmat I don't see why we need stashes to be able to import / export stuiff
*stuff
raiph lizmat: ok, that resonates something that came up for me from a different direction 11:55
in this SO stackoverflow.com/questions/785202...g-a-module
lizmat right, and that's how gfldex came up with their smuggling scheme 11:56
raiph lizmat: right. which is what i was working on reacting to. :) 11:57
in a footnote of my SO I wrote (long):
An EXPORT sub is the most powerful of the standard mechanisms for controlling "exporting and selective importing". It may be a surprise I'm guiding you to use an _export_ tool, especially a heavy weight one. What you want doesn't seem to be about exporting -- you've already got an is export. Shouldn't that be enough? Nor does what you want seem to 11:58
be about selective importing. You just want to import what the module had available for export, like normal, albeit declaring a parameter default for one of the exported subs. Can't be that difficult, right? Suffice to say, sub EXPORT is the mechanism via which one can do the fanciest things that can be done _during_ export/import, and, as I
currently understand things, what you want to do requires sufficiently fancy footwork that indeed a sub EXPORT is required.
lizmat yeah... :-) 11:59
tbrowder hi, any way to execute a prog without allowing access to existing .precomp
lizmat raiph: it just feels to me that Raku has taken too much inspiration from its predecessor in that respect
tbrowder i guess use a bash script to delete it first would work ok 12:00
lizmat tbrowder: no precompilation ?
tbrowder no, for some special introspection
still fooling with DISTRIBUTION... 12:01
existing .precomp is used and has old data
lizmat ah, yes, nuke .precomp :-)
tbrowder bash it tis 12:02
raiph tbrowder: couldn't u use `raku -!Mprecomp` or whatever the right incantation is?
tbrowder hm, i'll try that, tanks!
lizmat raiph: not sure what you're getting at? 12:03
raiph lizmat: i was thinking there's a `no precomp;` pragma 12:04
lizmat no precompilation: docs.raku.org/syntax/precompilation
but that forces source to always be compiled 12:05
what tbrowder wanted was a way to have a module ignore what's currently in .precomp, but precomp again
no precompilation won't precomp at all 12:06
raiph lizmat: ahh, ok 12:08
lizmat: also i've not figured out how one does a `no` use of a pragma using `-M`
lizmat one cannot at the moment, afaik
raiph tbrowder: ^^^ 12:09
lizmat: +1 free thinking re modules/pragmas/phasers/export/import/use 12:18
lizmat: and not leaning too heavily on perl for inspiration 12:20
lizmat: instead leaning into ergonomics of foreign module use 12:23
lizmat: hmm. i recall i returned here because I had questions...
tbrowder btw, @skaji just released new ver of mi6 to ease working with PRs of other repo owners 12:46
and nuking .precomp is easy with xt/ dir tests. that should solve my immediate problem and not affect installation 12:47
lizmat: see App::Mi6 new version 12:48
13:03 raiph left 13:14 Chanakan left 14:21 soverysour joined 14:24 Guest28 joined 14:30 Guest28 left
antononcube I mentioned yesterday that "Algorithm::KdTree" produces wrong (incomplete) results. It is based on a C implementation of the KD-Tree algorithm. I want to have a pure Raku (and correct) implementation. What is the best name that pure-Raku package/module? 14:35
I am using for now "Algorithm::KDTree". I was considering "ML::Nearest" and "ML::GeometricNearestNeighbors", but the spatial search of nearest points is not a Machine Learning (ML) use case (and related algorithms.) 14:37
Should I just submit "Algorithm::KDTree" with relevant confusion warnings in the README? 14:38
15:12 vrurg_ left 15:24 vrurg joined
tbrowder antononcube: how about plain "KD-Tree" 15:58
and rossetacode.org is a good place to search for algo prog names 16:01
antononcube 🤔 Sure. Although, I still think some parent namespace like "Math", "Geometry", or "Algorithm" is better. 16:02
Yeah, RosettaCode refers to it as "k-d tree" -- kind of misnamed. The Raku implementation is translation from Python's. (Works but awakward.) 16:03
tbrowder maybe, i floated that idea a long time ago but got shot down. he who picks name first wins! i used "AVL-Tree" for mine
it started that way in perl/CPAN but diverter rapidly. i do like Algo+ though 16:05
or Math
antononcube ok 16:12
I am considering using the full name of the algorithm: "Algorithm::KDimensionalTree" . 16:13
tbrowder sounds fine to me 16:14
lizmat +1 16:26
16:34 dakkar left
antononcube Thanks for your feedback! 17:06
17:23 soverysour left, soverysour joined 17:25 teatwo left 17:49 wayland joined 17:53 wayland76 left 17:55 Sgeo joined 18:13 soverysour left 18:34 jpn joined 18:38 jpn left 18:46 Maylay left 18:54 Maylay joined 19:06 tjr left, thatpicture joined
thatpicture hello 19:07
gfldex m: say „Hello thatpicture!“; 19:11
camelia Hello thatpicture!
19:13 soverysour joined 19:18 thatpicture left 19:26 raiph joined 19:27 swaggboi joined
[Coke] anyone know who thatpicture is? They pinged in privmsg but are gone. 19:34
jdv its always _that_ picture... 19:37
20:00 jpn joined 20:05 jpn left
antononcube @jdv 👍 20:15
20:16 swaggboi left 20:20 swaggboi joined 20:21 jpn joined 20:26 tjr joined 20:30 Manifest0 joined 20:39 wayland76 joined 20:40 wayland left 20:45 soverysour left 20:55 soverysour joined 21:02 soverysour left
Geth docker: m-dango++ created pull request #66:
Bump to 2024.05		 21:07
21:17 jpn left 22:02 Sgeo_ joined 22:06 Sgeo left 22:23 sena_kun left
[Coke] jdv: is there a template for the release announcement or do you copy the previous month's to star? 22:29
(I have a PR to sub mit if the former) 22:30
(if thge latter, can I setup a preview version for the next announcement? 22:34
jdv i don't do star 22:38
it might be anton oks but idk
the release announcement i handle is gen'd by github.com/rakudo/rakudo/blob/main...ement.raku 22:39
[Coke] jdv++ PR incoming, since I'm stuck in this airport for several more hours than planned. 22:44
22:44 wayland76 left
jdv sounds like a party 22:46
22:47 jpn joined
[Coke] it was delayed, *early*, back on time, delayed multiple times, over 3 gates (over the entire length of c terminal) 22:47
22:52 jpn left 23:43 jpn joined 23:48 jpn 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!