🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:06 reportable6 left 00:08 reportable6 joined 01:08 benchable6 left, linkable6 left, notable6 left, sourceable6 left, squashable6 left, greppable6 left, reportable6 left, quotable6 left, nativecallable6 left, statisfiable6 left, unicodable6 left, committable6 left, coverable6 left, bloatable6 left, bisectable6 left, evalable6 left, tellable6 left, releasable6 left, shareable6 left, sourceable6 joined, quotable6 joined 01:09 tellable6 joined, squashable6 joined, greppable6 joined, unicodable6 joined 01:10 notable6 joined 01:11 statisfiable6 joined, reportable6 joined, bloatable6 joined, bisectable6 joined 01:45 frost joined 02:08 committable6 joined 02:10 nativecallable6 joined, coverable6 joined, releasable6 joined 02:36 frost left 02:49 frost joined 03:08 discord-raku-bot left, discord-raku-bot joined 03:10 benchable6 joined 03:41 frost left 04:09 frost joined 04:11 shareable6 joined 04:18 frost left 05:56 greppable6 left, coverable6 left, notable6 left, nativecallable6 left, statisfiable6 left, quotable6 left, sourceable6 left, bloatable6 left, squashable6 left, bisectable6 left, reportable6 left, tellable6 left, unicodable6 left, releasable6 left, committable6 left, benchable6 left, shareable6 left 05:57 shareable6 joined, reportable6 joined, bloatable6 joined, coverable6 joined 05:59 benchable6 joined, nativecallable6 joined, sourceable6 joined, quotable6 joined 06:07 reportable6 left 06:09 reportable6 joined 06:57 committable6 joined 06:58 squashable6 joined, releasable6 joined 06:59 greppable6 joined, tellable6 joined 07:09 linkable6 joined 07:58 statisfiable6 joined 08:11 evalable6 joined 08:14 frost joined 08:19 frost left, moon-child left, moon-child joined 08:25 frost joined 08:59 bisectable6 joined 09:56 notable6 joined
Geth rakudo: 768ebea783 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals.pm6
Make initialization of core dynamic variables threadsafe

This fixes #4714, from a suggestion by nine++ in ugexe++ PR github.com/rakudo/rakudo/pull/4715		 10:01
10:05 linkable6 left
patrickb Are there strong emotions wrt adding minimal analytics to raku.org and rakudo.org? Can I just go ahead and add goatcounter.com to them both? (I wouldn't set up my own instance, but just use the hosted one which is free for us.) 10:18
lizmat patrickb: what would be the purpose of those analytics 10:20
?
patrickb I'm mostly interested in getting some insight in the overall development of hitcount. Basically a metric for how popular Raku is. 10:21
lizmat this also in the light that the Dutch authorities have issued a warning that Google Analytics may become illegal in the near future
patrickb Also possibly to find out which ways of distribution are how popular.
lizmat wouldn't you be able to get that info from the logs ? 10:22
access logs particularly ?
patrickb Yes, more or less.
lizmat: Have you had a look at goatcounter?
It's very conservative wrt tracking. It basically does none and (disclamers apply) doesn't require any consent. 10:23
If super cautious it can even work without any custom client side code and only be fed with log files. 10:24
lizmat if we would go that way, I would be strongly in favour of running our own instance
when I read this, I see NedStat all over again :-) 10:30
nl.wikipedia.org/wiki/Nedstat 10:38
(they used to be in the same building as I was, down the corridor even :-) 10:39
MasterDuke i want to make more jokes about how we should count *all* the farm animals 10:58
10:58 linkable6 joined 10:59 unicodable6 joined
Geth rakudo: ed99df18e4 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make unsuccessful .first about 40% faster

By separating the :end logic from the normal logic in separate private methods. Sadly, still not enough to allow it to be inlined, but it does appear to be good for performance nonetheless.		 11:53
lizmat m: .42.base(16,*) 12:05
camelia (timeout)
lizmat interesting
# Convert to given base until no fraction left: **CAUTION** this will 12:06
# loop indefinitely for simple values such as 1/3
12:07 reportable6 left 12:10 reportable6 joined
lizmat m: dd .42.base(16).parse-base(16) # an exact precision Rat shouldn't lose accuracy like that? 12:11
camelia 0.420000016689300537109375
lizmat m: dd .4.base(2).parse-base(2)
camelia 0.40625
12:21 Altai-man joined
Geth rakudo: 7dc3add843 | (Elizabeth Mattijsen)++ | src/core.c/Rational.pm6
Extract failure creation into separate subs

