[DotGNU]IRC Meeting Summary : 2002-10-19

[Gopal V]

IRC Meeting -- 2002-10-19
-------------------------

        The DotGNU Developers IRC meeting was conducted at irc.openprojects.net
#dotgnu on 2002-10-19th Saturday 1000 UTC and Saturday 2200 UTC. The focus
of the meeting was the possible mod to the current C# compiler to support
the Parrot bytecode format. The good people from parrotcode.org have been
there to answer questions and follow the general discussion about DotGNU
as well.

As stated in the agenda items , the choice of parrot for a bytecode 
engine has many motivations . The patent issue being the main head 
turner :-). Also in retrospect, we had always been talking about 
parrot as a secure VM for dynamic lanuages (perl,python..). But we'll
let's get to the meeting fast.

Ok, what follows is an annotated and abridged chatlog for the meeting,
with footnotes as necessary. It's partly chronological and partly context
based. (== ordered to makes sense :-)

[22:53] <rhysw> any parrot people around?
..........
[22:53] Action: q[acme] puts a hand up
........
[22:54] <hiroko> i'm kind of a parrot feathers hacker :)...
[22:55] <rhysw> I'm a little confused on some of the perl6-internals 
                discussion since my "C# and Parrot" posting yesterday.  
                Is it necessary to code up special-purpose PMC's in C 
                for each language that needs to be supported (e.g. CsInt,
                CsObject, ...) ?
[22:55] <rhysw> Or can a language binding be Parrot-bytecode only?
........
[22:57] <q[acme]> you'd have to add a couple of pmcs anyway as C# needs 
                  some features that parrot doesn't have (eg 32-bit ints)
...........
[22:59] <rhysw>  q[acme]: ok - just feeling out the boundaries of the 
                 system a bit  (writing PMC's would probably also help 
                 with the overflow-generating ops in C#)
.......
[23:01] <rhysw> q[acme]: I'm assuming that there is some way to write 
                non-core PMC's as a shared object, that is only loaded 
                when needed?
.......
[23:01] <q[acme]> rhysw: that's the plan. hasn't been done yet ;-)
[23:03] <rhysw> q[acme]: fine - I can easily distribute "C# patches" 
                to people who want to try out "cscc for Parrot" until 
                some better solution is devised
..........
[23:03] <q[acme]> (or how to do object-like things in parrot with vtables)
[23:03] <t3rmin4t0r> rhysw: btw, I was encountering a bug in enum handling
[23:03] Action: rhysw ducks
[23:03] <q[acme]> rhysw: or get them applied to parrot ;-)
........
**********/me distracts Rhys and the parrot thread slowly dies out*******
Quotd Rhys: "don't copy the beast - branch out" -- about future plans

