Zoffix ZofBot: tell me things 00:00
ZofBot Zoffix, The Party did not permit divorce, but it rather encouraged separation in cases where there were no children
Geth nqp: e0bd0ec664 | (Zoffix Znet)++ (committed using GitHub Web editor) | docs/ops.markdown
Fix eqat description

It doesn't appear to default to zero and needs it explicitly specified.		 00:14
MasterDuke Zoffix: i read that to mean the return value. are you thinking of $pos? 00:32
Zoffix Oh, I didn't even read the start of that sentence 00:34
Geth nqp: 129d4b8aff | (Zoffix Znet)++ (committed using GitHub Web editor) | docs/ops.markdown
Fix eqat description; MasterDuke++
MasterDuke heh, Zoffix++, that is clearer 00:35
AlexDaniel` samcv++ 03:12
ok, OO::Actors is a really weird one, but the problem is in the module itself 03:59
so it does $*SCHEDULER.cue(stuff) hundreds of times, where each “stuff” has an infinite loop 04:00
and that infinite loop never ends, never sleeps, and never blocks on anything
so this is a non-issue and I hope nobody is using the module :) 04:02
greppable6: OO\:\:Actors 04:10
greppable6 AlexDaniel`, gist.github.com/5c11d5a188c5e6fc52...01fa5ffd0c
AlexDaniel` anyway, feel free to discuss: github.com/jnthn/oo-actors/issues/6 04:11
.oO( NEXT!! )
greppable6: ZOFFLOP 04:40
greppable6 AlexDaniel`, Found nothing!
AlexDaniel` ehh
ah
quotable6: ZOFFLOP
quotable6 AlexDaniel`, OK, working on it! This may take up to three minutes (4412528 messages to process)
AlexDaniel`, Found nothing!
AlexDaniel` ehh
[Tux] This is Rakudo version 2017.09-490-g3f595acfb built on MoarVM version 2017.09.1-614-g19523568 06:10
csv-ip5xs 1.183 - 1.184
test 11.914 - 12.020
test-t 3.122 - 3.173
csv-parser 11.921 - 12.367
AlexDaniel` hmmm maybe WebSocket has issues because it is using IO::Socket::INET instead of IO::Socket::Async 06:22
OK, I see some stability issue 07:41
found it when I was digging into RT #132287 07:42
synopsebot RT#132287 [open]: rt.perl.org/Ticket/Display.html?id=132287 [REGRESSION][CONC] stall/block in async heavy code
AlexDaniel` the ticket itself is a bit weird because it seems to be doing concurrent access to %c, maybe
but the problem is that it hangs on qqx{}
and I can hang it on qqx without any of that code
it'll take a little bit for me to bisect it, so more info later 07:43
*but* I don't see that issue on 2017.09
or at least right now I don't 07:44
lizmat Files=1229, Tests=75768, 315 wallclock secs (14.68 usr 5.25 sys + 2180.70 cusr 212.04 csys = 2412.67 CPU) 07:47
AlexDaniel` lizmat: do you know what files exactly were hanging during the spectest? 08:13
lizmat I'm afraid not :-( 08:36
AlexDaniel` well, yeah, it'll take some time to bisect 09:33
the problem that I'm seeing is that this stuff: 09:34
await (^5).map({start { say qqx{echo -n foo $_} } })
dies or hangs, sometimes
lizmat :-(
AlexDaniel` I thought that it is a golfed version of this: RT #132287
synopsebot RT#132287 [open]: rt.perl.org/Ticket/Display.html?id=132287 [REGRESSION][CONC] stall/block in async heavy code
AlexDaniel` but I can't really reproduce the issue right after the merge of better-sched 09:35
and IMO this is the kind of issue we don't want to have in a release
lizmat but, wasn't this issue already in previous release, and it is now *less* manifest ? 09:36
AlexDaniel` I couldn't reproduce it on 2017.09 09:37
but I need to double check it
stmuk Does this only affect v6.d.PREVIEW?
AlexDaniel` no, “use v6.d.PREVIEW” is not needed to reproduce it 09:39
AlexDaniel` is trying again on 2017.09
lizmat re using phasers in hypered/raced blocks: I would propose setting a $*BATCH dynamic variable if running inside a batch 09:41
possibly this could have the batch number and maybe some other information
that way we wouldn't need any new phasers 09:42
and could code inside a phaser decide to do something special if $*BATCH is set, or not 09:43
AlexDaniel` This representation (Uninstantiable) does not support elems (for type (null))
lizmat m: use nqp; nqp::null.elems
camelia Cannot call method 'elems' on a null object
in block <unit> at <tmp> line 1
AlexDaniel` OK! False alarm then
lizmat hmmm
AlexDaniel` SNAFU.
lizmat m: use nqp; nqp::elems(nqp::null)
camelia This representation (Null) does not support elems (for type VMNull)
in block <unit> at <tmp> line 1
 09:44
AlexDaniel` that's on 2017.09
lizmat m: use nqp; nqp::elems(Mu but Ininstantiable)
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared name:
Ininstantiable used at line 1
AlexDaniel` took a bit longer tho, or maybe it depends on system load or whatever
lizmat m: use nqp; nqp::elems(Mu but Uninstantiable)
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared name:
Uninstantiable used at line 1
lizmat hmmm
AlexDaniel` buggable: tags 09:45
buggable AlexDaniel`, Total: 1630; 6.D: 2; 9999: 9; @LARRY: 28; ANNOYING: 8; BOGUSTEST: 1; BOOTSTRAP: 4; BUG: 588; BUILD: 12; CONC: 39; DOCS: 1; EXOTICTEST: 4; FLAP: 1; GLR: 3; IO: 19; JVM: 48; LHF: 7; LTA: 178; MATH: 6; META: 2; MOAR: 2; MOLD: 233; NATIVECALL: 21; NYI: 58; OO: 13; OPTIMIZER: 8; OSX: 2; PARSER: 5; PERF: 27; PERFTEST: 1; POD: 19; PRECOMP:
AlexDaniel`, 15; REGEX: 46; REGRESSION: 38; REPL: 6; RFC: 61; RT: 2; SECURITY: 2; SEGV: 30; SINK: 1; SITE: 1; SPESH: 1; STAR: 7; TESTCOMMITTED: 12; TESTNEEDED: 38; TODO: 13; UNI: 27; UNTAGGED: 284; WEIRD: 2; WINDOWS: 4; See fail.rakudo.party/ for details
AlexDaniel` This type (Nil+{Mu::Suggestion[Str]}) does not support elems 09:47
really weird errors coming out of this :)
AlexDaniel` rakudobugs
m: say 42 09:52
camelia 42
AlexDaniel` alright, so there it goes for RT #132287: rt.perl.org/Ticket/Display.html?id...xn-1501863 10:05
synopsebot RT#132287 [open]: rt.perl.org/Ticket/Display.html?id=132287 [REGRESSION][CONC] stall/block in async heavy code
AlexDaniel` now, OO::Actors is not our problem, and Test::Scheduler creates its own scheduler so I guess it can be fixed in the module itself 10:07
the only question left is about WebSocket module 10:08
I tried running the example and it does not seem to work, so it's not just an issue with tests
or so it seems
samcv: are you online? :) 10:26
Zoffix oh ffs
You brought annoying label to github too?
AlexDaniel` Zoffix: as I already mentioned, you can rename it to something better 10:27
(or did I mention it? I guess I did)
Zoffix AlexDaniel`: I have no idea what the fuck "annoying" is meant to indicate, so I don't know what something better is 10:29
AlexDaniel` .hug Zoffix 10:30
huggable hugs Zoffix
pmurias m: use Test;my regex single { o | k | e }; ok("bookkeeper" ~~ m/<single> ($<single>)/, 'Named backref');
camelia not ok 1 - Named backref
# Failed test 'Named backref'
# at <tmp> line 1
pmurias ^^ that's marked as dubious test
AlexDaniel` Zoffix: I guess rt.perl.org/Ticket/Display.html?id...xn-1496218 is not good enough to explain the purpose? 10:31
samcv AlexDaniel`, i am for a second. was sleeping but woke up
yoleaux 05:09Z <brrt> samcv: where should i write it? in the repo?
AlexDaniel` samcv: oh ok, ping me later then 10:32
we'll get the release going I hope
samcv awesome. will ping you when i wake up for real
pmurias AlexDaniel`: to be fair I'm not sure what the label 'annoying' is meant to be?
AlexDaniel` pmurias: okay, what about the explanation linked above? Does not cut it? 10:33
it may be that we need more than one tag for things that have ｢annoying｣ tag right now 10:40
pmurias AlexDaniel`: so the label just means that the bug is super annoying to the person who tagged it? 10:41
AlexDaniel` pmurias: oh, that's almost the right definition I think. It means that the bug is super annoying to anyone who stumbles upon it. 10:43
like, I didn't experience GH #1202 issue myself, so it's not annoying to me personally (but I tagged it). But I can totally imagine someone pulling his hair out because of this 10:44
does it make sense?
let's rename it to [hair-pulling] ? :) 10:46
Geth nqp: 6824c6aa89 | pmurias++ | 2 files
[js] Implement regex node charrange with ignorecase
 10:50
nqp: d2959ad4a4 | pmurias++ | 3 files
[js] Matching literals with :m
nqp: 9be4f9ae84 | pmurias++ | src/vm/js/nqp-runtime/nfa.js
[js] NFA matching for more things
AlexDaniel` lizmat: any chance for a git bisect on macos for RT #132349 ? :) 10:52
synopsebot RT#132349 [open]: rt.perl.org/Ticket/Display.html?id=132349 $*IN.getc not blocking on macOS
AlexDaniel` with ssh access to something macos-ish I can do it myself 10:55
lizmat AlexDaniel`: I currently don't have a MacOS machine that's accessible from the outside :-( 10:59
timotimo .o( it's the inside that counts ) 11:00
AlexDaniel` m: say $*INITTIME 11:08
camelia Instant:1508756941.119038
AlexDaniel` c: HEAD say $*INITTIME
committable6 AlexDaniel`, gist.github.com/95c61343aa6e1c5f9f...f629f25b38
AlexDaniel` “Deprecated since v2017.09.84.gb.02.da.4.d.1.a, will be removed with release v2017.08!” 11:09
ilmari m: say $*INIT-INSTANT == INIT now
camelia False
ilmari m: say $*INIT-INSTANT; say INIT now
camelia Instant:1508757008.014608
Instant:1508757008.073634
timotimo m: say $*INIT-INSTANT - INIT now
camelia -0.058967
lizmat MoarVM panic: Heap corruption detected: pointer 0x10c02dde8 to past fromspace # whee, running code of github.com/rakudo/rakudo/issues/1202 11:10
AlexDaniel` why camelia prints no deprecation message?
ilmari I guess $*INIT-INSTANT gets initialised before any INIT phasers run 11:11
m: say INIT now - $*INIT-INSTANT
camelia 0.0590460
timotimo AlexDaniel`: because it has RAKUDO_NO_DEPRECATIONS set in its environment
lizmat m: %*ENV<RAKUDO_NO_DEPRECATIONS> = 0; say $*INITTIME
AlexDaniel` oh
camelia Instant:1508757135.540318
Saw 1 occurrence of deprecated code.
================================================================================
$*INITTIME seen at:
<tmp>, line 1
Deprecated since v2017.09.84.gb.02.da.4.d.1.a, will be remove…
AlexDaniel` so I am changing it to 2018.08, right? 11:12
timotimo among other things because the ================================================================================ doesn't mix well with irc line length limits
AlexDaniel` or, I guess 2018.07 was mant
meant*
timotimo how often do you have to run the qqx thing before it usually fails?
AlexDaniel` timotimo: it really depends. I don't know 11:13
but normally it fails within a minute
Geth rakudo/nom: 6af44f8d38 | (Elizabeth Mattijsen)++ | src/core/IO/Handle.pm
Use a lexical instead of a state var to prevent sinking

This was one of the places where the code of
   github.com/rakudo/rakudo/issues/1202
was failing. Since we know that state variables have some racing issues and a state var was not needed here, change it to a lexical to reduce the surface of potential issues.		 11:14
lizmat running it with --ll-exception gives more info 11:15
fwiw, most of the issues appear to originate in ThreadPoolScheduler
and looking at the code, I wouldn't be surprised if there are still some racing issues there 11:16
Geth rakudo/nom: bd6c6403e0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | src/core/Instant.pm
Fix deprecation date

Definitely we cannot remove things from past releases.		 11:18
lizmat ok, I get the most fails now with "This type (Mu) does not support elems" 11:23
and this goes back to List.reify-until-lazy, where we first test for $!future.DEFINITE 11:24
and only then do a nqp::elems($!future)
timotimo liz, do you know about the cross-thread-write log?
lizmat no 11:25
so $!future is being reset in some other thread (which happens if the list is exhausted)
timotimo it's got lots of false positives in it, but maybe it can figure out why between .DEFINITE and nqp::elems the value might change there
lizmat how do I activate that ?
timotimo set MVM_CROSS_THREAD_WRITE_LOG 11:27
in the env
lizmat I also wonder what jnthn's thinking was by making $!general-workers, $!timer-workers and $!affinity-workers HLL List objects
rather than low level nqp::lists 11:28
timotimo: activating that brings its own set of errors :-( 11:29
moar(81961,0x700003374000) malloc: *** error for object 0x7ffda0479340: pointer being freed was not allocated 11:30
or just segfault :-(
timotimo oh! 11:31
i suppose it just bitrotted :(
i shall investigate briefly
can't find that kind of error with valgrind 11:32
OK, it happens without valgrind though 11:33
so requires threading to "cooperate"
lizmat timotimo: do you know why jnthn used Lists for the worker arrays, rather than nqp::lists ?
timotimo no 11:34
probably because List is "good enough"?
lizmat hmmm.. well, in the comments he says that they're immutable 11:35
which makes me wonder how such a list can have a $!future
timotimo grmbl why is --asan broken on my system 11:37
a realclean helped 11:42
patrickz 'annoying' tag name bikeshedding: 'severe'. A bug with consequences you can't easily live with and without a simple workaround possible. NYIs are never severe. 11:52
AlexDaniel` patrickz: I'm totally OK with that. “severe” word does not sound that severe to me, but it works 11:55
if there are no better suggestions I'll rename it to “severe” in a few hours 11:56
timotimo lizmat: you can get it to not crash by setting MVM_SPESH_BLOCKING and getting the patch i'll push to moar momentarily 11:58
pmurias a few of the ones we have in RT don't seem that "severe"
lizmat timotimo++
timotimo: I think there's a basic flaw in using Lists for the $!xxx.workers attributes in ThreadPoolScheduler 11:59
timotimo there it is
lizmat the fails so far are all in .elems being called, and the $!future being obliterated 12:00
basically: Lists are not thread safe
hmmm... it seems to fail most often when $!general-workers is null 12:09
so could it be that the Scheduler object is being used before it has run its BUILDALL to completion ? 12:10
Geth rakudo/nom: 50be159f20 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/create-release-announcement.pl6
Tiny improvements to announcement generation

This gets the generation in line with my monkey patching for last announcements (no trailing whitespace, more unicode, and Perl 6 with nbsp).		 12:22
rakudo/nom: 76017036aa | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Reflect actual date, claim next release
 12:28
AlexDaniel` lizmat: hoping to release a bit later today, let me know when you're done :)
getc issue on MacOS is a little bit worrying but there's not much I can do 12:29
stmuk AlexDaniel`: If you need a remote macOS shell I can probably set one up via SSH tunnels 12:31
AlexDaniel` stmuk: that would be great
stmuk: the first one from here will do: github.com/AlexDaniel.keys 12:32
if your stuff does not support ed25519 then the other one is fine as well
stmuk OK probably take a few mins I'll msg you when done 12:34
AlexDaniel` stmuk: thank you very much!
stmuk AlexDaniel`: whats your usual UNIX username? 12:36
AlexDaniel` alex
[Coke] I'm in the middle of upgrading xcode but when that's done can test stuff out 12:41
AlexDaniel` [Coke]: on macos you mean? It's more about bisecting (not just testing). I want to know what caused RT #132349 12:46
synopsebot RT#132349 [open]: rt.perl.org/Ticket/Display.html?id=132349 $*IN.getc not blocking on macOS
[Coke] sure, I can kick off a slow bisect once xcode is done. 12:47
Geth nqp/master: 9 commits pushed by pmurias++
AlexDaniel` [Coke]: that would be great 12:48
stmuk: not sure if I need that anymore ↑
Geth rakudo/nom: 6f6e62ea02 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
Some ThreadPoolScheduler tweaks

  - make sure we can identify which .elems failed in stacktrace
  - use = instead of .= Lock like everywhere else
   - not sure about this one		 12:50
AlexDaniel` stmuk: but if you'd let me use it in the future then I do need it :) 12:51
[Coke]: you can probably use something like this to do it automatically: start { sleep 2; exit 1}; say $*IN.getc 12:55
stmuk AlexDaniel`: OK I'll pause that ... but give me a shout if you still need access 12:56
AlexDaniel` stmuk: thank you!
[Coke] (started bisect, one down..) 12:58
AlexDaniel` by the way, for anybody else reading: if you stumble across unbuildable stuff then use “git bisect skip”. If you're doing it automatically, then you have to “exit 125”. One way to test it is to check if perl6 executable exists after you run make, or you can use the exit code from make itself. 13:02
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Use a lexical instead of a state var to prevent sinking 13:10
travis-ci.org/rakudo/rakudo/builds/291486125 github.com/rakudo/rakudo/compare/3...f44f8d38a0
[Coke] 5 steps remaining... 13:20
lizmat AlexDaniel`: still tracing some stuff 13:41
AlexDaniel` cool
lizmat bisectable6: class A { has $.a = 42; submethod BUILD() {} }; use nqp; dd nqp::getattr(A.new,A,q/$!a/) 13:44
bisectable6 lizmat, On both starting points (old=2015.12 new=6f6e62e) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Int $!a = 42»
lizmat so why is it documented that BUILD should take care of the default values as well? 13:45
[Coke] last run... 13:47
(sorry, didn't automate, and am in meeting, so am hitting up arrow every few minutes.)
oh. duh: gist.github.com/coke/071fd4d43ec79...1809e64a2c 13:50
it's the commit with "getc" in the subject. :)
AlexDaniel` yeah but Jul 14 :) 13:54
[Coke]: thanks
Zoffix [Coke]: what does perl6 -e '$*IN.eof.say' give you? 14:01
lizmat Zoffix: it gives True to me 14:05
Zoffix That must be it then. Gives False to me
[Coke] same as liz, gives true on a recent rakudo 14:13
Zoffix What about perl6 -e '$*IN.seek: 0, SeekFromCurrent' does this crash saying can't seek this handle? 14:22
[Coke] no output 14:23
Zoffix Aha! 14:24
ZOFVM: Files=1283, Tests=152772, 154 wallclock secs (21.15 usr 3.22 sys + 3311.70 cusr 170.37 csys = 3506.44 CPU) 14:26
Geth rakudo/nom: e70969e342 | (Zoffix Znet)++ | 2 files
Use lexical instead of state var when we can

Same reasoning as in
  github.com/rakudo/rakudo/commit/6a...6e33e4d89a		 14:27
travis-ci Rakudo build passed. Aleks-Daniel Jakimenko-Aleksejev 'Fix deprecation date 14:30
travis-ci.org/rakudo/rakudo/builds/291487729 github.com/rakudo/rakudo/compare/6...6c6403e083
Geth rakudo/nom: 50324bb004 | (Elizabeth Mattijsen)++ | src/core/List.pm
Threadsafe List.reify-until-lazy a bit

This is a bandaid for the 2017.10 release. It fixes the most common place where github.com/rakudo/rakudo/issues/1202 goes awry. The result is fewer crashes, and if they crash, it's because MoarVM itself go thoroughly corrupted.		 14:36
lizmat AlexDaniel`: ^^^ concludes my search for now
AlexDaniel` lizmat: awesome, thanks 14:37
Zoffix The macos $*IN.getc bug is likely on this line: github.com/MoarVM/MoarVM/blob/5d2e...ile.c#L171 don't got a macos so can't dump stuff to see what's in it. From answers above, on macos $*IN is seekable, and I'm guessing st_size is zero on that line and seek_pos is zero and the result is it thinks it reached EOF so it doesn't block to wait for a new char 14:40
Alternatively, the bug is that on macos $*IN is detected as seekable when it ain't (no idea about this stuff) 14:41
[Coke] Zoffix: doing a build with -g now, will try to get you a dump. 14:49
Zoffix This tells me "NOT seekable" on Linux: glot.io/snippets/eutbl8qmkz 14:54
and IIRC basically the code used by MoarVM to figure out if handle is seekable 14:55
[Coke] STDIN IS: seekable
Zoffix Well, that's where the problem is at, I guess. 14:56
[Coke] so do we just hardcode if stdin is seekable? 14:57
Zoffix What do you mean hardcode?
[Coke] stackoverflow.com/questions/287604...x-vs-linux
"if stdin, assume seek behavior is <blah>, regardless of what lseek says" 14:58
Zoffix "It appears to be a problem with OS X's standard library, even though this works with clang on Linux. It works on OS X using the Homebrew G++ 4.9." 14:59
yikes
[Coke]: with <blah> being what? It could be both seekable and unseekable depending on what it was pointed to, can't it?
[Coke] no clue, just spitballing. 15:00
In any case, is reverting jnthn's commit ok? Or adding a version that is mac specific? (Since the old way worked) 15:01
AlexDaniel` what if it needs #include <unistd.h> ? 15:03
Zoffix It's already included 15:04
AlexDaniel` stackoverflow.com/questions/587254...k-return-0
ah right
nvm
Zoffix [Coke]: reverting is kinda sweeping the problem under the rug. .eof would still be broken. This was all part of rework from async libuv stuff to sync stuff, so presumably inside libuv there's an answer for how to figure out EOF 15:05
Zoffix & 15:09
lizmat afk for a bit& 15:22
ugexe note that windows had a similar problem, where we recently added a return -1 if ESPIPE in its platform specific MVM_lseek function. which was ok because like lseek its behavior is not defined for non file type descriptors. so maybe we should add that constraint to non-windows MVM_lseek as well 15:48
pmurias bartolin: isn't p6bindattrinv meant for normal non-native attributes? 15:59
Zoffix What about changing this github.com/MoarVM/MoarVM/blob/5d2e...ile.c#L171 to return statbuf.st_size == seek_pos || (statbuf.st_size == 0 && S_ISREG(statbuf.st_mode)) 16:00
'cause we already do stat call there
Ah, wait no 16:02
ugexe: how to do that? I googled and results say to do lseek to figure out if you're on a seekable device and another answer is to use S_ISREG macro, but that needs a stat call and that's expensive or something? 16:09
ugexe a naive solution may assume fd 0,1,2 are not seekable 16:12
Zoffix That's too native, I think 16:14
$ perl6 -e '$*IN.readchars(3).say; $*IN.seek: 0, SeekFromBeginning; $*IN.slurp.say' < foo
abc
def
.seek works fine when $*IN is a file
ilmari $ perl6 -e '$*OUT.say("wibble"); $*OUT.seek: 0, SeekFromBeginning; $*OUT.say("wat")' > wibble 16:16
$ cat wibble
wat
le
ditto for $*OUT
Zoffix maybe special handling: use lseek, if it says fd is seekable and fd is 0, 1, 2, then do stat and check S_ISREG(statbuf.st_mode) 16:18
Zoffix & for a few hours 16:19
ugexe github.com/gdamore/less-fork/searc...&type= this shows `less` using lseek($, 1, $) to check if it is seekable, and then do a lseek($, 0, $) immediately afterwards if it is 16:21
so maybe in moarvm it should be doing an lseek($,1,$) instead of lseek($,0,$)? 16:22
bartolin pmurias: oh, I didn't know that. I was looking at that, because this code does not work on the jvm backend: github.com/rakudo/rakudo/blob/5032...Int.pm#L31 16:23
lizmat AlexDaniel`: are you still up for a release today ? If not, I think I have an idea on one of the underlying issues of github.com/rakudo/rakudo/issues/1202
AlexDaniel` lizmat: go for it, I'll adjust accordingly :) 16:24
lizmat the thing is that List.elems may not be a read-only action on a List
and there's plenty of .elems on Lists in ThreadPoolScheduler outside of protected blocks :-( 16:25
bartolin m: use nqp; say nqp::p6bindattrinvres(Int.new,Int,q|$!value|, nqp::getattr(42,Int,q|$!value|)) ## fails with BadReferenceRuntimeException on jvm 16:26
camelia 42
bartolin pmurias: ^^ in BOOTSTRAP.nqp we define $!value as bigint 16:27
Zoffix bartolin: FWIW that used to segfault on MoarVM 16:32
until recently
m: use nqp; nqp::bindattr(Int.new,Int,q|$!value|, nqp::getattr(42,Int,q|$!value|)); 16:33
camelia ( no output )
Zoffix m: use nqp; nqp::bindattr_i(Int.new,Int,q|$!value|, nqp::getattr_i(42,Int,q|$!value|));'
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> 3e|, nqp::getattr_i(42,Int,q|$!value|));'7⏏5<EOL>
expecting …
Zoffix m: use nqp; nqp::bindattr_i(Int.new,Int,q|$!value|, nqp::getattr_i(42,Int,q|$!value|));
camelia ( no output )
Zoffix both seem to work for bigint vOv
That was the fix for the segfault: github.com/MoarVM/MoarVM/commit/3b4b032984 16:35
m: use nqp; class Foo { has int $.x }; nqp::p6bindattrinvres(Foo.new, Foo, q|$!x|, my int $ = 42) 16:40
camelia P6opaque: representation mismatch when storing value (of type Int) to attribute (of type int)
in block <unit> at <tmp> line 1
timotimo you cannot use bindattr with native attributes 16:41
you need a bindattr_i equiv; we don't have that for p6bindattrinvres it seems
but it'd be easy enough to implement, no need to touch moarvm even
Zoffix m: use nqp; class Foo { has int $.x = 42 }; nqp::p6bindattrinvres(Foo.new, Foo, q|$!x|, nqp::getattr(Foo.new, Foo, q|$!x|)).x.say
camelia 42
lizmat afk for dinner& 16:42
timotimo not sure how exactly that works :) :)
Zoffix bartolin: maybe Int.new should just be changed?
Feels like the path of least resistance, since on moarvm p6bindattrinvres don't seem to be handling natives in all cases either 16:43
timotimo: what's `bigint` is that considered native attribute or not? 16:44
timotimo where exactly are you seeing that? 16:45
Zoffix Int's $!value attribute
timotimo ah
i expect it's .. quite special indeed
write access is usually done via boxing operations 16:46
Zoffix j: use nqp; nqp::bindattr_i(Int.bless,Int, q|$!value|, nqp::getattr_i(nqp::decont(42),Int, q|$!value|))
camelia Error while reading '/home/camelia/p6eval-token': No such file or directory at /home/camelia/rakudo-j-inst/bin/eval-client.pl line 10.
timotimo and at the lowest level Int will behave like a bigint, i guess? 16:47
bartolin Zoffix: your last evaluation gives: Attribute '$!value' is not a native int
timotimo m: use nqp; nqp::box_I(Int, Int.new(99)).perl.say;
camelia ===SORRY!===
No registered operation handler for 'box_I'
Zoffix m: use nqp; my $i := Int.bless; nqp::bindattr($i,Int, q|$!value|, nqp::getattr(nqp::decont(4200000000000000000000000000000000000000000000000000),Int, q|$!value|)); say $i
camelia 4200000000000000000000000000000000000000000000000000
timotimo m: use nqp; nqp::add_I(0, Int.new(99)).perl.say; 16:48
camelia ===SORRY!===
Arg count 2 doesn't equal required operand count 4 for op 'add_I'
timotimo m: use nqp; nqp::add_I(0, Int.new(99), Int).perl.say;
camelia 99
Zoffix bartolin: what about my last one ^
timotimo since we don't have box_I exposed, you can just do it like that and that'll have the effect you want
bartolin again a BadREferenceRuntimeException: Cannot access a native attribute as a reference attribute
Zoffix timotimo: that'd give me infinite loop tho. Is `Int.new` part necessary? 16:49
timotimo no, that's the argument you're getting passed in
this is about the Int:D case for Int.new, right?
i mean Int.new(Int:U: Int:D)
Zoffix Yeah: github.com/rakudo/rakudo/blob/nom/...pm#L31-L32 16:50
timotimo i'd implement it based on add_I
but not using Int literally in the add_I. use self instead, so it'll be subclassing friendly
Zoffix m: my $i := 42 but role Meows {}; use nqp; dd nqp::add_I(0, $i, Int) 16:51
camelia 42
Zoffix cool. Patch coming up
timotimo does that work on the jvm?
j: my $i := 42 but role Meows {}; use nqp; dd nqp::add_I(0, $i, Int)
camelia Error while reading '/home/camelia/p6eval-token': No such file or directory at /home/camelia/rakudo-j-inst/bin/eval-client.pl line 10.
timotimo oh, yeah
bartolin that one gives back 42 16:52
but this is a Exception again: 'use nqp; nqp::add_I(0, Int.new(99), Int).perl.say;'
Zoffix bartolin: 'cause that's got Int.new that has p6bindintvres 16:53
bartolin oops, you're right
Zoffix++
travis-ci Rakudo build passed. Aleks-Daniel Jakimenko-Aleksejev 'Tiny improvements to announcement generation 16:54
travis-ci.org/rakudo/rakudo/builds/291513127 github.com/rakudo/rakudo/compare/b...be159f202a
Zoffix m: use nqp; for ^1000_000 { nqp::p6bindattrinvres(0, Int, q|$!value|, nqp::getattr(42, Int, q|$!value|)) }; say now - INIT now 16:57
camelia 0.
Zoffix what's up with that output lol 16:58
m: use nqp; for ^1000_000 { nqp::p6bindattrinvres(100, Int, q|$!value|, nqp::getattr(42, Int, q|$!value|)) }; say now - INIT now 16:59
camelia 0.164588
Zoffix m: use nqp; for ^1000_000 { nqp::p6bindattrinvres(0, Int, q|$!value|, nqp::getattr(42, Int, q|$!value|)) }; say now - INIT now
camelia 0.
Zoffix Ok, whatevs. Seems to be something about messing with 0's guts
ZOFFLOP: t/spec/S11-modules/nested.t 17:00
m: use Test; isnt 2.WHERE, Int.new(2).WHERE 17:01
camelia ok 1 -
Zoffix The nqp::add_I method fails this test
"returns a new object (not a cached constant)"
Zoffix tries to remember why that matters
m: use nqp; my $orig := 2; my $new := nqp::add_I(0, $orig, Int); $new does role Meows {}; $orig.^name.say 17:04
camelia Int+{Meows}
Zoffix m: use nqp; my $orig := 2; my $new := Int.new: $orig; $new does role Meows {}; $orig.^name.say 17:05
camelia Int
Zoffix m: use nqp; my int $orig = 2; my $new := Int.new: $orig; $new does role Meows {}; $orig.^name.say 17:06
camelia Int+{Meows}
Zoffix Eh, it's a load of crap, I guess.
the test
Or is there a reliable way to get an uncached Int object? Basically, the idea is you could `Int.new: blah` and then mess with that object all you want without affecting all the other cached Int onstants in the entire codebase 17:07
Geth nqp: 0539f6bb77 | MasterDuke17++ (committed using GitHub Web editor) | docs/ops.markdown
Correct isprime_I documentation
 17:08
Zoffix ^ the native int version about just does `box_i` which evidently reuses the cached cosntant
m: use nqp; my int $orig = 2000; my $new := Int.new: $orig; $new does role Meows {}; $orig.^name.say 17:09
camelia Int
Zoffix m: use nqp; my $orig := 2; my $new := nqp::add_I(0, $orig, Int); $new does role Meows {}; $orig.^name.say; Rat.new(1, $orig).denominator.^name.say 17:12
camelia Int+{Meows}
Int
Zoffix Looks like there's a way to do it...
m: use nqp; my int $orig = 2; my $new := nqp::div_I(nqp::decont($orig), 1, Int); $new does role Meows {}; $orig.^name.say; 17:16
camelia Int
Zoffix works.... kinda hackish, but works 17:17
ZofBot: it's alive! 17:20
ZofBot Zoffix, He exists
Geth rakudo/nom: e4a5bb17c9 | (Zoffix Znet)++ | src/core/Int.pm
Improve/Fix Int.new

  - Don't use p6bindattrinvres with `bigint` attributes; it's
   questionable if it should work and fails on JVM (part of #1201)
  - Make Int.new: int candidate properly give a new object instead
   of a cached constant		 17:34
roast: c0aa93b717 | (Zoffix Znet)++ | S32-num/int.t
Improve tests for Int.new not returning cached constant

  - Test the more direct effects instead of poking at memory addresses
  - Also cover Int.new(int) and Int.new(Str) candidates
Rakudo fix: github.com/rakudo/rakudo/commit/e4a5bb17c9		 17:36
bartolin builds a new r-j 17:38
Zoffix & 17:43
Geth roast: bd0c59de19 | usev6++ | 2 files
[jvm] Run some tests using doesn't-hang
 18:16
lizmat AlexDaniel`: I don't think I'll be able to get to the github.com/rakudo/rakudo/issues/1202 issue for the next 16 hours or so :-( 18:19
AlexDaniel` lizmat: ok, so let's decide what we are going to do with it. Thing is, we've had this problem for a while so it's not like we *have* to fix it now. At the same time, samcv is still not here and I'm going to bed soon. 18:21
lizmat: so if you want to get it into the release, we can release tomorrow
lizmat I'll be busy with the P6W for the next 3 hours or so 18:22
and then I'll be ready for bed as well
and tomorrow morning I won't be able to do much until 12:30 at least
AlexDaniel` well tomorrow is like, in 24 hours :)
lizmat true, ok, let's take it there :-)
AlexDaniel` any objections from others? 18:23
Zoffix nope
AlexDaniel` as far as I'm concerned, there is no need to rush
.tell samcv See irclog.perlgeek.de/perl6-dev/2017-..._15342542. Basically, we'll be delaying it for a bit more. There is RT #132349 which would be nice to have fixed, so probably no need to release moar ahead of time (although it's unclear if we'll get getc issue fixed or not). In any case, see you tomorrow o/ 18:28
yoleaux AlexDaniel`: I'll pass your message to samcv.
synopsebot RT#132349 [open]: rt.perl.org/Ticket/Display.html?id=132349 [REGRESSION] $*IN.getc not blocking on macOS
samcv thanks AlexDaniel`. i'm working on some of the changelog entries i hadn't yet added right now
yoleaux 18:28Z <AlexDaniel`> samcv: See irclog.perlgeek.de/perl6-dev/2017-..._15342542. Basically, we'll be delaying it for a bit more. There is RT #132349 which would be nice to have fixed, so probably no need to release moar ahead of time (although it's unclear if we'll get getc issue fixed or not). In any case, see you tomorrow o/
AlexDaniel` samcv: by the way, what was your timezone? 18:29
samcv -8
or maybe it's -7 depending
if it's daylight savings
so it's 11:30am right now 18:30
AlexDaniel` 10 hour difference :)
ok good 18:31
samcv if we can get that bug fixed in that release that'd be great as well
AlexDaniel` yes
Zoffix I'll take a crack at $*IN.getc tonight... 18:32
AlexDaniel` awesome. Zoffix++
Zoffix I guess it's time to figure out where to get a macos shell :)
AlexDaniel` stmuk: ↑
Zoffix ZofBot: macos tacos 18:33
ZofBot Zoffix, Timings are more stable on my home machine. Must have some high-CPU browser tabs open at work.
AlexDaniel` stmuk: one shell for Zoffix, please :)
samcv you still aren't allowed to virtualize macos right? 18:34
AlexDaniel` ZofBot: what work?
ZofBot AlexDaniel`, Tonight was one of his nights at the Community Centre
moritz samcv: I think not 18:35
samcv i think you can if the host is macos though
per the EULA
moritz and don't rent the virtual copy out to anybody, I assume? 18:36
ugexe i used macincloud.com before getting mac hardware
Zoffix stmuk: these two keys, if possible: gist.github.com/zoffixznet/76a79a0...c35ee54927 18:44
travis-ci Rakudo build passed. Aleks-Daniel Jakimenko-Aleksejev 'Reflect actual date, claim next release' 19:11
travis-ci.org/rakudo/rakudo/builds/291515551 github.com/rakudo/rakudo/compare/5...017036aaa5
lizmat grrr... it looks like my last changes made hyper/racing only use a single worker :-( 19:12
bisecting now 19:13
.oO( P6W driven debugging )
Zoffix :D 19:14
lizmat news.ycombinator.com/item?id=15535893 # Quest for a 100-Year Programming Language 19:19
samcv javascript is a 100 year language? 19:20
what
Zoffix "javascript is a 100 year language" — Web Developer 19:22
lizmat
.oO( I'm a hammer, you're a nail :-)
 19:23
Zoffix :)
lizmat just realizes she has been bingewatching Dexter too much
stmuk pauses The Orville to look at SSH keys 19:24
lizmat blog.builtinperl.com/post/perl-in-brazil # last question / answer :-) 19:25
Zoffix \o/ 19:26
lizmat false alarm: apparently I was running with some uncommitted changes, HEAD is still ok for hypering/racing 19:28
[Coke] \o/ 20:09
lizmat AlexDaniel`: what was the way to get that gist for tickets again ? 20:14
(changes of the past week) 20:15
Zoffix I didn't do recent modules page cause I didn't feel up to it
lizmat Zoffix: no problem, sorry to have put the pressure on :-( 20:16
so, when *did* the ratchet || fix land in rakudo? I can't really find it/ 20:37
?
looks like jnthn merged it in Sep ?
Zoffix bisect: say so 'abc' ~~ /^ [b || a] bc / 20:43
bisectable6 Zoffix, On both starting points (old=2015.12 new=e4a5bb1) the exit code is 0 and the output is identical as well
Zoffix, Output on both points: «True»
Zoffix bisect: say so 'abc' ~~ /:r ^ [b || a] bc / 20:44
bisectable6 Zoffix, On both starting points (old=2015.12 new=e4a5bb1) the exit code is 0 and the output is identical as well
Zoffix, Output on both points: «True»
Zoffix fine! be that way
bartolin oops, I just got three segfaults in a row while running integration/error-reporting.t -- and that was not on MoarVM, but on the JVM (1.8.0_144) 20:45
Zoffix bisect: say so 'abc' ~~ /:r [a || b] c /
bisectable6 Zoffix, On both starting points (old=2015.12 new=e4a5bb1) the exit code is 0 and the output is identical as well
Zoffix, Output on both points: «True»
Zoffix clearly I don't fully understand this stuff :) 20:46
bartolin oh, that's really interesting: this code reliably leads to a segfault with Rakudo version 2017.09-498-ge4a5bb17c built on JVM, using OpenJDK build 1.8.0_144-b01 on FreeBSD 10.4: 20:50
m: -> ::RT129906 { class :: is RT129906 {} }
camelia 5===SORRY!5=== Error while compiling <tmp>
RT129906 does not support inheritance, so <anon|82510288> cannot inherit from it
at <tmp>:1
synopsebot RT#129906 [resolved]: rt.perl.org/Ticket/Display.html?id=129906 Error when role stubbed as class
Zoffix bisect: say so 'abc' ~~ /:r ^ a [b || bc] $/ 20:51
bisectable6 Zoffix, Bisecting by output (old=2015.12 new=e4a5bb1) because on both starting points the exit code is 0
Zoffix, bisect log: gist.github.com/8569e45b1eb7f68055...28eccdef1f 20:52
Zoffix, (2017-09-20) github.com/rakudo/rakudo/commit/96...50462b4cd2
Zoffix k, now I understand
Geth: ver github.com/rakudo/rakudo/commit/96...50462b4cd2
Geth Zoffix, version bump brought in these changes: github.com/perl6/nqp/compare/2017....ga5f92f2fe
Zoffix lizmat: Sep 20; first two commits by smsl++: github.com/perl6/nqp/compare/2017....ga5f92f2fe 20:53
lizmat ok, so not in the past 2 weeks 20:55
Geth nqp: 84cc117776 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/io/AsyncProcessHandle.java
[jvm] Left shift exit code for AsyncProcessHandle
 21:31
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/10/23/...ds-racing/ 21:37
Zoffix \o/ 21:38
cognominal lizmat++ 21:42
Geth roast: 3802dde946 | usev6++ | S07-hyperrace/for.t
[jvm] Don't run hyperrace tests that might hang
Zoffix lizmat: FWIW, this one's in reverse. The description is of the buggy behaviour; I made it return Proc always: "fixed IO::Pipe.close so that only the .close on the last open handle will return the Proc object" 21:43
lizmat ah, ok, fixing
must have misread the commit message
fixed 21:45
Zoffix++
Zoffix lizmat++ # good weekly
samcv lizmat++ 21:55
lizmat goes off to bed 22:06
Zoffix wonder how to test the $*IN.getc issue, since it relies on STDIN being a tty or something 22:19
This covers the bug, but I would've liked to test that I can read from it too and that .eof becomes True when you read everything: gist.github.com/zoffixznet/e377f82...0bdf5e697b 22:31
We don't got a way to create IO::Handles from file descriptor numbers, do we? 22:54
Alternatively, how do I get features of openpty() without using C code (or using NativeCall) 22:55
Zoffix tries to hack something up with `script` command 23:00
timotimo i do believe moar has something to get an io handle from an fd 23:04
don't know the details, also gotta go to bed
o/
Zoffix \o 23:06
(╯°□°）╯︵ ┻━┻ 23:24
24 minutes writing a shiny test routine until I realized `script` sits and waits for MY TTY to CTRL+D instead of reacting to .in.close from shell 23:25
Oh wait, nm, it works :p 23:26
works on... lInux :( 23:41
Another strike against Unicode chars in code: i.imgur.com/afLFM0d.png 23:42
Works fine in my editor and terminal, but not when I'm sshed into macos box
(those are fancy quotes) 23:43
*sigh* the test hangs on MacOS for some reason 23:46
looks like IO::Pipe.spurt is busted on macos 23:49
Or rather IO::Pipe.close after spurt :S 23:50
Hangs: ./perl6 -e 'my $p = shell :in, q|script -q /dev/null "./perl6" "test.t"|; $p.in.spurt: "meow"; $p.in.close; $p.in.close';
Works: ./perl6 -e 'my $p = shell :in, q|script -q /dev/null "./perl6" "test.t"|; $p.in.say: "meow"; $p.in.close; $p.in.close'; 23:51
oh, it waits for a newline or something
yeah, .print: "meow" "hangs" while .print: "meow\n" ok
k, nm, i'ts something with `script` program. screw it 23:52
OK. Now I see the same bug lizmat mentioned in repl.t tests. Where STDIN I send to a Proc ends up in my STDOUT pipe 23:56
# expected: "False\nmeow\n\nTrue\n"
# matcher: 'infix:<~~>'
# got: "meow\n^D\b\bTrue\nmeow\n\nTrue\n"

Powered by Cro and the Raku® Programming Language.

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

Thank you!