[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]IRC Meeting Summary : 2002-10-19
From: |
Gopal V |
Subject: |
[DotGNU]IRC Meeting Summary : 2002-10-19 |
Date: |
Sun, 20 Oct 2002 14:26:29 +0530 |
User-agent: |
Mutt/1.2.5i |
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
- [DotGNU]IRC Meeting Summary : 2002-10-19,
Gopal V <=