coleman quick question: whoever owns the rakubrew.org domain, have you renewed it? infra@raku.org got an email 10 days ago that says it needs to be renewed in 30 days 00:21
ugexe Windows on arm also has an x86 emulation layer 00:43
timo OK, in that case we would be building an x86_64 moar and everything would be as if we were targeting just 64bit windows? 00:51
ugexe: do you happen to have a hint for me where i should be looking to figure out the issue where one module causes precompilation for another module to be re-done? 00:53
Geth App-MoarVM-Debug/main: c1c50d57e0 | (Timo Paulssen)++ | lib/App/MoarVM/Debug.rakumod
add "step until" command

initial implementation, not stable yet		 01:12
App-MoarVM-Debug/main: f96b92e700 | (Timo Paulssen)++ | lib/App/MoarVM/Debug/Formatter.rakumod
don't explode with nested values in tables
ugexe the first thing i'd look at is if it goes away if you switch JSON::Class:ver<0.0.14+> to JSON::Class:ver<0.0.21> or whatever, which would suggest the precomp repositories have a problem with version ranges 01:29
timo with my local changes, you now get a handle to a dispatcher's current capture with the "bt" command, and you can get details about the callsite and also the values in the capture with the "positionals" command 01:46
ugexe github.com/rakudo/rakudo/blob/93ba...#L198-L204 like in this logic load-unit is only passed a dependency id which I'm not sure can represent a range 01:47
Geth App-MoarVM-Debug/main: 102616101c | (Timo Paulssen)++ | lib/App/MoarVM/Debug.rakumod
support "callsite" kind in positionals response

when it's not one kind for all slots like in VMArray, but each entry can have a different kind like in an MVMCapture. also: named entries		 01:52
App-MoarVM-Debug/main: cf1167d5c0 | (Timo Paulssen)++ | 2 files
bold line numbers in stack trace output
timo ah, that's very interesting 01:53
so there should perhaps be a fix for that in that code
the precompilation depends on the thing we choose from the range, rather than what range we pass, after all
does that also mean that if we compile something for .14+ and something else for 15+ those would conflict against each other, just in general? and if we have one program with both of these, they would keep re-writing one with the other, causing repeated precomp on every run? 01:58
ugexe we'd probably want to test that theory by changing the 14+ to 21 because it might not be the case. my mental model of the precomp code is not as strong as one might think :/ 02:03
timo TYVM for the suggestion in any case. have to go for now, but i'll try that soon 02:04
02:12 Voldenet left 02:15 Voldenet joined
timo i'm kind-of missing some sophisticated thing to let me define a command grammar and get tab completion and help and whatnot "for free" 09:15
i'm thinking about this in the context of the debugger CLI
ideally i'd at the same time have the ability to accept some keyboard combos as input, and also do TUI output 09:17
09:51 sena_kun joined 10:07 sena_kun left 10:19 finanalyst joined
patrickb Terminal-LineEditor / Terminal-Widgets is the best we currently have. 10:53
They are not yet in a good shape. But given I want to use them for the TUI debugger, they'll soon have to be. 10:54
11:45 andinus left
timo right 11:49
11:57 finanalyst left, finanalyst joined 12:04 finanalyst left, finanalyst joined
Geth rakudo/main: 55e40088af | (Elizabeth Mattijsen)++ | src/core.c/REPL.rakumod
Internally document the REPL.ctxsave method better

