🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
tonyo that isn't what i'm referring to as hell. the hell bit is more in reference to how seemingly simple libraries give you a large number of associated dependencies 00:05
Nemokosch It's all about who manages the dependency. Having the same code as one monolith wouldn't get you further, would it 00:10
tonyo for instance, nodejs `curl` looks like it should have no depends but gives you more than 30 modules to install 00:12
there isn't a whole lot of code to wrapping libcurl
so, while you're right on with your point it's irrelevant
if you had to have _either_ a monolith _or_ a bunch of small libraries then that'd be true but there are other options 00:13
Nemokosch Actually, most of the dependencies of libcurl come from gyp 00:16
Nothing can be done about that
SmokeMachine .tell whatnext Red::Config was merged! 00:17
tellable6 SmokeMachine, I'll pass your message to whatnext
Nemokosch Besides that, npmlog has 4 dependencies but those seem meaningful to me, much better than come around them with an ad-hoc semi-implementation 00:19
I think if you actually want to cut these dependencies, the reasonable thing is to not add certain random shiny sparkles to the module 00:21
Like does libcurl need a cute ascii loadbar? Not sure. 00:22
tonyo i'm not attacking js. i'm saying that it's dependency hell because js modules make it difficult to see the expanse of what you just installed. `7 Dependencies` can mean seven or in the case of libcurl it really means 126 dependencies 00:23
gyp is responsible for 96 of those dependencies 00:25
Nemokosch I think that's a different point than whether it's justified to have those dependencies or have as many. Sure thing, it could be more transparent but at the end of the day, this is npm's fault that many including Ryan Dahl himself ended up disliking 00:26
tonyo how is it npm's fault? 00:27
Nemokosch It is what doesn't show you the actual cost and doesn't enforce you to even think about it 00:28
If we want to apply the term "module hell" to the language itself, the only meaningful way would be: it was hell to even create a module in JS for a long time :D 00:31
tonyo it wasn't that bad, even in the early stages 00:32
Nemokosch There were ad-hoc patterns thrown around
tonyo i'm saying dependency hell because of the transparency for consumer and for the complexity it adds to module building on the package management side 00:33
less to do about a consumer who couldn't care less and just wants to get data from there to here or whatever
Nemokosch But that's not actually bound to the language, much more so to the ecosystem and the community 00:35
tonyo agreed
Nemokosch And even then I would say it's rather a certain approach than an anomaly
At least for the micro-modules
tonyo if it weren't then js wouldn't have the bloated numbers in that paper
that doesn't make it not hell to determine scope of dependencies or build them in the right order 00:36
particularly in the case of something like raku where precompilation is a concern
Nemokosch I don't know what implications it would have for raku, I as a casual JS user don't see the problem and actually I don't see it presented in a negative way in that paper either 00:39
The problem was when someone deleted that string padding module and broke half of npm - now that was quite some scandal 00:41
tonyo i used to write modules for js, some were popular some weren't. i use go for work and have used perl for work. something that is of concern is associated dependencies. the more there are the more places you have to trace bugs and if you do anything with PII then the more surface area for vulnerabilities. that paper mentions the latter part. if you don't code for work or you don't have to deal with PII then 00:42
it's of no concern 00:43
Nemokosch The paper also mentions that JS modules have notoriously low bug density, let alone when it comes to exploitable bugs 00:44
It's almost on par with Java 00:45
This is also something to wonder about
And you know, regarding work, I could tell more about the big copypasted C monolith 😅 00:48
Anyways, good universal sleeping time
tonyo 00:52
TimToady Hi, I think I accidentally cloned rakudo into Raku. Anyone know how to undo that? (I realize "undo" is a strange concept in gitland...) 02:14
tellable6 2019-07-24T18:40:12Z #perl6-dev <vrurg> timtoady: could you come up with an idea for a Map operator like those we have for List,Array, and Hash?
moon-child TimToady: you mean this github.com/Raku/rakudo ? Settings -> scroll to the bottom -> 'delete this repository' 02:15
TimToady That sounds...dangerous...
And I wasn't sure if it was there before, and I just did something idemptotent... 02:16
vrurg TimToady: no, it wasn't there. It is safe to delete it.
TimToady Thanks! 02:17
vrurg I can do it, if you wish.
[Coke] waves. 02:24
japhb TimToady \o/ 02:45
tonyo 3 04:14
andinus MasterDuke: ah i see, is it github.com/rakudo/rakudo/pull/4634 ? 04:16
tellable6 andinus, I'll pass your message to MasterDuke
frost say DateTime.now 07:46
m: say DateTime.now
camelia 2021-11-10T08:46:18.092819+01:00
andinus m: run 'uname' 08:01
camelia Linux
whatnext Hello all :) Another question regarding Red: I am currently getting "remaining connection slots are reserved for non-replication superuser connections" after a series of find/inserts - which makes me wonder if a new db connection is getting created for each database request. Does anyone know (or know where to find) info about how database 10:52
connections are managed with Red? :)
tellable6 2021-11-10T00:17:11Z #raku <SmokeMachine> whatnext Red::Config was merged!
whatnext SmokeMachine: ah yes that reminds me - that fix did indeed work. I forgot to close the issue. Doing that now 10:53
SmokeMachine whatnext: it should not create new connections, would you mind to share your code? 10:55
whatnext: but that's something I've being not paying much attention on... so it's very likely to be a bug... 10:56
:( 10:57
whatnext SmokeMachine: hang on a sec - preparing a gist 10:59
whatnext SmokeMachine: gist is here: gist.github.com/whatnext/825e0cd9a...6c8b625d5e - i've tried to summarise because it's a fair bit more complicated in reality - so let me know if it doesn't make sense 11:16
SmokeMachine whatnext: how is your connection? where is it defined? 11:20
whatnext SmokeMachine: in the top level script I have `my $*RED-DB = initdb()` which calls `database ....` and returns the result 11:23
this is only called once
SmokeMachine whatnext: why don't you use a schema instead of your wrapper? you could just do: `my $schema = schema(<Table1 Table2 Table3>)` and then `$schema.Table1` or `$schema.model("Table1")` would be equivalent to your `$.redwrap.set('Table1')`
whatnext SmokeMachine: probably because I don't know what I am doing? '=D Well, ok I did experiment quite a bit to try and find the most convenient way to organise the schema code. I had some issues setting it up using other methods - but I confess I don't 100% remember the rationale 11:29
do you think it makes a difference re. database connections? 11:30
SmokeMachine whatnext: have you tried doing that using "multi level" .^create? something like this: `Table1.^create: :$sheet_id, :$name, :table2{ :num-comps(@comps.elems) }, :comps(@comp.map: -> $name { %(:$sheet_id, :$name, :param{ :$eqn_id }) })` (sorry, I don't know your relationships' names than I just invented some names) 11:37
whatnext: I think it probably does... that's the `database` command that creates the connection... 11:38
whatnext SmokeMachine: I'm only calling `database...` once though 11:39
SmokeMachine whatnext: here's an example of "multi level" .^create: github.com/FCO/Red#create
here another example: fco.github.io/Red/tutorials/cookbook.html 11:40
whatnext SmokeMachine: I haven't tried that - but I am wondering if I should have to do that? Shouldn't it work as separate inserts as well? 11:41
SmokeMachine whatnext: would you mind to create a small code that could reproduce that bug, please?
yes, separated inserts inside a transaction...
yes, separated inserts inside a single transaction... 11:42
whatnext SmokeMachine: to be honest I don't think I am going to have time to do that currently - I am pretty maxed out at the moment 11:48
SmokeMachine whatnext: so, can you share the code itself where the bug is happening? or is that something "unsharable"? 11:49
whatnext: anyway, after work I'll test writing some code doing many inserts in loop and I'll see if I can reproduce that bug 11:50
whatnext SmokeMachine: ok great - let me know if you figure it out :) right now I will look for a workaround 11:52
it is a proprietary project, so I think I can't really share large amounts of the codebase unfortunately 11:53
SmokeMachine whatnext: sure! and please, if you find some time to golf that to something you can share, please let me know 11:55
what driver are you using? Pg os SQLite? 11:56
*or
whatnext: ^^ 11:59
whatnext SmokeMachine: Pg 12:00
SmokeMachine ok, thanks
stanrifkin What is the exponentiation algorithm in raku? when I say 2 ** 1000000 it takes a long time. Does it not uses square-and-multiply? Other languages like racket gives a result instantly. 17:44
[Coke] m: say 2 ** 1000000.0 17:45
camelia Inf
[Coke] m: say 2.0 ** 1000000 17:46
I presume the slowness is related to going to bigrats.
camelia (timeout)
japhb [Coke]: But he specified Int ** Int, which shouldn't need that. 17:47
stanrifkin i didn't use decimals or rats...
japhb m: say 2 ** 1000000
camelia (timeout)
[Coke] er, bigint?
japhb stanrifkin is correct that that shouldn't be that slow.
[Coke] it's definitely Big. :) 17:48
running it with a --profile here..
japhb m: my $n = 2 ** 1000000; say now - INIT now
camelia 0.000362705
japhb Yeah, it's not the math that's the problem. It's the stringification. 17:49
We've spent some effort on having faster Num <-> Str conversion; I don't recall if anyone looked at our (big) Int <-> Str conversion 17:50
[Coke] using 2021.10, 99.94% of time spent in Int.Str, yup 17:52
[Coke] that method is just: nqp::p6box_s(nqp::tostr_I(self)); 17:53
and that appears to be mainly this moarvm func: github.com/MoarVM/MoarVM/blob/9bb1...ps.c#L1006 17:59
japhb: good thinking. got there faster than the --profile. :) 18:00
japhb [Coke]: I have experience suspecting strings of being slow. ;-) 18:04
[Coke] github.com/MoarVM/MoarVM/blob/d11b...ascii.c#L5 maybe 18:05
MasterDuke the gmp branch will help with both the exponentiation and the str conversion
tellable6 2021-11-10T04:16:25Z #raku <andinus> MasterDuke: ah i see, is it github.com/rakudo/rakudo/pull/4634 ?
[Coke] MasterDuke++
stanrifkin what someone would normally do in C to convert a byte array into a str? 18:06
is gmp also slow?
MasterDuke fwiw, i also have wip moarvm+rakudo branches that provide some minor speedup to integer exponentation github.com/rakudo/rakudo/pull/4320 and github.com/MoarVM/MoarVM/pull/1470 18:06
no, gmp is very fast\ 18:07
stanrifkin MasterDuke: i don't the code but mpz_get_str should help or? 18:08
MasterDuke exactly
github.com/MoarVM/MoarVM/pull/1402
[Coke] what was the blocker there, windows? 18:09
MasterDuke yeah, still haven't debugged the problem there 18:10
[Coke] ok. I have a working windows again, can give it a shot this weekend?
MasterDuke i kind of know where the problem is (uint handling where windows is 32bit for some types compared to everything else being 64bit), and i do have a windows vm, i just haven't had good success yet using the debugger and such 18:27
so if you're willing to play around i'd love the help
but i don't really have anything concrete nailed down as far as what to try for a fix 18:28
[Coke] ok 18:31
stanrifkin MasterDuke: there is an gmp branch on linux already? 18:42
MasterDuke well, sort of. that branch needs a little cleaning up, but it does already build and rakudo passes all spectests (except for one where where we expect something to fail because the current bigint library can't do it, but with gmp it succeeds) 18:44
on linux and macos. it's just windows where it doesn't work
if you build your own rakudo you could probably just tell it to use that moarvm branch (i'd have to rebase it up to HEAD of master, but that shouldn't be too difficult) 18:45
stanrifkin hm... no. i am just a beginner. good work though. I was just wondering why LibTomMath has not a string conversion function. 18:48
MasterDuke it does have one, it's just using a slow algorithm. i actually had a pr open with them to use a much faster one, but it needed a little work and then i realized gmp would be faster for lots of other things as well and switched to working on getting moarvm to use it instead 18:50
github.com/libtom/libtommath/pull/330 18:51
stanrifkin MasterDuke: i am sure perl5 uses gmp on windows. maybe you can copy something there.
MasterDuke yeah. we'll figure it out eventually, i just don't find working in windows all that enjoyable so i keep procrastinating 18:54
stanrifkin MasterDuke: do you use vcpkg? 19:01
MasterDuke don't think so 19:03
[Coke] I don't think we have anyone on the project who is windows-first, glad everything seems to stay functioning there so I can use it for work. 19:58
tonyo isn't ugexe a windows user? 20:14
[Coke] user vs. developer maybe? 20:52
I can run a build and not much else. :)
moritz_ isn't jnthn developing on Windows? 21:07
MasterDuke i don't think he has for quite a while now 21:11
tonyo well, nick does development on windows too [Coke] 21:14
lizmat moritz_: jnthn hasn't been on Windows much in years, afaik 21:15
jdv is there an issue or PR or something about that $/ + concurrency trap? 21:51
just seems like there could be a better way of handling that being that raku is a "higher level lang" and all. 21:52
if it remains as is then it'll be like the whole "is this random code thread safe or not" thing you see in things like c and whatnot, no? 21:53
Nemokosch well, yes 22:37