Parrot 5.0.0 "Johnny Five Alive" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 23 January 2013.
00:10 Eddward joined
Coke wonders how that ASSERT was missing. 00:14
(since we didn't modify that file, I didn't think) 00:15
00:25 kid51 joined 00:29 Reini joined
Reini yes, strange 00:35
Coke Thanks for catching it, though. 00:55
00:59 kid51_ joined 01:30 dduncan joined 01:31 dduncan left 01:33 jlaire joined 01:54 kid51 joined
kid51 conducts his first smolder on the mighty sixparrot branch 01:55
01:58 uvtc joined
uvtc Dunno what I was thinking before; moved those Rakudo-SixParrot build instructions to the wiki wiki.perl6.org/Rakudo-Parrot . 02:03
dalek rrot/sixparrot: 0453c33 | jkeenan++ | t/steps/init/hints/darwin-01.t:
Update steps test to reflect revised Darwin hints.
 02:13
kid51 Some 'make fulltest' test failures in the sixparrot branch. 02:15
Should t/examples/pgegrep.t be removed entirely? (It failed all its tests.) 02:16
02:22 atrodo_ joined 02:23 atrodo joined
dalek rrot/sixparrot: 3061c23 | jkeenan++ | t/examples/tutorial.t:
Compensate for deletion of actual code examples from
 02:32
