introspector-developers — for anyone interested in hacking the introspector

[Introspector-developers] Re: call for alpha testers EulerSharp for dotgnu/pnet

[Jos D. <jos...@ag...>]

oops... I meant
the n3 parser can't live with*out* the engine

-- ,
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/


                                                                                                                   
                    Jos De_Roo                                                                                     
                                         To:     James Michael DuPont <mdu...@ya...>@AGFASMTP              
                    2003-02-09           cc:     dev...@do..., introspectors                              
                    02:25 PM             <int...@li...>, Jos                      
                                         De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER@AGFA, mi...@ca...,          
                                         www...@w3..., www...@w3...                  
                                         Subject:     Re: call for alpha testers EulerSharp for dotgnu/pnet        
                                         (Document link: Jos De_Roo)                                               
                                                                                                                   



> > > Thanks,
> >
> > you're welcome Mike
> >
> > > maybe we can find a savannah page for this?  We need a cvs.
> > > Otherwise we can host it under one other project.
> >
> > dunno what a savannah page is, but don't mind
> > I think it's up to you here to come up with
> > a good proposal ;-)
>
> Savannah.gnu.org is a project hosting system,
> the best thing woul be for you to register with them, and request a
> hosting space for the project. If you would like, I can handle this for
> you.

DanBri, what do you think?
I mean where to put EulerSharp
there is also dev.w3.org and I've
put a W3C Software Short Notice
in our current distribution

> >
> > > I would like to use this to process the RDF from the gcc, inside
> > the
> > > gcc,
> >
> > sounds good!
> > thoughts about other testcases?
> yes, I still need to test! I have not tried all the tests, but
> I will setup a makefile and test driver.

great, I look forward to the results!
our current Euler.cs runs on
the 1.1 beta .NET Framework redistributable dor win2k
and runs all the tests in http://www.agfa.com/w3c/euler/etc
but for the RDF parsing we use AskJena.cs which
is an http bridge to Jena which is running on a java VM
also, I think that compatibility with
http://www.ecma.ch/publications/standards/ECMA-334.HTM
http://www.ecma.ch/publications/standards/ECMA-335.HTM
is what really matters

> > (preferably using proofs)
>
> This is what i need to learn more about, to be honest, I dont fully
> grok the CWM/Euler software, I just know it is what i need.

;-)

> > >  For embedding the Euler into the GCC, i need only GPL modules.
> > > I would like to re-licensed Euler under the GPL, is that possible?
> >
> > what really matters to me is "W3C SOFTWARE NOTICE AND LICENSE"
> > --
> > http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
> > and therefore I would like to follow that one
> > in there I read that it
> > [[
> > is written so as to preserve the Free Software Foundation's
> > assessment of GPL compatibility and OSI's certification under
> > the Open Source Definition.
> > ]]
>
> Great, that means that I dont have to relicense it.
> Lets leave that along for now, until we have cross that bridge.
>
> But the n3 parser for example, that would be good as part of the
> dotgnu.rdf native implementation. I dont know if we can include w3c
> licensed code as part of the dotgnu project. Can you give me permission
> to dual license it? Disjunct under the GPL and under the w3c?
> :)

the n3 parser can't live with the engine
the n3 parser is a real quick hack and DanC
had the good idea to put it in a separate file
but it really needs Euler.cs everywhere

> >
> >
> > > BTW:
> > > I have just commited the updated dotgnu RDF stuff
> > > you can find it here:
> > > CVS: cvs -z3
> > > -d:pserver:an...@su...:/cvsroot/dotgnu-libs co
> > > dotgnu.rdf
> > >
> > > and I made a source deb :
> > >
> >
>
http://introspector.sourceforge.net/debian/incoming/dotgnu.rdf_0.2-1.tar.gz
> > >
> > > you can find the dotgnu stuff at www.dotgnu.org, I suggest using
> > the
> > > cvs.
> >
> > will definitely do that asap!
>
> That rdflib is not running yet, it is just a stubbed interface.
> The n3 parsed
>
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/

-- ,
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

[Introspector-developers] Re: call for alpha testers EulerSharp for dotgnu/pnet

[Jos D. <jos...@ag...>]

> > > Thanks,
> >
> > you're welcome Mike
> >
> > > maybe we can find a savannah page for this?  We need a cvs.
> > > Otherwise we can host it under one other project.
> >
> > dunno what a savannah page is, but don't mind
> > I think it's up to you here to come up with
> > a good proposal ;-)
>
> Savannah.gnu.org is a project hosting system,
> the best thing woul be for you to register with them, and request a
> hosting space for the project. If you would like, I can handle this for
> you.

DanBri, what do you think?
I mean where to put EulerSharp
there is also dev.w3.org and I've
put a W3C Software Short Notice
in our current distribution

> >
> > > I would like to use this to process the RDF from the gcc, inside
> > the
> > > gcc,
> >
> > sounds good!
> > thoughts about other testcases?
> yes, I still need to test! I have not tried all the tests, but
> I will setup a makefile and test driver.

great, I look forward to the results!
our current Euler.cs runs on
the 1.1 beta .NET Framework redistributable dor win2k
and runs all the tests in http://www.agfa.com/w3c/euler/etc
but for the RDF parsing we use AskJena.cs which
is an http bridge to Jena which is running on a java VM
also, I think that compatibility with
http://www.ecma.ch/publications/standards/ECMA-334.HTM
http://www.ecma.ch/publications/standards/ECMA-335.HTM
is what really matters

> > (preferably using proofs)
>
> This is what i need to learn more about, to be honest, I dont fully
> grok the CWM/Euler software, I just know it is what i need.

;-)

> > >  For embedding the Euler into the GCC, i need only GPL modules.
> > > I would like to re-licensed Euler under the GPL, is that possible?
> >
> > what really matters to me is "W3C SOFTWARE NOTICE AND LICENSE"
> > --
> > http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
> > and therefore I would like to follow that one
> > in there I read that it
> > [[
> > is written so as to preserve the Free Software Foundation's
> > assessment of GPL compatibility and OSI's certification under
> > the Open Source Definition.
> > ]]
>
> Great, that means that I dont have to relicense it.
> Lets leave that along for now, until we have cross that bridge.
>
> But the n3 parser for example, that would be good as part of the
> dotgnu.rdf native implementation. I dont know if we can include w3c
> licensed code as part of the dotgnu project. Can you give me permission
> to dual license it? Disjunct under the GPL and under the w3c?
> :)

the n3 parser can't live with the engine
the n3 parser is a real quick hack and DanC
had the good idea to put it in a separate file
but it really needs Euler.cs everywhere

> >
> >
> > > BTW:
> > > I have just commited the updated dotgnu RDF stuff
> > > you can find it here:
> > > CVS: cvs -z3
> > > -d:pserver:an...@su...:/cvsroot/dotgnu-libs co
> > > dotgnu.rdf
> > >
> > > and I made a source deb :
> > >
> >
>
http://introspector.sourceforge.net/debian/incoming/dotgnu.rdf_0.2-1.tar.gz
> > >
> > > you can find the dotgnu stuff at www.dotgnu.org, I suggest using
> > the
> > > cvs.
> >
> > will definitely do that asap!
>
> That rdflib is not running yet, it is just a stubbed interface.
> The n3 parsed
>
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/

