🦋 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.
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 ?
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
lizmat librasteve no worries 10:02
lizmat clickbaits rakudoweekly.blog/2024/06/10/2024-...ys-sommer/ 10:59
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!
[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
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
lizmat librasteve github.com/rakudo/rakudo/pull/5594 12:54
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
[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
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
_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
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
_grenzo <Ugexe> batching is working much faster 23:17

Powered by Cro and the Raku® Programming Language.

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

Thank you!