OT: Nonsense(was Re: FEATURE FREEZE Sunday 14-Sep-2003)
--- Steve Fink [EMAIL PROTECTED] wrote: The code name is, of course, open for discussion. Although I reserve the right to call it the hairy tulip release if I want. Hairy tulip is shorter than open for discussion http://home.pyramid.net/gallery/hairytulip.jpg You can call me anything you want, just dont call me late for dinner! mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Of AST and YAL
--- Leopold Toetsch [EMAIL PROTECTED] wrote: James Michael DuPont wrote: The redland rdf api provides a good C api into rdf. The advantages of using rdf instead of a homegrown format are the amount of tools available, you then have filters, and visualization tools immediatly available. First I have to admit: I don't like XML. I dont either. ;) XML sucks. Logic rulez. I have been using timbls n3 notation http://www.w3.org/2000/10/swap/Primer Second I don't want an external library at such a central place inside Parrot. Yes. We can make a native structure. The only thing is this basic api. We dont need to 1. you represent the ast as a set of triples (maybe quads with context) so each thing is a statement like : subject predicate object [context]. 2. You can transform or flatten any ast into a set of triples that is the only real support that I need from you. Basically a set of functions that can be used to emit any ast as a set of logical statements. The logical statements can just be parrot arrays and the user can figure out what to do with them. 3. you can build an ast out of such triples. The only support needed is to have some way to lookup the type of predicate by a name, or to reference an ast node by id. Then we can write various parser in parrot that use this api. I guess the input could also be a parrot array with three columns. 4. You register new predicate names (i have been extracting them from the gcc) you can see some of those here http://introspector.sourceforge.net/2003/09/ildasm_header_micront.owl That could also be an array of known predicates. Each statement could just contain the index to them. 5. we dont need an rdf parser or n3 parser, but can factor that out like redland does : in fact, the only api needed to be implemented is the rdf.storage and rdf.model. those two represent the parsed state of an rdf document and the way to interface to the representation. The rest can be left out of the core. I also think (hvaing a short look at redland-0.9.14, that this might be some overkill to use that as the AST interface for parrot. yes. We can make a very cut down api and simple (parrot) provider for n3. The Eulersharp code can be compiled later to parrot via dotgnu. http://eulersharp.sourceforge.net/2003/03swap/ OTOH ... Later on when we have a two-way gateway, then you will be able to use a proof engines to do rule-based tweaking of your AST before sending this off to the backend for execution. ... ab interface to RDF would be for sure a nice to have. Yes, I am really interested in the ability to plug in a proof engine and feed it rules to tweak the code. The format is really *egal*. (sorry for the extreme-denglishing) I hope that you do not get annoyed at this suggestion, if you feel it is off topic, please tell me. No, not at all. Thanks for your input. Ok, then you get more. :) schöne Grüsse aus Frankfurt am Main, mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Of AST and YAL
--- Leopold Toetsch [EMAIL PROTECTED] wrote: Michal Wallace [EMAIL PROTECTED] wrote: (My plan for this week was to do something very similar, and try to get a simple lisplike language to integrate with python) I'm thinking of a AST text interface for imcc/parrot too. The lispish AST-dump produced by YAL is handy for debugging and testing, and it can be parsed easily to reconstruct the AST again. OK. This is where I would like to get involved. Currently I have been working on documenting the GCC ast, in hopes of making that generatly useful. See my last mail about that here : http://sourceforge.net/mailarchive/forum.php?thread_id=3080551forum_id=7974 My plan is to make a generic RDF interface to save, manip. and restore ASTS. This will also include some of the parrot languages. The redland rdf api provides a good C api into rdf. The advantages of using rdf instead of a homegrown format are the amount of tools available, you then have filters, and visualization tools immediatly available. Later on when we have a two-way gateway, then you will be able to use a proof engines to do rule-based tweaking of your AST before sending this off to the backend for execution. The other advantage of using redland is that you can exchange ASTs in memory or using one of the storage systems that plug-in like the berkleydb interface. That allows high-speed exchange of large amounts of ASTS. I hope that you do not get annoyed at this suggestion, if you feel it is off topic, please tell me. Thanks, mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Parrot - 100% Gnu.NET ?
Here is my personal answer : --- Clemens Eisserer [EMAIL PROTECTED] wrote: But I´ve searched a long time for a system like .NET that can´t be controlled by Microsoft through Patents. I am also concerned about the control of patents, and the DotGnu(TM) team implementing patented interfaces that are of questionable value. Please note that ECMA sumbitted code is *not* covered by patents. In fact in my mail to the dotgnu list that got me banned, http://dotgnu.org/pipermail/pnet-developers/2003-August/000511.html I questioned the value of implemented this CodeDom interface. - finish CodeDom and write a test suite I have done an analysis of the codedom last year. This is definitly something that I am interested in. In fact, I think we might want to create dotgnu replacement for thatt, because it is not standard and part of the patent application : 20030028685 http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=/netahtml/PTO/srchnum.htmlr=1f=Gl=50s1='20030028685'.PGNR.OS=DN/20030028685RS=DN/20030028685 United States Patent Application, 20030028685. System.CodeDom.Compiler.txt I have some ideas about how this replacment might look, in fact, my working model is much more fine tuned, and would allow code on the finiest expression level to be created. So, my question: Is it planned to include a complete classpath into parrot, including gui, network, db, sound functionality or will it have only the really needed things like perl5 had? There are numerous plans to convert java to IL. There is a project in DotGnu(TM) for a java frontend. There is a plan to have a parrot backend for dotgnu. Please not that I am not speaking for anyone except myself, Gruss züruck, mike -- All trademarks (DotGnu) are owned by thier respective owners, In no way should you interpret my statements about them as any promise of support of these ideas by the Owners to the intellectual property named DotGNU. = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: mission haiku
My haiku, compiled with -debug based on the instructions : http://www.toyomasu.com/haiku/ this is even contain a seasonal reference to the thought's blossoming in spring. 11 1 2= 5 The Mind looks inside : 2111 2 = 7 Describe form of thought's blossom 1 4 This : introspection! = 5 17 sylables --- Mike Bad spellers of the world : UNTIE = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
NEWBIE Questions about bytecode emitting and JIT Compiling and an OO library
Dear fellow hackers, First of all, I would like to say that I hope that you dont take offence at my silly questions and crazy ideas! ;) I have been looking in the amazing work that you have been doing with parrot and the work that Michal Wallace has been doing with the Pirate, the following questions have came to mind : 1. Is it possible to stored in some way ASTs inside of parrot IMC byte code in such a way that they may be evaluated and compiled at runtime? We talked about this in the context of metadata and bazookas months ago, and I am ready to start making a simple prototype on top of pirate for storeing the ASTS in the metadata alongside of the bytecode. 2. Is it possible to emit new IMC routines on the fly and have them be loaded in as if they came from the load routine? like a form or reflection.emit? 3. It is possible to make the entire parrot object system as a lib that implements objects as special variables? like the old ATT CFront? 4. Is there any attempts at debugging support in parrot, for a way to mix the original source code and assembly together, a way to enable tracebility of. These features would allow portions of the features not supported to be added into a lib and for the lib to JIT implement these funky features or fail gracefully. Any ideas or am I way over board? mike PS: please feel free to ban me from this list for wasting your time and bytes with off topic posts and crazy ideas, you may have the sudden urge to ban me for no reason at all whatsoever. :) = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: generic code generator revisited
With great interest have I read about the idea of a Generic Code generator and AST representation. I would like to point out that the current experiments with the gcc show that RDF provides an optimal representation of AST structures. I have targeted the parrot as one of the language systems to be interfaced into the introspector project. We should be able to import and export ASTs from the gcc into parrot and vice versa. You can find the current ontology for the gcc ast structures here : http://introspector.sourceforge.net/2003/08/16/introspector.n3 That defines most of the fields and types using n3 fomat. see also my explaination here : http://www.advogato.org/article/696.html and http://www.advogato.org/person/mdupont/diary.html?start=17 and http://www.advogato.org/person/mdupont/diary.html?start=16 mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Approaching m4
--- Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Hi, I have started an implementation of m4 in PIR. See http://www.gnu.org/software/m4/m4.html. That is amazing! The goal is to make a lot of tests work, and eventually getting a drop in replacement for GNU m4. The plan is to implement everything in PIR, thus building on existing PMCs. I have looked breifly into extracting high level information from m4, I wonder if that would be possible using your implementation or if one could use the existing m4 to generate code for your backend? mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Parrot for windows?
--- Gopal V [EMAIL PROTECTED] wrote: If memory serves me right, Benjamin Goldberg wrote: whine I suppose if there isn't a windows binary out there, I could try downloading and installing a C compiler (gcc? djgpp?) and then compiling my own parrot... but I don't want to do that much work! /whine Cygwin ? ... I'm not using windows but I know quite a few people who are using cygwin or the mingw32 gcc for building Gnu'ish stuff on Windows. Cygwin might be better as it also comes with a perl5 interpreter to run the Configure.pl and stuff. Otherwise you might have to *buy* a version of VC++ or something. I had tested parrot on cygwin and reported a series of bugs. Most seemed to have been fixed, but I dont know for sure. I never got any formal close on them, so I guess they are not very interesting. I dont know where to look for the bug status anyway. Some day, I will find the time and retest under cygwin. mike mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com
Re: Bytecode metadata
--- Leopold Toetsch [EMAIL PROTECTED] wrote: James Michael DuPont wrote: --- [EMAIL PROTECTED] wrote: Mike -- Thats a lot of metadata. OK that sounds fine. My current problems with the graphs of meta-data are the speed of loading. When you arrange the meta-data as a single opcode stream, you have ~zero load time for the mmap()ed case. This means, you delay parsing of this stream to the time, when you are actually using it. Great. I will review the code and see how this can be done. That would be great!!! mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
Dear All, I just wanted to ask about a conclusion on the bytecode metadata. Here are the things I would like to know about a given bytecode : what line (maybe column) it comes from Possible comments about it. If it is a method call, what is the method name,signature,locatoin If it is a variable or constant, what is the variable name, type, size If it is a expression , what is the type of it, the size For a given type, the name, size would be great to store. Is it going to be possible to store this data in the meta-data, it does not have to be all there at once, but will the framework handle it? Hopefully you have answered this already, and you can just say, rtfm. Thanks for you patience, i am a bit slow today. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
Juergen, I completly agree with you. For my needs, the meta-data does not have to be loaded at the same time at all. I can be in a different file for I care. I just want to know how where we can put it. The Microsoft IL has a whole section on meta-data, and one wonders what Parrot might be doing to address the same issues. excuse my ignorance, I am sure you addressed this, and no I have not read the new pods yet. Bytecode reading must be fast. Ideally it is mmap and start. Treewalking for bytecodegeneration should be done by the compiler. yes I agree, I just want to be able to reconstruct the tree for debugging or reverse engineering (if the compiler that produced the bytecode whats to produce this). I would like to prototype some meta-data storage of my gcc The tree metadata can sure be some kind of intermediate output of the compiler (the output of the compiler front end), but normaly this should be fed into a backend which generates fast running bytecode or even native code. That sounds great. Normally you dont need this information, I just want to know how I can store it if I *do* need it. The metadata from the c++ that i am extracting even exceeds the size of the sourcecode itself. --- [EMAIL PROTECTED] wrote: b. -- I agree that under normal circumstances the bytecode is primary. I was observing that as more and more metadata is considered, eventually its quantity (measured, say, in bytes) could approach or even exceed that of the raw bytecode. In cases where one would feel such a quantity of metadata is needed, it may not always be necessary to get greased-weasel speed-of-loading (but, see below). I understand the the mmap-and-go idea, although it doesn't always work out even when mmap is available (for example, prederef requires a side pointer-array to store its prederef results). Sometimes its mmap-mumble-go (but, see below). Certainly, there is nothing to prevent one from having the linearized bytecode pregenerated in the PBC file even when a metadata tree is also present (the tree could reference contiguous chunks of that bytecode by offset-size pairs). If you don't care about the tree, you don't process it. If you do process it, you probably produce an index data structure mapping byte code offsets to tree nodes for the debugger. I believe we retain high speed with this approach. yeah, that is the idea. Reflection and introspector require the meta-data, that can be read by special reflection operations. We do need to consider how the metadata makes it from the compiler *through* IMCC to land in the PBC file. The compiler needs to be able to produce annotated input to IMCC, and IMCC needs to be able to retain the annotations while it makes its code improvements and rendering (register mapping, etc.). I'm thinking that, too, could possibly be a tree. IMCC can pick out the chunks of IMC, generate bytecode, and further annotate the tree with the offset and size of the generated PBC chunk. The tree can be retained as the metadata segment in the PBC file. Sounds good to me. For me, it could also be a graph in triples formats (subject,predicate,object), and not a tree. This is what I wanted to know, what is defined, and what needs to be defined. Regards, mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: XML output of parse tree for Jako
Gregor, It looks like we are going into a similar direction. I would like to make sure that we can represent this information in the parrot, if the compiler writers want to provide it. --- [EMAIL PROTECTED] wrote: James -- I'm open to other ideas. I've toyed with learning DAML and RDF for some ontology stuff I'm interested in, but so far I haven't had the mental click that would make me feel comfortable working with them. I do have a good comfort level with XML in general. The click came for me was very simple : triples are simple. Rdf is simple. Tools are built to process graphs of triples. XML is more complex, xml gives you more freedom, less structure. here is an example stat64 * __statbuf; #id-59 node_fields:linenumber 394 . #id-59 node_fields:filename #filename-stat.h . #id-59 node_fields:type #id-24 . #id-59 node_fields:name #id-61 . #id-61 node_fields:strg __statbuf . #id-24 node_fields:ptd #id-29 . #id-24 node_fields:size #id-28 . #id-28 node_fields:low 32 . # the pointer is 32 bytes #id-29 node_fields:flds #id-35 . I have omitted the fields of the struct #id-29 node_fields:modifier node_modifiers:struct . # it is a structure #id-29 node_fields:size #id-34 . #id-34 node_fields:low 768 . #the struct is 768 bytes #id-29 node_fields:name #id-33 . #id-33 node_fields:strg stat64 . I am pondering the sorts of transforms I could implement against the XML I've generated (using XSLT)... Yes, xslt is good. Another twist would be: can the compiler be reasonably implemented as a handler for the SAX events generated by the parser? If so, then the XML I'm generating today is just a textual rendering of the actual data structure passed from the parser to the compiler. I'm thinking this might be possible since a good amount of the optimization will occur in IMCC. that is the idea behind the introspector, we extract the ASTs from the gcc before they get transformed to RTL. Failing the pure SAX approach (which kind of implies single-pass), the other possibility would be DOM (accept the SAX events, build a tree and use DOM to tinker with it). These would be really good for the users. XML is not a religion for me, but I am interested in pushing on it to see where the boundaries of practicality are. XML occupies the following slot in my map: A common way to render (annotated) tree structures (with ordered children) as (mostly) plain text. (of course, you can substitute graph for tree if you consider internal links). Already, tinkering with the XML rendering of the Jako parse tree has made me think more deeply about a few of the language issues. For example, I need to treat strings with interpolations as expressions rather than as string literals (I'm making this transformation on-the-fly in the compilation and SAX rendering of string literals now, but it *should* happen during parsing, making the interpolated string CHowdy $what world! result in the same parse structure as C'Howdy ' . $what . ' world!' -- the former is just syntactic sugar). Sounds good. = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
--- [EMAIL PROTECTED] wrote: Mike -- Thats a lot of metadata. Sounds like maybe the metadata is primary and the bytecode is secondary, in which case perhaps what you really want is a (metadata) tree decorated with bytecode rather than a (bytecode) array decorated with metadata. Fair enough. good point! Of course, the most natural candidate for the metadata would be the annotated (file line, etc.) parse tree, or some approximation to it after compilation-related transformations. OK that sounds fine. My current problems with the graphs of meta-data are the speed of loading. I would like to use something like what you are talking about with the mmap. Also, dot.net IL has tons of meta-data, very very much of it. I can imagine a process that loads the tree, and linearizes the bytecode with the metadata consisting of backpointers to nodes of the tree, either in band as escaped noop-equivalent bytecode or out of band in an offset-pointer table. Sure, a zippper (Reihverschluss ;) concept. With a suitable amount of forethought on the tree representation, you should be able to have good flexibility while still having enough standardization on how tree-emitting compilers represent typical debug-related metadata (file, line, etc.) that debuggers and other tools could be generic. OK. Well the current rdf format that I have is ok, so that brings me back to the idea of using rdf Redland supports a bdb, which also supports fast loading, but is not platform independant. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
Hey Gopal, Nice to meet you here ;) --- Gopal V [EMAIL PROTECTED] wrote: If memory serves me right, James Michael DuPont wrote: I just want to know how where we can put it. The Microsoft IL has a whole section on meta-data, AFAIK, that just holds the offset, line number and filename. IIRC the JVM had a LineNumberTable and VarNameTable for debugging which were declared as ``attributes'' to each method in the .class tree. I suppose VarNameTable is totally irrelevant for Parrot ... I dont know that, what is it? Variable name table? If so, i think it might be good for debugging. yes I agree, I just want to be able to reconstruct the tree for debugging or reverse engineering (if the compiler that produced the bytecode whats to produce this). Optimisations ? ... (bang, there goes the line numbers ;) If you want to debug, you dont want optimizations. When you run the debugger in the gcc, it produces a dwarf file, that is the type of meta-data i am talking about. Normally you dont need this information, I just want to know how I can store it if I *do* need it. The metadata from the c++ that i am extracting even exceeds the size of the sourcecode itself. yeah, that is the idea. Reflection and introspector require the meta-data, that can be read by special reflection operations. I think Parrot is going to *need* reflection operations :) ... You might be able to extract information like you do with C# , with reflection looping over the methods. You might want to run C# in parrot, then you need it. Btw, your RDF stuff wouldn't be what I call metadata :) .. it's data itself in a pre-processed format. Well read my first answer to the original meta-data post, with all the links. I think it is meta-data, all information about the bytecode that might be interesting to a person, to understand what a give bytecode is and means, it's context, meaning, usage, and all that. it is all meta-data. The bytecode is what is needed to run. IMCC can pick out the chunks of IMC, generate bytecode, .line 42 life.fubar Again, nice to meet you again Mr. Victory, Mike The first ten million years were the worst, said Marvin, and the second ten million years were the worst too. The third ten million I didn't enjoy at all. After that I went into a bit of a decline.. The best conversation I had was over forty million years ago, continued Marvin.And that was with a coffee machine. - Marvin complaining about being left alone for years. = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: XML output of parse tree for Jako
--- [EMAIL PROTECTED] wrote: I just committed some changes to the Jako compiler that add a '-x' switch. Using jakoc -x will cause the compiler to emit the parse tree as XML (via SAX events sent to XML::Handler::YAWriter). Sounds interesting. I have to look into this, i have dropped xml in favor of RDF, maybe we can find a common base. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [Introspector-developers] Re: Bytecode metadata
--- Juergen Boemmels [EMAIL PROTECTED] wrote: Nicholas Clark [EMAIL PROTECTED] writes: I guess in future once the normal JIT works, and we've got the pigs flying nicely then it would be possible to write a Not Just In Time compiler that saves out assembly code and relocation instructions. Bah. That's parrot -o foo.o foo.pmc isn't it? And if we make C a parrot supported language we can even build parrot with parrot? I was just thinking that myself. There are two issues here : 1. The gcc : I have %99 of the information about the function bodies of parrot c source code in rdf/xml. That could be fed to parrot. 2. The pnet/C : there has been work done by Rhys to make a managed c compiler for pnet. Gopal has been working on a parrot bytecode emitter for Pnet. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
--- chromatic [EMAIL PROTECTED] wrote: On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote: Since it looks like it's time to extend the packfile format and the in-memory bytecode layout, this would be the time to start discussing metadata. What sorts of metadata do people think are useful to have in either the packfile (on disk) or in the bytecode (in memory). Comments, if a disassembler is to be able to reconstruct the original source sufficiently well[1]. -- c 1) for the various values of well that include semantic equivalence Yes! Deparsing. that would be great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
--- Dave Mitchell [EMAIL PROTECTED] wrote: On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote: My current idea for the in memory format of the bytecode is this: I would strongly urge any file-based byte-code format to arranged in such a way that it (or most of it) can simply be mmap-ed in (RO), analogously to executables. This means that a Perl server that relies on a lot of modules, and which forks for each connection (imagine a Perl-based web server), doesn't consume acres of swap space just to have an in-memory image per Perl process, of all the modules. sounds good. could that be seen as similar to shared memory communication with the compile, via mem-mapped file interfaces? mike This is a real problem that's hitting me hard with Perl 5 in my day job. Dave. -- Any [programming] language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. - Larry Wall = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Bytecode metadata
--- Juergen Boemmels [EMAIL PROTECTED] wrote:
Hello,
after quite a long time away from keyboard and fighting through a
huge
backlog of mail I'm (hopefully) back again.
Dan Sugalski [EMAIL PROTECTED] writes:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start
discussing
metadata. What sorts of metadata do people think are useful to have
in
either the packfile (on disk) or in the bytecode (in memory).
My current idea for the in memory format of the bytecode is this:
One bytecodesegment is a PMC consisting of three parts the actual
bytecode (a flat array of opcode_t), the associated constants, which
don't fit into an opcode_t (floats and strings), and a scratch area
for the JITed code. All other Metadata will be attached as
properties (or maybe as elements of an aggregate). This will be an
easy way for future extension. The invoke call to this pmc would
simply start the bytecode from the first instruction.
To support inter-segment jumps a kind of symboltable is also
neccessary. All externally reachable codepoints need some special
markup. This could be a special opcode extlabel_sc or an entry in a
symboltable. Also needed is a fixup of the outgoing calls, either via
modification of the bytecode or via a jumptable. Both have their pros
and cons: The bytecode modifcation prohibits a readonly mmap of the
data on disk and the fixup needs to be done at load-time but once
this
is done the impact on the runtimespeed is minimal, whereas the
jumpcode is on extra indirection. But as stated somewere else the
typical inter-segment jump will be call/tailcall/callmethod/invoke,
which are at least two indirections.
The on disk version is a matter of serializing and deserializing this
PMC.
Keep in mind that parrot may be in the position where it has to
ignore
or mistrust the metadata, so be really cautious with things you
propose as required.
Ok to summarize:
ByteCodeSegment = {
bytecode = requiered;
constants = only neccessary if string or num constants;
fixup = (or jumptable) only neccessary if outgoing jumps;
symbols = all possible incomming branchpoints, optional;
JIT = will be filled when bytecode is invoked;
source= surely optional;
debuginfo = also optional;
...
}
I LIKE IT.
Bytecodes have a type? each bytecode has meta-data?
Here are the metadata I have collected from the parrot source code so
far. It should be a set of predicates to define all the other meta-data
needed.
First, this is the core meta-data for storing perl code :
in order of simplicity
identifier_node
Name of things
boolean_type,integer_type,real_type
types of things that are simple
all *_decls have a type that is a type_*
all *_decls have a name that is a type_decl or identifier_node
const_decl
Constant values
var_decl
variable values
The rest of the more complex types need a tree_list
tree_list
function_decl,
parm_decl # list of
array_type
integer_cst, # list of
enumeral_type
integer_cst # list of
record_type,union_type,
field_decl # list of
# a void is very special
void_type
The following are derived types :
pointer_type,reference_type
# function types allow for linkage
function_type,
type_* # we have a list of
# here the user defines its own
type_decl
# this is a commonly defined user type
complex_type,
=
James Michael DuPont
http://introspector.sourceforge.net/
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
RE: Bytecode metadata
--- Brent Dax [EMAIL PROTECTED] wrote:
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# Dan Sugalski:
# # Since it looks like it's time to extend the packfile
# format and the #
# in-memory bytecode layout, this would be the time to start
# discussing #
# metadata. What sorts of metadata do people think are useful
# to have #
# in either the packfile (on disk) or in the bytecode (in memory).
#
# I do think that, whatever native (i.e. understood by
# Parrot) metadata
# we support, we *must* allow for extensibility, both for
# future native
# metadata and for third-party tools.
#
# Must is an awfully strong word, there. We don't really must do
# anything, though I do realize the feature is useful, hence my
# question.
A strong word for a strong opinion. :^) Besides, I did qualify it
with
an I do think, which is another way to say IMO.
# Moreover, this must not be
# implemented with a special type of metadata block, or by using
# sequentially-increasing numbers. (The first means that any
# metadata we
# decide to add in the future will be slower than the metadata we
add
# now; the second has problems with several third-party tools
# picking the
# same
# number.)
#
# I'm afraid extensible metadata is going to live in its own chunk
# unless someone can come up with a way to embed it without penalty.
# (And I'm generally considering using separate chunks for the
metadata
# the engine does understand)
Are you expecting to have chunk type determined by order? If so,
what
will you do if a future restructuring means you either don't need
chunk
type X or you need a new, highly incompatible version? Will you
leave
in an empty ghost chunk?
I would suggest (roughly) the following format for a chunk:
TYPE: One 32-bit number
VERSION: One 32-bit number; suggested usage is as four eight-bit
components
SIZE: One 32-bit number of bytes (or maybe 64-bit)
DATA: arbitrary length
For C-heads, think of it like this:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
Type IDs less than 256 would be reserved to Parrot (so we have plenty
of
room for future expansion); all third-party tools would use some sort
of
cryptographic checksum of the tool's name and the data structure's
name,
making sure (of course) that their type ID was greater than 255.
If there's a directory of some sort, it should record the type ID and
the offset to the beginning of the chunk. This should allow for a
fairly quick lookup by type. If you think that there might be a
demand
for multiple instances of the same type of metadata, you may want to
add
a chunk ID of some sort.
Cool!
that means we can use opcodes to store the introspector data!
We need to have the meta data paired with the opcodes.
basically this means storing the source code in some ast form in the
meta-data for full reflection and introspection on the expression
level.
mike
=
James Michael DuPont
http://introspector.sourceforge.net/
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Bytecode metadata
--- Dan Sugalski [EMAIL PROTECTED] wrote: Since it looks like it's time to extend the packfile format and the in-memory bytecode layout, this would be the time to start discussing metadata. What sorts of metadata do people think are useful to have in either the packfile (on disk) or in the bytecode (in memory). Keep in mind that parrot may be in the position where it has to ignore or mistrust the metadata, so be really cautious with things you propose as required. Dear Dan, I would like to see a powerful meta-data system made possible, even if it is not implemented immediatly. The symantic web researchers like David Beckett and Tim Bernard-Lee have been working on powerfull systems to support meta-data in general, maybe as the parrot meta-data is just getting started, we can cut a bit of that off? Take a look at the list here at Diffuse MetaData Interchange [4] at the bottom of this mail, you will see an overview of metadata systems. Even if they are not specific to parrot, the goals are similar in many casess. Recently I have been making progress with the rdf[1], specifically with the redland application framework[2]. With the simple concept of triples of data, a triple being (subject, predicate, object) we are able to capture the metadata of the gcc compiler, and I hope other compilers and systems. Redland is written in clean c, and supports meta-data storage in memory, and on disk in multiple formats, in rdf/xml, rdf/ntriples (even in berkleydb). It would be possible to create a new storage model to store the a packfile as well. The subjects are the items in the program, the node, each getting a number inside the system. Predicates are important, the represent the meat of the system. The objects are either literal data or other subjects. Via the redland api, you can add in new statements about things, and find all the statements about a subject, about an object, all that meet a predicate. I tell you this, because maybe you want to provide this sort of flexible meta-data api into parrot : for example the predicates that we extract that you might find interesting : * Filename of the node * Line number of the node (the Column Number is not supported yet) * Internal Type of the node (variable declaration, type, integer const, etc), as opposed to the type of the * Name of the node (the identifier) * Type of the node (if it is a variable, or constant) this is a pointer to another node * Unsigned Type of a type, if a type supports itself being unsigned, here it is. * Comments are supported, but not used yet, but would be a good idea. Now we get into more specific types of predicates * Parameters of an expression * Variables in a block * Size of a variable * Alignment of a variable * Constant flag * Volitile flag then we have * Fields of a struct * Parameters of a function * Return type of a function * Body block of a function So, with this idea of meta-data, by adding more predicates, you can support the capturing and storage of all the source code in an abstract form, or just the basic function data. You will probably think that this is overkill for parrot, but I think that it would give you an extensible system to add in new forms of meta-data as langauges are added. Via OWL[3] the users will be able to define the meaning and the classes of metadata as well. mike [1] RDF http://www.w3.org/RDF/ [2] Redland http://www.redland.opensource.ac.uk/ [3] OWL http://www.w3.org/TR/owl-absyn/ [4] Diffuse MetaData Interchange standards http://www.diffuse.org/meta.html = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Introspector rdf/ntriples results for packdump.c
Dear all, you will find an example of the gcc-introspector output applied to parrot here : http://introspector.sourceforge.net/2003/01/19/parrot-packdump/ Here you find the globals for parrot 450k http://introspector.sourceforge.net/2003/01/19/parrot-packdump/_global__.tu_.ntriples.gz The sources are from here : http://introspector.sourceforge.net/2003/01/19/parrot-packdump/packdump.i.gz you will find a debian source package here http://introspector.sourceforge.net/debian/incoming/parrot-packdump_1.17.orig.tar.gz, that contains all the files created. even if the file is created from packdump, the compiler includes all the global datatypes into the dump. the ntriples are easy to read, and can even be used via grep. $ grep \#strg _global__.tu_.ntriples | cut -d\ -f2 | sort -u | grep Parrot -- ParrotIO ParrotIOBuf ParrotIOData ParrotIOFilter ParrotIOLayer ParrotIOLayerAPI ParrotIOTable Parrot_CharType_Transcoder Parrot_Context Parrot_Continuation Parrot_Coroutine Parrot_Float Parrot_Float4 Parrot_Float8 Parrot_Int Parrot_Int2 Parrot_Int4 Parrot_Interp Parrot_Interp_flag Parrot_Lexicals Parrot_Opcode Parrot_PackFile Parrot_Pointer Parrot_Sub Parrot_Sync Parrot_UInt Parrot_UInt2 Parrot_UInt4 Parrot_allocate Parrot_allocate_string Parrot_allocate_zeroed Parrot_base_classname_hash Parrot_base_vtables Parrot_chartype_lookup Parrot_clear_i Parrot_clear_n Parrot_clear_p Parrot_clear_s Parrot_destroy Parrot_destroy_header_pools Parrot_destroy_memory_pools Parrot_dlclose Parrot_dlerror Parrot_dlopen Parrot_dlsym Parrot_do_dod_run Parrot_encoding_lookup Parrot_exception Parrot_exit Parrot_floatval_time Parrot_get_datatype_enum Parrot_get_datatype_name Parrot_go_collect Parrot_init Parrot_initialize_header_pools Parrot_initialize_memory_pools Parrot_intval_time Parrot_jump_buff Parrot_on_exit Parrot_pop_i Parrot_pop_n Parrot_pop_off_stack Parrot_pop_p Parrot_pop_s Parrot_psprintf Parrot_push_i Parrot_push_n Parrot_push_on_stack Parrot_push_p Parrot_push_s Parrot_reallocate Parrot_reallocate_string Parrot_setenv Parrot_sleep Parrot_snprintf Parrot_sprintf Parrot_sprintf_c Parrot_sprintf_s Parrot_string_cstring Parrot_vsnprintf Parrot_vsprintf Parrot_vsprintf_c Parrot_vsprintf_s Parrot_warn Parrot_warn_s _ParrotIO _ParrotIOBuf _ParrotIOData _ParrotIOFilter _ParrotIOLayer _ParrotIOLayerAPI Also if you are interested, you will find dumps of the data structures of other modules : ildasm :http://introspector.sourceforge.net/2003/01/19/pnet-ildasm/ m4 :http://introspector.sourceforge.net/2003/01/20/m4-builtin/ gcc:http://introspector.sourceforge.net/2003/01/19/cppdefault.i/ raptor :http://introspector.sourceforge.net/2003/01/19/raptor-parse/ = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
APIS and metadata
Dear list, Please excuse my ignorance, and if the answer is just RTFM, then please shoot me. What is the plan for declaring Object Oriented APIs in parrot. In dotnet il, you have a OO concept built into the assembly, but parrot seems to be missing this. Is there a plan for supporting the high level definition of an abstract oo api that all parrot languages can use? Is there a way to wrap a c api in parrot and provide hints to the languages how to marschall the data. Have you considered porting the IL meta-data system on top of parrot? mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: pretty pictures
cool! i will try that out. mike --- Bart Schuller [EMAIL PROTECTED] wrote: On Thu, Jan 16, 2003 at 10:46:21AM -0800, Marc M. Adkins wrote: I have a Perl program that processes Perl source and generates fake C++ headers that doxygen will process. Doxygen doesn't have a hook for adding a I've done the same thing, you can get it or see the output here: http://smop.org/ -- Bart. = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: pretty pictures
--- Mitchell N Charity [EMAIL PROTECTED] wrote: Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. You might be interested in autodia, it handles perl. http://droogs.org/autodia/ (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) The goal of the introspector is to publish a RDF/XML ontology of the various systems and thier dumps. Then you can merge the ontologies on a logical level and transform them between each other. Well what exactly do you need? I will be looking in running the introspector over the parrot code. That will produce a rdf file of the entire parrot source code. I would like to also figure out how to extract the high-level infomration from perl. The next step for the introspector was B::ToXML and to get that running. But for Perl6, i wonder what that best way to get at the data? The assembler does not contain any high level information. GraphVis (www.graphviz.org) did the actual drawing. Yes, that is on major goal of the introspector project to replace this funky non-free graphvis with the VCG. I hope to port VCG to GTK this year, and integrate it with DIA for a nice graph editor. http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html Hmm. Maybe a picture of the complete include graph would be useful introductory material... the graphs you doxygen produces are great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: The draft todo/worklist
--- Dan Sugalski [EMAIL PROTECTED] wrote: *) Fixed disassembler I will volunteer to take over on this and get it working if no one has time for it. *) Working make install see next note : *) Support for cross compilation i think that it is important that we really come to terms with the new configure tool. To be honest, i like the idea of using a perl based configurator, and my research into autoconf and automake might feed into this. How far do you plan on stepping on autoconfs toes with this? Do you want to continue with a special solution, or does not it make sense to turn around and go back to automake and autoconf? mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: The draft todo/worklist
--- Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Jan 13, 2003 at 06:12:59AM -0800, James Michael DuPont wrote: *) Support for cross compilation i think that it is important that we really come to terms with the new configure tool. To be honest, i like the idea of using a perl based configurator, and my research into autoconf and automake might feed into this. How far do you plan on stepping on autoconfs toes with this? Do you want to continue with a special solution, or does not it make sense to turn around and go back to automake and autoconf? Well, http://www.gnu.org/software/autoconf/autoconf.html says: Autoconf is an extensible package of m4 macros that produce shell scripts ... These scripts can adapt the packages to many kinds of UNIX-like systems well, the m4 is not needed to run the configure. Automake says (http://www.gnu.org/software/automake/automake.html): Automake requires the use of GNU Autoconf. automake is written in perl which implies that autoconf needs a shell to run the configure system it generates. That's not going to work for Win32 yes, unless you translate that shell into perl for execution. (Not that I use Win32 personally, but I like things to work on Win32 because then no-one complains that things don't work, and so I can pretend it doesn't exist. I'm speaking personally here - other people working on parrot probably have much less selfish views on Win32) I aggree that win32 is important, but as perl is ported, m4 and shell have also been ported. (if you look at mingw32-sys and cygwin you will see that) Again, i like the new configure script, but it will need expansion to handle more responsabilites. I dont like the configure scripts, but they work, and many people support them, not the question is, do you want to beef put the new system to handle cross compiling and other configure responsabilities? Do you want to make a replacement for autoconf in general? I have been looking into bashdb, it supports the debugging of bash scripts. It is an idea to translate the configure scripts via bashdb into perl and to use that to create new features for the perl configure scripts. Also, the m4 macros can themself be modified directly into perl because they are used to generate the configuration tests. but this all needs lot of work and will take months to do, the question is how far are we with configure and how happy are you with it? mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: The draft todo/worklist
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 6:12 AM -0800 1/13/03, James Michael DuPont wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: *) Fixed disassembler I will volunteer to take over on this and get it working if no one has time for it. I had a fix for it in my inbox, so I applied it and this is no longer an issue. :) cool! *) Working make install see next note : *) Support for cross compilation i think that it is important that we really come to terms with the new configure tool. To be honest, i like the idea of using a perl based configurator, and my research into autoconf and automake might feed into this. How far do you plan on stepping on autoconfs toes with this? I don't plan on stepping on autoconf's toes only because I don't plan on paying much attention to it. We can't rely on it since our cross-platform needs are past what it can deliver, unfortunately. Ok, well, I would like to review how it is possible to transfer some more logic from autoconf into Configure.pl, specifically the --host and --target options. I *do* like the idea of using perl instead of shell for running the configure scripts, just would like to get a handle on how to port more over. The debugging of shell scripts is one thing that should be put to an end. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [perl #19874] Patch for pdump
--- Leopold Toetsch [EMAIL PROTECTED] wrote: James Michael DuPont (via RT) wrote: --- packdump.c 2 Nov 2002 14:57:47 - 1.6 +++ packdump.c 4 Jan 2003 16:18:37 - +#ifdef HAS_parrot_string_t_flags This is already fixed. thanks, I have not tested it again, but also did not hear anything. I will retest from cvs. sorry for a double report. you did see that the c version of packdump just errors out when started? mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
perl6 testing on mingw32
first of all : to run this, it needs a -I. second of all, the test has errors the Perl6grammar.pm did not return a true value at (eval 58) line 3. can be ignored, because via some magic, it is regenerated. I get the following error WHOA! Somehow you got a different number of results than tests ran! This should never happen! Please contact the author immediately! END failed--call queue aborted. test results : --- mdupont@PI /cygdrive/c/development/testing/parrot/parrot/languages/perl6 $ perl -I. ./perl6 --test Perl6grammar.pm did not return a true value at (eval 58) line 3. Test details: t/builtins/array.t2/3 t/builtins/string.t...4/4 t/compiler/1.t..14/14 t/compiler/2.t5/5 t/compiler/3.t7/7 t/compiler/4.t3/3 t/compiler/5.t5/5 t/compiler/6.t6/6 t/compiler/7.t1/1 t/compiler/8.t6/6 t/compiler/9.t4/4 t/compiler/a.t3/3 t/compiler/b.t6/6 t/compiler/c.t6/6 t/compiler/qsort.t1/1 t/rx/basic.t..6/6 t/rx/call.t...2/2 t/rx/special.t2/2 Test summary: t/builtins/array.tesok, 2/3 skipped: various reasons t/builtins/string.tesok t/compiler/1.tesok t/compiler/2.tesok t/compiler/3.tesok t/compiler/4.tesok t/compiler/5.tesok t/compiler/6.tesok t/compiler/7.tesok t/compiler/8.tesok t/compiler/9.tesok t/compiler/a.tesok t/compiler/b.tesok t/compiler/c.tesok t/compiler/qsort.tesok t/rx/basic.tes..ok t/rx/call.tes...ok t/rx/special.tesok All tests successful, 2 subtests skipped. Files=18, Tests=84, 3 wallclock secs ( 0.79 cusr + 1.03 csys = 1.82 CPU) WHOA! Somehow you got a different number of results than tests ran! This should never happen! Please contact the author immediately! END failed--call queue aborted. = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Question about the disassembler
Dear fellow hackers, the C disassembler is crashing : mdupont@introspector:~/development/parrot/parrot$ ./disassemble t/pmc/sub_1.pbc disassemble: debug.c:1055: PDB_disassemble_op: Assertion `size + 20 space' failed. Aborted And the perl dissambler works ! I have been looking into and it seems that the parrot contains very little meta-data compared to IL/DOTGNU the table at the top of the program contains many strings, pmc_* and sometimes other slots. But i wonder if you will try and represent OO classes like IL does with the IL .class attribute? best regards, mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Introduction and cygwin results
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
Can someone tell me if anyone uses packdump from cvs? is that an
equivalent to ildasm in dotnet? It seems to be broken.
Can I dump an set of instructions from a program into a file, and
reassemble them?
If not, is there a way to dump a parrot program?
Not that I know of, I think so, damn, you should be able to, and no
no other way.
Here is my patch for pdump :
But the pdump does not disassemble... i have to look into
dissassemble.pl
Index: packdump.c
===
RCS file: /cvs/public/parrot/packdump.c,v
retrieving revision 1.6
diff -u -r1.6 packdump.c
--- packdump.c 2 Nov 2002 14:57:47 - 1.6
+++ packdump.c 4 Jan 2003 16:18:37 -
@@ -107,8 +107,13 @@
case PFC_STRING:
PIO_printf(interpreter, [ 'PFC_STRING', {\n);
-PIO_printf(interpreter, FLAGS= 0x%04lx,\n,
+
+#ifdef HAS_parrot_string_t_flags
+
+PIO_printf(interpreter, FLAGS=
0x%04lx,\n,
(long)self-string-flags);
+#endif
+
PIO_printf(interpreter, ENCODING = %s,\n,
self-string-encoding-name);
PIO_printf(interpreter, TYPE = %s,\n,
Anyone working on cross compiling? I have a setup here for cross
compiling from debian to windows, but always use autoconf to do that.
Anyone have an idea?
Is there a way to capture the line number, and comments of a perl6
program in parrot? What about high level type information?
Line number, yes. Comments, probably not, though it's possible that
info can get embedded. What type of high-level info are you looking
for? We've all sorts. :)
well as much as you can give me.
Seriously, if you're looking for variable
type info, it'll potentially be there, assuming that it's not been
stripped out.
OK, that is good.
I would be willing to port my code to the subset of perl/parrot that
is
currently supported, where I can i find that?
Perl 6 is in languages/perl6, though I think that there's still some
stuff missing.
Well, I will try that out. Thanks,
mike
=
James Michael DuPont
http://introspector.sourceforge.net/
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Introduction and cygwin results
Hi There! My name is Mike, and I have decided to pick up on the parrot again. You seem to be making good progress, let me help you test this thing and build some interfaces to other programs. Can someone tell me if anyone uses packdump from cvs? is that an equivalent to ildasm in dotnet? It seems to be broken. Can I dump an set of instructions from a program into a file, and reassemble them? If not, is there a way to dump a parrot program? Is there a way to capture the line number, and comments of a perl6 program in parrot? What about high level type information? I am interested in building a interface from parrot into the introspector, that will give you a way to convert your programs internals into RDF/XML and visualize and manipulate them via the GUI. I am using the redland perl api, and would like to link that into parrot. We are freezing the gcc interface soon, and because the introspector is mostly writtten in perl, I think that parrot would be the next step. I would be willing to port my code to the subset of perl/parrot that is currently supported, where I can i find that? Here is my first test results with parrot under cygwin : [SECTION GCC -V] compiler version [SECTION MAKE TEST] results of maketest [SECTION PACKDUMP] compiling error in packdump running examples : [SECTION MOPS] [SECTION LIFE] Mike [SECTION GCC -v] gcc -v : Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable languages=c,c++,f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) [SECTION MAKE TEST] perl t/harness --gc-debug --running-make-test t/src/basic.ok t/src/exit..ok t/src/intlist...ok t/src/list..ok t/src/manifest..ok t/src/sprintf...ok t/op/basic..ok t/op/bitwiseok t/op/comp...ok t/op/conv...ok t/op/debuginfo..ok t/op/gc.ok t/op/globalsok t/op/hacks..ok t/op/ifunless...ok t/op/jitok t/op/jitn...ok t/op/lexicals...ok t/op/macro..ok, 1/15 skipped: Await exceptions t/op/number.ok t/op/rx.ok, 1/23 skipped: Pending some sort of lowercasing op t/op/stacks.ok, 1/35 skipped: Await exceptions t/op/string.ok t/op/time...ok t/op/trans..ok t/op/types..ok t/pmc/array.ok t/pmc/boolean...ok t/pmc/intlist...ok t/pmc/multiarrayok t/pmc/nci...ok, 11/11 skipped: needs jit/i386 and libnci.so t/pmc/perlarray.ok t/pmc/perlhash..ok t/pmc/perlint...ok, 1/5 skipped: add_keyed: not yet t/pmc/perlstringok, 1/8 skipped: Pending new version of concat_p_p_s t/pmc/pmc...ok 31/80# Failed test (t/pmc/pmc.t at line 491) # got: '2.70 # ' # expected: 'bar2.70 # ' t/pmc/pmc...ok 79/80# Looks like you failed 1 tests of 80. t/pmc/pmc...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 32 Failed 1/80 tests, 98.75% okay (-2 skipped tests: 77 okay, 96.25%) t/pmc/prop..ok t/pmc/scratchpadok t/pmc/sub...ok Failed Test Status Wstat Total Fail Failed List of Failed --- t/pmc/pmc.t1 256801 1.25% 32 18 subtests skipped. Failed 1/42 test scripts, 97.62% okay. 1/584 subtests failed, 99.83% okay. make: *** [test_dummy] Error 2 [SECTION PACKDUMP] make packdump.exe packdump.c: In function `PackFile_Constant_dump': packdump.c:111: structure has no member named `flags' make: *** [packdump.o] Error 1 I have commented that out for now : /*PIO_printf(interpreter, FLAGS= 0x%04lx,\n, (long)self-string-flags); */ [SECTION MOPS] $ ./examples/mops/mops.exe Iterations:1 Estimated ops: 2 Elapsed time: 0.784000 M op/s:255.102028 [SECTION LIFE] $ examples/assembly/life.exe .. 5000 generations in 6.707000 seconds. 745.489785 generations/sec A total of 460064 bytes were allocated A total of 14 DOD runs were made A total of 93 collection runs were made Copying a total of 13534560 bytes There are 471 active Buffer structs There are 6400 total Buffer structs = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Introduction and cygwin results
--- James Michael DuPont [EMAIL PROTECTED] wrote: Hi There! [SECTION PACKDUMP] make packdump.exe packdump.c: In function `PackFile_Constant_dump': packdump.c:111: structure has no member named `flags' make: *** [packdump.o] Error 1 I have commented that out for now : /*PIO_printf(interpreter, FLAGS= 0x%04lx,\n, (long)self-string-flags); */ Oopps : more then that : pdump.c: In function `main': pdump.c:21: storage size of `file_stat' isn't known pdump.c:37: `O_RDONLY' undeclared (first use in this function) pdump.c:37: (Each undeclared identifier is reported only once pdump.c:37: for each function it appears in.) under cygwin you need : #include fcntl.h mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Copyright notices and license stuff
Dan Wrote, This came up a while back in regards to GCC. Someone was working on a front (or back, I don't recall) end to gcc to dump out the internal representation of source as XML for some damn thing or other. I am working on something like that, there are 2-3 other similar projects. I am using the front end tree structures of the gcc to extract information about software into a new visualization and reverse engineering tool. This was essentially stopped (don't recall whether it was stopped outright, or GPL was put on the generated rep, which is close enough to stopping for most folks) by the GCC folks as they claimed, quite rightly, that the internal representation was a derived work of their code as well as the original source, and as such they could put their license on it too. I had stopped distribution for a while on my own accord. It was not stopped by the gcc. I had stopped for a while, out of respect of the wishes of the gcc group and rms. It now turns out that they are doing the same themselves. There is not any real policy or consistency in the actions of the gcc and fsf group, therefore I will hold back any longer. The gcc interface project has been offically restarted. http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html quite rightly, that the internal representation was a derived work of their code as well as the original source, and as such they could put their license on it too. This is not correct, there is no way to enforce that via the GPL, which is based on copyright. Look at the dumping of the ASTS into GraphViz Format. The only arguments which are pretty weak where that the data structures are copyrighted, but there is no real case for it. Just lots and lots of FUD from the gcc developers. This doesn't apply to object files that gcc generates as there's explicit disclaiming of ownership on them in gcc's license, as there is with pretty much all compilers. This does not apply to any of the input or output files of a GPled software, only the creative work of a person can be copyrighted. Mechanical translations are just derived works. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
