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.
Coke I could branch, sure, but means there's a discontinuity when this goes in. 00:01
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.
cotto +1 and thank you, then 00:03
00:15 bluescreen joined
Coke cotto: gist.github.com/coke/4981953 ? 00:17
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*. :)
ah well, enough of that for one day.
cotto I'm a little bit relieved. 00:20
dalek rrot/coke/rm_pasm: 5c443cd | coke++ | config/gen/makefiles/root.in:
another merge fix.
Coke ok, I'm all pushed.
(doesn't fix the nqp issue) 00:29
01:07 woosley joined 01:59 dmalcolm joined
benabik alt.parrot.pasm.die.die.die 02:01
cotto I love that group. I wish it existed. 02:03
benabik "Your ideas are intriguing to me, and I wish to subscribe to your newsletter." 02:04
02:23 davidfetter joined 03:07 preflex joined
bonsaikitten dukeleto: bpaste.net/show/78223/ that's the strace part around perldoc detection 03:25
Util "Zombie Parrot" wins, by popular acclaim! 03:56
04:46 preflex_ joined 05:19 bonsaikitten joined, sri joined
dukeleto Util++ 06:23
bonsaikitten: either that is not enough of the output and/or you will need -f to show the syscalls of forked processes 06:24
bonsaikitten dukeleto: let me try to add that 06:27
cotto a whole mess of opsc tests are failing and yaml_tiny, but that seems to be all 06:34
and ops2c is generating more write barriers than it should for some ops
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
dukeleto: looks like perldoc can't access the temp file that the parent process created (want the whole log pasted?)
dukeleto bonsaikitten: sure 06:48
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
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. 06:55
07:06 Mike-PerlRecruiter_ joined
cotto and now parrot-dev knows 07:06
bonsaikitten dukeleto: gentooexperimental.org/~patrick/perl-logfile.zip sorry for the delay, was a bit tricky to upload. 25MB uncompressed. 07:14
07:46 bouncy joined
dalek rrot/ops2c-necromancy: 4d361e8 | cotto++ | src/dynoplibs/Rules.in:
[ops2c] ops2c is already quiet and doesn't need --quiet
 08:36
rrot/ops2c-necromancy: 244d6d1 | cotto++ | / (3 files):
[ops2c] various fixes for symbol visibility and constants translation
 08:37
rrot/ops2c-necromancy: 0bbd2dc | cotto++ | lib/Parrot/OpsFile.pm:
[ops2c] clean up/fix write barrier generation

The generated core_ops.c now doesn't seem to contain any subtantial differences from what's in git and all non-opsc tests pass with the exception t/library/yaml_tiny.t.
rrot/ops2c-necromancy: fee5554 | cotto++ | config/gen/makefiles/root.in:
[ops2c] bring back the makefile rules for ops2c's generated files
10:00 xcombelle joined
tadzik cotto++ # blog post 11:01
"Parrot’s best bet is to focus exclusively on supporting Rakudo and give it a reason to stick around" nails it, imo 11:02
12:27 he__ joined 13:45 benabik joined 14:10 PacoAir joined 14:15 PacoAir joined 14:21 Psyche^ joined, bluescreen joined 14:27 benabik joined 14:49 benabik joined 14:51 benabik_ joined 14:58 JimmyZ joined 15:09 bluescreen joined 15:27 contingencyplan joined 15:34 dmalcolm joined 15:35 benabik joined
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
oh, he's gone
15:58 mtk joined
cotto ~~ 16:35
dukeleto ~~ 16:48
16:49 davidfetter joined
dalek rrot/ops2c-necromancy: ca04662 | cotto++ | / (32 files):
[op2c] remove nqp-based opsc
 16:52
rrot/ops2c-necromancy: 5b4836f | cotto++ | / (3 files):
[ops2c] remove the generated core ops files from git

They were originally checked in so that Parrot could bootstrap itself. Since they're now back to being generated by p5, keeping them in git isn't necessary.
cotto dukeleto: if you've got some tuits, t/library/yaml_tiny.t is failing in that branch. 16:53
or you can see how the it does with nqp. I haven't done anything wrt testing that yet. 16:55
Coke is yaml_tiny going to survive sixparrot? if not, may not be worth fixing. 16:56
cotto Coke: excellent question.
Coke I think most of the runtime libs are unused by nqp/rakudo - if it's not used internally, may not be worth it.
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
I'm more concerned that there's an underlying bug that that test just happens to expose. 16:57
Coke ah. 17:01
dalek rrot/ops2c-necromancy: 5350d2d | cotto++ | MANIFEST:
[ops2c] update MANIFEST
 17:27
p/target-pbc: 679cac2 | (Gerhard R)++ | src/HLL/Compiler.pm:
Migrate to new PackfileView API
 17:38
p/target-pbc: b7d0122 | (Gerhard R)++ | src/NQP/World.pm:
Rename $main to $mainline to avoid confusion
cotto not_gerd++ 17:39
17:56 not_gerd joined
not_gerd o/ 17:56
I believe I've now taken care of everything pmichaud complained about
if he's fine with merging into NQP/Rakudo, the Eval PMC is ready to die 17:57
cotto nice
not_gerd hopefully, it won't take another 10 months 17:58
just to be sure: I can just allocate PMCs in C and the GC will take of deallocation, correct? 17:59
^take care of
cotto not_gerd: it's a bug if it doesn't
not_gerd how far along was PIRATE in terms of bytecode generation? 18:02
18:02 kid51 joined
kid51 Is #parrotsketch resuming today (Tuesday) or tomorrow (Wednesday)? 18:03
cotto kid51: today
not_gerd: not sure 18:06
not_gerd: do you see a performance benefit for Rakudo from PIRATE? 18:10
*potential performance benefit
not_gerd cotto: possibly, but not necessarily - however, it would be "the right thing to do"[tm] 18:12
right now, we write out pir anly to parse it again and emit pbc
ie we already have a perfetly fine ops tree, that we serialize just because we're lacking infrastructure
^perfectly 18:13
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
first, nqp-rx is an obsolete version of nqp that's only used in Parrot's repo 18:15
second, compiling directly to bytecode involves some tricky bootstrapping issues 18:16
they're less pronounced with nqp-rx but would be pretty significant with nqp
I agree about it being the right thing to do, but we need to find the lhf first. 18:17
I'm +1 for PIRATE, just not right now. 18:18
not_gerd stage0 pir files are already checked into the NQP repo
note we'd only need to steal the bytecode emitter from PIRATE - we already have POST and PIRT trees 18:19
one needs to decide if parts of PIRATE can be recycled or if its easier to start from scratch
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
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:26
pmichaud not_gerd: (eval pmc patch) I see the updated patch for Rakudo... is there an updated patch for NQP? 18:30
good morning, #parrot
not_gerd pmichaud: yes, in the target-pbc branch of the main repo
note that this no longer works with current parrot as I added methods to the PackfileView PMC 18:31
pmichaud okay, I'm afraid I'm really confused. 18:32
18:32 mtk joined
not_gerd ;) 18:32
what about - what part of which repositories you need, or my changes to the codebase?
pmichaud about synchronizing these changes with "parrot" 18:35
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
there are open pull requests for the latter 2
pmichaud I have to put on my "release manager" hat for a bit. 18:37
not_gerd the change views are github.com/perl6/nqp/compare/maste...target-pbc github.com/gerdr/parrot/compare/ma.....eval_pmc github.com/gerdr/rakudo/compare/no...target-pbc
pmichaud When will there be a Parrot release that has the EvalPMC replacement? 18:38
18:40 not_gerd_ joined
not_gerd_ pmichaud: there's a #parrotsketch today 18:40
~40min, it I'm not mistaken?
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
dalek rrot: f9242d6 | util++ | docs/project/release_manager_guide.pod:
[doc][ci skip] Fix typo
 18:42