-- ,
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

[Introspector-developers] Re: call for alpha testers EulerSharp for dotgnu/pnet

[James M. D. <mdu...@ya...>]

--- Jos De_Roo <jos...@ag...> wrote:
> 
> 
> > Thanks,
> 
> you're welcome Mike
> 
> > maybe we can find a savannah page for this?  We need a cvs.
> > Otherwise we can host it under one other project.
> 
> dunno what a savannah page is, but don't mind
> I think it's up to you here to come up with
> a good proposal ;-)

Savannah.gnu.org is a project hosting system, 
the best thing woul be for you to register with them, and request a
hosting space for the project. If you would like, I can handle this for
you. 

> 
> > I would like to use this to process the RDF from the gcc, inside
> the
> > gcc,
> 
> sounds good!
> thoughts about other testcases?
yes, I still need to test! I have not tried all the tests, but 
I will setup a makefile and test driver.

> (preferably using proofs)

This is what i need to learn more about, to be honest, I dont fully
grok the CWM/Euler software, I just know it is what i need.

> >  For embedding the Euler into the GCC, i need only GPL modules.
> > I would like to re-licensed Euler under the GPL, is that possible?
> 
> what really matters to me is "W3C SOFTWARE NOTICE AND LICENSE"
> --
> http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
> and therefore I would like to follow that one
> in there I read that it
> [[
> is written so as to preserve the Free Software Foundation's
> assessment of GPL compatibility and OSI's certification under
> the Open Source Definition.
> ]]

Great, that means that I dont have to relicense it.
Lets leave that along for now, until we have cross that bridge.

But the n3 parser for example, that would be good as part of the 
dotgnu.rdf native implementation. I dont know if we can include w3c
licensed code as part of the dotgnu project. Can you give me permission
to dual license it? Disjunct under the GPL and under the w3c?
:)

> 
> 
> > BTW:
> > I have just commited the updated dotgnu RDF stuff
> > you can find it here:
> > CVS: cvs -z3
> > -d:pserver:an...@su...:/cvsroot/dotgnu-libs co
> > dotgnu.rdf
> >
> > and I made a source deb :
> >
>
http://introspector.sourceforge.net/debian/incoming/dotgnu.rdf_0.2-1.tar.gz
> >
> > you can find the dotgnu stuff at www.dotgnu.org, I suggest using
> the
> > cvs.
> 
> will definitely do that asap!

That rdflib is not running yet, it is just a stubbed interface. 
The n3 parsed 

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Re: call for alpha testers EulerSharp for dotgnu/pnet

[Jos D. <jos...@ag...>]

> Thanks,

you're welcome Mike

> maybe we can find a savannah page for this?  We need a cvs.
> Otherwise we can host it under one other project.

dunno what a savannah page is, but don't mind
I think it's up to you here to come up with
a good proposal ;-)

> I would like to use this to process the RDF from the gcc, inside the
> gcc,

sounds good!
thoughts about other testcases?
(preferably using proofs)


>  For embedding the Euler into the GCC, i need only GPL modules.
> I would like to re-licensed Euler under the GPL, is that possible?

what really matters to me is "W3C SOFTWARE NOTICE AND LICENSE"
-- http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
and therefore I would like to follow that one
in there I read that it
[[
is written so as to preserve the Free Software Foundation's
assessment of GPL compatibility and OSI's certification under
the Open Source Definition.
]]


> BTW:
> I have just commited the updated dotgnu RDF stuff
> you can find it here:
> CVS: cvs -z3
> -d:pserver:an...@su...:/cvsroot/dotgnu-libs co
> dotgnu.rdf
>
> and I made a source deb :
>
http://introspector.sourceforge.net/debian/incoming/dotgnu.rdf_0.2-1.tar.gz
>
> you can find the dotgnu stuff at www.dotgnu.org, I suggest using the
> cvs.

will definitely do that asap!


have a nice weekend


-- ,
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

[Introspector-developers] cwm and the introspector

[<mdu...@ya...>]

here is a simple cwm program that you can try out on your own!

first : the command line :

python2.2 cwm.py  _librdf_perl_world_init_.tu_.ntriples 
--filter=testfilter.n3 

Here testfilter.n3  is the name of the filter , and
_librdf_perl_world_init_.tu_.ntriples  is the name of the dump file.


Here is the filter:
---------------------------------------------------------------------------
@prefix : <#> .
@prefix log: <http://www.w3.org/2000/10/swap/log#> .
@prefix fld: <node_fields> .

this log:forAll <#x> , <#y> , <#z>, <#t1>.

{ <#x> <node_fields:name> <#y>       .
  <#y> <node_fields:strg> <#z>       .
  <#x> <node_fields:tree-code> <#t1> .

} log:implies { 
	<#x> <fld:has-name> <#z> .
	<#x> <fld:has-type> <#t1> .
	}.
---------------------------------------------------------------------------
here is the output :
#  Notation3 generation by
#       notation3.py,v 1.131 2003/01/21 16:10:36 timbl Exp

#   Base was:
file:/mnt/hda4/development/development2/w3c/2000/10/swap/_librdf_perl_world_init_.tu_.ntriples
     @prefix : <#> .
     @prefix fld: <node_fields> .
     @prefix log: <http://www.w3.org/2000/10/swap/log#> .
    
    :id-1     <fld:has-name> "librdf_perl_world_init";
         <fld:has-type> <node_types:function_decl> .
    
    :id-14     <fld:has-name> "bit_size_type";
         <fld:has-type> <node_types:integer_type> .
    
    :id-21     <fld:has-name> "librdf_world";
         <fld:has-type> <node_types:type_decl> .
    
    :id-22     <fld:has-name> "librdf_world_s";
         <fld:has-type> <node_types:record_type> .
    
    :id-33     <fld:has-name> "librdf_world_set_error";
         <fld:has-type> <node_types:function_decl> .
    
    :id-4     <fld:has-name> "world";
         <fld:has-type> <node_types:parm_decl> .
    
    :id-43     <fld:has-name> "librdf_world_set_warning";
         <fld:has-type> <node_types:function_decl> .
    
    :id-45     <fld:has-name> "librdf_perl_world";
         <fld:has-type> <node_types:var_decl> .
    
    :id-56     <fld:has-name> "librdf_perl_error_handler";
         <fld:has-type> <node_types:function_decl> .
    
    :id-61     <fld:has-name> "user_data";
         <fld:has-type> <node_types:parm_decl> .
    
    :id-62     <fld:has-name> "librdf_perl_warning_handler";
         <fld:has-type> <node_types:function_decl> .
    
    :id-67     <fld:has-name> "user_data";
         <fld:has-type> <node_types:parm_decl> .
    
    :id-78     <fld:has-name> "va_list";
         <fld:has-type> <node_types:type_decl> .



