Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2012-05-22

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

All times shown according to UTC.

Time Nick Message
00:30 wagle joined #parrotsketch
02:51 japhb joined #parrotsketch
06:00 contingencyplan joined #parrotsketch
07:41 contingencyplan joined #parrotsketch
08:17 lucian joined #parrotsketch
08:54 lucian joined #parrotsketch
11:02 kjs joined #parrotsketch
11:02 kjs REPORT FOR KJS:
11:03 kjs + Started implementation of "M1", a subset of C, slightly extended with features handy for Parrot/M0
11:03 kjs + implementation can be found at: https://github.com/parrot/m1
11:04 kjs + Code generator not done. Some instructions (M0) seem missing, such as "<" or ">"; one of both is needed. goto_if can be used as a replacement for "==" I think but adding a "iseq" op would be handy. Also, function calls (goto_chunk) is not quite clear; parameter handling same.
11:04 kjs + Feedback would be most welcome; is this on the right track?
11:04 kjs .EOR
12:03 bluescreen joined #parrotsketch
12:31 kjs joined #parrotsketch
13:07 bluescreen joined #parrotsketch
13:44 Coke REPORT: $dayjob and teh sick ate all my tuits. coke/rm_pasm still idling.
15:23 contingencyplan joined #parrotsketch
15:55 contingencyplan joined #parrotsketch
15:55 bluescreen joined #parrotsketch
15:55 japhb joined #parrotsketch
15:55 wagle joined #parrotsketch
15:55 alvis joined #parrotsketch
15:55 PerlJam joined #parrotsketch
15:55 Coke joined #parrotsketch
15:55 eternaleye joined #parrotsketch
15:55 sorear joined #parrotsketch
15:55 Tene joined #parrotsketch
15:55 wendar joined #parrotsketch
15:55 cotto joined #parrotsketch
15:55 jlaire joined #parrotsketch
15:55 wagle_ joined #parrotsketch
15:55 eternaleye joined #parrotsketch
15:56 nine joined #parrotsketch
16:02 eternaleye_ joined #parrotsketch
16:02 allison joined #parrotsketch
16:02 wagle joined #parrotsketch
17:44 lucian joined #parrotsketch
17:57 kjs joined #parrotsketch
19:07 lucian joined #parrotsketch
19:22 NotFound joined #parrotsketch
19:44 brrt joined #parrotsketch
19:47 brrt for the logs
19:49 brrt REPORT: started working on the design of mod_parrot.
19:50 brrt + starting apache with a debug configuration
19:50 brrt + todo: link parrot to apache in a module
19:50 brrt EOR
20:29 benabik joined #parrotsketch
20:33 whiteknight joined #parrotsketch
20:37 cotto hello
20:37 kjs hello
20:37 whiteknight hello
20:37 benabik hihi
20:38 cotto How's this week been, apart from everyone forgetting #ps at the right time? ;)
20:38 kjs the number of participants has gone down dramatically since i last joined.
20:39 cotto it varies based on who's free and awake, but it has been a bit sparse lately
20:39 kjs well, my report is posted, a few hours ago.
20:40 cotto kjs, I was glad to see your work on M1
20:40 kjs I've hacked together a compiler to emit M0 ops, and boy, it was gooood to do some hacking.
20:40 tadzik joined #parrotsketch
20:40 kjs I'd like to have a quick chat about M0/M1, and the role of M0 and M1, if possible.
20:40 whiteknight yes, the compiler looks very nice
20:40 cotto kjs, sure
20:41 NotFound Nothing interesting to report from me.
20:41 cotto kjs, for the time being, the lack of a comparison operators is intentional.  How much work would it be to implement those in terms of arithmetic ops?
20:42 cotto one of M0's goals is a minimal op set (though not so minimal that it can't generate efficient code).
20:42 kjs cotto; well, i've thought about that. one could do something with sub etc. but you need to know which side of 0 you are.
20:42 kjs but i'm not a math wizkid. perhaps there's certain mathematical axioms or whatever.
20:43 kjs i seem to remember the minimum is 1 equality and 1 gt or lt operator
20:43 kjs so, 2 to implement all 6: ==, !=, >= >, <, <=
20:44 cotto Don't look at M0 as a finished product.  If you run into holes, we'll likely need to fill them in.
20:44 kjs but that's not the biggest issue :-)
20:44 cotto what is?
20:44 kjs what's more important is the role of M0/M1
20:44 NotFound If you have <= , == is a <= b and b <= a
20:44 kjs (not implying that my hacking result /is/ M1, but at least it's a prototype)
20:45 kjs so, bascially, the Big Question is, IF C language had Parrot Calling Conventions, would M0 still be necessary?
20:45 cotto no
20:45 kjs right.
20:45 kjs so basically you'd like to do implement parrot in a language that HAS the parrot calling conventions
20:45 cotto M1 is needed because of the mismatch between C and PCC.
20:46 kjs right. so you want to do away completely with C, wherever there's intereaction possible between parrot assembly and parrot's implementation language
20:46 cotto not completely, but largely
20:46 kjs that means that certain parts can stay in C, as long as there's no interaction (data and control)
20:47 cotto right
20:47 kjs so, this means that large chunks of Parrot will be implemented in M0
20:47 kjs assuming for this sentence there is no M1 or higher language
20:47 cotto right, but we'll need M1 because it'd be insane to implement much of Parrot in m0
20:47 kjs indeed
20:48 kjs so enter M1.
20:48 kjs will M1 have the parrot calling conventions then?
20:48 kjs have=support
20:48 cotto I think the answer is "yes".
20:49 kjs ok, so these can be either implemented at the M0 level, or by the M1 compiler
20:49 kjs but there needs to be some essential basic support at the M0 level
20:49 kjs with continuations at that level
20:50 cotto yes.  In M0, call frames are equivalent (roughly) to continuations.
20:50 kjs ok.
20:50 kjs ok so bascially, at M1 level, we could define fancy syntax for named parameters, optional parameters, etc. all the fancy stuff that PIR has
20:50 kjs since these are part of the PCC right?
20:50 cotto yes
20:50 kjs cool. ok clear.
20:51 kjs next question :-)
20:51 kjs i've done some browsing of the parrot source
20:51 kjs and from a distance, it's all a bunch of moving around data :-)
20:51 kjs with very diffficult code, really
20:51 kjs most function just move around stuff, copy data, etc.
20:51 kjs i suppose that's what any program does
20:51 kjs anyway, to make a long story short:
20:52 kjs Parrot's code is written in C with all sorts of fancy stuff that is invented by parrot developers
20:52 kjs for instance, VTABLE_blabla()
20:52 kjs these are macros I believe
20:52 kjs (right?)
20:52 whiteknight yes
20:52 kjs and a lot of other infrastructure that is built to implement many of parrot's fancy features.
20:52 cotto magic macros that get post-processed by perl, but mostly yes
20:53 whiteknight include/parrot/vtable.h, I think
20:53 kjs right.
20:53 kjs well, since we're /defining/ M1 language, we might as well make it easy for ourselves
20:53 kjs by building supporting syntax for this
20:53 kjs so no more preprocessor stuff
20:53 kjs but just plain built-in M1 code.
20:54 kjs *code/syntax
20:54 kjs as an implication:
20:54 kjs I assume PMCs will be written in M1 as well
20:54 whiteknight yes
20:54 kjs PMCs are bascially C++ -styel classes, really (prob some diffs here and there)
20:54 kjs in that they support inheritance
20:54 kjs and methods
20:55 kjs why not add syntactic support for that?
20:55 kjs have a keyword "method"
20:55 kjs and also "vtable" (or "virtual" to please C++ heads)
20:55 kjs to make it clear which methods are virtual/vtable
20:55 kjs and which are not
20:55 kjs bascially, implement your own OO system on top of M0
20:55 kjs with a vtable and all. shouldn't be /that/ difficult.
20:56 whiteknight depends what we want out object model to look like at the time
20:56 whiteknight the way PMCs are now is not the way they will always be
20:56 whiteknight though, that's an issue of code generation, not M1 parsing
20:56 kjs whiteknight: not sure if this is what you're saying but the OO model of M1 need not be the same as Parrot's object model
20:56 whiteknight okay, yes
20:57 kjs though it /would/ be nice in a way, i suppose
20:57 kjs (so this would also imply keywords such as "extends" and perhaps "implements" or whatever)
20:57 cotto one thing to be aware of is that post-M0 PMCs will be built on 6model
20:57 kjs (as well as syntax as: foo.bar(), where foo is a PMC instance and bar a method on that)
20:58 kjs what do you mean by post-M0 PMCs, cotto?
20:58 cotto PMCs in Parrot after we've completely moved to things that compile down to M0
20:59 kjs eh, so PMCs written in M0/M1?
20:59 cotto yes
20:59 kjs ok, well so either 6model needs to be supported at the M0 level, or M0 needs to be sufficiently functional that 6model can be implemented on top of M0
21:00 cotto M0 needs to be able to support a 6model implementation
21:00 kjs right. that's what i tried to say in my ill-worded statement :-)
21:00 kjs even ill-worded is ill-worded. I meant ill-phrased.
21:01 kjs ok. well so far everything sounds good to me. makes sense.
21:01 kjs another more bigger issue:
21:01 kjs if parrot is ipmlemented in M1/M0
21:01 kjs then it's no longer C
21:01 kjs will that be a problem to attract developers?
21:01 kjs one of the original reasons behind the choice for C is developer pool
21:01 kjs (dan sugalski wrote this many years ago)
21:02 cotto If M1 is sufficiently C-like, it shouldn't be too big of a barrier to entry.
21:02 kjs ok. one idea i had for M1, is to "fix" the issues that C has
21:03 NotFound I think that at the time the choice was "not C++"
21:03 kjs including, also, if you want to push it a bit farther, to do away with the perl scripts that check your source code formatting, because the M1 compiler already requires it!
21:03 kjs NotFound: I believe not C++ because of portability, and C is "the best we have"
21:04 kjs ok, well, i just want to mention this point, because at this moment, M1 is "yet another C-like language".
21:04 NotFound kjs: no, "not C++" because of developer pool.
21:05 kjs NotFound: ah ok. it's been a while :-)
21:05 cotto I'd rather not force stylistic choices at the compiler level.
21:05 kjs cotto: could be warnings but ok. not v important at this point, just an idea.
21:05 cotto it's worth exploring
21:05 kjs anyway, to build-in the design of M1 the abuse of the language
21:05 kjs eh, to prevent that.
21:06 cotto I'm fine with "easy to use correctly"
21:06 cotto and "hard to misuse"
21:06 kjs right.
21:06 kjs ok. so there's another isue with this approach: we don't know if it will work well :-)
21:07 kjs it might not be faster.
21:07 kjs basically, it will be an interpreter on top of an interpreter.
21:07 whiteknight it might not
21:07 whiteknight This whole experiment is going to depend heavily on having a high-quality JIT in place
21:08 kjs ok.
21:09 kjs so antoher implication of this architecture will be that all extensions that interact with control and data need to be implemented using M1
21:09 kjs so only the C parts could be extended using C, effectively.
21:11 kjs ok, well i'm just stating some observations at this point. My time will at some point be more limited, but it's great to do some hacking on M1 now. The answers above confirm that some of my ideas could be useful and work.
21:11 kjs I have a few more questions: I'm not really clear on function calling and parameter passing at this stage (how that's done in M0). (2) do exceptions (throwing, catchgin) exist at the M0 level?
21:13 cotto calling conventions for M0 need to be defined, so it's not surprising that you're unclear on them.
21:13 cotto there are some basic ideas on exceptions in the m0 spec, but nothing that's been thoroughly fleshed out
21:14 kjs yes, one of the ideas is that M0 instructions are easy to jit. but PCC are quite complex; if there's insturction support at the M0 level (similar to PIR level) then those M0 instructions are unlikely to be easy to JIT.
21:14 kjs cotto: ok, i'll ignore those bits then at the moment.
21:14 whiteknight PCC is going to have to become much less complex
21:14 whiteknight at the lowest levels it could have far fewer features
21:15 kjs so, no named parameters
21:15 kjs which i think are quite expensive
21:15 kjs with hashtables and all
21:15 kjs and slurpy etc. i think too
21:15 whiteknight yes
21:16 kjs one thing i noticed, maybe wrongly, is that the M0 virtual machine looks a bit like parrot in the beginning, as defined by Dan
21:16 cotto interesting
21:17 whiteknight I'm not aware of designs that old
21:17 kjs not sure if i'm correct, but i was reminded of it.
21:17 kjs not sure if those designs can be traced back online
21:17 cotto dan's old blog was still online last I checked.  I should skim through it.
21:17 kjs ok, well i have 1 final thing that makes life slightly hard on me at the moment.
21:18 kjs and that is that the assembler perl script doesnt' work here for some reason
21:18 kjs lemme see what the error message is (just a min.)
21:18 cotto metadata perhaps?
21:18 cotto that's definitely an area that's nyi
21:19 cotto either nyi or broken, iirc
21:20 kjs what's nyi?
21:20 kjs pastebin?
21:20 kjs what's the command to get the pastebin link again?
21:20 cotto not yet implemented
21:20 kjs oh right
21:21 kjs well the short verison is: can't locate autodie
21:21 kjs see parrot channel for link to paste
21:22 cotto that's more of a #parrot question.  Let's continue it there.
21:22 kjs ok. i've got most answers I wanted. thanks.
21:23 cotto excellent
21:23 cotto and thanks for the work so far
21:23 kjs it's my pleasure :-)
21:23 cotto any other questions before we wrap up?
21:24 whiteknight just an announcement
21:24 whiteknight I've posted some of my ideas for revamping the IO subsystem in the wiki (https://github.com/parrot/parro​t/wiki/Tasklist:-IO-Subsystem) and in the whiteknight/io_cleanup1 branch
21:24 whiteknight I'm probably going to start on that project soon, feedback would be appreciated
21:24 cotto also, we're officially in GSoC season as of yesterday
21:24 whiteknight yes, that started on monday
21:26 NotFound whiteknight: moving stringfication to the buffering layer may also simplify things.
21:27 whiteknight Notfound: yes, I plan on doing that. Also, transcoding and other string-related issues
21:27 whiteknight So all IO transactions will move through a buffer, though most buffers won't store any data
21:27 whiteknight or, something like that
21:28 NotFound whiteknight: yes, in the non-buffering case doing only the conversions.
21:29 cotto I'll read through that page in detail later today.  I somehow missed it until just now.
21:30 whiteknight cotto: it was poorly named until a week ago or so
21:31 whiteknight I added the four bullet points at the top, which are pretty broad. Everything else was there already (and some of it will be tackled en passant in my refactor)
21:31 whiteknight Some to-do items which would have been very hard in the old system seem conceptually very easy in the new design
21:33 whiteknight I am already starting to plan out a second-round refactor, which will make using custom IO PMCs and other IO mechanisms much easier for the user
21:34 whiteknight brrt has already been asking for output vectors that are completely unsupported by our system (calling a C-level function with all output requests instead of a PIOHANDLE, etc)
21:36 whiteknight anyway, I have to run catch a train. I'll be on later tonight
21:36 cotto It's good to know some of the motivation behind the changes.
21:36 cotto any other questions before we call it a wrap?
21:39 cotto let's call it a wrap.
21:41 NotFound left #parrotsketch
21:43 tadzik left #parrotsketch
22:37 lucian joined #parrotsketch
23:15 lucian joined #parrotsketch

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