00:59 FROGGS_ joined 02:00 FROGGS__ joined 02:11 vendethiel joined 04:14 colomon joined 05:38 ggoebel2 joined 06:28 d4l3k_ joined 06:59 brrt joined 07:06 FROGGS joined 08:31 kjs_ joined 08:33 daxim joined 09:02 kjs_ joined 10:19 brrt left 11:13 colomon joined 12:32 lue joined 12:50 cognome joined
jnthn evening, #moarvm 13:41
timotimo hello jnthn!
FROGGS hello jnthn! 13:43
13:44 cognome joined
timotimo jnthn: did you comment on brrt's idea on making calling/frame allocation "optimistic by default"? 13:45
jnthn "Too soon" is my gut feeling on that 13:46
I think we should not consider it until after getting rid of the current remaining pesky inline bug(s?), and figuring out how escape analysis will be.
timotimo OK 13:47
i just had no intuition on how big the impact would be and how much effort it'd take to implement
jnthn Mostly I'm just wanting to make sure we take care of stability along with performance. 13:48
nwc10 jnthn++
PerlJam in the profiler output for routines, does "entries" mean how many times it was called?
jnthn PerlJam: Yes, with a caveat.
nwc10 stability matters
jnthn PerlJam: Well, 2. First off, it includes calls that were inlined (but I think it tells you the percentage there) 13:49
PerlJam: Second, continuations being taken count as stack frames being left, and continuations being invoked count as stack frames being re-entered. 13:50
PerlJam: This means the timings are accurate (good), but may distort the counts (less bad than bogus timing data).
PerlJam ok 13:51
jnthn Anyway, I've seen a few too many SIGSEGV and malloc errors for my liking of late, and I'm keen for us to squelch those.
It's maybe not as fun as performance work, but "does everything fast, including segfault" isn't really a reputation I want. :) 13:53
PerlJam jnthn++ indeed
nwc10 me too (to see them squelched), although I'm not really sure I'm part of the "we" which will do the hard work to acchieve this
nah.
not a great repuation 13:54
timotimo i'm way too short-sighted to consider stability over performance. i'm a bad, bad engineer :) 13:55
nwc10 performance gives you enough marketing to attract folks to try it out 13:56
lack of stability kills your ability to retain them 13:57
PerlJam timotimo: Are you a parrot contributor?
nwc10 ultimately what matters is having an ecosystem
PerlJam ducks
nwc10 and you only get that by growinging it over time
meaning that you need to retain enough users that they build re-usable stuff
timotimo i didn't realize parrot was more performant than it was stable ...
nwc10 chromatic did a fantastic job of fixing instabilities 13:58
PerlJam timotimo: it probably isn't, but that's the type of design decision that led it to where it is today IMHO
nwc10 no-one ever thanked him enough for that
jnthn I don't think instability was really Parrot's issue
Or at least, there were far more significant ones. 13:59
nwc10: Yes, that's probably the main reason why stability was better than many other aspects. 14:00
FROGGS our current problems are certainly not Parrot's faults
I have no proof of any regression caused by upgrading parrot
though we might discover bugs that exist for years now that we fiddle with rakudo's guts moar and moar 14:01
jnthn FROGGS: I don't think anybody was suggesting they were. 14:03
timotimo hmm 14:04
jnthn Anyway, my point was that performance isn't the only goal we should be keeping in mind. :)
FROGGS just wanted to state that parrot is actually pretty stable...
jnthn: that's why I try to unbreak stuff from time to time :o) 14:05
jnthn FROGGS: Yes, which I appreciate. :-)
FROGGS :o)
jnthn FROGGS: Though at some point we may want to try and figure out how much of our userbase uses each backend. 14:06
FROGGS somehow fears that moment... 14:07
but I can't explain why
PerlJam perhaps the fear stems from just identifying the userbase? :) 14:09
FROGGS *g*
[Coke] ponders porting GD to p6 via nativecall. 14:36
"ok, we have 5 people using parrot, and 20 using moar."
"also, I may have rounded up slightly" 14:37
timotimo %) 14:44
don't we have a gd nativecall module on the ecosystem already?
if so, you can probably get a jump start with that
[Coke] that's nice! now to pick a bigger one and see if that magically appears! 14:48
FROGGS :P 14:50
timotimo :D
[Coke] S26 has sample pod6 that is rendered as: 14:51
B<=begin pod>
Compiling lib/NativeCall.pm6 to mbc 14:53
===SORRY!===
No registered operation handler for 'nativecallglobal'
build stage failed for NativeCall: Failed building lib/NativeCall.pm6
^^ panda install GD pulls in nativecall which dies.
timotimo yeah, too new nativecall for not new enough rakudo
[Coke] roger.
FROGGS [Coke]: you can checkout 2014.08 in zavolaj 14:55
[Coke] using panda? 14:57
FROGGS no :/
14:59 brrt joined 15:35 kjs_ joined
japhb FROGGS: Weren't you working on versioning support in Panda some time ago? Or am I dreaming that? 15:49
jnthn: Two thumbs way up for a stability push. The performance improvements have been enough that right now my biggest blocker to evangelism is crashes (from both r-m and r-j) when doing threading/async stuff. I don't want Rakudo to get a black eye on what I consider one of its strongest selling points. But I also don't have a background debugging threading in a VM .... :-/ 15:53
jnthn japhb: Much of what's needed for such debugging is a good bit of patience and persistence...and thus it needs a lot of free and undisturbed time. 15:55
japhb: Which I've not really had much of recenlty. 15:56
japhb Nodnod, totally understood. $day_job and all that. Me too. 15:57
15:57 FROGGS joined
jnthn Yeah. But I'm a copule of working days of being finished with the current very-energy-consuming assignment :) 15:58
*off
timotimo sounds good :) 15:59
jnthn: would we ever end up inlining something like the argument to a map call into the map routine's body? 16:00
in spesh, i mean
jnthn timotimo: map doesn't do anything really
timotimo: It makes a MapIter and returns it 16:01
So that's not where you'd end up inlining.
At the moment spesh can't do a whole lot with map, sadly.
Inlinability will, I magine, be once of the design forces on the GLR we discuss in Salzburg :)
timotimo that'd be pretty cool 16:02
jnthn *imagine, *one
japhb When are you meeting in Salzburg? 16:21
(Happy to hear energy-consuming assignment is nearing the end. Hope it was a great success. :-) 16:22
nwc10 japhb: act.useperl.at/apw2014/schedule?day=2014-10-12 and act.useperl.at/apw2014/schedule?day=2014-10-13 16:25
FROGGS japhb: correct, which is still in a branch and/or on my disk 16:29
japhb Does no good sitting there on your disk! :-)
FROGGS japhb: I can already fetch stuff from cpan and/or github with my version of panda, there is just a small issue: 16:30
it does not work on windows, and it does not work on 32bit machines
japhb nwc10: Thanks
FROGGS because it needs like ten more dependencies like gzip support and HTTP::UserAgent, and these are not yet portable 16:31
[Coke] ufo is segfaulting
japhb HTTP::UserAgent isn't portable? That seems like an odd thing to be platform-dependent
Oh, because of SSL?
FROGGS for example, yes 16:32
japhb hmmm
FROGGS so... to fix all these things we have to get NativeCall wokring reliable on x86, and we may need pure Perl 6 version of gzip
[Coke] opens a ufo ticket.
japhb adds to his resource wishlist: 32-bit VMs for those who no longer have access to earlier hardware 16:34
FROGGS japhb: when I think about it... Compress::Zlib might be the only blocker right now 16:35
japhb: virtual machines also do 16:36
japhb Who owns that one?
"virtual machines also do"?
FROGGS hmm? 16:38
I wanted to say that you don't need a 32bit hardware when you can have a virtualbox
[Coke] any idea where to find "load_ext" under $*VM these days? 16:43
[Coke] has a horrible idea: 16:44
r: say $*VM.config<load_ext>
camelia rakudo-moar 85c4c0: OUTPUTĀ«(Any)ā¤Ā» 16:45
..rakudo-parrot 85c4c0: OUTPUTĀ«(timeout)Ā»
..rakudo-jvm 85c4c0: OUTPUTĀ«Can't call method "syswrite" on an undefined value at /home/p6eval/jvm-rakudo/eval-client.pl line 32.ā¤Ā»
[Coke] does that work under parrot?
FROGGS what is load_ext meant to be?
moritz .so vs .dll, iirc
FROGGS m: say $*VM.precomp-ext 16:46
camelia rakudo-moar 85c4c0: OUTPUTĀ«moarvmā¤Ā»
FROGGS in case it is this...
for dll extension I'd look at NativeCall
[Coke] ... oh. yah, nativecall makes this obsolete now, I think. thanks. 16:47
FROGGS Bitte :o) 16:48
[Coke] FROGGS++
yay, GD fixed. 16:54
looks like someone else submitted a patch for one of the issues back on Jun 10 16:55
we should probably change the modules version to point elsewhere, I guess.
or talk it about it, anyway 16:56
... also, this was probably all meant for #perl6
16:59 vendethiel joined
FROGGS [Coke]: yes, I've got two other PR's open for mrhdias 17:04
17:10 colomon joined 17:52 colomon joined
[Coke] Do we have a cabal that can rule on "do we take a fork as the main repo in modules" ? 18:11
japhb [Coke]: Didn't TimToady have some rules he wanted to follow regarding setting default auth[or[ity]?]? 18:12
timotimo [Coke]: everyone with access to the perl6/ecosystem repository can do that 18:18
japhb timotimo: If I'm reading his question correctly, it was more of a "What's the Right Thing in terms of community practice?" rather than "Who has ACL permissions to make the change?" 18:20
timotimo oh 18:21
18:39 FROGGS_ joined
[Coke] japhb++ yes. 18:56
I would say no response on an ecosystem module since June == "ok to point to a fork."
FROGGS +1 19:06
[Coke]: I've opened two PR on 27th February 19:07
github.com/mrhdias/perl6-IUP/pulls and github.com/mrhdias/perl6-Imlib2/pulls
19:58 Ven joined 19:59 colomon joined 20:14 njmurphy joined 21:16 Ven joined
dalek arVM: 2949416 | (Geoffrey Broadwell)++ | docs/moar.pod:
Another typo fix
 22:47
23:38 nebuchadnezzar 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!