Camelia, the Perl 6 bug

IRC log for #parrot, 2013-02-19

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 Coke I could branch, sure, but means there's a discontinuity when this goes in.
00:02 cotto Ah.  You're looking for a way to make a smooth transition, not thinking of pasm -> pir as a long-term thing.
00:02 Coke right. it would just hang around long enough to smooth things over.
00:03 cotto +1 and thank you, then
00:15 bluescreen joined #parrot
00:17 Coke cotto: https://gist.github.com/coke/4981953 ?
00:19 cotto Coke: I guess that'll work.  Just make sure and document why it's being done.
00:19 Coke ah. it won't, because that's already not a char*. :)
00:19 Coke ah well, enough of that for one day.
00:20 cotto I'm a little bit relieved.
00:20 dalek parrot/coke/rm_pasm: 5c443cd | coke++ | config/gen/makefiles/root.in:
00:20 dalek parrot/coke/rm_pasm: another merge fix.
00:20 dalek parrot/coke/rm_pasm: review: https://github.com/parrot/parrot/commit/5c443cdbe3
00:20 Coke ok, I'm all pushed.
00:29 Coke (doesn't fix the nqp issue)
01:07 woosley joined #parrot
01:59 dmalcolm joined #parrot
02:01 benabik alt.parrot.pasm.die.die.die
02:03 cotto I love that group.  I wish it existed.
02:04 benabik "Your ideas are intriguing to me, and I wish to subscribe to your newsletter."
02:23 davidfetter joined #parrot
03:07 preflex joined #parrot
03:25 bonsaikitten dukeleto: http://bpaste.net/show/78223/ that's the strace part around perldoc detection
03:56 Util "Zombie Parrot" wins, by popular acclaim!
04:46 preflex_ joined #parrot
05:19 bonsaikitten joined #parrot
05:19 sri joined #parrot
06:23 dukeleto Util++
06:24 dukeleto bonsaikitten: either that is not enough of the output and/or you will need -f to show the syscalls of forked processes
06:27 bonsaikitten dukeleto: let me try to add that
06:34 cotto a whole mess of opsc tests are failing and yaml_tiny, but that seems to be all
06:34 cotto and ops2c is generating more write barriers than it should for some ops
06:42 bonsaikitten dukeleto: there's one thing in that output that is very unexpected - "[pid 32737] open("/tmp/RKtKliMts8", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)"
06:42 bonsaikitten dukeleto: looks like perldoc can't access the temp file that the parent process created (want the whole log pasted?)
06:48 dukeleto bonsaikitten: sure
06:49 dukeleto bonsaikitten: are you using some kind of SE/Linux variant that has additional security ACLs?
06:49 bonsaikitten dukeleto: no. pretty boring chroot on amd64-linux
06:55 cotto Let's do a #ps tomorrow at the usual time of 1930 UTC (1130 PST).  The crickets and I will be there if nobody else is.
07:06 Mike-PerlRecruiter_ joined #parrot
07:06 cotto and now parrot-dev knows
07:14 bonsaikitten dukeleto: http://gentooexperimental.or​g/~patrick/perl-logfile.zip sorry for the delay, was a bit tricky to upload. 25MB uncompressed.
07:46 bouncy joined #parrot
08:36 dalek parrot/ops2c-necromancy: 4d361e8 | cotto++ | src/dynoplibs/Rules.in:
08:36 dalek parrot/ops2c-necromancy: [ops2c] ops2c is already quiet and doesn't need --quiet
08:36 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/4d361e8f34
08:37 dalek parrot/ops2c-necromancy: 244d6d1 | cotto++ | / (3 files):
08:37 dalek parrot/ops2c-necromancy: [ops2c] various fixes for symbol visibility and constants translation
08:37 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/244d6d178c
08:37 dalek parrot/ops2c-necromancy: 0bbd2dc | cotto++ | lib/Parrot/OpsFile.pm:
08:37 dalek parrot/ops2c-necromancy: [ops2c] clean up/fix write barrier generation
08:37 dalek parrot/ops2c-necromancy:
08:37 dalek parrot/ops2c-necromancy: The generated core_ops.c now doesn't seem to contain any subtantial
08:37 dalek parrot/ops2c-necromancy: differences from what's in git and all non-opsc tests pass with the
08:37 dalek parrot/ops2c-necromancy: exception t/library/yaml_tiny.t.
08:37 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/0bbd2dc7b0
08:37 dalek parrot/ops2c-necromancy: fee5554 | cotto++ | config/gen/makefiles/root.in:
08:37 dalek parrot/ops2c-necromancy: [ops2c] bring back the makefile rules for ops2c's generated files
08:37 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/fee5554092
10:00 xcombelle joined #parrot
11:01 tadzik cotto++ # blog post
11:02 tadzik "Parrot’s best bet is to focus exclusively on supporting Rakudo and give it a reason to stick around" nails it, imo
12:27 he__ joined #parrot
13:45 benabik joined #parrot
14:10 PacoAir joined #parrot
14:15 PacoAir joined #parrot
14:21 Psyche^ joined #parrot
14:21 bluescreen joined #parrot
14:27 benabik joined #parrot
14:49 benabik joined #parrot
14:51 benabik_ joined #parrot
14:58 JimmyZ joined #parrot
15:09 bluescreen joined #parrot
15:27 contingencyplan joined #parrot
15:34 dmalcolm joined #parrot
15:35 benabik joined #parrot
15:56 rurban ctult: lua, cola, potion and io and most lisps are reasonable fast vm's, targetting native systems, not JS/CLR/.NET. Reasonable fast vm's for JS/CLR/.NET are JS/CLR/.NET
15:56 rurban oh, he's gone
15:58 mtk joined #parrot
16:35 cotto ~~
16:48 dukeleto ~~
16:49 davidfetter joined #parrot
16:52 dalek parrot/ops2c-necromancy: ca04662 | cotto++ | / (32 files):
16:52 dalek parrot/ops2c-necromancy: [op2c] remove nqp-based opsc
16:52 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/ca04662106
16:52 dalek parrot/ops2c-necromancy: 5b4836f | cotto++ | / (3 files):
16:52 dalek parrot/ops2c-necromancy: [ops2c] remove the generated core ops files from git
16:52 dalek parrot/ops2c-necromancy:
16:52 dalek parrot/ops2c-necromancy: They were originally checked in so that Parrot could bootstrap itself.
16:52 dalek parrot/ops2c-necromancy: Since they're now back to being generated by p5, keeping them in git
16:52 dalek parrot/ops2c-necromancy: isn't necessary.
16:52 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/5b4836f678
16:53 cotto dukeleto: if you've got some tuits, t/library/yaml_tiny.t is failing in that branch.
16:55 cotto or you can see how the it does with nqp.  I haven't done anything wrt testing that yet.
16:56 Coke is yaml_tiny going to survive sixparrot? if not, may not be worth fixing.
16:56 cotto Coke: excellent question.
16:56 Coke I think most of the runtime libs are unused by nqp/rakudo - if it's not used internally, may not be worth it.
16:56 cotto When the test dies it complains about not being able to find nqp-setting.pbc, so it doesn't seem like a yaml-specific failure
16:57 cotto I'm more concerned that there's an underlying bug that that test just happens to expose.
17:01 Coke ah.
17:27 dalek parrot/ops2c-necromancy: 5350d2d | cotto++ | MANIFEST:
17:27 dalek parrot/ops2c-necromancy: [ops2c] update MANIFEST
17:27 dalek parrot/ops2c-necromancy: review: https://github.com/parrot/parrot/commit/5350d2d3d4
17:38 dalek nqp/target-pbc: 679cac2 | (Gerhard R)++ | src/HLL/Compiler.pm:
17:38 dalek nqp/target-pbc: Migrate to new PackfileView API
17:38 dalek nqp/target-pbc: review: https://github.com/perl6/nqp/commit/679cac29b2
17:38 dalek nqp/target-pbc: b7d0122 | (Gerhard R)++ | src/NQP/World.pm:
17:38 dalek nqp/target-pbc: Rename $main to $mainline to avoid confusion
17:38 dalek nqp/target-pbc: review: https://github.com/perl6/nqp/commit/b7d0122e8c
17:39 cotto not_gerd++
17:56 not_gerd joined #parrot
17:56 not_gerd o/
17:56 not_gerd I believe I've now taken care of everything pmichaud complained about
17:57 not_gerd if he's fine with merging into NQP/Rakudo, the Eval PMC is ready to die
17:57 cotto nice
17:58 not_gerd hopefully, it won't take another 10 months
17:59 not_gerd just to be sure: I can just allocate PMCs in C and the GC will take of deallocation, correct?
17:59 not_gerd ^take care of
17:59 cotto not_gerd: it's a bug if it doesn't
18:02 not_gerd how far along was PIRATE in terms of bytecode generation?
18:02 kid51 joined #parrot
18:03 kid51 Is #parrotsketch resuming today (Tuesday) or tomorrow (Wednesday)?
18:03 cotto kid51: today
18:06 cotto not_gerd: not sure
18:10 cotto not_gerd: do you see a performance benefit for Rakudo from PIRATE?
18:10 cotto *potential performance benefit
18:12 not_gerd cotto: possibly, but not necessarily - however, it would be "the right thing to do"[tm]
18:12 not_gerd right now, we write out pir anly to parse it again and emit pbc
18:12 not_gerd ie we already have a perfetly fine ops tree, that we serialize just because we're lacking infrastructure
18:13 not_gerd ^perfectly
18:14 not_gerd assuming this works out, imcc could be booted from libparrot and only be kept around as a seperate executable for bootstrapping
18:14 cotto not_gerd: there are a couple problems with PIRATE
18:15 cotto first, nqp-rx is an obsolete version of nqp that's only used in Parrot's repo
18:16 cotto second, compiling directly to bytecode involves some tricky bootstrapping issues
18:16 cotto they're less pronounced with nqp-rx but would be pretty significant with nqp
18:17 cotto I agree about it being the right thing to do, but we need to find the lhf first.
18:18 cotto I'm +1 for PIRATE, just not right now.
18:18 not_gerd stage0 pir files are already checked into the NQP repo
18:19 not_gerd note we'd only need to steal the bytecode emitter from PIRATE - we already have POST and PIRT trees
18:19 not_gerd one needs to decide if parts of PIRATE can be recycled or if its easier to start from scratch
18:20 not_gerd the best solution of course is cloning jnthn and bribing his clone with beer until he agrees to repeating his recent JAST work for parrot
18:20 cotto hah
18:26 cotto I'm leery of moving in a direction that doesn't have significant potential for performance gains until Parrot's at the point where the Rakudo folks are pretty happy with performance.
18:30 pmichaud not_gerd: (eval pmc patch)   I see the updated patch for Rakudo... is there an updated patch for NQP?
18:30 pmichaud good morning, #parrot
18:30 not_gerd pmichaud: yes, in the target-pbc branch of the main repo
18:31 not_gerd note that this no longer works with current parrot as I added methods to the PackfileView PMC
18:32 pmichaud okay, I'm afraid I'm really confused.
18:32 mtk joined #parrot
18:32 not_gerd ;)
18:32 not_gerd what about - what part of which repositories you need, or my changes to the codebase?
18:35 pmichaud about synchronizing these changes with "parrot"
18:36 not_gerd you need the NQP target-pbc branch, the eval_pmc branch from my Parrot fork and the target-pbc branch from my Rakudo fork
18:36 not_gerd there are open pull requests for the latter 2
18:37 pmichaud I have to put on my "release manager" hat for a bit.
18:37 not_gerd the change views are https://github.com/perl6/nqp​/compare/master...target-pbc https://github.com/gerdr/parr​ot/compare/master...eval_pmc https://github.com/gerdr/rak​udo/compare/nom...target-pbc
18:38 pmichaud When will there be a Parrot release that has the EvalPMC replacement?
18:40 not_gerd_ joined #parrot
18:40 not_gerd_ pmichaud: there's a #parrotsketch today
18:40 not_gerd_ ~40min, it I'm not mistaken?
18:41 pmichaud I don't know if I'll be able to make it to today's #parrotsketch.  I've joined the chan... but $wife may have a medical appointment then
18:41 cotto not_gerd_ your're correct
18:42 dalek parrot: f9242d6 | util++ | docs/project/release_manager_guide.pod:
18:42 dalek parrot: [doc][ci skip] Fix typo
18:42 dalek parrot: review: https://github.com/parrot/parrot/commit/f9242d6a58
18:42 pmichaud looking at https://github.com/perl6/nqp​/compare/master...target-pbc, it seems as though the target-pbc branch is based off of a really old copy of nqp :-(
18:42 cotto not_gerd_: are your changes in shape to merge before the release today?
18:43 not_gerd joined #parrot
18:44 pmichaud there's also a problem in that today's release is not a "supported release"
18:46 not_gerd cotto: my changes include whiteknight's removal of the Eval PMC which was ready 10 months ago, 1 new packfile API function and 2 new PackfileView PMC methods
18:46 not_gerd they are *probably* good to go, but no one besides myself has looked through them or tested it
18:47 cotto pmichaud: What effect does that have?
18:47 pmichaud cotto: this is a drastically backwards-incompatible change
18:47 pmichaud since 5.1.0 is not a "supported release", it won't appear in e.g. Debian distros
18:48 pmichaud if we apply the changes to nqp/rakudo to do the removal of the Eval PMC , the new nqp/rakudo will no longer be compatible with 5.0.0
18:48 cotto Do we need to say "supported" somewhere in the release to get it into distros?  I'm happy saying that we only support the latest release.
18:50 pmichaud I'm not sure that simply saying "supported" in the release notes is going to be sufficient.  Parrot's had a published "supported / monthly" release policy for almost four years now, I don't think the packagers are going to adapt to a new policy that quickly.
18:52 not_gerd there's no pressing need to get teh changes in right now
18:52 allison as the packager for Debian/Ubuntu, I can say I'm holding off on 5.0 because I'm not sure of the status of it or future releases
18:53 allison I thought the eval_pmc stuff wasn't right yet?
18:53 pmichaud oh, things are much simpler if allison++ is the packager.  :)
18:54 not_gerd allison: hopefully, it is now
18:54 allison not_gerd: you got the semantic confusion on :main sorted out? It sounded like we were using it to mean too many different things
18:55 allison :main is like C main, only for execution
18:55 allison but, it seems to be used for lots of other things
18:55 allison like, library loading and such
18:55 Coke Eastern was not one of the #ps times listed, and I am lazy. ETA?
18:56 benabik joined #parrot
18:56 pmichaud I think the way :main is being used in the new Parrot branch is okay; I think it's only how it was being used/described in the proposed nqp/rakudo patches is suspect.
18:56 cotto Coke: 35 minutes
18:56 Coke ah, good, I'll be free-ish.
18:56 allison pmichaud: ok, good
18:57 pmichaud but I'm not certain of that, since the people submitting the patches haven't quite understood what nqp/rakudo need
18:58 pmichaud not_gerd: regarding https://github.com/perl6/nqp​/compare/master...target-pbc ... is it possible for me to get a diff that only shows the changes due to the evalpmc removal?  This diff has a lot of other stuff that looks unrelated.
18:58 cotto pmichaud: do you see any problems arising from doing away with the distinction between supported and developer releases given that allison++ is the debian packageer?
18:58 pmichaud cotto: I've never been a fan of the supported/developer release tagging.
18:59 Coke suggestion: put everything in the "developer" bucket going forward
18:59 cotto great
18:59 allison Coke: as a distro packager, I can say that doesn't work
18:59 cotto Coke: I'm happy with that plan.
18:59 pmichaud cotto: so, I'd like to see it gone.  I don't know how long it will take our audiences to adjust; we might need to find/notify the rakudo packager as well.
19:00 Coke (then we don't have to come up with a new folder system)
19:00 allison Coke: we can't get every monthly release into the distro
19:00 Coke allison: fine. if the buckets don't matter to us, and they matter to you, we put them all in "supported"
19:00 Coke so don't put them all in.
19:00 allison Coke: so, whatever Parrot calls them, please pick 2-4 releases a year to designate as distro releases
19:00 Coke why?
19:01 allison because, like it or not, you do have to think differently for those releases
19:01 benabik Debian packages persist for a long time.
19:01 allison you can't tell people "oh, just upgrade to the next month releases"
19:01 Coke let's back up a second. How does making things easy for packages help us with rakudo?
19:01 Coke and do we care if we are bundled separately from rakudo?
19:01 allison because rakudo lives or dies by its availibility in releases
19:01 * not_gerd gone for a bit, back in a minute
19:01 pmichaud just an aside that rakudo cares about packaging issues
19:02 pmichaud (which is why I brought the topic up)
19:02 allison (by "releases" there, I meant "distro releases")
19:02 Coke allison: rakudo ships its own package, outside the scope of the released ones.
19:02 allison Coke: the only packages that matter are the ones in Debian/Ubuntu/Fedora
19:02 allison sorry, that's just the way the world works
19:02 pmichaud Coke: rakudo ships its own package, yes, but it's tied to specific Parrot packages
19:03 allison we're very, very careful to release parrot/rakudo in lockstep on Debian/Ubuntu
19:03 Coke I disagree, but ok. I'll just abstain on packaging issues.
19:03 benabik rakudo requires parrot = x.y.z ?
19:03 Coke (I think heading down this path in the first place is one of the things that hurt us in terms of shipping a working product)
19:03 pmichaud if we publish a Rakudo release that depends on Parrot 5.1.0, that Rakudo release will never appear in a Debian distribution.
19:04 pmichaud at least, it won't appear in a Debian distribution until there's a supported release of Parrot (i.e., 5.3.0) that goes into a Debian distribution
19:04 cotto allison: is it reasonable to label Parrot releases as "supported" based on which version of Rakudo will go into distros?
19:05 Coke Why even do monthly releases at that point, I wonder.
19:05 allison we can designate them "distro", if that helps
19:05 Coke changing the names doesnt help, no.
19:05 allison Coke: I was wondering that myself
19:05 Coke it's one more infrastructure thing to change.
19:06 allison cotto: and, yes, it's perfectly reasonable to flex the schedule
19:06 allison cotto: whenever we're ready to make a Rakudo release for distros, we pair it with a Parrot "supported" release
19:06 allison if that's once a year, fine
19:06 allison twice a year, fine
19:08 Mike-PerlRecruiter_ joined #parrot
19:08 cotto excellent
19:08 cotto That'll give us the flexibility we need.
19:09 cotto pmichaud: how's that sound do you?
19:09 pmichaud Like the beginning of a plan, but not a complete one.
19:10 allison pmichaud: I'm still not 100% certain there will ever be another "supported" Parrot release after 5.0, so planning can probably come later
19:11 allison pmichaud: btw, while we're on the topic, is it worth making a 5.0 Parrot release to Debian/Ubuntu?
19:11 pmichaud allison: right, that's what concerns me about making a backwards-incompatible change like the eval_pmc one.
19:11 allison pmichaud: it's currently at 4.6.0
19:12 pmichaud allison: current Rakudos want at least 4.10.0, I think, so bumping to 5.0.0 would be good.
19:12 allison pmichaud: wheezy is actually going out the door with 4.0.0
19:12 allison pmichaud: ok, I'll do that, and we'll coordinate a compatible rakudo package version to go with it
19:13 pmichaud does wheezy have a rakudo, too?
19:13 allison pmichaud: and that'll probably be the last packaged version of Parrot until things settle down on the revamp side
19:13 pmichaud (last packaged version)  yeah, that's part of the reason I'm wary of doing too much backwards-incompatible stuff with rakudo/nqp
19:13 allison wheezy's rakudo is 0.1~2012.01-1
19:14 allison (which makes sense, as the packaging is done in lock step)
19:14 Coke why even bother with such an old version?
19:14 Coke does it actually help get people onto rakudo/parrot, or does it result mainly in "why is my rakudo broken?"
19:14 pmichaud the "lock step" needs to be a little less locked.  Later versions of rakudo would have worked with 4.0.0 also, I think.
19:14 allison debian has strict guidelines about when a package migrates from "unstable" to "testing"
19:15 allison pmichaud: I don't actually own the rakudo packages, but I work with the DDs who do
19:15 allison Coke: "unstable" is pretty open, and it's actually what Ubuntu pulls from
19:16 allison Coke: "testing" is the candidate for the next Debian "stable" release, and requires passing on all architectures
19:16 Coke ok. I have no idea how "wheezy" relates to stable or unstable.
19:16 allison Coke: which parrot and rakudo aren't doing right now
19:16 allison ay, "wheezy" is "testing"
19:16 allison and will become the next "stable"
19:16 Coke so the /testing/ release is a year old?
19:17 allison yup
19:17 Coke that seems insane.
19:17 allison this is what people complain about in Debian
19:17 Coke are there tickets open for whatever is blocking us from getting a newer version in there?
19:17 allison but, it does make for a very stable base
19:17 pmichaud I should say I'm less concerned about Debian itself than Ubuntu, fwiw.
19:18 allison pmichaud: aye, but Ubuntu pulls from Debian "unstable", so that's easier to keep current
19:18 kid51 joined #parrot
19:18 allison pmichaud: "unstable" has 2012.10
19:21 allison Coke: I know there are tickets for some, but I'm not sure if they're all ticketed
19:24 cotto #ps in 5
19:24 Coke ok. if you can ask the devs you mentioned earlier to keep on top of that, we'd really appreciate it.
19:24 Coke and perhaps we could tag them all with something so they'll be easier to find/prioritize. (I would say this is a very high priority)
19:26 uvtc joined #parrot
19:27 uvtc This might be a silly question: given Parrot's current goals, why not package it together with Rakudo (wrt Debian, Ubuntu, Redhat)?
19:28 uvtc As one package.
19:28 moritz uvtc: I'm not sure how well that align with Rakudo's goals
19:28 cotto uvtc: I was wondering that too.
19:28 moritz uvtc: rakudo's goal is to run on multiple VMs in the future (where "multiple" can be larger than 2)
19:29 moritz so coupling more tightly to parrot is a step backwards
19:29 cotto though if there's a viable way to keep them separate, it won't hurt to do so
19:31 allison uvtc: that's not the way Debian packaging works
19:31 dalek nqp: f8a37df | (Tobias Leich)++ | / (4 files):
19:31 dalek nqp: add sequential array interpolation switch
19:31 dalek nqp:
19:31 dalek nqp: Arrays in regexes will match sequential if preceded by ||.
19:31 dalek nqp: review: https://github.com/perl6/nqp/commit/f8a37dfcd7
19:31 allison uvtc: in fact, the Parrot and Rakudo "source" packages actually each split into multiple "binary" packages
19:31 Coke which is crazy.
19:32 allison nope, it makes perfect sense
19:32 allison it allows flexibility in what's actually installed
19:32 pmichaud Parrot was never intended to be "for Rakudo only", so it should get a separate packaging name.
19:32 dalek parrot: ab955c5 | util++ | / (2 files):
19:32 dalek parrot: Prepare for the 5.1.0 release
19:32 dalek parrot: review: https://github.com/parrot/parrot/commit/ab955c5f94
19:33 allison like, if you're only ever running code, and not building new compilers, there's loads of stuff in the Parrot source you don't need installed
19:33 allison pmichaud: maybe, we'll about names when we get there
19:33 allison *we'll see
19:33 uvtc Whoops --- sorry. Given the time, I probably should've asked that question on #parrotsketch.
19:34 pmichaud allison: yeah, I meant historically, not necessarily going forward.
19:34 allison pmichaud: there's not much value in maintaining Parrot 5.0 packages forever if the future of the project is headed in another direction
19:34 allison pmichaud: and, to be honest, the rakudo packages are the only ones that depend on the parrot packages anyway :)
19:35 uvtc left #parrot
20:11 PerlJam Does parrot still have issues building when there's already a parrot installed?
20:11 cotto PerlJam: I don't believe so.
20:13 not_gerd PerlJam: it does, at least on Cygwin when trying to install into the same location
20:13 Coke unless you're on OS X.
20:13 Coke (at which point all the make targets take care of it, but if you're running stuff out of the build directory by hand, be careful)_
20:14 PerlJam how about this ... If I try to build a sixparrot (on an Ubuntu system) when I already have another parrot installed, am I likely to run into problems?
20:14 Coke probably not. especially if you're building it as part of a local rakudo test.
20:14 Coke (different install dirs)
20:15 PerlJam ok
20:15 PerlJam thanks all  :)
20:16 dalek parrot/sixparrot-nci: 9f849dd | (Jon Gentle)++ | / (14 files):
20:16 dalek parrot/sixparrot-nci: Remove PCRE
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/9f849dd8d9
20:16 dalek parrot/sixparrot-nci: 061a519 | (Jon Gentle)++ | / (52 files):
20:16 dalek parrot/sixparrot-nci: Remove curses, postgres and sdl
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/061a5197b3
20:16 dalek parrot/sixparrot-nci: c9b23ac | (Jon Gentle)++ | examples/opengl/ (8 files):
20:16 dalek parrot/sixparrot-nci: Remove more OpenGL stuff
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/c9b23acfc2
20:16 dalek parrot/sixparrot-nci: f0c2744 | (Jon Gentle)++ | / (7 files):
20:16 dalek parrot/sixparrot-nci: Remove dlfunc and dlvar
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/f0c27442aa
20:16 dalek parrot/sixparrot-nci: f2918e8 | (Jon Gentle)++ | src/multidispatch.c:
20:16 dalek parrot/sixparrot-nci: Remove NCI from multidispatch
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/f2918e86ba
20:16 dalek parrot/sixparrot-nci: 2f2c720 | (Jon Gentle)++ | / (3 files):
20:16 dalek parrot/sixparrot-nci: Remove the guts of nci.pmc
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/2f2c720e6e
20:16 dalek parrot/sixparrot-nci: 215dc42 | (Jon Gentle)++ | / (6 files):
20:16 dalek parrot/sixparrot-nci: Remove has_core_nci_thunks and has_extra_nci_thunks
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/215dc42b11
20:16 dalek parrot/sixparrot-nci: 8f32960 | (Jon Gentle)++ | / (5 files):
20:16 dalek parrot/sixparrot-nci: Remove the nci dev tools
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/8f32960837
20:16 dalek parrot/sixparrot-nci: bd00503 | (Jon Gentle)++ | / (29 files):
20:16 dalek parrot/sixparrot-nci: Gut a good portion of nci
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/bd0050322f
20:16 dalek parrot/sixparrot-nci: 2cf45b2 | (Jon Gentle)++ | src/ (3 files):
20:16 dalek parrot/sixparrot-nci: Remove uses of enum_class_NCI
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/2cf45b2607
20:16 dalek parrot/sixparrot-nci: d770f20 | (Jon Gentle)++ | / (5 files):
20:16 dalek parrot/sixparrot-nci: Gut nci.h
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/d770f208ec
20:16 dalek parrot/sixparrot-nci: f098bf3 | (Jon Gentle)++ | / (8 files):
20:16 dalek parrot/sixparrot-nci: Remove nci.pmc and nci.h
20:16 dalek parrot/sixparrot-nci: review: https://github.com/parrot/parrot/commit/f098bf33fb
20:17 cotto wheee
20:18 dalek rakudo/nom: 8e6fa0b | (Tobias Leich)++ | / (3 files):
20:18 dalek rakudo/nom: add array in regex interpolation feature
20:18 dalek rakudo/nom:
20:18 dalek rakudo/nom: Arrays withinn regex will be treated as alternations of its elements.
20:18 dalek rakudo/nom: Preceding | or || will change its behaviour, || means sequential alt-
20:18 dalek rakudo/nom: ernation and | LTM, while the LTM is just a basic approach and needs
20:18 dalek rakudo/nom: tweeking.
20:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8e6fa0b562
20:24 atrodo sixparrot-nci is ready to be looked at and possibly merged with sixparrot
20:24 atrodo it compiles and passes rakudo with no problems for me
20:25 benabik joined #parrot
20:25 cotto atrodo: including rakudo spectest?
20:25 atrodo cotto: Including spectest
20:25 cotto atrodo++
20:26 atrodo I think I need to update my version of Rakudo, but it fails exactly the same spectests as master
20:32 dalek rakudo/agressive-sink-warnings: 80f788b | moritz++ | src/Perl6/Optimizer.pm:
20:32 dalek rakudo/agressive-sink-warnings: Warn when pure expressions are used in sink context
20:32 dalek rakudo/agressive-sink-warnings:
20:32 dalek rakudo/agressive-sink-warnings: even if the arguments are not constant, or the expression warns.
20:32 dalek rakudo/agressive-sink-warnings: By explicit request from TimToady++ at
20:32 dalek rakudo/agressive-sink-warnings: http://irclog.perlgeek.de/​perl6/2013-02-18#i_6469204
20:32 dalek rakudo/agressive-sink-warnings: review: https://github.com/rakudo/rakudo/commit/80f788bbd7
20:32 dalek rakudo/agressive-sink-warnings: 2f210be | moritz++ | src/Perl6/Optimizer.pm:
20:32 dalek rakudo/agressive-sink-warnings: awesomify sink context warning text
20:32 dalek rakudo/agressive-sink-warnings: review: https://github.com/rakudo/rakudo/commit/2f210bea17
21:16 donaldh joined #parrot
21:50 masak joined #parrot
21:50 not_gerd masak: look for example at Rust's threading system - there's no sharing
21:50 not_gerd you can only move unique pointers between threads
21:51 not_gerd only the thread owning that pointer may modify the object
21:51 not_gerd this is limiting on comparison to everything goes shared-by-default threading implementations
21:51 not_gerd nevertheless, you can do useful stuff
21:51 rurban Perljam: osx and cygwin has problems with an installed parrot, all others not
21:51 benabik joined #parrot
21:52 not_gerd someone just needs to take a close look at how threading in Parrot works and come up with good stories for various real-world problems
21:52 not_gerd for some value of 'just', of course
21:52 Coke Answering pmichaud's coding sample would be most helpful.
21:52 jsut left #parrot
21:53 Coke and probably the best way to get traction in nqp/rakudo adoption.
21:53 masak not_gerd: what you say doesn't directly address the concerns diakopter wrote in that second, unreplied-to email. I'd really like to see a point-by-point reply to that one.
21:53 masak wrote about*
21:54 not_gerd have the link ready?
21:54 not_gerd I thought it was a case of the XY-problem, but I might be mistaken
21:54 masak not_gerd: http://lists.parrot.org/pipermail/p​arrot-dev/2012-December/007296.html
21:54 not_gerd masak++
21:55 masak particularly the paragraph starting with 'What do you mean by "the GC knows not to follow those references"?' and giving a long, detailed example.
21:55 allison I'm most fond of the Erlang threading model these days
21:56 masak it's clear that diakopter has put in a lot of effort writing this email. and that he's not just rambling.
21:56 allison shared memory sucks
21:56 masak even if he's *wrong*, how can such an email go unanswered for such a long time?
21:56 allison masak: because other things are more important right now
21:56 allison masak: and no one feels like arguing about it
21:57 allison masak: we're talking about ripping out huge chunks of code
21:57 benabik masak: Fatigue. IIRC, diakopter spent a lot of time saying "This won't work" and not seeming to absorb anything about what he's talking about.
21:57 allison masak: and the success or failure of the last "experimental" change to parrot under the old, dead development model is... not so important anymore
21:57 masak right.
21:58 masak maybe I shouldn't be so quick to bite on rurban's "someone is spreading fud" line ;)
21:58 allison yes, that struck me as rather trollish (sorry rurban, I know it's your code)
21:58 masak fwiw, diakopter seems to have a point here, even if no-one has the strength to argue against him.
21:59 allison masak: to be honest, I haven't looked at the code, or closely at diakopter's points, so he could be right
21:59 Coke so, anyway, on threads: code is the best way forward. if someone can writeup a way to do pmichaud's sample that shows threads in action, that can be the next point to act from. Having diakopter and rurban fight will do nothing but piss them and everyone else off.
21:59 rurban no, it's not my code at all. it's stefans code, and he should answer it.
21:59 allison masak: I'm going with 50/50 chance he's right at t this point
21:59 PerlJam masak: my reading of diakopter's email just now seems to be a longish way of saying "proxies leak"
22:00 allison PerlJam: I'm sure he's right there
22:00 rurban However, I see no serious problem in the scenarios diakopter outlined. we just do not do that.
22:00 not_gerd masak: the point is not if there is a problem, but rather if its fatal
22:00 not_gerd reference counters can't collect cycles
22:00 rurban we know that proxies leak when created via other threads
22:00 not_gerd is refcounting therefore not useful?
22:01 rurban but in the very end they are collected
22:01 rurban but as we do not create proxies from subthreads it's fud
22:01 not_gerd instead of coming up with an example that breaks, you need to come up with a 'real#world' problem and need to look into how to implement it within the given constraints
22:01 PerlJam not_gerd++ code trumps speculation
22:02 not_gerd no one has done that yet for Parrot's threading system
22:02 not_gerd but *because* no one has done that yet, it's premature to say that it's not useful
22:02 rurban several real world problems are in examples/thread already
22:03 Coke rurban: btw, I tried running the thread examples - most of them seemed to hang. I was unclear as to what they were trying to show me.
22:03 rurban even with semaphores
22:03 Coke so perhaps they could use some more documentation as to what to expect.
22:03 rurban Coke: which OS did hang?
22:03 Coke s/hang/run a long time/
22:03 Coke OS X.
22:04 Coke I'm not suggesting there was a deadlock or anything, just that it was unclear what the example was doing, and after a few minutes, I gave up.
22:07 rurban Coke: OS X should turn off DEBUG for threads, but I thing I removed the deadlock by running the GC validator already
22:07 rurban OS X with threads should not run the GC validator
22:08 Coke Ok. I have no idea what that means. I did a build with no config options.
22:08 Coke (if there are required options for OS X, I think we can add that to the defaults in config/ somewhere.)
22:08 rurban then you have a slow mac. all examples run fine on my macbook air
22:08 ctult_ joined #parrot
22:09 Coke or prohibited ones.
22:09 benabik I think debug is enabled by default.
22:09 Coke I have a macbook air with quad cores and 4GB of memory. Seems pretty zippy.
22:09 benabik My build script has a --debugging=0 in it.
22:09 benabik IIRC
22:10 Coke so, all those examples should terminate quickly?
22:10 rurban I've also added threads and gc stress tests
22:10 rurban no, the thread samples can run very long
22:10 rurban lemme time it...
22:10 Coke rurban, you can be a very frustrating person to have a conversation with.
22:12 rurban why?
22:12 Coke it would be helpful to me if those examples had some docs about what they were demonstrating and how long they ran (maybe in relation to each other, just so we have some idea when running the examples, what we're supposed to be looking for)
22:12 Reini joined #parrot
22:12 Coke because I'm trying to found out why these are slow. You say I have a slow mac, but then say "no, the thread samples can run very long."
22:12 Reini time ./parrot examples/threads/chameneos.pir real0m10.063s
22:13 Reini 10s is very long
22:13 Reini and the other tests need much more time
22:13 PerlJam Reini: would those take very very very long?   :)
22:13 Reini on a slow mac 10s will be 40s
22:14 Reini and this is the fastest test
22:14 benabik Slow programs should perhaps output progress...
22:14 Reini yes, maybe
22:14 Coke *sigh*
22:14 Reini but you could also look at them what they are doing
22:14 benabik But documentation would be really best.
22:15 Reini like less examples/threads/alloc_test.pir
22:15 Coke if by that, you mean, "look at the source", sure. but I don't know what you're trying to showcase.
22:16 Coke I'll open a ticket.
22:16 Reini what for?
22:16 Reini the ones which need more than 10s do output progress
22:17 Coke nevermind.
22:18 Coke I really can't waste anymore positive energy trying to steer threads in a helpful direction.
22:18 Coke thank for all the effort on the code side, though.
22:19 Reini you could help by stopping the stupid rumors at the perl6 side.
22:19 Reini time ./parrot examples/threads/moretasks.pir needs several minutes and is printing a lot of progress
22:20 Coke Reini: you're giving me nothing to help you. Sorry.
22:21 Coke The only person you have a problem with is diakopter. Everyone else is looking to some code to jumpstart things, or the examples to figure things out.
22:21 rurban I can give the hint that parrot threads are far superior to jvm threads
22:21 rurban and to all the other GIL langs
22:21 rurban (global interpreter lock)
22:22 benabik Parrot threads are basically orthogonal to JVM threads.
22:22 rurban I am having more a problem with chromatic declaring parrot publicly dead
22:22 benabik Wholly different programming model.  Which is better is highly dependent on what you understand.
22:22 Coke FYI, OS X here with a fresh parrot is killing a CPU running alloc_test (120% CPU), and is eating 20.9% memory so far, and has been running for 2+ minutes.
22:22 rurban it is dead for him since a year, but he should not kill perl6
22:23 Coke so ignore him. Or do good things instead. Don't let him piss you off.
22:23 benabik +
22:23 benabik +1
22:23 rurban alloc_test.pir is running in an endless LOOP AFAIR
22:23 benabik Really, +(as many as I'm allowed)
22:24 rurban I did ignored chromatic, but then the old parrot managers declared parrot dead
22:24 Coke ... who?
22:24 rurban coke, allison, chromatic
22:25 Coke I never said parrot was dead.
22:25 rurban and then they decided to do desperate things, again. as every two years or so.
22:25 benabik Open source projects are only dead when nobody is involved in them.  Parrot has been limping along with minimal participation for months now.
22:25 Coke let's not go down that path of "he said, she said" again without having some links.
22:25 benabik s/ without.*//
22:25 Coke rurban: I'm not doing anything desperate. I'm working on a branch.
22:26 rurban minimal participation with many exciting features and progress
22:26 allison Coke: he might mean me
22:26 Coke Playing around. it's more commits than I've done to parrot in years. Sorry they're not where you want them, but I can't help you there.
22:26 allison benabik: years, more like
22:26 rurban I haven't looked who said what.
22:26 cotto pretty much
22:26 Coke ah, well make sure you attribute things incorrectly up front. very helpful.
22:27 rurban I could only come back when allison left. to clean up the mess she left.
22:27 allison rurban: you declared that you're working on your own VM
22:27 rurban yes, on p2 and helping out parrot
22:28 rurban perl6 needs parrot alive.
22:28 allison rurban: hmmm... I think I won't go there
22:28 rurban and not declared dead by some outsiders who have no idea
22:28 allison it has been very, very sick for a long time
22:28 Coke anyway, if someone could add a note to examples/threads/alloc_test.pir that it is an infinite loop, and not expected to return, that'd be awesome.
22:28 benabik allison: I somewhat object to that...
22:29 allison possibly all the way back to the Dan/Leo flamewars
22:29 allison benabik: I'm at a point in the grieving process where I accept all that's past
22:29 allison benabik: and accepting it gives me the freedom to focus on the future
22:30 rurban And I'm at a point where I cannot accept more damage being done.
22:30 rurban So far the cleanup were pretty okay so. good work
22:30 benabik allison: The last couple of years may not have been as active as previously, but there have still been people working on it.
22:30 rurban but I'm afraid some pretty bad decision will be made.
22:31 rurban And I want that rakudo will have a veto in it
22:31 allison benabik: yes, I greatly appreciate those who have stuck by parrot faithfully
22:31 benabik As opposed to the last few months while most of the developers have done basically nothing.
22:31 Coke rurban: yes, of course rakudo will have a veto.
22:31 Coke rurban: that's the entire point of the sixparrot branch.
22:31 rurban good
22:32 Coke well, entire is stretching it, but it's a preconition. if we agree that rakudo is our main customer, why would we piss them off?
22:32 allison benabik: that's fair, I confess I was completely suprised when Coke told me rurban was the last active developer and had just quit
22:32 Coke so, instead of coming in here and spreading FUD, perhaps you could talk to us first. :)
22:32 rurban I haven't quit. I never said that
22:32 allison benabik: I was only following just enough to see that there was *some* activity
22:32 Coke that was the impression many of us seem to have taken with your announcement about p2. Apologies.
22:33 cotto benabik: yeah.  The people who've stuck around for the last couple years have done a lot.  The problem is that Parrot still isn't running in production anywhere.
22:33 rurban whiteknight was overworked, and I started my better vm to help out p6 and p5
22:33 allison rurban: that's great, nothing to be ashamed about there
22:33 rurban and fperrad is also working on a similar vm
22:33 cotto I hope whiteknight takes a nice tropical vacation.  He needs to un-burn himself out.
22:33 benabik cotto: I'm in academia.  That doesn't bother me.  ;-)
22:33 allison rurban: your interests are elsewhere, that's totally cool
22:33 rurban so everything will be fine
22:33 rurban my interests are perl
22:35 * not_gerd is also working on his own vm, just so you knwo :p
22:35 allison I've thought of starting my own, several times
22:35 not_gerd I calling it tentatively m42, because it's my answer to m0
22:35 allison even have a gitorious repo staked out for it
22:36 allison but, at the moment, sixparrot is more interesting to me
22:36 cotto I enjoyed working on m0, but it gave me an allergy to big rewrites.
22:37 allison if there's one lesson I've learned in my decade on Perl 6, it's that starting over from scratch is never easier
22:38 allison it may be *better* in some cases
22:38 allison but never easier
22:38 allison (and often it's not even better)
22:38 cotto You see all the problems that exist but rarely the ones that have been solved.
22:38 allison aye
22:38 allison because they aren't pain points
22:38 allison they just work
22:39 masak depends what you mean by "from scratch".
22:40 allison m0
22:40 not_gerd that's where I'm at, if anyone is interested: https://gist.github.com/gerdr/4990845
22:40 allison or, for that matter, Perl 6 itself
22:40 allison which I still think is a good idea
22:40 allison but, I don't think anyone could argue Perl 6 has been *easier* than patching up Perl 5
22:41 allison and so far, it's not even better, but it has potential to be better
22:42 masak I see many small domains where it's already better :)
22:42 allison ah, that gets down to fine details of what's "better"
22:43 allison until I can convince clients to switch to Perl 6, and offer them compelling reasons why they should, I don't consider it "better"
22:46 masak *nod*
22:52 Coke it would be helpful if someone could add "threads" as a github issue label, and then tag issue #936
22:53 benabik Coke: done
22:54 Coke benabik++
22:57 not_gerd good night, #parrot
22:57 not_gerd left #parrot
22:57 * pmichaud adds the "threads" label to #889
23:04 Coke is there a way to disable paging on SOME irssi windows?
23:36 Util Proposal for Perl-NG Hackathon is now codified:
23:36 Util http://www.yapcna.org/yn2013/wiki?node=Hackathons
23:36 Util http://ideas.yapcna.org/idea/6290DA56-7AEB​-11E2-818A-8AC49D4F7835/perl-ng-hackathon
23:36 Util If you are interested in attending, based on the first link, please click "Interested" on the second link. Thanks!
23:38 cotto Util: thanks
23:49 kid51 joined #parrot

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

Parrot | source cross referenced