🦋 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:38 jpn joined 00:43 jpn left 01:17 Sgeo left 01:30 jpn joined 01:35 jpn left 01:54 kylese left, hulk joined 02:15 Sgeo joined, hulk left, kylese joined 02:45 xinming left 02:46 xinming joined 02:48 jpn joined 02:53 jpn left 03:49 jpn joined 03:54 jpn left 04:47 kjp left 04:48 kjp_ joined 04:50 jpn joined 04:55 jpn left 05:51 jpn joined 05:57 jpn left 05:58 Sgeo left 05:59 jpn joined 06:04 jpn left 06:31 jpn joined 06:36 jpn left 06:59 jpn joined 07:04 jpn left 07:34 __________ left, samebchase left, Maylay left, tobs left 07:35 jcallen left, jcallen joined, tobs joined, Maylay joined 07:36 _________ joined, samebchase joined 07:42 derpydoo joined 08:05 dakkar joined 08:18 lichtkind joined 08:28 sena_kun joined 09:17 xinming left 09:19 xinming joined, jpn joined
librasteve hmm maybe anton is trying to tell us something by starting module at <ver:0.0.7> 09:25
kudos on the new module - I hope to use it soon!
on the topic of flatmap, I would like to test initial response to a new possible method, namely hammermap and its relative hammer ... this one is intended to recursively hammer flat nested lists a(nd to forcably flatten any itemized lists) and is guaranteed to produce a flat list. does anyone thing this is a good idea? 09:29
(if so, I will start a discussion topic)
lizmat I'm not sure that should be conflated with .map 09:31
maybe .flattenize ?
09:47 wayland76 joined, jpn left 09:50 jpn joined
librasteve github.com/Raku/problem-solving/issues/431 09:51
lizmat: sorry to be a pest and make you re-state but I thought it would be best for you to add the "deconflation" point as a comment on the issue over your name to maintain clarity 09:52
09:55 jpn left
lizmat librasteve no worries 10:02
10:08 jpn joined 10:54 teatime joined 10:56 derpydoo left
lizmat clickbaits rakudoweekly.blog/2024/06/10/2024-...ys-sommer/ 10:59
11:12 jpn left 11:19 jpn joined 11:21 Altai-man joined 11:25 sena_kun left 11:38 jpn left
tbrowder anyone here use hashnode? 11:38
lizmat
.oO( only recreationally )
 11:39