=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de

[Introspector-developers] Re: call for alpha testers EulerSharp for dotgnu/pnet

[<mdu...@ya...>]

Thanks,
maybe we can find a savannah page for this?  We need a cvs.
Otherwise we can host it under one other project.

I would like to use this to process the RDF from the gcc, inside the
gcc, For embedding the Euler into the GCC, i need only GPL modules.
I would like to re-licensed Euler under the GPL, is that possible? 

BTW:
I have just commited the updated dotgnu RDF stuff
you can find it here:
CVS: cvs -z3
-d:pserver:an...@su...:/cvsroot/dotgnu-libs co
dotgnu.rdf

and I made a source deb :
http://introspector.sourceforge.net/debian/incoming/dotgnu.rdf_0.2-1.tar.gz

you can find the dotgnu stuff at www.dotgnu.org, I suggest using the
cvs.

Mike
 --- Jos De_Roo <jos...@ag...> schrieb: > 
> Dear mike,
> 
> still can't believe my eyes...!
> will try to start testing ASAP
> and give support as much as possible
> 
>   we can work it out
>   forty five hundred times
>   ...
> 
> -- ,
> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
> 
> 
>                                                                      
>                                              
>                     James Michael                                    
>                                              
>                     DuPont               To:    
> www...@w3..., dev...@do...                    
>                     <mdupont777@ya       cc:     Jos
> De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER@AGFA,                       
>                     hoo.com>              mi...@ca...    
>                                              
>                                          Subject:     call for alpha
> testers EulerSharp for dotgnu/pnet            
>                     2003-02-08                                       
>                                              
>                     04:40 PM                                         
>                                              
>                                                                      
>                                              
>                                                                      
>                                              
> 
> 
> 
> 
> Dear all,
> you can find a alpha version of the EulerSharp Module for pnet
> 
> It is based on the code from Jos from http://www.agfa.com/w3c/euler/
> 
> This is based on the first Closed World Machine from TimBL:
> http://infomesh.net/2001/cwm/
> 
>
http://introspector.sourceforge.net/debian/incoming/eulersharp_0.1-1.tar.gz
> MD5  e4d84d45dade17c7541beb1a6131a101 54896 eulersharp_0.1-1.tar.gz
> 
> You might want to try with these options :
> try with -debug
> try with -trace
> 
> There were problems with the indexing of empty arrays and empty
> strings
> in pnet, i had to add checking code.
> 
> Otherwise, I still have only gotten one or two examples running,
> and the IL code in the file is out of date, (still buggy) so dont use
> it.
> 
> Otherwise, I have officially started working on the DotGNU port of
> Redland, Minddog (Adam B.) has setup a framework, a set of interfaces
> that will give you a redland API with no implementation. We will make
> a
> redland c implemention, but also a system.xml imp.
> you can check that out here
> https://savannah.gnu.org/projects/dotgnu-libs/
> 
> Also, I am hacking swig into a c# stub generator with some help
> https://savannah.nongnu.org/projects/swigsharp/
> 
> more to come,
> mike
> 
> 
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________________________
> 
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Bis zu 100 MB Speicher bei http://premiummail.yahoo.de
> 
> 
> 
>  

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de

[Introspector-developers] Fwd: Project Approved!!!

[<mdu...@ya...>]

 --- sav...@gn... schrieb: > From sav...@gn...
Fri Feb  7 13:57:26 2003
> An: mdu...@ya...
> Betreff: Project Approved
> Von: sav...@gn...
> Datum: Fri, 07 Feb 2003 16:57:26 -0500
> 
> 	
> Your project registration for Savannah has been approved.
> Project Full Name:   libre-introspector
> Project System Name: intrspctr
> Project page:        /projects/intrspctr
> 
> Please note that it may take a few hours for the system files to
> be updated (CVS repository creation for instance) after receiving
> this mail.
> 
> Enjoy the system, and please tell others about Savannah. Let us know
> if there is anything we can do to help you.
> 
>  -- the Savannah Volunteers
> 
> 
> 
> 
> 
> Post scriptum, important note:
>    In order, to release your project, you should write copyright
> notices
>    and license notices at the beginning of every source code file,
> and
>    include a copy of the plain text version of the license. If your
>    software is published under the GNU GPL license, you should read
>    http://www.gnu.org/copyleft/gpl.html#SEC4
>     

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de

[Introspector-developers] Fwd: submission of libre-introspector - savannah.nongnu.org

[James M. D. <mdu...@ya...>]

I have submitted this to savannah.
Can you please do me a favor, and write to sav...@gn...
asking them to approve the project?

thanks,
mike

