Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-28

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:47 PacoLinux joined #parrot
00:51 patspam joined #parrot
00:55 PacoLinux joined #parrot
01:05 PacoLinux joined #parrot
01:51 s1n i'd like to inquire about cage cleaning, who's the right person to speak with?
01:57 zak_ joined #parrot
02:00 baest joined #parrot
02:01 Infinoid s1n: You're in the right place, though I can't point to a particular person :)
02:02 burmas joined #parrot
02:02 Infinoid As mentioned before, there isn't a formal process, there is some documentation which we've already mentioned
02:02 Infinoid But if you have a more specific question, you can just ask directly and whoever's awake will answer
02:22 Zak joined #parrot
02:32 kid51 joined #parrot
02:35 janus joined #parrot
02:38 rdice joined #parrot
02:39 mikehh_ joined #parrot
02:59 particle joined #parrot
03:08 tetragon_ joined #parrot
03:29 tetragon joined #parrot
03:35 Theory joined #parrot
03:42 jdv79 joined #parrot
04:20 s1n i'm actually interested in doing some cage cleaning work and wanted to know where to start. i've sifted through the pod on this but was wondering how people find things that need cleaning
04:21 mikehh pre/pos config, smoke, fulltest All PASS - r39811 on Ubuntu 9.04 Amd64
04:21 mikehh post
04:24 mikehh s1n: one thing to look at is the results of tests, especially codetest - there are some TODO failures there
04:25 mikehh things like missing POD and such like
04:25 s1n mikehh: thanks
04:33 jdv79 reading andrews blog about L1 and related.  my first question is how the hell did we get here?
04:33 jdv79 ugh
04:37 s1n jdv79: most of those posts were directly inspired by the parrot workshop last week
04:37 mikehh jdv79: I think it's a case of prioritizing and looking for ways to improve what we have
04:40 mikehh chromatic has been pushing, for a while, for a way to move away from the reliance on C
04:41 mikehh L1 provides a good way to move toward this
04:46 * skids beginning to think C needs a real competitor (not just in the Parrot area.)
04:46 skids Some not-oo, architecture-aware lowlevel language.
04:47 skids But I doubt that's a good tangent to go off on in Parrot's case.
04:53 jdv79 that's not what i meant.  i mean how did it come to be that parrot is implemented in a way that seems obviously flawed.
04:54 jdv79 i was at the workshop
04:54 jdv79 unfortunately i hadn't looked at parrot beforehand so i was kinda dazed and confused.  trying to research up now.
04:55 mikehh people moving in different directions
04:55 chromatic Some flaws are obvious only in retrospect.
04:56 mikehh sometimes you can only find things out if you try it
04:57 jdv79 chromatic: that's kinda what i thought.
04:57 mikehh we are working on some new concepts here - at least as far as the "real world" is concerned
04:59 mikehh a lot of research works on specific concepts and usually involving one or two researchers
05:00 mikehh here we have a lot of concepts thrown together in a large project with lots of independent developers
05:00 mikehh and not that much control
05:01 jdv79 are VMs that cutting edge?  why can't parrot attract more established VM talent?
05:02 mikehh We are looking at a VM aimed at dynamic languages here
05:02 mberends jdv79: what do you mean by obviously flawed?
05:02 mikehh most other VM's are for static languages
05:02 jdv79 calling back and forth between c and pir through multiple runloops for starters
05:03 mberends jdv79: ok, that would not be elegant
05:04 mikehh that is probably the most obvious problem we have and what L1 is a possible resolution
05:05 mikehh that doesn't parse right - I think I need some sleep
05:05 cotto chromatic, ping
05:06 jdv79 why L1?  why not just reduce the existing ops and push the remaining complexity up the stack?
05:06 cotto jdv79, that'd basically be L1
05:07 jdv79 thanks.  ok, back to reading.
05:07 mikehh there are other possible solutions but I like the L1 one
05:08 jdv79 have they been voiced?  i'd like to hear about them.
05:08 cotto obviously depending on how extreme a reduction you'd propose
05:08 cotto mikehh, please speak up if you have possible alternatives.
05:09 cotto This is the perfect time to make them known, since L1 is still very much at the idea stage.
05:09 mikehh I think L1 is the best altertnative at the moment
05:11 cotto Worse alternatives are good too.  If they have advantages we can integrate them into L1.
05:11 cotto Even if not, it's good to think in different terms to solve a problem.
05:12 mberends is there a faint echo of Perl 5 stagnation in 2000 sounding? "Current architecture unwieldy.. Need a fresh start.."
05:14 mikehh a lot of the code we are working with, for example, imcc, has suffered serious bitrot, and is due to be replaced,
05:14 cotto It's not an issue of stagnation, but the architecture is getting in the way in many places.
05:16 mikehh In a lot of cases we have lost sight of the KISS principal
05:16 cotto I like the idea of a nanoparrot that's only capable of interpreting L1, then having all sorts of shiny built on top of that.
05:17 mikehh me too
05:18 cotto The name is a little deceptive.  It'll be a significantly smaller executable but not quite at the level of a bf interpreter.
05:20 mikehh One of the problems, I think, has been, too many different things added, without getting things working properly first.
05:21 cotto I'm sure libparrot will be smaller than 3.6M stripped, though.  Eek.
05:22 * cotto gets back to pmcc, hoping that chromatic will show up before I collapse into an unconscious state, possibly accompanied by hallucinations and subsequent memory loss.
05:23 mikehh we really need to get that going
05:24 cotto It's happening, though slowly.  There's a faint possibility that it'll be ready for 1.4.
05:25 mikehh that would be realkly nice
05:25 cotto if not that, I'd be deeply disappointed if it wasn't in 1.5.
05:25 mberends to me as a new parrot user, the implementation of 'not stack based' seems to have overshot the mark. The heap gets a heavier load, with more housekeeping debt. Or what am I missing?
05:26 * cotto minimizes irc
05:27 chromatic pong
05:28 cotto and unminimizes it just in time to see chromatic's pong
05:30 chromatic I'm not sure how to reconcile stack-based with pervasive CPS and first-class continuations.
05:31 mikehh_ joined #parrot
05:33 brbrooks joined #parrot
05:37 mberends parrot seems to use a heap of stacks in places, probably for continuations
05:38 chromatic If that were true (and I don't believe it is), I'm not sure how first-class continuations would work.
05:39 chromatic Control flow in that case is an acyclic graph.
05:40 * mberends will read more docs before getting even more out of depth
05:51 bacek_ joined #parrot
05:53 bacek_ o hai
05:54 bacek_ cotto: ping
05:55 brbrooks joined #parrot
05:55 brbrooks_ joined #parrot
05:55 cotto bacek_, I see your ping and raise you a pong
05:56 bacek_ cotto: I have something for you to sleep on it.
05:56 cotto I was going to use my futon, but go ahead
05:57 bacek_ Abandon pmcc. It's useless. Switch to ops. PMC can be implemented as current PIR + little bit of L1 ops.
05:57 cotto orly?
05:57 purl YA RLY.
05:57 bacek_ purl++
05:57 chromatic Sounds risky.
05:57 bacek_ Actually no.
05:58 bacek_ ops are smaller.
05:58 cotto I am intrigued by your proposal.
05:58 bacek_ L1 will include some low-level stuff to access raw-memory.
05:58 chromatic pmcc has the nice benefit of working in small steps.
05:59 cotto exactly what I was going to say
05:59 bacek_ So, all "high-level" structures in PMCs can be implemented as NQP/PIR + little bit of L1
05:59 bacek_ "ops" are even smaller
05:59 cotto Yes, but wouldn't we have to rewrite them all?
06:00 bacek_ imcc/pirc support ":method" and ":vtable" already, so there is no value to parse current "pseudo-C"
06:00 bacek_ cotto: in bright shiny future - yes.
06:01 cotto bacek_, I mean that we couldn't do it as a gradual change like we can with pmcc, i.e. have a usable release where only some PMCs are converted.
06:01 bacek_ cotto: we can.
06:01 bacek_ Just replace some PMCs with PIR/NQP based
06:02 abesapien joined #parrot
06:02 bacek_ But we don't need to parse current PMCs.
06:02 bacek_ It's throw-away job (Yes, I'm repeating myself)
06:03 cotto That's definitely worth thinking about.
06:03 chromatic I still don't follow.
06:03 cotto bacek++
06:04 bacek_ (clarifying myself) We can avoid step with generating C code.
06:04 bacek_ 1. Implement Integer PMC in PIR.
06:04 cotto I think he's saying that we start now reimplementing PMC in nqp and PIR
06:04 jsut joined #parrot
06:05 bacek_ 2. Check which ops are missing for low-level stuff
06:05 bacek_ 3. Add them to L1 dynops.
06:05 bacek_ ...
06:05 bacek_ 5. Profit!
06:05 cotto your plans always end the same way
06:05 cotto There's more to life than profit.
06:05 bacek_ ok, scratch step 5.
06:05 chromatic If that doesn't work, we don't have a good way to dump Perl 5 from the PMC building process.
06:05 cotto What about world peace or ponies?
06:05 bacek_ new 5. World domination.
06:06 cotto That implies a certain level of peace.  Sounds good.
06:06 bacek_ chromatic: it will.
06:06 bacek_ It's simplified version of original plan.
06:07 chromatic Sure, and you can simplify it further by working in bigger steps.  I'm not sure that's wise.
06:07 bacek_ And, honestly, I don't see and benefits from getting rid of Perl5 just for getting rid of Perl5.
06:07 bacek_ chromatic: emitting C from NQP isn't big step. It's HUGE step.
06:08 chromatic It's about as big as emitting L1 from NQP.
06:08 chromatic Perhaps smaller.
06:08 bacek_ as first-cut we can skip emitting L1 from NQP.
06:08 cotto L1->C and nqp->L1 can be worked on in parallel too
06:09 bacek_ Just go NQP->PIR->L1
06:09 bacek_ because we'll need "PIR->L1" anyway.
06:09 bacek_ And we already have "NQP->PIR"
06:09 chromatic Yes, but we *don't know* if NQP->L1 will work.
06:10 bacek_ Ok. PIR->L1 should work?
06:10 chromatic We *know* pmcc->C will work, because we *know* Perl 5->C works.
06:13 bacek_ Should PIR->L1 work?
06:14 cotto yes, by definition
06:14 chromatic Once we reach the point where we know L1 itself works.
06:14 bacek_ ok, Does NQP->L1 work?
06:15 chromatic Hopefully.
06:15 cotto I think the issue is the sufficiency of nqp for implementing PMCs.  If/when that's solved, I think bacek's idea would work.
06:15 bacek_ ok, Does NQP->PIR work?
06:15 bacek_ NQP _is_ sufficient.
06:16 chromatic NQP is sufficient only in so far as what it can emit is sufficient.
06:16 cotto not as it stands today
06:16 bacek_ NQP can emit PIR
06:16 bacek_ NQP can embed PIR
06:16 bacek_ PIR can be converted into L1
06:16 bacek_ NQP is sufficient
06:17 cotto I'm not convinced we can do everything the C PMCs do in nqp
06:17 chromatic I'm not convinced we know how PIR can be converted into L1.
06:18 bacek_ chromatic: exactly. That's why I propose to start with "ops", not "pmc"
06:18 bacek_ consider simple "op fdiv"
06:19 bacek_ It's exposing calling plain-C function.
06:19 chromatic Consider how you dispatch those ops now.
06:19 bacek_ And it's oneliner
06:19 chromatic Can we convert those ops piecemeal?
06:19 chromatic Or is it (as I suspect) all or nothing?
06:20 * bacek_ imaging half-pregnant girl
06:20 chromatic What does that do to our runloop?
06:20 bacek_ "op fdiv" converted to "sub fdiv".
06:20 bacek_ which is L1 sub
06:21 chromatic L1 oughtn't know anything about subs.
06:21 chromatic That's much too high a level.
06:21 bacek_ (In next few months we implement in-lining to avoid call)
06:21 bacek_ erm....
06:22 bacek_ How are you going to implement sub calls on top of L1 dispatcher?
06:22 chromatic Answer me this: which existing ops know anything about subs?
06:23 bacek_ "invoke"?
06:23 chromatic If you want to get very, very technical, you can come up with a few.
06:24 chromatic L1 only needs to be able to tell the runloop the next op to execute.
06:27 bacek_ same for current ops, isn't it?
06:27 cotto bacek_, if your idea survives its encounter with chromatic could you send a quick summary of your plan to the list?
06:27 bacek_ cotto: I'll try
06:28 chromatic Even if it doesn't.  I'm suffering jet lag and am not sure I'm thinking it through.
06:28 bacek_ but chromatic is tough :)
06:28 chromatic Sure, it's the same for current ops.
06:28 cotto Thanks.
06:28 cotto I'm off to bed.
06:28 cotto night
06:28 bacek_ chromatic: night
06:28 chromatic I don't see how turning fdiv into a subroutine helps though.  That seems to push a higher level abstraction down into L1 where I don't think it belongs.
06:29 bacek_ chromatic: I don't pushing it down
06:29 bacek_ I actually pushing it up
06:29 chromatic I don't see how.
06:29 bacek_ All PIR "ops" are "subs" from L1 point of view
06:29 bacek_ isn't it?
06:30 chromatic That depends what you mean by "subs".
06:30 chromatic I figure there's a PCT-based ops parser that emits L1.
06:30 bacek_ But I can also emit "subs".
06:31 chromatic What do you mean by "subs"?
06:31 bacek_ ".sub fdiv; ... L1 body ... .end"
06:32 chromatic Why do that?
06:32 bacek_ Drop src/ops/*.ops?
06:33 chromatic Why do that?
06:33 bacek_ Actually rewrite them in L1.
06:33 chromatic That's always been my plan.
06:33 bacek_ Yes. I'm totally on your side
06:34 chromatic Why turn our existing ops (L2, let's say) into subs?
06:35 bacek_ Ok, not "subs". But from external point of view they are "subs" implemented in L1
06:35 chromatic I don't see how.  We don't pass parameters in and we don't get results back.
06:35 chromatic If we can optimize L1 across L2 op boundaries, we do it aggressively.
06:37 bacek_ erm...
06:37 bacek_ Let rephrase myself.
06:37 bacek_ "op foo" in L2 when I read sources is just some subroutine in some language.
06:37 bacek_ currently it's pseudo-C.
06:37 dalek parrot: r39812 | petdance++ | trunk/src/packdump.c:
06:37 dalek parrot: fixing some splint flags
06:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39812/
06:38 bacek_ In bright future it's L1.
06:39 chromatic It's only a subroutine in C for the default slow core.
06:39 bacek_ Those subroutines are small, understandable and (almost) have no more than 5 lines of code.
06:39 chromatic By "sub" do you mean "discrete unit of L1 ops"?
06:39 chromatic I can get behind that.
06:40 bacek_ Ah. Yes. Sorry for my bad 4th language
06:40 chromatic No problem, I just wanted to make sure.
06:41 bacek_ So, reimplementing such "subs" in L1 we'll have almost clear understanding of L1 requirements.
06:41 chromatic The same way we would if we reimplemented PMCs in terms of L1.
06:42 chromatic Except that the body of an op is generally much smaller and simpler than a PMC as a whole.
06:42 bacek_ My point is - ops are much smaller, than PMCs.
06:42 chromatic Which has some compelling in the argument.
06:43 * bacek_ looking for translation of "compelling"
06:43 chromatic You make a good point.
06:45 bacek_ Hooray. I finally explained my point of view in this barbarian language :)
06:45 chromatic Barbarian?  We're not speaking Australian, mate.
06:46 bacek_ So, If we have working "pir ops->L1" translation we can start re-implementing PMCs in NQP/PIR using L1 ops directly when required.
06:46 chromatic Or vice versa.
06:46 chromatic But I see your point.
06:47 bacek_ But ops _are_ smaller and simpler.
06:47 chromatic Right.
06:48 bacek_ I'm usually hate to dump my own code... But in this case it's better to dump pmcc.
06:48 chromatic I don't think we need to dump pmcc.
06:49 chromatic We need something like it eventually.
06:49 bacek_ Of cause.
06:49 bacek_ But... imcc/pirc can compiler pir already.
06:49 chromatic I don't see how that matters.
06:50 bacek_ Current PMC can be translated into PIR with few ":method" and ":vtable" subs.
06:50 bacek_ We can express almost everything in it.
06:50 chromatic I don't believe that.
06:51 bacek_ Why?
06:51 chromatic I've hacked too many PMCs.
06:52 bacek_ heh. Doesn't count. I've hacked many on them too :)
06:54 bacek_ Actually, current VTABLEs is hack to speed up MMD over first argument.
06:55 chromatic Sure.
06:55 bacek_ s/is/are/
06:55 chromatic I don't understand the benefit of writing PMCs in PIR.
06:55 tetragon joined #parrot
06:55 bacek_ We can write them in NQP.
06:55 bacek_ Or Close
06:56 bacek_ Or anything else.
06:56 purl anything else is violating dry. and we're in the wrong channel.
06:56 bacek_ ...which emits "PIR"
06:56 chromatic Why would it emit PIR?
06:56 bacek_ shortcut to reduce effort.
06:56 chromatic How so?
06:57 bacek_ 1. We _have_ to emit L1 from PIR.
06:57 bacek_ 2. Many compilers already emit PIR
06:57 bacek_ So, we can use current compilers without adjusting to use with L1.
06:58 chromatic I see.
06:58 chromatic You're assuming that we can write everything currently in C for PMCs in PIR, if PIR supports L1.
06:58 chromatic I'm assuming that it's easier to write everything currently in C for PMCs in something that compiles to L1 directly.
06:58 bacek_ L1+PIr actually
07:00 chromatic I guess that's possible.
07:00 bacek_ Oh... Did you check how many LOC in "to_pir" methods in PCT? It's not a small chunk of work
07:01 chromatic Sure.  Writing emitters is not always easy.
07:02 chromatic Of course, PIR doesn't always make that easy.
07:02 bacek_ L1 will not make it easier.
07:03 chromatic That depends how far L1 is from Close/NQP/whatever.
07:03 bacek_ With my proposal it doesn't matter.
07:04 chromatic I need to think about it more.
07:04 bacek_ PCT will emit PIR+L1-ops
07:04 maettu joined #parrot
07:04 bacek_ And it can do it already
07:05 chromatic I don't like something about it, but I can't tell you what or why.
07:05 chromatic Please do write it up though.
07:06 bacek_ There is a lot of sharp corners of cause.
07:07 bacek_ I'll try to write some summary tomorrow. I have to sleep on this little bit more.
07:07 chromatic Me too.
07:08 bacek_ chromatic: ok
07:10 maettu noob question: after checking out the svn, can I install parrot like described in /docs/book/ch02_getting_started.pod.html ?
07:11 chromatic I believe so, maettu.
07:12 maettu do I type 'B<perl Configure.pl>' or just 'perl Configure.pl'?
07:13 chromatic perl Configure.pl
07:13 chromatic B<...> is formatting.
07:13 maettu ah! should this be changed on the mentioned webpage?
07:14 chromatic Yes.
07:14 maettu how could I help with this?
07:14 chromatic Though the right fix is to use ppod2html instead of pod2html, which requires the use of Pod::PseudoPod instead of Pod::Simple.
07:19 maettu ..and one should preferably install as an admin (on linux)? Could I insert this in the page mentioned?
07:19 chromatic Install Parrot as admin?
07:19 maettu well yes, it writes to /usr/local (I mean you need to be root or something) :-)
07:24 chromatic Yes, if you want to install it there.  There's a Configure.pl argument to install it elsewhere.  That's why I was confused.
07:26 maettu thanks! parrot up & running :-) (by the way, love your blog!)
07:28 chromatic Thank you.
07:28 chromatic I love... the air.
07:30 maettu there is only an 0.7 - debian - parrot or something on parrot.org. I would be ready to build parrot from time to time and send it in, if you tell me how
07:32 maettu (if it makes sense, at all)
07:34 maettu there is a small typo on /html/book/ch03_pir.pod.html in "Variables": "mroe" instead of "more"
07:36 maettu and under "Strings: Encodings an Charsets", shouldn't it be "older times" instead of "olden times"?
07:40 dukeleto joined #parrot
07:40 mberends maettu: "mroe" is wrong, but "olden times" is fine.
07:41 maettu ok, I corrected the typo in my local copy. What's next?
07:44 bacek_ maettu: in this case - relax :) In other cases feel free to open ticket at parrot's trac.
07:45 dalek parrot: r39813 | bacek++ | trunk/docs/book/draft/ch03_pir.pod:
07:45 dalek parrot: Fix typo. maettu++
07:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39813/
07:45 bacek_ parrotbug?
07:45 purl rumour has it parrotbug is obsolete, use https://trac.parrot.org/
07:46 bacek_ maettu:  https://trac.parrot.org/ (You'll need a trivial registering)
07:47 maettu thanks, I do. I'm very relaxed, :-) just trying to help out a little bit
07:47 bacek_ I just did it :)
07:47 maettu thanks!
07:50 bacek_ No. Thank _you_ for spotting this.
08:02 muixirt joined #parrot
08:02 maettu I think i like parrot :-)
08:11 bacek_ maettu: You are welcome :)
08:13 MoC joined #parrot
08:13 bacek_ maettu: Every contribution matter.
08:13 maettu welcome
08:16 iblechbot joined #parrot
08:21 bacek_ maettu: anyway, if you think that something is wrong can be improved, feel free to send patches to trac/mailinglist.
08:22 maettu i will
08:22 bacek_ maettu: thanks!
08:32 Khisanth joined #parrot
08:35 snarkyboojum joined #parrot
08:59 tetragon joined #parrot
09:10 tetragon joined #parrot
09:15 maettu i've just done a little experiment with a (recursive) program and found that .pir is *much* slower than the compiled c - equivalent.
09:46 Zak joined #parrot
09:51 eiro__ joined #parrot
10:04 tetragon joined #parrot
10:14 jonathan joined #parrot
10:23 shorten joined #parrot
10:47 zak_ joined #parrot
11:23 snarkyboojum joined #parrot
12:01 particle1 joined #parrot
12:03 masak joined #parrot
12:09 elmex joined #parrot
12:14 dalek TT #798 created by richardh++: [BUG] and [PATCH] SDL Font color is wrong
12:18 maettu left #parrot
12:26 Whiteknight joined #parrot
12:41 Whiteknight good morning
12:41 purl And good moroning to you, Whiteknight.
12:41 Whiteknight purl, you're an asshole
12:41 purl Whiteknight: sorry...
12:44 Infinoid hah
12:44 Infinoid morning Whiteknight
12:45 Infinoid I don't know if I mentioned this already, but I checked out the t/op/io.t failure you were getting in io_cleanups
12:45 Whiteknight yeah, I think you said something yesterday about it
12:45 Whiteknight about how we need to better integrate pipe logic into the IO API
12:46 Infinoid This particular case would be pretty easy to fix, except that there's even more functionality than we (or at least I) expected, bundled in the FileHandle behemoth
12:46 Infinoid It creates what amounts to a simple pipe... except that it also has a waitpid() for the child process on destruction
12:46 Whiteknight yeah, we really need to separate that out
12:47 Whiteknight unfortunately we can't really remove functionality from FileHandle without a deprecation
12:47 Infinoid I didn't anticipate that, I guess it's something else we need to add to Pipe (or wherever)
12:48 Infinoid I suppose it isn't that bad, I can just add a "pid" attribute and some -1 default so it knows whether to do that or not
12:48 Infinoid I worried a bit in-channel lastnight about how this will cause the GC to hang if you happen to spawn a child process that closes stdout and keeps running
12:48 Whiteknight okay, let's "fix" the test so that it doesn't error, and we'll put in a deprecation notice about the Pipe-like behaviors of FileHandle
12:48 Infinoid I can add the pid handling to pipes and leave filehandle alone for the moment
12:48 Whiteknight post-1.4 sometime we create a new branch to make the switch-over to using the Pipe class
12:49 Whiteknight okay, that's good
12:50 Whiteknight I'm still trying to figure out why Parrot_io_open_pipe_unix is calling set_integer_keyed, none of the IO types even implement that vtable
12:51 Infinoid Oh, that's how it stashes the child pid so it can waitpid() on destruction
12:51 startPerl joined #parrot
12:51 Infinoid It really should be using an attr for that.
12:51 Infinoid But we're moving it into a different PMC anyway, so it doesn't matter
12:51 Whiteknight ok
12:52 startPerl Whiteknight: reading your blog quite often
12:52 Whiteknight startPerl: awesome! let me know what you think about it
12:52 startPerl Whiteknight: I think that I'd like to write some damn code but it all seems so damn complicated to me
12:53 startPerl Whiteknight: I mean I wanna contribute
12:53 Infinoid I contribute sometimes, and I still believe I know less than 50% of parrot
12:53 Whiteknight you're right, a lot of it is pretty complicated
12:53 Infinoid I think focusing on a small piece helps
12:53 Whiteknight I'm with infinoid: there are a lot of systems that I still don't understand
12:53 startPerl so what can I do ?
12:53 Whiteknight but if you have any particular areas where you are interested, we can help you get started
12:54 startPerl I'm the guy who asked about threads in Perl6 and Parrot on your blog
12:54 Infinoid some aspects of parrot threads are busted in interesting ways, if you're good at such things :)
12:54 startPerl is someone working on the thread primitives in Parrot now ?
12:55 startPerl busted in what sense ?
12:55 Whiteknight ah, okay. Threads is an area that's still a little messy and needs some lovin'
12:55 startPerl yeah let's have a discussion about this
12:55 Infinoid The breakage I recently ran into has to do with cloning namespaces properly when spawning a new thread
12:55 Whiteknight startPerl: each thread has it's own interpreter object, which is usually cloned from the parent
12:55 Whiteknight we have a problem now where the new interpreter is not a faithful clone, and some operations fail
12:56 * Infinoid hates those faithless clones.
12:56 startPerl why do you copy it ?
12:56 startPerl the interpreter object ?
12:56 whoppix startPerl, to be able to run code in both threads at the same time
12:56 Infinoid The interpreter object is our analogy of a CPU; it has the register sets and other per-thread details
12:57 startPerl what are the threads at low-level ? are they actually processes ?
12:57 Whiteknight it's kind of complicated, but the interpreter object is basically the state of the bytecode, and you need one state object of every btecode stream
12:57 Whiteknight I believe the threads are OS threads
12:57 Whiteknight not processes
12:57 startPerl I read in Stevens book APUE that they're "lightweight-processes" .. whatever that meant ?
12:58 startPerl Whiteknight: so basically , reading what others have done in say ... Python could be of help /
12:58 startPerl ?
12:58 startPerl like checking out the CPython implementation
12:58 startPerl and re-implementing what they do in Parrot threads
12:58 startPerl becuase I hear they have kind of a OK threads implementation
12:59 Infinoid We have an implementation already, it just doesn't quite work in all cases
12:59 Whiteknight that might work, I'm not very familiar with the CPython threads
12:59 startPerl Infinoid: what kind of things ?
12:59 whoppix CPython has a GIL, the great interpreter lock, so no two threads can actually execute python bytecode at the same time.
12:59 whoppix thats not really what I would consider an OK implementation
13:00 startPerl whoppix: yeah I read about the GIL and the presentation was on reddit and also the talk video , did you read/watched those two ?
13:00 whoppix startPerl, no.
13:00 Infinoid startPerl: https://trac.parrot.org/parrot/ticket/757
13:00 startPerl whoppix: comeon it was on reddit
13:00 startPerl whoppix: where did you read/hear about it ?
13:00 Infinoid startPerl: Cloning PIR namespaces doesn't quite work yet
13:00 whoppix startPerl, I don't think I've ever been on reddit.
13:00 startPerl Infinoid: thanks , I'll take a look
13:01 startPerl whoppix: so why do they call them threads if they're not actually threads ?
13:01 whoppix startPerl, they are threads
13:01 whoppix startPerl, they just have to wait on eachother if they want to execute python code
13:01 Infinoid Sounds like they're just executed in serial, which makes them fairly useless for parallelization
13:02 whoppix indeed
13:02 startPerl so they have kind-of POE
13:03 startPerl Infinoid: reading the bug report
13:03 whoppix startPerl, no, they are actual OS threads that use locks.
13:03 whoppix you can block one thread using read() or sleep() or whatnot
13:03 whoppix the other will still keep on running
13:03 whoppix it's just that only one thread can execute python code at a time
13:03 startPerl is there like .. any dynamic language
13:03 startPerl Ruby
13:03 startPerl Scala
13:03 startPerl Lua
13:04 startPerl etc etc
13:04 startPerl that implements threads PROPERLY ?
13:04 whoppix startPerl, yes, erlang does
13:04 startPerl that's cool
13:04 startPerl something a bit more imperative  in syntax ?
13:04 startPerl erlang's declarative from what I read
13:04 startPerl and also functional
13:04 whoppix erlang is functional
13:05 whoppix startPerl, imperative languages and parallelisation don't mix all that well.
13:05 Whiteknight eventually all those languages will have a proper threading implementation, when Parrot's gets fixed and all those languages move to PArrot :)
13:05 startPerl ok , but is there any dynamic language that implements threads properly ? (except for erlang)
13:05 whoppix there are many ways to do it, but I daresay all of them are much harder than the simple principles you can apply on functional languages
13:05 startPerl Whiteknight: yeah , do you think they'll wanna move to Parrot for inter-operability ?
13:06 whoppix Whiteknight, hehe
13:06 whoppix startPerl, I think IronPython and IronRuby as well as JRuby should have "proper threads", as their underlying vms (.net and the jvm) support threading
13:06 startPerl so it's a matter of their VM implementing them properly more than it is a matter of language implementing them ?
13:07 Whiteknight yes
13:07 * startPerl forgot he's in #parrot
13:07 whoppix startPerl, more or less. the JVM implements threads properly, but I personally don't think java allows you to create parallelized programs properly.
13:07 whoppix but thats just my humble opinion, mind you :)
13:09 Infinoid The best parallel programs I've ever seen were written in VHDL.
13:09 startPerl so I'm reading this -> https://trac.parrot.org/parrot/​attachment/ticket/757/tt757.pir
13:09 shorten startPerl's url is at http://xrl.us/beytfj
13:09 whoppix Infinoid, VHDL?
13:10 startPerl where's test_more.pir ?
13:10 purl well, test_more.pir is very forgiving about incorrect plans
13:10 whoppix I see.
13:10 startPerl purl: where is test_more.pir ?
13:10 purl rumour has it test_more.pir is very forgiving about incorrect plans
13:10 startPerl poor bot
13:10 startPerl Infinoid: test_more.pir ?
13:10 purl i heard test_more.pir was very forgiving about incorrect plans
13:10 Infinoid startPerl: runtime/parrot/include/test_more.pir
13:11 Infinoid It's a common library, chosen semi-arbitrarily.  (Ok, it was inherited from my original failure when I boiled it down)
13:12 startPerl what is used in tt757 from it ?
13:13 Infinoid Nothing.  It creates a namespace named 'Test;More' whose existence causes an assertion failure when spawning the thread
13:13 bacek_ joined #parrot
13:13 Infinoid evening, bacek_
13:15 startPerl so the Test;More namespaces is not cloned properly
13:15 startPerl ?
13:15 startPerl why should Test;More be cloned in the first place ?
13:15 startPerl it should be shared somehow IMHO
13:15 startPerl between the two threads
13:16 * startPerl reminds himself that shared memory is not really a viable option
13:16 * startPerl with shmat ... ftok etc
13:17 startPerl or maybe it is , Infinoid have you considered this route , using shared memory ?
13:17 Infinoid I've no idea what the design goals behind our current implementation is, But if it's documented somewhere, it'll be in the PDDs
13:17 startPerl Infinoid: link please ?
13:17 brbrooks joined #parrot
13:17 Infinoid http://docs.parrot.org/par​rot/latest/html/pdds.html
13:18 Infinoid Parrot Design Documents :)
13:18 Infinoid Sorry, I have to go carry heavy boxes around for a while now
13:20 Whiteknight startPerl: shared memory might work in this case
13:20 Whiteknight PMCs are able to be shared, they can be associated with a mutex object if you need
13:20 Whiteknight so if we don't want to clone everything, we could mark them all as shared and access them through mutexes
13:20 skids joined #parrot
13:21 Whiteknight although I worry that might cause some slow downs and race conditions
13:21 Infinoid It'd probably be less slow than copying the whole world, though
13:21 Infinoid I guess it depends on how long the threads live
13:23 Whiteknight I have conceived of a more light-weight threading model, similar to what other systems refer to as "fibers"
13:23 Whiteknight instead of using a full interpreter it uses a small subset of it and passes other requests to the parent interpreter
13:23 bacek_ morning, Infinoid
13:23 startPerl this virtual machine ... what is it written in ? C ?
13:23 Whiteknight startPerl: yes, C
13:23 startPerl does it have like a bunch of registers
13:23 startPerl and a stack /
13:23 startPerl ?
13:23 Infinoid registers, yes, stack, no
13:24 * Infinoid has to leave now, but will backlog
13:24 startPerl how can it work without a stack ?
13:24 Whiteknight startPerl: lots of linked lists and trees
13:24 * startPerl has dealt with some fair bit of reverse engineering in 2002-2004 with assembly , and SoftIce
13:25 startPerl Whiteknight: so it's basically emulating a stack ?
13:25 startPerl Whiteknight: I mean you have some function calls
13:25 Whiteknight startPerl: not really, no. The semantics are completely different
13:25 startPerl Whiteknight: how can you emulate those function calls if not through a stck ?
13:25 Whiteknight everything is continuation based
13:25 startPerl what should I read on this ?
13:26 whoppix hooray for continuations.
13:26 Whiteknight so we call a function, which takes a return continuation, and then we call the continuation to return
13:26 startPerl the PDDs ?
13:26 purl the pdds are up to chip or Parrot Design Documents
13:26 Whiteknight so it's invoke->invoke, not invoke->return
13:26 Whiteknight startPerl: let me find something
13:26 startPerl so the continuation is an anonymous function ?
13:26 whoppix Whiteknight, can you throw away the continuation to delete it from the stack, to f.ex. do tail recursion?
13:26 startPerl I have read very little about it
13:27 Whiteknight whoppix: in the case of tail recursion, we reuse the existing continuation instead of creating a new one
13:27 Whiteknight startPerl: yes, a continuation is like an anonymous function. Think of it as a snap shot of the state of the interpreter, or a setjmp point in C
13:28 Whiteknight invoking a continuation rewinds the state of the interpreter back to where it was when the continuation was taken
13:28 startPerl isn't it inefficient ?
13:29 Whiteknight except a continuation can take aguments, so you don't return a value from a function, you call a continuation with return arguments
13:29 Whiteknight startPerl: not really, no. If we had a stack it would be inefficient because we would need to capture the state of the stack
13:29 Whiteknight without a stack, we just update a few pointers and go
13:30 startPerl why aren't there any images  explaining this ?
13:30 startPerl and the PDDs are without any images at all
13:30 whoppix startPerl, make some
13:30 whoppix startPerl, have you used inkscape?
13:30 startPerl no
13:31 whoppix startPerl, it's a free program for creating and editing vector graphics
13:31 whoppix you can nicely make flowcharts and that kind of visualisations with it
13:31 Whiteknight startPerl: the most information we have about the concept right now is in /docs/book/pir/ch06_subroutines.pod
13:31 Whiteknight yeah, we do need more illustrations
13:32 Whiteknight and more descriptions. I don't think there is any mention of CPS in the PDDs at all
13:33 * startPerl is serious about tackling some Parrot stuff
13:33 * startPerl starts to read pdd03
13:34 burmas joined #parrot
13:34 Whiteknight startPerl: excellent! Please don't hesitate to ask any questions
13:35 startPerl Whiteknight: thank you
13:35 startPerl do developers of Parrot actually have experience with this sort of thing ? like ..did they develop other VMs as well ?
13:35 * whoppix plans to contribute some stuff to parrot as well, once hes done with his current rather large projects...
13:35 startPerl or they are self-taught and wanna make a nice job ?
13:38 dukeleto joined #parrot
13:38 bacek_ startPerl: It depends.
13:40 bacek_ F.e. I've implemented few other languages before joining Parrot. Other people have very good CS/VM background.  Etc, etc, etc
13:41 startPerl that's interesting
13:41 bacek_ it's opensource project. Almost everyone can join.
13:42 Whiteknight startPerl: a lot of the early Parrot developers and designers were Perl people, so a lot of them had experience with the Perl interpreter
13:42 bacek_ Every contribution matter
13:42 Whiteknight I personally read *a lot* of research papers about the topic now, and I know some other people do as well
13:43 startPerl Whiteknight: can you triage between the papers that have a sci-fi non-realistic approach ?
13:43 register joined #parrot
13:44 Whiteknight startPerl: yes, although in my experience there aren't too many of those
13:44 Whiteknight at least, not where I look
13:44 startPerl where do you look ?
13:44 Whiteknight ACM and IEEE Computer mostly
13:44 * Whiteknight actually needs to renew memberships to both
13:45 startPerl so you need to pay for those papers right ?
13:46 Whiteknight yeah. I had been in gradschool until last year, so I got them all for free
13:46 Whiteknight but now I'm in the "real world" and have to pay for stuff
13:49 startPerl what's a fiber ?
13:49 purl a fiber is good if you need distance or a Win32 really lightweight thread - Win32 has processes, threads, and fibers, which sort of correspond to Unix processes, threads, and nothing, respectively or (: fios)
13:49 Whiteknight yeah, fibers are very very light weight threads on Win32
13:50 Whiteknight it has very low overhead, but there are some restrictions that I can't remember
13:53 whoppix http://msdn.microsoft.com/en-u​s/library/ms682661(VS.85).aspx
13:53 whoppix looks like sort of microthreads inside of threads
13:54 whoppix so they don't really run in parallel
13:54 whoppix the only interesting thing is that you can convert fibers to real threads and the other way around, apparantly
15:23 MoC joined #parrot
15:30 tetragon joined #parrot
15:53 muixirt joined #parrot
16:12 Andy joined #parrot
16:15 szbalint <@Whiteknight> yeah, we do need more illustrations
16:15 szbalint indeed
16:16 Whiteknight my graphics-foo is weak, unfortunately
16:16 Whiteknight I could draw a bunch of lousy line drawings
16:17 whoppix I suppose I could make some
16:17 whoppix given someone throws together a bunch of subjects we need illustrations for
16:18 whoppix I unfortunately currently don't have time go look over all of the docs.
16:27 * szbalint is in sponge mode atm
16:28 szbalint I'd like to suck in as much information as possible before YAPC::EU :)
16:35 dukeleto joined #parrot
16:39 dalek parrot: r39814 | fperrad++ | trunk/t/op/io.t:
16:39 dalek parrot: [t] add a missing todo
16:39 dalek parrot: - replace a deprecated mode
16:40 dalek parrot: - remove a magic number
16:40 dalek parrot: - and minor improvements
16:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39814/
16:42 Psyche^ joined #parrot
16:43 Theory joined #parrot
16:46 jan joined #parrot
17:00 chromatic joined #parrot
17:06 flh joined #parrot
17:27 dalek parrot: r39815 | whiteknight++ | branches/context_pmc/src (3 files):
17:27 dalek parrot: [context_pmc] lots more switchover, especially in the pcc system. Updated Context.mark to mark registers, added some documentation
17:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39815/
17:41 dalek parrot: r39816 | whiteknight++ | branches/context_pmc/lib/Parrot (4 files):
17:41 dalek parrot: [context_pmc] a few more switchovers, especially dealing with ops. Doesn't work correctly, need to figure out what everything is expecting here. Also, may need to find a VTABLE-based method for getting constants
17:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39816/
17:43 autark joined #parrot
18:28 Theory joined #parrot
19:22 PacoLinux joined #parrot
19:36 brbrooks joined #parrot
20:36 bacek_ joined #parrot
20:49 PacoLinux joined #parrot
21:14 bacek_ good morning #parrot
21:24 Coke msg chromatic I see you like you some Horrible.
21:24 purl Message for chromatic stored.
21:24 Whiteknight good morning
21:24 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
21:25 eternaleye Infinoid: What about just closing the pipe on destruction? Then the writing process would get SIGPIPE if it kept going, which is what cat/sed/every-other-unix-tool seems to do
21:25 eternaleye (was backlogging)
21:26 eternaleye (statement was in response to the discussion a while back about parrot's unix pipe doing a waitpid(), and the option of just letting init handle it)
21:39 pmichaud good afternoon, #parrot
21:42 Coke hio
21:47 Whiteknight hello
21:47 purl que tal, Whiteknight.
21:49 Infinoid eternaleye: Works for me
22:01 snarkyboojum joined #parrot
22:07 Theory joined #parrot
22:35 rg joined #parrot
23:08 bacek_ joined #parrot
23:10 szabgab joined #parrot
23:19 snarkyboojum joined #parrot
23:46 dalek TT #799 created by Austin_Hastings++: Configure should explicitly check for symbolic link capability on Linux

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

Parrot | source cross referenced