rrot/sixparrot: cff6094 | jkeenan++ | t/steps/init/hints/darwin-01.t:
Merge branch 'sixparrot' of git@github.com:parrot/parrot into sixparrot
02:35 kid51_ joined
kid51_ sixparrot branch: t/examples/shootout.t failing one test 02:37
not ok 10 - examples/shootout/nsieve.pir
# Method 'fill' not found for invocant of class 'FixedIntegerArray' 02:38
# current instr.: 'primes_in_range' pc 11
So we have two t/examples failures in the sixparrot branch, but I suspect they're easily fixed 02:40
(but not by me)
03:03 bluescreen joined 03:57 Reini joined 04:50 preflex_ joined 04:52 Reini joined 05:01 Reini joined 06:07 uvtc left 06:26 xcombelle joined 06:38 zby_home joined 07:09 Mike-PerlRecruiter_ joined 11:26 kid51_ joined 12:25 xcombelle joined 13:30 zby_home joined 14:05 PacoAir joined 14:08 PacoAir joined 14:10 zby_home_ joined 14:12 benabik joined 14:13 bluescreen joined 14:19 zby_home joined 14:25 Psyche^ joined 15:24 jsut joined 15:32 dmalcolm joined 15:36 benabik joined 16:43 Reini joined 16:58 benabik joined 17:01 Reini joined
rurban The current BSD mag hosts an explanation to setup a SIMH VAX simulator! simh.trailing-edge.com/ 17:20
bsdmag.org/magazine/1830-rehosting-in-netbsd
Coke huh. 17:21
rurban With the VAX/VMS OS under this HP approved license www.openvmshobbyist.com/news.php 17:22
17:51 PacoAir joined 18:01 PacoAir joined
atrodo Yay. I think I've got nci ripped out 18:25
moritz wow, nqp uses the Undef pmc 18:27
18:44 PacoAir joined 18:48 contingencyplan joined
pmichaud after dealing with ops2c discussions on #parrot and parrot-dev, I'd like to invoke some form of the relationship manager rule on the issue for a bit. 18:49
my position is that I'd really prefer ops2c to be written in p5. 18:50
I'm willing to accept that it be written in nqp.
cotto pmichaud: I feel the same way.
benabik Don't break the toolchain by changing your tools? 18:51
pmichaud I absolutely do not want Rakudo to be a requirement for creating or modifying ops in nqp or rakudo.
cotto modern nqp would be an acceptable second place, but I'd rather have Parrot build on its own with things that can be reasonably expected to live on a random machine.
atrodo That just seems like a bad idea. Like requiring parrot to change parrot's ops
benabik p5 > nqp >> rakudo?
cotto benabik: pretty much
pmichaud any further discussion on the issue with me I want to come from Parrot's relationship managers, whoever they end up being :-) 18:52
cotto The p5 ops2c was broken and stupid, but predictably so.
benabik Don't we distribute bootstrap ops? Or is the goal to kill that?
benabik wouldn't mind killing that, now that he thinks about it.
cotto benabik: ops2c is still needed for nqp and rakudo's ops
pmichaud: I'll weigh in on parrot-dev 18:53
benabik cotto: Was in reference to "building on its own". The bootstrap ops is how we manage that.
pmichaud cotto: thanks
18:55 not_gerd joined
not_gerd pmichaud, cotto: I apologize if my mail came across a bit too strong 18:56
18:56 donaldh joined
not_gerd I'm not trying to soure parrot/rakudo relationships - the goal would be driving Perl6 adoption 18:56
basically, the tools could be written in *any* language
so why not Perl6 - after all, it is supposed to be a general-purpose, eventually widely adopted programming language 18:57
(hopefully, that is)
but as I already mentioned, that decision is not up to me and I don't have anything riding in that game
I just thought it would be a fun project 18:58
cotto not_gerd: that's a good goal. I just disagree that using Rakudo to build Parrot right now is the best option.
18:58 benabik_ joined
moritz to run a program compiled by rakudo, you need the correct versions of parrot, nqp and rakudo's setting to run it 18:59
not_gerd if the scripts were written in python, you'd need python installed 19:00
moritz having three dependencies for bootstrapping the lowest level of the chain seems risky
not_gerd if they were written in perl6, you'd need perl6 installles
there are (otr should not) be any runtime dependencies
^or
benabik I think, all things being equal, P6 would be a lovely choice. It's just that it's not all equal.
moritz not_gerd: well, that would be fine, IF an installed parrot wouldn't interfere with building parrot 19:01
often enough, it does
and when you need to remove the installed parrot (and thus Perl 6) to be able to build parrot again, you can't bootstrap it 19:02
not_gerd ooc, what is the failure mode here - on cygwin, I mainly encouter picking up the installed libparrot.dll.a file, which is probably fixable 19:03
moritz not_gerd: this has been a point with parrot since I became interested in the project in 2006 or 2007. Dismissing it was "is probably fixable" doesn't really create confidence 19:05
benabik On OS X, generally you "just" load the installed library.
not_gerd benabik: so a similar issue
moritz just like performance has been a pain point for quite long 19:06
moritz stops here, before sliding off into unfair comparisons
Coke (uses Undef) it is very surprising to me what breaks when you pull at some of these strings. (not in a bad way, we had 'em, why not use them) 19:07
the Exporter PMC looks like a possible candidate, though it's got a test that requires it.
moritz anyway, if somebody could fix that, it would benefit parrot's developers and users, indepdently of which direction parrot takes in the end 19:08
19:08 Mike-PerlRecruiter_ joined
moritz Coke: the winxed compiler emits code that uses Exporter 19:08
Coke moritz: ah well. Danke.
cotto rurban: how many of your branches are worth keeping around? 19:09
moritz git grep 'new \\[.Exporter\\b'
allison not_gerd: I really don't understand why people are so addicted to generating ops 19:10
not_gerd: they'd be fine just written in C
rurban cotto: I already deleted all of my old branches
pmichaud allison: I looked at the C, it doesn't look like something I want to generate or maintain by hand.
allison not_gerd: possibly even better, because people would actually *look* at the C code, instead of sweeping all that complexity/performance loss under a dirty carpet 19:11
Coke allison: that's fine, but that's not this project.
cotto rurban: there's a bunch of them on github
allison pmichaud: well, yes, the generator is producing nasty C code, but that doesn't necessarily mean the C code has to be nasty
Coke if it's as easy to write an op in C as it is in Ops, ok.
allison Coke: ops are *mostly* C already 19:12
Coke Yes. only mostly.
:(
er, :)
rurban g br |grep rurban|wc -l => 20 yes
pmichaud allison: it's the tables and all of the variants I don't necessarily want to maintain.
cotto rurban: I see you're as lazy as I am about typing "it"
not_gerd allison: as long you keep the dynop system, you'll probably need some form of parsing/code generation 19:13
allison pmichaud: then maybe we shouldn't have the tables and all the variants
rurban alias g=git
git alias br=branch
pmichaud allison: fair enough, that sounds like a much more fundamental change than "port ops2c"
allison we're looking for things to simplify. Assuming that the ops are good as is, and that we need to port the entire op generation system to another language is probably not the simplest starting assumption.
rurban I had a cmd to list already fully merged branches... 19:14
cotto allison: that'd make the build even simpler. It'd be less work though to just resuccect ops2c.pl for the time being
allison cotto: assuming that the old ops2c.pl still works, yes
cotto yes, assuming that
allison cotto: it's been dead a long time, and I'm sure doesn't produce the same output as what we're getting currently 19:15
benabik rurban: git branch --merged ?
pmichaud from my perspective, I'm looking for things to simplify that increase performance and don't significantly increase maintenance/development costs for nqp and rakudo.
if someone says "we have to change dynops to increase performance" then I'm okay with that.
if they say "we have to change dynops because we don't like the build tools we have now", that's a big -1 from me.
allison pmichaud: agreed, the driving motivation must always be performance 19:16
Coke I see no problem switching back to the ole p5 version. I will try to get to that this weekend if no one beats me to it.
allison cotto: I'm totally okay with keeping the current ops generation code in place, even with its dependencies
Coke (insuring that the first version generates an identical C file)
not_gerd pmichaud: personally, I'd like to move more dynops to core so eventually, we'll get the lua experience
rurban well, ops2c requires nqp, which has a long build time
allison cotto: those are build-time dependencies, and aren't hurting runtime performance at all
Coke Yes. I am happy in sixparrot to move any dynops used by rakudo to core. 19:17
not_gerd simple build that results in a binary and a dll instead of *directories' full of stuff
allison rurban: build-time doesn't matter
pmichaud not_gerd: I'm more concerned about the dynops that nqp and rakudo have. Those aren't likely to all go to parrot core.
allison rurban: it's "free" as far as we're concerned
rurban I also had trouble to implement line directives in the nqp variant of ops2c but it was trivial in the perl5 pmc compiler
cotto istr those always being off 19:18
Coke well, all things being equal, faster build is better. but it's last on the list, sure.
atrodo I now hate nci more. It has it's little paws in too many pots 19:19
19:19 dduncan joined
benabik Merged branches: gh929_ffa_sort_bug, github-links, kill_current_object, mrshu/simple_sort_benchmark-gh175, relocatable-gh800, rurban/dynpmc-manifest-gh922, rurban/fh-strerr-gh911, rurban/nci_test-dupldecl-gh897, rurban/sanitycheck_install-gh910, rurban/threaded-say-gh893, vms-usize_t-gh854, whiteknight/io_cleanup1 19:20
rurban I am just cleanup up left overs from me also
not_gerd pmichaud: if it were up to me, I'd argue that *all* NQP dynops should become parrot ones - ie parrot eventually becomes /nqp/backend/parrot
but that's a long way off, if even desired by the powers-that-be 19:21
benabik would like many nqp ops to be parrot ops, but that's because he prefers 6model as an object system. 19:22
allison not_gerd/benabik: sixparrot's purpose is to serve nqp/rakudo, so I'm in favor of moving anything into it that will improve performance or reduce the maintenance burden on Rakudo folks 19:23
Coke Any thoughts on the calling conventions?
allison if moving all nqp/rakudo dynops into sixparrot means we can get rid of the dynops system entirely, I'd call it a win :) 19:24
Coke I know rurban has mentioned it recently, and it's been out there for a while as a potential bottleneck.
allison Coke: I looked at calling conventions earlier in the week
Coke: in general, we should strip them down to only what nqp/rakudo uses
pmichaud if we eliminate dynops entirely, without something reasonable to replace it, that's a loss.
from an nqp perspective, it's a big loss. 19:25
allison Coke: I was hoping they only used :call_sig
Coke pmichaud: right. don't want to have to rebuild parrot to add a new op.
allison Coke: cause that would make the whole system super-simple
pmichaud: there should certainly be a way to extend the VM, I'm just not chained to the idea that dynops are the best way 19:26
pmichaud allison: I suspect there aren't many places that need to be updated to use :call_sig everywhere (but I haven't looked)
not_gerd there
allison pmichaud: it was nqp where I found a lot of :slurpy, :flat, etc
pmichaud: and not one use of :call_sig anywhere in the stage* code
not_gerd someone should probably take another look at mls work
allison pmichaud: (that was nqp master)
pmichaud allison: looking. stage* code is generated code. 19:27
not_gerd he's one of the few people who actually did some profiling
allison pmichaud: so, could be regenerated, yeah
pmichaud: I'll just log that as a preference, to use :call_sig everywhere :)
pmichaud: it would hugely simplify dispatch 19:28
Coke: also, it looks like MMD can be ripped out entirely
Coke: especially all that expensive manhattan distance stuff
atrodo allison: I'm all for that. That code is a mess, and I only looked at it to remove nci 19:29
allison Coke: nqp doesn't use :multi at all 19:30
benabik istr that one of the big issues with call performance was the split of callcontext from continuation or something like that.
allison benabik: it might be possible to merge them, yes
benabik: reduce the memory pressure
not_gerd benabik: see lists.parrot.org/pipermail/parrot-d...07354.html
benabik not_gerd++ 19:31
pmichaud looks like only Rakudo uses a custom call convention via :call_sig; NQP uses Parrot's native calling convention stuff.
allison not_gerd: moving call contexts back to being C structs is not a good idea, because it makes them inaccessible to nqp/rakudo
not_gerd: but, making it so we only allocate *one* PMC for each call is a good one 19:32
pmichaud: that's what it looked like to me too
pmichaud: how onerous would it be if parrot's native calling convention stuff disappeared? 19:33
pmichaud depends on what it got replaced with, I suspect. :)
allison pmichaud: my debate there, honestly, is that in theory we can optimize at the parrot level currently
pmichaud: whereas, if we replace :slurpy and :flat and such with simple :call_sig, the complexity goes into the generated opcodes 19:34
pmichaud just a sec
rurban I've cleanup all my finished branches. thanks for the reminder 19:35
cotto rurban: thanks for the cleanup
19:39 xcombelle joined
benabik allison: Perhaps we could make contexts be C structs and only create PMCs when it needs to be poked at by in-VM? 19:45
pmichaud okay, did some checking. 19:46
moving NQP to use :call_sig everywhere is somewhat non-trivial (more)
allison benabik: the point is, to completely eliminate argument handling at the Parrot level
benabik: that gains us a whole lot more than doing all the argument handling in a C struct
pmichaud essentially, we end up moving the code for unpacking CallContexts from Parrot into NQP
allison pmichaud: yup 19:47
benabik Wouldn't that hurt even more performance-wise?
allison pmichaud: which I guess you're already doing in rakudo?
pmichaud Rakudo is able to work with :call_sig because every Code object has a Signature object attached to it. So the opcode knows where to look to find out how to unpack the arguments into the formal parameters. 19:48
allison pmichaud: can it be generated the same way in nqp?
pmichaud: well, the call signature object also has a signature attached to it
pmichaud allison: but that signature object doesn't think in terms of lexical parameter names or slots 19:49
allison benabik: it depends. what it does is limit the cost of really expensive features like :slurpy and :flat to locations where they're actually used
benabik: and makes cheap cases really, really cheap
pmichaud rakudo's signatures contain type information, lexical slot information, etc. in them. So, if we take a rakudo-approach then we'd have to add a lot of that stuff to NQP generated code, which is somewhat significant. 19:50
If we take a parrot-approach then we're just moving Parrot code to NQP.
allison pmichaud: so, really, what you're using the .params for is just to tell the call signature what the local names should be for those elements 19:51
pmichaud allison: .params in which case? NQP generates Parrot code objects just like PIR authors are expected to do so.
allison pmichaud: and maybe the answer is to keep the .params in PIR, but entirely change their purpose
pmichaud: by .params, I mean like ".param pmc _lex_param_0 :slurpy" 19:53
(from QAST-s0.pir)
pmichaud: which is currently handled by a lot of spendy C code 19:54
pmichaud: but could just as easily be syntactic sugar for "really, just dispatch by :call_sig, and when you get there, put all the arguments in _lex_param_0" 19:55
pmichaud what about cases where there's more than on .param argument? I mean, how does this speed things up or simplify things? 19:56
*than one
allison pmichaud: it accomplishes the same purpose, but doesn't change the syntax for you
pmichaud: because the current code for handling all that special dispatch stuff is very, very expensive 19:57
pmichaud I don't understand what makes it expensive, or how this avoids the expense.
allison pmichaud: certainly needs benchmarks to prove it
pmichaud (because I've never deeply investigated how parrot handles it call argument binding)
allison pmichaud: but, I'm confident enough that it will substantially improve things to be willing too do it on a branch just to compare
pmichaud: it's pretty sloppy in call argument binding 19:58
pmichaud: it's another one of those areas where we put in a "temporary" solution, that was never replaced by one that's reasonably good and reasonably performant
pmichaud okay. Short answer seems to be that it's non-trivial to get nqp to use a Rakudo-style :call_sig model as things stand now. 19:59
allison pmichaud: but assume for now that nqp can go on generating the same PIR code and will get the same behavior
pmichaud: yes, that that's a very helpful answer 20:00
pmichaud (which is a pity, because if we could do so we could eliminate a huge chunk of imcc ickiness.)
allison pmichaud: well, all I said is that you'll keep generating .params the same way in nqp
pmichaud if we had a good way to encode params in a manner that a custom op could then properly unpack the call sig, that could work too. 20:01
allison pmichaud: I didn't promise not to entirely change the actual VM operations that execute those .param statements :)
remember that .param isn't an actual op, it's a macro
pmichaud right (more) 20:02
allison so, replacing its behavior is more straightforward
pmichaud in rakudo, we use :call_sig, and then later we invoke a custom op that unpacks the call_sig
allison so, in theory, we might be able to use the same model at a deeper level 20:03
pmichaud right
another possibility, which might not be faster, would be to have something like: 20:04
.param pmc args :call_sig
allison probably just with some added info in the call sig object
pmichaud getarg args, "I", "$lex1" # fetch argument into $lex1
getarg args, "P", "$lex2" # fetch argument into $lex2
getslurpy args, "$lex3" # fetch all remaining args into $lex3
and the "I" and "P" could even be omitted, because the parameter type is encoded in the lexinfo struct 20:05
allison pmichaud: looks entirely possible 20:06
pmichaud it does turn call argument handling into a sequence of op dispatches instead of a single one, but each one would be fairly simple.
allison so, it's just a matter of comparing performance
pmichaud so I don't know how performance would end up being.
allison yes, it would be nice if it could be one call, but there's a balance between having several cheap calls and one expensive call 20:08
pmichaud well, the advantage of the multiple calls is that it's easy to determine the signature
because you don't need a vararg op
the signature ends up being encoded (and processed) as a sequence of opcodes 20:09
anyway, adjusting the PIR that nqp generates for parameter handling shouldn't be too difficult, if that turns out to be needed 20:10
20:10 donaldh joined 20:16 benabik joined
not_gerd bye, #parrot 20:19
20:19 not_gerd left 20:40 zby_home joined 21:08 donaldh joined 21:26 Reini joined 22:12 Reini joined 22:15 particle joined 22:27 Reini 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!