Eiffel › Eiffel Gobo

Git development

34 messages

1 2

Howard Thomson

Git development

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Hi Eric & Wolfgang,

I would welcome a move to using Git as the SCM system for Gobo.

I see that there is a useful page on wikipedia about git, with reference to Windows implementations:

http://en.wikipedia.org/wiki/Git_(software)#Implementation

There is also an excellent website detailing how to use git ...

http://progit.org/

Regarding my own project:

I have recently, I think [famous last words], reached stability with my

GC when compiling with my modified 'gec', albeit that I have only so

far tested it on Linux. A Win32 version should be a fairly trivial adaptation,

as it should be no more than adaptation of a single, smallish, routine.

I am also thinking of renaming my project as 'guide',

the Gobo-eiffel Users' Integrated Development Environment,

from 'edp', the Eiffel Developers' Project. Although there a few

classes [from other sources] that are LGPL, nearly all code that does

not already derive from gobo, is EFFLv2 or MIT.

I am very interested to hear about the introspection and debugger code, as

I need such facilities for my intended future coding.

One of the areas of the code generator that I intend to alter is the polymorphic

dispatch implementation, for two reasons:

Firstly for rapid re-compilation, I want to be able to generate an initial code package as

an executable stub with dynamic library, where libraries register their routine addresses

with the runtime, with subsequent partial re-compilation code generated as an additional

dynamic library whose routines override the registered routines of the initial library. This

requires that routine dispatch be done using a tree data structure, of some sort ...

Secondly, I envisage that it should be possible, as with Java and other languages [mostly interpreted ..],

to dynamically add class libraries to an executable system, where such libraries have been packaged,

[compiled or otherwise verified against] to be compatible with classes already in the current system.

That would also require that the dispatch to reachable routines be dynamically extendable.

I am adapting my work on the Eiffel GUI toolkit derived from the Fox-toolkit to use the Vision2 interface,

providing an X11/Win32 all Eiffel GUI Toolkit, which has its advantages ...

I am working toward using LLVM as the basis for code generation for native Eiffel routines, initially to emit

LLVM assembler with llvm-as invocation, and with the possibility [much] later of emitting machine code directly.

I think using Git would assist in cooperation between myself and other gobo-eiffel contributors and developers.

Regards,

Howard Thomson

"Only two things are infinite, the universe and human stupidity,

and I'm not sure about the former." -- Albert Einstein

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jocelyn.Fiat

Re: Git development

Reply Threaded

Note that, I first learn about git with this document:

http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
Then for svn user, this doc can help
http://git.or.cz/course/svn.html
And of course the official git web site, with all its links
http://git-scm.com/
including:
http://book.git-scm.com/

-- Jocelyn

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jocelyn.Fiat

Re: Git development

Reply Threaded

In reply to this post by Howard Thomson

In a previous post, Eric said the git tools for Windows were not very
attractive.
And I agree they are not yet at the same level as TortoiseSVN.

However, personally I am using on Windows
- msysGit http://code.google.com/p/msysgit/downloads/list
- for the gui ... either git gui, or gitk which come with any git setup
but most often, I use Git Extensions
(http://sourceforge.net/projects/gitextensions/) which is good enough
for my need.
- I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/)
but I was unable to make it work on my Win XP Pro 64bits (too bad, since
I am a TortoiseSVN user, and I really like it)

For my usage, the Git Extensions GUI is good enough, and when I need to
do complicated operation (or even simple) I use (very often) git in
command line (as I do with svn)
Indeed git is much more powerful than svn, but it is also more
complicated (in addition the command name are not always very
intuitive), thus I find it often easier to use command line to do
exactly what I want.
Also the branching is great, but you have to get used to it, otherwise
you waste time figuring out how to best deal with it (in final, I learnt
that the best solution is to ALWAYS work on its own branch, and merge
with the master/trunk when ready to commit)

And at the end, I agree that git on Windows is much slower than git on
linux (especially git svn), but it is ok

There are other alternative to git, such as mercurial, but I don't
really know them. It seems like git is the most popular (due to linux
repo I guess).
I heard there is a native client for Windows in development, but I don't
know where to find it ...

Maybe before going for git, Gobo's dev could use git-svn as following
> mkdir gobo.git
> cd gobo.git
Initialize your local repository based on the gobo's subversion repo
> git svn init
https://gobo-eiffel.svn.sourceforge.net/svnroot/gobo-eiffel/gobo/trunk
fetch the commits from revision 6555 (for instance this one which is
the gobo 3.9 release)
note, you can also git clone the entire gobo's repository .. but it is
longer
> git fetch -r6555
now, get sync with trunk@HEAD
> git svn rebase

If you want, to do some modification, I would recommend to work on your
own branch (I use my login for that "jfiat")
> git checkout -b jfiat

Then you can work on your own branch ... as with any git repo, so check
the git tutorials to know how to use git. This includes locally commits
(that's such a great feature, I wish subversion implement it some day).

And when ever you are ready to commit and "push" to the official gobo's
svn repository, you switch back to the master (which represent the trunk
in subversion)
> git checkout master
Eventually sync with head with: git svn rebase

Merge the changes from your branch
> git merge --squash jfiat
The --squash is used to merge your branch to the master .. BUT without
doing any commit, then you can commit your change in only one commit.
I tried without the "--squash", and it re-creates all the commits done
in my branch into the master. This could be useful, if you want to
"replay" your work in the master for history...

You can then commit your change
> git commit -a -m "Merge jfiat's branch into the master branch
to implement feature X"

And finally, you push/send your changes to the svn repo
> git svn dcommit

Check the following links for use cases:
- http://techbase.kde.org/Development/Tutorials/Git
- http://live.gnome.org/GitForGnomeDevelopers

So this way to do, can be a temporary solution to use git with Gobo.
Then decide with gobo's developers, if git is the right tool for gobo's
repo.

(Note that using git with real git repositories, is easier and more fun,
but .. git-svn is a solution to try, and even work)

-- Jocelyn

Howard Thomson wrote:

> >
> > Hi Eric & Wolfgang,
> >
> > I would welcome a move to using Git as the SCM system for Gobo.
> >
> > I see that there is a useful page on wikipedia about git, with
> > reference to Windows implementations:
> >
> > http://en.wikipedia.org/wiki/Git_(software)#Implementation
> >
> > There is also an excellent website detailing how to use git ...
> >
> > http://progit.org/
> >
> > <snip>....</snip>
> >
> > I think using Git would assist in cooperation between myself and other
> > gobo-eiffel contributors and developers.
> >
> > Regards,
> >
> > Howard Thomson
> >
>

Jocelyn.Fiat

Re: Git development

Reply Threaded

This message is a side note about what Eric said about me, Jocelyn,
using git for void-safe version of Gobo.
This message has nothing to do with Gobo, and is focused on special
usage of git and subversion.

So yes, I am using git for void-safe version of Gobo
(http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master), but my
use of git for this is unusual.

I use it to have a double SCM control on gobo's and ise's classes
related to Gobo.
To be short, I use git AND svn on the same files to be able to local
commit on the git repository (hosted on github), and also being able to
diff using svn diff on the ise and gobo's svn repository.

Indeed, when you svn checkout
https://svn.eiffel.com/eiffelstudio/trunk/Src/library/gobo
you end up with
gobo/many files
gobo/override
gobo/src
gobo/svn

and gobo/* are parts of eiffelstudio's svn repository
while gobo/svn/* are part of the gobo's svn repository (we use
svn:externals for that purpose).

And my git repository covers gobo/* AND gobo/svn/* files
This can be seens as a little trick, but it is really nice to have local
commits, and still be able to diff easily with gobo's subversion repository.

However, this is possible, but this is not that convenient when there
are big commits on the gobo's trunk. Since there are many conflict to
resolve in order to keep synchronized with gobo's trunk@HEAD

(probably, I could have used git svn, and git sub modules, but at that
time, I was using git for the very first time)

-- Jocelyn

Jocelyn wrote:

> In a previous post, Eric said the git tools for Windows were not very
> attractive.
> And I agree they are not yet at the same level as TortoiseSVN.
>
> However, personally I am using on Windows
> - msysGit http://code.google.com/p/msysgit/downloads/list
> - for the gui ... either git gui, or gitk which come with any git setup
> but most often, I use Git Extensions
> (http://sourceforge.net/projects/gitextensions/) which is good enough
> for my need.
> - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/)
> but I was unable to make it work on my Win XP Pro 64bits (too bad, since
> I am a TortoiseSVN user, and I really like it)
>
> For my usage, the Git Extensions GUI is good enough, and when I need to
> do complicated operation (or even simple) I use (very often) git in
> command line (as I do with svn)
> Indeed git is much more powerful than svn, but it is also more
> complicated (in addition the command name are not always very
> intuitive), thus I find it often easier to use command line to do
> exactly what I want.
> Also the branching is great, but you have to get used to it, otherwise
> you waste time figuring out how to best deal with it (in final, I learnt
> that the best solution is to ALWAYS work on its own branch, and merge
> with the master/trunk when ready to commit)
>
> And at the end, I agree that git on Windows is much slower than git on
> linux (especially git svn), but it is ok
>
> There are other alternative to git, such as mercurial, but I don't
> really know them. It seems like git is the most popular (due to linux
> repo I guess).
> I heard there is a native client for Windows in development, but I don't
> know where to find it ...
>
> Maybe before going for git, Gobo's dev could use git-svn as following
> > mkdir gobo.git
> > cd gobo.git
> Initialize your local repository based on the gobo's subversion repo
> > git svn init
> https://gobo-eiffel.svn.sourceforge.net/svnroot/gobo-eiffel/gobo/trunk
> fetch the commits from revision 6555 (for instance this one which is
> the gobo 3.9 release)
> note, you can also git clone the entire gobo's repository .. but it is
> longer
> > git fetch -r6555
> now, get sync with trunk@HEAD
> > git svn rebase
>
> If you want, to do some modification, I would recommend to work on your
> own branch (I use my login for that "jfiat")
> > git checkout -b jfiat
>
> Then you can work on your own branch ... as with any git repo, so check
> the git tutorials to know how to use git. This includes locally commits
> (that's such a great feature, I wish subversion implement it some day).
>
> And when ever you are ready to commit and "push" to the official gobo's
> svn repository, you switch back to the master (which represent the trunk
> in subversion)
> > git checkout master
> Eventually sync with head with: git svn rebase
>
> Merge the changes from your branch
> > git merge --squash jfiat
> The --squash is used to merge your branch to the master .. BUT without
> doing any commit, then you can commit your change in only one commit.
> I tried without the "--squash", and it re-creates all the commits done
> in my branch into the master. This could be useful, if you want to
> "replay" your work in the master for history...
>
> You can then commit your change
> > git commit -a -m "Merge jfiat's branch into the master branch
> to implement feature X"
>
> And finally, you push/send your changes to the svn repo
> > git svn dcommit
>
> Check the following links for use cases:
> - http://techbase.kde.org/Development/Tutorials/Git
> - http://live.gnome.org/GitForGnomeDevelopers
>
> So this way to do, can be a temporary solution to use git with Gobo.
> Then decide with gobo's developers, if git is the right tool for gobo's
> repo.
>
> (Note that using git with real git repositories, is easier and more fun,
> but .. git-svn is a solution to try, and even work)
>
> -- Jocelyn
>
> Howard Thomson wrote:
>
>
>>> Hi Eric & Wolfgang,
>>>
>>> I would welcome a move to using Git as the SCM system for Gobo.
>>>
>>> I see that there is a useful page on wikipedia about git, with
>>> reference to Windows implementations:
>>>
>>> http://en.wikipedia.org/wiki/Git_(software)#Implementation
>>>
>>> There is also an excellent website detailing how to use git ...
>>>
>>> http://progit.org/
>>>
>>> <snip>....</snip>
>>>
>>> I think using Git would assist in cooperation between myself and other
>>> gobo-eiffel contributors and developers.
>>>
>>> Regards,
>>>
>>> Howard Thomson
>>>
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gobo-eiffel-develop mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>

Wolfgang Jansen

Re: Git development

Reply Threaded

In reply to this post by Howard Thomson

Some javascript/style in this post has been disabled (why?)

Hi Howard,

Howard Thomson wrote:

>
> Hi Eric & Wolfgang,
>
> I would welcome a move to using Git as the SCM system for Gobo.
>
> I see that there is a useful page on wikipedia about git, with
> reference to Windows implementations:
>
> http://en.wikipedia.org/wiki/Git_(software)#Implementation
>
> There is also an excellent website detailing how to use git ...
>
> http://progit.org/
>
> Regarding my own project:
>
> I have recently, I think [famous last words], reached stability with my
>
> GC when compiling with my modified 'gec', albeit that I have only so
>
> far tested it on Linux. A Win32 version should be a fairly trivial
> adaptation,
>
> as it should be no more than adaptation of a single, smallish, routine.
>
> I am also thinking of renaming my project as 'guide',
>
> the Gobo-eiffel Users' Integrated Development Environment,
>
> from 'edp', the Eiffel Developers' Project. Although there a few
>
> classes [from other sources] that are LGPL, nearly all code that does
>
> not already derive from gobo, is EFFLv2 or MIT.
>
> I am very interested to hear about the introspection and debugger code, as
>
> I need such facilities for my intended future coding.
>

Description of introspection and debugger code may be really large.

Here, a short outline.
Descendant classes of ET_C_GENERATOR (extending the work of that class)
generate a description of the system to be compiled for use during runtime:
they extract information from objects of types
ET_DYNAMIC_SYSTEM, ET_DYNAMIC_TYPE etc. and puts
the information into objects of types ET_IN_SYSTEM, ET_IN_TYPE etc.
The resulting description is put onto C code (additional to the usual code)
using a special output mode of the persistence closure classes.
This code is C compiled, and the system description is available
during runtime (after a few adaptations at startup) as Eiffel objects.
More precisely, the root object of the description is provided by an
external
routine that fetches the object's address from C code, the other objects
are then recursively available by Eiffel calls on the root object.
The attachment contains the interface of an example class
to show what kind of information is available during runtime.

Introspection for persistence closure and debugging differs in the amount
of information in the system description. For example, the debugger needs
information about routines but the persistence closure does not.
Moreover, in case of debugging many calls to the debugger have been
inserted
into the "normal" code. The debugger then decides whether switching
into interactive mode (say a breakpoint has been reached)
or returning immediately to the caller.

Historically, the work started with the persistence closure.
I soon realized the introspection is a necessary prerequisite.
Then, having introspection, the idea was to utilize it also
for other purposes, e.g. for the "print" command of a debugger.
So, the debugger has been developed.

The approach to implement the persistence closure etc.
may be emphasized as follows:
The Eiffel compiler is written in Eiffel.
So, why not also implementing the Eiffel runtime system in Eiffel?

BTW, does your GC mark/seep or move/compress? In the former case,
object marking may also be interesting when building the persistence
closure.
Currently, the already seen objects are registered
in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient
because of the POINTER keys. Marking like the GC would be an
interesting alternative.

> One of the areas of the code generator that I intend to alter is the
> polymorphic
>
> dispatch implementation, for two reasons:
>
> Firstly for rapid re-compilation, I want to be able to generate an
> initial code package as
>
> an executable stub with dynamic library, where libraries register
> their routine addresses
>
> with the runtime, with subsequent partial re-compilation code
> generated as an additional
>
> dynamic library whose routines override the registered routines of the
> initial library. This
>
> requires that routine dispatch be done using a tree data structure, of
> some sort ...
>
> Secondly, I envisage that it should be possible, as with Java and
> other languages [mostly interpreted ..],
>
> to dynamically add class libraries to an executable system, where such
> libraries have been packaged,
>
> [compiled or otherwise verified against] to be compatible with classes
> already in the current system.
>
> That would also require that the dispatch to reachable routines be
> dynamically extendable.
>

This sounds very interesting. Extendibility of a program, dynamic

linking etc. seems to be
necessary for contemporary software (otherwise, Eiffel will never have a
chance).

>
> I am adapting my work on the Eiffel GUI toolkit derived from the
> Fox-toolkit to use the Vision2 interface,
>
> providing an X11/Win32 all Eiffel GUI Toolkit, which has its
> advantages ...
>
> I am working toward using LLVM as the basis for code generation for
> native Eiffel routines, initially to emit
>
> LLVM assembler with llvm-as invocation, and with the possibility
> [much] later of emitting machine code directly.
>
> I think using Git would assist in cooperation between myself and other
> gobo-eiffel contributors and developers.
>
> Regards,
>
> Howard Thomson
>
> --
>
> "Only two things are infinite, the universe and human stupidity,
>
> and I'm not sure about the former." -- Albert Einstein
>

--
Dr. Wolfgang Jansen
University of Potsdam, Germany
Institute of Computer Science
Tel: +49 331 / 977 3047
mailto: [hidden email]

IN_TYPE: Eiffel class interface

deferred class interface IN_TYPE

feature(s) from INTROSPECTION
   -- Constants

   Boolean_ident: INTEGER

   Character_ident: INTEGER

   Integer_ident: INTEGER

   Int8_ident: INTEGER

   Int16_ident: INTEGER

   Int32_ident: INTEGER

   Int64_ident: INTEGER

   Real_ident: INTEGER

   Double_ident: INTEGER

   Pointer_ident: INTEGER

   String_ident: INTEGER

   Foreign_flag: INTEGER

   Scoop_flag: INTEGER

   No_gc_flag: INTEGER

   Reference_flag: INTEGER

   Separate_flag: INTEGER

   Expanded_flag: INTEGER

   Living_flag: INTEGER

   Native_array_flag: INTEGER

   Basic_expanded_flag: INTEGER

   Capacity_index_flag: INTEGER

   Tuple_flag: INTEGER

   Agent_flag: INTEGER

   Missing_id_flag: INTEGER

   Bits_flag: INTEGER

   Deep_reference_flag: INTEGER

   Invariant_flag: INTEGER

   Generic_flag: INTEGER

   Sedb_flag: INTEGER

   Do_flag: INTEGER

   External_flag: INTEGER

   Once_flag: INTEGER

   Deferred_flag: INTEGER

   Frozen_flag: INTEGER

   Creation_flag: INTEGER

   Rescue_flag: INTEGER

   No_current_flag: INTEGER

   Side_effect_flag: INTEGER

   Inline_flag: INTEGER

   Attribute_flag: INTEGER

   Constant_flag: INTEGER

   Unique_flag: INTEGER

   Precomputable_flag: INTEGER

   Target: INTEGER

   Argument: INTEGER

   Old_value: INTEGER

   Local_var: INTEGER

   Result_value: INTEGER

   runtime_system: IN_RUNTIME_SYSTEM
      -- The actual IN_SYSTEM.

      ensure
         not_void: Result /= Void

feature(s) from COMPARABLE
   is_equal (other: like Current): BOOLEAN
      require
         other /= Void
      ensure
         generating_type = other.generating_type implies Result = other.is_equal(Current);
         trichotomy: Result = (not (Current < other) and not (other < Current))

   infix "<" (other: IN_TYPE): BOOLEAN
      -- Comparison by ident.

      require
         other_exists: other /= Void
      ensure
         asymmetric: Result implies not (other < Current)

   infix "<=" (other: like Current): BOOLEAN
      -- Is Current less than or equal other?

      require
         other_exists: other /= Void
      ensure
         definition: Result = (Current < other or is_equal(other))

   infix ">" (other: like Current): BOOLEAN
      -- Is Current strictly greater than other?

      require
         other_exists: other /= Void
      ensure
         definition: Result = (other < Current)

   infix ">=" (other: like Current): BOOLEAN
      -- Is Current greater than or equal than other?

      require
         other_exists: other /= Void
      ensure
         definition: Result = (other <= Current)

   in_range (lower, upper: like Current): BOOLEAN
      -- Return true if Current is in range [lower..upper]

      ensure
         Result = (Current >= lower and Current <= upper)

   compare (other: like Current): INTEGER
      -- If current object equal to other, 0
      -- if smaller,  -1; if greater, 1.

      require
         other_exists: other /= Void
      ensure
         equal_zero: Result = 0 = is_equal(other);
         smaller_negative: Result = -1 = (Current < other);
         greater_positive: Result = 1 = (Current > other)

   three_way_comparison (other: like Current): INTEGER
      -- If current object equal to other, 0
      -- if smaller,  -1; if greater, 1.

      require
         other_exists: other /= Void
      ensure
         equal_zero: Result = 0 = is_equal(other);
         smaller_negative: Result = -1 = (Current < other);
         greater_positive: Result = 1 = (Current > other)

   min (other: like Current): like Current
      -- Minimum of Current and other.

      require
         other /= Void
      ensure
         Result <= Current and then Result <= other;
         compare(Result) = 0 or else other.compare(Result) = 0

   max (other: like Current): like Current
      -- Maximum of Current and other.

      require
         other /= Void
      ensure
         Result >= Current and then Result >= other;
         compare(Result) = 0 or else other.compare(Result) = 0

feature(s) from HASHABLE
   hash_code: INTEGER
      -- The hash-code value of Current.

      ensure
         good_hash_value: Result >= 0

feature(s) from GENERAL
   -- Access:

   generating_type: STRING
      -- Name of current object's generating type (type of
      -- which it is a direct instance).


   generator: STRING
      -- Name of current object's generating class (base class
      -- of the type of which it is a direct instance).


   stripped (other: GENERAL): like other
      -- Newly created object with fields copied from current object,
      -- but limited to attributes of type of other.

      require
         conformance: conforms_to(other)
      ensure
         stripped_to_other: Result.same_dynamic_type(other)

feature(s) from GENERAL
   -- Status report:

   conforms_to (other: GENERAL): BOOLEAN
      -- Is dynamic type of Current a descendant of dynamic type of
      -- other ?
      --
      -- Note: because of automatic conversion from expanded to reference
      -- type when passing argument other, do not expect a correct
      -- behavior with  expanded types.

      require
         not is_expanded_type;
         other_not_void: other /= Void

   same_dynamic_type (other: like Current): BOOLEAN
      -- Is the dynamic type of Current identical to the dynamic type 
      -- of other?


feature(s) from GENERAL
   -- Comparison:

   equal (some: ANY; other: like some): BOOLEAN
      -- Are some and other both Void or attached to objects 
      -- considered equal ?

      ensure
         symmetric: Result implies equal(other,some)

   standard_equal (some: ANY; other: like some): BOOLEAN
      -- Are some and other both Void or attached to
      -- field-by-field objects of the same type ?
      -- Always use the default object comparison criterion.

      ensure
         definition: Result = (some = Void and other = Void) or else some /= Void and other /= Void and then some.standard_is_equal(other)

   standard_is_equal (other: like Current): BOOLEAN
      -- Are Current and other field-by-field identical?

      require
         other /= Void
      ensure
         same_dynamic_type(other) implies Result = other.standard_is_equal(Current)

feature(s) from GENERAL
   -- Deep Comparison:

   deep_equal (some: ANY; other: like some): BOOLEAN
      -- Are some and other either both Void or attached to
      -- recursively isomorphic object structures ?

      ensure
         shallow_implies_deep: standard_equal(some,other) implies Result

   is_deep_equal (other: like Current): BOOLEAN
      -- Is Current recursively isomorph with other ?

      require
         other_not_void: other /= Void

feature(s) from GENERAL
   -- Duplication:

   clone (other: ANY): like other
      -- When argument other is Void, return Void otherwise 
      -- return other.twin.

      ensure
         equal: equal(Result,other)

   twin: like Current
      -- Return a new object with the dynamic type of Current.
      -- Before being returned, the new object is initialized using
      -- feature copy (Current is passed as the argument).
      -- Thus, when feature copy of GENERAL is not redefined,
      -- twin has exactly the same behaviour as standard_twin.

      ensure
         equal: Result.is_equal(Current)

   copy (other: like Current)
      require
         same_dynamic_type(other)
      ensure
         is_equal(other)

   standard_clone (other: ANY): like other
      -- Void if other is Void; otherwise new object
      -- field-by-field identical to other.
      -- Always use the default copying semantics.

      ensure
         equal: standard_equal(Result,other)

   standard_twin: like Current
      -- Return a new object with the dynamic type of Current.
      -- Before being returned, the new object is initialized using
      -- feature standard_copy (Current is passed as the argument).


   standard_copy (other: like Current)
      -- Copy every field of other onto corresponding field of
      -- current object.

      require
         other_not_void: other /= Void
      ensure
         standard_is_equal(other)

   box: REFERENCE[like Current]
      -- Create a REFERENCe object referring to Current 


feature(s) from GENERAL
   -- Deep Duplication:

   deep_clone (other: ANY): like other
      -- When argument other is Void, return Void
      -- otherwise return other.deep_twin.

      ensure
         deep_equal(other,Result)

   deep_twin: like Current
      -- Return a new object with the dynamic type of Current.
      -- The new object structure is recursively duplicated from the one
      -- attached to Current.


feature(s) from GENERAL
   -- Basic operations:

   default: like Current
      -- Default value of entities declared with the Current type.
      -- Hence, the Result is Void for all reference types and, as another 
      -- example, the Result is 0 for an INTEGER expression.


   is_default: BOOLEAN
      -- Is the Current object in the default state?
      -- For example, when this feature is applied on an INTEGER, the 
      -- Result is True only when the INTEGER is 0.  If not redefined, the 
      -- Result is always False for a reference expression. Actually, this 
      -- is_default predicate may be useful for user-defined expanded 
      -- objects stored in collection (see all_default of class 
      -- COLLECTION).


   default_pointer: POINTER
      -- Default value of type POINTER (avoid the need to write p.default 
      -- for some p of type POINTER).

      ensure
         Result = Result.default

   default_rescue
      -- Handle exception if no Rescue clause. (Default: do nothing.)


feature(s) from GENERAL
   -- Input and Output:

   io: STD_INPUT_OUTPUT
      -- Handle to standard file setup.
      -- To use the standard input/output file.
      -- Has type STD_FILES in ELKS 95.

      ensure
         Result /= Void

   std_input: STD_INPUT
      -- To use the standard input file.


   std_output: STD_OUTPUT
      -- To use the standard output file.


   std_error: STD_ERROR
      -- To use the standard error file.


feature(s) from GENERAL
   -- Object Printing:

   print (some: GENERAL)
      -- Write terse external representation of some on
      -- standard_output.
      -- To customize printing, one may redefine
      -- fill_tagged_out_memory or out_in_tagged_out_memory (see
      -- for example how it works in class COLLECTION).
      -- Not frozen in ELKS 95.


   print_on (file: OUTPUT_STREAM)
      -- Default printing of current object on a file.
      -- One may redefine fill_tagged_out_memory or
      -- out_in_tagged_out_memory to adapt the behavior of
      -- print_on.
      --


   tagged_out: STRING
      -- New string containing printable representation of current
      -- object, each field preceded by its attribute name, a
      -- colon and a space.


   out: STRING

   out_in_tagged_out_memory
      -- Append terse printable represention of current object
      -- in tagged_out_memory.

      ensure
         not_cleared: tagged_out_memory.count >= old tagged_out_memory.count;
         append_only: (old tagged_out_memory.twin).is_equal(tagged_out_memory.substring(1,old tagged_out_memory.count))

   tagged_out_memory: STRING

   fill_tagged_out_memory
      -- Append a viewable information in tagged_out_memory in
      -- order to affect the behavior of out, tagged_out, etc.


feature(s) from GENERAL
   -- Access to command-line arguments:

   argument_count: INTEGER
      -- Number of arguments given to command that started
      -- system execution (command name does not count).

      ensure
         Result >= 0

   argument (i: INTEGER): STRING
      -- i th argument of command that started system execution
      -- Gives the command name if i is 0.

      require
         i >= 0;
         i <= argument_count
      ensure
         Result /= Void

   command_arguments: FAST_ARRAY[STRING]
      -- Give acces to arguments command line including the
      -- command name at index 0.

      ensure
         not Result.is_empty

feature(s) from GENERAL
   -- SCOOP:

   available: BOOLEAN
      -- Wait the result (By Necessity [TM])
      -- Always return True
      -- (Meaningless in a non-SCOOP world)


feature(s) from GENERAL
   -- System calls and crashs:

   crash
      -- Print Run Time Stack and then exit with exit_failure_code.


   trace_switch (flag: BOOLEAN)
      -- May be used in combination with option "-sedb" of command
      -- compile_to_c (see compile_to_c documentation for details).


   sedb_breakpoint
      -- May be used in combination with option "-sedb" of command
      -- compile_to_c to set a breakpoint for sedb, the SmartEiffel debugger.


   die_with_code (code: INTEGER)
      -- Terminate execution with exit status code code.
      -- Do not print any message.
      -- Note: you can use predefined exit_success_code or
      -- exit_failure_code as well as another code you need.


   exit_success_code: INTEGER

   exit_failure_code: INTEGER

feature(s) from GENERAL
   -- Should not exist:

   not_yet_implemented

feature(s) from GENERAL
   -- For ELS Compatibility:

   id_object (id: INTEGER): ANY
      -- Object for which object_id has returned id
      -- Void if none.

      require
         id /= 0

   object_id: INTEGER
      -- Value identifying current reference object.

      require
         not is_expanded_type

feature(s) from GENERAL
   -- The Guru section:

   to_pointer: POINTER
      -- This routine can be used only if the value of Current is really
      -- a memory address. (This is the case for all reference types and
      -- for the NATIVE_ARRAY type only.) Actually, this routine do
      -- nothing: the value of Current which is an address is returned
      -- unchanged. The compiler will emit a warning if you try to use
      -- to_pointer on some invalid type.


   is_expanded_type: BOOLEAN
      -- Target is not evaluated (Statically computed).
      -- Result is True if target static type is an expanded type.
      -- Useful for formal generic type.


   is_basic_expanded_type: BOOLEAN
      -- Target is not evaluated (Statically computed).
      -- Result is True if target static type is one of the
      -- following types: BOOLEAN, CHARACTER, INTEGER, REAL,
      -- DOUBLE or POINTER.

      ensure
         Result implies is_expanded_type

   object_size: INTEGER
      -- Gives the size of the current object at first level
      -- only (pointed-to sub-object are not concerned).
      -- The result is given in number of CHARACTER.


feature(s) from GENERAL
   -- Implementation of GENERAL (do not use directly):

   se_assigned_from (other: GENERAL): BOOLEAN
      -- To implement conforms_to (must only be called inside
      -- conforms_to because of VJRV rule).

      require
         not is_expanded_type

feature(s) from IN_BASE
   -- Access

   name: STRING
      ensure
         not_void: Result /= Void

feature(s) from IN_BASE
   -- Status

   has_name (s: STRING): BOOLEAN
      -- Is name equal to s when ignoring letter case?

      require
         not_void: s /= Void

   name_has_prefix (s: STRING): BOOLEAN
      -- Does name start with s when ignoring latter case?

      require
         not_void: s /= Void

feature(s) from IN_BASE
   -- Basic operation

   append_name (str: STRING)
      -- Append name to s.

      require
         not_void: str /= Void
      ensure
         appended: str.has_suffix(name)

feature(s) from IN_BASE
   -- COMPARABLE

   compare_name (nm: STRING): INTEGER
      -- Compare Current's name with nm in the sense 
      -- of three_way_comparison. 


   same_name (other: IN_BASE): BOOLEAN
      -- Have Current and other the same name?


feature(s) from PLATFORM
   -- Maximum:

   Maximum_character_code: INTEGER_16
      -- Largest supported code for CHARACTER values.

      ensure
         meaningful: Result >= 127

   Maximum_integer_8: INTEGER_8
      -- Largest supported value of type INTEGER_8.


   Maximum_integer_16: INTEGER_16
      -- Largest supported value of type INTEGER_16.


   Maximum_integer: INTEGER
      -- Largest supported value of type INTEGER/INTEGER_32.


   Maximum_integer_32: INTEGER
      -- Largest supported value of type INTEGER/INTEGER_32.


   Maximum_integer_64: INTEGER_64
      -- Largest supported value of type INTEGER_64.


   Maximum_real: REAL
      -- Largest supported value of type REAL.

      ensure
         meaningful: Result >= 0.0

   Maximum_double: DOUBLE
      -- Largest supported value of type DOUBLE.

      ensure
         meaningful: Result >= Maximum_real

feature(s) from PLATFORM
   -- Minimum:

   Minimum_character_code: INTEGER_16
      -- Smallest supported code for CHARACTER values.

      ensure
         meaningful: Result <= 0

   Minimum_integer_8: INTEGER_8
      -- Smallest supported value of type INTEGER_8.


   Minimum_integer_16: INTEGER_16
      -- Smallest supported value of type INTEGER_16.


   Minimum_integer: INTEGER
      -- Smallest supported value of type INTEGER/INTEGER_32.


   Minimum_integer_32: INTEGER
      -- Smallest supported value of type INTEGER/INTEGER_32.


   Minimum_integer_64: INTEGER_64
      -- Smallest supported value of type INTEGER_64.


   Minimum_double: DOUBLE
      -- Smallest supported value of type DOUBLE.

      ensure
         meaningful: Result <= 0.0

   Minimum_real: REAL
      -- Smallest supported value of type REAL.

      ensure
         meaningful: Result <= 0.0

feature(s) from PLATFORM
   -- Bits:

   Boolean_bits: INTEGER
      -- Number of bits in a value of type BOOLEAN.

      ensure
         meaningful: Result >= 1

   Character_bits: INTEGER
      -- Number of bits in a value of type CHARACTER.

      ensure
         meaningful: Result >= 1;
         large_enough: (2).to_integer_32 ^ Result >= Maximum_character_code

   Integer_bits: INTEGER
      -- Number of bits in a value of type INTEGER.

      ensure
         integer_definition: Result = 32

   Real_bits: INTEGER
      -- Number of bits in a value of type REAL.

      ensure
         meaningful: Result >= 1

   Double_bits: INTEGER
      -- Number of bits in a value of type DOUBLE.

      ensure
         meaningful: Result >= 1;
         meaningful: Result >= Real_bits

   Pointer_bits: INTEGER
      -- Number of bits in a value of type POINTER.


feature(s) from IN_TYPE
   -- Access

   ident: INTEGER
      -- System wide unique identifier.


   bit_count: INTEGER
      -- Number of bits if is a BIT_N type.


   base_class: IN_CLASS_TEXT
      -- Type descriptor of base type.


   generic_count: INTEGER
      -- Number of generics parameters.

      ensure
         not_negative: Result >= 0

   valid_generic (i: INTEGER): BOOLEAN
      ensure
         validity: Result = (0 <= i and then i < generic_count)

   generic_at (i: INTEGER): IN_TYPE
      -- Type of the i-th actual generic parameter. 

      require
         valid_index: valid_generic(i)
      ensure
         result_not_void: Result /= Void

   effector_count: INTEGER
      -- Number of Currents's effecting types. 

      ensure
         not_negative: Result >= 0

   valid_effector (i: INTEGER): BOOLEAN
      ensure
         validity: Result = (0 <= i and then i < effector_count)

   effector_at (i: INTEGER): IN_TYPE
      -- Type of i-th effective descentant.

      require
         valid: valid_effector(i)

   attribute_count: INTEGER
      -- Number of variable attributes.

      ensure
         not_negative: Result >= 0

   valid_attribute (i: INTEGER): BOOLEAN
      ensure
         validity: Result = (0 <= i and then i < attribute_count)

   attribute_at (i: INTEGER): IN_FIELD
      -- i-th variable attribute. 

      require
         valid_index: valid_attribute(i)
      ensure
         not_void: Result /= Void

   constant_count: INTEGER
      -- Number of constant attributes.

      ensure
         not_negative: Result >= 0

   valid_constant (i: INTEGER): BOOLEAN
      ensure
         validity: Result = (0 <= i and then i < constant_count)

   constant_at (i: INTEGER): IN_CONST[ANY]
      -- i-th constant attribute. 

      require
         valid_index: valid_constant(i)
      ensure
         not_void: Result /= Void

   routine_count: INTEGER
      -- Number of routines.

      ensure
         not_negative: Result >= 0

   valid_routine (i: INTEGER): BOOLEAN
      ensure
         validity: Result = (0 <= i and then i < routine_count)

   routine_at (i: INTEGER): IN_ROUTINE
      -- i-th routine.

      require
         valid_index: valid_routine(i)

   invariant_function: like routine_at
      -- Function computing the class invariant.


   has_bracket: BOOLEAN
      -- Has Current a bracket function?


   bracket: IN_ROUTINE
      -- The type's bracket function, if any.


feature(s) from IN_TYPE
   -- Status

   flags: INTEGER

   is_expanded: BOOLEAN

   is_basic_expanded: BOOLEAN
      ensure
         is_expanded: Result implies is_expanded

   is_reference: BOOLEAN

   is_separate: BOOLEAN

   is_none: BOOLEAN

   is_boolean: BOOLEAN

   is_character: BOOLEAN

   is_integer: BOOLEAN

   is_real: BOOLEAN

   is_double: BOOLEAN

   is_pointer: BOOLEAN

   is_char8: BOOLEAN

   is_char32: BOOLEAN

   is_int8: BOOLEAN

   is_int16: BOOLEAN

   is_int32: BOOLEAN

   is_int64: BOOLEAN

   is_nat8: BOOLEAN

   is_nat16: BOOLEAN

   is_nat32: BOOLEAN

   is_nat64: BOOLEAN

   is_bit_n: BOOLEAN

   is_string: BOOLEAN

   is_unicode: BOOLEAN

   is_normal: BOOLEAN

   is_special: BOOLEAN

   is_tuple: BOOLEAN

   is_agent: BOOLEAN

   is_living: BOOLEAN
      -- Is the type alive (i.e. can instances be created) ?


   is_actionable: BOOLEAN
      -- Does the type's base class inherit from PC_ACTIONABLE?


   has_invariant: BOOLEAN
      -- Does the type's base class define an invariant clause?


feature(s) from IN_TYPE
   -- Instance sizes

   instance_size: INTEGER
      -- Memory size (in bytes) of instances of the current type.


   boxed_size: INTEGER
      -- Memory size of boxed expanded instances. 


   field_size: INTEGER
      -- Memory size (in bytes) of objects within other objects.

      ensure
         not_negative: 0 <= Result;
         when_expanded: is_expanded implies Result = instance_size

   boxed_offset: INTEGER
      -- Offset of unboxed item within boxed object.


feature(s) from IN_TYPE
   -- Comparison

   less_by_name (other: IN_TYPE): BOOLEAN
      -- Comparison by name.


   conformance (other: IN_TYPE): INTEGER
      -- How good does Current conform to other?
      -- Result=0 means exact match, Result=Maximum_integer means no match,
      -- i.e. assignment like other_obj:=current_obj is not possible.

      require
         other_not_void: other /= Void
      ensure
         not_negative: Result >= 0

   conforms_to_type (other: IN_TYPE): BOOLEAN
      -- Does type described by Current conform to type
      -- described by other?

      require
         not_void: other /= Void

   does_effect (other: IN_TYPE): BOOLEAN
      -- Does type described by Current effect the type
      -- described by other?

      require
         not_void: other /= Void

feature(s) from IN_TYPE
   -- Searching

   attribute_by_name (nm: STRING): like attribute_at
      -- Currents attribute with name nm
      -- void if no such attribute exists.

      require
         nm_not_void: nm /= Void
      ensure
         when_found: Result /= Void implies Result.has_name(nm) and then attributes.has(Result)

   constant_by_name (nm: STRING): like constant_at
      -- Currents constant attribute with name nm
      -- void if no such constant exists.

      require
         nm_not_void: nm /= Void
      ensure
         when_found: Result /= Void implies Result.has_name(nm) and then constants.has(Result)

   routine_by_name (nm: STRING): like routine_at
      -- routine in Currents class with name nm
      -- void if no such routine exists.

      require
         name_not_void: nm /= Void
      ensure
         when_found: Result /= Void implies Result.has_name(nm) and then routines.has(Result)

   push_type (t: IN_TYPE)
      require
         not_void: t /= Void
      ensure
         type_stack_not_void: type_stack /= Void;
         stack_size: type_stack.count = old type_stack.count + 1

   top_type: IN_TYPE
      ensure
         on_top: Result = type_stack.item(type_stack.count - 1);
         stack_size: type_stack.count = old type_stack.count

   pop_types (n: INTEGER)
      -- Pop n types from the type_stack. 

      require
         not_negative: n >= 0
      ensure
         type_stack_size: type_stack.count = old type_stack.count - n

   routine_by_signature (res: IN_LOCAL; na: INTEGER; previous: like routine_at): like routine_at
      -- Routine in Currents class with na argument types
      -- (which have been pushed previously to the type_stack) 
      -- and result type res (Void in case of a procedure).
      -- Search strats after previous (Void for the first call).
      -- Result is the next routine found
      -- (or Void if no more such routines). 

      require
         res_not_void: res /= Void;
         na_not_negative: na >= 0

feature(s) from IN_TYPE
   -- Output

   append_indented (s: STRING; indent, indent_increment: INTEGER)
      -- Fill s by printable format of Current preceded by indent
      -- and closed by a new line character.

      require
         s_not_void: s /= Void;
         indent_not_negative: indent >= 0;
         increment_not_negative: indent_increment >= 0


invariant
   ident_not_negative: ident >= 0;
   base_class_not_void: base_class /= Void;
   instance_size_not_negative: instance_size >= 0;
   boxed_size_not_smaller_than_instance_size: boxed_size >= instance_size;

end of deferred IN_TYPE

Howard Thomson

Re: Git development

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Hi Wolfgang,

On Friday 14 August 2009, you wrote:

> The approach to implement the persistence closure etc.

> may be emphasized as follows:

> The Eiffel compiler is written in Eiffel.

> So, why not also implementing the Eiffel runtime system in Eiffel?

I considered writing the Eiffel GC substantially in Eiffel, and I may well transliterate much

of the new GC code into Eiffel at some point, once we have [or I understand ... !] some means

of either separately generating library code [with Gobo], or some means of ensuring that all

of the GC classes are 'in' the system; actually not too difficult ...

I think Gobo's ability to inline code needs to be enhanced before it makes sense to do that.

> BTW, does your GC mark/seep or move/compress? In the former case,

> object marking may also be interesting when building the persistence

> closure.

> Currently, the already seen objects are registered

> in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient

> because of the POINTER keys. Marking like the GC would be an

> interesting alternative.

It is currently a simple mark/sweep, non-moving, but precise collector, so

the ability to move / compact could be added later. Correctness is much

more important, and there are still some code generation changes that

need to be made to ensure that all references are visible to the GC at

any point where it may be invoked.

> > One of the areas of the code generator that I intend to alter is the

> > polymorphic

> >

> > dispatch implementation, for two reasons:

> >

> > Firstly for rapid re-compilation, I want to be able to generate an

> > initial code package as

> >

> > an executable stub with dynamic library, where libraries register

> > their routine addresses

> >

> > with the runtime, with subsequent partial re-compilation code

> > generated as an additional

> >

> > dynamic library whose routines override the registered routines of the

> > initial library. This

> >

> > requires that routine dispatch be done using a tree data structure, of

> > some sort ...

> >

> > Secondly, I envisage that it should be possible, as with Java and

> > other languages [mostly interpreted ..],

> >

> > to dynamically add class libraries to an executable system, where such

> > libraries have been packaged,

> >

> > [compiled or otherwise verified against] to be compatible with classes

> > already in the current system.

> >

> > That would also require that the dispatch to reachable routines be

> > dynamically extendable.

> >

> This sounds very interesting. Extendibility of a program, dynamic

> linking etc. seems to be

> necessary for contemporary software (otherwise, Eiffel will never have a

> chance).

> >

I think it is essential ...

Regards

Howard

"Only two things are infinite, the universe and human stupidity,

and I'm not sure about the former." -- Albert Einstein

Wolfgang Jansen

Re: Git development

Reply Threaded

Howard Thomson wrote:

>
> Hi Wolfgang,
>
> On Friday 14 August 2009, you wrote:
>
> >
>
> > The approach to implement the persistence closure etc.
>
> > may be emphasized as follows:
>
> > The Eiffel compiler is written in Eiffel.
>
> > So, why not also implementing the Eiffel runtime system in Eiffel?
>
> >
>
> I considered writing the Eiffel GC substantially in Eiffel, and I may
> well transliterate much
>
> of the new GC code into Eiffel at some point, once we have [or I
> understand ... !] some means
>
> of either separately generating library code [with Gobo], or some
> means of ensuring that all
>
> of the GC classes are 'in' the system; actually not too difficult ...
>
> I think Gobo's ability to inline code needs to be enhanced before it
> makes sense to do that.
>

May it help you to re-use my introspection code?
It sees all references on stack, all global references (i.e. values of
once functions)
and, starting on these references, all references on heap.
The debugger uses this for checkpointing.
A critical point in the GC case may be to make the things on stack
visible. In case of the debugger, making stack variables visible
is necessary for printing the variables, using their visibility
for checkpointing is a by-product. But additional code is needed
(run at most once per routine) to get the addresses. The additional code
may be considered too heavy for every days work.

--
Dr. Wolfgang Jansen
University of Potsdam, Germany
Institute of Computer Science
Tel: +49 331 / 977 3047
mailto: [hidden email]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Howard Thomson

Re: Git development

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Hi Wolfgang,

On Saturday 15 August 2009, you wrote:

> May it help you to re-use my introspection code?

> It sees all references on stack, all global references (i.e. values of

> once functions)

> and, starting on these references, all references on heap.

Yes, it would be useful [necessary ...] to ensure that there is one way to make

available, to both the GC and debugger, all relevant info.

The specific code generation case that I was referring to is where C code is generated

with two or more arguments to a routine [excluding Current], each of which is a memory-allocating

funtion that returns a reference [where the return value is the only extant reference], and therefore

the GC needs to have access to a value that is not a declared C variable.

In C terms:

void * f_allocate() {

/* This routine allocates memory [create ...] and may instigate a GC collection */

return(GC_alloc_memory(...));

}

