Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-09-01

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:14 cognominal joined #perl6-dev
01:48 ilbot3 joined #perl6-dev
01:48 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
04:40 zostay joined #perl6-dev
04:48 JimmyZ joined #perl6-dev
06:22 pmurias joined #perl6-dev
06:29 brrt joined #perl6-dev
06:31 dalek nqp: bedc1f3 | (Pawel Murias)++ | / (2 files):
06:31 dalek nqp: [js] NPM packaging tweaks.
06:31 dalek nqp: review: https://github.com/perl6/nqp/commit/bedc1f3af9
06:31 dalek nqp: 5ab6ddc | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
06:31 dalek nqp: [js] Fix slot handling bug.
06:31 dalek nqp: review: https://github.com/perl6/nqp/commit/5ab6ddc91d
06:31 dalek nqp: e8a8cb5 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
06:31 dalek nqp: [js] Fix bug in nqp::istype cause by calling convention change.
06:31 dalek nqp: review: https://github.com/perl6/nqp/commit/e8a8cb58be
06:31 dalek nqp: 799ee3d | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
06:31 dalek nqp: [js] Look into the NQPJS_LIB env variable for modules.
06:31 dalek nqp: review: https://github.com/perl6/nqp/commit/799ee3dbde
06:50 nine joined #perl6-dev
07:50 RabidGravy joined #perl6-dev
08:04 [Tux] This is Rakudo version 2016.08.1-59-gec9e814 built on MoarVM version 2016.08
08:04 [Tux] csv-ip5xs       11.132
08:04 [Tux] test            15.820
08:04 [Tux] test-t           7.668
08:04 [Tux] csv-parser      16.918
08:16 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:29 brrt joined #perl6-dev
08:30 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:31 brrt it's a bug in any language you'd care for
08:32 brrt 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:34 vendethiel joined #perl6-dev
08:58 dalek rakudo/nom: f0e6ae7 | lizmat++ | src/core/metaops.pm:
08:58 dalek rakudo/nom: Change some while ! to until
08:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f0e6ae7e00
09:03 nine joined #perl6-dev
09:03 Ulti joined #perl6-dev
09:03 jdv79 joined #perl6-dev
09:47 brrt joined #perl6-dev
10:07 dalek nqp: bcf943a | (Zoffix Znet)++ | docs/ops.markdown:
10:07 dalek nqp: Fix typo
10:07 dalek nqp: review: https://github.com/perl6/nqp/commit/bcf943ad4c
10:55 lizmat nine: given a file "Foo.pm" that contains just "sub a() is export { say "a" }
10:55 lizmat could you think of a reason why "perl6 -I. -MFoo -e 'a'" takes 4.5 seconds to load *every time* ?
10:58 lizmat nine: https://gist.github.com/lizmat/283178b87864a5a028b32529eeaa8f15
11:00 dalek rakudo/json_timing_stuff: 0dfbc65 | timotimo++ | src/core/ (4 files):
11:00 dalek rakudo/json_timing_stuff: some debug spam and timing of json parsing
11:00 dalek rakudo/json_timing_stuff: review: https://github.com/rakudo/rakudo/commit/0dfbc6585a
11:00 timotimo lizmat: can you try with this commit applied and see what the output is?
11:01 lizmat timotimo: that's related to my question?
11:01 timotimo yes
11:02 timotimo it showed a good chunk of time being spent in json parsing when doing -MGTK::Simple
11:05 lizmat timotimo: my git fu is insufficient
11:05 timotimo oh, just check out that branch
11:05 timotimo i rebased it on top of the nom branch just a minute ago
11:05 timotimo it should be sufficient
11:07 nine lizmat: that sounds horrible!
11:07 lizmat yeah, I was unpleasantly surprised  :-(
11:07 jnthn lizmat: fwiw, the incantation to do what timo suggested is something like `git checkout -b test-timo-thingy && git cherry-pick 0dfbc65`
11:08 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
11:08 nine mst: okay :)
11:09 nine lizmat: what does it show with RAKUDO_MODULE_DEBUG=1
11:10 lizmat https://gist.github.com/lizmat/efd9a31666a1615ad08ed2eec2d8d748
11:11 lizmat ah, perhaps because I have very filled .precomp dirs
11:12 lizmat nope
11:12 lizmat :-(
11:15 nine lizmat: aaaah, that's it!
11:15 lizmat what is?
11:15 nine Your /Users/liz/Github/rakudo.moar/ directory and its subdirectories are rather large, isn't it?
11:18 lizmat LizyPro:rakudo.moar liz$ ls | wc -l
11:18 lizmat 145
11:20 nine So calculating the sha-1 for those ~ 145 files is taking about 4 seconds :/
11:21 lizmat aha...
11:21 lizmat hmmm...
11:21 brrt ough
11:21 nine That's an unfortunate edge case of https://github.com/rakudo/rakudo/commit/848add944fe6de9090f0abc3b17e9a3a8e2cc42b
11:22 brrt ideaggestion
11:22 brrt SQLite database
11:22 brrt indexed, consistency ensured, portable
11:22 brrt fast
11:22 brrt concurrent
11:22 lizmat since when ?
11:23 brrt sqlite? since years
11:23 lizmat my experiences with SQLite in concurrent situations have been, sub-optimal
11:23 brrt alright, concurrent reads, single-threaded writes
11:24 lizmat still, having that as an external dependency, feels like a deadlock situation waiting to happen :-(
11:24 brrt not really to me
11:24 brrt why?
11:24 brrt also, why not make it an internal dependency? we already depend on libuv..
11:25 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...
11:25 brrt anyway, feel free to shoot it down
11:25 brrt :-)
11:25 nine Unless you convince all users to store their development modules in sqlite, we won't make progress in that direction :)
11:25 brrt that is a decent enough point
11:26 brrt otoh, for precompiled modules that shouldn't be a problem
11:26 lizmat $ time perl6 -Imodules -MZip -e 'a'
11:26 lizmat a
11:26 lizmat real0m0.201s
11:26 lizmat *phew*
11:28 lizmat so nine: we calculate the sha1 everytime for all of the files in the dir ?
11:55 vendethiel joined #perl6-dev
12:18 MasterDuke joined #perl6-dev
12:19 nine lizmat: once per process run on the first module load
12:20 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 :/
12:21 lizmat but if you keep it per process, there's no guarantee that they'll stay the same either  ?
12:24 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)
12:24 camelia rakudo-moar f0e6ae: OUTPUT«oh => -2422202650792912384␤»
12:24 timotimo i'd consider that a bug
12:24 masak aye
12:24 timotimo good catch!
12:25 masak I see no reason why it should be limited to some native size
12:26 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:27 masak it is a bug, though
12:27 masak is a rakudobug currently being submitted by someone? :)
12:27 masak (or shall I do it)
12:27 MasterDuke i'm looking into as part of RT #117739
12:27 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=117739
12:28 MasterDuke you don't remember every bug you've ever submitted?
12:29 masak only the ones I also discovered
12:29 masak and probably not even all of those :>
12:29 * masak .oO( 99999999999999999999999 beers on the wall, submit one down, pass it around... )
12:38 moritz a software tester walks into a bar, order 0 beers, order -1 beers, order 0xbeaf beers, orders al;dskfjslke54rjl34asdf09 beers
12:41 MasterDuke PR #855
12:45 dalek rakudo/nom: 816020f | (Zoffix Znet)++ | docs/release_guide (2 files):
12:45 dalek rakudo/nom: Add automated release guide [draft]
12:45 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/816020ffbd
12:57 dalek rakudo/nom: 5759717 | MasterDuke17++ | src/Perl6/Grammar.nqp:
12:57 dalek rakudo/nom: Fix RT #117739
12:57 dalek rakudo/nom:
12:57 dalek rakudo/nom: Fixes the error and also has the side-effect of adding support for
12:57 dalek rakudo/nom: values larger than an int.
12:57 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=117739
12:57 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/575971752a
12:57 dalek rakudo/nom: a452022 | lizmat++ | src/Perl6/Grammar.nqp:
12:57 dalek rakudo/nom: Merge pull request #855 from MasterDuke17/RT117739
12:57 dalek rakudo/nom:
12:57 dalek rakudo/nom: Fix RT #117739
12:57 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a452022476
13:00 MasterDuke thanks, working on some tests now
13:00 lizmat MasterDuke: doesn't seem to fix it for me :-(
13:03 MasterDuke huh, what did you test?
13:03 lizmat m: say (:123124124134124134134134124124314135135413412432513413325123523521342135245425oh)
13:03 camelia rakudo-moar 816020: OUTPUT«oh => -2422202650792912384␤»
13:03 lizmat ?
13:04 MasterDuke perl6 -e 'say (:123124124134124134134134124124314135135413412432513413325123523521342135245425oh)'
13:04 MasterDuke oh => 123124124134124134134134124124314135135413412432513413325123523521342135245425
13:05 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
13:05 lizmat timotimo: ah, good point  :-)
13:05 timotimo i'm just a little disappointed my branch wasn't able to point out the problem in the slow loading time :(
13:06 lizmat timotimo: because it was something entirely else
13:14 timotimo yeah
13:15 skids joined #perl6-dev
13:29 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:48 dalek roast: d85d8f4 | MasterDuke17++ | S02-literals/adverbs.t:
13:48 dalek roast: Test for RT #117739
13:48 dalek roast:
13:48 dalek roast: Requires Rakudo PR #855 (https://github.com/rakudo/rakudo/pull/855).
13:48 dalek roast: review: https://github.com/perl6/roast/commit/d85d8f46d8
13:48 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=117739
13:48 dalek roast: bc71659 | MasterDuke17++ | S02-literals/adverbs.t:
13:48 dalek roast: Merge pull request #149 from MasterDuke17/RT117739
13:48 dalek roast:
13:48 dalek roast: Test for RT #117739
13:48 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=117739
13:48 dalek roast: review: https://github.com/perl6/roast/commit/bc7165909f
14:02 gfldex joined #perl6-dev
14:23 lizmat I'm starting to wonder whether having "our" as the default for "class" is a wrong decision
14:23 bobv joined #perl6-dev
14:23 lizmat as it will interfere with the lexicality of -use- statements
14:24 lizmat 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?
14:28 lizmat if I have a file modules/A.pm with "class A { has $.a = 42 }" in it
14:28 lizmat and I do -Imodules -e '{ use A }; dd A.new'
14:28 lizmat this *will* work
14:28 lizmat even though the use itself is lexical
14:29 lizmat 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:32 Woodi lizmat: but is it specced that way ?
14:34 lizmat I think the default for "class" being our, is specced yes, and I'm questioning it
14:36 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:38 lizmat I mean, how are we going to handle:
14:38 lizmat { use Foo:ver<1.0> }; { use Foo:ver<2.0> }
14:39 lizmat if both versions have an "our class Foo" in them ?
14:39 Woodi our is "alias into the symbol table"; "symbol table" means global ?  https://docs.perl6.org/language/variables#The_our_Declarator
14:39 lizmat I should say 'implicit "our" in the class Foo definition
14:41 b2gills Just thinking out loud, but what if the current definition of what 「our」 means is slightly wrong when considering that use-case
14:44 lizmat b2gills: how would you like to change its meaning then ?
14:45 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:46 AlexDaniel joined #perl6-dev
14:46 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:47 lizmat so I guess we will need to teach people to use "my class Foo { }
14:47 lizmat "
14:48 lizmat the more I think about this, the more I think there are only downsides to "our"
14:48 lizmat in the Perl 6 context
14:48 lizmat also from an execution / optimization point of view
14:48 lizmat also multithreaded point of view
14:49 lizmat I mean, creating an entry into the global table would have to be checked against race conditions
14:55 TimToady well, we made 'my' short for a reason :)
14:56 jnthn One thing to note about "my" being the default is that
14:56 jnthn module Foo { class Bar { } }; Foo::Bar # doesn't exist
14:57 jnthn So it's certainly not a magic fix :)
14:57 jnthn But yes, there are genuine concurrency issues if you were doing things like concurrent runtime module loading
14:58 jnthn 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?
14:58 lizmat I mean, the check is on the long name, not on the short name
14:59 jnthn I'm not sure how exactly it's managed
14:59 lizmat well, the check *should* be on the long name, no ?
14:59 jnthn I wasn't really talking about checking anything so much as forcing serialization on module loads
14:59 lizmat I mean, if we want to be able to load multiple versions of the same module at the same time ?
15:00 jnthn Ah, I wasn't addressing that point, just the concurrency contorl one :)
15:00 jnthn *control
15:00 jnthn (to avoid confusion, I mean serialize in the concurrency sense above, not the persistence sense...)
15:00 lizmat TimToady: but would you not agree then that "our" for classes is a less useful default ?
15:02 jnthn It might be that only long names make sense in the global stash
15:04 lizmat our $foo is export   # how do we attach a long name on that ?
15:05 timotimo i think the long name would get "attached" when importing
15:05 jnthn It's already in a longnamed thing?
15:06 jnthn That is, if you're declaring it in a module Foo:auth<blah>:ver<1> { } then it's within that
15:06 jnthn Unless you declare it in GLOBAL in which case you get precisely what you deserve :)
15:07 lizmat jnthn: my understanding is that only the globalish of the compunit is longnamed
15:08 lizmat not individual elements of the globalish
15:13 TimToady I was always assuming that only long names go global
15:14 TimToady short names are supposed to be lexical aliases
15:15 TimToady though perhaps "assuming" is too strong a word since that's what S11 specifies^H^H^H^H^Hulates
15:16 TimToady (I assume :)
15:17 TimToady ((it could have changed since I last looked at it...))
15:18 lizmat TimToady: but that's about the whole globalish of the compilation unit, not about specific "our" elements in there
15:18 lizmat or is it ?
15:18 lizmat should we be able to say:
15:19 lizmat my $a = $foo:ver<1.2> ?
15:19 lizmat and get the "our" $foo of the version 1.2 of the compilation unit ?
15:20 [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?
15:21 [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
15:23 nine our/my is ortogonal to the issues with putting the names into GLOBAL
15:23 lizmat nine: ?
15:24 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 nine 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.
15:24 lizmat nine: even if it said "our class Foo" ?
15:25 nine yes
15:25 lizmat so what is then the difference between "my class Foo" and "our class Foo" ?
15:25 nine Because our/my is only about "is this accessible from the outside at all". Not about where to export it to.
15:26 nine With my class Foo even '{ use Foo; Foo.new }' will throw an error.
15:26 nine With our class Foo '{ use Foo; Foo.new }' will work while '{ use Foo; } Foo.new' won't
15:27 nine 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 nine s/global change/global state/
15:28 lizmat ok, so "my class Foo" is intended to be used only *within* that compilation unit
15:29 nine Yep. Just like any other my scoped names
15:29 jnthn unless you mark it "is export", of course :)
15:29 lizmat if you want it also accessible in the scope in which the compilation unit is loaded, one would need to say
15:29 lizmat my class Foo is export
15:29 lizmat ?
15:29 lizmat so basically "our" is short for "my ... is export" ?
15:30 nine Seems like, now that you mention that.
15:31 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
15:31 TimToady that's the whole point of having universal names...
15:31 lizmat TimToady: but when would one need to create a universal name ?
15:32 TimToady when one wants to claim that name everywhere and always
15:32 TimToady like when installing into the universal library
15:32 TimToady that's the Whole Point of longnames
15:33 TimToady the web only works because we have URLs, or URIs, or whatever they're called today
15:34 nine I hope merging the long names into GLOBAL will be the easy part :)
15:34 pmurias joined #perl6-dev
15:35 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
15:35 jnthn I think it's also helpful to keep in mind that when we say "name", we're not talking about a flat string
15:35 jnthn So
15:35 jnthn module Foo::Bar:ver<1>:auth<jnthn> { }
15:36 jnthn Would (approx)
15:36 jnthn Create Foo in the GLOBAL stash
15:36 jnthn Create Bar:ver<1>:auth<jnthn> inside of that Foo
15:36 jnthn Create a lexical package Foo
15:36 gfldex m: enum Options(<Foo Bar>); sub f(Foo $foo?){}; f();
15:36 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␤␤»
15:36 gfldex is this a bug?
15:37 pyrimidine joined #perl6-dev
15:37 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>".
15:37 jnthn That is, I guess there are the lexical shortnames and then the global long names
15:38 jnthn For longname I mean "with ver and auth"
15:38 jnthn Foo::Bar isn't a long name, just a nested name
15:39 nine But it's refered to as longname in some places of the code base :)
15:39 nine Most notably the grammar.
15:39 jnthn Note that longname in the grammar also parses colonpairs ;)
15:39 jnthn But yes, we handwave some, and probably too much, no dobut
15:42 nine Ok, rolling into Innsbruck now.
15:49 pmurias joined #perl6-dev
16:19 lizmat hmmm... I can't seem to get bare startup time below .128 anymore, used to be .114 a week ago
16:20 lizmat ah duh, backup running  :-(
16:29 tofu_ joined #perl6-dev
16:29 tofu_ m: for ^1000 { "foo".subst: :g, /<{"a\\sb\\sc"}>/, "" }
16:29 camelia rakudo-moar a45202: ( no output )
16:30 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␤»
16:31 tofu_ https://rt.perl.org/Ticket/Display.html?id=129161
16:34 woolfy joined #perl6-dev
16:34 woolfy left #perl6-dev
16:35 [Coke] let's remove #perl6-release
16:35 [Coke] I think that -dev and -toolchain cover any of the issues that could be brought up there, and they are actively used.
16:38 lizmat let's make #perl6-release robot only  :-)
16:42 [Coke] sure
16:53 lizmat afk&
17:39 vendethiel joined #perl6-dev
17:50 Ven joined #perl6-dev
18:27 Zoffix_ joined #perl6-dev
18:28 Zoffix_ mst: what am I supposed to find in strace -f?
18:29 Zoffix_ It sits waiting for "read(9,"
18:29 mst Zoffix_: the write() from your process to the pty, and hopefully the read() from them
18:32 Zoffix_ Well, yeah, there's "write(3, "MyPassPhrase\n", 13)          = 13". and I see a bunch of reads
18:45 Zoffix_ This is ridiculous lol. I've now spent 3 hours trying to feed gpg passphrase to git tag via STDIN :/
18:45 AlexDaniel joined #perl6-dev
18:51 mst Zoffix_: are you ever going to show me this
18:52 mst the question is the freaking pty
18:52 mst is it opening the right pty etc.
18:52 mst I would like to help, but quoting me random lines that look correct
18:52 mst won't help me work out what went wrong :P
18:54 Zoffix_ mst: here's the full output: http://temp.perl6.party/out.txt
18:55 Zoffix_ And the passphrase is MyPassPhrase
18:55 mst moment
18:57 mst [pid  3368] open("/dev/tty", O_RDWR)    = 8
18:57 mst you've not convinced it to use the pty you created
18:58 mst my gpg man page doesn't mention GPG_TTY
18:58 mst it *appears* that --status-fd and --command-fd might work
18:59 mst ooh, hang on
18:59 mst --passphrase-fd surely
18:59 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`
19:00 mst well, at least we know the problem is it, currently, not using the right tty
19:04 Zoffix_ Yeah. Thanks for spotting that.
19:06 mst basically, the trick with strace is you find where it went wrong
19:07 mst then you go backwards to find the open()
19:07 mst then you swear because you don't know why it's open()ing the wrong thing
19:07 Zoffix_ :)
19:09 TheLemonMan joined #perl6-dev
19:11 mst Zoffix_: oooh hang on
19:12 mst Zoffix_: you appear to've done it wrong
19:12 mst Zoffix_: you're supposed to fork()
19:12 mst Zoffix_: then do $pty->make_slave_controlling_terminal
19:12 mst Zoffix_: *then* exec()
19:13 mst Zoffix_: https://api.metacpan.org/source/TODDR/IO-Tty-1.12/t/test.t <- look for /dev/tty in there, there's a test for doing it that way :D
19:17 Zoffix_ ok
19:17 Zoffix_ 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
19:18 mst well, try the make_slave thing without setting it
19:18 mst and then see what you get
19:18 * mst crosses toes
19:18 TheLemonMan Zoffix_, R6 is very sweet looking, good job with that!
19:22 Zoffix_ Well, I tried this, but it's telling me "bad passphrase" https://gist.github.com/zoffixznet/ec574e21aae6e86ac35211c3888a8cd7
19:23 Zoffix_ Well, the full is "gpg: cancelled by user   gpg: no default secret key: bad passphrase  gpg: signing failed: bad passphrase"
19:25 Zoffix_ And it says that even if I don't send any passes to the pty
19:35 geekosaur you didn't attach the gpg to the pty
19:37 Zoffix_ How? I get the same issue if I specify the tty via GPG_TTY
19:43 Zoffix_ 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:47 Zoffix_ OMG! I won! Fuck you, computer! I'm better than you. muaahaha
19:47 Zoffix_ (sleep 1; echo "MyPassPhrase"; sleep 2) | unbuffer -p git tag ...
19:49 Zoffix_ With this fix in place, my release robot should finally be able to release NQP entirely automatically :)
19:50 Zoffix_ mst++ for helping :)
19:50 * Zoffix_ decommute
19:51 mst \o/
21:11 Zoffix joined #perl6-dev
21:20 TheLemonMan hmm, do we want a \n here ? https://github.com/rakudo/rakudo/blob/nom/src/core/Exception.pm#L366 the exceptions already show the backtrace on a new line, this feels a bit inconsistent
21:51 Ulti Zoffix++ for validating JSON :P
21:51 Zoffix Ulti, are you Matt Oates?>
21:51 Ulti should probably make a little git hook for checking that
21:51 Ulti yup
21:52 Zoffix Ah :) I just spotted the [error] on http://modules.perl6.org/update.log
21:53 Zoffix There's http://modules.perl6.org/dist/Test::META that'll check for you
21:53 Ulti orly
22:02 TheLemonMan RT#126134 can be closed, both the examples work fine
22:02 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=126134
22:10 Zoffix bisect: sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
22:10 bisectable6 Zoffix, No build for ‘bad’ revision
22:10 Zoffix wat
22:10 Zoffix bisect: bad=2015.12.25,good=HEAD sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
22:11 bisectable6 Zoffix, Cannot find ‘bad’ revision
22:11 Zoffix mmkay
22:11 Zoffix bisect: bad=2015.12,good=HEAD sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
22:11 bisectable6 Zoffix, Cannot find ‘bad’ revision
22:11 Zoffix bisect: bad=2016.01,good=HEAD sub aa (Int @a) { say "hi"; }; my @a of Int; aa(@a)
22:11 bisectable6 Zoffix, Cannot find ‘bad’ revision
22:12 Zoffix Marked ticket as testsneeded
22:12 TheLemonMan RT#126108 now prints the right error message
22:12 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=126108
22:16 MasterDuke joined #perl6-dev
22:18 Zoffix Marked as tests neeed, thanks.
22:18 Zoffix .ask [Coke] would it be possible to give TheLemonMan RT access so they could modify status of tickets they reviewed?
22:18 yoleaux2 Zoffix: I'll pass your message to [Coke].
22:18 Zoffix TheLemonMan, [Coke] will need your RT account email address
22:18 bisectable6 joined #perl6-dev
22:19 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)))␤»
22:20 TheLemonMan the iterator seemingly stringifies the WHICH instead of the key itself
22:20 dalek rakudo/nom: 631e2f7 | LemonBoy++ | src/core/Exception.pm:
22:20 dalek rakudo/nom: Print a newline after the message when using 'warn'
22:20 dalek rakudo/nom:
22:20 dalek rakudo/nom: Streamline the behaviour so now it's consistent across die, note and
22:20 dalek rakudo/nom: warn.
22:20 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/631e2f770e
22:20 dalek rakudo/nom: 128a0bd | (Zoffix Znet)++ | src/core/Exception.pm:
22:20 dalek rakudo/nom: Merge pull request #856 from LemonBoy/warn-nl
22:20 dalek rakudo/nom:
22:20 dalek rakudo/nom: Print a newline after the message when using 'warn'
22:20 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/128a0bd207
22:21 dalek rakudo/nom: d2b115f | lizmat++ | src/core/metaops.pm:
22:21 dalek rakudo/nom: Don't bother saving in a var if we don't need it
22:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d2b115f7fd
22:23 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
22:23 bisectable6 MasterDuke, Output on both points: hi
22:23 Zoffix \o/
22:23 Zoffix MasterDuke++
22:30 Zoffix left #perl6-dev
22:39 lizmat good night, #perl6-dev!
22:58 skids joined #perl6-dev

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary