Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
00:47 PacoLinux joined 00:51 patspam joined 00:55 PacoLinux joined 01:05 PacoLinux joined
s1n i'd like to inquire about cage cleaning, who's the right person to speak with? 01:51
01:57 zak_ joined 02:00 baest joined
Infinoid s1n: You're in the right place, though I can't point to a particular person :) 02:01
02:02 burmas joined
Infinoid As mentioned before, there isn't a formal process, there is some documentation which we've already mentioned 02:02
But if you have a more specific question, you can just ask directly and whoever's awake will answer
02:22 Zak joined 02:32 kid51 joined 02:35 janus joined 02:38 rdice joined 02:39 mikehh_ joined 02:59 particle joined 03:08 tetragon_ joined 03:29 tetragon joined 03:35 Theory joined 03:42 jdv79 joined
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:20
mikehh pre/pos config, smoke, fulltest All PASS - r39811 on Ubuntu 9.04 Amd64 04:21
post
s1n: one thing to look at is the results of tests, especially codetest - there are some TODO failures there 04:24
things like missing POD and such like 04:25
s1n mikehh: thanks
jdv79 reading andrews blog about L1 and related. my first question is how the hell did we get here? 04:33
ugh
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
chromatic has been pushing, for a while, for a way to move away from the reliance on C 04:40
L1 provides a good way to move toward this 04:41
skids beginning to think C needs a real competitor (not just in the Parrot area.) 04:46
Some not-oo, architecture-aware lowlevel language.
But I doubt that's a good tangent to go off on in Parrot's case. 04:47
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:53
i was at the workshop 04:54
unfortunately i hadn't looked at parrot beforehand so i was kinda dazed and confused. trying to research up now.
mikehh people moving in different directions 04:55
chromatic Some flaws are obvious only in retrospect.
mikehh sometimes you can only find things out if you try it 04:56
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
a lot of research works on specific concepts and usually involving one or two researchers 04:59
here we have a lot of concepts thrown together in a large project with lots of independent developers 05:00
and not that much control
jdv79 are VMs that cutting edge? why can't parrot attract more established VM talent? 05:01
mikehh We are looking at a VM aimed at dynamic languages here 05:02
mberends jdv79: what do you mean by obviously flawed?
mikehh most other VM's are for static languages
jdv79 calling back and forth between c and pir through multiple runloops for starters
mberends jdv79: ok, that would not be elegant 05:03
mikehh that is probably the most obvious problem we have and what L1 is a possible resolution 05:04
that doesn't parse right - I think I need some sleep 05:05
cotto chromatic, ping
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
jdv79 thanks. ok, back to reading. 05:07
mikehh there are other possible solutions but I like the L1 one
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
mikehh, please speak up if you have possible alternatives.
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
cotto Worse alternatives are good too. If they have advantages we can integrate them into L1. 05:11
Even if not, it's good to think in different terms to solve a problem.
mberends is there a faint echo of Perl 5 stagnation in 2000 sounding? "Current architecture unwieldy.. Need a fresh start.." 05:12
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.
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.
mikehh me too 05:17
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:18
mikehh One of the problems, I think, has been, too many different things added, without getting things working properly first. 05:20
cotto I'm sure libparrot will be smaller than 3.6M stripped, though. Eek. 05:21
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:22
mikehh we really need to get that going 05:23
cotto It's happening, though slowly. There's a faint possibility that it'll be ready for 1.4. 05:24
mikehh that would be realkly nice 05:25
cotto if not that, I'd be deeply disappointed if it wasn't in 1.5.
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?
cotto minimizes irc 05:26
chromatic pong 05:27
cotto and unminimizes it just in time to see chromatic's pong 05:28
chromatic I'm not sure how to reconcile stack-based with pervasive CPS and first-class continuations. 05:30
05:31 mikehh_ joined 05:33 brbrooks joined
mberends parrot seems to use a heap of stacks in places, probably for continuations 05:37
chromatic If that were true (and I don't believe it is), I'm not sure how first-class continuations would work. 05:38
Control flow in that case is an acyclic graph. 05:39
mberends will read more docs before getting even more out of depth 05:40
05:51 bacek_ joined
bacek_ o hai 05:53
cotto: ping 05:54
05:55 brbrooks joined, brbrooks_ joined
cotto bacek_, I see your ping and raise you a pong 05:55
bacek_ cotto: I have something for you to sleep on it. 05:56
cotto I was going to use my futon, but go ahead
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?
purl YA RLY.
bacek_ purl++
chromatic Sounds risky.
bacek_ Actually no.
ops are smaller. 05:58
cotto I am intrigued by your proposal.
bacek_ L1 will include some low-level stuff to access raw-memory.
chromatic pmcc has the nice benefit of working in small steps.
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
"ops" are even smaller
cotto Yes, but wouldn't we have to rewrite them all?
bacek_ imcc/pirc support ":method" and ":vtable" already, so there is no value to parse current "pseudo-C" 06:00
cotto: in bright shiny future - yes.
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.
Just replace some PMCs with PIR/NQP based
06:02 abesapien joined
bacek_ But we don't need to parse current PMCs. 06:02
It's throw-away job (Yes, I'm repeating myself)
cotto That's definitely worth thinking about. 06:03
chromatic I still don't follow.
cotto bacek++
bacek_ (clarifying myself) We can avoid step with generating C code. 06:04
1. Implement Integer PMC in PIR.
cotto I think he's saying that we start now reimplementing PMC in nqp and PIR
06:04 jsut joined
bacek_ 2. Check which ops are missing for low-level stuff 06:05
3. Add them to L1 dynops.
...
5. Profit!
cotto your plans always end the same way
There's more to life than profit.
bacek_ ok, scratch step 5.
chromatic If that doesn't work, we don't have a good way to dump Perl 5 from the PMC building process.
cotto What about world peace or ponies?
bacek_ new 5. World domination.
cotto That implies a certain level of peace. Sounds good. 06:06
bacek_ chromatic: it will.
It's simplified version of original plan.
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.
chromatic: emitting C from NQP isn't big step. It's HUGE step.
chromatic It's about as big as emitting L1 from NQP. 06:08
Perhaps smaller.
bacek_ as first-cut we can skip emitting L1 from NQP.
cotto L1->C and nqp->L1 can be worked on in parallel too
bacek_ Just go NQP->PIR->L1 06:09
because we'll need "PIR->L1" anyway.
And we already have "NQP->PIR"
chromatic Yes, but we *don't know* if NQP->L1 will work.
bacek_ Ok. PIR->L1 should work? 06:10
chromatic We *know* pmcc->C will work, because we *know* Perl 5->C works.
bacek_ Should PIR->L1 work? 06:13
cotto yes, by definition 06:14
chromatic Once we reach the point where we know L1 itself works.
bacek_ ok, Does NQP->L1 work?
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.
bacek_ ok, Does NQP->PIR work?
NQP _is_ sufficient.
chromatic NQP is sufficient only in so far as what it can emit is sufficient. 06:16
cotto not as it stands today
bacek_ NQP can emit PIR
NQP can embed PIR
PIR can be converted into L1
NQP is sufficient
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.
bacek_ chromatic: exactly. That's why I propose to start with "ops", not "pmc" 06:18
consider simple "op fdiv"
It's exposing calling plain-C function. 06:19
chromatic Consider how you dispatch those ops now.
bacek_ And it's oneliner
chromatic Can we convert those ops piecemeal?
Or is it (as I suspect) all or nothing?
bacek_ imaging half-pregnant girl 06:20
chromatic What does that do to our runloop?
bacek_ "op fdiv" converted to "sub fdiv".
which is L1 sub
chromatic L1 oughtn't know anything about subs. 06:21
That's much too high a level.
bacek_ (In next few months we implement in-lining to avoid call)
erm....
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?
bacek_ "invoke"? 06:23
chromatic If you want to get very, very technical, you can come up with a few.
L1 only needs to be able to tell the runloop the next op to execute. 06:24
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?
bacek_ cotto: I'll try
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 :)
chromatic Sure, it's the same for current ops.
cotto Thanks.
I'm off to bed.
night
bacek_ chromatic: night
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.
bacek_ chromatic: I don't pushing it down 06:29
I actually pushing it up
chromatic I don't see how.
bacek_ All PIR "ops" are "subs" from L1 point of view
isn't it?
chromatic That depends what you mean by "subs". 06:30
I figure there's a PCT-based ops parser that emits L1.
bacek_ But I can also emit "subs".
chromatic What do you mean by "subs"? 06:31
bacek_ ".sub fdiv; ... L1 body ... .end"
chromatic Why do that? 06:32
bacek_ Drop src/ops/*.ops?
chromatic Why do that? 06:33
bacek_ Actually rewrite them in L1.
chromatic That's always been my plan.
bacek_ Yes. I'm totally on your side
chromatic Why turn our existing ops (L2, let's say) into subs? 06:34
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.
If we can optimize L1 across L2 op boundaries, we do it aggressively.
bacek_ erm... 06:37
Let rephrase myself.
"op foo" in L2 when I read sources is just some subroutine in some language.
currently it's pseudo-C.
dalek rrot: r39812 | petdance++ | trunk/src/packdump.c:
fixing some splint flags
bacek_ In bright future it's L1. 06:38
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.
chromatic By "sub" do you mean "discrete unit of L1 ops"?
I can get behind that.
bacek_ Ah. Yes. Sorry for my bad 4th language 06:40
chromatic No problem, I just wanted to make sure.
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.
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.
chromatic Which has some compelling in the argument.
bacek_ looking for translation of "compelling" 06:43
chromatic You make a good point.
bacek_ Hooray. I finally explained my point of view in this barbarian language :) 06:45
chromatic Barbarian? We're not speaking Australian, mate.
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.
But I see your point.
bacek_ But ops _are_ smaller and simpler. 06:47
chromatic Right.
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.
We need something like it eventually. 06:49
bacek_ Of cause.
But... imcc/pirc can compiler pir already.
chromatic I don't see how that matters.
bacek_ Current PMC can be translated into PIR with few ":method" and ":vtable" subs. 06:50
We can express almost everything in it.
chromatic I don't believe that.
bacek_ Why? 06:51
chromatic I've hacked too many PMCs.
bacek_ heh. Doesn't count. I've hacked many on them too :) 06:52
Actually, current VTABLEs is hack to speed up MMD over first argument. 06:54
chromatic Sure. 06:55
bacek_ s/is/are/
chromatic I don't understand the benefit of writing PMCs in PIR.
06:55 tetragon joined
bacek_ We can write them in NQP. 06:55
Or Close
Or anything else. 06:56
purl anything else is violating dry. and we're in the wrong channel.
bacek_ ...which emits "PIR"
chromatic Why would it emit PIR?
bacek_ shortcut to reduce effort.
chromatic How so?
bacek_ 1. We _have_ to emit L1 from PIR. 06:57
2. Many compilers already emit PIR
So, we can use current compilers without adjusting to use with L1.
chromatic I see. 06:58
You're assuming that we can write everything currently in C for PMCs in PIR, if PIR supports L1.
I'm assuming that it's easier to write everything currently in C for PMCs in something that compiles to L1 directly.
bacek_ L1+PIr actually
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
chromatic Sure. Writing emitters is not always easy. 07:01
Of course, PIR doesn't always make that easy. 07:02
bacek_ L1 will not make it easier.
chromatic That depends how far L1 is from Close/NQP/whatever. 07:03
bacek_ With my proposal it doesn't matter.
chromatic I need to think about it more. 07:04
bacek_ PCT will emit PIR+L1-ops
07:04 maettu joined
bacek_ And it can do it already 07:04
chromatic I don't like something about it, but I can't tell you what or why. 07:05
Please do write it up though.
bacek_ There is a lot of sharp corners of cause. 07:06
I'll try to write some summary tomorrow. I have to sleep on this little bit more. 07:07
chromatic Me too.
bacek_ chromatic: ok 07:08
maettu noob question: after checking out the svn, can I install parrot like described in /docs/book/ch02_getting_started.pod.html ? 07:10
chromatic I believe so, maettu. 07:11
maettu do I type 'B<perl Configure.pl>' or just 'perl Configure.pl'? 07:12
chromatic perl Configure.pl 07:13
B<...> is formatting.
maettu ah! should this be changed on the mentioned webpage?
chromatic Yes. 07:14
maettu how could I help with this?
chromatic Though the right fix is to use ppod2html instead of pod2html, which requires the use of Pod::PseudoPod instead of Pod::Simple.
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?
maettu well yes, it writes to /usr/local (I mean you need to be root or something) :-)
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:24
maettu thanks! parrot up & running :-) (by the way, love your blog!) 07:26
chromatic Thank you. 07:28
I love... the air.
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:30
(if it makes sense, at all) 07:32
there is a small typo on /html/book/ch03_pir.pod.html in "Variables": "mroe" instead of "more" 07:34
and under "Strings: Encodings an Charsets", shouldn't it be "older times" instead of "olden times"? 07:36
07:40 dukeleto joined
mberends maettu: "mroe" is wrong, but "olden times" is fine. 07:40
maettu ok, I corrected the typo in my local copy. What's next? 07:41
bacek_ maettu: in this case - relax :) In other cases feel free to open ticket at parrot's trac. 07:44
dalek rrot: r39813 | bacek++ | trunk/docs/book/draft/ch03_pir.pod:
Fix typo. maettu++
 07:45
bacek_ parrotbug?
purl rumour has it parrotbug is obsolete, use trac.parrot.org/
bacek_ maettu: trac.parrot.org/ (You'll need a trivial registering) 07:46
maettu thanks, I do. I'm very relaxed, :-) just trying to help out a little bit 07:47
bacek_ I just did it :)
maettu thanks!
bacek_ No. Thank _you_ for spotting this. 07:50
08:02 muixirt joined
maettu I think i like parrot :-) 08:02
bacek_ maettu: You are welcome :) 08:11
08:13 MoC joined
bacek_ maettu: Every contribution matter. 08:13
maettu welcome
08:16 iblechbot joined
bacek_ maettu: anyway, if you think that something is wrong can be improved, feel free to send patches to trac/mailinglist. 08:21
maettu i will 08:22
bacek_ maettu: thanks!
08:32 Khisanth joined 08:35 snarkyboojum joined 08:59 tetragon joined 09:10 tetragon joined
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:15
09:46 Zak joined 09:51 eiro__ joined 10:04 tetragon joined 10:14 jonathan joined 10:23 shorten joined 10:47 zak_ joined 11:23 snarkyboojum joined 12:01 particle1 joined 12:03 masak joined 12:09 elmex joined
dalek TT #798 created by richardh++: [BUG] and [PATCH] SDL Font color is wrong 12:14
12:18 maettu left 12:26 Whiteknight joined
Whiteknight good morning 12:41
purl And good moroning to you, Whiteknight.
Whiteknight purl, you're an asshole
purl Whiteknight: sorry...
Infinoid hah 12:44
morning Whiteknight
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
about how we need to better integrate pipe logic into the IO API
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
It creates what amounts to a simple pipe... except that it also has a waitpid() for the child process on destruction
Whiteknight yeah, we really need to separate that out
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)
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
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
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
Infinoid I can add the pid handling to pipes and leave filehandle alone for the moment
Whiteknight post-1.4 sometime we create a new branch to make the switch-over to using the Pipe class
okay, that's good 12:49
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:50
Infinoid Oh, that's how it stashes the child pid so it can waitpid() on destruction 12:51
12:51 startPerl joined
Infinoid It really should be using an attr for that. 12:51
But we're moving it into a different PMC anyway, so it doesn't matter
Whiteknight ok
startPerl Whiteknight: reading your blog quite often 12:52
Whiteknight startPerl: awesome! let me know what you think about it
startPerl Whiteknight: I think that I'd like to write some damn code but it all seems so damn complicated to me
Whiteknight: I mean I wanna contribute 12:53
Infinoid I contribute sometimes, and I still believe I know less than 50% of parrot
Whiteknight you're right, a lot of it is pretty complicated
Infinoid I think focusing on a small piece helps
Whiteknight I'm with infinoid: there are a lot of systems that I still don't understand
startPerl so what can I do ?
Whiteknight but if you have any particular areas where you are interested, we can help you get started
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 :)
startPerl is someone working on the thread primitives in Parrot now ?
busted in what sense ? 12:55
Whiteknight ah, okay. Threads is an area that's still a little messy and needs some lovin'
startPerl yeah let's have a discussion about this
Infinoid The breakage I recently ran into has to do with cloning namespaces properly when spawning a new thread
Whiteknight startPerl: each thread has it's own interpreter object, which is usually cloned from the parent
we have a problem now where the new interpreter is not a faithful clone, and some operations fail
Infinoid hates those faithless clones. 12:56
startPerl why do you copy it ?
the interpreter object ?
whoppix startPerl, to be able to run code in both threads at the same time
Infinoid The interpreter object is our analogy of a CPU; it has the register sets and other per-thread details
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
I believe the threads are OS threads
not processes
startPerl I read in Stevens book APUE that they're "lightweight-processes" .. whatever that meant ?
Whiteknight: so basically , reading what others have done in say ... Python could be of help / 12:58
?
like checking out the CPython implementation
and re-implementing what they do in Parrot threads
becuase I hear they have kind of a OK threads implementation
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
startPerl Infinoid: what kind of things ?
whoppix CPython has a GIL, the great interpreter lock, so no two threads can actually execute python bytecode at the same time.
thats not really what I would consider an OK implementation
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.
Infinoid startPerl: trac.parrot.org/parrot/ticket/757
startPerl whoppix: comeon it was on reddit
whoppix: where did you read/hear about it ?
Infinoid startPerl: Cloning PIR namespaces doesn't quite work yet
whoppix startPerl, I don't think I've ever been on reddit.
startPerl Infinoid: thanks , I'll take a look
whoppix: so why do they call them threads if they're not actually threads ? 13:01
whoppix startPerl, they are threads
startPerl, they just have to wait on eachother if they want to execute python code
Infinoid Sounds like they're just executed in serial, which makes them fairly useless for parallelization
whoppix indeed 13:02
startPerl so they have kind-of POE
Infinoid: reading the bug report 13:03
whoppix startPerl, no, they are actual OS threads that use locks.
you can block one thread using read() or sleep() or whatnot
the other will still keep on running
it's just that only one thread can execute python code at a time
startPerl is there like .. any dynamic language
Ruby
Scala
Lua
etc etc 13:04
that implements threads PROPERLY ?
whoppix startPerl, yes, erlang does
startPerl that's cool
something a bit more imperative in syntax ?
erlang's declarative from what I read
and also functional
whoppix erlang is functional
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 :)
startPerl ok , but is there any dynamic language that implements threads properly ? (except for erlang)
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
startPerl Whiteknight: yeah , do you think they'll wanna move to Parrot for inter-operability ?
whoppix Whiteknight, hehe 13:06
startPerl, I think IronPython and IronRuby as well as JRuby should have "proper threads", as their underlying vms (.net and the jvm) support threading
startPerl so it's a matter of their VM implementing them properly more than it is a matter of language implementing them ?
Whiteknight yes 13:07
startPerl forgot he's in #parrot
whoppix startPerl, more or less. the JVM implements threads properly, but I personally don't think java allows you to create parallelized programs properly.
but thats just my humble opinion, mind you :)
Infinoid The best parallel programs I've ever seen were written in VHDL. 13:09
startPerl so I'm reading this -> trac.parrot.org/parrot/attachment/.../tt757.pir
shorten startPerl's url is at xrl.us/beytfj
whoppix Infinoid, VHDL?
startPerl where's test_more.pir ? 13:10
purl well, test_more.pir is very forgiving about incorrect plans
whoppix I see.
startPerl purl: where is test_more.pir ?
purl rumour has it test_more.pir is very forgiving about incorrect plans
startPerl poor bot
Infinoid: test_more.pir ?
purl i heard test_more.pir was very forgiving about incorrect plans
Infinoid startPerl: runtime/parrot/include/test_more.pir
It's a common library, chosen semi-arbitrarily. (Ok, it was inherited from my original failure when I boiled it down) 13:11
startPerl what is used in tt757 from it ? 13:12
Infinoid Nothing. It creates a namespace named 'Test;More' whose existence causes an assertion failure when spawning the thread 13:13
13:13 bacek_ joined
Infinoid evening, bacek_ 13:13
startPerl so the Test;More namespaces is not cloned properly 13:15
?
why should Test;More be cloned in the first place ?
it should be shared somehow IMHO
between the two threads
startPerl reminds himself that shared memory is not really a viable option 13:16
startPerl with shmat ... ftok etc
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
startPerl Infinoid: link please ?
13:17 brbrooks joined
Infinoid docs.parrot.org/parrot/latest/html/pdds.html 13:17
Parrot Design Documents :) 13:18
Sorry, I have to go carry heavy boxes around for a while now
Whiteknight startPerl: shared memory might work in this case 13:20
PMCs are able to be shared, they can be associated with a mutex object if you need
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
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
I guess it depends on how long the threads live
Whiteknight I have conceived of a more light-weight threading model, similar to what other systems refer to as "fibers" 13:23
instead of using a full interpreter it uses a small subset of it and passes other requests to the parent interpreter
bacek_ morning, Infinoid
startPerl this virtual machine ... what is it written in ? C ?
Whiteknight startPerl: yes, C
startPerl does it have like a bunch of registers
and a stack /
?
Infinoid registers, yes, stack, no
Infinoid has to leave now, but will backlog 13:24
startPerl how can it work without a stack ?
Whiteknight startPerl: lots of linked lists and trees
startPerl has dealt with some fair bit of reverse engineering in 2002-2004 with assembly , and SoftIce
Whiteknight: so it's basically emulating a stack ? 13:25
Whiteknight: I mean you have some function calls
Whiteknight startPerl: not really, no. The semantics are completely different
startPerl Whiteknight: how can you emulate those function calls if not through a stck ?
Whiteknight everything is continuation based
startPerl what should I read on this ?
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
startPerl the PDDs ?
purl the pdds are up to chip or Parrot Design Documents
Whiteknight so it's invoke->invoke, not invoke->return
startPerl: let me find something
startPerl so the continuation is an anonymous function ?
whoppix Whiteknight, can you throw away the continuation to delete it from the stack, to f.ex. do tail recursion?
startPerl I have read very little about it
Whiteknight whoppix: in the case of tail recursion, we reuse the existing continuation instead of creating a new one 13:27
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
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 ?
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
startPerl: not really, no. If we had a stack it would be inefficient because we would need to capture the state of the stack
without a stack, we just update a few pointers and go
startPerl why aren't there any images explaining this ? 13:30
and the PDDs are without any images at all
whoppix startPerl, make some
startPerl, have you used inkscape?
startPerl no
whoppix startPerl, it's a free program for creating and editing vector graphics 13:31
you can nicely make flowcharts and that kind of visualisations with it
Whiteknight startPerl: the most information we have about the concept right now is in /docs/book/pir/ch06_subroutines.pod
yeah, we do need more illustrations
and more descriptions. I don't think there is any mention of CPS in the PDDs at all 13:32
startPerl is serious about tackling some Parrot stuff 13:33
startPerl starts to read pdd03
13:34 burmas joined
Whiteknight startPerl: excellent! Please don't hesitate to ask any questions 13:34
startPerl Whiteknight: thank you 13:35
do developers of Parrot actually have experience with this sort of thing ? like ..did they develop other VMs as well ?
whoppix plans to contribute some stuff to parrot as well, once hes done with his current rather large projects...
startPerl or they are self-taught and wanna make a nice job ?
13:38 dukeleto joined
bacek_ startPerl: It depends. 13:38
F.e. I've implemented few other languages before joining Parrot. Other people have very good CS/VM background. Etc, etc, etc 13:40
startPerl that's interesting 13:41
bacek_ it's opensource project. Almost everyone can join.
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
Whiteknight I personally read *a lot* of research papers about the topic now, and I know some other people do as well
startPerl Whiteknight: can you triage between the papers that have a sci-fi non-realistic approach ? 13:43
13:43 register joined
Whiteknight startPerl: yes, although in my experience there aren't too many of those 13:44
at least, not where I look
startPerl where do you look ?
Whiteknight ACM and IEEE Computer mostly
Whiteknight actually needs to renew memberships to both
startPerl so you need to pay for those papers right ? 13:45
Whiteknight yeah. I had been in gradschool until last year, so I got them all for free 13:46
but now I'm in the "real world" and have to pay for stuff
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)
Whiteknight yeah, fibers are very very light weight threads on Win32
it has very low overhead, but there are some restrictions that I can't remember 13:50
whoppix msdn.microsoft.com/en-us/library/ms...S.85).aspx 13:53
looks like sort of microthreads inside of threads
so they don't really run in parallel 13:54
the only interesting thing is that you can convert fibers to real threads and the other way around, apparantly
15:23 MoC joined 15:30 tetragon joined 15:53 muixirt joined 16:12 Andy joined
szbalint <@Whiteknight> yeah, we do need more illustrations 16:15
indeed
Whiteknight my graphics-foo is weak, unfortunately 16:16
I could draw a bunch of lousy line drawings
whoppix I suppose I could make some 16:17
given someone throws together a bunch of subjects we need illustrations for
I unfortunately currently don't have time go look over all of the docs. 16:18
szbalint is in sponge mode atm 16:27
I'd like to suck in as much information as possible before YAPC::EU :) 16:28
16:35 dukeleto joined
dalek rrot: r39814 | fperrad++ | trunk/t/op/io.t:
[t] add a missing todo

  - remove a magic number
  - and minor improvements		 16:39
16:42 Psyche^ joined 16:43 Theory joined 16:46 jan joined 17:00 chromatic joined 17:06 flh joined
dalek rrot: r39815 | whiteknight++ | branches/context_pmc/src (3 files):
[context_pmc] lots more switchover, especially in the pcc system. Updated Context.mark to mark registers, added some documentation
 17:27
rrot: r39816 | whiteknight++ | branches/context_pmc/lib/Parrot (4 files):
[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
17:43 autark joined 18:28 Theory joined 19:22 PacoLinux joined 19:36 brbrooks joined 20:36 bacek_ joined 20:49 PacoLinux joined
bacek_ good morning #parrot 21:14
Coke msg chromatic I see you like you some Horrible. 21:24
purl Message for chromatic stored.
Whiteknight good morning
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
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
(was backlogging)
(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:26
pmichaud good afternoon, #parrot 21:39
Coke hio 21:42
Whiteknight hello 21:47
purl que tal, Whiteknight.
Infinoid eternaleye: Works for me 21:49
22:01 snarkyboojum joined 22:07 Theory joined 22:35 rg joined 23:08 bacek_ joined 23:10 szabgab joined 23:19 snarkyboojum joined
dalek TT #799 created by Austin_Hastings++: Configure should explicitly check for symbolic link capability on Linux 23:46

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!