void called_routine(void *a_Current, void *a1, void *a2) {

/* do something [not relevant] with arguments */

xxx = a1;

yyy = a2;

}

If the routine call:

called_routine(Current, f_allocate(), f_allocate());

occurs in the generated C code then the GC, if invoked from the f_allocate call that occurs second, then

the one and only reference to the memory returned by the first f_allocate call is only accessible via a

C compiler unnamed temporary.

Does your stack tracing code track, precisely, i.e. not conservatively, such compiler temporaries ?

Do you develop on Windows or Linux ?

If you want to look at [an earlier version of] my code, it is available at:

www.ashford-ht.vm.bytemark.co.uk as a compressed tar download, admittedly more suitable for Linux developers ...

Regards,

Howard

> The debugger uses this for checkpointing.

> A critical point in the GC case may be to make the things on stack

> visible. In case of the debugger, making stack variables visible

> is necessary for printing the variables, using their visibility

> for checkpointing is a by-product. But additional code is needed

> (run at most once per routine) to get the addresses. The additional code

> may be considered too heavy for every days work.

Howard Thomson

"Only two things are infinite, the universe and human stupidity,

and I'm not sure about the former." -- Albert Einstein

Wolfgang Jansen

Re: Git development

Reply Threaded

Hi Howard,

> Hi Wolfgang,
>
> On Saturday 15 August 2009, you wrote:
>
> > May it help you to re-use my introspection code?
>
> > It sees all references on stack, all global references (i.e. values of
>
> > once functions)
>
> > and, starting on these references, all references on heap.
>
> Yes, it would be useful [necessary ...] to ensure that there is one
> way to make
>
> available, to both the GC and debugger, all relevant info.
>
> The specific code generation case that I was referring to is where C
> code is generated
>
> with two or more arguments to a routine [excluding Current], each of
> which is a memory-allocating
>
> funtion that returns a reference [where the return value is the only
> extant reference], and therefore
>
> the GC needs to have access to a value that is not a declared C variable.
>
> In C terms:
>
> void * f_allocate() {
>
> /* This routine allocates memory [create ...] and may instigate a GC
> collection */
>
> return(GC_alloc_memory(...));
>
> }
>
> void called_routine(void *a_Current, void *a1, void *a2) {
>
> /* do something [not relevant] with arguments */
>
> xxx = a1;
>
> yyy = a2;
>
> }
>
> If the routine call:
>
> called_routine(Current, f_allocate(), f_allocate());
>
> occurs in the generated C code then the GC, if invoked from the
> f_allocate call that occurs second, then
>
> the one and only reference to the memory returned by the first
> f_allocate call is only accessible via a
>
> C compiler unnamed temporary.
>
> Does your stack tracing code track, precisely, i.e. not
> conservatively, such compiler temporaries ?
>

No yet. Printing arguments and local variables does not need this
and checkpointing not either since the call to the debugger
happens, currently, always before an instruction, in particular
before the temporaries are set to new values. In other words, in case of

x := f(g(y))

there is one break at the beginning of the line but not before
the calls to functions `f' and `g'.
Things will be different if the debugger is called also before
function calls (planned in future). The function arguments are often
temporaries and need to be stored by checkpointing
(or checkpointing must be allowed in front of instructions only).

Anyway, I will think about the problem how to extract the information
about temporaries from the compiler classes (putting the information
to introspection classes and making it available during runtime is easy).
>
> Do you develop on Windows or Linux ?
>
On Sun Solaris, a Unix variant.
>
> If you want to look at [an earlier version of] my code, it is
> available at:
>
> www.ashford-ht.vm.bytemark.co.uk as a compressed tar download,
> admittedly more suitable for Linux developers ...
>
>
Thanks, I got the sources and the Linux version.

WJ

PS:
Below is the (slightly simplified) initial part of C code of STRING_8.append
as generated for debugging.

1 void T17f42(GE_ZS* ac, T0* C, T0* a1)
2 {
3 GE_ZS tc = {0,0,ac};
4 T1 t1;
5 T6 t2;
6 T0* t3;
7 T6 l1 = 0;
8 T6 l2 = 0;
9 T6 l3 = 0;
10 static T0* f = (T0*)0;
11 if (!f) {
12 T82f77(&tc, (T0*)GE_zrts, 17, 1)
13 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&C-(size_t)&tc, 0)
14 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&a1-(size_t)&tc, 1)
15 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l3-(size_t)&tc, 3)
16 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l2-(size_t)&tc, 4)
17 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l1-(size_t)&tc, 5)
18 }
19 tc.routine = f;
20 GE_zpos(&tc, 655, 0);
21 l2 = (((T17*)(GE_void(a1)))->a2);
22 ....
23 }

