00:06 guifa2 joined 00:10 guifa2 left 00:13 guifa2 joined 00:21 guifa2 left 00:55 guifa2 joined 00:59 guifa2 left
Geth roast/rakudo_3713: eec472c1ee | (Vadim Belman)++ | S16-io/watch.t
One more try to make sure things are trully in sync

On an overloaded system it might be required to make sure the writer thread is started too.
Also increased the timeout up to 30sec.		 02:02
02:04 klapperl_ joined 02:05 klapperl left 03:21 guifa2 joined 03:25 guifa2 left
[Coke] nine++ # documenting nqp ops! :) 03:47
ShimmerFairy ooh, nqp op documentation? where? 04:20
Quick POD question, now that my mind's in that space: is =data necessary or useful? (Worth noting that, like with many P5 things, I have no clue what __DATA__ is used for there.) 05:41
nine ShimmerFairy: I wasn't aware of =data, but I've used =finish like this: github.com/niner/Inline-Perl5/blob....pm6#L1386 06:14
And github.com/niner/Inline-Perl5/blob...5.pm6#L920
ShimmerFairy Oh yeah, I don't have an issue with =finish, I just spotted =data in S26 and suddenly wondered why we bother. (It's not like =finish at all, it's just a block like any other that never gets rendered in docs and only exists to be put in $=data) 06:19
So it just strikes me that =for data :key<foo> is a needless extra way of doing %data<foo> = "..." 06:21
nine Especially considering our awesome indentable heredocs 06:24
06:25 klapperl_ left
ShimmerFairy Yeah, I feel like heredocs can cover every situation __DATA__ would be used for, just based on a quick glance of how that's used in P5. 06:29
06:52 JJMerelo joined 06:57 domidumont joined
tyil nqp's Configure.pl seems to do a number of `git` calls, which generates errors about it not being a git repo when used in rakudo-star 07:16
tellable6 2020-05-23T20:55:54Z #raku <melezhik> tyil[m] and for Log::Simple - pretty much the same. HTH - gist.github.com/melezhik/4e421cfed...45191137f9
tyil is there a flag for the Configure.pl to not do those git calls? 07:17
07:22 JJMerelo left 07:53 Kaiepi left 07:57 Kaiepi joined 08:13 JJMerelo joined
JJMerelo Hi 08:13
I'm trying to wrap my head around the concept of compile-time testing.
I just released Test::Script, for testing scripts 08:17
(obviously)
08:17 Altai-man_ joined
JJMerelo Besides output, I'd like to check if some variable has been set and its value. 08:18
On the script side, I guess I'll have to export variables and also declare them as our, which is why I wanted to do something like this stackoverflow.com/questions/619885...or-in-raku 08:20
But on the test side, I need to know the name of the variables I want exported in compile time, which means I can't give the name of the variables to a sub for testing. 08:21
I think that maybe this can be done using macros, or poor-person macros, that is, EVAL.
I don't like EVAL because you wouldn't be actually running the script (as you would with require). 08:22
And I don't know macros too well; they're still experimental, right?
08:27 sena_kun joined 08:29 Altai-man_ left
gfldex JJMerelo: they are experimantal and subject to change. That change might be imminent. 08:37
JJMerelo gfldex but could they be used for doing that kind of thing? compile-time tests?
gfldex you will get full access to the AST. If you change to AST you also change the script you are testing. You may suffer from heisenbugs that way. 08:39
But any testing helps I guess. 08:40
gfldex .oO( $imminent eqv $before-christmas ) 08:42
08:42 klapperl joined
JJMerelo But in the state it is now, I guess it can still be used somehow, right? 08:43
gfldex JJMerelo: I would need to see code to understand what you actually want to do. 08:48
nine JJMerelo: I haven't understood yet what you're trying to achieve. Why do you need to check variables in the first place? 08:49
JJMerelo gfldex This is what I want to do github.com/rakudo/rakudo/issues/3718
nine I'd like to do white box testing of scripts.
I've already released this github.com/JJ/raku-test-script but as a matter of fact the same could be achieved using any other number of things, like qx or EVAL 08:50
I'd have liked to create a test that checks if some variables have been set, or its value. 08:51
So I say something like variable-ok( "script.p6", ['$foo'], "Variable is OK") 08:52
script.p6 is "require"d, but we need to know the name of the variables in compile time, so that can't be actually done 08:54
nine how would you do that?
gfldex You could try to sneak in Proxies to catch values in containers. That wont work everywhere because you don't need a container to hold a value. 08:55
Even if you got access to the AST that could be tricky. You would have to change how my, our and friends work. 08:56
JJMerelo Well, variables can be declared using our and is export. That's not big deal. 08:57
gfldex still, we need to specifically import those variables into the testing script when we "require", and we need to know those names in compile time. 08:58
gfldex So you don't even have to import the names. You just need access to the name and the value of the exported symbol. That's what require is providing anyway. 09:01
`is export` is just stuffing names into a hash after all. 09:02
JJMerelo gfldex theoretically you don't, but in practice I couldn't find the FQN for exported symbols via require. It must somehow involve the file name or something, but as I said, no way... 09:09
Geth rakudo: 027935205b | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Revert "Add a IO::Path.child(List) candidate"

