dalek p: bedc1f3 | (Pawel Murias)++ | / (2 files):
[js] NPM packaging tweaks.
 06:31
p: 5ab6ddc | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Fix slot handling bug.
p: e8a8cb5 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Fix bug in nqp::istype cause by calling convention change.
p: 799ee3d | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
[js] Look into the NQPJS_LIB env variable for modules.
[Tux] This is Rakudo version 2016.08.1-59-gec9e814 built on MoarVM version 2016.08 08:04
csv-ip5xs 11.132
test 15.820
test-t 7.668
csv-parser 16.918
nine mst: don't know if you've noticed, but I've updated Inline::Perl6 documentation with the purely functional interface (mirroring the Inline::Perl5 docs). The OO interface currently has no advantage as you've noticed. 08:16
brrt re: reading 4 bytes from a single packet of a TCP stream as a unicode string and expecting it to work is a bug 08:30
it's a bug in any language you'd care for 08:31
possibly redundant, but the solution is for the sender to send a close and to have that end-of-stream be propagated to the decoder, which i think is just what jnthn++ is doing 08:32
dalek kudo/nom: f0e6ae7 | lizmat++ | src/core/metaops.pm:
Change some while ! to until
 08:58
p: bcf943a | (Zoffix Znet)++ | docs/ops.markdown:
Fix typo
 10:07
lizmat nine: given a file "Foo.pm" that contains just "sub a() is export { say "a" } 10:55
could you think of a reason why "perl6 -I. -MFoo -e 'a'" takes 4.5 seconds to load *every time* ?
nine: gist.github.com/lizmat/283178b8786...29eeaa8f15 10:58
dalek kudo/json_timing_stuff: 0dfbc65 | timotimo++ | src/core/ (4 files):
some debug spam and timing of json parsing
 11:00