Line 1 : `ac' is the stack descriptor of the caller;
type GE_ZS is a C struct, not Eiffel
Line 3 : `tc' is the stack descriptor of the current routine
(`ac', `tc' are re-used from GOBO's code tracing)
Line 10: `f' is a pointer to an IN_ROUTINE object
Line 12: `f' is set by the object describing the current routine;
GE_zrts is the root introspection object (global variable)
Line 13 .. 17: offsets of the local variables relative to `tc' are set
in `f';
more lines are needed if temporary variables are of interest.
Line 19: set `f' in stack descriptor
Line 20: call debugger with stack descriptor, source line number 655
and reason of break

Other uses of routine descriptors (say by GC) will need the additional code
of lines 1, 3, 10, 12, 13 .. 17 (as many as needed), 19.
After that `tc' is ready and detailed information may be extracted
(as done by the debugger in line 20).

Instead of the additional argument `ac' a global pointer
to the top most stack descriptor might be used.

--
Dr. Wolfgang Jansen
University of Potsdam, Germany
Institute of Computer Science
Tel: +49 331 / 977 3047
mailto: [hidden email]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jann Röder-2

XML generator

Reply Threaded

Hello,
I have two problems with the gobo XML library:
1. {XM_NAMESPACE}.make seems to miss the precondition a_prefix /= Void ,
or there is a bug in {XM_XMLNS_GENERATOR}.on_attribute line "elseif
is_implicit (a_prefix)" since if a_prefix is Void a Void call will occur
in is_implicit

2. How can I influence the output generated by the pretty printer? For
example I'd like it not to add the prefix to every tag and attribute.

<tag id="2"> instead of <prefix:tag prefix:id="2">

Also I'd like it to use the short form for tags when possible:

<tag id="2"/> instead of <tag id="2"></tag>

Is this possible somehow or will I have to write my own pretty printer?

Thanks,
Jann

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Colin Paul Adams

Re: XML generator

Reply Threaded

>>>>> "Jann" == Jann Röder <[hidden email]> writes:

Jann> Hello, I have two problems with the gobo XML library:
Jann> 1. {XM_NAMESPACE}.make seems to miss the precondition
Jann> a_prefix /= Void , or there is a bug in
Jann> {XM_XMLNS_GENERATOR}.on_attribute line "elseif is_implicit
Jann> (a_prefix)" since if a_prefix is Void a Void call will occur
Jann> in is_implicit

I'll leave that for Franck to answer.

Jann> 2. How can I influence the output generated by the pretty
Jann> printer? For example I'd like it not to add the prefix to
Jann> every tag and attribute.

Jann> <tag id="2"> instead of <prefix:tag prefix:id="2">

Jann> Also I'd like it to use the short form for tags when
Jann> possible:

Jann> <tag id="2"/> instead of <tag id="2"></tag>

Jann> Is this possible somehow or will I have to write my own
Jann> pretty printer?

There is an XSLT-inspired (*) serializer that you can use if you want full
control over the output. See
http://www.gobosoft.com/eiffel/gobo/xml/xslt/xslt_serializer.html .

It's actually the serializer used by the Gobo XSLT library, but you do
not need to run an XSLT transformation to use it.
--
Colin Adams
Preston Lancashire

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Colin Paul Adams

Re: XML generator

Reply Threaded

In reply to this post by Jann Röder-2

>>>>> "Jann" == Jann Röder <[hidden email]> writes:

Jann> For example I'd like it not to add the prefix to
Jann> every tag and attribute.

Jann> <tag id="2"> instead of <prefix:tag prefix:id="2">

The two are not equivalent, as attributes are never in the default
namespace. Instead they are in the per-element namespace. I.e. in the
first case, id is in a different namespace from tag (assuming you have
a default namespace declaration in scope). In the second case, they
are both in the same namespace.
--
Colin Adams
Preston Lancashire

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jann Röder-2

Re: XML generator

Reply Threaded

Colin Paul Adams schrieb:

>>>>>> "Jann" == Jann Röder <[hidden email]> writes:
>
> Jann> For example I'd like it not to add the prefix to
> Jann> every tag and attribute.
>
> Jann> <tag id="2"> instead of <prefix:tag prefix:id="2">
>
> The two are not equivalent, as attributes are never in the default
> namespace. Instead they are in the per-element namespace. I.e. in the
> first case, id is in a different namespace from tag (assuming you have
> a default namespace declaration in scope). In the second case, they
> are both in the same namespace.

Ok got it. I just put everything in the same namespace, since the
namespace argument must not be Void. Now I put everything except the
root node in the default namespace and the prefixes disappeared. It
would be nice if you could pass Void as the namespace argument if you
want to put the element into the default namespace.

Jann

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jann Röder-2

Patch for XML pretty printer

Reply Threaded

In reply to this post by Colin Paul Adams

Hi,
I wrote a patch for the XML pretty printer to make it use the short form
for tags that don't have content or children, i.e. <tag/> instead of
<tag></tag> .
See attachment.

I also noticed, that the pretty printer does not output the XML
descriptor (this: <?xml version="1.0" ?>). I'm not sure what's the best
way to fix this. Simply adding code in the on_xml_descriptor feature
doesn't work because it is never called, or I don't know what to do to
have it called.

Anyway in the meantime I'd be glad about some feedback regarding my patch.

Jann

Index: xm_indent_pretty_print_filter.e
===================================================================
--- xm_indent_pretty_print_filter.e (revision 6665)
+++ xm_indent_pretty_print_filter.e (working copy)
@@ -70,6 +70,8 @@
do
check space_preserved_not_void: space_preserved /= Void end

+ flush_close_tag_buffer
+
if not has_content then
if is_root then
is_root := False
@@ -105,14 +107,18 @@
do
depth := depth - 1

- if not has_content then
- output_indent_new_line
- output_indent
+ if last_call_was_start_tag_finish then
+ Precursor (a_namespace, a_prefix, a_local_part)
+ else
+ if not has_content then
+ output_indent_new_line
+ output_indent
+ end
+
+ Precursor (a_namespace, a_prefix, a_local_part)
end
+
has_content := False
-
- Precursor (a_namespace, a_prefix, a_local_part)
-
space_preserved.remove
end

Index: xm_pretty_print_filter.e
===================================================================
--- xm_pretty_print_filter.e (revision 6665)
+++ xm_pretty_print_filter.e (working copy)
@@ -45,6 +45,8 @@
output_constant (Space_s)
output (a_content)
output_constant (Pi_end)
+
+ last_call_was_start_tag_finish := False
Precursor (a_name, a_content)
end

@@ -54,6 +56,8 @@
output_constant (Comment_start)
output (a_content)
output_constant (Comment_end)
+
+ last_call_was_start_tag_finish := False
Precursor (a_content)
end

@@ -62,36 +66,53 @@
on_start_tag (a_namespace: STRING; a_prefix: STRING; a_local_part: STRING) is
-- Print start of start tag.
do
+ flush_close_tag_buffer
+
output_constant (Stag_start)
output_name (a_prefix, a_local_part)
+
+ last_call_was_start_tag_finish := False
Precursor (a_namespace, a_prefix, a_local_part)
end

on_attribute (a_namespace: STRING; a_prefix: STRING; a_local_part: STRING; a_value: STRING) is
-- Print attribute.
do
+ flush_close_tag_buffer
+
output_constant (Space_s)
output_name (a_prefix, a_local_part)
output_constant (Eq_s)
output_constant (Quot_s)
output_quote_escaped (a_value)
output_constant (Quot_s)
+
+ last_call_was_start_tag_finish := False
Precursor (a_namespace, a_prefix, a_local_part, a_value)
end

on_start_tag_finish is
-- Print end of start tag.
do
- output_constant (Stag_end)
+ close_tag_buffered := True
+
+ last_call_was_start_tag_finish := True
Precursor
end

on_end_tag (a_namespace: STRING; a_prefix: STRING; a_local_part: STRING) is
-- Print end tag.
do
- output_constant (Etag_start)
- output_name (a_prefix, a_local_part)
- output_constant (Etag_end)
+ if last_call_was_start_tag_finish then
+ output_constant (emptytag_end)
+ close_tag_buffered := False
+ else
+ output_constant (Etag_start)
+ output_name (a_prefix, a_local_part)
+ output_constant (Etag_end)
+ end
+
+ last_call_was_start_tag_finish := False
Precursor (a_namespace, a_prefix, a_local_part)
end

@@ -102,10 +123,29 @@
-- NOT atomic: successive content may be different.
-- Default: forward event to 'next'.
do
+ flush_close_tag_buffer
+
output_escaped (a_content)
+
+ last_call_was_start_tag_finish := False
Precursor (a_content)
end

+feature {NONE} -- Implementation
+
+ last_call_was_start_tag_finish: BOOLEAN
+
+ close_tag_buffered: BOOLEAN
+
+ flush_close_tag_buffer is
+ -- Output the buffered close tag, if any
+ do
+ if close_tag_buffered then
+ output_constant (stag_end)
+ close_tag_buffered := False
+ end
+ end
+
feature {NONE} -- Escaped

is_escaped (a_char: INTEGER): BOOLEAN is

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Eric Bezault

Re: Patch for XML pretty printer

Reply Threaded

Hi Jann,

Jann Röder wrote:

> I wrote a patch for the XML pretty printer to make it use the short form
> for tags that don't have content or children, i.e. <tag/> instead of
> <tag></tag> .
> See attachment.
>
> I also noticed, that the pretty printer does not output the XML
> descriptor (this: <?xml version="1.0" ?>). I'm not sure what's the best
> way to fix this. Simply adding code in the on_xml_descriptor feature
> doesn't work because it is never called, or I don't know what to do to
> have it called.
>
> Anyway in the meantime I'd be glad about some feedback regarding my patch.

It may take a few days before your patch makes it way in the
repository because I'm currently converting the repository to
Git.

I'll let XML experts give feedback on your patch if they have something
to say. But in the meantime, can you please add header comments to the
features `last_call_was_start_tag_finish' and `close_tag_buffered'?
Thanks.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Colin Adams-3

Re: Patch for XML pretty printer

Reply Threaded

In reply to this post by Jann Röder-2

I would say this might break existing programs (if anyone is using
this to write legacy xhtml, for instance, for sending to old
browsers). Perhaps consult on gobo-users list first?

2009/9/3 Jann Röder <[hidden email]>:

> Hi,
> I wrote a patch for the XML pretty printer to make it use the short form for
> tags that don't have content or children, i.e. <tag/> instead of <tag></tag>
> .
> See attachment.
>
> I also noticed, that the pretty printer does not output the XML descriptor
> (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix
> this. Simply adding code in the on_xml_descriptor feature doesn't work
> because it is never called, or I don't know what to do to have it called.
>
> Anyway in the meantime I'd be glad about some feedback regarding my patch.
>
> Jann
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gobo-eiffel-develop mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>

--
Colin Adams
Preston,
Lancashire,
ENGLAND

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jocelyn.Fiat

Re: Patch for XML pretty printer

Reply Threaded

I haven't looked at the patch, but it might be easy to support both behavior
with short tag <foo/> and <foo></foo> using a boolean attribute, or
flag for the executable.

This way, this won't break existing programs

Colin Adams wrote:

> I would say this might break existing programs (if anyone is using
> this to write legacy xhtml, for instance, for sending to old
> browsers). Perhaps consult on gobo-users list first?
>
> 2009/9/3 Jann Röder <[hidden email]>:
>
>> Hi,
>> I wrote a patch for the XML pretty printer to make it use the short form for
>> tags that don't have content or children, i.e. <tag/> instead of <tag></tag>
>> .
>> See attachment.
>>
>> I also noticed, that the pretty printer does not output the XML descriptor
>> (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix
>> this. Simply adding code in the on_xml_descriptor feature doesn't work
>> because it is never called, or I don't know what to do to have it called.
>>
>> Anyway in the meantime I'd be glad about some feedback regarding my patch.
>>
>> Jann
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>
>>
>>
>
>
>
>

Eric Bezault

Re: Patch for XML pretty printer

Reply Threaded

Jocelyn wrote:
> I haven't looked at the patch, but it might be easy to support both behavior
> with short tag <foo/> and <foo></foo> using a boolean attribute, or
> flag for the executable.
>
> This way, this won't break existing programs

Either that, or write a descendant of the pretty-printer class
and let dynamic binding use one or the other form.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Jann Röder-2

Re: Patch for XML pretty printer

Reply Threaded

Ok,
I updated my patch with better feature names and comments and I made the
use of "empty element tags" optional, disabled by default.

Jann

PS: Can anyone comment on the XML declaration issue?

Eric Bezault schrieb:

> Jocelyn wrote:
>> I haven't looked at the patch, but it might be easy to support both behavior
>> with short tag <foo/> and <foo></foo> using a boolean attribute, or
>> flag for the executable.
>>
>> This way, this won't break existing programs
>
> Either that, or write a descendant of the pretty-printer class
> and let dynamic binding use one or the other form.
>

Index: xm_indent_pretty_print_filter.e
===================================================================
--- xm_indent_pretty_print_filter.e (revision 6665)
+++ xm_indent_pretty_print_filter.e (working copy)
@@ -70,6 +70,8 @@
do
check space_preserved_not_void: space_preserved /= Void end

+ flush_pending_tag_end
+
if not has_content then
if is_root then
is_root := False
@@ -105,14 +107,18 @@
do
depth := depth - 1

- if not has_content then
- output_indent_new_line
- output_indent
+ if last_call_was_start_tag_finish and empty_element_tags_enabled then
+ Precursor (a_namespace, a_prefix, a_local_part)
+ else
+ if not has_content then
+ output_indent_new_line
+ output_indent
+ end
+
+ Precursor (a_namespace, a_prefix, a_local_part)
end
+
has_content := False
-
- Precursor (a_namespace, a_prefix, a_local_part)
-
space_preserved.remove
end

Index: xm_pretty_print_filter.e
===================================================================
--- xm_pretty_print_filter.e (revision 6665)
+++ xm_pretty_print_filter.e (working copy)
@@ -45,6 +45,8 @@
output_constant (Space_s)
output (a_content)
output_constant (Pi_end)
+
+ last_call_was_start_tag_finish := False
Precursor (a_name, a_content)
end

@@ -54,6 +56,8 @@
output_constant (Comment_start)
output (a_content)
output_constant (Comment_end)
+
+ last_call_was_start_tag_finish := False
Precursor (a_content)
end

@@ -62,36 +66,57 @@
on_start_tag (a_namespace: STRING; a_prefix: STRING; a_local_part: STRING) is
-- Print start of start tag.
do
+ flush_pending_tag_end
+
output_constant (Stag_start)
output_name (a_prefix, a_local_part)
+
+ last_call_was_start_tag_finish := False
Precursor (a_namespace, a_prefix, a_local_part)
end

on_attribute (a_namespace: STRING; a_prefix: STRING; a_local_part: STRING; a_value: STRING) is
-- Print attribute.
do
+ flush_pending_tag_end
+
output_constant (Space_s)
output_name (a_prefix, a_local_part)
output_constant (Eq_s)
output_constant (Quot_s)
output_quote_escaped (a_value)
output_constant (Quot_s)
+
+ last_call_was_start_tag_finish := False
Precursor (a_namespace, a_prefix, a_local_part, a_value)
end

on_start_tag_finish is
-- Print end of start tag.
do
- output_constant (Stag_end)
+ if empty_element_tags_enabled then
+ is_tag_end_pending := True
+ else
+ output_constant (stag_end)
+ end
+ last_call_was_start_tag_finish := True
+
Precursor
end

on_end_tag (a_namespace: STRING; a_prefix: STRING; a_local_part: STRING) is
-- Print end tag.
do
- output_constant (Etag_start)
- output_name (a_prefix, a_local_part)
- output_constant (Etag_end)
+ if last_call_was_start_tag_finish and empty_element_tags_enabled then
+ output_constant (emptytag_end)
+ is_tag_end_pending := False
+ else
+ output_constant (Etag_start)
+ output_name (a_prefix, a_local_part)
+ output_constant (Etag_end)
+ end
+
+ last_call_was_start_tag_finish := False
Precursor (a_namespace, a_prefix, a_local_part)
end

@@ -102,10 +127,49 @@
-- NOT atomic: successive content may be different.
-- Default: forward event to 'next'.
do
+ flush_pending_tag_end
+
output_escaped (a_content)
+
+ last_call_was_start_tag_finish := False
Precursor (a_content)
end

+feature -- Settings
+
+ empty_element_tags_enabled: BOOLEAN
+ -- Do we use empty element tags
+ -- i.e. <tag/> instead of <tag><tag/>
+
+ enable_empty_element_tags is
+ -- Use empty element tags
+ do
+ empty_element_tags_enabled := True
+ end
+
+ disable_empty_element_tags is
+ -- Do not use empty element tags
+ do
+ empty_element_tags_enabled := False
+ end
+
+feature {NONE} -- Implementation
+
+ last_call_was_start_tag_finish: BOOLEAN
+ -- Was the last `on_*' feature called `on_start_tag_finished' ?
+
+ is_tag_end_pending: BOOLEAN
+ -- Do we have a pending ">" or "/>" to be written ?
+
+ flush_pending_tag_end is
+ -- Output the pending tag end, if any
+ do
+ if is_tag_end_pending then
+ output_constant (stag_end)
+ is_tag_end_pending := False
+ end
+ end
+
feature {NONE} -- Escaped

is_escaped (a_char: INTEGER): BOOLEAN is

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Colin Adams-3

Re: Patch for XML pretty printer

Reply Threaded

2009/9/3 Jann Röder <[hidden email]>:

>
> PS: Can anyone comment on the XML declaration issue?
>

I discussed it with Franck yesterday.
The issue is with the encoding. I was claiming that as he is writing
STRINGs, then the XML declaration is required, because the encoding
will be iso8859-1, but he said the actual serialization depends upon
what XM_OUTPUT does down the line. Therefore the problem is difficult.

The best way is not to use this pretty printer for serializing XML -
really it's only a debug tool. The XSLT serializer should be used for
serializing output (note this does not mean you have to run XSLT).
--
Colin Adams
Preston,
Lancashire,
ENGLAND

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

1 2