🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
01:24 dogbert11 joined 01:28 ilogger2_ joined 01:29 jdv_ joined 01:34 [Tux] left, dogbert17 left, rakkable left, jdv left, ilogger2 left
japhb timo: Cancelable in a way that leaves stdin still readable and possibly buffering, or which throws away any remaining input? 02:06
timo oh, huh.
well, the thing that we have that supports cancellation is tapping a supply, so the Tap can be closed 02:07
02:08 jdv_ is now known as jdv
japhb T::LE goes through a little dance when you hit ^Z (SIGTSTP), so I already know how to make that work in a *somewhat* reasonable fashion. But it feels like an interesting question about what happens if the last Tap is closed, and then at some later point when input has still been arriving opening a new Tap. 02:10
02:11 [Tux] joined, rakkable joined
timo right, this is all very "inter-process communication" territory with all the fun that entails 02:11
japhb I suppose there could be some way to tell the Supplier what you *want* to have happen.
timo: 100%
timo so, the issue why i'm asking in the first place is, I tried to put a "CATCH" on the method prompt in Terminal::LineEditor to make it exit raw mode before outputting the exception (it doesn't do it itself, it just passes the exception further up) and found out that the output only came after i pressed another key 02:13
the only real investigation i did for that state was that i attached gdb and looked what the other threads were doing, and of course one of them was inside the c stdlib reading a byte from stdin 02:14
the catch block could do set-done, but of course the loop that reads bytes doesn't notice until the read function returns 02:15
japhb timo: Yeah, I believe that's a limitation of libuv's API (or how MoarVM uses it, I'm not sure). 02:22
timo we're not using libuv for stdin/stdout/stderr, or i think file handles in general? 02:23
there's syncfile.c but no asyncfile.c
japhb IIRC there's no way to peek or do the equivalent of select with immediate timeout
timo we might at some point have had it but changed to sync? maybe for performance reasons?
japhb Hmmm, this may be true.
timo well, can always turn a file into a socket right? :D
| * f8e607934 - Eliminate last libuv usages from syncfile. (8 years ago) <Jonathan Worthington> 02:25
japhb What I'd really like is a Raku-level way to ask an open IO whether it has anything waiting. Has this already happened and I didn't notice?
timo not aware of anything 02:27
japhb (And I don't mean "use NativeCall to select() on the native-descriptor) 02:28
Bah.
timo agreed. 02:29
in theory, something that will ask libuv to do a callback when something becomes available could be A Thing, but that probably means the handle has to be switched to async io mode on the OS level? that's a thing, right? async or nowait or something i seem to recall 02:30
japhb BTW, it should be possible to make CATCH mess with the screen as desired, then possibly force an input redraw, and then rethrow the exception. 02:31
timo indeed, i have CATCH do set-done, clear-input-field, leave-raw-mode, flush-prompt
japhb There's a bunch of different variants (that vary between OS and kernel versions), but ISTR we're using libuv to paper over all that. 02:32
timo yeah
we don't really get to have the simpler syncfile code and the ability to just go async mode whenever we want
maybe, just maybe, there's a way to give libuv a file handle to watch for writable/readable/error just like select, and not have to give libuv full control over it 02:33
japhb 🤔 02:35
win 10 02:46
timo activate your free upgrade to win 11! 02:47
japhb :-1: 02:54
09:18 lizmat_ joined 09:21 lizmat left, lizmat_ left 09:22 lizmat joined 09:43 finanalyst joined 10:02 greenfork left, greenfork joined 10:16 donaldh left 12:26 rakkable left, rakkable joined
lizmat notable6: weekly 12:33
notable6 lizmat, 3 notes: gist.github.com/3e07b65abc80e5b469...5472c5c4c7
12:53 donaldh joined, donaldh left
lizmat hmmm... looks like fez doesn't install because of testing error: Could not find Fez::Util::AST 13:00
tonyo ugexe ^^
ugexe Is that something that exists? It sounds like something someone working on rakuast would cause 13:12
lizmat zef install fez
ugexe I installed fez fine two days ago
lizmat is what I did
ugexe I’m implying that it sounds like rakudo 13:13
lizmat in other news: my new MBP running Sequoia 15.4 has 2 spectest failures
ugexe I guess there is such a namespace so never mind me
lizmat raku t/spec/S32-io/out-buffering.t and t/spec/S16-io/eof.t 13:14
they both fail with: script: tcgetattr/ioctl: Operation not supported on socket on STDERR checking
heh, looks like the test is marked: 13:19
todo('Fails on Sonoma') if $*DISTRO.desc eq 'Sonoma';
Geth rakudo/main: f4b545bb1a | (Elizabeth Mattijsen)++ | src/core.c/Distro.rakumod
Add Sequoia as a known MacOS distribution
 13:25
roast: 7326335c2a | (Elizabeth Mattijsen)++ | 2 files
TODO failing tests also on MacOS Sequoia
 13:26
13:29 donaldh joined 13:31 donaldh left
[Coke] wonders why we don't report just 15.x instead of using the named versions. 13:37
(but I dislike those)
m: dd $*DISTRO 13:42
camelia Distro.new(release => "15.6", path-sep => ":", name => "opensuse-leap", auth => "www.opensuse.org/", version => v15.6, signature => Blob, desc => "openSUSE Leap 15.6")
13:42 donaldh joined
lizmat m: say $*DISTRO 13:48
camelia opensuse-leap (15.6)
timo it occurs to me that we can just ask the terminal to respond to some random request if we want to have the read on stdin be finished 14:02
ugexe why does that test only now need to be TODOd? 14:07
it feels like we already run the spec test on the latest macos in our CI 14:08
if its just failing for your personal laptop then we shouldnt TODO it
ah we only run the spectest on linux probably 14:10
lizmat FWIW if it wouldn't have had the "Sonoma" test already, I wouldn't have added "Sequoia" there 14:12
[Coke] if it were numeric, we would have changed it from ==14 to >= 14 14:15
lizmat not sure: would have probably changed it to 14 | 15 myself 14:18
who knows whether future versions *will* allow this ?
notable6: weekly reset 14:19
notable6 lizmat, Moved existing notes to “weekly_2025-04-15T14:19:27Z”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/04/15/2025-15-in-place/ 14:52
[Coke] lizmat: is the 156/166 a recent check? I have 163/166 from a run I did... late last week? 14:57
will update the changelog draft if your test is recent.
lizmat [Coke]: that's from a check I just did now 14:58
lemme double check
[Coke] I trust your numbers more than mine. :)
releasable6 Next release in ≈4 days and ≈3 hours. 2 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
lizmat ah.... I see the problem 15:03
"skipped: RakuAST" wasn't interpreted as "ok" 15:05
corrected 15:06
Geth rakudo/main: a3af5e3838 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: remove skip-all, as these files don't test macros
 15:08
rakudo/main: 4c0bbc428c | (Elizabeth Mattijsen)++ | 6 files
RakuAST: use correct spelling of supersede
 15:11
[Coke] lizmat: so with that, what's the new total? 15:31
lizmat I git 164 / 166, but am not 100% sure that's not because it already had precomped something 15:32
so I went with 163/166
aka your number
[Coke] Roger. 15:37
Any bumps left to do for moar/nqp? 15:38
if so, can we get those in now? will kick off another blin run tomorrow to get zef 1.0.0 in there.
Just one oddball failure on last Blin run 15:39
lizmat checks
looks there are some :-(
Geth nqp/main: dce74d2c9d | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for latest fixes
 15:42
tonyo wonder if i accidentally published the client updated for the new endpoints >.< 15:47
tellable6 2025-04-09T08:20:04Z #raku <melezhik.> tonyo - I’ve got email from fez - Error reading META from your last upload, though my distro meta is valid and local zef run said no complaints when I did fez upload 15:48
2025-04-09T08:46:37Z #raku <melezhik> tonyo: ok - now i have got the same email from fez with the same error ... looks my distro is not being handled at the moment
2025-04-14T12:36:28Z #raku <melezhik> tonyo: I've already figured this out, looks like ( like i said ) this is my working environment issue, no problem from home laptop, anyway, thanks
tonyo lizmat: can you try installing an older version, eg 54 or 53?
lizmat tonyo: I just installed it with --/test, and it worked well enough to make mi6 release work :-) 15:49
tonyo tak
lizmat so I think it's just a test issue, rather than an issue with the module itself 15:50
tonyo oder dank, es ist dank ja?
lizmat tak is danish / swedish afaik
tonyo yea
lizmat dank je would be Dutch
danke would be German
tonyo two words in dutch? or is more equivalent to 'thank you'?
lizmat dank -> thank, je -> you indeed 15:51
danke in German would be more equivalent to "thanks"
tonyo yea
dank je 15:52
then
lizmat I guess the closest thing in Dutch would be "bedankt", but that very easily is interpreted as cynical
as in "thanks, but no thanks"
graag gedaan :-) 15:53
(as in "you're welcome" )
[Coke] google translate gives "don't mention it"
lizmat I guess that comes closer to the French "de rien" or the Spanish? "de nada" 15:55
?
as in " it's nothing" ?
[Coke] aye
Geth rakudo/main: e494d4d80e | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for the latest NQP/MoarVM fixes
[Coke] Still seeing some roast issues also: github.com/rakudo/rakudo/issues/5841 - the changes to the errata branches will probably have to be manually reviewed (cherry pick has conflicts) 16:00
github.com/Raku/roast/pulls - also 3 PRs here for some cleanup 16:01
nine lizmat: completion of the RakuAST grant might have been worth a mention :) 16:17
17:43 finanalyst left 18:06 vrurg left 18:10 vrurg joined, finanalyst joined 18:23 finanalyst left
lizmat nine: would have been nice if there were a blog post about that :-) 18:38
and sorry that I missed it: I was less focused on Raku things the past week 18:41
[Coke] Gives us a big item to go along with the release in next week's! 18:43
20:06 notna joined 20:54 finanalyst joined 20:57 notna left 21:38 finanalyst left 23:09 japhb left 23:32 japhb 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!