🦋 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:21 stanrifkin left 01:25 maylay left, kylese left, kylese joined 01:29 nine left 01:30 maylay joined, nine joined 01:46 maylay left 01:52 maylay joined 02:15 kylese left, kylese joined
antononcube weekly: youtu.be/6uCIoonlybk 02:44
notable6 antononcube, Noted! (weekly)
02:56 derpydoo joined 03:41 Aedil joined 03:48 derpydoo left 04:30 kylese left 04:34 kylese joined 05:02 lichtkind joined 05:30 kylese left 05:32 kylese joined 06:03 Aedil left 06:44 Aedil joined 07:06 tjr left 07:41 Sgeo left 07:59 lizmat left 08:04 dakkar joined 08:10 derpydoo joined 08:19 jpn joined 09:09 sena_kun joined 09:36 jpn left 09:41 jpn joined 09:45 jpn left 09:57 jpn joined 10:44 stanrifkin joined 11:01 derpydoo left
grondilu what can I do to avoid circular module loading? Seems to me that sometimes it's difficult to avoid. 11:07
Like I made a module Chess::Graphics, and I really would like to use symbols in Chess, but Chess already loads Chess::Graphics.
timo worst case, run-time loading. otherwise extract to a shared module if possible 11:09
grondilu yeah maybe create a third module indeed. 11:10
Voldenet alternative is putting everything in the same module 11:40
though logically Chess::Graphics is a module building on top of Chess 11:42
so maybe Chess should have scalar reference to rendering module and when Chess::Graphics loads, it'd register itself as provider when loading 11:44
and Chess would only have a role for rendering
11:46 sena_kun left 11:47 sena_kun joined
Voldenet last solution sounds too convoluted, shared module sounds best 11:47
11:52 sena_kun left 11:53 sena_kun joined 11:56 sena_kun left 11:57 sena_kun joined 12:07 JimmyZhuo joined
antononcube Using roles is what I do often in those cases. 12:12
grondilu turns out what I needed in Chess::Graphics was just board related symbols, like colors, squares, &rank and &file. So I made Chess::Board, which I should have made sooner anyway. 12:15
antononcube Right, that is the “normal” thing to do. 12:16
12:16 sena_kun left 12:17 sena_kun joined
tbrowder librasteve:ref my async prob: i think the solution is in brian’s book with his answer to exercise 18.5 12:38
Voldenet: ^^ 12:39
grondilu m: print <foo bar> Z=> (^1_000_000).pick(*) 12:43
camelia foo 967707 bar 8845
grondilu m: print <foo bar> Z=> (^1_000_000_000).pick(*)
camelia MoarVM panic: Memory allocation failed; could not allocate 71335936 bytes
grondilu that looks wrong to me
on second thought maybe not 12:44
on third thought I'm not sure 12:45
m: print <foo bar> Z=> (^1_000_000_000).pick(2) 12:46
camelia foo 295507191 bar 498295973
antononcube @grondilu For "Graph" it seems (seemed) that I had a lot of chicken-and-egg problems. For example, there is a class Graph that is generic and there are graph makers. Those makes could be just functions, but they benefited from knowing the Graph class. So, I used subclasses and roles. Also, there is big database of "well known" graphs (≈12K) which instead of being tucked-in into the "Graph::" namespace it would
be better placed in "Data::Graph" (or similar.)
grondilu well, for similar issues I could not put Chess::Position or Chess::Move in their own compunits 12:47
maybe it'll be possible after everything is cleaned up, though. 12:48
antononcube Thinking in terms of possible Web APIs for those might help. If you have a web service for these functionalities what would endpoints look like. 12:51
In my graph data use cases there are two established designs I can follow: House of Graphs (web service), and Wolfram Language / Mathematica corresponding functions. 12:53
13:15 tjr joined
tbrowder on seventeenth though, exercises 19.2 and 19.3 look “Promising” 😎 13:27
*thought
Voldenet Promises don't solve the problem at all, main problem is how readline receives input line by line and buffers the line 13:30
so you can't say "discard whatever user has typed until now and abort the read" anyhow 13:31
tho when user starts typing before the timeout it gets messy
13:32 atweedie_ joined, greenfork_ joined, oodani_ joined 13:33 dustinm`_ joined
tbrowder yes, seems to me i need the async, await, and a timer loop… 13:35
13:35 facetious joined, JimmyZhuo_ joined 13:36 andinus2 joined
tbrowder and i just take the first line and ignore all after, or abort if out of time 13:37
Voldenet I don't know the use case, but there's also an option to not use time-based logic, but option-based "enable interactive mode" 13:39
that's what I usually prefer
13:40 JimmyZhuo left, oodani left, greenfork left, atweedie left, dustinm` left, andinus left, acidsys left, tailgate left, greenfork_ is now known as greenfork, atweedie_ is now known as atweedie
tbrowder hm, “enable…” which thingy provides that? 13:41
Voldenet well, there's nothing like that in the language itself, but `sub MAIN(Bool :$interactive)` 13:42
or $*ENV<interactive>
13:43 JimmyZhuo_ left 13:44 synthmeat left
tbrowder thnx. my simple use case is: ask user yes or no, wait x seconds for answer, eval answer or abort if no answer 13:44
Voldenet I use the second form when I need debug shell using command pattern, I use the first when I want to handle prompt-based input instead of arg-based
13:44 synthmeat joined
tbrowder so it looks like first case then. 13:46
13:47 acidsys joined
tbrowder my sad lack of experience with sub MAIN may be my downfall here 13:47
Voldenet I used to stay away from it for some time, but MAIN turned out to be surprisingly straightforward 13:48
tbrowder i’ve been rolling my own mostly since i started.
Voldenet in all cases where args are complicated, i fall back to `Str :$thing = "sane default" #= some info about the format` 13:50
it's kinda manual still, but Bool and Int arguments are handled nicely 13:51
tbrowder i’ll check out the docs again. thank you for good advice.
p. 18 in brian’s book! 13:53
Voldenet it doesn't mention `multi sub MAIN`, but it's handled nicely too 13:54
e.g. 13:55
m: multi sub MAIN("foo") { }; multi sub MAIN("bar") {}
camelia Usage:
<tmp> foo
<tmp> bar
Voldenet it's really nice when the app needs subcommands or multiple variations of arguments 13:56
now I thought about the very simple solution for timeouting prompt 13:59
read input in `start { loop { … }}` all the time, emit things to the channel 14:00
if something's attached to the channel, it gets the input
though it doesn't solve the "buffered things get into the next prompt" problem still 14:01
time-based input also doesn't consider things like heavy load preventing input from arriving in time 14:04
14:04 apac joined
tbrowder thnx, kinda what i’ve been seeing in chaps 18 and 19. hard for me to wrap my head around it…my use does not involve heavy loads…bye for now 14:05
nahita3882 i did this with Python for Windows years ago using its msvcrt library. Raku has nativecall so i transported it, maybe it's useful paste.debian.net/1368690/ 14:14
tested on 2021.07, Windows 10 14:16
14:17 apac left
Voldenet for linux Terminal::ReadKey would do similar thing 14:33
that _getch does
erm, _getche 14:34
15:31 sena_kun left 15:48 sena_kun joined 16:03 jpn left 16:05 sena_kun left
[Coke] folks, any pointers on why this change throws a 'connect refused' ? 16:13
github.com/Raku/roast/commit/fb6d3...9f60411689 16:14
er, *connection
(trying to clean up the test so it uses the dynamic port where it makes sense - but I think awaiting to get the port # back is causing an issue. 16:17
ugexe maybe you cant get the port if its closed already 16:19
[Coke] it is getting the port (I can diag it out) 16:22
the connection issue is on line 115 or so
await client('u'.encode('utf-8'), "\c[COMBINING DOT ABOVE]\n".encode('utf-8'));
[Coke] wonders how this worked, as it's closing the tap before getting to the next client call. hurm. 16:23
does each new .tap get a new port? (that doesn't seem right) 16:24
Ugh, the port is changing. 16:27
fixable, anyway. 16:28
16:31 dakkar left 16:52 Sgeo joined 17:30 jpn joined 17:35 jpn left 18:12 lizmat joined 18:29 lizmat left 20:15 lichtkind left 20:35 lichtkind joined 20:57 jpn joined 21:52 jpn left 21:58 maylay left 22:01 guifa joined 22:05 maylay joined 22:17 lizmat joined 22:29 stanrifkin left 22:49 Aedil left 22:53 lizmat_ joined 22:56 lizmat left 23:05 lichtkind left 23:36 lizmat_ left 23:43 MasterDuke joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!