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...
sortiz Seems so.
01:47 ilbot3 joined 03:17 cognominal joined 03:18 synopsebot6 joined
dalek p: 5a65ffe | (David Warring)++ | examples/rubyish/rubyish.nqp:
[examples/rubyish] replace %*save-sym with %*inner-sym

Minor tweak. Reads better and avoids updating the outer %*SYM;		 04:19
p: e9f1bdd | (David Warring)++ | examples/rubyish/rubyish.nqp:
[examples/rubyish] add more comments
04:21 geekosaur joined 05:52 sno joined
[Tux] lizmat_, :( p6weekly.wordpress.com/2016/05/02/...-landings/ QA report: Brand is without t 06:12
This is Rakudo version 2016.04-82-gd065bad built on MoarVM version 2016.04 06:32
test 22.472
test-t 13.921
csv-parser 36.314
lizmat_ [Tux]: strange, I thought I copy-pasted that, apparently not :-( 07:10
lizmat [Tux]: fixed now
dalek kudo/nom: 28c2795 | lizmat++ | src/core/Num.pm:
Make Num.Rat 25% faster for e0 case

By skipping a lot of initializations, at the expense of one extra
  (fast) check for the slow path.		 07:41
07:58 dalek joined 07:59 hoelzro joined 08:00 tomboy64 joined 08:01 geekosaur joined 08:03 RabidGravy joined
RabidGravy bloop 08:14
dalek kudo/nom: 8fb78d8 | lizmat++ | src/core/Num.pm:
Explicitely specify denominator

Explicitely specifying an argument, even if it is the same as the default, is about 2x as fast.		 08:16
kudo/nom: 8197a00 | lizmat++ | src/core/Int.pm:
Use explicit OutOfRange exception

What's good enough for digits, is good enough for base :-)		 10:58
kudo/nom: 495e03c | lizmat++ | src/core/Int.pm:
Make Int.base(2) almost 2x as fast

By giving it a separate candidate		 11:18
11:27 TimToady joined
dalek kudo/nom: e4a1b56 | lizmat++ | src/core/Int.pm:
Make Int.polymod between 1.2x and 1.7x faster

By providing separate loops for the lazy vs non-lazy list		 11:48
kudo/nom: feaf76d | lizmat++ | src/core/Int.pm:
Make infix:<div/%>(Int,Int) about 1.5x as fast

By using a single ternary for the divided by 0 test		 12:33
timotimo yay! 12:34
same should be possible for Num, right? 12:35
well, ok, you're just working through Int.pm, clearly
but still :)
either div or / used to be extremely high on the list of things eating up time in my particles benchmark 12:36
lizmat yeah, working on it :) 12:39
timotimo \o/ 12:48
of course, the 25x improvement in framerate won't be as easy as making those functions faster :) 12:49
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?
lizmat timotimo: aaah. good point :-) 12:51
I guess it would only make the fail faster, but yes
timotimo i'm still interested in figuring out a way to remove that zero-check when the RHS is a literal number
because that was a quite common case in my code 12:52
lizmat "foo div 0" a common case ? 12:55
timotimo no, foo div 2
lizmat ack
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:57
lizmat do we have a bitcount function? 12:59
if bitcount(a) == 1, then we can shift
timotimo oof, really not sure 13:01
jnthn 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
Whereas if they're in Perl6::Optimizer we pay for them wherever they are
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
dalek kudo/nom: ec6c3b8 | lizmat++ | src/core/Int.pm:
Don't need to fail if were already returning