pmichaud looking at github.com/perl6/nqp/compare/maste...arget-pbc, it seems as though the target-pbc branch is based off of a really old copy of nqp :-(
cotto not_gerd_: are your changes in shape to merge before the release today?
18:43 not_gerd joined
pmichaud there's also a problem in that today's release is not a "supported release" 18:44
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
they are *probably* good to go, but no one besides myself has looked through them or tested it
cotto pmichaud: What effect does that have? 18:47
pmichaud cotto: this is a drastically backwards-incompatible change
since 5.1.0 is not a "supported release", it won't appear in e.g. Debian distros
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.
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:50
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
I thought the eval_pmc stuff wasn't right yet? 18:53
pmichaud oh, things are much simpler if allison++ is the packager. :)
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
:main is like C main, only for execution 18:55
but, it seems to be used for lots of other things
like, library loading and such
Coke Eastern was not one of the #ps times listed, and I am lazy. ETA?
18:56 benabik joined
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
Coke ah, good, I'll be free-ish.
allison pmichaud: ok, good
pmichaud but I'm not certain of that, since the people submitting the patches haven't quite understood what nqp/rakudo need 18:57
not_gerd: regarding github.com/perl6/nqp/compare/maste...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?
pmichaud cotto: I've never been a fan of the supported/developer release tagging.
Coke suggestion: put everything in the "developer" bucket going forward 18:59
cotto great
allison Coke: as a distro packager, I can say that doesn't work
cotto Coke: I'm happy with that plan.
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.
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
Coke allison: fine. if the buckets don't matter to us, and they matter to you, we put them all in "supported"
so don't put them all in.
allison Coke: so, whatever Parrot calls them, please pick 2-4 releases a year to designate as distro releases
Coke why?
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.
allison you can't tell people "oh, just upgrade to the next month releases"
Coke let's back up a second. How does making things easy for packages help us with rakudo?
and do we care if we are bundled separately from rakudo?
allison because rakudo lives or dies by its availibility in releases
not_gerd gone for a bit, back in a minute
pmichaud just an aside that rakudo cares about packaging issues
(which is why I brought the topic up) 19:02
allison (by "releases" there, I meant "distro releases")
Coke allison: rakudo ships its own package, outside the scope of the released ones.
allison Coke: the only packages that matter are the ones in Debian/Ubuntu/Fedora
sorry, that's just the way the world works
pmichaud Coke: rakudo ships its own package, yes, but it's tied to specific Parrot packages
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.
benabik rakudo requires parrot = x.y.z ?
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)
pmichaud if we publish a Rakudo release that depends on Parrot 5.1.0, that Rakudo release will never appear in a Debian distribution.
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?
Coke Why even do monthly releases at that point, I wonder. 19:05
allison we can designate them "distro", if that helps
Coke changing the names doesnt help, no.
allison Coke: I was wondering that myself
Coke it's one more infrastructure thing to change.
allison cotto: and, yes, it's perfectly reasonable to flex the schedule 19:06
cotto: whenever we're ready to make a Rakudo release for distros, we pair it with a Parrot "supported" release
if that's once a year, fine
twice a year, fine
19:08 Mike-PerlRecruiter_ joined
cotto excellent 19:08
That'll give us the flexibility we need.
pmichaud: how's that sound do you? 19:09
pmichaud Like the beginning of a plan, but not a complete one.
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:10
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.
allison pmichaud: it's currently at 4.6.0
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
pmichaud: ok, I'll do that, and we'll coordinate a compatible rakudo package version to go with it
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
pmichaud (last packaged version) yeah, that's part of the reason I'm wary of doing too much backwards-incompatible stuff with rakudo/nqp
allison wheezy's rakudo is 0.1~2012.01-1
(which makes sense, as the packaging is done in lock step) 19:14
Coke why even bother with such an old version?
does it actually help get people onto rakudo/parrot, or does it result mainly in "why is my rakudo broken?"
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.
allison debian has strict guidelines about when a package migrates from "unstable" to "testing"
pmichaud: I don't actually own the rakudo packages, but I work with the DDs who do 19:15
Coke: "unstable" is pretty open, and it's actually what Ubuntu pulls from
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.
allison Coke: which parrot and rakudo aren't doing right now
ay, "wheezy" is "testing"
and will become the next "stable"
Coke so the /testing/ release is a year old?
allison yup 19:17
Coke that seems insane.
allison this is what people complain about in Debian
Coke are there tickets open for whatever is blocking us from getting a newer version in there?
allison but, it does make for a very stable base
pmichaud I should say I'm less concerned about Debian itself than Ubuntu, fwiw.
allison pmichaud: aye, but Ubuntu pulls from Debian "unstable", so that's easier to keep current 19:18
19:18 kid51 joined
allison pmichaud: "unstable" has 2012.10 19:18
Coke: I know there are tickets for some, but I'm not sure if they're all ticketed 19:21
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.
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
uvtc This might be a silly question: given Parrot's current goals, why not package it together with Rakudo (wrt Debian, Ubuntu, Redhat)? 19:27
As one package. 19:28
moritz uvtc: I'm not sure how well that align with Rakudo's goals
cotto uvtc: I was wondering that too.
moritz uvtc: rakudo's goal is to run on multiple VMs in the future (where "multiple" can be larger than 2)
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
allison uvtc: that's not the way Debian packaging works 19:31
dalek p: f8a37df | (Tobias Leich)++ | / (4 files):
add sequential array interpolation switch

Arrays in regexes will match sequential if preceded by ||.
allison uvtc: in fact, the Parrot and Rakudo "source" packages actually each split into multiple "binary" packages
Coke which is crazy.
allison nope, it makes perfect sense 19:32
it allows flexibility in what's actually installed
pmichaud Parrot was never intended to be "for Rakudo only", so it should get a separate packaging name.
dalek rrot: ab955c5 | util++ | / (2 files):
Prepare for the 5.1.0 release
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
pmichaud: maybe, we'll about names when we get there
*we'll see
uvtc Whoops --- sorry. Given the time, I probably should've asked that question on #parrotsketch.
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
pmichaud: and, to be honest, the rakudo packages are the only ones that depend on the parrot packages anyway :)
19:35 uvtc left
PerlJam Does parrot still have issues building when there's already a parrot installed? 20:11
cotto PerlJam: I don't believe so.
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.
(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)_
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.
(different install dirs)
PerlJam ok 20:15
thanks all :)
dalek rrot/sixparrot-nci: 9f849dd | (Jon Gentle)++ | / (14 files):
Remove PCRE
 20:16
rrot/sixparrot-nci: 061a519 | (Jon Gentle)++ | / (52 files):
Remove curses, postgres and sdl
rrot/sixparrot-nci: c9b23ac | (Jon Gentle)++ | examples/opengl/ (8 files):
Remove more OpenGL stuff
rrot/sixparrot-nci: f0c2744 | (Jon Gentle)++ | / (7 files):
Remove dlfunc and dlvar
rrot/sixparrot-nci: f2918e8 | (Jon Gentle)++ | src/multidispatch.c:
Remove NCI from multidispatch
rrot/sixparrot-nci: 2f2c720 | (Jon Gentle)++ | / (3 files):
Remove the guts of nci.pmc
rrot/sixparrot-nci: 215dc42 | (Jon Gentle)++ | / (6 files):
Remove has_core_nci_thunks and has_extra_nci_thunks
rrot/sixparrot-nci: 8f32960 | (Jon Gentle)++ | / (5 files):
Remove the nci dev tools
rrot/sixparrot-nci: bd00503 | (Jon Gentle)++ | / (29 files):
Gut a good portion of nci
rrot/sixparrot-nci: 2cf45b2 | (Jon Gentle)++ | src/ (3 files):
Remove uses of enum_class_NCI
rrot/sixparrot-nci: d770f20 | (Jon Gentle)++ | / (5 files):
Gut nci.h
rrot/sixparrot-nci: f098bf3 | (Jon Gentle)++ | / (8 files):
Remove nci.pmc and nci.h
cotto wheee 20:17
dalek kudo/nom: 8e6fa0b | (Tobias Leich)++ | / (3 files):
add array in regex interpolation feature

Arrays withinn regex will be treated as alternations of its elements. Preceding | or || will change its behaviour, || means sequential alt- ernation and | LTM, while the LTM is just a basic approach and needs tweeking.		 20:18
atrodo sixparrot-nci is ready to be looked at and possibly merged with sixparrot 20:24
it compiles and passes rakudo with no problems for me
20:25 benabik joined
cotto atrodo: including rakudo spectest? 20:25
atrodo cotto: Including spectest
cotto atrodo++
atrodo I think I need to update my version of Rakudo, but it fails exactly the same spectests as master 20:26
dalek kudo/agressive-sink-warnings: 80f788b | moritz++ | src/Perl6/Optimizer.pm:
Warn when pure expressions are used in sink context

even if the arguments are not constant, or the expression warns. By explicit request from TimToady++ at
  irclog.perlgeek.de/perl6/2013-02-18#i_6469204		 20:32
kudo/agressive-sink-warnings: 2f210be | moritz++ | src/Perl6/Optimizer.pm:
awesomify sink context warning text
21:16 donaldh joined 21:50 masak joined
not_gerd masak: look for example at Rust's threading system - there's no sharing 21:50
you can only move unique pointers between threads
only the thread owning that pointer may modify the object 21:51
this is limiting on comparison to everything goes shared-by-default threading implementations
nevertheless, you can do useful stuff
rurban Perljam: osx and cygwin has problems with an installed parrot, all others not
21:51 benabik joined
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
for some value of 'just', of course
Coke Answering pmichaud's coding sample would be most helpful.
21:52 jsut left
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.
wrote about*
not_gerd have the link ready? 21:54
I thought it was a case of the XY-problem, but I might be mistaken
masak not_gerd: lists.parrot.org/pipermail/parrot-d...07296.html
not_gerd masak++
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
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
masak even if he's *wrong*, how can such an email go unanswered for such a long time?
allison masak: because other things are more important right now
masak: and no one feels like arguing about it
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.
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
masak right.
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)
masak fwiw, diakopter seems to have a point here, even if no-one has the strength to argue against him.
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.
rurban no, it's not my code at all. it's stefans code, and he should answer it.
allison masak: I'm going with 50/50 chance he's right at t this point
PerlJam masak: my reading of diakopter's email just now seems to be a longish way of saying "proxies leak"
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.
not_gerd masak: the point is not if there is a problem, but rather if its fatal
reference counters can't collect cycles
rurban we know that proxies leak when created via other threads
not_gerd is refcounting therefore not useful?
rurban but in the very end they are collected 22:01
but as we do not create proxies from subthreads it's fud
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
PerlJam not_gerd++ code trumps speculation
not_gerd no one has done that yet for Parrot's threading system 22:02
but *because* no one has done that yet, it's premature to say that it's not useful
rurban several real world problems are in examples/thread already
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
Coke so perhaps they could use some more documentation as to what to expect.
rurban Coke: which OS did hang?
Coke s/hang/run a long time/
OS X.
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:04
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
OS X with threads should not run the GC validator
Coke Ok. I have no idea what that means. I did a build with no config options. 22:08
(if there are required options for OS X, I think we can add that to the defaults in config/ somewhere.)
rurban then you have a slow mac. all examples run fine on my macbook air
22:08 ctult_ joined
Coke or prohibited ones. 22:09
benabik I think debug is enabled by default.
Coke I have a macbook air with quad cores and 4GB of memory. Seems pretty zippy.
benabik My build script has a --debugging=0 in it.
IIRC
Coke so, all those examples should terminate quickly? 22:10
rurban I've also added threads and gc stress tests
no, the thread samples can run very long
lemme time it...
Coke rurban, you can be a very frustrating person to have a conversation with.
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
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 real\t0m10.063s
10s is very long 22:13
and the other tests need much more time
PerlJam Reini: would those take very very very long? :)
Reini on a slow mac 10s will be 40s
and this is the fastest test 22:14
benabik Slow programs should perhaps output progress...
Reini yes, maybe
Coke *sigh*
Reini but you could also look at them what they are doing
benabik But documentation would be really best.
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.
I'll open a ticket. 22:16
Reini what for?
the ones which need more than 10s do output progress
Coke nevermind. 22:17
I really can't waste anymore positive energy trying to steer threads in a helpful direction. 22:18
thank for all the effort on the code side, though.
Reini you could help by stopping the stupid rumors at the perl6 side. 22:19
time ./parrot examples/threads/moretasks.pir needs several minutes and is printing a lot of progress
Coke Reini: you're giving me nothing to help you. Sorry. 22:20
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
and to all the other GIL langs
(global interpreter lock)
benabik Parrot threads are basically orthogonal to JVM threads. 22:22
rurban I am having more a problem with chromatic declaring parrot publicly dead
benabik Wholly different programming model. Which is better is highly dependent on what you understand.
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.
rurban it is dead for him since a year, but he should not kill perl6
Coke so ignore him. Or do good things instead. Don't let him piss you off. 22:23
benabik +
+1
rurban alloc_test.pir is running in an endless LOOP AFAIR
benabik Really, +(as many as I'm allowed)
rurban I did ignored chromatic, but then the old parrot managers declared parrot dead 22:24
Coke ... who?
rurban coke, allison, chromatic
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.
benabik Open source projects are only dead when nobody is involved in them. Parrot has been limping along with minimal participation for months now.
Coke let's not go down that path of "he said, she said" again without having some links.
benabik s/ without.*//
Coke rurban: I'm not doing anything desperate. I'm working on a branch.
rurban minimal participation with many exciting features and progress 22:26
allison Coke: he might mean me
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.
allison benabik: years, more like
rurban I haven't looked who said what.
cotto pretty much
Coke ah, well make sure you attribute things incorrectly up front. very helpful.
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
rurban yes, on p2 and helping out parrot
perl6 needs parrot alive. 22:28
allison rurban: hmmm... I think I won't go there
rurban and not declared dead by some outsiders who have no idea
allison it has been very, very sick for a long time
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.
benabik allison: I somewhat object to that...
allison possibly all the way back to the Dan/Leo flamewars 22:29
benabik: I'm at a point in the grieving process where I accept all that's past
benabik: and accepting it gives me the freedom to focus on the future
rurban And I'm at a point where I cannot accept more damage being done. 22:30
So far the cleanup were pretty okay so. good work
benabik allison: The last couple of years may not have been as active as previously, but there have still been people working on it.
rurban but I'm afraid some pretty bad decision will be made.
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
benabik As opposed to the last few months while most of the developers have done basically nothing.
Coke rurban: yes, of course rakudo will have a veto.
rurban: that's the entire point of the sixparrot branch.
rurban good
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
Coke so, instead of coming in here and spreading FUD, perhaps you could talk to us first. :)
rurban I haven't quit. I never said that
allison benabik: I was only following just enough to see that there was *some* activity
Coke that was the impression many of us seem to have taken with your announcement about p2. Apologies.
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
allison rurban: that's great, nothing to be ashamed about there
rurban and fperrad is also working on a similar vm
cotto I hope whiteknight takes a nice tropical vacation. He needs to un-burn himself out.
benabik cotto: I'm in academia. That doesn't bother me. ;-)
allison rurban: your interests are elsewhere, that's totally cool
rurban so everything will be fine
my interests are perl
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
not_gerd I calling it tentatively m42, because it's my answer to m0
allison even have a gitorious repo staked out for it
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.
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:37
it may be *better* in some cases 22:38
but never easier
(and often it's not even better)
cotto You see all the problems that exist but rarely the ones that have been solved.
allison aye
because they aren't pain points
they just work
masak depends what you mean by "from scratch". 22:39
allison m0 22:40
not_gerd that's where I'm at, if anyone is interested: gist.github.com/gerdr/4990845
allison or, for that matter, Perl 6 itself
which I still think is a good idea
but, I don't think anyone could argue Perl 6 has been *easier* than patching up Perl 5
and so far, it's not even better, but it has potential to be better 22:41
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"
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:43
masak *nod* 22:46
Coke it would be helpful if someone could add "threads" as a github issue label, and then tag issue #936 22:52
benabik Coke: done 22:53
Coke benabik++ 22:54
not_gerd good night, #parrot 22:57
22:57 not_gerd left
pmichaud adds the "threads" label to #889 22:57
Coke is there a way to disable paging on SOME irssi windows? 23:04
Util Proposal for Perl-NG Hackathon is now codified: 23:36
www.yapcna.org/yn2013/wiki?node=Hackathons
ideas.yapcna.org/idea/6290DA56-7AEB...-hackathon
If you are interested in attending, based on the first link, please click "Interested" on the second link. Thanks!
cotto Util: thanks 23:38
23:49 kid51 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!