🦋 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.
00:03 djerius left 00:04 reportable6 left
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
00:05 djerius joined 00:07 reportable6 joined
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
00:18 dogbert17 joined
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
00:31 hkdtam left
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
00:33 melezhik joined
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
00:55 melezhik left 01:35 frost joined 02:12 TimToady joined
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
03:12 linkable6 left, evalable6 left 03:13 linkable6 joined 03:14 evalable6 joined 03:39 TimToady left 03:46 MasterDuke left, Xliff joined
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
04:46 linkable6 left, evalable6 left 04:57 Xliff left 05:35 bdju_ is now known as bdju 06:02 reportable6 left 06:04 reportable6 joined 06:28 hkdtam joined 06:52 Sgeo_ left, Sgeo joined 07:17 seednode left 07:18 seednode joined
frost say DateTime.now 07:46
m: say DateTime.now
camelia 2021-11-10T08:46:18.092819+01:00
07:51 ufobat joined
andinus m: run 'uname' 08:01
camelia Linux
08:23 Oshawott left 08:25 Sgeo left 08:35 ufobat left, ufobat joined 08:49 evalable6 joined 08:58 abraxxa joined 09:02 abraxxa left 09:03 abraxxa joined 09:05 dakkar joined 09:47 linkable6 joined 10:04 Skarsnik joined 10:23 archenoth joined 10:37 frost left 10:39 frost joined 10:46 frost left 10:49 whatnext joined
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
10:59 frost joined
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
11:47 whatnext left, whatnext joined
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
11:50 Altai-man joined
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
12:03 reportable6 left 12:09 frost left 12:13 hkdtam left 12:17 Skarsnik left 12:23 sm1 joined 12:30 whatnext left 13:20 dakkar left 13:21 dakkar joined 15:00 linkable6 left, evalable6 left 15:01 linkable6 joined, evalable6 joined 15:06 vrurg left 15:07 vrurg joined 15:30 Sgeo joined 15:36 Sgeo_ joined 15:39 Sgeo left 16:15 thowe joined 16:28 cognominal left 16:34 patrickb joined 16:35 Kaipi left, Kaipi joined 17:01 dakkar left 17:05 reportable6 joined 17:15 TimToady joined 17:25 linkable6 left 17:42 stanrifkin joined
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
17:45 sm1 left
[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
17:53 MasterDuke joined
[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
18:02 reportable6 left
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?
18:06 Altai-man left
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
18:45 A26F64 joined
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.
18:54 casaca left
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
18:54 casaca joined
stanrifkin MasterDuke: do you use vcpkg? 19:01
MasterDuke don't think so 19:03
19:06 abraxxa left 19:16 abraxxa-home joined 19:17 casaca left 19:22 casaca joined 19:48 AntonOks joined 19:50 AntonOks left
[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
20:05 reportable6 joined
tonyo isn't ugexe a windows user? 20:14
20:19 whatnext joined 20:21 whatnext left 20:23 ufobat left 20:27 linkable6 joined 20:52 MasterDuke left
[Coke] user vs. developer maybe? 20:52
I can run a build and not much else. :)
20:58 MasterDuke joined
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
21:17 A26F64 left
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
22:12 whatnext joined 22:16 whatnext left 22:28 stanrifkin left 22:34 Sgeo joined, Sgeo_ left
Nemokosch well, yes 22:37
22:49 dogbert11 joined, dogbert17 left 23:19 patrickb left 23:47 abraxxa-home 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!