This reverts commit 800878a1b6adf4926e05a07dd03587a03ee16e51.		 09:13
09:13 JJMerelo left
Geth rakudo: 8b94d8d279 | (Elizabeth Mattijsen)++ | 3 files
Revert my work on IO::Path.child and revision control

By popular demand.		 09:15
¦ problem-solving: lizmat assigned to jnthn Issue The Problem Solving Process is not working github.com/Raku/problem-solving/issues/200 09:25
09:29 JJMerelo joined
[Tux] Rakudo version 2020.05.1-204-g8b94d8d27 - MoarVM version 2020.05-15-g644533ad1
csv-ip5xs0.831 - 0.835
csv-ip5xs-208.577 - 8.937
csv-parser27.200 - 28.028
csv-test-xs-200.393 - 0.396
test7.452 - 7.865
test-t2.017 - 2.182
test-t --race0.981 - 1.041
test-t-2032.218 - 35.280
test-t-20 --race9.446 - 10.185
 09:33
Hmm, will rerun later today
nine JJMerelo: if the variables are our scoped, you can just access them through the package 09:37
m: our $foo = 2; say GLOBAL::<$foo>
camelia 2
JJMerelo nine but what about an our variable declared in a "require"d file?
nine require TestScript:file<foo.raku>; say TestScript::<$foo> 09:39
You just need to give it a package to put the symbols into 09:40
09:40 [TuxCM] joined 09:41 [TuxCM] left
ShimmerFairy nqp-m: my $bitype := nqp::knowhow().new_type(:name<Big>, :repr<P6bigint>); say(nqp::base_I(nqp::box_i(117, $bitype),64)) 09:45
camelia 1r
ShimmerFairy Fun thing I noticed about base_I. Camelia's other backends aren't working right now, but IIUC nqp-jvm should return "117", and nqp-js should die because 64 > 36
(JVM would give back 117 because the conversion function used apparently defaults to base 10 if your radix is out of range) 09:47
nine lizmat: so....at the current rate we'll solve your problem-solving ticket about the problem-solving process in just a few years ;) 09:51
lizmat yes
and I'm not :-) about that
JJMerelo nine cool, thanks! 09:54
09:59 [Tux] left
lizmat bisectable6: old=2020.01 dd "2020-05-24T10:10:00.034Z".Str 09:59
bisectable6 lizmat, On both starting points (old=2020.01 new=8b94d8d) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «"2020-05-24T10:10:00.034Z"␤»
lizmat bisectable6: old=2019.07 dd "2020-05-24T10:10:00.034Z".Str
bisectable6 lizmat, On both starting points (old=2019.07 new=8b94d8d) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «"2020-05-24T10:10:00.034Z"␤»
lizmat bisectable6: old=2020.01 dd "2020-05-24T10:10:00.034Z".DateTime.Str 10:00
bisectable6 lizmat, Bisecting by exit code (old=2020.01 new=8b94d8d). Old exit code: 1
lizmat, bisect log: gist.github.com/64de6dd776f21b7d99...418dacb090
lizmat, (2020-02-29) github.com/rakudo/rakudo/commit/d9...d198747f09
lizmat bisectable6: old=2020.01 dd DateTime.new("2020-05-24T10:10:00.034Z").Str
bisectable6 lizmat, On both starting points (old=2020.01 new=8b94d8d) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «"2020-05-24T10:10:00.034000Z"␤»
lizmat bisectable6 old=2020.02 dd DateTime.new("2020-05-24T10:10:00.034Z").second 10:03
JJMerelo lizman I don't think the problem is the process. It's the lack of resources. 10:07
lizmat bisectable6 old=2020.02 dd DateTime.new("2020-05-24T10:10:00.034Z").second
JJMerelo Same reason why there are 1k tickets in Rakudo now.
Maybe a finer distribution in categories would help things move faster. 10:08
10:16 Kaeipi joined, Kaiepi left 10:20 [Tux] joined 10:23 [Tux] left 10:24 [Tux] joined 10:26 Altai-man_ joined 10:29 sena_kun left
JJMerelo niner could we try and generate random namespaces as another workaround for this? github.com/rakudo/rakudo/issues/3719 10:30
nine not too sure how could I do that, either... 10:38
nine JJMerelo: if you really need to load an arbitrary number of computation units at runtime and introspect them, just go to a lower level and use $*REPO.need to load and access the CompUnit you get. 10:41
JJMerelo nine let me check that 10:42
nine needs a bit of more scaffolding... The only thing I need is to require the same unit (a script) several times. As a workaround, I can do it giving it different names. 10:44
As in "foo.p6", "./foo.p6" and so on.
nine I can't imagine you really needing that
JJMerelo nine I'm trying to do white-box testing of scripts 10:45
so I want to launch a script with different values. 10:46
Since it's white box, I need to somehow load, not simply run it.
nine You don't need to load it multiple times but to run it
JJMerelo nine but if I run it it's black-box testing. 10:47
require runs it _and_ imports symbols that can be accessed 10:48
nine Once it's loaded, it's loaded. Why would you need to load it again?
JJMerelo nine OK, let's look at this in a different way
nine I want to run a script _and_ access its variables and things like that. The name of the script is known only at runtime. I might want to run it several times, and again access variable values after running it. 10:49
by using the mechanism you have mentioned of giving the required script a name, I can access the variables, that's no big deal. 10:50
However, for testing purposes I need to run it several times, thus require it several times, with different ENV and args combinations. 10:51
My workaround: simply access the file using different paths. There's a finite number of them, but no big deal.
nine So, you agree that you actually don't need to _load_ it multiple times, but _run_ the code multiple times. 10:52
JJMerelo correct
nine Great. Then we can go a step further and agree that a mechanism that inseparably combines loading and running may not be the right tool for the job. 10:53
JJMerelo nine well, there are always many ways to do it, but OK, agree. 10:54
nine so there's a mechanism that allows to run without re-loading? 10:57
nine So what you need is a tool that lets you have more control as the high level primitives are really designed and optimized for a different use case. You actually don't need and not even want all that machinery that's meant for finding modules, loading them and ensuring that we don't do the work multiple times.
All you need is something to load code from a file, run it and access the exported data. 10:58
JJMerelo nine right
nine CompUnit::Loader.load-source-file($path) will do just that. It gives you a CompUnit::Handle through which you can access the symbols 10:59
JJMerelo nine checking 11:01
nine Going that route will also keep your Test module from getting influenced by the tested code.
JJMerelo nine that's cool 11:04
However, I'm looking at this github.com/rakudo/rakudo/blob/mast...Handle.pm6 and can't really find a way to access symbols
nine maybe this? github.com/rakudo/rakudo/blob/mast...le.pm6#L68 11:05
nine Try it 11:06
don't even need an "is export" that way
JJMerelo Yep, I skipped them even when using a symbol. 11:08
right! 11:09
my $handle=CompUnit::Loader.load-source-file("foo.p6".IO);say $handle.globalish-package<$foo>;
love you, nine!
nine++
(Still need to see if it's taking the args and env, but still, great.
11:16 [Tux] left, [Tux] joined 11:52 Geth left, Geth joined
JJMerelo nine released new Test::Script, now with variable testing capabilities! 12:11
Thanks nine!
12:16 Xliff joined
Xliff \o 12:16
MasterDuke m: use nqp; my %h; %h{nqp::null} = 4 # don't know how likely this is to happen without trying, but the error is kind of LTA 12:20
camelia Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
12:27 sena_kun joined 12:29 Altai-man_ left
nine MasterDuke: I'd say very inlikely. Unless you tread in those lower levels of the dungeon. In which case you must be aware that there are dangers hidden 12:29
MasterDuke yeah, i wouldn't consider the highest priority of LTA errors 12:31
nine: while you're here. any idea why moving github.com/MoarVM/MoarVM/blob/mast...ers.c#L755 to right after the malloc of entry could cause a problem? spectests pass, but there's a consistent fail in t/02-rakudo/repl.t 12:32
nine not off-the-cuff 12:39
MasterDuke yeah, it's odd 12:44
12:49 JJMerelo left
lizmat PSA: There will not be a Rakudo Weekly News this week. Yours truly needs a break. Please check in again next week! 12:51
Xliff Thanks for all you do, lizmat. 12:54
[Tux] Thanks for all you do, lizmat. 12:55
sena_kun lizmat++ # incredible amounts of work done, relax at ease! 12:59
vrurg lizmat++ 13:18
tyil lizmat: too bad, thanks for all the posts you make :) 13:23
fwiw, me and hankache are working on getting the rakudo-star release out today 13:24
13:31 cognomin_ joined 13:34 cognominal left 13:43 Merfont joined 13:46 Kaeipi left
moritz tyil++ hankache++ 13:48
13:59 guifa2 joined 14:26 Altai-man_ joined 14:29 sena_kun left 14:48 guifa2 left 14:54 Merfont left 14:57 Kaiepi joined
Geth nqp/new-disp: 96504eba34 | (Jonathan Worthington)++ | t/moar/53-dispatch.t
Cover dispatcher-[track|insert]-arg
 15:10