In order to reduce bytecode size of the hot path: still not enough to inline. Basically a redo on Rat of 4d78bc6ace6ba0a1695177b		 12:38
rakudo/lizmat-NYI-as-sub: e4f23079f9 | (Elizabeth Mattijsen)++ | 10 files
Introduce NYI as a sub

Many places in the core setting use:
   Failure.new: X::NYI.new: feature => "unimplemented feature"
in relatively hot code. Another often occurring idiom is: ... (17 more lines)		 13:17
rakudo: lizmat++ created pull request #4716:
Introduce NYI as a sub
14:03 Altai-man left 14:08 Altai-man joined 14:52 frost left
patrickb lizmat: Can you phrase your concerns with not hosting ourself? 15:01
15:22 frost joined 16:01 Kaipi left, Kaipi joined
lizmat patrickb: because then you don't know what's going to happen with your data, more so then hosting yourself? 16:03
16:22 frost left
nine lizmat: now that I think of it github.com/rakudo/rakudo/commit/76...82172b3661 may actually fix the 15-gh_1202.t failures that are plaguing CI 16:30
lizmat well, that's a good bonus then :-)
nine I would have bet that I have come across this issue before though and that I've even fixed it. But maybe I never comitted or pushed the fix as I got side tracked by the still present expr-jit issue 16:32
(which is responsible for the remaining failures of that test)
lizmat well, maybe it's time to disable the expression JIT by default ?
Geth rakudo/lizmat-NYI-as-sub: 63d5ef1ba7 | (Elizabeth Mattijsen)++ | 21 files
Use the NYI shortcut in the core where possible
 16:46
