Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 10 April 2012.
00:30 wagle joined 02:51 japhb joined 06:00 contingencyplan joined 07:41 contingencyplan joined 08:17 lucian joined 08:54 lucian joined 11:02 kjs joined
kjs REPORT FOR KJS: 11:02
+ Started implementation of "M1", a subset of C, slightly extended with features handy for Parrot/M0 11:03
+ implementation can be found at: github.com/parrot/m1
+ 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
+ Feedback would be most welcome; is this on the right track?
.EOR
12:03 bluescreen joined 12:31 kjs joined 13:07 bluescreen joined
Coke REPORT: $dayjob and teh sick ate all my tuits. coke/rm_pasm still idling. 13:44
15:23 contingencyplan joined 15:55 contingencyplan joined, bluescreen joined, japhb joined, wagle joined, alvis joined, PerlJam joined, Coke joined, eternaleye joined, sorear joined, Tene joined, wendar joined, cotto joined, jlaire joined, wagle_ joined, eternaleye joined 15:56 nine joined 16:02 eternaleye_ joined, allison joined, wagle joined 17:44 lucian joined 17:57 kjs joined 19:07 lucian joined 19:22 NotFound joined 19:44 brrt joined
brrt for the logs 19:47
REPORT: started working on the design of mod_parrot. 19:49
+ starting apache with a debug configuration 19:50
+ todo: link parrot to apache in a module
EOR
20:29 benabik joined 20:33 whiteknight joined
cotto hello 20:37
kjs hello
whiteknight hello
benabik hihi
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.
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.
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
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
cotto kjs, sure
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?
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.
but i'm not a math wizkid. perhaps there's certain mathematical axioms or whatever.
i seem to remember the minimum is 1 equality and 1 gt or lt operator 20:43
so, 2 to implement all 6: ==, !=, >= >, <, <=
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 :-)
cotto what is?
kjs what's more important is the role of M0/M1
NotFound If you have <= , == is a <= b and b <= a
kjs (not implying that my hacking result /is/ M1, but at least it's a prototype)
so, bascially, the Big Question is, IF C language had Parrot Calling Conventions, would M0 still be necessary? 20:45
cotto no
kjs right.
so basically you'd like to do implement parrot in a language that HAS the parrot calling conventions
cotto M1 is needed because of the mismatch between C and PCC.
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
kjs that means that certain parts can stay in C, as long as there's no interaction (data and control)
cotto right 20:47
kjs so, this means that large chunks of Parrot will be implemented in M0
assuming for this sentence there is no M1 or higher language
cotto right, but we'll need M1 because it'd be insane to implement much of Parrot in m0
kjs indeed
so enter M1. 20:48
will M1 have the parrot calling conventions then?
have=support
cotto I think the answer is "yes".
kjs ok, so these can be either implemented at the M0 level, or by the M1 compiler 20:49
but there needs to be some essential basic support at the M0 level
with continuations at that level
cotto yes. In M0, call frames are equivalent (roughly) to continuations. 20:50
kjs ok.
ok so bascially, at M1 level, we could define fancy syntax for named parameters, optional parameters, etc. all the fancy stuff that PIR has
since these are part of the PCC right?
cotto yes
kjs cool. ok clear.
next question :-) 20:51
i've done some browsing of the parrot source
and from a distance, it's all a bunch of moving around data :-)
with very diffficult code, really
most function just move around stuff, copy data, etc.
i suppose that's what any program does
anyway, to make a long story short:
Parrot's code is written in C with all sorts of fancy stuff that is invented by parrot developers 20:52
for instance, VTABLE_blabla()
these are macros I believe
(right?)
whiteknight yes
kjs and a lot of other infrastructure that is built to implement many of parrot's fancy features.
cotto magic macros that get post-processed by perl, but mostly yes
whiteknight include/parrot/vtable.h, I think 20:53
kjs right.
well, since we're /defining/ M1 language, we might as well make it easy for ourselves
by building supporting syntax for this
so no more preprocessor stuff
but just plain built-in M1 code.
*code/syntax 20:54
as an implication:
I assume PMCs will be written in M1 as well
whiteknight yes
kjs PMCs are bascially C++ -styel classes, really (prob some diffs here and there)
in that they support inheritance
and methods
why not add syntactic support for that? 20:55
have a keyword "method"
and also "vtable" (or "virtual" to please C++ heads)
to make it clear which methods are virtual/vtable
and which are not
bascially, implement your own OO system on top of M0
with a vtable and all. shouldn't be /that/ difficult.
whiteknight depends what we want out object model to look like at the time 20:56
the way PMCs are now is not the way they will always be
though, that's an issue of code generation, not M1 parsing
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
whiteknight okay, yes
kjs though it /would/ be nice in a way, i suppose 20:57
(so this would also imply keywords such as "extends" and perhaps "implements" or whatever)
cotto one thing to be aware of is that post-M0 PMCs will be built on 6model
kjs (as well as syntax as: foo.bar(), where foo is a PMC instance and bar a method on that)
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
kjs eh, so PMCs written in M0/M1? 20:59
cotto yes
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
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 :-)
even ill-worded is ill-worded. I meant ill-phrased.
ok. well so far everything sounds good to me. makes sense. 21:01
another more bigger issue:
if parrot is ipmlemented in M1/M0
then it's no longer C
will that be a problem to attract developers?
one of the original reasons behind the choice for C is developer pool
(dan sugalski wrote this many years ago)
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
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!
NotFound: I believe not C++ because of portability, and C is "the best we have"
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.
kjs NotFound: ah ok. it's been a while :-) 21:05
cotto I'd rather not force stylistic choices at the compiler level.
kjs cotto: could be warnings but ok. not v important at this point, just an idea.
cotto it's worth exploring
kjs anyway, to build-in the design of M1 the abuse of the language
eh, to prevent that.
cotto I'm fine with "easy to use correctly" 21:06
and "hard to misuse"
kjs right.
ok. so there's another isue with this approach: we don't know if it will work well :-)
it might not be faster. 21:07
basically, it will be an interpreter on top of an interpreter.
whiteknight it might not
This whole experiment is going to depend heavily on having a high-quality JIT in place
kjs ok. 21:08
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
so only the C parts could be extended using C, effectively.
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
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?
cotto calling conventions for M0 need to be defined, so it's not surprising that you're unclear on them. 21:13
there are some basic ideas on exceptions in the m0 spec, but nothing that's been thoroughly fleshed out
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
cotto: ok, i'll ignore those bits then at the moment.
whiteknight PCC is going to have to become much less complex
at the lowest levels it could have far fewer features
kjs so, no named parameters 21:15
which i think are quite expensive
with hashtables and all
and slurpy etc. i think too
whiteknight yes
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
whiteknight I'm not aware of designs that old 21:17
kjs not sure if i'm correct, but i was reminded of it.
not sure if those designs can be traced back online
cotto dan's old blog was still online last I checked. I should skim through it.
kjs ok, well i have 1 final thing that makes life slightly hard on me at the moment.
and that is that the assembler perl script doesnt' work here for some reason 21:18
lemme see what the error message is (just a min.)
cotto metadata perhaps?
that's definitely an area that's nyi
either nyi or broken, iirc 21:19
kjs what's nyi? 21:20
pastebin?
what's the command to get the pastebin link again?
cotto not yet implemented
kjs oh right
well the short verison is: can't locate autodie 21:21
see parrot channel for link to paste
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.
cotto excellent 21:23
and thanks for the work so far
kjs it's my pleasure :-)
cotto any other questions before we wrap up?
whiteknight just an announcement 21:24
I've posted some of my ideas for revamping the IO subsystem in the wiki (github.com/parrot/parrot/wiki/Task...Subsystem) and in the whiteknight/io_cleanup1 branch
I'm probably going to start on that project soon, feedback would be appreciated
cotto also, we're officially in GSoC season as of yesterday
whiteknight yes, that started on monday
NotFound whiteknight: moving stringfication to the buffering layer may also simplify things. 21:26
whiteknight Notfound: yes, I plan on doing that. Also, transcoding and other string-related issues 21:27
So all IO transactions will move through a buffer, though most buffers won't store any data
or, something like that
NotFound whiteknight: yes, in the non-buffering case doing only the conversions. 21:28
cotto I'll read through that page in detail later today. I somehow missed it until just now. 21:29
whiteknight cotto: it was poorly named until a week ago or so 21:30
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
Some to-do items which would have been very hard in the old system seem conceptually very easy in the new design
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:33
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:34
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.
any other questions before we call it a wrap?
let's call it a wrap. 21:39
21:41 NotFound left 21:43 tadzik left 22:37 lucian joined 23:15 lucian joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!