nqp/new-disp: d39df6de9b | (Jonathan Worthington)++ | t/moar/53-dispatch.t
Tweak name of literal obj arg, test literal str
 15:19
15:36 domidumont left
nine So, it turns out that BEGIN time EVAL in precompilation still has severe problems, like adding the wrong bytecode to callables, trivially reproducible with a module like: unit module A; our constant Foo = EVAL 'class Foo { has $.name }'; 15:38
raku -I. -e 'use A; A::Foo.new(:name<foo>)' will give you "Too many positionals passed; expected 0 arguments but got 3" for the call to new, because the bytecode is that of <unit> instead 15:39
Luckily I feel this odd familiarity with the MAST compiler :) 15:41
Waaay back, when I made BEGIN time EVAL possible at all, I added the possibility to collecte mast frames during a compilation and add them to the outer compiler's. But mast_frames is only a lookup hash to get references right. The actual list of frames that get written to the byte code is in the MAST::CompUnit's @!frames array 15:43
Now I wonder what else is missing and if it may be necessary to share the whole MAST::CompUnit between compilers. Or at least add the nested one's data to the outer's (like the intention behind mast_frames was). 15:47
Yes, that's absolutely necessary. We need to pre-seed at least @!frames, @!sc_handles, %!sc_lookup, $!serialized and $!string_heap 15:53
Of course, rathern than pass these implementation details around, 15:56
we ought to collect the MAST::CompUnit objects and give them to the outer CompUnit for initialization 15:57
15:57 domidumont joined 16:19 domidumont left 16:27 sena_kun joined
nine Though if we want multiple BEGIN time EVALs to cooperate, this can't even be a list. 16:28
Maybe it's better to give the backend a chance to initialize some common data structure at the start of a precompilation and store that in %*COMPILING 16:29
16:29 Altai-man_ left
nine %*COMPILING is an odd hash. The only key ever accessed is '%?OPTIONS' 17:30
18:08 Xliff left 18:27 Altai-man_ joined 18:29 sena_kun left
nine Ah, lucky me. We don't have to share $!serialized as we already share the serialization context on the higher level. That would have been a major headache 19:18
19:22 lucs left 19:38 lucs joined
dogbert17 m: my $a = round(3.14159) for ^5000000; say now - INIT now 20:18
camelia 0.1088431
dogbert17 m: my $a = (3.14159).round for ^5000000; say now - INIT now
camelia 1.407243
MasterDuke heh. didn't you have some example recently where it was the other way around? 20:24
20:28 sena_kun joined 20:29 Altai-man_ left
MasterDuke it's the optimizer. the sub case is being completely optimized away. if you run with --optimize=off then the method is about twice as fast (on my machine) 20:31
Geth nqp: c82c9fd2a0 | (David Warring)++ | 2 files
[rubyish] Perl -> Raku + spelling
 21:04
