🦋 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:56 Some-body_ joined, DarthGandalf left 00:58 Some-body_ is now known as DarthGandalf 01:06 hulk joined 01:08 kylese left 01:29 floyza left 01:33 Tirifto_ left 01:34 Tirifto joined 01:39 Tirifto_ joined 01:40 Tirifto left 01:50 tejr left 01:53 tejr joined 02:15 hulk left, kylese joined 02:35 Tirifto_ left 03:45 kylese left 03:49 kylese joined 03:58 stanrifkin_ joined, gabiruh_ joined 04:00 gabiruh left 04:01 stanrifkin left 04:04 gabiruh_ left 04:59 gabiruh joined 05:03 gabiruh left, stanrifkin_ left 05:23 gabiruh joined 06:09 gabiruh left 06:38 gabiruh joined 07:11 Aedil joined 07:30 gabiruh left 08:44 Aedil left 08:50 Sgeo left 08:53 lizmat joined 09:01 apac joined 09:03 gabiruh joined 09:04 razetime left 09:10 lizmat left 10:49 stanrifkin joined 12:06 wayland joined, wayland76 left 13:23 sftp joined
antononcube Both "Jupyter::Kernel" and "Jupyter::Chatbook" can be used to produce JavaScript plots with "JavaScripdt::D3" or "JavaScripdt::Google::Charts". 14:06
As @librasteve said above, "Jupyter::Chatbook" facilitates the use of LLMs in several ways: (i) having direct access to LLM-service providers via "magic" cells, (ii) having notebook-scope chats with several different LLM personas within a notebook, again, via magic cells, (iii) pre-loading of the "main" LLM Raku packages. 14:09
In addition, (iv) custom/user notebook initialization code, and (v) loading of custom/user specified LLM-personas. 14:12
I filed a GitHub issue about (iv) to be implemented also in "Jupyter::Kernel". 14:13
14:28 apac left 15:12 stanrifkin left, apac joined 15:28 Aedil joined 15:35 guifa left 15:39 guifa joined 16:13 apac left 16:35 apac joined
Are new uploaded CPAN Raku packages registered in the Zef ecosystem? Will they show up in raku.land ? 16:51
17:22 abraxxa-home joined 17:31 abraxxa-home left 17:50 abraxxa-home joined
[Coke] I believe raku.land is scanning cpan. 18:33
so the latter, yes. I don't think the former is happening or driving the latter. 18:34
18:47 Sgeo joined 18:54 abraxxa-home left
antononcube Ok, thanks! 19:19
19:48 MasterDuke joined 20:54 Aedil left 21:00 SrainUser__ joined
ugexe REA was supposed to stop scanning p6c and cpan long ago so i dont think they'd get picked up 21:04
21:11 SrainUser__ left
ab5tract I didn't know that CPAN was still accepting Raku uploads 21:12
It felt like we spent a fair amount of time integrating into CPAN only to then fairly rapidly get told to GTFO 21:13
Since we aren't welcome there, and we aren't scanning there, I think it would be a good idea to ensure that no one is mistakenly trying to release their Raku code there 21:14
ugexe what gives you the impression we aren't welcome there?
ab5tract There was a rush to get on and a rush to get off 21:15
If we self-enforced the rush to get off, then my memory is mistaken
ugexe github.com/Raku/problem-solving/issues/316
i never had the impression anything was rushed... that seems a bit hyperbolic given we waited years after that problem solving issue before we stopped scanning p6c and cpan 21:16
ab5tract Yeah, I guess I've got some wires crossed indeed. Those crossed wires remember a significantly earlier timeline for exiting CPAN, more along the lines of when we did the name change 21:18
21:21 MasterDuke left
antononcube FYI -- I could not convince fez to publish the tools-supporting (aka function calling) version 0.3.6 of "WWW::OpenAI". I uploaded it an hour ago with CPAN. See the corresponding Jupyter demo notebook: github.com/antononcube/Raku-WWW-Op...flow.ipynb 21:25
21:29 lizmat joined 21:59 SrainUser__ joined
Voldenet timo: I've done some rough criu testing to see if that would improve startup performance (I transported the code via named pipe using `EVAL "code".IO.slurp`) and the resulting execution time was cut by half: `0.21user 0.03system 0:00.19elapsed 131%CPU (0avgtext+0avgdata 132856maxresident)k` `0.02user 0.07system 0:00.11elapsed 91%CPU (0avgtext+0avgdata 106828maxresident)k` 22:12
But it doesn't handle stdin very well and requires CAP_CHECKPOINT_RESTORE or CAP_CHECKPOINT_RESTORE 22:13
the ugly part is that pages.img file takes 90MiB (which is twice more than raku), so I'm guessing this speedup will depend on the IO speed 22:26
still, I can imagine some "criu-snapshot /script/some-script" that would combine criu, criu dump and running rakudo script, so that the script state can be "saved in time", letting raku start from the exact point in file 22:31
possibly increasing startup time by the portion that also generates AST 22:32
23:05 wayland left 23:52 rir joined 23:55 rir 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!