--- sav...@gn... wrote:
> From sav...@gn... Wed Feb  5 13:19:02 2003
> Return-Path: <www...@su...>
> Received: from 199.232.41.2  (EHLO subversions.gnu.org)
> (199.232.41.2)
>   by mta404.mail.yahoo.com with SMTP; 05 Feb 2003 13:19:02 -0800
> (PST)
> Received: from www-data by subversions.gnu.org with local (Exim 3.35
> #1 (Debian))
> 	id 18gWwg-0002vo-00; Wed, 05 Feb 2003 16:19:02 -0500
> To: mdu...@ya...
> Subject: submission of libre-introspector - savannah.nongnu.org
> From: sav...@gn...
> Reply-to: sav...@gn...
> Message-Id: <E18...@su...>
> Date: Wed, 05 Feb 2003 16:19:02 -0500
> Content-Length: 822
> 
> 
> A package was submitted to savannah.nongnu.org
> This mail was sent to mdu...@ya..., sav...@gn...
> 
> 
> James Michael DuPont <mdu...@ya...> described the package as
> follows:
> License: gpl
> Other License: Also needs some coverage for generated code under BSD
> and Artistic
> Package: libre-introspector
> System name: intrspctr
> Type: non-GNU
> 
> Description:
> The introspector meta project
> builds rdf meta-data extraction tools for free sofware.
> 
> It uses redland to store meta data in rdf/ntriples and rdf/xml.
> 
> Currently targeted are gcc(c,c++,java) that is underway
> in planning  bash, m4, parrot, c#/il
> in experimentation: perl, 
> 
> 
> 
> Other Software Required:
> redland 
> gcc
> bash, m4, make
> perl, 
> 
> 
> 
> Other Comments:
> this project is hosted on introspector.sf.net,
> i want to migrate to savannah, i think the file release system is
> better and want to support it.
> 


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Fwd: Re: Question about extensible HLL syntax

[James M. D. <mdu...@ya...>]

Here we are getting to the idea
of making modifiers for algorithms that can be used on many data-types,
like in a c++ templating system, but based on introspection.
mike

--- James Michael DuPont <mdu...@ya...> wrote:
> From James Michael DuPont Tue Feb  4 22:20:01 2003
> Received: from [80.128.233.199] by web41503.mail.yahoo.com via HTTP;
> Tue, 04 Feb 2003 22:20:01 PST
> Date: Tue, 4 Feb 2003 22:20:01 -0800 (PST)
> From: James Michael DuPont <mdu...@ya...>
> Subject: Re: Question about extensible HLL syntax
> To: Brian T Rice <wa...@tu...>, Michael Conrad
> <con...@em...>
> CC: tu...@tu...
> In-Reply-To: <Pin...@be...>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> Content-Length: 1146
> 
> 
> --- Brian T Rice <wa...@tu...> wrote:
> > So really it would be extra information about laying out the code
> > that would be "tagged" onto the syntax tree nodes as needed, or if
> there's
> > an  automatic layout algorithm that someone used, the "whole tree"
> would
> > be tagged that way. The way Migration deals with it is that these
> > attributes are only moved across the network on demand, or even
> that
> it wouldn't  be  migrated, but the remote user who changes the code
> ships back the
> > changes  which the first user incorporates. Pretty-printing vs.
> careful manual
> > arrangement (of various kinds) is a matter of aesthetics, though,
> so
> > I  don't think there's an ideal solution for this, but it could
> probably be  done well enough. Does that make sense?
> 
> Brian, Sorry if you know all about this, but 
> You might be interested in the VCG (Visualization of Compiler Graphs
> )tool, it is a GPLed graph layout tool written in C.
> 
> http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html
> 
> I have started to create a new version of it, and have gotten all the
> uglified code from the author that was not availible for years. 
> If you are interested in that code, please let me know.
> 
> So if you want someone to port that to tunes some day, I am sure it
> would be a nice algorithm that would translate well to a different
> language. In fact, the whole idea of semantics preservation is very
> interesting with such a graph layout algorithm, becuase the basic
> algortithm should be independent of the names and the structure of
> the
> graph data structure. 
> 
> Will tunes allow for algorithms to be modified on the fly to use
> different underlying datastructures that basically have the same
> semantics : like two different graph data structures? If so, then the
> VCG algorithm could act directly on the internal language
> representation  with some mapping code, or on the standard vcg graph
> data structures.
> 
> 
> Just some ideas, hope you find them interesting.
> mike
> 
> 
> mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Fwd: Status

[James M. D. <mdu...@ya...>]

Here is a mail about the swig support, and c#
this will be an interesting addition for the introspector.

--- James Michael DuPont <mdu...@ya...> wrote:
> From James Michael DuPont Wed Feb  5 01:08:41 2003
> Date: Wed, 5 Feb 2003 01:08:41 -0800 (PST)
> From: James Michael DuPont <mdu...@ya...>
> Subject: Status
> To: Neil Cawse <ne...@ge...>, 'Peter Gloor' <p_...@ho...>
> CC: int...@li..., ma...@ya..., 
>     qtc...@li...
> 
> Dear All,
> I am preparing a patch for the swig cvs.
> Can you all please get cygwin, ssh, and cvs.
> use the swig cvs and check out the latest version.
> 
> I will be putting our files in the swigsharp cvs on savannah.
> The current issues are with the automake setttings, i needed to redo
> all that, you need automake 1.7 and autoconf 2.5.
> 
> The patch is also crashing on the simplist examples, 
> I will post what i have, and then we need to collect the patches.
> Does someone have that one patch that was submitted?
> 
> Also there is an interesting project call Binge, part of qtsharp I
> hope
> to use that for better access to the C# interfaces, those guys are
> much
> futher along.
> 
> mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Fwd: VCG Graph Layout in DIA (Re: XML)

[James M. D. <mdu...@ya...>]

Here is a mail about the VCG layout tool
one of the components of the introspector GUI.

--- James Michael DuPont <mdu...@ya...> wrote:
> From James Michael DuPont Wed Feb  5 00:54:04 2003
> Received: from [194.202.25.243] by web41509.mail.yahoo.com via HTTP;
> Wed, 05 Feb 2003 00:54:04 PST
> Date: Wed, 5 Feb 2003 00:54:04 -0800 (PST)
> From: James Michael DuPont <mdu...@ya...>
> Subject: VCG Graph Layout in DIA (Re: XML)
> To: dia...@gn...
> CC: gr...@gn...
> In-Reply-To: <81a...@sh...>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Length: 1214
> 
> 
> --- Lars Clausen <lrc...@cs...> wrote:
> > On Tue, 4 Feb 2003, James Michael DuPont wrote:
> > > 
> > > --- Lars Clausen <lrc...@cs...> wrote:
> > >> On Tue, 4 Feb 2003, James Michael DuPont wrote:
> > >> > 
> > >> > My biggest concern with the dotty program is that we are
> > supporting
> > >> > non-free software. Creating a direct dependancy on a software
> > that
> > >> is
> > >> > not compatible with the GPL. The software would have to be
> > >> distributed
> > >> > with dia to use this feature. 
> > >> 
> > >> As long as Dia don't require dot to compile/run, there's no
> > problem
> > >> with
> > >> interaction.  Having the ability to call out to dot when
> available
> > is
> > >> a
> > >> good thing.  
> > > 
> > > Would you consider also directly supporting the VCG tool?
> > > it produces modest results, and is GPLEd. We need at least some
> > basic
> > > support for multiple graph file formats. The VcG layout algorithm
> > can
> > > be directly embedded into Dia.
> > 
> > Certainly.  I wasn't aware of its existence.  Perhaps we can steal
> > some
> > autolayout for autorouting.
> 
> Great,
> I posted an annouce to the list of the availibilty of the full source
> code, 
> 
> http://mail.gnome.org/archives/dia-list/2003-February/msg00029.html
> 
> Maybe you can test it? We need to work out a layout api
> for passing graphs and and layouts back and forth :
> 
> for the past 8 years, the sources have been uglified, preventing full
> gpl compliance and preventing full usage. After some emails and
> convincing to the author, we have the patches to make it fully GPL
> compliant. Thanks to Gregor Greve for lots of help with it. 
> 
> I have mentioned it on the list a many times,
> but not really explaining the purpose or the meaning.
> If you want to review what I have said about vcg here are some mails
> :
> 
> http://www.mail-archive.com/dia...@gn.../msg03870.html
> http://www.mail-archive.com/dia...@gn.../msg04114.html
> 
> http://mail.gnome.org/archives/dia-list/2002-May/msg00129.html
> http://mail.gnome.org/archives/dia-list/2002-June/msg00021.html
> http://mail.gnome.org/archives/dia-list/2002-June/msg00443.html
> http://mail.gnome.org/archives/dia-list/2002-July/msg00024.html
> http://mail.gnome.org/archives/dia-list/2002-July/msg00241.html
> http://mail.gnome.org/archives/dia-list/2002-July/msg00165.html
> http://mail.gnome.org/archives/dia-list/2002-August/msg00210.html
> http://mail.gnome.org/archives/dia-list/2002-September/msg00078.html
> 
> Here are some mails from other lists:
> http://mail.gnome.org/archives/xml/2002-June/msg00153.html
>
http://mail.gnome.org/archives/gtk-app-devel-list/2003-January/msg00202.html
> 
> mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Re: Bytecode metadata

[James M. D. <mdu...@ya...>]

--- Leopold Toetsch <lt...@to...> wrote:
> James Michael DuPont wrote:
> 
> > --- gr...@fo... 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

[Introspector-developers] Re: Bytecode metadata

[Leopold T. <lt...@to...>]

James Michael DuPont wrote:

> --- gr...@fo... 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.


> mike

leo

[Introspector-developers] call for testing un uglified vcg 1.3

[<mdu...@ya...>]

Here are the uploads of the new version of vcg
that contains the unuglified code:

http://introspector.sourceforge.net/debian/incoming/vcg_1.30-4.tar.gz
http://introspector.sourceforge.net/debian/incoming/vcg_1.30-4_i386.deb

please test and report back.

I cannot wait any longer, we need to start working on this.

Sander said that I can do what I wish with his patches,
so here they are. The program passes the basic tests.

mike


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat,  5 Jan 2001 21:38:18 -0100
Source: vcg
Binary: vcg
Architecture: i386
Version: 1.30-4
Distribution: unstable
Urgency: low
Maintainer: Malcolm Parsons <ma...@iv...>
Changed-By: James Michael DuPont
Description: 
 vcg        - A Visualization Tool for compiler graphs
Changes: 
 vcg (1.30-4) unstable; urgency=low
 .
   * removed uglified code
Files: 
 4acf69a83a663d715359b64088db0df9 287684 graphics optional
vcg_1.30-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Pavd7TaNAfoTAloRAraqAJ9IGTrmPQVBzMG6QyZfekzFrRl+rACfdCKr
OEIpL8ifinwEviaOudZGHjQ=
=CsCG
-----END PGP SIGNATURE-----

=====
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] Patched HTMLGenerator.pm for VCG & Global dumping disabled.

