Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-03

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:46 sortiz .tell lizmat_ I found the culprit of my 'Can not invoke this object! 'PROCESS::' is null in the deserialized closure, this "BEGIN { temp PROCESS::; -> { note } }();" works.
01:46 geekosaur someone needs to invite yoleaux...
01:46 sortiz Seems so.
01:47 ilbot3 joined #p6dev
01:47 Topic for #p6dev is now Perl 6 language and compiler development
03:17 cognominal joined #p6dev
03:18 synopsebot6 joined #p6dev
04:19 dalek nqp: 5a65ffe | (David Warring)++ | examples/rubyish/rubyish.nqp:
04:19 dalek nqp: [examples/rubyish] replace %*save-sym with %*inner-sym
04:19 dalek nqp:
04:19 dalek nqp: Minor tweak. Reads better and avoids updating the outer %*SYM;
04:19 dalek nqp: review: https://github.com/perl6/nqp/commit/5a65ffe12e
04:19 dalek nqp: e9f1bdd | (David Warring)++ | examples/rubyish/rubyish.nqp:
04:19 dalek nqp: [examples/rubyish] add more comments
04:19 dalek nqp: review: https://github.com/perl6/nqp/commit/e9f1bdd89d
04:21 geekosaur joined #p6dev
05:52 sno joined #p6dev
06:12 [Tux] lizmat_, :( https://p6weekly.wordpress.com/2016/05/02/2016-18-long-awaited-landings/ QA report: Brand is without t
06:32 [Tux] This is Rakudo version 2016.04-82-gd065bad built on MoarVM version 2016.04
06:32 [Tux] test            22.472
06:32 [Tux] test-t          13.921
06:32 [Tux] csv-parser      36.314
07:10 lizmat_ [Tux]: strange, I thought I copy-pasted that, apparently not :-(
07:10 lizmat [Tux]: fixed now
07:41 dalek rakudo/nom: 28c2795 | lizmat++ | src/core/Num.pm:
07:41 dalek rakudo/nom: Make Num.Rat 25% faster for e0 case
07:41 dalek rakudo/nom:
07:41 dalek rakudo/nom: By skipping a lot of initializations, at the expense of one extra
07:41 dalek rakudo/nom: (fast) check for the slow path.
07:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/28c2795e80
07:58 dalek joined #p6dev
07:59 hoelzro joined #p6dev
08:00 tomboy64 joined #p6dev
08:01 geekosaur joined #p6dev
08:03 RabidGravy joined #p6dev
08:14 RabidGravy bloop
08:16 dalek rakudo/nom: 8fb78d8 | lizmat++ | src/core/Num.pm:
08:16 dalek rakudo/nom: Explicitely specify denominator
08:16 dalek rakudo/nom:
08:16 dalek rakudo/nom: Explicitely specifying an argument, even if it is the same as the
08:16 dalek rakudo/nom: default, is about 2x as fast.
08:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8fb78d8d1c
10:58 dalek rakudo/nom: 8197a00 | lizmat++ | src/core/Int.pm:
10:58 dalek rakudo/nom: Use explicit OutOfRange exception
10:58 dalek rakudo/nom:
10:58 dalek rakudo/nom: What's good enough for digits, is good enough for base  :-)
10:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8197a0089c
11:18 dalek rakudo/nom: 495e03c | lizmat++ | src/core/Int.pm:
11:18 dalek rakudo/nom: Make Int.base(2) almost 2x as fast
11:18 dalek rakudo/nom:
11:18 dalek rakudo/nom: By giving it a separate candidate
11:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/495e03cacd
11:27 TimToady joined #p6dev
11:48 dalek rakudo/nom: e4a1b56 | lizmat++ | src/core/Int.pm:
11:48 dalek rakudo/nom: Make Int.polymod between 1.2x and 1.7x faster
11:48 dalek rakudo/nom:
11:48 dalek rakudo/nom: By providing separate loops for the lazy vs non-lazy list
11:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e4a1b568cb
12:33 dalek rakudo/nom: feaf76d | lizmat++ | src/core/Int.pm:
12:33 dalek rakudo/nom: Make infix:<div/%>(Int,Int) about 1.5x as fast
12:33 dalek rakudo/nom:
12:33 dalek rakudo/nom: By using a single ternary for the divided by 0 test
12:33 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/feaf76ddd9
12:34 timotimo yay!
12:35 timotimo same should be possible for Num, right?
12:35 timotimo well, ok, you're just working through Int.pm, clearly
12:35 timotimo but still :)
12:36 timotimo either div or / used to be extremely high on the list of things eating up time in my particles benchmark
12:39 lizmat yeah, working on it  :)
12:48 timotimo \o/
12:49 timotimo of course, the 25x improvement in framerate won't be as easy as making those functions faster :)
12:50 timotimo lizmat: say, using Failure.new(...) and just returning that ... would that be the same as using "fail"? it *could* be faster, too
12:50 timotimo are you interested in trying that?
12:51 lizmat timotimo: aaah. good point  :-)
12:51 lizmat I guess it would only make the fail faster, but yes
12:51 timotimo i'm still interested in figuring out a way to remove that zero-check when the RHS is a literal number
12:52 timotimo because that was a quite common case in my code
12:55 lizmat "foo div 0" a common case ?
12:55 timotimo no, foo div 2
12:55 lizmat ack
12:57 timotimo and, of course, "strength reduction" by turning div-by-2 into a bit shift would also be worth a tiny bit; that'd likely go into spesh, though, not Perl6::Optimizer
12:59 lizmat do we have a bitcount function?
12:59 lizmat if bitcount(a) == 1, then we can shift
13:01 timotimo oof, really not sure
13:03 jnthn Probably one to do in spesh
13:03 jnthn Generally, we want to do things in spesh that we can, because then we only pay for the optimizations on hot code
13:03 jnthn Whereas if they're in Perl6::Optimizer we pay for them wherever they are
13:04 jnthn So really we just want to do the higher-level things that spesh will have trouble figuring out.
13:04 timotimo at some point we may want to have value/range propagation and a "this is non-zero" proofs
13:13 dalek rakudo/nom: ec6c3b8 | lizmat++ | src/core/Int.pm:
13:13 dalek rakudo/nom: Don't need to fail if were already returning
13:13 dalek rakudo/nom:
13:13 dalek rakudo/nom: Not seeing any performance gain, but this should produce smaller
13:13 dalek rakudo/nom: bytecode, no?
13:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ec6c3b89c5
13:15 timotimo yeah, throws out a call, i think
13:15 timotimo can you measure failing over and over and over?
13:15 timotimo well, i guess you already have
14:18 skids joined #p6dev
14:36 sortiz joined #p6dev
15:29 skids joined #p6dev
15:30 [Coke] rakudobrew has a request for a way to quickly find latest/stable tags for rakudo. I think we can simplify that to latest, since we don't really have a separate concept of stable. The suggestion on the ticket was to have a tag that moved. In general, we don't want that. Is this a case where that would be OK?
15:30 [Coke] asking here, since it's a git question.
15:31 [Coke] Alternatively, we could make rakudo.org/downloads/rakudo/tag return a text file with "2016.04" in it or something.
15:32 psch i only know that moving tags in git is really inconvenient for everyone downstream
15:33 psch hosting the latest tag somewhere seems good enough
15:34 psch i suppose we could also merge into a latest branch at every tag
15:34 psch and just pull that from rakudobrew
15:34 stmuk I thought the idea was two branches with existing "nom" becoming a dev branch and a new master becoming a stable (release) branch
15:34 stmuk or was it the other way round? :)
15:35 psch yeah, that's what i mean, except i called master "latest"
15:37 [Coke] you want to build rakudobrew from tags, not from a branch-latest.
15:37 [Coke] unless we're embracing gitflow, which I don't think was on the agenda.
15:38 stmuk yes but if we are tagging a branch we need to be clear about which branch first
15:38 [Coke] if you're building from a tag, you don't care what branch it's from, do you?
15:39 geekosaur if you just want latest, use annotated tags and then git describe tells you the latest annotated tag
15:40 stmuk if you only ever merge once onto master from nom then master always points at the current release doesn't it?
15:40 [Coke] geekosaur: in rakudobrew, we show you what versions are available before you've checked anything out, if that matters.
15:41 [Coke] stmuk: so, something gitflow like. Sure. In that scenario, you merge back to master from develop(or a release branch), and tag master. so latest is always master.
15:41 [Coke] er, latest released.
15:42 teatime changing tags is silly.  branch is perfect.  'latest' kind of sounds like a development branch, but meh whatever you like
15:43 teatime there's no reason it has to be as complicated as git-flow / more complicated than tagging
15:43 stmuk I suppose you make the changes on master atomic by being careful to only push once after tests pass
15:43 [Coke] git flow is not that complicated.
15:43 teatime I mean, if you want to use that model, feel free, I just mean there's no need if all you want is the add'l one branch for rakudobrew purposes
15:44 stmuk a quick google suggests moving git tags is complicated
15:44 teatime tags are not what you want for this for sure.
15:44 teatime also, from a git client perspective, you can pretty much use a branch name anywhere you could use a tag
15:44 teatime so there's no desire from that end for it to be a tag
15:45 teatime `git checkout 2016.05; git push upstream latest` is pretty easy.
16:21 nine_ tags are names for commits.
16:21 nine_ branches are names for commits!
16:21 nine_ The only difference between them is that branches usually point to different commits over time while tags are static.
16:21 nine_ So if you want a "moving tag", you simply want a branch, because that's what they are.
16:27 nine_ Whenever you think in terms of a branch "containing" something, you are just wrong and make your life harder. They no more contain anything than a symlink on the file system does.
16:29 nine_ Fun fact: since branches are just names for commits, you can use a commit id where you'd use a branch name, e.g. for git merge. git will generate a message like "Merge commit '7d664616d29b662d480bf654934e69cbb5d466b1' into master". And yes, this will of course merge the commit's parents up to the last common ancestor.
16:30 geekosaur especially fun fact when you're faced with an octopus merge >.>
17:03 RabidGravy I think we should all go back to using rcs and patch
17:06 [Coke] jnthn: Regarding docs/language_versions.md, I think we need 3 branches, not two: nom stays the same. "latest" or something new can be the auto-merging one you talk about. and we can have master which corresponds to the latest tagged release.
17:06 lizmat joined #p6dev
17:09 [Coke] then we can use master to solve the rakudobrew problem, the release process isn't complicated, and we can still have a not-quite-bleeding edge branch for people who are super excited about that sort of thing. (but it can still come later, since either master or nom is mostly fine in that case)
17:40 perlpilot [Coke]: Having a branch called "latest" that isn't "the latest tagged release" seems weird.
17:51 [Coke] perlpilot: it's the "latest version of development that passed tests"
17:51 [Coke] I'm fine to bikeshed the name.
17:51 timotimo DefinitelyWorksâ„¢
17:51 [Coke] *snrk*
17:52 timotimo i'm not sure â„¢ is actually allowed, but it'd be a good candidate if it did
17:53 [Coke] I used cyrillic in tags a few times, nothing exploded.
17:54 [Coke] er, unicode. once was cyrillic.
18:24 * masak .oO( оисе is cyrillic )
18:36 jnthn masak: argh, don't consonant the vowels dammit :P
18:37 masak more or less the reaction I expected :P
18:37 geekosaur w
18:37 masak (no, I don't like that either) :)
18:38 jnthn The sign at that oelrepublican place in Goteborg drove me nuts for that :P
18:40 [Coke] https://rt.perl.org/Ticket/Display.html?id=126873 looks closable, yes?
18:41 nine_ jnthn: I may have a lockless solution
18:42 jnthn uh-oh :)
18:44 geekosaur git check-ref-format likes DefinitelyWorksâ„¢ :p
18:44 nine_ jnthn: it involves implementing support in MoarVM for loading bytecode from a buffer and writing the dependency information + the mbc into a single file. Rakudo can load that file, process the dependency information and pass the rest to loadbytecodebuffer
18:44 jnthn [Coke]: Looks like.
18:45 [Coke] jnthn: closed, thanks.
18:45 jnthn nine_: We'll want something like that anyway for producing bytecode from MAST :)
18:45 jnthn nine_: Or even directly from QAST, killing off MAST :)
18:45 jnthn (Which is my eventual plan)
18:45 nine_ Updating a precomp file will be to write it to a temporary file and when that's finished moving it over the old file.
18:45 jnthn nine_: So yeah, seems reasonable
18:46 jnthn nine_: Is replacing a file "atomic enough" portably?
18:46 jnthn nine_: Or do you use a lock file to get an ordering?
18:46 jnthn (On the writes)
18:46 nine_ My first idea was to load the precomp file, generate a hash from its contents, loading the deps file, checking the generated hash against the stored hash in the .deps and if they don't match just try the whole thing again. But then, why bother when I have to implement loadbytecodebuffer anyway :)
18:47 jnthn :)
18:48 nine_ jnthn: I actually cannot imaginge replace being anything but atomic. I know rename() on POSIX is guaranteed to be and it's a standard technique for atomically replacing a file. And mandatory locking on Windows will probably prevent me from replacing while someone else is still reading anyway, won't it?
18:50 geekosaur rename is guaranteed but only works within the same filesystem. Windows with UNC paths likes to pretend it's all one filesystem, and it's Hardâ„¢ to guarantee atomicity across e.g. shared / network file systems
18:50 nine_ Oh, there's actually a MVM_cu_from_bytes, so it's only the high level OP that's still missing.
18:50 nine_ geekosaur: as the files will all be in the same directory, I guess we're safe
18:51 jnthn nine_: Yeah, I think ReplaceFile or so on Windows should be enough
18:51 jnthn I think I linked an SO thread yesterday with various discussion/reources
18:51 jnthn http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows if not :)
18:52 nine_ jnthn: oh, and once I've got this up and running, I can actually even think about precompiling the CompUnit::DependencySpecification.new(...) bits in the dependency information that I'm currently EVALing.
19:00 sno joined #p6dev
19:00 [TuxCM] joined #p6dev
19:06 nine_ jnthn: it seems like we don't even need ReplaceFile and that MoveFileEx as libuv uses for rename() on Windows is actually sufficient. The difference is that ReplaceFile keeps the file's meta data which as all files involved are generated automatically shouldn't matter anyway.
19:10 jnthn nine_: ah, ok
19:10 jnthn nine_: So then we should be good :)
19:12 pmichaud joined #p6dev
19:14 nine_ So it's just a matter of coding now :)
19:18 jnthn Famous last words... :)
19:34 hoelzro joined #p6dev
19:51 lizmat joined #p6dev
19:51 skids joined #p6dev
19:51 JimmyZ joined #p6dev
19:51 stmuk joined #p6dev
19:51 masak joined #p6dev
19:51 vendethiel joined #p6dev
19:51 psch joined #p6dev
19:51 tadzik joined #p6dev
19:51 sno joined #p6dev
19:51 cognominal joined #p6dev
19:51 Brock joined #p6dev
21:38 brrt joined #p6dev
22:12 skids joined #p6dev

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary