Camelia, the Perl 6 bug

IRC log for #parrot, 2013-02-15

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:10 Eddward joined #parrot
00:14 * Coke wonders how that ASSERT was missing.
00:15 Coke (since we didn't modify that file, I didn't think)
00:25 kid51 joined #parrot
00:29 Reini joined #parrot
00:35 Reini yes, strange
00:55 Coke Thanks for catching it, though.
00:59 kid51_ joined #parrot
01:30 dduncan joined #parrot
01:31 dduncan left #parrot
01:33 jlaire joined #parrot
01:54 kid51 joined #parrot
01:55 * kid51 conducts his first smolder on the mighty sixparrot branch
01:58 uvtc joined #parrot
02:03 uvtc Dunno what I was thinking before; moved those Rakudo-SixParrot build instructions to the wiki http://wiki.perl6.org/Rakudo-Parrot .
02:13 dalek parrot/sixparrot: 0453c33 | jkeenan++ | t/steps/init/hints/darwin-01.t:
02:13 dalek parrot/sixparrot: Update steps test to reflect revised Darwin hints.
02:13 dalek parrot/sixparrot: review: https://github.com/parrot/parrot/commit/0453c3340b
02:15 kid51 Some 'make fulltest' test failures in the sixparrot branch.
02:16 kid51 Should t/examples/pgegrep.t be removed entirely?  (It failed all its tests.)
02:22 atrodo_ joined #parrot
02:23 atrodo joined #parrot
02:32 dalek parrot/sixparrot: 3061c23 | jkeenan++ | t/examples/tutorial.t:
02:32 dalek parrot/sixparrot: Compensate for deletion of actual code examples from
02:32 dalek parrot/sixparrot: examples/tutorial/12_math_ops_pasm.pir.
02:32 dalek parrot/sixparrot: review: https://github.com/parrot/parrot/commit/3061c23fe0
02:32 dalek parrot/sixparrot: cff6094 | jkeenan++ | t/steps/init/hints/darwin-01.t:
02:32 dalek parrot/sixparrot: Merge branch 'sixparrot' of git@github.com:parrot/parrot into sixparrot
02:32 dalek parrot/sixparrot: review: https://github.com/parrot/parrot/commit/cff609473f
02:35 kid51_ joined #parrot
02:37 kid51_ sixparrot branch: t/examples/shootout.t failing one test
02:37 kid51_ not ok 10 - examples/shootout/nsieve.pir
02:38 kid51_ # Method 'fill' not found for invocant of class 'FixedIntegerArray'
02:38 kid51_ # current instr.: 'primes_in_range' pc 11
02:40 kid51_ So we have two t/examples failures in the sixparrot branch, but I suspect they're easily fixed
02:40 kid51_ (but not by me)
03:03 bluescreen joined #parrot
03:57 Reini joined #parrot
04:50 preflex_ joined #parrot
04:52 Reini joined #parrot
05:01 Reini joined #parrot
06:07 uvtc left #parrot
06:26 xcombelle joined #parrot
06:38 zby_home joined #parrot
07:09 Mike-PerlRecruiter_ joined #parrot
11:26 kid51_ joined #parrot
12:25 xcombelle joined #parrot
13:30 zby_home joined #parrot
14:05 PacoAir joined #parrot
14:08 PacoAir joined #parrot
14:10 zby_home_ joined #parrot
14:12 benabik joined #parrot
14:13 bluescreen joined #parrot
14:19 zby_home joined #parrot
14:25 Psyche^ joined #parrot
15:24 jsut joined #parrot
15:32 dmalcolm joined #parrot
15:36 benabik joined #parrot
16:43 Reini joined #parrot
16:58 benabik joined #parrot
17:01 Reini joined #parrot
17:20 rurban The current BSD mag hosts an explanation to setup a SIMH VAX simulator! http://simh.trailing-edge.com/
17:20 rurban http://bsdmag.org/magazine​/1830-rehosting-in-netbsd
17:21 Coke huh.
17:22 rurban With the VAX/VMS OS under this HP approved license http://www.openvmshobbyist.com/news.php
17:51 PacoAir joined #parrot
18:01 PacoAir joined #parrot
18:25 atrodo Yay. I think I've got nci ripped out
18:27 moritz wow, nqp uses the Undef pmc
18:44 PacoAir joined #parrot
18:48 contingencyplan joined #parrot
18:49 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:50 pmichaud my position is that I'd really prefer ops2c to be written in p5.
18:50 pmichaud I'm willing to accept that it be written in nqp.
18:50 cotto pmichaud: I feel the same way.
18:51 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.
18:51 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.
18:51 atrodo That just seems like a bad idea. Like requiring parrot to change parrot's ops
18:51 benabik p5 > nqp >> rakudo?
18:51 cotto benabik: pretty much
18:52 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.
18:52 benabik Don't we distribute bootstrap ops?  Or is the goal to kill that?
18:52 * benabik wouldn't mind killing that, now that he thinks about it.
18:52 cotto benabik: ops2c is still needed for nqp and rakudo's ops
18:53 cotto 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.
18:53 pmichaud cotto: thanks
18:55 not_gerd joined #parrot
18:56 not_gerd pmichaud, cotto: I apologize if my mail came across a bit too strong
18:56 donaldh joined #parrot
18:56 not_gerd I'm not trying to soure parrot/rakudo relationships - the goal would be driving Perl6 adoption
18:56 not_gerd basically, the tools could be written in *any* language
18:57 not_gerd so why not Perl6 - after all, it is supposed to be a general-purpose, eventually widely adopted programming language
18:57 not_gerd (hopefully, that is)
18:57 not_gerd but as I already mentioned, that decision is not up to me and I don't have anything riding in that game
18:58 not_gerd 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 #parrot
18:59 moritz to run a program compiled by rakudo, you need the correct versions of parrot, nqp and rakudo's setting to run it
19:00 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
19:00 not_gerd if they were written in perl6, you'd need perl6 installles
19:00 not_gerd there are (otr should not) be any runtime dependencies
19:00 not_gerd ^or
19:00 benabik I think, all things being equal, P6 would be a lovely choice.  It's just that it's not all equal.
19:01 moritz not_gerd: well, that would be fine, IF an installed parrot wouldn't interfere with building parrot
19:01 moritz often enough, it does
19:02 moritz 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:03 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:05 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.
19:05 not_gerd benabik: so a similar issue
19:06 moritz just like performance has been a pain point for quite long
19:06 * moritz stops here, before sliding off into unfair comparisons
19:07 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 Coke the Exporter PMC looks like a possible candidate, though it's got a test that requires it.
19:08 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 Mike-PerlRecruiter_ joined #parrot
19:08 moritz Coke: the winxed compiler emits code that uses Exporter
19:08 Coke moritz: ah well. Danke.
19:09 cotto rurban: how many of your branches are worth keeping around?
19:09 moritz git grep 'new \[.Exporter\b'
19:10 allison not_gerd: I really don't understand why people are so addicted to generating ops
19:10 allison not_gerd: they'd be fine just written in C
19:10 rurban cotto: I already deleted all of my old branches
19:10 pmichaud allison: I looked at the C, it doesn't look like something I want to generate or maintain by hand.
19:11 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.
19:11 cotto rurban: there's a bunch of them on github
19:11 allison pmichaud: well, yes, the generator is producing nasty C code, but that doesn't necessarily mean the C code has to be nasty
19:11 Coke if it's as easy to write an op in C as it is in Ops, ok.
19:12 allison Coke: ops are *mostly* C already
19:12 Coke Yes. only mostly.
19:12 Coke :(
19:12 Coke er, :)
19:12 rurban g br |grep rurban|wc -l => 20 yes
19:12 pmichaud allison: it's the tables and all of the variants I don't necessarily want to maintain.
19:12 cotto rurban: I see you're as lazy as I am about typing "it"
19:13 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
19:13 rurban alias g=git
19:13 rurban git alias br=branch
19:13 pmichaud allison: fair enough, that sounds like a much more fundamental change than "port ops2c"
19:13 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.
19:14 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
19:14 allison cotto: assuming that the old ops2c.pl still works, yes
19:14 cotto yes, assuming that
19:15 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 ?
19:15 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.
19:15 pmichaud if someone says "we have to change dynops to increase performance" then I'm okay with that.
19:15 pmichaud 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.
19:16 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.
19:16 allison cotto: I'm totally okay with keeping the current ops generation code in place, even with its dependencies
19:16 Coke (insuring that the first version generates an identical C file)
19:16 not_gerd pmichaud: personally, I'd like to move more dynops to core so eventually, we'll get the lua experience
19:16 rurban well, ops2c requires nqp, which has a long build time
19:16 allison cotto: those are build-time dependencies, and aren't hurting runtime performance at all
19:17 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
19:17 allison rurban: build-time doesn't matter
19:17 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.
19:17 allison rurban: it's "free" as far as we're concerned
19:17 rurban I also had trouble to implement line directives in the nqp variant of ops2c but it was trivial in the perl5 pmc compiler
19:18 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.
19:19 atrodo I now hate nci more. It has it's little paws in too many pots
19:19 dduncan joined #parrot
19:20 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
19:20 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
19:21 not_gerd but that's a long way off, if even desired by the powers-that-be
19:22 * benabik would like many nqp ops to be parrot ops, but that's because he prefers 6model as an object system.
19:23 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?
19:24 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.
19:24 allison Coke: I looked at calling conventions earlier in the week
19:24 allison Coke: in general, we should strip them down to only what nqp/rakudo uses
19:24 pmichaud if we eliminate dynops entirely, without something reasonable to replace it, that's a loss.
19:25 pmichaud from an nqp perspective, it's a big loss.
19:25 allison Coke: I was hoping they only used :call_sig
19:25 Coke pmichaud: right. don't want to have to rebuild parrot to add a new op.
19:25 allison Coke: cause that would make the whole system super-simple
19:26 allison 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)
19:26 not_gerd there
19:26 allison pmichaud: it was nqp where I found a lot of :slurpy, :flat, etc
19:26 allison pmichaud: and not one use of :call_sig anywhere in the stage* code
19:26 not_gerd someone should probably take another look at mls work
19:26 allison pmichaud: (that was nqp master)
19:27 pmichaud allison: looking.  stage* code is generated code.
19:27 not_gerd he's one of the few people who actually did some profiling
19:27 allison pmichaud: so, could be regenerated, yeah
19:27 allison pmichaud: I'll just log that as a preference, to use :call_sig everywhere :)
19:28 allison pmichaud: it would hugely simplify dispatch
19:28 allison Coke: also, it looks like MMD can be ripped out entirely
19:28 allison Coke: especially all that expensive manhattan distance stuff
19:29 atrodo allison: I'm all for that. That code is a mess, and I only looked at it to remove nci
19:30 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.
19:30 allison benabik: it might be possible to merge them, yes
19:30 allison benabik: reduce the memory pressure
19:30 not_gerd benabik: see http://lists.parrot.org/pipermail/p​arrot-dev/2013-February/007354.html
19:31 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.
19:31 allison not_gerd: moving call contexts back to being C structs is not a good idea, because it makes them inaccessible to nqp/rakudo
19:32 allison not_gerd: but, making it so we only allocate *one* PMC for each call is a good one
19:32 allison pmichaud: that's what it looked like to me too
19:33 allison 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.  :)
19:33 allison pmichaud: my debate there, honestly, is that in theory we can optimize at the parrot level currently
19:34 allison 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
19:35 rurban I've cleanup all my finished branches. thanks for the reminder
19:35 cotto rurban: thanks for the cleanup
19:39 xcombelle joined #parrot
19:45 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:46 pmichaud okay, did some checking.
19:46 pmichaud moving NQP to use :call_sig everywhere is somewhat non-trivial (more)
19:46 allison benabik: the point is, to completely eliminate argument handling at the Parrot level
19:46 allison benabik: that gains us a whole lot more than doing all the argument handling in a C struct
19:46 pmichaud essentially, we end up moving the code for unpacking CallContexts from Parrot into NQP
19:47 allison pmichaud: yup
19:47 benabik Wouldn't that hurt even more performance-wise?
19:47 allison pmichaud: which I guess you're already doing in rakudo?
19:48 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?
19:48 allison pmichaud: well, the call signature object also has a signature attached to it
19:49 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
19:49 allison benabik: and makes cheap cases really, really cheap
19:50 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 pmichaud If we take a parrot-approach then we're just moving Parrot code to NQP.
19:51 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.
19:51 allison pmichaud: and maybe the answer is to keep the .params in PIR, but entirely change their purpose
19:53 allison pmichaud: by .params, I mean like ".param pmc _lex_param_0 :slurpy"
19:53 allison (from QAST-s0.pir)
19:54 allison pmichaud: which is currently handled by a lot of spendy C code
19:55 allison 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:56 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 pmichaud *than one
19:56 allison pmichaud: it accomplishes the same purpose, but doesn't change the syntax for you
19:57 allison 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.
19:57 allison pmichaud: certainly needs benchmarks to prove it
19:57 pmichaud (because I've never deeply investigated how parrot handles it call argument binding)
19:57 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
19:58 allison pmichaud: it's pretty sloppy in call argument binding
19:58 allison 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
19:59 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
20:00 allison 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.)
20:00 allison pmichaud: well, all I said is that you'll keep generating .params the same way in nqp
20:01 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 :)
20:01 allison remember that .param isn't an actual op, it's a macro
20:02 pmichaud right (more)
20:02 allison so, replacing its behavior is more straightforward
20:02 pmichaud in rakudo, we use :call_sig, and then later we invoke a custom op that unpacks the call_sig
20:03 allison so, in theory, we might be able to use the same model at a deeper level
20:03 pmichaud right
20:04 pmichaud another possibility, which might not be faster, would be to have something like:
20:04 pmichaud .param pmc args :call_sig
20:04 allison probably just with some added info in the call sig object
20:04 pmichaud getarg args, "I", "$lex1"   # fetch argument into $lex1
20:04 pmichaud getarg args, "P", "$lex2"   # fetch argument into $lex2
20:04 pmichaud getslurpy args, "$lex3"   # fetch all remaining args into $lex3
20:05 pmichaud and the "I" and "P" could even be omitted, because the parameter type is encoded in the lexinfo struct
20:06 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.
20:06 allison so, it's just a matter of comparing performance
20:06 pmichaud so I don't know how performance would end up being.
20:08 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
20:08 pmichaud because you don't need a vararg op
20:09 pmichaud the signature ends up being encoded (and processed) as a sequence of opcodes
20:10 pmichaud anyway, adjusting the PIR that nqp generates for parameter handling shouldn't be too difficult, if that turns out to be needed
20:10 donaldh joined #parrot
20:16 benabik joined #parrot
20:19 not_gerd bye, #parrot
20:19 not_gerd left #parrot
20:40 zby_home joined #parrot
21:08 donaldh joined #parrot
21:26 Reini joined #parrot
22:12 Reini joined #parrot
22:15 particle joined #parrot
22:27 Reini joined #parrot

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

Parrot | source cross referenced