[Dupont, M. <mic...@mc...>]

-----Original Message-----
From: Bernardi Mario Luca [mailto:mar...@in...]
Sent: Thursday, January 30, 2003 6:13 PM
To: introspector ml
Cc: James Michael DuPont
Subject: [Introspector-developers] Patched HTMLGenerator.pm for VCG &
Global dumping disabled.


Hi all ,

Here is the modified HTMLGenerator.pm that dumps vcg output. It creates
a ./output/vcg/gccmodel.vcg file.

I've used some conventions:

Boxed Nodes = Types ( they can be white(for classes) or lightcyan(for
interfaces)
Elliptical Nodes = Fields ( all not inherited fields of the node ) 
Red Edges = Inheritance (they are backedges so mostly go from bottom to
top)
Black Edges = Member fields (nearedge so they are placed orizontally
near the node type that owns them)
LightGrey Edges = Each gray edge pecify the type of each field.
 
Use this HTMLGenerator.pm instead of the cvs version to get the vcg
file. More work should be done for:
1) Add a VCGGenerator.pm instead of patching the HTML one.
2) Select the best visual option ( needs a bit of experimentation).
I would also consider the possibility of using subgraphs.

YES!!!!

THANKS,
THANKS
THANKS.

Grazie, siete il la cosa migliore. 

mike

[Introspector-developers] Patched HTMLGenerator.pm for VCG & Global dumping disabled.

[Bernardi M. L. <mar...@in...>]

Hi all ,

Here is the modified HTMLGenerator.pm that dumps vcg output. It creates
a ./output/vcg/gccmodel.vcg file.

I've used some conventions:

Boxed Nodes = Types ( they can be white(for classes) or lightcyan(for
interfaces)
Elliptical Nodes = Fields ( all not inherited fields of the node ) 
Red Edges = Inheritance (they are backedges so mostly go from bottom to
top)
Black Edges = Member fields (nearedge so they are placed orizontally
near the node type that owns them)
LightGrey Edges = Each gray edge pecify the type of each field.
 
Use this HTMLGenerator.pm instead of the cvs version to get the vcg
file. More work should be done for:
1) Add a VCGGenerator.pm instead of patching the HTML one.
2) Select the best visual option ( needs a bit of experimentation).
I would also consider the possibility of using subgraphs.

>From the testing scene i've just disabled the global dumping and now i'm
rebuilding. I'll report you the speed improvement  :)

-- 
Cheers,
Bernardi Mario Luca <mar...@in...>

Re: [Introspector-developers] Re: Bytecode metadata

[James M. D. <mdu...@ya...>]

--- Juergen Boemmels <boe...@ph...> wrote:
> Nicholas Clark <ni...@un...> 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

[Introspector-developers] Re: Bytecode metadata

[Juergen B. <boe...@ph...>]

Nicholas Clark <ni...@un...> writes:

[...]

> > 	struct Chunk {
> > 		opcode_t type;
> > 		opcode_t version;
> > 		opcode_t size;
> > 		void data[];
> > 	};

will this ever compile?
void data[] is not allowed, and even char data[] is an incomplete
type, so its not allowed in a structure definition. A void * data
pointer seems more appropriate. This way its possible to have one
TableOfContent for the whole bytecode file and every chunk of the file
can be accessed in constant time (no need to scan over the complete
file to reach the last chunk)

> I agree with the "roughly" bit, but I'd suggest ensuring that you put
> in enough bits to get data[] 64 bit aligned. Mainly because at least 1
> architecture exists that has no 32 bit types (Crays I know about; others
> may exist. I can't remember if perl 5.8 passes 100% of tests on Crays.
> We certainly tried)

opcode_t will be 64 bit on this architectures.

[...]

> I'm thinking that register usage information from imcc could be of use
> to the JIT, as that would save it having to work out things again. So that
> probably needs a segment.
> 
> Also some way of storing a cryptographic signature in the file, so that you
> could compile a parrot that automatically refuses to load code that isn't
> signed by you.

These ideas show clearly one thing:
The typecode must be extendible.

[...]
> > >It might be even possible to dump the jitted code. This would increase
> > >the startup. Then strip the bytecode to reduce the size of the file
> > >and TADA: Yet another new binary format.

> > When you then are able to to get the same memory layout for a newly 
> > created interpreter, it might even run ;-)
> 
> So the JITted code contains lots of hard references to address in running
> interpreter? It's not just dependent on that particular binary's
> layout?

And if there are two interpreters in the same process (isn't that the
supposed way of multiple threads) each one has to compile the same
code again?

> 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?

bye
boe
-- 
Juergen Boemmels			boe...@ph...
Fachbereich Physik			Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern		Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

[Introspector-developers] Re: Tree documentation

[James M. D. <mdu...@ya...>]

Steven, 
thank you for your interest. I have forward your mail to the mailling
list (I hope you dont mind). Mario Luca and I have evaluated the simple
trees and found them to be too unstable at the moment for usage.
I will review your documentation. 

The introspector API is for the gcc, but is based on the idea of making
the docuementation as part of the API, basically self descriptive.

We are working on testing the c++ interface at this moment, and will
need to review the c++ tree documentation in detail, as the c++ trees
are crashing.