nqp-configure: 7c343d4917 | (Patrick Böker)++ | lib/NQP/Config.pm
Workaround for nmake detection failure

The nmake detection fails randomly on Windows. It does so much more often on CI systems. The detection fails, because the STDOUT of the make call is partly or completely lost. This points to a bug in IPC::Cmd, IPC::Open3 or the Perl core. Instead of trying to hunt down a tricky and long standing bug in Perl (bug reports of possibly related issues date back to 2014:
  rt.cpan.org/Public/Bug/Display.html?id=91784) we work around the
issue by trying the detection several times before giving up.
This fixes #19.		 21:56
rakudo: 8440e219f4 | (Patrick Böker)++ | 3rdparty/nqp-configure
Bump nqp-configure to fix nmake detection failures on Windows
 21:58
nqp: 1f308c7118 | (Patrick Böker)++ | 3rdparty/nqp-configure
Bump nqp-configure to fix nmake detection failures on Windows
 22:00
rakudo: 986f8ab6b9 | (Patrick Böker)++ | tools/templates/NQP_REVISION
Bump NQP

This pulls in the nmake detection change that should help stabilize CI builds on Windows.		 22:05
22:05 patrickb joined 22:27 Altai-man_ joined 22:29 sena_kun left 22:47 patrickb left 23:18 guifa2 joined 23:23 MasterDuke left 23:44 guifa2 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!