nine Well, honestly, yes. Though it does cost ~ 10 % performance in settings compilation
japhb lizmat: Hmmm, that NYI-as-sub PR -- it feels like we're underutilizing ... and !!!, but I do understand that X::NYI is way more than either of those. Just feels odd somehow. 16:47
lizmat well, I see ... and !!! and ??? as quicky stopgaps, NYI as a longer term stopgap 16:48
japhb :-D
lizmat also, ... seems to confuse the hell out of a lot of newbies 16:49
e.g. Question: how do you stub a sub ?
A: sub foo { ... }
Q: but how do you stub it ?
patrickb lizmat: It's possible I'd not even uncomforable making generic usage data entirely public. I'm not sure what I'd should be afraid of. The worst I can imagine is a shitstorm because the numbers are so low...
japhb Oh yes, I've noted that. 16:50
patrickb lizmat: I'm ok with going for self-hosting (even though it's more work). But I'd like to understand your point of view. 16:52
lizmat I'm not too worried about low numbers... I'm more worried about people feeling tracked 16:56
japhb I'd prefer not to do client-side tracking at all. 16:58
patrickb OK. So just using goatcounter by only feeding it with access logs would be fine? 16:59
lizmat that seems legit to me
patrickb Even if not self-hosted?
(Not sure if that's technically possible, just asking) 17:00
lizmat I'm not sure that would make a lot of sense
japhb I'd prefer self-hosted -- logs should not leave our purview.
lizmat to not self-host parsing logs
patrickb Third alternative would be to add a hook in the server side code to call the API and feed them the data directly. But yes, I do understand that from an information security pov this isn't any different from just sending over the access logs. 17:03
lizmat: But then again, what does self / remote hosting change about people feeling tracked? 17:04
I think I still don't fully understand.
lizmat at least we can tell them that the access logs are not given to third parties ?
japhb At this point, whether through malice or incompetence, you have to assume third parties *will* mishandle private data. 17:05
(And I mean that both as a user and a server operator)
patrickb OK. So the point is distrust in the remote party. That I understand. 17:10
lizmat indeed.... 17:11
17:25 TempIRCLogger left, TempIRCLogger joined 17:26 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined
nine I wonder if numbers generated by something like goatcounter are actually useful for anything. The biggest problem with webstats is filtering out bot access. There are a _lot_ more bots out there than you'd imagine. Unless you are a busy website, bot access will drown real users. 17:28
lizmat yeah, I see that on the logs server as well 17:30
patrickb goatcounter at least claims to be good at filtering out bots. (At least when using client side code.)
Is that true for downloads as well? 17:31
lizmat yeah, that's pretty simple that way
bots generally don't run the JS
patrickb OK. So only looking at logfiles isn't worth much, and running client side code is also discouraged. What options do we have left? 17:33
lizmat 1 pixel image 17:34
patrickb Huh? But that's also client side tracking. 17:35
17:41 Altai-man left
Geth rakudo: codesections++ created pull request #4717:
Specify base of non base 10 invalid numbers		 17:42
lizmat well, that's as much client side tracking as doing image requests on a server is ?
17:43 discord-raku-bot left, discord-raku-bot joined
patrickb true 17:44
OK. So self-hosted + tracking pixels it is? 17:45
18:06 reportable6 left 19:09 reportable6 joined
nine At some point one has to decide how important getting those numbers is. Personally I don't see an issue with JS based user counting. Because that's what we want to do: count users. We don't "track" them, are not interested in their habits, don't store anything personal about them and don't want to do anything that could do them harm. 19:41
lizmat that's a really broad statement :-) 19:42
Goatcounter appears to basically only use User-Agent and IP: github.com/arp242/goatcounter/blob...s-solution 19:45
it's this I'm a bit worried about: "Keeps useful statistics such as browser information, location, and screen size. Keep track of referring sites and campaigns."
which would imply they link Referer: to the UA and IP hash 19:46
nine None of which is personal information
moon-child those can be enough to deanonymize
nine And then what? What's the threat to the user if someone can find out that they visited raku.org? 19:47
Also deanonymization can only happen if we e.g. notice that a user with browser X, location Y, screen size Z, etc. was also active on $other-site where we do have their name or something. But such correlation just would not happen as we don't even have another such site. 19:55
That's why it's definitely a problem with Google Analytics (they are everywhere), but not when someone collects the same information in isolation. 19:56
lizmat well, that would *definitely* be a reason to be hosting this ourselves :-) 20:00
I guess I could live with having JS in that case, as long as the JS is **also** hosted by us
20:22 discord-raku-bot left, discord-raku-bot joined
Geth tap-harness6/cwd: 5d0e2206b0 | (Leon Timmermans)++ | lib/TAP.pm
WIP
 20:48