I will work on a texi output dump of the current meta-model, based on
your documentation. We will see if we can come to a synthesis.

mike
--- Steven Bosscher <s.b...@st...> wrote:
> Wow, what an email change can do...  I didn't know you were working
> on
> improving the documentation of, a.o.t., the tree structure.  As part
> of
> the tree-ssa work, I was planning some documentation of GENERIC, and
> later of GIMPLE.  The former is the intermediate representation that
> future front ends should target, the latter is the lowest-level tree
> representation we have in GCC (well, on the branch at least), on
> which
> we're doing SSA-bases optimizations.
> 
> Attached is my first shot at it, that I posted to Diego Novillo a
> month
> or so ago.  Maybe it's of some help for you, or better, maybe we can
> finish this together.
> 
> Greetz
> Steven
> 
> 
> 
> > \input texinfo  @c -*-texinfo-*-
> @c Copyright (c) 2003 Free Software Foundation, Inc.
> @c Free Software Foundation, Inc.
> @c This is part of the GCC manual.
> @c For copying conditions, see the file gcc.texi.
> 
> @c
> ---------------------------------------------------------------------
> @c GENERIC
> @c
> ---------------------------------------------------------------------
> 
> 
> @node GENERIC
> @chapter GENERIC: The language-independent abstract syntax tree
> intermediate representation.
> @cindex Trees
> @cindex GENERIC
> 
> This chapter explains the language-independent intermediate
> representation GENERIC.
> When presented with a source program,
> a front end parses the program, performs semantic analysis
> (including the generation of error messages),
> and then produces the internal representation described here.
> This representation contains a complete representation for
> the entire translation unit provided as input to the front end.
> 
> This is a draft of a design of this new intermediate
> representation.
> It's a bit sketchy at this point, because the
> language-independent optimizers are still very much
> work-in-progress.
> Sometimes the specification of this IR has to be changed
> to better suite the needs of the optimizers.
> 
> 
> @node Introduction
> @section Introduction to GENERIC
> 
> Like most other compilers, GCC uses different intermediate
> representations, or @dfn{IRs}, at different stages of the
> compilation process.
> At the highest level, each front end represents the syntax
> and semantics of the input in a language-dependent parse tree.
> The parse tree may not be the most suitable representation
> to perform high-level optimizations on.
> Also, if optimizations were to be performed on the parse tree,
> then the optimizations could not be language independent,
> and different implementations of the optimizations would
> have to exist for each language. 
> To avoid all that code duplication, GCC has a language
> independent abstract syntax tree representation called
> @dfn{GENERIC}.
> In GENERIC, the full semantics of each of the supported
> languages can be represented.
> Therefore, GCC can now perform high-level optimizations
> in a language independent way on this IR.
> 
> In GENERIC, the semantics of the source language is
> represented as a chain of @dfn{statement-expressions}, i.e.,
> a series of statements which may return a value.
> The distinction between statements and expressions is that
> a statement is something for which we are only interested
> in its side-effects, not its value.
> It's a difference of evaluation context, not always an
> intrinsic difference.
> However, most languages do explicitly distinguish between
> statements and expressions.
> This makes it harder to represent the language-indepentend
> semantics in a properly structured way.
> By not distinguishing between statements and expressions,
> and by virtue of working mostly in the existing backend
> tree codes,
> GENERIC is relatively small IR that can represent
> the semantics of all the languages that GCC has
> front ends for.
> 
> 
> @node Functions
> @section Functions
> @tindex FUNCTION_DECL
> 
> A function declaration is represented by a @code{FUNCTION_DECL} node,
> 
> @example
> @group
>    function :
> 	FUNCTION_DECL
> 	   DECL_SAVED_TREE -> block
> @end group
> @end example
> 
> To determine the scope of a function, you can use the
> @code{DECL_CONTEXT} macro.
> This points to either a @code{FUNCTION_DECL} for the
> containing function, a @code{RECORD_TYPE}
> or a @code{UNION_TYPE} for the containing class,
> or @code{NULL_TREE} if the function has "file scope".
> 
> If the @code{DECL_CONTEXT} for a function is another
> @code{FUNCTION_DECL}, this representation indicates
> that the GNU nested function extension is in use.
> For details on the semantics of nested functions,
> you are refered to the GCC Users Manual.
> The nested function can refer to local variables in
> its containing function.
> Such references are not explicitly marked in GENERIC.
> 
> Overloaded functions cannot be represented in GENERIC,
> and should be resolved in the front end.
> 
> 
> @node Scope
> @section Scope
> @tindex BIND_EXPR
> 
> A @code{BIND_EXPR} represents a scope.
> @code{BIND_EXPR_VARS} holds a list of @code{VAR_DECL} nodes,
> connected via their @code{TREE_CHAIN} field.
> These will never require cleanups.
> All of the decls for a block are given RTL at the beginning
> of the block.
> Declarations with static initializers keep their
> @code{DECL_INITIAL};
> other initializations are implemented with @code{INIT_EXPRs}
> in the codestream.
> The scope of these variables is just the body of the
> @code{BIND_EXPR},
> which can be accessed through the @code{BIND_EXPR_BODY} macro.
> The body holds the expression to be computed using the
> variables.
> 
> If the @code{BIND_EXPR} is ever expanded,
> its @code{TREE_USED} flag is set.
> @code{BIND_EXPR_BLOCK} is the @code{BLOCK} that corresponds
> to the bindings in this block, for debugging purposes.
> If this @code{BIND_EXPR} is actually expanded,
> that sets the @code{TREE_USED} flag in the @code{BLOCK}.
> This tells the code for debugging symbol tables not to ignore
> the @code{BIND_EXPR}.
> If the @code{BIND_EXPR} should be output for debugging but
> will not be expanded,
> set the @code{TREE_USED} flag by hand.
> 
> @example
> @group
>    block :
> 	BIND_EXPR
> 	   BIND_EXPR_VARS -> DECL chain
> 	   BIND_EXPR_BLOCK -> BLOCK
> 	   BIND_EXPR_BODY -> compound-stmt
> @end group
> @end example
> 
> @example
> @group
>    compound-stmt :
> 	COMPOUND_EXPR
> 	   op0 -> non-compound-stmt
> 	   op1 -> stmt
> 
>    stmt :
> 	compound-stmt
> 	| non-compound-stmt
> @end group
> @end example
> 
> Questions have been raised about the advisability of using
> @code{COMPOUND_EXPR} to chain statements;
> in most front ends, the program is represented as a chain
> of @code{*_STMT} nodes, and the @code{TREE_CHAIN} field of
> these nodes is used to chain them together.
> The benefit of using @code{COMPOUND_EXPR} instead is modularity;
> apart from the statemenent/expression distinction,
> using @code{COMPOUND_EXPR} makes it easy to replace a
> single, complex expression with a sequence of simple ones,
> simply by plugging in a @code{COMPOUND_EXPR} in its place.
> The @code{TREE_CHAIN} scheme required a lot more pointer
> management in order to splice the new @code{*_STMTs}
> in at both ends.
> 
> (An additional advantage that we do not use yet,
> is that double-chaining could be provided by using
> the @code{TREE_CHAIN} of the @code{COMPOUND_EXPRs}.
> Without double-chaining,
> some code transformations like goto elimination are
> much harder to implement.)
> 
> 
> @node Control Flow
> @section Control Flow
> 
> @c Every @code{non-compound-stmt} affects control flow.
> 
> @example
> @group
>    non-compound-stmt :
> 	block
> 	| loop-stmt
> 	| if-stmt
> 	| switch-stmt
> 	| labeled-block-stmt
> 	| jump-stmt
> 	| label-stmt
> 	| try-stmt
> 	| modify-stmt
> 	| call-stmt
> @end group
> @end example
> 
> @node Unconditional Branching
> @subsection Unconditional Branching
> 
> @example
> @group
>    jump-stmt :
> 	EXIT_EXPR
> 	   EXIT_EXPR_COND -> condition
> 	| GOTO_EXPR
> 	   GOTO_DESTINATION -> LABEL_DECL | '*' ID
> 	| RETURN_EXPR
> 	   op0 -> modify-stmt | NULL_TREE
> 	| EXIT_BLOCK_EXPR
> 	   EXIT_BLOCK_LABELED_BLOCK -> ref to LABELED_BLOCK_EXPR
> 	   op1 -> NULL_TREE
> 	| THROW_EXPR ???
> @end group
> @end example
> 
> Ideally, the assignment to the return value would
> be moved out of the @code{RETURN_EXPR},
> but it appears that @code{expand_return} depends
> on getting an assignment
> (or actually, a @code{MODIFY_EXPR})
> in order to handle some return semantics.
> 
> @example
> @group
>    labeled-block-stmt :
> 	LABELED_BLOCK_EXPR
> 	   LABELED_BLOCK_LABEL -> LABEL_DECL
> 	   LABELED_BLOCK_BODY -> stmt
> @end group
> @end example
> 
> @example
> @group
>    label-stmt :
> 	LABEL_EXPR
> 	   LABEL_EXPR_LABEL -> LABEL_DECL
> 	| CASE_LABEL_EXPR
> 	     CASE_LOW -> value | NULL_TREE
> 	     CASE_HIGH -> value | NULL_TREE
> @end group
> @end example
> 
> @node Conditional Branching
> @subsection Conditional Branching
> @tindex COND_EXPR
> @tindex SWITCH_EXPR
> 
> There are two kinds of expressions in GENERIC that
> represent conditional branching:
> @code{COND_EXPR} and @code{SWITCH_EXPR}.
> The former is used to represent a conditional branch
> on a boolean expression;
> the latter represents multiway branching.
> 
> The @code{COND_EXPR} is a natural way to represent an
> @code{if} statement.
> The @code{COND_EXPR} should be interpreted as a
> @code{ ... ? ... : ...} expression in C.
> 
> @example
> @group
>    if-stmt :
> 	COND_EXPR
> 	   op0 -> condition
> 	   op1 -> stmt
> 	   op2 -> stmt
> @end group
> @end example
> 
> A multiway branching expression depending on the value
> of a certain expression,
> such as the @code{switch} statement,
> is represented by a @code{SWITCH_EXPR}.
> 
> @example
> @group
>    switch-stmt:
> 	SWITCH_EXPR
> 	   op0 -> value
> 	   op1 -> stmt
> @end group
> @end example
> 
> The exact representation for multiway branches
> is not entirely clear yet.
> There will probably have to be a vector that maps
> all the case value ranges to @code{LABEL_EXPRs}
> for each @code{SWITCH_EXPR},
> but this has not been implemented yet.
> There are many ways the different cases could be
> represented in the IR,
> and each of them has their specific advantages and
> disadvantages.
> Intermediate representations for other compilers,
> such as the McCAT SIMPLE IR,
> require that during lowering the case labels are
> made disjoint by copying shared code around,
> allowing a more structured representation of a
> multiway branch.
> For GCC this is too dubious an optimization to be
> performed by default,
> as it would just copy too much code around.
> This still might be interesting as part
> of a goto-elimination pass, though,
> or for multiway branches with no more than a
> certain number of cases.
> 
> @node Loops
> @subsection Loops
> @tindex LOOP_EXPR
> @tindex COND_EXPR
> 
> All loops are represented by a generic @code{LOOP_EXPR}.
> Because a @code{LOOP_EXPR} represents an infinite loop, 
> the loop body has one or more @code{EXIT_EXPR} nodes,
> used to express the loop condition.
> Usually the @code{EXIT_EXPR} is in one of the branches
> for an @code{COND_EXPR}.
> 
> @example
> @group
>    loop-stmt:
> 	LOOP_EXPR
> 	   LOOP_EXPR_BODY -> stmt
> @end group
> @end example
> 
> There is no distinction between what might have been
> a @code{for} loop or a @code{do @{ ... @} while} loop
> in the source program.
> The only difference in the representation is whether the
> exit condition is evaluated at the start of the loop body,
> as in @code{while} and @code{for} loops,
> or at the end of the loop body,
> as in @code{do-while} loops.
> 
> @code{EXIT_EXPR} is a bit backwards for some purposes,
> as its sense is opposite to that of the loop condition,
> so we end up calling invert_truthvalue twice in
> the process of generating and expanding it.
> That's not a big deal,
> but perhaps we should change it anyway.
> 
> 
> @node Exception Handling
> @section Exception Handling
> @example
> @group
>    try-stmt :
> 	TRY_CATCH_EXPR
> 	| TRY_FINALLY_EXPR
> @end group
> @end example
> 
> This will need to be extended to handle type-based catch clauses as
> well.
> 
> @c I think it makes sense to leave this as a separate tree code for
> handling
> @c cleanups.
> 
> @node Expressions
> @section Expressions
> 
> @example
> @group
>    modify-stmt :
> 	MODIFY_EXPR
> 	   op0 -> lhs
> 	   op1 -> rhs
> 	| INIT_EXPR
> 	     op0 -> lhs
> 	     op1 -> rhs
> 
>    call-stmt :
> 	CALL_EXPR
> 	   op0 -> ID
> 	   op1 -> arglist
> @end group
> @end example
> 
> Assignment and calls are the only expressions with
> intrinsic side-effects,
> so only they can appear at statement context.
> 
> The rest of this is basically copied from the McCAT design.
> I think it still needs some tweaking,
> but that can wait until after the statement-level stuff is
> worked out.
> 
> @example
> @group
>    varname :
> 	compref
> 	| ID (rvalue)
> 
>    lhs :
> 	compref
> 	| ID (lvalue)
> 	| * ID (rvalue)
> 
>    pseudo-lval :
> 	ID
> 	| '*' ID  (either lvaule or rvalue)
> 
>    compref :
> 	COMPONENT_REF
> 	   op0 -> compref | pseudo-lval
> 	| ARRAY_REF
> 	   op0 -> compref | pseudo-lval
> 	   op1 -> value
> 
>    condition :
> 	value
> 	| value relop val
> 
>    value :
> 	ID
> 	| CONST
> 
>    rhs :
> 	varname
> 	| CONST
> 	| '*' ID
> 	| '&' varname_or_temp
> 	| call_expr
> 	| unop value
> 	| value binop value
> 	| '(' cast ')' varname
> 
>    unop :
> 	'+'
> 	| '-'
> 	| '!'
> 	| '~'
> 
>    binop :
> 	relop
> 	| '-'
> 	| '+'
> 	| '/'
> 	| '*'
> 	| '%'
> 	| '&'
> 	| '|'
> 	| '<<'
> 	| '>>'
> 	| '^'
> 
>    relop :
> 	'<'
> 	| '<='
> 	| '>'
> 	| '>='
> 	| '=='
> 	| '!='
> @end group
> @end example
> 
> 
> 
> 


