🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
04:09 guifa left 05:23 sivoais left, sivoais joined 05:30 lizmat_ joined 05:33 lizmat left
ab5tract Maybe it would be worthwhile exploring an SQLite version of the above 07:46
Ah, not in the context of fatpacker necessarily, but just as a compunit repo 07:48
08:37 finanalyst joined 08:49 donaldh left 09:59 sjm_ left, sjm_ joined 10:03 sjm__ joined 10:04 sjm_ left 10:10 lizmat_ left, lizmat joined 10:54 donaldh joined 12:05 guifa joined
ugexe it would be a good learning experience for whoever as it is relatively trivial to model it after CUR::Tar and CUR::Github (just replace calls from `tar` to `sqlite3` or a sqlite library), but i'm not sure it would be particularly useful to anyone unless it was in the core and replaced the existing CURI (i.e. it is used to solve the file naming on any file system thing). 14:15
but even then these type of repos are probably only useful for pure-raku module sets 14:16
lizmat hmmmm are you implying adding sqlite support in MoarVM itself? 14:20
ugexe i think it would be smarter to figure out the use case first, particularly since i just pointed out a pretty glaring flaw 14:27
lizmat you mean distributions with resources ? 14:28
ugexe i mean anything that uses nativecall
or anything that interfaces with anything outside of raku and has no concept of whatever virtual file system the sqlite db would be acting as 14:29
similar to in perl how you can't fat pack XS stuff
it has to be pure perl
lizmat I thought the point of NativeCall would be that *if* the naive deps are installed, you wouldn't need a compiler, and thus it would still be pure raku ? 14:30
Geth rakudo/main: bb0857c8b5 | (Will Coleda)++ | docs/release_guide.pod
jdv taking 2025.05 release
ugexe yeah thats true, to be more precise i should have said anything providing non-raku code in the distribution 14:31
like how openssl provides the dlls in the distribution itself
lizmat right, understood
but that would be a very small subset of distributions
although openssl is really high up river indeed 14:32
ugexe in general it is probably safe to assume most things with a Build.rakumod would not work since that is typically used for compiling stuff 14:33
lizmat remind me what the a Build.rakumod has over a BEGIN block in a module ? 14:35
ugexe that being said, i'm not against sqlite being in core even if for other stuff
lizmat I guess it could be used to create the source...
ugexe Build.rakumod is often used to compile c code. for example: inline::perl5
lizmat yeah, sqlite is used by the profiler, afaik
and Red already supports it as well, afaik 14:36
ugexe if it compiles C code then the generated artifacts need to be referenced by the raku code, but those artifacts wouldn't be on the file system
lizmat and it could provide a way to create persistent data structures, backed by sqlite database
ugexe i guess but what advantage does a database have for that vs any other storage medium 14:38
lizmat only possible issue I can think of, is that sqlite still is single threaded?
standarization, I guess
and the ability to do a bit smarter querying I gess
ugexe i think using a file would be the most standardized way
lizmat *guess
SmokeMachine Red supports SQLite, but it uses DBIish for that... 14:39
lizmat re standarization: "The SQLite file format is stable, cross-platform, and backwards compatible and the developers pledge to keep it that way through the year 2050. SQLite database files are commonly used as containers to transfer rich content between systems [1] [2] [3] and as a long-term archival format for data [4]. There are over 1 trillion (1e12) SQLite databases in active use [5]." 14:40
from the sqlite home page
ugexe i dont see how the file format is relevant
a persistent data structure just needs some representation that raku understands and correctly recreates whatever object 14:41
lizmat "pledge to keep it that way through the year 2050"
ugexe but how is that relevant
lizmat actually, I'm not 100% sure, but it feels good :-) 14:42
15:38 finanalyst left
timo lizmat: sqlite has multi threaded modes that you can opt into if you promise to be good 19:01
i think if you just create multiple "handle" objects on the same database and only use one handle from one thread at the same time you get a performance increase by being able to utilise multiple cores 19:02
nine Just for correctness' sake: Inline::Perl5 does not have a Build.rakumod 19:13
timo nine: apart from "user is now responsible for nuking their ~/.raku/precomp at the right times", what issues can you foresee from using `install-dist.raku --/precomp` when building debian packages? to be clear, this is just a hotfix to get things working again before the deadline which is approaching verily 19:17
nine Not sure how well we cope when we can't find any writable precomp store. Other than that it should be just a collossal waste of resources 19:19
And I still wonder how we got into this situation when the way to package Raku modules has been pretty clear for some 8 years or so 19:20
Also wouldn't it be just easier to do this properly? It's not like you have do do much, is it? 19:22
timo i may not have to do much, but i also don't have time to make more than one attempt and get it right the first time 19:31
21:28 guifa left 22:02 guifa joined 22:03 guifa left
Geth rakudo: wayland++ created pull request #5876:
Test that a submethod can access an attribute		 22:24

Powered by Cro and the Raku® Programming Language.

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

Thank you!