*********the discussion goes into a bug & todo thread *******************
..............
[23:15] <t3rmin4t0r> FileAccess.cs:31: `Read' is not declared in the 
                     current scope
 
*******************DotGNU Wiki page is previewed out*********************
[23:17] <ajmitch> http://www.libertyetech.com/cgi-bin/twiki/view/DotGNU
[23:17] <springer> ajmitch - Is the WW wiki official yet?
[23:17] <ajmitch> springer: uhh, sorta yeah :)
[23:18] <springer> I'll post my notes on working with gdb and cscc.
..............
[23:27] <ajmitch> it's on chillywilly's box and is incredibly slow

********************complier discussions continue********************
[23:19] <silvernerd> rhysw: do I asume correctly that pnet is a 3 pass 
                     parser:
[23:20] <rhysw> parse, type gathering, sem analysis, assembly codegen  
                (assembly itself happens separately)
[23:20] <t3rmin4t0r> for me the compiler ends where the assembler starts

**********************QTSharp in the news ****************************
[23:31] <t3rmin4t0r> I need that for debugging QT#
[23:31] <t3rmin4t0r> 800 warning
[23:32] <ajmitch> it's a code generator, so probably 800 of the same
[23:32] <rhysw> is this the "new" thing that you were discussing on the 
                list?  If so, they should fix their binding generator, IMHO.
                
****************Rhys's Philosophy about Weekend Warriors******************
[23:50] <t3rmin4t0r> silvernerd: you think I'm good at PR ?
[23:51] <t3rmin4t0r> rhysw: remember the WW announcement :-) "rhys 
                     has allowed us free run of the compiler"
[23:51] <silvernerd> t3rmin4t0r: yup
[23:51] <silvernerd> note that that sentence was Gopal's idea
[23:52] <rhysw> yeah - I only found out about WW having free run after
                the announcement :)
[23:52] <rhysw> (not that I mind)
[23:52] <ajmitch> rhysw: we didn't know if you were to be hacking much :)
[23:52] <mdupont> rhysw: LOL, that is funny
[23:53] <rhysw> the more bugs the WW fix, the less Rhys has to

********* Arise Sir Rich333, Knight of The Bound Variable ***************
[00:01] <rhysw> I can set up commit access (what's your savannah id?)
[00:01] <Rich333> rhysw: Rich333
[00:01] Action: springer notes that rhys is feeling generous today.
[00:07] <rhysw> rich333 and springjp now have cvs access - try not to 
                mess up the tree too badly guys :)
[00:08] <ajmitch> rhysw: hey, i've had cvs access for awhile, i haven't 
                  killed it yet ;)
[00:09] <rhysw> ajmitch: since you only change the debian directory, and
                it was your mess to begin with, there's not much that can 
                go wrong.
[00:09] <ajmitch> hehe
[00:10] <ajmitch> rhysw: wait until i start dabbling with the compiler...
[00:11] Action: rhysw runs down the hall screaming ...
...
*********** Parrot rises again from the ashes. No, Not Phoenix.**********
[00:03] <t3rmin4t0r> rhysw: are we going to use dictionaries and method 
                     pointers for emulating classes here ?
[00:04] <rhysw> t3rmin4t0r: for parrot?
[00:05] <t3rmin4t0r> rhysw:yup
[00:06] <rhysw> t3rmin4t0r: probably initially we'll need to represent 
                objects as PerlHash values or something.  Dan is apparently 
                working on an object manipulation system for Parrot.
[00:06] <t3rmin4t0r> rhysw: well, that's quite like Python's __dict__
[00:21] <q[acme]> i have to go. Dan'll be here for the second meeting if 
                  you need to ask parrot questions, otherwise i welcome 
                  you all to parrot ;-)

*****************************The New Deal******************************* 
[01:09] <fitzix> Microsoft and .Net have largely been neutralized as Free 
                 Software killers
[01:10] <Rich333> I think gopz was trying to say the same thing a couple 
                  of weeks ago on the list... move from working against 
                  MS to keeping the internet open and free
[01:14] <fitzix> I think that people feel that the tone of the project is 
                 largely confrontational - which it was - and that now 
                 that doesn't reflect the project
****************************Meet-a-thon Plans*****************************
[02:30] <fitzix> perhaps that's a good theme to end the meet-a-thon on
[02:30] <minddog> meet-a-thon where is this
[02:31] <Rich333> fitzix: yeah... introduce any new ppl who show up to 
                  the project to start it off... discuss everything... 
                  end with rejuv stuff
[02:31] <Rich333> minddog: here... next week
[02:31] <minddog> oh nice, maybe you can come to the slashdot meetings 
                  or WIG at ASU
**************************/me sees a PR oppurtunity there******************
[02:32] <minddog> ahh, ill be semi-new by next weekend
[02:33] <Rich333> meetathons are always good... I was on the list for a 
                  couple of months b4 the last meetathon... I didn't start
                  hacking on pnetlib 'til after I went to the meet
[02:33] <fitzix> Rich333: yeah - sort of a blow-out announcement
[02:34] <fitzix> perhaps try coordinating a site reorg with that so that 
                 we can start on a completely new foot
[02:34] <fitzix> So - Sunday, we end with the rejuvination announcement and 
                the site re-org

***********************Webservices , Php and Licenses*********************
[03:06] <minddog> Rich333 is it legal to study the source of php4
[03:06] <minddog> and not copy any code
[03:06] <Rich333> then you start a thread
[03:06] <minddog> okay got it
[03:06] Nick change: minddog -> minddog[z3hack]
[03:07] <Rich333> minddog[z3hack]: it is legal, but you would be 
                  contaminating yerself mentally with their code... 
                  they could sue you
[03:07] <Rich333> if you were to use stuff learned from zend in gnu php, 
                  they could sue
[03:07] <Rich333> just using their ideas, not their code
[03:08] <Rich333> cuz yer code would be similar
[03:08] <Rich333> get too similar, and it's lawsuit time
[03:10] <minddog[z3hack]> true
[03:10] <minddog[z3hack]> its all bout the syntax rules, something we 
                          can do without lookin at code
*****Clean room procedure: read code and spec it, read spec & code*********
[03:11] <Rich333> yep... copy interface, not implementation, and yer fine
[03:11] <minddog[z3hack]> this is really invaluable lesson
******************The discusssion goes political***************************
...........
[03:26] <minddog[z3hack]> no political movement on FSF been public.
.....
[03:36] <Rich333> Vote GNU! Vote for Freedom!
....
***************************Dan arrives early******************************
[08:14] <minddog[void]> do i build treecc before i build pnet
[08:14] <minddog[void]> i think so
[08:14] <Dan> I'm definitely not the guy to ask about that
..........
[09:10] <Dan> Quick .NET question. Does .NET's VM require atomic 64-bit 
              integers?
[09:10] <S11001001> Dan: you talking about M$ .NET?
[09:10] <Dan> Or ECMA's. Don't much care either way. :)
[09:13] t3rmin4t0r (address@hidden) joined #dotgnu.
[09:13] Action: t3rmin4t0r has some good news about Parrot ....
[09:14] <Dan> Really? Is it done? I certainly hope so, that'd make my 
              life easier
[09:14] <t3rmin4t0r> Dan: :-)
[09:14] <t3rmin4t0r> but this was my "hello world" to parrot
[09:15] <t3rmin4t0r> http://symonds.net/~gopalv82/expr_compiler.tgz
[09:15] <Dan> Does it compile C# to parrot? That'd be cool.
[09:15] <t3rmin4t0r> I have ported ("very ugly and cumbersome") code for 
                     an expression compiler for IL
[09:15] <t3rmin4t0r> Dan: don't rush me :-)
[09:15] <Dan> Oh, and I'll repeat an older question: Does .NET require 
              64 bit integers?
[09:15] <t3rmin4t0r> It's 1:40 AM here
[09:16] <t3rmin4t0r> Int64s are there in .NET
[09:16] <t3rmin4t0r> just like Int32s , and Int16s
[09:16] <Dan> Damn. Okay, one more thing to go think about.
[09:16] <t3rmin4t0r> Dan: btw, that link I posted was a small expression 
                     compiler I use for learning purposes
[09:16] <t3rmin4t0r> I have made it output imcc code

***********************Performance Counts (upto 10 and goes home)**********
[09:17] <Dan> Cool. Wonder how the performance ranks against the .NET 
                core. With complex expressions the register scheme should 
                be a win
[09:19] Action: t3rmin4t0r has stopped thinking speedwise a long time ago
[09:19] <S11001001> t3rmin4t0r: rhysw says he isn't going to do a JIT, 
                                IIRC, at least not for a while
[09:19] Action: Dan thinks speedwise all the time
[09:19] <Dan> No point in writing the software if a pencil and paper would 
              be faster
 
********************Register machines Vs Stack Machine *****************
[09:27] <Dan> Okay, just getting a handle on things. I've not paid much 
              attention to .NET stuff, other than trying to make sure 
              Parrot runs equivalent programs faster than Mono.
[09:27] <t3rmin4t0r> Dan: that's great !
[09:27] <t3rmin4t0r> so C# programs compiled to parrot will run faster 
                     as well :-)
[09:27] <Dan> Apparently Miguel thinks register machines are the wrong 
              way to go. I take that as something of a challenge :)
[09:28] <Dan> C# will probably have less bookkeeping to do, which ought 
              to make much of it faster.
************************************ YAY ! ***************************
[09:28] <t3rmin4t0r> Dan: all that revolves round how the "Object" is 
                     implemented
[09:29] <t3rmin4t0r> the PerlHash idea reminds me of python's __dict__
[09:29] <Dan> It should remind you of perl's hashes, which is where they 
              mostly draw from
[09:30] <t3rmin4t0r> hmmm... using hashes for member storage is not that 
                     new or revolutionary
[09:30] <Dan> Position preserving hashes are obligatory for fast symbol 
              table lookups. Old concept.
[09:30] <Dan> Lisp, no doubt, did it all 30 years ago :)

*****************************Python and Parrot**************************
[09:33] <S11001001> Dan: so I gather you're involved with Parrot?
[09:33] <Dan> Yeah. I'm the designer
[09:34] Action: S11001001 is interested in the possibility of compiling 
        Python <gasp!> to Parrot bytecode so as to load GNU Enterprise 
        et al up with DotGNU eventually
[09:35] Action: Dan notes that a python compiler is on the big ToDo list
[09:35] <Dan> Naive python bytecode translation should be reasonably simple

*****************************Parrot, IL and JVM**************************
[10:26] <Dan> acme: Do you remember if the JVM requires 64 bit ints?
[10:27] <q[acme]> Dan: yup, for longs. see 
                  http://java.sun.com/docs/books/vmspec/2nd-edition/html/
                  Overview.doc.html#22239
[10:28] <Dan> Okay, then. That clinches it. Time to do weird things for 
              parrot's ints.
[10:29] <q[acme]> shame that jvm and msil are more hardware-level really ;-)
[10:30] <Dan> I just begrudge the cache fluff that emulated 64 bit ints 
              will bring
[10:31] <Dan> But split registers are a major pain, and I don't want to 
              emulate 64 bit math anywhere if I can avoid it
[10:37] <Dan> Hrm. How close does the ECMA 335 doc map to what .NET really 
              does?
[10:43] <Rich333> most likely, not very closely... MS rarely follows the 
                  standard all that well
[10:43] <Rich333> we're more compliant
***************************Second meeting starts*************************
[10:56] rhysw (address@hidden) joined #dotgnu.
[10:56] <ajmitch> morning
[10:56] <rhysw> hello
[10:56] <ajmitch> first time we've had a second meeting for awhile :)

*************************Guru meets Guru*********************************
[11:01] <rhysw> I have some questions for the Parrot guys in the audience, 
                if they are still around ...
[11:02] <Dan> What can I do for you to illuminate the inner reaches of 
              Parrot? :)

*********************Long,Ulong,And other strange type******************
[11:03] <rhysw> first, a stylistic question - should new engine facilities 
                be added by way of PMC's (e.g. CsInt), or opcodes (convert
                int to short), or does it depend?
[11:03] <Dan> Depends. A mix of both is probably the right way.
[11:03] <Dan> I'm going to add int and float conversion code, so I regs 
              can be 8, 16, 32 or (gack) 64 bits, and F regs single or 
              double precision
[11:03] <Dan> With opcodes to handle that, of course
[11:04] <Dan> For more complex things, PMCs are probably in order.
[11:04] <rhysw> are you thinking of "add_8bit" or "add;conv_8bit" ?
[11:04] <Dan> Probably, much as I loathe the idea, add8/add16/add32/add64 
              and its ilk
[11:05] <Dan> Less info lost, so more hints for the JIT and various other 
              bits of the engine
[11:05] <rhysw> add8/add16 aren't really necessary if you have conv 
                opcodes, because in the few cases where 8-bit/16-bit ops 
                are required, re-normalizing after a 32-bit op will be 
                sufficient.
[11:06] <Dan> What, even with signed 8 and 16 bit values?
[11:06] <rhysw> yep - it's what JVM and IL do.  e.g. "iadd; i2s"
[11:06] <rhysw> the i2s is responsible for truncating, and then sign-extending.
[11:07] <rhysw> ...back to int
[11:07] <Dan> Really. Interesting. Crap idea, but interesting nonetheless.
              Someone was too hung up on "tiny instruction set"
[11:07] <Dan> I'll have to give Guy a hard time if I see him. :)
[11:07] <rhysw> :)
[11:07] <Dan> Still, if that works, I'm cool with it. Less for me to deal
              with to start
 ..........
[11:10] <Dan> rhysw: Special case code for special machines is fine. 
              Hobbling the capable machines for the less capable ones is 
              silly
[11:11] <rhysw> it's your baby - either approach is fine with me - I will 
                need the conversion opcodes regardless though, for 
                implementing C# casts.
[11:11] <Dan> That's not a problem. Worst case we can throw them in a custom 
              dynamically loaded opcode library, if we don't just make them
              standard
[11:12] <rhysw> that sort of brings up another question - it appears that 
                the Parrot engine is maleable in that you don't use Parrot
                per se, but "Parrot plus these extra bits for my language".  
                Is that correct?
[11:12] <minddog> synergy =D
[11:13] <Dan> Potentially, yes. If you need bits that aren't part of the 
              standard distribution, you just load what you need.
[11:15] <rhysw> just asking - I'll assume that eventually a "core Parrot" 
                will emerge that has 99% of the useful stuff and so it 
                won't be as big an issue.
[11:15] <Dan> It'll have everything that Perl needs, and if the ports are 
               done Python and Ruby, so odds are that'll be fine for most 
               anyone
[11:16] <Dan> It'll be turing complete, so you can certainly use the core 
              set, if going with a custom library's not deemed the best way.

************************Object Orientation Comes Up*********************
[11:16] <rhysw> next question - could you explain how the object system 
                is going to work?  i.e. how one defines a "class", 
                invokes a virtual method, etc.
[11:17] <Dan> I'm a little fuzzy on runtime class creation, as Larry's 
              still working that out for perl. For method calls, you ask 
              your object for a method variable (giving it the method name) 
              and you call it
[11:18] <rhysw> Dan: will there be some kind of class metadata, or will 
                the program be responsible for building a "thing" that 
                represents the class, using Subs to register methods and 
                what-not?
[11:19] <Dan> There'll be class metadata. i'm not sure whetner individual 
              classes will just be objects themselves that you query, or 
              something more fancy.
***********************Some really funny remarks about OO **************
[11:20] <rhysw> OO is for people who don't know how to program procedurally ...
[11:20] <Dan> Objects are for people who can't flip the front-panel toggle 
              switches :)
[11:20] <rhysw> exactly
[11:21] <Dan> But this could quickly degenerate to "When I was a kid we 
              didn't even *have* ones! Just zeroes..." so we should 
              probably stop :)
[11:21] <springjp> you had zeroes :-)
[11:21] <Dan> Well, I'm still sorta young

*********************Simple & Abstract ****************************
[11:21] <rhysw> anyway - if there is going to be class metadata, try not 
                to wire it to a specific object model, like the JVM and 
                IL guys did.
[11:22] <Dan> I've got Python, Ruby, perl 6, and potentially perl 5 style 
              objects to deal with. Simple and abstract are the words I'm
              living by :)
              
****************** Method Dispatchers : Lookup and find "god"************
[11:23] <rhysw> Dan: good - I was looking into how to do interfaces the 
                     other day and it pretty much came down to "invoke 
                     the virtual method called InterfaceName.X", which was 
                     pretty easy.
[11:24] <Dan> That's my goal. That way when people decide that the four 
              different method dispatch methods we have aren't good enough
              then they can write their own
[11:24] <rhysw> Could you describe the four methods so that I have them 
                straight?
[11:25] <Dan> I picked the number out of the air, but there's   
              leftmost-depth first, leftmost breadth-first, 
              closest based on signature, and redispatched versions 
              of those three.
[11:26] <rhysw> Dan: ok - I'll do some more research on them later.

**************************Subroutine, Libs and OO again*******************
[11:27] <rhysw> next question - if I "bsr" to a subroutine that isn't 
                defined in the current assembly/bytecode file, will it 
                fix it up at run time?  Another way of expressing this 
                I suppose is "how do I refer to a subroutine in a library"?
[11:28] <Dan> bsr's not for language-level sub dispatch
[11:28] <Dan> For named subs visible to everyone you get the sub PMC from 
              the symbol table and call it with the call opcode
              
*****************************The masters Agree****************************
[11:30] <rhysw> Dan: ok - I think I'm basically on the right page with
                     Parrot now.
[11:30] <Dan> Cool. Sounds like I need to get more high-level descriptive 
              docs written
**************************C compilers for Parrot ?************************
[11:31] <rhysw> Dan: to go off on a different tangent now - C support
[11:31] <rhysw> Dan: compiling C to Parrot, that is
[11:31] <Dan> Ah, that. Yeah, definitely doable. It'll be rather slow, though
[11:31] <Dan> Our function call overhead's rather large compared to what C needs
[11:32] <Dan> Still, I find the thought of C with native continuations 
              rather interesting. Scary, but interesting
[11:32] <rhysw> Dan: I was more thinking of the memory layout issues.  
                C code is very particular about struct layout, array 
                representation, etc.  I didn't see any opcodes that 
                would allow one to do "pull an int32 out of offset N 
                from this pointer".
[11:33] <Dan> C's not at all particular about struct layout, unless they 
              changed the standard.
[11:33] <Dan> Still, you can do them either with struct PMCs, whcih'd be 
              slowish, or with the pack/unpack opcodes, which I bet are 
              insufficiently documetned
[11:35] <Dan> Still, the packed structures need more thoght. Hrm.
[11:35] <rhysw> Dan: I suppose a better question would be "is supporting 
                     C a goal, or would it just be a cool hack but 
                     otherwise uninteresting?"
[11:36] <rhysw> because, as you say, it wouldn't be terribly efficient ...
[11:36] <Dan> Neither, really. It's interesting in the sense that it'd let 
              people use code that they otherwise couldn't, if they don't 
              have a C compiler for.
[11:36] <Dan> But it's definitely not a primary goal
[11:36] <Dan> Consider it both mildly interesting and mildly bemusing :)
[11:37] <fitzix> Dan: It could make it very useful as a power tool
[11:37] <Dan> True, but I'm not willing to lose sight of the primary goal
              for it.
[11:37] Action: rhysw greps around in his head for any more questions
[11:37] <ajmitch> rhysw: is your goal to support parrot in the codegen stage?
[11:37] <fitzix> Dan: That makes sense.

**************************They plan implementations !*****************
[11:40] <rhysw> I'm currently in the investigation stage to figure out 
                how the code generator will work.  eg. whether I'll 
                generate pasm or imcc.  I'm also investigating object 
                layout and method dispatch, which will probably be 
                isolated enough that the Parrot object system can be 
                plugged in later.
[11:41] <Dan> Generate imcc code, though imcc will at some point take 
              trees rather than text. It does the register spill stuff
              if nothing else, which is non-trivial
[11:41] <rhysw> trees, or three-address code?
[11:42] <rhysw> On the tree front, you may want to look at my treecc tool, 
                which does 99% of the hard work of managing abstract 
                syntax trees.
[11:42] <rhysw> http://www.southern-storm.com.au/treecc.html
[11:42] <Dan> Trees, probably. At some point there'll be an AST->bytecode 
              generator. Whether that's just IMCC or IMCC with another 
              front end's up in the air
[11:44] <rhysw> well, as one data point, I would prefer to have relatively 
                raw access to the imcc code output phase, as I already 
                have extensive AST support in cscc.
                
****************************A Parrot Chip ?*****************************
[11:49] <Dan> One of the boston perlmongers is an ASIC designer. He's 
              asked about hardware...
[11:50] Action: rhysw is in Brisbane, Australia

*****************************Linux Conf Australia**********************
[11:51] <rhysw> ajmitch: absolutely - I'm presenting "Design of the 
                Portable.NET Interpreter".
 
****************************MEETING ENDS, Almost***********************
[11:55] <Dan> I'll be stepping out, then. Later folks, it's been interesting

************************Regular DotGNU Stuff**************************
[11:56] <Rich333> any chance anyone here could do daily (or more than daily)
                  builds of pnetlib using the ms tools so we can test 
                  more quickly???
[11:57] <rhysw> someone needs to dedicate a windows machine to the cause - 
                I really can't do that here.
[11:57] <fitzix> rhysw: What kind of dedication do you need?

**********************Secret Weapons made decisive********************
[12:12] <fitzix> rhysw: Frankly, I think that Treecc is our secret weapon
                - nobody else has anything even close to this
[12:13] <rhysw> we need to raise our public profile a little more as well, 
                but in a way that won't degenerate into yet another 
                "why are you copying mono" flame war on Slashdot.
                
This is Gopal.V reporting for DotGNU-Developers,

This report was prepared due to 

[11:45] <ajmitch> someone good at writing should do a summary of this 
                  weekend's meetings :)

Gopal
-- 
The difference between insanity and genius is measured by success