=====
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: [DotGNU]call for c,c++,java te st cases for the introspector

[Dupont, M. <mic...@mc...>]

OK, no problem.
I will take care of it.

mike

-----Original Message-----
From: Peter Minten [mailto:pet...@wa...]
Sent: Sunday, January 26, 2003 3:01 PM
To: James Michael DuPont
Cc: dotgnu; introspectors
Subject: Re: [Introspector-developers] Re: [DotGNU]call for c,c++,java
test cases for the introspector


James Michael DuPont wrote:

> If you can do be a big favor :
> if you know the libs of these two systems, and have it all installed
> and running, please compile with -save-temps on a juicy file from both
> systems, the ruby api, and the fox kit itself.  zip it up and put it
> where i can get it. Sure it is a little more work for you, and I can
> completly understand if you dont have the time, but it would make
> things easier on me. I dont know if I even have ruby installed ....

Unfortunately my internet connection (dialup) is too small to transport the
whole bunch of files :-(, sorry.

Greetings,

Peter



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Introspector-developers mailing list
Int...@li...
https://lists.sourceforge.net/lists/listinfo/introspector-developers

[Introspector-developers] Re: Bytecode metadata

[James M. <ja...@ma...>]

On 01/25/2003 4:26 AM, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>> Also some way of storing a cryptographic signature in the file, so 
>> that you
>> could compile a parrot that automatically refuses to load code that isn't
>> signed by you.
> The palladium parrot :)
Just because it's possible to use a technology for evil doesn't mean you 
shouldn't create it.  I think it would be quite useful to define a 
standard for signed PBC.  It doesn't need to be complex; just define a 
new packfile section, SIGNATURE, that is defined to be a cryptographic 
signature of all sections previous to it in the file.  (We'd have to 
exclude certian parts of the header, or otherwise work around 
chicken-and-egg problems with the signed header changing in the act of 
attaching the signature, but those are long-since-solved problems.)