Not seeing any performance gain, but this should produce smaller bytecode, no?		 13:13
timotimo yeah, throws out a call, i think 13:15
can you measure failing over and over and over?
well, i guess you already have
14:18 skids joined 14:36 sortiz joined 15:29 skids joined
[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
asking here, since it's a git question.
Alternatively, we could make rakudo.org/downloads/rakudo/tag return a text file with "2016.04" in it or something. 15:31
psch i only know that moving tags in git is really inconvenient for everyone downstream 15:32
hosting the latest tag somewhere seems good enough 15:33
i suppose we could also merge into a latest branch at every tag 15:34
and just pull that from rakudobrew
stmuk I thought the idea was two branches with existing "nom" becoming a dev branch and a new master becoming a stable (release) branch
or was it the other way round? :)
psch yeah, that's what i mean, except i called master "latest" 15:35
[Coke] you want to build rakudobrew from tags, not from a branch-latest. 15:37
unless we're embracing gitflow, which I don't think was on the agenda.
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?
geekosaur if you just want latest, use annotated tags and then git describe tells you the latest annotated tag 15:39
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.
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
er, latest released.
teatime changing tags is silly. branch is perfect. 'latest' kind of sounds like a development branch, but meh whatever you like 15:42
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
[Coke] git flow is not that complicated.
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
stmuk a quick google suggests moving git tags is complicated 15:44
teatime tags are not what you want for this for sure.
also, from a git client perspective, you can pretty much use a branch name anywhere you could use a tag
so there's no desire from that end for it to be a tag
`git checkout 2016.05; git push upstream latest` is pretty easy. 15:45
nine_ tags are names for commits. 16:21
branches are names for commits!
The only difference between them is that branches usually point to different commits over time while tags are static.
So if you want a "moving tag", you simply want a branch, because that's what they are.
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:27
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:29
geekosaur especially fun fact when you're faced with an octopus merge >.> 16:30
RabidGravy I think we should all go back to using rcs and patch 17:03
[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
17:06 lizmat joined
[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:09
perlpilot [Coke]: Having a branch called "latest" that isn't "the latest tagged release" seems weird. 17:40
[Coke] perlpilot: it's the "latest version of development that passed tests" 17:51
I'm fine to bikeshed the name.
timotimo DefinitelyWorks™
[Coke] *snrk*
timotimo i'm not sure ™ is actually allowed, but it'd be a good candidate if it did 17:52
[Coke] I used cyrillic in tags a few times, nothing exploded. 17:53
er, unicode. once was cyrillic. 17:54
masak .oO( оисе is cyrillic ) 18:24
jnthn masak: argh, don't consonant the vowels dammit :P 18:36
masak more or less the reaction I expected :P 18:37
geekosaur w
masak (no, I don't like that either) :)
jnthn The sign at that oelrepublican place in Goteborg drove me nuts for that :P 18:38
[Coke] rt.perl.org/Ticket/Display.html?id=126873 looks closable, yes? 18:40
nine_ jnthn: I may have a lockless solution 18:41
jnthn uh-oh :) 18:42
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
jnthn [Coke]: Looks like.
[Coke] jnthn: closed, thanks. 18:45
jnthn nine_: We'll want something like that anyway for producing bytecode from MAST :)
nine_: Or even directly from QAST, killing off MAST :)
(Which is my eventual plan)
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.
jnthn nine_: So yeah, seems reasonable
nine_: Is replacing a file "atomic enough" portably? 18:46
nine_: Or do you use a lock file to get an ordering?
(On the writes)
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 :)
jnthn :) 18:47
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:48
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.
geekosaur: as the files will all be in the same directory, I guess we're safe
jnthn 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
stackoverflow.com/questions/167414/...on-windows if not :)
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. 18:52
19:00 sno joined, [TuxCM] joined
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:06
jnthn nine_: ah, ok 19:10
nine_: So then we should be good :)
19:12 pmichaud joined
nine_ So it's just a matter of coding now :) 19:14
jnthn Famous last words... :) 19:18
19:34 hoelzro joined 19:51 lizmat joined, skids joined, JimmyZ joined, stmuk joined, masak joined, vendethiel joined, psch joined, tadzik joined, sno joined, cognominal joined, Brock joined 21:38 brrt joined 22:12 skids joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!