timotimo lizmat: can you try with this commit applied and see what the output is?
lizmat timotimo: that's related to my question? 11:01
timotimo yes
it showed a good chunk of time being spent in json parsing when doing -MGTK::Simple 11:02
lizmat timotimo: my git fu is insufficient 11:05
timotimo oh, just check out that branch
i rebased it on top of the nom branch just a minute ago
it should be sufficient
nine lizmat: that sounds horrible! 11:07
lizmat yeah, I was unpleasantly surprised :-(
jnthn lizmat: fwiw, the incantation to do what timo suggested is something like `git checkout -b test-timo-thingy && git cherry-pick 0dfbc65`
mst nine: well, except that the OO interface is the one that works elegantly over Object::Remote :) 11:08
nine FWIW it's 0.8 seconds on the first run here and 0.4 seconds on the following ones
mst: okay :)
lizmat: what does it show with RAKUDO_MODULE_DEBUG=1 11:09
lizmat gist.github.com/lizmat/efd9a31666a...eec2d8d748 11:10
ah, perhaps because I have very filled .precomp dirs 11:11
nope 11:12
:-(
nine lizmat: aaaah, that's it! 11:15
lizmat what is?
nine Your /Users/liz/Github/rakudo.moar/ directory and its subdirectories are rather large, isn't it?
lizmat LizyPro:rakudo.moar liz$ ls | wc -l 11:18
145
nine So calculating the sha-1 for those ~ 145 files is taking about 4 seconds :/ 11:20
lizmat aha... 11:21
hmmm...
brrt ough
nine That's an unfortunate edge case of github.com/rakudo/rakudo/commit/84...3a8e2cc42b
brrt ideaggestion 11:22
SQLite database
indexed, consistency ensured, portable
fast
concurrent
lizmat since when ?
brrt sqlite? since years 11:23
lizmat my experiences with SQLite in concurrent situations have been, sub-optimal
brrt alright, concurrent reads, single-threaded writes
lizmat still, having that as an external dependency, feels like a deadlock situation waiting to happen :-( 11:24
brrt not really to me
why?
also, why not make it an internal dependency? we already depend on libuv..
nine Please note that installed modules are fast already and will be faster hopefully soon. It's uninstalled modules we load from some directory that cause the issues here. 11:25
lizmat can't really put my finger on it...
brrt anyway, feel free to shoot it down
:-)
nine Unless you convince all users to store their development modules in sqlite, we won't make progress in that direction :)
brrt that is a decent enough point
otoh, for precompiled modules that shouldn't be a problem 11:26
lizmat $ time perl6 -Imodules -MZip -e 'a'
a
real0m0.201s
*phew*
so nine: we calculate the sha1 everytime for all of the files in the dir ? 11:28
nine lizmat: once per process run on the first module load 12:19
lizmat ok, so it's not kept between runs... 12:20
nine IOW I really just need to figure out if the -I directory contains exactly the same as when we precompiled. And unfortunately file names + modification times are not enough because of shitty file systems :/
lizmat but if you keep it per process, there's no guarantee that they'll stay the same either ? 12:21
MasterDuke for the :123a form of pair creation, is the value supposed to be no bigger than a native int? 12:24
timotimo m: say (:123124124134124134134134124124314135135413412432513413325123523521342135245425oh)
camelia rakudo-moar f0e6ae: OUTPUT«oh => -2422202650792912384␤»
timotimo i'd consider that a bug
masak aye
timotimo good catch!
masak I see no reason why it should be limited to some native size 12:25
MasterDuke that form isn't very well documented, but the only text i could find in the docs that references a size is in the Adverb Pair entry of the Glossary "One special form starts with an integer value, followed by a name (for the key):" 12:26
masak it is a bug, though 12:27
is a rakudobug currently being submitted by someone? :)
(or shall I do it)
MasterDuke i'm looking into as part of RT #117739
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=117739
MasterDuke you don't remember every bug you've ever submitted? 12:28
masak only the ones I also discovered 12:29
and probably not even all of those :>
masak .oO( 99999999999999999999999 beers on the wall, submit one down, pass it around... )
moritz a software tester walks into a bar, order 0 beers, order -1 beers, order 0xbeaf beers, orders al;dskfjslke54rjl34asdf09 beers 12:38
MasterDuke PR #855 12:41
dalek kudo/nom: 816020f | (Zoffix Znet)++ | docs/release_guide (2 files):
Add automated release guide [draft]
 12:45
kudo/nom: 5759717 | MasterDuke17++ | src/Perl6/Grammar.nqp:
Fix RT #117739

Fixes the error and also has the side-effect of adding support for values larger than an int.		 12:57
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=117739
kudo/nom: a452022 | lizmat++ | src/Perl6/Grammar.nqp:
Merge pull request #855 from MasterDuke17/RT117739