In purticlar, it would be nice to be able to trust code written by 
myself and people I personaly trust, run CPAN code in checked mode, run 
code submited by users without access to create IO PMCs, and not run 
Micorosoft code at all.

A code signing standard would enable that.  It's defining a trust model 
that doesn't let the user know what's actualy going on that we have to 
be wary of.  (Even authenticating the host is potentialy useful... 
though I can't think of a good use.)

	-=- James Mastros

Re: [Introspector-developers] Re: [DotGNU]call for c,c++,java test cases for the introspector

[Peter M. <pet...@wa...>]

James Michael DuPont wrote:

> If you can do be a big favor :
> if you know the libs of these two systems, and have it all installed
> and running, please compile with -save-temps on a juicy file from both
> systems, the ruby api, and the fox kit itself.  zip it up and put it
> where i can get it. Sure it is a little more work for you, and I can
> completly understand if you dont have the time, but it would make
> things easier on me. I dont know if I even have ruby installed ....

Unfortunately my internet connection (dialup) is too small to transport the
whole bunch of files :-(, sorry.

Greetings,

Peter

Re: [Introspector-developers] Re: [DotGNU]call for c,c++,java test cases for the introspector

[James M. D. <mdu...@ya...>]

--- Peter Minten <pet...@wa...> wrote:
> James Michael DuPont wrote:
> > 
> > dear all,
> > 
> > can you please help me prepare some test cases for the c++/pnvoke
> > handling?
> > I would like to test the introspector on some code, the best would
> be
> > the code that uses swig, inline or c# pinvoke.  Anything that has a
> > monster header file would do!
> 
> Well this isn't exactly what you asked for, but it has really monster
> header
> files, FOX. I tried to use SWIG on it but didn't get very far. Anyway
> a good
> (stable, and without the new license that causes GPL incompat) is at
> http://www.fox-toolkit.org/ftp/fox-1.0.29.tar.gz , the FXRuby package
> at
> http://sourceforge.net/projects/fxruby has SWIG files, but those are
> a little
> ruby specific.
>  

Ruby? Thats a good idea!
/me will run the introspector over ruby.
thanks for the links.

If you can do be a big favor :
if you know the libs of these two systems, and have it all installed
and running, please compile with -save-temps on a juicy file from both
systems, the ruby api, and the fox kit itself.  zip it up and put it
where i can get it. Sure it is a little more work for you, and I can
completly understand if you dont have the time, but it would make
things easier on me. I dont know if I even have ruby installed ....

that would save me a chunk of time, i want to get this c++ bug cleared
out soon. (the introspector is segfaulting)!

that goes to all of you, if you have a minute, please start collecting
your .i files for the introspector, pick out some juicy files that
contain an lot, and send them in. 

So far we have submissions from ajmitch (konquerer/qt) and stefan
cambell (Emacs and Guile). Anyone else out there working on some
interesting code?

thanks,
mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Re: [DotGNU]call for c,c++,java test cases for the introspector

[Peter M. <pet...@wa...>]

James Michael DuPont wrote:
> 
> dear all,
> 
> can you please help me prepare some test cases for the c++/pnvoke
> handling?
> I would like to test the introspector on some code, the best would be
> the code that uses swig, inline or c# pinvoke.  Anything that has a
> monster header file would do!

Well this isn't exactly what you asked for, but it has really monster header
files, FOX. I tried to use SWIG on it but didn't get very far. Anyway a good
(stable, and without the new license that causes GPL incompat) is at
http://www.fox-toolkit.org/ftp/fox-1.0.29.tar.gz , the FXRuby package at
http://sourceforge.net/projects/fxruby has SWIG files, but those are a little
ruby specific.
 
Greetings,

Peter

[Introspector-developers] Re: Bytecode metadata

[Leopold T. <lt...@to...>]

Nicholas Clark wrote:

> On Sat, Jan 25, 2003 at 10:26:22AM +0100, Leopold Toetsch wrote:
> 

>>The palladium parrot :)
>>
> 
> naa. I said "signed by you", not "signed by the RIAA^WMPAA^WMicrosoft"


Yes, of course. I would do this with a personalized version of 
fingerprint.c and generate a separate executable.


> Nicholas Clark


leo