tap-harness6/cwd: 4007bfd428 | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.		 20:50
tap-harness6: Leont++ created pull request #49:
Add cwd attribute to TAP::Harness
leont ugexe ^
ugexe noice
leont Haven't tested it at all beyond "it compiles", not sure I'll have the time for that this weekend, would be convenient if you could look into that 20:51
ugexe sure
leont The relativization of the paths made sense to me, but I might be wrong on that 20:55
ugexe seems like it might be prefixing an extra ../ onto the paths i pass to run
[zef] Could not open ../t/00-load.t. Failed to stat file: no such file or directory
[zef] t/00-load.t ....................... Dubious, test returned 1
leont Are you passing IO::Path objects or Str?
ugexe IO::Path for cwd
zef test ./zef --debug 20:56
so im testing from 1 level above the root dist dir
leont I meant the file paths you pass to run, are they strings or IO::Path? 20:58
ugexe Str
my $parser = ::("TAP::Harness").new(:@handlers, :output($.stdout), :err($.stderr), :cwd($path)); 20:59
my $promise = $parser.run(@test-files.map(*.relative($path)));
so i pass $path as the cwd as well as use it to make the test file paths relative 21:00
leont Right, so then it's running .relative twice
I guess it will work if you leave out the map 21:01
ugexe it would seem to me you should check if the path is relative before calling .relative($cwd)
leont If everything is an IO::Path, it all doesn't matter 21:02
They tend to DWIM
(because they remember their own cwd)
ugexe yeah, most of this code is written this way to instead deal with spawning processes 21:03
i'll see if that works
ah yeah i was probably just calling .relative so TAP showed the shorter name anyway (which is what it is doing now) 21:04
Type check failed in binding to parameter '$name'; expected Str but got IO::Path (IO::Path.new("./zef/...) 21:08
leont Great, that is totally on me 21:09
Geth tap-harness6/cwd: 54025224fd | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.
leont How about now? 21:10
ugexe method make-source(IO::Path(Str):D 21:11
it doesnt like that
❯ raku -I. -e 'use TAP;'
===SORRY!=== Error while compiling -e
===SORRY!=== Error while compiling /Users/ugexe/repos/tap-harness6/lib/TAP.pm (TAP)
Invalid typename 'D' in parameter declaration.
at /Users/ugexe/repos/tap-harness6/lib/TAP.pm (TAP):902
------> method make-source(IO::Path(Str):D⏏ $prename, Any:D :$err, IO::Path:D :$cwd
Geth tap-harness6/cwd: 331955feeb | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.
ugexe :( [zef] Could not open ../t/00-load.t. Failed to stat file: no such file or directory 21:13
I think you want IO() $prename 21:15
although if i pass strings instead of IO it looks like it works 21:16
(Im just using `raku -e 'use TAP; my @handlers = TAP::Harness::SourceHandler::Raku.new(:incdirs(["$*CWD/lib"])); my $parser = TAP::Harness.new(:@handlers, :cwd("./zef".IO)); my $p = $parser.run("t/00-load.t".IO); say $p.result'`) 21:17
removing the .IO allows it to work
"t/00-load.t".IO -> "t/00-load.t" rather
although it does show './zef/t/00-load.t .. ok' 21:18
Geth tap-harness6/cwd: 55a5618d0d | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.		 21:19
leont No, that doesn't work either 21:23
Ok, I may need to think a little about the architecture of this all 21:24
ugexe method make-source(Str $prename, Any:D :$err, IO::Path:D :$cwd) { 21:27
my $name = $prename.IO.is-relative ?? $prename !! $prename.relative($cwd);
that seems to work if i pass strings
22:00 notna joined
leont I almost got it to work with both, but I'm getting a «This type cannot unbox to a native string: P6opaque, Failure» and --ll-exception doesn't seem to do anything here 22:30
Right, because that happens in the test it runs. 22:35
«raku -I./lib t/source-file.t» works but «(cd t; raku -I../lib source-file.t)» dpesm 22:36
doesn't
22:43 Xliff left 23:21 notna left
leont Ok, main bug is entirely my own fault, but the error message is quite LTA and I may have to take a look at that later. 23:25
Geth tap-harness6/cwd: 2acaf1dc76 | (Leon Timmermans)++ | 2 files
Make t/source-file.t cwd-independent
 23:44
tap-harness6/cwd: d785a5981d | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.
leont Now it should work for IO::Path regardless of it's cwd, and for Str with current cwd.
I don't have strong opinions on how it should interpret Str 23:45
ugexe my $parser = TAP::Harness.new(:@handlers, :cwd("./zef".IO)); my $p = $parser.run("t/00-load.t"); 23:46
my $parser = TAP::Harness.new(:@handlers, :cwd("./zef".IO)); my $p = $parser.run("./zef/t/00-load.t"); 23:47
the later works as expected
but i would expect the former to work, not the later
I can of course just pass in absolute paths in zef, but still
Geth tap-harness6/cwd: 99668d5a02 | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.		 23:48
leont I can make that workI think that should work
ugexe yeah that seems to work
$*PROGRAM.parent.child('source-file-test-data'); 23:52
thats a little nicer way of writing that
dirname wont include the volume on windows 23:53
i dont think anyway
leont Yeah that looks better 23:54
Geth tap-harness6/cwd: d7c03e2b4a | (Leon Timmermans)++ | 2 files
Make t/source-file.t cwd-independent
 23:56
tap-harness6/cwd: 9b63ace2a3 | (Leon Timmermans)++ | lib/TAP.pm
Add cwd attribute to TAP::Harness

This will run the tests in the right working directory without affecting the main program's working directory.

Powered by Cro and the Raku® Programming Language.

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

Thank you!