tbrowder one cool thing about it is it uses Markdown. blog in rakudoc, convert to Markdown, and publish from Github 11:40
CLI all the way! 11:41
we’ll see how that works, but it needs GraphQL which is broken ☹️ 11:42
because of Text::Wrap 11:43
maybe candidates for community modules 11:44
[Coke] tbrowder: is the issue that GraphQL has a too-weak declaration of what Text::Wrap it needs? 11:56
and is getting the one from _ instead of the one from github:jkramer ? 11:57
I wonder if our best practice should be to always specify the auth of the module we're requiring.
lizmat [Coke]++ 11:59
[Coke] I also find it amusing that _ is supposed to be helping here and may accidentally be breaking some things. 12:02
wayland76 tbrowder: I recently threw together wayland.github.io/table-oriented-programming/ entirely in XML/XSL. Used XSL to convert my xml-with-html-embedded into just HTML. I also used XSLT to inline SVGs, generate tables of contents, and the like. I put the xml/xsl on GitHub pages and the xsl is rendered in the browser.
lizmat oohh.. wow. XSLT: it's been decades since I used that :-) 12:03
wayland76 For entertainment, compare the "inspect" view of a page on that site with the "view source" view -- they're significantly different, despite not using any javascript.
The way I see it, Raku Grammars are the best tool for easy conversion of streams to trees, but tree to tree, XSLT still has a lot going for it. 12:04
Yeah, it'd been a while since I touched it myself.
[Coke] added a comment to github.com/CurtTilmes/Perl6-GraphQL/issues/10 12:05
wayland76 I had a bit of a look around, and I think the resurrection of XSLT will be as follows: 1) someone will finish a Rust library that can replace libxml/libxslt 2) The browsers will adopt it 3) The Rust library will be changed to support version 3 or whatever of XSLT/XPath. 12:06
JRaspass: Also, when I was using your container, I had to delete /tmp/.zef to get zef install working for non-root users. You might want to add a rm -rf /tmp/.zef to your "zef install" command (I haven't looked at your source, but I assume that's what's going on). HTH, 12:08
Anyway, bedtime for this Australian :)
lizmat sleep well!
12:14 jpn joined 12:19 jpn left
[Coke] ugh. github.com/jkramer/p6-Text-Wrap/bl...META6.json doesn't provide an auth section 12:19
ah, that's fine, can use :auth<github:jkramer> 12:22
12:26 merp left 12:31 merp joined 12:45 raiph joined
antononcube @librasteve "hmm maybe anton is trying to tell us something by starting module at <ver:0.0.7>" -- My high confidence offical packages are with "ver<0.1.0+>" and "api<1>". Having the lesser versions and api numbers means that I want to proclaim the package but I have not used it enough to see it "finalized enough." 12:49
ugexe using api and version together have other benefits. see - gist.github.com/ugexe/e93a5d28815b...r-versions 12:50
12:52 jpn joined
lizmat librasteve github.com/rakudo/rakudo/pull/5594 12:54
13:03 jpn left
librasteve nice! 13:30
tbrowder [Coke]: Curt says Raku community can take over GraphQL. 13:47
antononcube @librasteve "kudos on the new module - I hope to use it soon!" -- Thanks! I plan to make an enticing video this week. 14:04
14:14 kjp_ left, kjp joined
[Coke] tbrowder: I hesitate to add another unsupported module to the community pile. Do we have a process for considering modules to add? 14:19
another approach would be for someone to fork it. 14:20
14:23 jpn joined
tbrowder i don’t know about a process, but i think lizmat gives perms to anybody who asks. 14:25
even if “unsupported” it’s a step up from “abandoned” modules with authors who have lost interest. 14:27
i don’t hesitate submitting a PR to community modules 14:28
i can merge it if absolutely necessary, or ping one of our more active folks who may have more free time and interest 14:29
14:38 Sgeo joined 14:45 librasteve_ joined 15:31 jpn_ joined 15:32 jpn left 15:35 jpn_ left 15:45 raiph left 16:25 abraxxa-home joined 16:27 abraxxa-home left 16:28 abraxxa-home joined 16:29 teatime left, teatime joined 16:46 dakkar left 17:36 wayland76 left, wayland joined 18:19 teatime left, teatime joined 19:31 librasteve_ left 20:13 abraxxa-home left 20:40 polettix_ left 20:50 jjido joined 20:51 Altai-man left, Altai-man joined 20:55 teatime left 21:03 jpn joined 21:18 wayland left 21:30 jpn left 21:32 jpn joined
_grenzo Quesstion: Given this: await do for $script-path.IO.lines -> $line { start { $lines-done++; my $dbh = DB::Pg.new(:$conninfo); my @res = $dbh.query($line).values; $dbh.finish; sleep 1; #say "Thread {$*THREAD.id}: " ~ dd @res; } } The file has about 380K update statements but after 1% I get this: Progress: 3380/338635 21:39
0.998125% Progress: 3380/338635 0.998125% Progress: 3380/338635 0.998125% Killed
raku -v Welcome to Rakudo™ v2024.04. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2024.04. 21:40
any ideas what might be killing the process? 21:41
Nevermind, I think I figured out the problem 22:00
ab5tract That snippet would (attempt to) start 380K threads 22:10
You might consider batching the lines via rotor and doing the await on a smaller number of promises. If DB::Pg is thread safe you could share the handle across them 22:13
22:14 jjido left, jpn left
ugexe if you're batching with rotor might as well use hyper or race I would think 22:18
_grenzo I changed max threads to 26 via the ENV Var
forgot to mention
ugexe does DB::Pg.new open handles? your code would potentially open that many if so 22:19
_grenzo Also, there was a bad id in the one of the sql statements
DB::Pg has connection pooling
so each thread always gets the same connection
I put a try around the sql execution...it seems to be good now 22:20
Thanks though...I'll look into the batching 22:21
ugexe "If multiple simultaneous queries occur, perhaps in different threads, each will get a new connection so they won't interfere with one another." 22:22
i guess that is a bit ambiguous 22:23
since the next line reads "You can even do arbitrary queries in multiple threads without worrying about connections:" :P
_grenzo I assume he's doing something like this: sub cache-connect(Int $thread-id, $conninfo) { state %cache; #say "Thread $thread-id"; if %cache{$thread-id}:exists { say "Thread $thread-id already has a connection"; } %cache{$thread-id} //= DB::Pg.new(:$conninfo); } 22:24
which I put in before I read those lines
ugexe thing is, i'd expect it to pool connections per instance 22:26
you are creating thousands of instances
_grenzo not actually. I limited the number of threads. 22:27
if by instance you mean thread
ugexe by instance i mean what is created by DBD::Pg.new 22:28
_grenzo handle then
ugexe i'm guessing each time you call DBD::Pg.new it creates a new cache for that specific instance
in that scenario no connections would. be reused
_grenzo I'd have to check the code, but I'd think that would be a bad way to do it. 22:29
ugexe yeah, the cache uses attributes on the instance 22:30
github.com/CurtTilmes/raku-dbpg/bl...od#L62-L75
seems reasonable to me
22:36 bdju left 22:42 lichtkind left 22:53 bdju joined 23:01 Altai-man left
_grenzo <Ugexe> batching is working much faster 23:17
23:25 jpn joined 23:30 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!