Fix RT #117739
MasterDuke thanks, working on some tests now 13:00
lizmat MasterDuke: doesn't seem to fix it for me :-(
MasterDuke huh, what did you test? 13:03
lizmat m: say (:123124124134124134134134124124314135135413412432513413325123523521342135245425oh)
camelia rakudo-moar 816020: OUTPUT«oh => -2422202650792912384␤»
lizmat ?
MasterDuke perl6 -e 'say (:123124124134124134134134124124314135135413412432513413325123523521342135245425oh)' 13:04
oh => 123124124134124134134134124124314135135413412432513413325123523521342135245425
timotimo lizmat: you don't happen to still be on my branch? 13:05
MasterDuke This is Rakudo version 2016.08.1-63-ga452022 built on MoarVM version 2016.08-34-g344f379
lizmat timotimo: ah, good point :-)
timotimo i'm just a little disappointed my branch wasn't able to point out the problem in the slow loading time :(
lizmat timotimo: because it was something entirely else 13:06
timotimo yeah 13:14
nine llizmat: right. But the failure mode is that we miss a newer version of a dependency that popped into existence during our program run. Which I think is acceptable 13:29
dalek ast: d85d8f4 | MasterDuke17++ | S02-literals/adverbs.t:
Test for RT #117739

Requires Rakudo PR #855 (github.com/rakudo/rakudo/pull/855).		 13:48
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=117739
dalek ast: bc71659 | MasterDuke17++ | S02-literals/adverbs.t:
Merge pull request #149 from MasterDuke17/RT117739

Test for RT #117739
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=117739
lizmat I'm starting to wonder whether having "our" as the default for "class" is a wrong decision 14:23
as it will interfere with the lexicality of -use- statements
especially when trying to load multiple versions of the same compilation unit 14:24
timotimo but "use"ing something won't put stuff that's packge-scoped into the thing that's using it?
lizmat if I have a file modules/A.pm with "class A { has $.a = 42 }" in it 14:28
and I do -Imodules -e '{ use A }; dd A.new'
this *will* work
even though the use itself is lexical
I would have to add a "my" to the class definition in the file to make sure that the class definition doesn't except the scope 14:29
Woodi lizmat: but is it specced that way ? 14:32
lizmat I think the default for "class" being our, is specced yes, and I'm questioning it 14:34
b2gills I'm sure that was a very early decision, which means it didn't take into account all of the other features that were added later 14:36
lizmat I mean, how are we going to handle: 14:38
{ use Foo:ver<1.0> }; { use Foo:ver<2.0> }
if both versions have an "our class Foo" in them ? 14:39
Woodi our is "alias into the symbol table"; "symbol table" means global ? docs.perl6.org/language/variables#...Declarator
lizmat I should say 'implicit "our" in the class Foo definition
b2gills Just thinking out loud, but what if the current definition of what ｢our｣ means is slightly wrong when considering that use-case 14:41
lizmat b2gills: how would you like to change its meaning then ? 14:44
b2gills I don't know if my previous statement has anything to do with reality. I figured it might get someone to think from a different direction. 14:45
Woodi b2gills: our for vars is ok if someone want that :) but permament entry into global table for lexically used things is not very functional 14:46
lizmat so I guess we will need to teach people to use "my class Foo { } 14:47
"
the more I think about this, the more I think there are only downsides to "our" 14:48
in the Perl 6 context
also from an execution / optimization point of view
also multithreaded point of view
I mean, creating an entry into the global table would have to be checked against race conditions 14:49
TimToady well, we made 'my' short for a reason :) 14:55
jnthn One thing to note about "my" being the default is that 14:56
module Foo { class Bar { } }; Foo::Bar # doesn't exist
So it's certainly not a magic fix :) 14:57
But yes, there are genuine concurrency issues if you were doing things like concurrent runtime module loading
Though existing locking there to ensure you really only do load a module once may already take care of that. 14:58
lizmat jnthn: but that check would only apply to identical versions of a module, not to different versions of a module?
I mean, the check is on the long name, not on the short name
jnthn I'm not sure how exactly it's managed 14:59
lizmat well, the check *should* be on the long name, no ?
jnthn I wasn't really talking about checking anything so much as forcing serialization on module loads
lizmat I mean, if we want to be able to load multiple versions of the same module at the same time ?
jnthn Ah, I wasn't addressing that point, just the concurrency contorl one :) 15:00
*control
(to avoid confusion, I mean serialize in the concurrency sense above, not the persistence sense...)
lizmat TimToady: but would you not agree then that "our" for classes is a less useful default ?
jnthn It might be that only long names make sense in the global stash 15:02
lizmat our $foo is export # how do we attach a long name on that ? 15:04
timotimo i think the long name would get "attached" when importing 15:05
jnthn It's already in a longnamed thing?
That is, if you're declaring it in a module Foo:auth<blah>:ver<1> { } then it's within that 15:06
Unless you declare it in GLOBAL in which case you get precisely what you deserve :)
lizmat jnthn: my understanding is that only the globalish of the compunit is longnamed 15:07
not individual elements of the globalish 15:08
TimToady I was always assuming that only long names go global 15:13
short names are supposed to be lexical aliases 15:14
though perhaps "assuming" is too strong a word since that's what S11 specifies^H^H^H^H^Hulates 15:15
(I assume :) 15:16
((it could have changed since I last looked at it...)) 15:17
lizmat TimToady: but that's about the whole globalish of the compilation unit, not about specific "our" elements in there 15:18
or is it ?
should we be able to say:
my $a = $foo:ver<1.2> ? 15:19
and get the "our" $foo of the version 1.2 of the compilation unit ?
[Coke] yup. if I use bailador's "post /.*/ -> sub {..}", works fine. if I add a start {} inside the callback, then the first hook works, and no subsequent start blocks are run. 15:20
nine lizmat: have you seen the lexical_module_load branch?
[Coke] Any suggestions on how to debug? Using docker, so currently at 2016.07.1. wonder if I should try to upgrade docker first. :| 15:21
lizmat nine: I've heard of it, must admit I haven't looked at it yet
nine our/my is ortogonal to the issues with putting the names into GLOBAL 15:23
lizmat nine: ?
nine The lexical_module_load branch changes is so we no longer merge the comp unit's GLOBALish into GLOBAL at all but into the current lexical scope. So '{ use Foo; } Foo.new' will throw an error. 15:24
This is almost done. When it is we can talk about merging long names into a GLOBAL name space. We have discussed this briefly last week but couldn't find much of a use case for that.
lizmat nine: even if it said "our class Foo" ?
nine yes 15:25
lizmat so what is then the difference between "my class Foo" and "our class Foo" ?
nine Because our/my is only about "is this accessible from the outside at all". Not about where to export it to.
With my class Foo even '{ use Foo; Foo.new }' will throw an error. 15:26
With our class Foo '{ use Foo; Foo.new }' will work while '{ use Foo; } Foo.new' won't
Being able to contain it in a block is cute. More important is that other files won't see a change in the global change if you load some module. 15:27
s/global change/global state/
lizmat ok, so "my class Foo" is intended to be used only *within* that compilation unit 15:28
nine Yep. Just like any other my scoped names 15:29
jnthn unless you mark it "is export", of course :)
lizmat if you want it also accessible in the scope in which the compilation unit is loaded, one would need to say
my class Foo is export
?
so basically "our" is short for "my ... is export" ?
nine Seems like, now that you mention that. 15:30
TimToady anything creating a universal name has to be global though 15:31
lizmat this feels as a "false friend" between Perl dialects, but I could live with that
TimToady that's the whole point of having universal names...
lizmat TimToady: but when would one need to create a universal name ?
TimToady when one wants to claim that name everywhere and always 15:32
like when installing into the universal library
that's the Whole Point of longnames
the web only works because we have URLs, or URIs, or whatever they're called today 15:33
nine I hope merging the long names into GLOBAL will be the easy part :) 15:34
TimToady unless our library system takes two different modules and gives them the same longname, which should never be allowed to happen 15:35
lizmat TimToady: totally understood
jnthn I think it's also helpful to keep in mind that when we say "name", we're not talking about a flat string
So
module Foo::Bar:ver<1>:auth<jnthn> { }
Would (approx) 15:36
Create Foo in the GLOBAL stash
Create Bar:ver<1>:auth<jnthn> inside of that Foo
Create a lexical package Foo
gfldex m: enum Options(<Foo Bar>); sub f(Foo $foo?){}; f();
camelia rakudo-moar a45202: OUTPUT«Invocant requires an instance of type Int, but a type object was passed. Did you forget a .new?␤ in sub f at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
gfldex is this a bug?
jnthn Install a Bar within that 15:37
nine Well, according to current use, "name" can refer to "Bar" or "Bar:ver<1>:auth<jnthn>" "Foo::Bar:ver<1>:auth<jnthn>" and "longname" can refer to "Foo::Bar" or "Foo::Bar:ver<1>:auth<jnthn>".
jnthn That is, I guess there are the lexical shortnames and then the global long names
For longname I mean "with ver and auth" 15:38
Foo::Bar isn't a long name, just a nested name
nine But it's refered to as longname in some places of the code base :) 15:39
Most notably the grammar.
jnthn Note that longname in the grammar also parses colonpairs ;)
But yes, we handwave some, and probably too much, no dobut
nine Ok, rolling into Innsbruck now. 15:42
lizmat hmmm... I can't seem to get bare startup time below .128 anymore, used to be .114 a week ago 16:19
ah duh, backup running :-( 16:20
tofu_ m: for ^1000 { "foo".subst: :g, /<{"a\\sb\\sc"}>/, "" } 16:29
camelia ( no output )
tofu_ m: for ^1000 { "foo".subst: :g, /<{"abc".comb.join("\\s")}>/, "" } 16:30
camelia rakudo-moar a45202: OUTPUT«Memory allocation failed; could not allocate 762824 bytes␤»
tofu_ rt.perl.org/Ticket/Display.html?id=129161 16:31
[Coke] let's remove #perl6-release 16:35
I think that -dev and -toolchain cover any of the issues that could be brought up there, and they are actively used.
lizmat let's make #perl6-release robot only :-) 16:38
[Coke] sure 16:42
lizmat afk& 16:53
Zoffix_ mst: what am I supposed to find in strace -f? 18:28
It sits waiting for "read(9," 18:29
mst Zoffix_: the write() from your process to the pty, and hopefully the read() from them
Zoffix_ Well, yeah, there's "write(3, "MyPassPhrase\n", 13) = 13". and I see a bunch of reads 18:32
This is ridiculous lol. I've now spent 3 hours trying to feed gpg passphrase to git tag via STDIN :/ 18:45
mst Zoffix_: are you ever going to show me this 18:51
the question is the freaking pty 18:52
is it opening the right pty etc.
I would like to help, but quoting me random lines that look correct
won't help me work out what went wrong :P
Zoffix_ mst: here's the full output: temp.perl6.party/out.txt 18:54
And the passphrase is MyPassPhrase 18:55
mst moment
[pid 3368] open("/dev/tty", O_RDWR) = 8 18:57
you've not convinced it to use the pty you created
my gpg man page doesn't mention GPG_TTY 18:58
it *appears* that --status-fd and --command-fd might work
ooh, hang on 18:59
--passphrase-fd surely
Zoffix_ Hm.. --passphrase-fd 0 lets me use STDIN (without wrapper script), but it doesn't invoke gpg-agent, which I need to invoke and accept my password so it would work in `git tag`
mst well, at least we know the problem is it, currently, not using the right tty 19:00
Zoffix_ Yeah. Thanks for spotting that. 19:04
mst basically, the trick with strace is you find where it went wrong 19:06
then you go backwards to find the open() 19:07
then you swear because you don't know why it's open()ing the wrong thing
Zoffix_ :)
mst Zoffix_: oooh hang on 19:11
Zoffix_: you appear to've done it wrong 19:12
Zoffix_: you're supposed to fork()
Zoffix_: then do $pty->make_slave_controlling_terminal
Zoffix_: *then* exec()
Zoffix_: api.metacpan.org/source/TODDR/IO-T...2/t/test.t <- look for /dev/tty in there, there's a test for doing it that way :D 19:13
Zoffix_ ok 19:17
I also tested GPG_TTY on command line and if I set it to trash, the signing fails, so at least that seems to be working
mst well, try the make_slave thing without setting it 19:18
and then see what you get
mst crosses toes
TheLemonMan Zoffix_, R6 is very sweet looking, good job with that!
Zoffix_ Well, I tried this, but it's telling me "bad passphrase" gist.github.com/zoffixznet/ec574e2...c3888a8cd7 19:22
Well, the full is "gpg: cancelled by user gpg: no default secret key: bad passphrase gpg: signing failed: bad passphrase" 19:23
And it says that even if I don't send any passes to the pty 19:25
geekosaur you didn't attach the gpg to the pty 19:35
Zoffix_ How? I get the same issue if I specify the tty via GPG_TTY 19:37
It might be something with gpg... I installed `unbuffer`. `echo | unbuffer tty` gives /dev/pts/14, but if I do echo "Pass" | unbuffer git tag .... it just seems to freeze up 19:43
OMG! I won! Fuck you, computer! I'm better than you. muaahaha 19:47
(sleep 1; echo "MyPassPhrase"; sleep 2) | unbuffer -p git tag ...
With this fix in place, my release robot should finally be able to release NQP entirely automatically :) 19:49
mst++ for helping :) 19:50
Zoffix_ decommute
mst \o/ 19:51
TheLemonMan hmm, do we want a \n here ? github.com/rakudo/rakudo/blob/nom/...on.pm#L366 the exceptions already show the backtrace on a new line, this feels a bit inconsistent 21:20
Ulti Zoffix++ for validating JSON :P 21:51
Zoffix Ulti, are you Matt Oates?>
Ulti should probably make a little git hook for checking that
yup
Zoffix Ah :) I just spotted the [error] on modules.perl6.org/update.log 21:52
There's modules.perl6.org/dist/Test::META that'll check for you 21:53
Ulti orly
TheLemonMan RT#126134 can be closed, both the examples work fine 22:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126134
Zoffix bisect: sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a) 22:10
bisectable6 Zoffix, No build for ‘bad’ revision
Zoffix wat
bisect: bad=2015.12.25,good=HEAD sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
bisectable6 Zoffix, Cannot find ‘bad’ revision 22:11
Zoffix mmkay
bisect: bad=2015.12,good=HEAD sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
bisectable6 Zoffix, Cannot find ‘bad’ revision
Zoffix bisect: bad=2016.01,good=HEAD sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
bisectable6 Zoffix, Cannot find ‘bad’ revision
Zoffix Marked ticket as testsneeded 22:12
TheLemonMan RT#126108 now prints the right error message
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126108
Zoffix Marked as tests neeed, thanks. 22:18
.ask [Coke] would it be possible to give TheLemonMan RT access so they could modify status of tickets they reviewed?
yoleaux2 Zoffix: I'll pass your message to [Coke].
Zoffix TheLemonMan, [Coke] will need your RT account email address
TheLemonMan m: say :{ a => 1 }.Map # lizmat, can you give a look at this when you got a minute to spare? 22:19
camelia rakudo-moar a45202: OUTPUT«Map.new(("Str|a" => :a(1)))␤»
TheLemonMan the iterator seemingly stringifies the WHICH instead of the key itself 22:20
dalek kudo/nom: 631e2f7 | LemonBoy++ | src/core/Exception.pm:
Print a newline after the message when using 'warn'

Streamline the behaviour so now it's consistent across die, note and warn.
kudo/nom: 128a0bd | (Zoffix Znet)++ | src/core/Exception.pm:
Merge pull request #856 from LemonBoy/warn-nl

Print a newline after the message when using 'warn'
kudo/nom: d2b115f | lizmat++ | src/core/metaops.pm:
Don't bother saving in a var if we don't need it
 22:21
MasterDuke bisect: good=2015.12 bad=2016.08.1 sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a) 22:23
bisectable6 MasterDuke, On both starting points (good=2015.12 bad=2016.08.1) the exit code is 0 and the output is identical as well
MasterDuke, Output on both points: hi
Zoffix \o/
MasterDuke++
lizmat good night, #perl6-dev! 22:39

Powered by Cro and the Raku® Programming Language.

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

Thank you!