00:01 pmurias left 00:02 patrickb left 00:16 hungrydonkey joined 00:34 Kaiepi left, Kaiepi joined 00:35 Kaeipi joined 00:39 Kaiepi left 00:58 moritz_ joined 00:59 vrurg_ joined, discord6 left 01:00 Geth left, discord6 joined, Voldenet left, [Tux] left, vrurg left, moritz left, discord6 left, discord6 joined, [Tux] joined 01:02 Voldenet joined, Voldenet left, Voldenet joined 01:07 Kaeipi left 01:08 Kaeipi joined 01:33 sena_kun left 01:48 sena_kun joined 02:22 entonian left 03:06 Kaeipi left, Kaiepi joined 03:35 sena_kun left 03:49 sena_kun joined 04:15 vrurg_ is now known as vrurg
Kaiepi can someone review github.com/rakudo/rakudo/pull/3451 and friends? doesn't need to be right now, but hopefully before the next release 04:30
github.com/MoarVM/MoarVM/pull/1232 as well 04:31
05:10 Kaiepi left 05:11 Kaiepi joined 05:35 sena_kun left 05:49 sena_kun joined 07:34 sena_kun left 07:48 sena_kun joined 08:15 Kaiepi left
lizmat Files=1302, Tests=111140, 212 wallclock secs (28.57 usr 8.20 sys + 2957.69 cusr 277.30 csys = 3271.76 CPU) 08:16
08:19 Kaiepi joined 08:54 hungrydonkey left 09:09 TreyHarris left 09:11 TreyHarris joined 09:34 sena_kun left 09:50 sena_kun joined 10:11 hungrydonkey joined
nine Kaiepi: looks sensible 10:49
sena_kun likes this PR a lot as long as it doesn't break anything backward 11:01
11:34 sena_kun left 11:49 sena_kun joined 13:15 lucasb joined 13:33 sena_kun left 13:49 sena_kun joined 14:04 MasterDuke joined
Kaiepi the plan i have for solving the dns problem solving issue is *a lot* of work, but i have basic dns lookups and address-related stuff working now fpaste.scsys.co.uk/587830 15:30
15:32 sena_kun left 15:48 sena_kun joined 16:06 hungrydonkey left 16:11 hungrydonkey joined
lizmat hmmm... looks like we lost Geth again :-( 16:43
pinging tyil
nine I'm looking at untangling the source-name mess I created back then. It looks like there already was a bit of a mess to begin with: my $?FILES := join(' ', @files); So at least when the compiler is run with multiple input files and --combine, $?FILES already wasn't a path and impossible to take apart 17:04
lizmat aaah... I was wondering why it was internally called $?FILES <-- the S 17:08
nine OTOH in nqp $?FILES is used exclusively in a descriptive way. Mostly for annotations in bytecode, i.e. something where having the comp unit name in addition to the path is actually benefitial. 17:12
Using $?FILES as the basis of Raku's $?FILE may just never have been a good idea 17:13
17:16 Geth joined
tyil really should figure out why Geth dies so often 17:16
lizmat so, do we know the "current" file in another way ?
tyil: maybe I'm committing too much ? :-) 17:17
tyil heh
could be :p
I'm not sure what's causing the problems, the logs dont show anything wrong
lizmat was it still running? or did the process die ?
perhaps add additional logging?
tyil the process was still running 17:18
if the process just died kubernetes would spawn a new one, which would be the preferred behaviour 17:19
nine I've had the same issue when I was still running geth. I think it swallows network errors instead of reporting or handling them
tyil I need to take an afternoon to just dig into it I think
nine I'd probably start by ripping out all CATCHes and trys :)
tyil heh
been thinking of just ripping out the github related stuff and dump it into an IRC::Client::Plugin module 17:20
nine And adding `use v6.d` everywhere, since I'm not sure if we're reporting errors in threads in v6.c mode by default.
tyil but rn I'm already working on 3 modules or so ;~;
more if I spot a bug in one of the deps :p 17:21
nine What would $?FILE actually show when there are multiple source files? 17:24
lizmat that is a good question: I didn't even know that was possible ... 17:26
I mean, why are we doing the concatting of setting files then ?
couldn't we just list the files with --combine ?
also: is this feature actually being used? 17:27
nine I'm wondering the same thing :)
lizmat but to answer the question: I would think that $?FILE would represent the filename of the actual file (part) being processed 17:28
also: how does this:
wind up in a stacktrace for the setting ?
nine --combine was introduced in 2011 and seems to have come from Parrot's nqp 17:31
I couldn't find any use of it, ever.
lizmat and then there's github.com/Raku/problem-solving/issues/143 17:32
nine Oh, that's not true. It seems to have been used until 2013: github.com/rakudo/rakudo/commit/4d...248c475cb9 17:33
lizmat specifically wrt to a file living *inside* the directory that would indicate in which order files should be concatenated before being compiled
17:35 sena_kun left
MasterDuke lizmat: `#line 1 SETTING::src/core.c/DateTime.pm6`at line 49562 of my gen/moar/CORE.c.setting is how 17:42
lizmat aaaah... duh! 17:43
MasterDuke one of the first things i implemented for rakudo after i started contributing
lizmat remembers now
MasterDuke never got it working for the jmv backing though... 17:44
17:50 sena_kun joined 18:04 hungrydonkey left
Geth rakudo: a331ac4d1b | (Elizabeth Mattijsen)++ | src/core.c/DateTime.pm6
Make DateTime.Str about 90x as fast

  - same process as with making Date.Str faster
  - do not use sprintf, use nqp::ops
19:34 sena_kun left 19:50 sena_kun joined 19:53 Voldenet left 19:59 Voldenet joined, Voldenet left, Voldenet joined
Geth roast: 0818d5eb39 | (Elizabeth Mattijsen)++ | S32-exceptions/misc2.t
Add test for R#3466

Also fix references to old and new tickets to actual URLs
linkable6 R#3466 [open]: github.com/rakudo/rakudo/issues/3466 [tests needed] Inaccurate error when a positional param follows a named param in signature
Geth rakudo: 246f20db14 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Hopefully improve InvalidTypeSmiley message

In response to R#3426. $ raku -e 'False:so' will now say:
   Invalid type smiley ':so' used, only ':D', ':U' and ':_' are allowed
linkable6 R#3426 [open]: github.com/rakudo/rakudo/issues/3426 LTA error when adverbing Bool (or identifiers?)
21:33 sena_kun left 21:47 sena_kun joined 23:32 lucasb left 23:34 sena_kun left 23:49 sena_kun joined 23:56 hungrydonkey joined