It is vital to a correct REPL functioning, I found out the hard way		 12:14
timo lizmat: you see the call to ctxsave in every --target=ast or --target=optimize 12:20
lizmat yeah, I think I'm finally starting to grok the interaction between $*CTXSAVE and $*MAIN_CTX 12:22
fwiw, I'm re-imagining the REPL as a module at the moment, with the intent of replacing the current REPL code in core 12:23
timo yeah i think MAIN_CTX is probably what makes every line appear to be nested inside the previous one, so that we can have variables
do you have an opinion on making the repl code more oriented around Supply to make it a bit pipeline-like in design, very vaguely inspired by how Cro works? i must admit i haven't thought that through very thoroughly 12:24
, though 12:25
lizmat no, not really
short-term goals: 1. better interface for prompt handling, so you can make your own easier
raku -MREPL::MyHandler 12:26
would start the REPL with the REPL::MyHandler role / class to do the handling 12:27
timo in any case, for the thing i did recently with the "semantic integration" i wanted to be able to override not just what to print for the prompt, but also how it reacts when the prompt is finished / inputting is done, and probably before and after the point where the repl checks if there has been any output on $*OUT or $*ERR, if it should print the result from the evaluated code, and also if there
lizmat 2. get grammar changes persistent as well
timo was an error on if it was successful
i imagine you planned for almost exactly that already
yes, grammar changes will be helpful
lizmat 2. handling of natives
timo i wonder if that's more than just stashing away the $?LANG or whatever it's called 12:28
maybe we'll end up with a LANGSAVE haha
lizmat well, perhaps...
but first to get some interface going :-) 12:29
timo right-o
if there's also a way to get a custom $*OUT and $*ERR that is used by the executed code, that'd be neat
lizmat fwiw, it would not be mixing in the handling: the REPL would have an $!editor attribute that "handles" all of the interface methods 12:30
at least, that's my current thinking 12:31
timo Did You Knowā„¢ that if every executed line gets its own $*OUT and $*ERR, then you can have code that keeps doing stuff in the background and the new output could be shown differently between old and new code outputting stuff, or you could have a section of output under each line entered that updates after the fact through moving the cursor there or something more complicated in terms of TUI
and if the $*OUT and $*ERR are "special" objects with some smarts, then code could output stuff without writing over the prompt and what the user has already entered
you can even be mean and make their .t return True >:) 12:32
lizmat hnmmm on that thought: has someone tried to do: raku -e 'repl' 12:33
on those gitBash shells on Windows ?
timo making $*ERR go to a separate UI pane on the side and be "mixed" and making $*OUT split by executed line ...
oh huh. i was looking if there's any hexdump module on raku.land and there wasn't but now i see HexDump::Tiny in the community modules, and there were definitely commits about zef releases there 12:36
lizmat yeah, I resurrected that last year if I remember correctly 12:37
one of perlpilot's modules :-( 12:38
timo rest in peace, buddy ... 12:39
lizmat timo: the "editor" is supposed to provide a "read" method 12:41
that could do checking and such
timo it would read input from the user, right? what kind of checking are you thinking of? 12:42
lizmat "how it reacts when the prompt is finished / inputting is done" was your suggestion?
timo right, as long as it's easy to just add to whatever line editor the repl would already have chosen 12:43
so that i can just say "before prompting, and after input is finished, do this. otherwise, do whatever you would normally do" with a callsame or so 12:44
lizmat well, while it's a module, it's going to be flexible enough
timo good 12:45
do you think changing the way output happens, like reacting differently to error or success, would go to some other place than $!editor?
lizmat the $!editor needs to provide an OUT and ERR method, which in the fallback case return $*OUT and $*ERR 12:47
that would give you all of the flexibility you need ?
timo this lets me give an OUT and ERR to the executed code, or is that only used by the repl code to do outputs and error printing? 12:48
lizmat before doing the EVAL, it does: my $*OUT := self.OUT; my $*ERR := self.ERR;
is that an answer ? 12:49
timo it'd be a little bit awkward to dance between prompt and outputting, especially if the repl code is silly like `Promise.in(2).then({ say "haha!" })`
i'd prefer (or like having additionally) making the code hookable that takes the result from evaluating and printing it 12:50
i hope i'm not asking too much, i'll stop before it comes to the kitchen sink, i promise 13:01
lizmat no, by all means, let those suggestions flow in! 13:02
just introduced a "silent" method to $!editor, that should return True if there was no output
so that's abstracted away now as well 13:03
13:48 finanalyst left 13:57 finanalyst joined 14:25 finanalyst left
timo m: say 5.rotor 14:28
camelia Cannot resolve caller infix:Ā«<Ā»(); none of these signatures matches:
( --> Bool::True)
($ --> Bool::True)
(\a, \b)
(Real $a, Real $b)
(Int:D $a, Int:D $b --> Bool)
(int $a, int $b --> Bool)
(uint $a, uint $bā€¦
timo m: say "buf:"; for Buf.new(1,2,3)[^5] { .raku.say }; say "blob:"; for Blob.new(1,2,3)[^5] { .raku.say } 14:44
camelia buf:
1
2
3
0
0
blob:
1
2
3
Failure.new(exception => X::OutOfRange.new(what => "Index", got => 3, range => "0..2", comment => Any), backtrace => Backtrace.new)
Failure.new(exception => X::OutOfRange.new(what => "Index", got => 4, ā€¦
timo this difference is because one is mutable, the other is fixed-size and immutable? 14:45
i wanted a fixed-length list with items from the input array/buf/blob/whatever but some sentinel when there was no item there (because the input is not long enough); using .list[^16] gave me Nil for those cases, which works nicely 14:48
15:07 [Coke] joined
ab5tract m: say ā€˜5ā€™.rotor 15:27
camelia Cannot resolve caller infix:Ā«<Ā»(); none of these signatures matches:
( --> Bool::True)
($ --> Bool::True)
(\a, \b)
(Real $a, Real $b)
(Int:D $a, Int:D $b --> Bool)
(int $a, int $b --> Bool)
(uint $a, uint $bā€¦
ab5tract At least itā€™s consistent there
timo hm. no way to mix a role into a Buf or Blob? 15:40
m: role Marker {}; (Buf but Marker).new(1,2,3).say 15:41
camelia No such method 'mixin' for invocant of type
'Perl6::Metamodel::ParametricRoleGroupHOW'
in block <unit> at <tmp> line 1
timo m: role Marker {}; (Buf.new(1,2,3) but Marker).say
camelia This REPR cannot change type
in block <unit> at <tmp> line 1
timo m: role Marker {}; (Buf[int8] but Marker).new(1,2,3).say
camelia No such method 'mixin' for invocant of type
'Perl6::Metamodel::CurriedRoleHOW'
in block <unit> at <tmp> line 1
timo m: role Marker {}; (buf8 but Marker).new(1,2,3).say
camelia No such method 'mixin' for invocant of type
'Perl6::Metamodel::CurriedRoleHOW'
in block <unit> at <tmp> line 1
timo m: role Marker {}; (class :: { } but buf8 but Marker).new(1,2,3).say
camelia ===SORRY!=== Error while compiling <tmp>
Operators 'but' and 'but' are non-associative and require parentheses
at <tmp>:1
------> role Marker {}; (class :: { } but buf8ā but Marker).new(1,2,3).say
expecting any of:
ā€¦
timo m: role Marker {}; ((class :: { } but buf8) but Marker).new(1,2,3).say 15:42
camelia P6opaque: missing attribute protocol in compose of <anon|1>+{Buf[uint8]}
in block <unit> at <tmp> line 1
[Coke] Buf is a role - can you mix a role into a role with no class?
m: role X {}; role Y {}; dd Y but X; 15:43
camelia No such method 'mixin' for invocant of type
'Perl6::Metamodel::ParametricRoleGroupHOW'
in block <unit> at <tmp> line 1
timo m: class MTE {}; (MTE but buf8).new(1,2,3).raku.say
camelia P6opaque: missing attribute protocol in compose of MTE+{Buf[uint8]}
in block <unit> at <tmp> line 1
timo m: class MTE is repr<VMArray> {}; (MTE but buf8).new(1,2,3).raku.say
camelia MTE+{Buf[uint8]}.new(1,2,3)
[Coke] rlwrap is messing with my repl .:| 15:44
timo export INSIDE_EMACS=1 15:49
if you mean the automatic self-re-execution of rakudo with rlwrap if it's not inside it already and doesn't have a line editor module installed
in that case, updating to latest will also disable that behaviour
[Coke] I killed a running REPL and the next repl in that shell was wonky 15:51
yah, am not at HEAD
timo oh, that's maybe just left-over stuff that rlwrap set up with some escape sequences? i'd probably just "reset" my terminal if i see something like that 16:12
[Coke] mmm 16:14
17:42 finanalyst joined 18:08 finanalyst left 19:03 finanalyst joined 19:34 finanalyst left 20:00 finanalyst joined
lizmat timo: re my REPL work: raku.land/zef:lizmat/REPL 20:22
still early days, but it works, so far :-)
timo cool 20:32
lizmat Readline Linenoise Terminal::LineEditor now supported 20:57
tomorrow I'll be documenting the API
afk& 21:01
21:04 sena_kun joined 23:07 sena_kun 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!