[01:46] .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] someone needs to invite yoleaux... [01:46] Seems so. [01:47] *** ilbot3 joined [03:17] *** cognominal joined [03:18] *** synopsebot6 joined [04:19] nqp: 5a65ffe | (David Warring)++ | examples/rubyish/rubyish.nqp: [04:19] nqp: [examples/rubyish] replace %*save-sym with %*inner-sym [04:19] nqp: [04:19] nqp: Minor tweak. Reads better and avoids updating the outer %*SYM; [04:19] nqp: review: https://github.com/perl6/nqp/commit/5a65ffe12e [04:19] nqp: e9f1bdd | (David Warring)++ | examples/rubyish/rubyish.nqp: [04:19] nqp: [examples/rubyish] add more comments [04:19] nqp: review: https://github.com/perl6/nqp/commit/e9f1bdd89d [04:21] *** geekosaur joined [05:52] *** sno joined [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] [Tux]: strange, I thought I copy-pasted that, apparently not :-( [07:10] [Tux]: fixed now [07:41] rakudo/nom: 28c2795 | lizmat++ | src/core/Num.pm: [07:41] rakudo/nom: Make Num.Rat 25% faster for e0 case [07:41] rakudo/nom: [07:41] rakudo/nom: By skipping a lot of initializations, at the expense of one extra [07:41] rakudo/nom: (fast) check for the slow path. [07:41] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/28c2795e80 [07:58] *** dalek joined [07:59] *** hoelzro joined [08:00] *** tomboy64 joined [08:01] *** geekosaur joined [08:03] *** RabidGravy joined [08:14] bloop [08:16] rakudo/nom: 8fb78d8 | lizmat++ | src/core/Num.pm: [08:16] rakudo/nom: Explicitely specify denominator [08:16] rakudo/nom: [08:16] rakudo/nom: Explicitely specifying an argument, even if it is the same as the [08:16] rakudo/nom: default, is about 2x as fast. [08:16] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8fb78d8d1c [10:58] rakudo/nom: 8197a00 | lizmat++ | src/core/Int.pm: [10:58] rakudo/nom: Use explicit OutOfRange exception [10:58] rakudo/nom: [10:58] rakudo/nom: What's good enough for digits, is good enough for base :-) [10:58] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8197a0089c [11:18] rakudo/nom: 495e03c | lizmat++ | src/core/Int.pm: [11:18] rakudo/nom: Make Int.base(2) almost 2x as fast [11:18] rakudo/nom: [11:18] rakudo/nom: By giving it a separate candidate [11:18] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/495e03cacd [11:27] *** TimToady joined [11:48] rakudo/nom: e4a1b56 | lizmat++ | src/core/Int.pm: [11:48] rakudo/nom: Make Int.polymod between 1.2x and 1.7x faster [11:48] rakudo/nom: [11:48] rakudo/nom: By providing separate loops for the lazy vs non-lazy list [11:48] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e4a1b568cb [12:33] rakudo/nom: feaf76d | lizmat++ | src/core/Int.pm: [12:33] rakudo/nom: Make infix:
(Int,Int) about 1.5x as fast [12:33] rakudo/nom: [12:33] rakudo/nom: By using a single ternary for the divided by 0 test [12:33] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/feaf76ddd9 [12:34] yay! [12:35] same should be possible for Num, right? [12:35] well, ok, you're just working through Int.pm, clearly [12:35] but still :) [12:36] either div or / used to be extremely high on the list of things eating up time in my particles benchmark [12:39] yeah, working on it :) [12:48] \o/ [12:49] of course, the 25x improvement in framerate won't be as easy as making those functions faster :) [12:50] lizmat: say, using Failure.new(...) and just returning that ... would that be the same as using "fail"? it *could* be faster, too [12:50] are you interested in trying that? [12:51] timotimo: aaah. good point :-) [12:51] I guess it would only make the fail faster, but yes [12:51] i'm still interested in figuring out a way to remove that zero-check when the RHS is a literal number [12:52] because that was a quite common case in my code [12:55] "foo div 0" a common case ? [12:55] no, foo div 2 [12:55] ack [12:57] 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] do we have a bitcount function? [12:59] if bitcount(a) == 1, then we can shift [13:01] oof, really not sure [13:03] Probably one to do in spesh [13:03] Generally, we want to do things in spesh that we can, because then we only pay for the optimizations on hot code [13:03] Whereas if they're in Perl6::Optimizer we pay for them wherever they are [13:04] So really we just want to do the higher-level things that spesh will have trouble figuring out. [13:04] at some point we may want to have value/range propagation and a "this is non-zero" proofs [13:13] rakudo/nom: ec6c3b8 | lizmat++ | src/core/Int.pm: [13:13] rakudo/nom: Don't need to fail if were already returning [13:13] rakudo/nom: [13:13] rakudo/nom: Not seeing any performance gain, but this should produce smaller [13:13] rakudo/nom: bytecode, no? [13:13] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ec6c3b89c5 [13:15] yeah, throws out a call, i think [13:15] can you measure failing over and over and over? [13:15] well, i guess you already have [14:18] *** skids joined [14:36] *** sortiz joined [15:29] *** skids joined [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] i only know that moving tags in git is really inconvenient for everyone downstream [15:33] hosting the latest tag somewhere seems good enough [15:34] i suppose we could also merge into a latest branch at every tag [15:34] and just pull that from rakudobrew [15:34] 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] or was it the other way round? :) [15:35] 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] 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] if you just want latest, use annotated tags and then git describe tells you the latest annotated tag [15:40] 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] changing tags is silly. branch is perfect. 'latest' kind of sounds like a development branch, but meh whatever you like [15:43] there's no reason it has to be as complicated as git-flow / more complicated than tagging [15:43] 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] 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] a quick google suggests moving git tags is complicated [15:44] tags are not what you want for this for sure. [15:44] also, from a git client perspective, you can pretty much use a branch name anywhere you could use a tag [15:44] so there's no desire from that end for it to be a tag [15:45] `git checkout 2016.05; git push upstream latest` is pretty easy. [16:21] tags are names for commits. [16:21] branches are names for commits! [16:21] The only difference between them is that branches usually point to different commits over time while tags are static. [16:21] So if you want a "moving tag", you simply want a branch, because that's what they are. [16:27] 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] 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] especially fun fact when you're faced with an octopus merge >.> [17:03] 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 [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] [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] DefinitelyWorks™ [17:51] <[Coke]> *snrk* [17:52] 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] masak: argh, don't consonant the vowels dammit :P [18:37] more or less the reaction I expected :P [18:37] w [18:37] (no, I don't like that either) :) [18:38] 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] jnthn: I may have a lockless solution [18:42] uh-oh :) [18:44] git check-ref-format likes DefinitelyWorks™ :p [18:44] 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] [Coke]: Looks like. [18:45] <[Coke]> jnthn: closed, thanks. [18:45] nine_: We'll want something like that anyway for producing bytecode from MAST :) [18:45] nine_: Or even directly from QAST, killing off MAST :) [18:45] (Which is my eventual plan) [18:45] 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] nine_: So yeah, seems reasonable [18:46] nine_: Is replacing a file "atomic enough" portably? [18:46] nine_: Or do you use a lock file to get an ordering? [18:46] (On the writes) [18:46] 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] :) [18:48] 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] 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] Oh, there's actually a MVM_cu_from_bytes, so it's only the high level OP that's still missing. [18:50] geekosaur: as the files will all be in the same directory, I guess we're safe [18:51] nine_: Yeah, I think ReplaceFile or so on Windows should be enough [18:51] I think I linked an SO thread yesterday with various discussion/reources [18:51] http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows if not :) [18:52] 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 [19:00] *** [TuxCM] joined [19:06] 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] nine_: ah, ok [19:10] nine_: So then we should be good :) [19:12] *** pmichaud joined [19:14] So it's just a matter of coding now :) [19:18] Famous last words... :) [19:34] *** hoelzro joined [19:51] *** lizmat joined [19:51] *** skids joined [19:51] *** JimmyZ joined [19:51] *** stmuk joined [19:51] *** masak joined [19:51] *** vendethiel joined [19:51] *** psch joined [19:51] *** tadzik joined [19:51] *** sno joined [19:51] *** cognominal joined [19:51] *** Brock joined [21:38] *** brrt joined [22:12] *** skids joined