Geth rakudo: LLFourn++ created pull request #1079:
Revert "Fix stuck precomp on osx"		 00:44
rakudo/nom: b7bed98c6d | (Lloyd Fournier)++ (committed using GitHub Web editor) | src/core/CompUnit/PrecompilationRepository.pm
Revert "Fix stuck precomp on osx"
 00:46
rakudo/nom: 31903fd458 | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/PrecompilationRepository.pm
Merge pull request #1079 from LLFourn/revert-1076-bugfix/osx-unstuck-precomp

Revert "Fix stuck precomp on osx"
ugexe llfourn: so does that mean spitsh is filling stdout during precomp instead of stderr? 00:49
llfourn ugexe: that could be it because rakudo precomp writes to STDOUT right? 00:50
Spit is huge so a lot of modules get loaded
ugexe yeah 00:51
Geth nqp: MasterDuke17++ created pull request #359:
Convert substr+eq to eqat		 01:28
Zoffix You do have a commit bit... 01:29
MasterDuke_ yep, and i'll merge after a while if nobody has any comment or objections 01:52
Zoffix cool 01:53
Zoffix sets Kitten on fire 02:02
Just realized it has a special case that, say Kitten.new(<fo o>).words has a special has where after returning word `foo`, my approach would still end up returning `''` at the end, because it has no clue whether we're at the end of the work queue (so return IterationEnd) or just freshly started and Kitten is an empty string (so return '') 02:04
s/special has/special case/
So my approach of making some seq-in-the-middle generalized iterator won't work :( 02:05
Well, good news. All of a sudden I freed all this time to work on finishing IO grant. Bad news is I don't have the proper tool to make .words/.lines/.comb/.split work right; especially on IO::CatHandle 02:06
Radical idea: make them all line-based; even .comb and .split 02:08
Radicaler idea: remove them 02:09
They're aching to be removed 02:10
them = .comb/.split
Or... make them eagerly slurp. This will minimize (or eliminate) fallout 02:14
But would make them LTA in IO::CatHandle ('cause they'll slurp all the files/wait for STDIN to terminate before returning anything) 02:15
Maybe that isn't all that fatal. It won't have to stay that way forever; only until someone smarter than me makes a proper Cat. 02:16
m: say 583-193 02:18
camelia 390
Zoffix I hope the person who wrote original code isn't too attached to it, 'cause it'll be about 360 nixed lines.
m: "".words.iterator.pull-one.perl.say 02:25
camelia IterationEnd
Zoffix oh
I don't have a special case. Never mind. Back on track with Kitten heh 02:26
oh wait, yeah, there still is a special case; not with words but with .comb/.split 02:28
m: "foo".comb(/^./).perl.say
camelia ("f",)
Zoffix with Kitten that would end up giving <f o o>
Zoffix goes to bed
[Tux] Inline::Perl5( 07:32
*fetch stage failed for Inline::Perl5: Unable to handle source 'www.cpan.org/authors/id/N/NI/NINE/P...6.tar.gz')
This is Rakudo version 2017.04.3-193-g31903fd45 built on MoarVM version 2017.04-57-g8d8a09b9 07:36
csv-ip5xs 3.071
test 12.679
test-t 4.247 - 4.277
csv-parser 13.465
nine [Tux]: are you using panda or zef? 07:39
[Tux] zef and panda 07:40
for the real install I now use zef, but I still build and test panda
nine Does zef update fix it?
[Tux] zef update does nothing but showing some statistics 07:41
nine And the error persists after the zef update? 07:43
[Tux] $ zef install Inline::Perl5 07:45
All candidates are currently installed
No reason to proceed. Use --force to continue anyway
Geth nqp: 5e9403a1fe | MasterDuke17++ | 11 files
Convert substr+eq to eqat

nqp::eqat is much faster than doing a substr+eq.		 08:28
nqp: 50a05bb472 | lizmat++ (committed using GitHub Web editor) | 11 files
Merge pull request #359 from MasterDuke17/convert_substr_plus_eq_to_eqat

Convert substr+eq to eqat
rakudo/nom: 3f7d1334dc | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Bump NQP to get MasterDuke's eqat fixes
 08:37
Ā¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-g50a05bb
lizmat afk again&
Geth nqp: b63e734d3f | (Pawel Murias)++ | src/vm/js/nqp-runtime/io.js
[js] Fix nqp::filereadable, nqp::filewritable, nqp::fileexecutable
 10:23
nqp: 66eae599ad | (Pawel Murias)++ | src/vm/js/nqp-runtime/multicache.js
[js] Remove debugging leftover
 11:42
nqp: 674cb40a88 | (Pawel Murias)++ | src/vm/js/nqp-runtime/io.js
[js] Handle all the modes that can be passed to nqp::open
Zoffix awwww. Realized Kitten don't got special cases I mentioned above and despite being dog slow would work... until I hit another roadblock: generic iter don't know how much string to cut off: " bar foo".words cuts it as "r foo" because the chunk is "bar" so it thinks it needs to cut off 3 chars from the head :/ 12:16
Zoffix gives up with it for good
and gonna make .split/.comb on IO::Handle full-slurp for now; until we have proper Cat 12:18
Woodi_ Cat is lazy slurp ? 12:23
can't find doc for it...
Zoffix Cat is lazy string 12:24
"Can't open perl script "Configure.pl": No such file or directory" :/ 12:41
great
ah. It'd help if I ran `build-rakudo` in correct directory
timotimo :D
Zoffix ZofBot: moar coffee plz!
ZofBot Zoffix, See <jnthn
jnthn o.O :) 12:42
MasterDuke_ didn't realize jnthn was as cool as Sting, Prince, Bono, etc.. must be pretty important to get a single name url! 12:45
Zoffix m: dd "xfoo".comb: "" 13:07
camelia ("", "", "", "", "").Seq
Zoffix Is that supposed to be this way? 13:08
Or more specifically:
m: dd "".comb: ""
camelia ("",).Seq
Zoffix ^ that that is 1 el list and not an empty Seq
There's a test for IO::Handle.comb that tests it to be empty,
timotimo but the empty string matches the empty file! 13:10
Zoffix makes "".comb: "" return ().Seq to see if we test for that case 13:12
timotimo m: say +"foobar".comb(""); say "foobar".graphs;
camelia 7
No such method 'graphs' for invocant of type 'Str'
in block <unit> at <tmp> line 1
timotimo m: say +"foobar".comb(""); say "foobar".chars;
camelia 7
6
timotimo hmm.
not my new favourite idiom for "how long is this string"
Zoffix it kinda makes sense if you assume chars are surrounded by empty strings :P 13:13
timotimo :D 13:14
tadzik . o O ( we're surrounded by nothingness ) 13:15
timotimo yo tadzik
tadzik \o/ 13:16
hey hey
timotimo if imgur weren't over capacity i'd show you a screenshot of my TUI profiler
tadzik oo
Zoffix m: dd "xfoo".comb(0) 13:17
camelia ("x", "f", "o", "o").Seq
Zoffix m: dd "xfoo".comb(0) eqv "xfoo".comb: 1
camelia Bool::True
Zoffix m: dd "xfoo".comb: -42
camelia ("x", "f", "o", "o").Seq
tadzik do want
timotimo it's very early in development
you can't control it yet, so all it does is output a not-fully-expanded call graph 13:18
it knows to expand only up to things that have multiple children 13:20
because the call graphs usually start with <unit-outer> -> <unit> -> <something>
Zoffix Well, no Str tests fail but more IO comb tests fail
m: dd "abcd".comb: ""
camelia ("", "", "", "", "").Seq
Zoffix 'cause it expects ^ that to be... um, well 5 els 13:21
So dd "".comb: "" is 0 els, but "abcd".comb: "" is 5 els :/
timotimo those tests don't seem all that great
Zoffix Yeah
Gonna change it. Because I basically made IO::Handle.comb do exact same thing as Str.comb 13:22
MasterDuke_ oh hey, anybody mind merging github.com/rakudo/rakudo/pull/1077? 13:23
Geth roast: b803879a6d | (Zoffix Znet)++ | S16-io/comb.t
Make test description better

by making it dump .perl of args Capture rather than just type. Very hard to figure out which test is failing otherwise.		 13:24
rakudo/nom: 4 commits pushed by MasterDuke17++, (Zoffix Znet)++ 13:25
MasterDuke_ Zoffix++ thanks 13:26
timotimo marvellous
dogbert11 m: use Test; is (0, 1e-1 ... * >= 1).gist, "(0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1)", "(oops)" # isn't it a bit suspicious to compare Nums like this ? 13:30
camelia ok 1 - (oops)
dogbert11 it's more or less pure luck that this test passes 13:31
m: say (6, 1e-1 ... * >= 7).gist 13:32
camelia (6 0.0999999999999996 -5.8 -11.7 -17.6 -23.5 -29.4 -35.3 -41.2 -47.1 -53 -58.9 -64.8 -70.7 -76.6 -82.5 -88.4 -94.3 -100.2 -106.1 -112 -117.9 -123.8 -129.7 -135.6 -141.5 -147.4 -153.3 -159.2 -165.1 -171 -176.9 -182.8 -188.7 -194.6 -200.5 -206.4 -212.3 -21ā€¦
Zoffix :S 13:34
m: say 6 - 1e-1
camelia 5.9
Zoffix m: say 1e-1
camelia 0.1
dogbert11 the second sequence was a bit of a fail :)
timotimo yeah, of course it goes negative when you go from 6 to 0.1 :)
dogbert11 but the original test looks a bit shaky to me
Zoffix what's up with 0.0999999999999996 tho? 13:35
There's no noise in 1e-1
timotimo are you sure?
Zoffix s: 1e-1, 'gist', \()
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/3f7d...ric.pm#L28
dogbert11 m: say (0, 1e-1 ... * >= 7).gist 13:36
camelia (0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.99999999999999 6.099999ā€¦
Zoffix s: 1e-1, 'Str', \()
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/3f7d...Num.pm#L97
timotimo i think 0.1 isn't possible as a floating point number
dogbert11 m: say (0, 0.1 ... * >= 7).gist # Rat
camelia (0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 6 6.1 6.2 6.3 6.4 6.5 6.6ā€¦
Zoffix huh?
Zoffix refocuses on IO 13:37
dogbert11 I was looking at the pi bug we discussed the other day, changing snprintf from "%.15g" to "%.16g" makes one test fail in t/spec/integration/advent2013-day15.t 13:39
and the test is 'is (0, 1e-1 ... * >= 1).gist, "(0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1)", "(oops)"' 13:40
MasterDuke_ how does it fail? 13:41
timotimo BBL 13:42
dogbert11 well, the result suddenly contains a lot of decimals
like (0 0.1 0.2 0.299999999 ...) 13:43
Zoffix dogbert11: it should be changed. One thing I can think of is `ok (so all (0, 1e-1 ... * >= 1) Ā»ā‰…Ā« (0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1, 1.1)), "blah blah"` 13:44
dogbert11 Ā»ā‰…Ā« nifty 13:45
MasterDuke_: I tried to fix RT #127184 by changing a "%.15g" to a "%.16g" 13:47
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=127184
dogbert11 two spectests failed, the one above and t/spec/S32-exceptions/misc.rakudo.moar 13:48
in addition to that I stumbled upon another bug/feature whereas the number e was suddenly printed out as 2.718281828459046, i.e. the last digit was incorrect 13:49
which was particularly interesting since e is defined (in src/core/Num.pm) as being 2.71828_18284_59045_235e0 13:51
[Coke] .
dogbert11 the 'fix' for the 'e' problem was to remove the underscores from the definition, i.e. 2.718281828459045235e0 instead of 2.71828_18284_59045_235e0 !?! 13:53
MasterDuke_ !!
dogbert11 the question is, what do I do now, pursue the problem by adjusting the 'broken' tests and trying to figure out what's happening when printing 'e' 13:55
Zoffix dogbert11: that sounds like the grammar is doing math to end up with the final number and it's overflowing or whatever before it gets a chance to end up with the final number
dogbert11 Zoffix: that could very well be the case 13:56
Zoffix bisect: say 1.1e308
bisectable6 Zoffix, Bisecting by output (old=2015.12 new=10e9d0c) because on both starting points the exit code is 0
Zoffix, bisect log: gist.github.com/15da5046f7657e3757...c342975803
Zoffix, (2016-11-08) github.com/rakudo/rakudo/commit/72...cf911dd7cf
Zoffix dogbert11: ^ similar to that bug
dogbert11 Zoffix: looks like it 13:58
dogbert11 IEEE 754 is tricky business 14:02
Zoffix ZOFFLOP: t/spec/S11-modules/require.t 14:08
m: dd "abc".comb: 0 14:11
camelia ("a", "b", "c").Seq
Zoffix m: dd "abc".comb: 0, 42
camelia ("b", "c").Seq
Zoffix *sigh*
Zoffix journeys deeper down the rabbit hole 14:14
ZofBot: why is it called a rabbit hole if I'm chasing after bugs?
ZofBot Zoffix, We are not turning Perl into any other existing language
dogbert11 Zoffix: can you see what happens during the ZOFFLOP, is anything logged to the console? 14:16
[Coke] rabbit hole, bug hunt, yak shaving.
Zoffix t/spec/S11-modules/require.t ...................................... Dubious, test returned 1 (wstat 256, 0x100) 14:24
No subtests run
t/spec/S11-modules/require.t (Wstat: 256 Tests: 0 Failed: 0)
Non-zero exit status: 1
Parse errors: No plan found in TAP output
dogbert11: that's it
ZOFVM: Files=1242, Tests=133881, 115 wallclock secs (21.68 usr 3.22 sys + 2368.46 cusr 137.55 csys = 2530.91 CPU)
dogbert11 interesting, I'll try to reproduce it, are you running the perl5 harness? 14:26
Zoffix Yes 14:27
nine Well we can say that it's a compile time issue as there are 0 tests run 14:29
Geth rakudo/nom: a995966617 | (Zoffix Znet)++ | src/core/Str.pm
Fix Str.comb(Int, $limit) for <1 combers

We already equate such combers to `1`, but only did so if $limit was effectively Inf.
Add same behaviour for other $limits		 14:35
rakudo/nom: aa711c1460 | (Zoffix Znet)++ | src/core/Str.pm
Fix Str.comb with empty-string comber

  - Make behave same as `1` comber
  - We already do the same for <1 Int combers
  - We already do the same for IO::Handle.comb
roast: a75a24c1e2 | (Zoffix Znet)++ | S32-str/comb.t
Remove trailing whitespace
 14:36
roast: b72f37f344 | (Zoffix Znet)++ | S32-str/comb.t
Define Str.comb for empty-string Str / <1 Int combers

  - Equate to `1` as comber; that is split the string into characters
  - We already tested for this behaviour for empty-string Str in IO::Handle.comb
   6.c-errata tests. This merely expands the tests to Str.comb and Int combers
Woodi Zoffix: IO::Handle.comb is like: int fd = open(); fd.comb ? very strange if yes... 14:44
Zoffix what? 14:46
Geth rakudo/nom: 973338a6b7 | (Zoffix Znet)++ | src/core/IO/Handle.pm
[io grant] Fix IO::Handle.comb/.split; make them .slurp

The current implementation has the following issues:
  - The features of the two methods do not match those of Str versions
  - Incorrect results are produced when the chunk to be produced overlaps
   the $*DEFAULT-READ-ELEMS boundary; e.g. .comb(65546) will return
   a 2-element list for a file with a `"x" x 65546` string in it; one
... (14 more lines)		 14:47
roast: 2dac218a24 | (Zoffix Znet)++ | S32-io/io-handle.t
Cover chunked-read issue in IO::Handle iter-producing read methods

Rakudo fix and bug description in:
  github.com/rakudo/rakudo/commit/973338a6b7		 14:49
Zoffix Woodi: IO::Handle.comb is now IO::Handle.slurp.comb; it used to be similar to that except without .slurp and with bugs
And for IO::CatHandle I think I'll just throw as NYI in .comb/.split. IO::ArgFiles don't do those anyway, and implicitly .slurping all of files sounds like a recipe for disaster 14:53
ZOFFLOP: t/spec/S32-io/IO-Socket-INET.t # doesn't so much flop, but starts hanging after I used the box for long enough time to have run 15+ stresstests 15:21
s/hanging/waiting for an already-taken port, I'd guess/ 15:25
Woodi Zoffix: IMO .comb and .split should be removed from Handle. and similiar. becouse they should operate on strings not file descriptors
timotimo i'd expect an already taken port to cause an exception rather than a wait 15:28
Zoffix ZOFFLOP: t/spec/S11-modules/nested.t 15:30
t/spec/S11-modules/nested.t .. Use of uninitialized value $repo-id of type Any in string context.
Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.
in any statement_control at ./blib/Perl6/Grammar.moarvm line 1
Use of uninitialized value $repo-id of type Any in string context.
Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.
in any statement_control at ./blib/Perl6/Grammar.moarvm line 1
^ that output showed up after I re-ran the test
And does not show up again on further re-runs 15:31
Geth rakudo/nom: 0bd39de255 | (Zoffix Znet)++ | src/core/Exception.pm
Make method name optional in X::Invalid::ComputedValue

Sometimes we don't know what the user-facing method was used.		 15:32
rakudo/nom: 60f898194f | (Zoffix Znet)++ | src/core/Baggy.pm
Throw on NaN values to Baggy.roll/.pick/.grab

Fixes RT#131270: rt.perl.org/Ticket/Display.html?id=131270		 15:33
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131270
Geth roast: b6073e1782 | (Zoffix Znet)++ | S02-types/baggy.t
Test NaN is rejected in Baggy.pick/.grab/.roll

RT#131270: rt.perl.org/Ticket/Display.html?id=131270 Rakudo fix: rt.perl.org/rt3/Public/Bug/Display...?id=131270		 15:34
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131270
Zoffix Woodi: says who? 15:35
dogbert11 Zoffix: wrt the ZOFFLOPS, could you be running out of some resource, e.g. FD's, memory or the like? 15:38
Zoffix dogbert11: definitely not memory. FDs... dunno maybe 15:39
Probably not tho
I'm running with TEST_JOBS=30 15:40
dogbert11 my initial attempts to reproduce you errors have failed although that doesn't prove much
how much memory do you have, 32 gig? 15:41
Zoffix tries to repro with while t/fudgeandrun t/spec/S11-modules/require.t; do true; done 15:42
dogbert11 relocates &
Zoffix dogbert11: 24GB
And when I had ~100GB or so, I got a google notice saying I never use that much and my VM can do with 21GB
I'd figure that's not the minimum RAM I could do with 15:43
perlpilot Woodi: I dunno ... a file can be seen as a strange kind of string :) 15:46
Zoffix By that logic we should also remove .lines and .words and force the user to do reads manually, because that's the way people did things in 1980s 15:47
perlpilot Woodi: though ... why don't we have indexing on strings like we do on listy things? That's probably most analogous to your opinion. 15:48
Woodi perlpilot: my concern are string methods on file descriptor...
Zoffix Because then the auto-1-item-list idiom breaks down and does the wrong thing any time you have a Str
Woodi but I just map *NIX into here 15:49
Zoffix Woodi: what's the concern tho?
You say they shouldn't be there without ever stating a reason.
Woodi in C: int fd = open(...); strtok(fd); 15:50
perlpilot that would be awesome.
Woodi perlpilot: :)
but IO::Handle is our low-level-ish module ? 15:51
Zoffix It's normal-level
m: 1[1] 15:59
camelia Index out of range. Is: 1, should be in 0..0
in block <unit> at <tmp> line 1

Actually thrown at:
in block <unit> at <tmp> line 1
Zoffix m: dd (1,)[1]
camelia Nil
Zoffix Feels discontinuous. I'd expect the two cases to be equivalent.
dogbert11: well, it's been running all this time and I didn't get any failures 16:07
dogbert11: I see both S11-modules/runtime.t and S11-modules/nested.t have `use lib 't/spec/packages/S11-modules';` maybe some issue with precomping some modules in it or something? 'cause IIRC some tests modify the module files in-situ. The fix might ivolve simply copying the files into `make-temp-dir` (from Test::Util) and performing the test there 16:10
geekosaur while seeing what Woodi wants (and C does *not* provide), I think that's actually more on the level of the as yet unimplemented Cat? 16:15
Woodi geekosaur: I provided C example of what I do not see in IO::Handle :) but I loooong time ago proposed to have UNIX::read/write/printf/strncmp implemented via NativeCall :) and for other OSes. then IO::Handle could be whatever we want :) better streams then fread/fwrite from stdio.h ! better then C++ too !! ;) 16:23
probably s/UNIX/Posix/ 16:24
Zoffix Woodi: so what does strtok do? 16:27
Woodi exploits ;)
man strtok_r
Zoffix shrugs 16:28
geekosaur well, except we're not using stdio, we're using libuv
Zoffix We do have .split. I don't see the difference
geekosaur strtok is as close as C gets to parsing
which isn't very 16:29
it's also kinda disgusting, but then it's C >.>
Zoffix And you say we don't have anything to in IO::Handle to split, right after saying that .comb and .split should be removed because they should operate on strings and not handles 16:30
geekosaur Woodi wants an abstraction over anything that can produce strings, and the low level stuff in that view to be hidden low level stuff 16:31
my experience is you don't hide those, you need them too much. adding an additional higher level view has its place but you can't live off of it, you run into too many edge cases
one of those neat ideas that only works in a subset of real world situations in practice 16:32
Woodi geekosaur: not me, perlpilot. and Zoffix :) 16:35
Zoffix I wouldn't have added .split and .comb to IO::Handle without a Cat, but it's too late now
Well, even with Cat.
Due to the whole data loss thing 16:36
with "foo".IO.open { say .words.head; say .lines.head; } would loose data and give wrong .lines.head because .words reads more than it needs 16:37
Would have another class on top of IO::Handle that keeps the read data in some buffer on which all the methods operate, so no loss is done. 16:39
Though it's still crap due to iterators and laziness
ZofBot: it's a giant mess
ZofBot Zoffix, Subroutines (keyword: "sub") are non-inheritable routines with parameter lists
Zoffix But... there's always module space :) 16:40
geekosaur that was one of the things I was hinting at, yes
Woodi more or less wants Haskell's conduit / pipes abstraction. that should likely be module space 16:41
Woodi Zoffix: if thing is specced that way then oki. but I think IO::Handle is just our fat file descriptor so string methods not fit into it. .x .rw are for fd
geekosaur right you want conduit/pipes. 16:42
Woodi like in good old OOP :)
geekosaur don't build that into the core
Zoffix Woodi: we don't have .x .rw on handles though. Only IO::Paths 16:43
Woodi geekosaur: ok, so what IO::Handle is ?
geekosaur you've already claoimed what it is is a thing that never has any reason to exist so I guess that is unanswerable
Woodi Zoffix: that is mistake too, we talk this few weeks ago
geekosaur since, you seem to think perl 6 should be so high level that low level is nonexistent
my claim is that nobody is at that level, for a reason
Zoffix Woodi: it's only a mistake because you want IO::Handle be the same thing as whatever C does 16:44
geekosaur C does not do this
Woodi wants ultra high level to be the only level. C doesnt do high level much less ultra high level
Zoffix File handles have modes in C, don't they
read write whateverf 16:45
geekosaur Woodi is saying those belong to file descriptors, and the only level above that is a magical String abstraction
Woodi Zoffix: I want clear distinction, what IO::Handle is responsible for. file descriptor is so far moust sensible functionality. but not saying it *must* be same as in low level space
geekosaur which is pipes/conduit in Haskell, or emulated with lazy I/O (getContrnts and friends) which are a constant source of bugs
Woodi I *realy* thinked we have IO already specced :) 16:47
Zoffix Woodi: there's really no file descriptors in Perl 6. There's a method you can get a number from, but you can't do anything with them. So saying IO::Handle is file descriptor is kinda meh
geekosaur oh, also you keep talking about how it should be based on POSIX
should we discontinue Windows support?
(also POSIX does not spec the things you asked for) 16:48
Woodi geekosaur: *nix is just example. but in other os'es it's exactly the same: file description, read write etc :)
Zoffix Woodi: IO::Handle let's you read/write data from files and pipes. That's all the description it needs IMO
geekosaur Woodi, on Windows a socket is not a file descriptor 16:49
there is a horrible and extremely fragile hack that tries to pretend that it is
Woodi Zoffix: still looks like abstraction over file descriptor :)
Zoffix I don't care what *nix/C can do with file descriptors. It's not IO::Handle"s concern
Nor do I care what a "file descriptor" or "strtok" is.
perlpilot PerlĀ 6 does quite a bit to blur distinctions so that things Just Work. 16:50
I mean that's one of the reasons we don't normally make the programmer think about the details of how numbers are implemented (for instance), they're just numbers in the mathematical sense. 16:51
or why the idea of "hashref" has given way to just "hash"
Zoffix is getting distracted again by IRC 16:52
We need #perl6-dev-dev... like #perl6-dev but queter
:)
Woodi Zoffix: you should care becouse you delegate to them via libuv. and libuv is just universal abstraction over OSes raw functionalities. to me, so far, IO::Handle is just another wrapper with few additions 16:53
geekosaur no 16:54
or, perhaps, now you want to kill off jvm and javascript backends?
Zoffix Woodi: I don't delegate anything to libuv. I'm using nqp ops
Woodi ok, I just skipped on layer :) still not spec what IO::Handle do 16:55
Zoffix We have a decent spec in roast and docs.
Woodi looking... 16:56
geekosaur it abstracts over multiple possible lower levels, not all of which are your file-descriptor-which-is-clearly-always-there even though I just pointed out a case on Windows where it is not
Zoffix This feels like faffing about.
geekosaur apparently speccing a wrapper over an implementation detail is wasteful and pointless, so we should pick one backend and code to it only
Zoffix Just talk about removing methods or something missing in IO Handle and no specs, without anything doable or concrete.
Zoffix places this conversation on ignore... 16:57
Woodi ok, docs.perl6.org/type/IO::Handle do exactly what "file descriptor" :) off too. 17:01
geekosaur right, abstractions are evil 17:06
code to the bare metal, specific bare metal since you can't have evil backends that let you support some other hardware. perfect 17:07
Woodi geekosaur: you just assume too much
geekosaur you want to know what IO::Handle is
I told you
you rejected it 17:08
I can only see one reason to reject it: you don't care about abstraction over different backends, you want IO::Handle to either be the backend or get out of the way. therefore abstraction is obviously pointless and wrong
Woodi geekosaur: no. I want nice abstraction too. you assume I want bare metal. but thing is that current IO::Handle *is* bare metal wrapped 4 times :) + a) .split; b) .comb :) 17:11
geekosaur no, it is not
or.
Woodi docs.perl6.org/type/IO::Handle
geekosaur and ity has been pointed out that they don;t belong there
Woodi we still don't started that nice abstraction. it's raw fd functionality 17:12
geekosaur mpo, split and comb don;t work on file descriptors in any language
*no,
your C example was nonsense
Woodi geekosaur: by design !!!!
geekosaur and split and comb don't belong on IO::Handle althoygh I bet someone put it there as an optimization (a bad one)
and you still think file descriptors are the only backend when I pointed out a case where they are not 17:13
which you conveniently ignored, possibly because so many things insist on using the fundamentally broken winsock wrapper that makes sockets almost look like file descriptors as long as you don;t breathe around them 17:14
(Haskell ditched that wrapper entirely because it's so fragile and unworkable)
Woodi geekosaur: I know *nix and win only... so in my situation I didn't ignore anything :) 17:15
geekosaur but, you've made up your mind. enjoy the breakage
you don;t know win if you think file descriptors are *the* backend 17:16
in partivcular you;ve never worked seriously with winsock except through wrappers that hide the breakage from you
*wrappers*
the things you think are pointless and should go away
Woodi geekosaur: pleas stop... you said "split and comb don't belong on IO::Handle" and that is what I say from the start. some strange circles here 17:18
and every body wants nice abstraction but so far we have fd wrapped x times 17:19
geekosaur and uypu just repeated the completely wrong again
[Coke] I can't even follow at this point what geekosaur's position is.
geekosaur figures
[Coke] Can you state it for me? 17:20
geekosaur yes, fine, fuilke descriptor is the perfect abstraction layer, it is never broken especially on winsock where it is fundamentally broken but no it is never broken
Woodi geekosaur: we have libuv only + jvm, right ?
[Coke] Woodi: also a partial js. 17:21
MasterDuke_ wasn't libuv written for Node.js?
Woodi ok, probably we should add more .comb and .split like Zoffix++ proposed and we will have some abstraction over fd :) 17:22
geekosaur ...
I have been talking abotu how file descriptrs ARE BROKEN
this is 100% ignored
I guess that's my answer
Woodi geekosaur: I think not-Haskellers don't know this. where I can read about that ? 17:23
geekosaur msdn.microsoft.com/en-us/library/w...s.85).aspx 17:24
firrst thing it says: IS NOT A FILE DESCRIPTOR
windows stdio (ONLY STDIO NOT LOWER LEVELS) will try to pretend for you, up to the point where it breaks 17:25
[Coke] geekosaur: are you upset because people are using sloppy (and/or incorrect) terminology? Or that we should be changing our implementation? Or that someone has proposed something you feel is technically inappropriate?
I get that you're frustrated, but it's hard for me to see what exactly is the frustrating bit here.
geekosaur Woodi either wants raw file descriptors or something like Haksell pipes/condduit, anything in between is pointless wrapping 17:26
[Coke] please don't characterize what woodi wants. I'm asking you what you want.
geekosaur I pointed out file descriptors don;t work for everything even if you limit to win/unix, and only now is *maybe* that being acknowledged. Maybe.
I pointed out that wrapping is necessary because of bugs that need to be worked around, this is ignored still 17:27
I pointed out that different backends offer different things and not all of them are "file descriptor"-like, this is ignored still
[Coke] geekosaur: ignored by whom? 17:28
geekosaur [08 17:11:14] <Woodi> geekosaur: no. I want nice abstraction too. you assume I want bare metal. but thing is that current IO::Handle *is* bare metal wrapped 4 times :) + a) .split; b) .comb :)
this AFTER I pointed these things out, they're obviously not enough reason for wrapping the file descriptor that is defined as the only correct abstraction even though I had already pointed out it was wrong 17:29
Woodi yes, didn't thinked about network :)
geekosaur I am not continuing this. I consider myself answered and will be looking out for breakage from now on 17:30
Woodi geekosaur: but read this again: a) <Woodi> geekosaur: no. I want nice abstraction too. b) but thing is that current IO::Handle *is* bare metal wrapped 4 times : in I described reality
[Coke] I don't read woodi's send as ignoring your comment at all. he doesn't even mention FDs in the first one you quote. 17:33
I think perhaps stepping away for a bit as you suggest is a good idea, yes. 17:34
[Coke] drifts away back to $dayjob
MasterDuke_ nqp: my %h := nqp::hash("a", "b", "c", "d"); say(nqp::atpos(%h, 0)) 18:10
camelia This representation (VMHash) does not support positional access (for type BOOTHash)
at <tmp>:1 (<ephemeral file>:<mainline>)
from gen/moar/stage2/NQPHLL.nqp:1588 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/Nā€¦
MasterDuke_ lizmat: locally i have a patch for MoarVM such that ^^^ returns `b`, is that what you wanted? 18:11
lizmat MasterDuke_: yeah, just about :-) 18:12
yoleaux 13:12Z <AlexDaniel> lizmat: MasterDuke said that you may be interested in RT #131270
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131270
AlexDaniel m: say ^5 .BagHash.pick(2.5) 18:14
camelia count computed to 2.5, which cannot be used
in block <unit> at <tmp> line 1
MasterDuke_ lizmat: cool, anything else in particular or should i PR it?
AlexDaniel it's interesting that in some places we .Int-ify stuff, and in others it just refuses to work 18:15
lizmat MasterDuke_ : please PR it so that jnthn can have a look at it
AlexDaniel m: say ^5 .BagHash.pick(2)'
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3say ^5 .BagHash.pick(2)7ā5'
expecting any of:
infix
infix stopper
postfix
statement end
statement moā€¦
AlexDaniel m: say ^5 .BagHash.pick(2)
camelia (4 2)
AlexDaniel m: say ^5 .BagHash.pickpairs(2)
camelia (2 => 1 0 => 1)
AlexDaniel m: say ^5 .BagHash.pickpairs(2.5)
camelia (3 => 1 1 => 1)
AlexDaniel m: say ^5 .BagHash.pick(2.5)
camelia count computed to 2.5, which cannot be used
in block <unit> at <tmp> line 1
AlexDaniel :| 18:16
MasterDuke_ lizmat: PR'ed 18:24
lizmat MasterDuke_++
AlexDaniel screw it. RT #131272 18:26
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131272
Geth rakudo/nom: 31be51284e | (Elizabeth Mattijsen)++ | src/core/Baggy.pm
Better fix for RT #131270, fixes RT #131272

This breaks the latest added too specific tests for RT #131270.		 18:45
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131270
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131272
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131270
AlexDaniel so what's the rule of thumb? 18:56
ā€œif a non-int argument makes no sense, it is intifiedā€?
e: say ^5 .BagHash.pick(2.5) 18:57
evalable6 (1 0)
AlexDaniel e: say ^5 .BagHash.pick(-2.5)
evalable6 (3 0 1 4 2)
AlexDaniel e: say ^5 .BagHash.pickpairs(-2.5)
evalable6 (exit code 1) Unable to allocate an array of 18446744073709551614 elements
in block <unit> at /tmp/p5a9fTqCqs line 1
AlexDaniel what the f
c: HEAD~100 say ^5 .BagHash.pickpairs(-2.5) 18:58
committable6 AlexDaniel, Ā¦HEAD~100: Ā«Coercion to UInt out of range. Is: -2, should be in 0..^Infā¤ in block <unit> at /tmp/YU1w1WC3Ky line 1ā¤ā¤Actually thrown at:ā¤ in block <unit> at /tmp/YU1w1WC3Ky line 1ā¤ Ā«exit code = 1Ā»Ā»
lizmat AlexDaniel: oooh wow
AlexDaniel bisect: good=HEAD~100 say ^5 .BagHash.pickpairs(-2.5)
bisectable6 AlexDaniel, Bisecting by output (old=HEAD~100 new=31be512) because on both starting points the exit code is 1
AlexDaniel, bisect log: gist.github.com/9098a03c04deb2a200...e40cf5c63e
AlexDaniel, (2017-05-07) github.com/rakudo/rakudo/commit/0f...f5addd988f
lizmat looks
AlexDaniel lizmat: don't really have time to follow it, so I thought I'll file a ticket just in case: RT #131273 19:02
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131273
AlexDaniel buggable: tag REGRESSION 19:06
buggable AlexDaniel, There are 18 tickets tagged with REGRESSION; See perl6.fail/t/REGRESSION for details
Geth rakudo/nom: 08b5c1019f | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Fix for RT #131273
 19:08
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131273
AlexDaniel as long as I am stumbling upon these before users, I think everything is great :)
lizmat :-) 19:09
AlexDaniel I have some lovely ideas for regressionable bot, but this won't happen before June :( 19:10
Geth rakudo/nom: 20cfd6b7c6 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Move count validity check to PICK-N

So we won't have to repeat that in the future		 19:17
Zoffix split and comb fit nicely into IO::Handle if we have Cat 19:33
Zoffix boggles at screenfulls of mindless bickering abou it 19:34
samcv morning o/ 19:35
Zoffix \o
Geth roast: 42a4bc6112 | (Zoffix Znet)++ | S02-types/baggy.t
Adjust exception looked for by tests

To accomodate github.com/rakudo/rakudo/commit/31be51284e
The tests went in a few hours ago and are not part of 6.c-errata		 19:48
MasterDuke_ google offers $ rewards for integrating with their free fuzzing tool opensource.googleblog.com/2017/05/...r-and.html 19:50
Zoffix ZofBot: IT'S A TRAP! 20:22
ZofBot 5040
Zoffix m: dd "foo".comb: "o" 20:49
camelia ("o", "o").Seq
Zoffix m: dd "foo".comb: /o/
camelia ("o", "o")
timotimo not a seq? 20:50
Zoffix No
Zoffix is mildly annoyed by that inconsistency 20:51
'cause I'm documenting IO::Path.comb and now I can't put the `--> Foo` and indicate what it returnes, like I do for all other methods :/
MasterDuke_ is that explicitly tested behavior? 20:52
Zoffix Doubt it, since IIRC this got changed some time in october/november and tests didn't pick it up 20:53
lizmat Zoffix: fwiw, I think it should be a Seq, so please RT it 20:54
Zoffix OK
MasterDuke_ changing topics, would anybody object to also making `dd` a method? and wouldn't it make more sense in Mu.pm? 20:55
moritz objects
we already have .perl as a method
lizmat FWIW, this came up last week at the Amsterdam PM meeting
moritz and shouldn't add short method to Mu
lizmat and I agree with moritz
dd is a debugging aid 20:56
Zoffix objects to dd as method
MasterDuke_ moritz: "shouldn't add short method to Mu"? short in name?
moritz MasterDuke_: yes 20:57
MasterDuke_ why would the length of the name matter?
moritz (we should also be careful with adding more method to Mu at all, but especially with short names) 20:58
MasterDuke_: because they have a bigger potential to collide with user-supplied methods/attributes
Zoffix It's an unspecced debugging routine whose presence that doesn't affect anything and is easy to change in subsequent language versions. It as a method would make it present in all objects, will interefere with augmentations, would show up in .^methods(:all), and is hard to change between language versions.
moritz also stuff that prints directly to $*OUT/$*ERR is much less extensible than methods that just return something 21:00
which why we have .perl as a method in Mu, but not .dd
Zoffix m: say WHAT "foo".match: /o/, :x(42) 21:03
camelia (Slip)
Zoffix m: say WHAT "foo".match: /o/, :x(1)
camelia (List)
Zoffix Well, .comb returns a List for that one case because it uses .match and match returns a List 21:04
m: with (1, 2, 3).Seq { .join; .join } 21:08
camelia This Seq has already been iterated, and its values consumed
(you might solve this by adding .cache on usages of the Seq, or
by assigning the Seq into an array)
in block <unit> at <tmp> line 1
Zoffix Wonder if Seqs made from Lists can be pre-cached. 'cause it's already got a List invovled. We could just shove it into Seq.$!list and have all the things the same, except you'd get cache too, no? 21:10
lizmat sounds like a plan to me
Zoffix tries 21:15
jnthn I'm not sure it's entirely wise 21:33
Zoffix jnthn: how come? 21:34
jnthn It will break .Seq consistently giving you something that you can iterate once, unless you use .cache on it
timotimo right, accidentally rely on it and boom, you're done
jnthn I can imagine somebody writing code that passes its tests because the test has a hard-coded list of test data, then explodes in real use when it's given a Seq from some other source 21:35
Zoffix jnthn: I recall you saying the throwage due to iterating a non-cachede Seq twice isn't meant to be realied upon
And it's very easy to indirectly end up with a cached seq 21:36
m: with (1, 2, 3).Seq { .[0]; .join; .join }
camelia ( no output )
Zoffix There are 11 test failures tho... so the discussion may be moot.
jnthn I wasn't intending the end result to be a "feature" that makes producing reliable code harder. :S 21:37
Zoffix Right now it's a feature that duplicates data 21:38
Well, not 21:39
It is duplicated if you cache a seq made from list
jnthn I don't buy that. If code is written to explicitly take a Seq, then in all likelihood it's going to be doing something pipeline-y with it
And if it's not written to explicitly take a Seq, jsut some Iterable or Positional, you'd not have been doing a .Seq coercion in the first place.
Just passing it the original thing. 21:40
jnthn struggles to remember a case where he wrote .Seq in code that wasn't test code... 21:41
Zoffix I have it as my HEAD. Coercing List returned by Str.match to .Seq to keep consistent Seq-y interface of .comb 21:42
jnthn Str.match with :g ? 21:44
Zoffix Yeah
jnthn is mildy surprised that doesn't return Seq :) 21:45
If we already have factored it so .match with :g calls down to some internal thing, though, perhaps that could just produce an Iterator, and .match can form a List from it, and comb a Seq. 21:46
Yeah, looks like self!match-list is worth taking a look at 21:48
heh
Inside of there it's making a Seq and then .list-ing it :P
Zoffix That's probably because during Great Match Refactor there was the same inconsistency with Str.match as with Str.comb right now, where some combination of args returned a List while another a Seq 21:51
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/05/08/...batross_i/ 21:53
Zoffix OK. All test failures were my mess up. They're green now, with the exception of non-6.c-errata test for RT#127492 21:54
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=127492
Zoffix jnthn: so no, I should not push it?
jnthn Indeed...I think making List.Seq magically cache is probably a bit of a big hammer to fix .comb efficiently, though. Seems a more local refactoring would be preferable.
Zoffix it = List.Seq autocaching
jnthn I'd prefer not; it feels like a rough edge people will hurt themselves on every so often, and it will be a pain to debug. 21:55
Zoffix OK 21:56
lizmat++ # good weekly 21:57
jnthn lizmat++
Always see some things I've missed in the weekly :) 21:58
cog_ lizmat++ 22:22
about telemeh. How can one read number of cycles? Probably should read the branch to know 22:25
timotimo search for rdtscp
that's an x86 instruction that reads a performance counter 22:26
cog_ thx, nice
timotimo it's cool
it's also a nightmare to figure out how to correctly complie or refuse to compile stuff based on the running (or target) system
cog_ cuz people here are knowledgeable and cool 22:27
yea, it must be very architecture dependant 22:28
Zoffix method { 'foo' } shows up in bench with some time, but method (--> 'foo') {} always shows 0% 23:03
timotimo Zoffix: wow, not even inlining can do that! 23:05
unless it actually can?!
i mean, if the body of the function is so short that two consecutive calls to "get time from the clock please" just gives the same number for accuracy or caching reasons or something? 23:06
Zoffix I was thinking more along the lines of the bench doesn't catch the run?
Because it got empty body and all the "work" is in the signature?
Profiled this now and the --> 'foo' form is ~7 percentage points faster, but I dunno if that's real or not :) 23:10
timotimo hm. i don't think the static optimizer can throw method calls away. only private methods because it can resolve those at compile time, right? 23:12
i *think* if you turn on spesh logging with the profiler active it'll actually show you the places where the profiler emits its "log a call starting here" and "log the call ending here" things 23:13
it also makes those for inlined things
for something to appear in the call graph at all, i believe it has to hit those, i don't think there's another way for that to happen 23:17
does the number of entries match up with your expectations?
Zoffix The number is 1, so yeah. 23:18
This is what I profiled: gist.github.com/zoffixznet/de80ca6...4e60e8e64a 23:19
timotimo maybe we're just rounding it not-too-well? but i think i saw like 0.1% entries or something?
huh, i wouldn't expect a bench that short to give reasonable results
Zoffix and if I stick method calls into subs (e.g. sub x { Foo.spurt2 }), then the signature method consistently gives ~6 percentage points smaller time, but I don't know if that's real or not. 23:20
timotimo: so it has to iterate multiple times, just like when we do `now - INIT now` thing?
timotimo hmm. i wouldn't say it has to, but i wouldn't trust a measurement with N=1 23:21
Zoffix OK
timotimo anyway, to figure out stuff such as this i'd generally turn on spesh logging and make sure the functions i'm looking at get moderately ho
hot*
because then you'll see the bytecode we'll actually end up running
omg the cat is being adorable right next to me 23:22
away from keyboard, engaging kitty cuddles mode
Zoffix Well, I don't execute these methods 100_000 times in my code; just a few times, so they probably don't get speshied or wahteverr 23:23
And if I do 1000_000 iterations, 99.46% ends up for sink and both my methods are 0% :/ 23:24
timotimo hmm 23:37
feel free to xz the spesh log and toss it over
Zoffix is too tired to do anything today 23:38
timotimo no prob 23:40
i'll go to bed soon, too

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!