gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Geant

[Colin P. A. <co...@co...>]

I just happened to notice today that there is a GEANT URN scheme
registered - RFC 4926.

In this case GEANT stands for Consortium of European Academic and
Research Networks (don't ask me how that is).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Bug reports for geant in the Bug Tracker

[Sven E. <sve...@we...>]

Eric Bezault wrote:

> In case you are not aware of them yet, there are some issues
> assigned to you in the Tracker:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937
> https://sourceforge.net/tracker/index.php?func=detail&aid=1882794&group_id=24591&atid=381937
> 

The first one:

  https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937

should be fixed now. I replaced the call to routine `string_tokens' with a `ST_SPLITTER.split_greedy' call.
Although this is a bug fix it is possible that it break scripts which made use or worked around this behavior.
I will add a note to History.txt.

- Sven

Re: [gobo-eiffel-develop] Bug reports for geant in the Bug Tracker

[Sven E. <sve...@we...>]

Eric Bezault wrote:
> You can try to compile in non-finalized mode:
> 
>   geant compile_debug_ge
> 
> It will compile the generated C code without the -O2 option,
> which might speed up the C compilation.
> 

That's much better. Thank you.

- Sven

Re: [gobo-eiffel-develop] Bug reports for geant in the Bug Tracker

[Eric B. <er...@go...>]

Sven Ehrke wrote:
> I will have a look at them. Just one (different) question: When I was compiling geant for example
> just recently (on linux) using gcc and gec it took me about 5-6 minutes on my quite dated
> computer. Then I downloaded ISE Eiffel 6.1 but noticed that 1G of memory is recommended (I have
> only 512MB) and when I tried to install it I noticed that the space on my windows drive does
> not have enough free space anymore to complete the installation (although selected a different drive
> for the installation). I soon have to buy a new computer
> anyway and then these problems should be gone but do you have a recommendation on how to get a speed
> improvement for compilation in the meanwhile?

You can try to compile in non-finalized mode:

   geant compile_debug_ge

It will compile the generated C code without the -O2 option,
which might speed up the C compilation.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Bug reports for geant in the Bug Tracker

[Sven E. <sve...@we...>]

Eric Bezault wrote:
> In case you are not aware of them yet, there are some issues
> assigned to you in the Tracker:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937
> https://sourceforge.net/tracker/index.php?func=detail&aid=1882794&group_id=24591&atid=381937
> 

Hi Eric,

I will have a look at them. Just one (different) question: When I was compiling geant for example
just recently (on linux) using gcc and gec it took me about 5-6 minutes on my quite dated
computer. Then I downloaded ISE Eiffel 6.1 but noticed that 1G of memory is recommended (I have
only 512MB) and when I tried to install it I noticed that the space on my windows drive does
not have enough free space anymore to complete the installation (although selected a different drive
for the installation). I soon have to buy a new computer
anyway and then these problems should be gone but do you have a recommendation on how to get a speed
improvement for compilation in the meanwhile?
My next try will be to download the linux version of ISE Eiffel and see how that works.

- Sven

[gobo-eiffel-develop] Bug reports for geant in the Bug Tracker

[Eric B. <er...@go...>]

Sven Ehrke wrote:
> Yes, I am still around :-)

;-)

In case you are not aware of them yet, there are some issues
assigned to you in the Tracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937
https://sourceforge.net/tracker/index.php?func=detail&aid=1882794&group_id=24591&atid=381937

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] geant: notion of local variables

[Eric B. <er...@go...>]

Jocelyn wrote:
> I was wondering if this would make sense to create a branch for geant 
> source code, at least to share my change without breaking trunk 
> development ?

So far we didn't use branches in Gobo. Personally I think that
the best way to experiment with your changes and to find out
whether they break something or not it to commit them in the
trunk.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Speed of Gestalt compiled with GEC versus ISE

[Eric B. <er...@go...>]

You should note the gec always checks for call-on-void-target.
I think that this is a requirement from ECMA when the attached
mechanism is not enabled.

Also, gec checks for CAT-calls, but when it found no CAT-call
at compilation time then there is no check needed at execution
time. So, no penalty here.

One thing to remember is that there has been not that much effort
spent yet on optimizing the C code generated by gec. So I guess
that when that is done it should be faster than 40 seconds.
For example, as far as I remember, SE optimizes the generated
C code better than gec. One reason why I'm interested in still
supporting SE 1.2 is to be able to benchmark the C code generated
by gec against the one generated by SE.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com


Colin Adams wrote:
> No I didn't.
> 
> Doing so does improve the speed dramatically, as you say - now 72 seconds.
> Still significantly slower than GECs 40seconds.
> 
> Thanks for the tip, anyway.
> 
> On 04/02/2008, Jann Röder <roe...@et...> wrote:
>> Did you turn of exception tracing (this makes a huge difference if you
>> have many feature calls) and void call exceptions for ISE ?
>>
>> Colin Adams wrote:
>>> That timing information is rather interesting - on my 5-year old
>>> 32-bit intel machine, I get timings of 2:15 for ISE (comparable with
>>> yours) and 40 seconds with GEC (at roughly 3.5 times quicker, that is
>>> in line with other measurements I have seen).
> 

[gobo-eiffel-develop] [Fwd: Re: MA_DECIMAL_CONSTANTS.zero]

[Eric B. <er...@go...>]

CRISMER Paul-Georges wrote:
> In fact, I remember I've been forced to do that for assertion violation reason.
> 
> The initial implementation follows your proposal.
> 
> The problem is I did not log the rationale for doing that.
> And for the moment I do not have energy to chase why.
> 
> Best regards,
> 
> Paul G. Crismer
> 
> -----Original Message-----
> From: Eric Bezault [mailto:er...@go...]
> 
> Sent: jeudi 7 février 2008 15:40
> To: CRISMER Paul-Georges
> Cc: Gobo Developers Mailing List
> Subject: Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero
> 
> CRISMER Paul-Georges wrote:
>> Recursive?
> 
> Oops, indeed. I didn't realize that we were talking about `zero' from MA_DECIMAL_CONSTANTS and not from MA_DECIMAL.
> 
> This implementation looks twisted to me though. I would have written in class MA_DECIMAL_CONSTANTS:
> 
> 	zero: MA_DECIMAL is
> 			-- Neutral element for "+" and "-"
> 		once
> 			create Result.make_zero
> 		ensure
> 			zero_not_void: Result /= Void
> 			is_zero: Result.is_zero
> 		end
> 
> and in MA_DECIMAL:
> 
> 	zero: like Current is
> 			-- Neutral element for "+" and "-"
> 		do
> 			Result := decimal.zero
> 		ensure then
> 			is_zero: Result.is_zero
> 		end
> 
> and no need for `once_zero'. Or did I miss something again?
> 
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
> 
> ***** Disclaimer *****
> http://www.groupes.be/1_mail-disclaimer.htm
> 
> 
> 

Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

[Eric B. <er...@go...>]

CRISMER Paul-Georges wrote:
> Recursive?

Oops, indeed. I didn't realize that we were talking about
`zero' from MA_DECIMAL_CONSTANTS and not from MA_DECIMAL.

This implementation looks twisted to me though. I would have
written in class MA_DECIMAL_CONSTANTS:

	zero: MA_DECIMAL is
			-- Neutral element for "+" and "-"
		once
			create Result.make_zero
		ensure
			zero_not_void: Result /= Void
			is_zero: Result.is_zero
		end

and in MA_DECIMAL:

	zero: like Current is
			-- Neutral element for "+" and "-"
		do
			Result := decimal.zero
		ensure then
			is_zero: Result.is_zero
		end

and no need for `once_zero'. Or did I miss something again?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

[Eric B. <er...@go...>]

CRISMER Paul-Georges wrote:
> {MA_DECIMAL}.make_zero creates one object whose value is zero.
> That way, 1 million of objects whose value is zero.
> 
> {MA_DECIMAL_CONSTANTS}.zero refers to a single object whose value is
> zero.
> You can have as many references to {MA_DECIMAL}.zero or
> {MA_DECIMAL_CONSTANTS}.zero, they refer all to a unique object whose
> value is zero.
> 
> In {MA_DECIMAL_CONSTANTS}.zero, you have to create a {MA_DECIMAL}
> instance (line 1:) before being able to call the {MA_DECIMAL}.zero
> feature (line 2:).
> 
> Since this object is just a "proxy" to be able to call the
> {MA_DECIMAL}.zero feature, I chose to write line 1: which creates a
> decimal object with 1 significant digit.
> 
> Does this make sense to you?

It does not make sense to me. In your implementation you have
a recursive call to the once function to define it.

I think that what Berend meant was something like:

	zero: MA_DECIMAL is
			-- Neutral element for "+" and "-"
		once
			create Result.make_zero
		ensure
			zero_not_void: Result /= Void
		end

As far as I can tell we don't create a million objects and
the implementation of `zero' is not recursive anymore.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

[Colin A. <col...@go...>]

On 07/02/2008, CRISMER Paul-Georges <Pau...@gr...> wrote:
> {MA_DECIMAL_CONSTANTS}.zero refers to a single object whose value is
> zero.

To be more accurate, it refers to a single object whose initial value is zero.

I presume this is what Berend is concerned about.

Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

[CRISMER Paul-G. <Pau...@gr...>]

Typo.

Instead of
"That way, 1 million of objects whose value is zero."

Please read
"That way, you could create 1 million of objects whose value is zero."

-----Original Message-----
From: gob...@li... [mailto:gob...@li...] On Behalf Of CRISMER Paul-Georges
Sent: jeudi 7 février 2008 14:01
To: gob...@li...
Subject: Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero


Hello Berend,

{MA_DECIMAL}.make_zero creates one object whose value is zero.
That way, 1 million of objects whose value is zero.

{MA_DECIMAL_CONSTANTS}.zero refers to a single object whose value is zero.
You can have as many references to {MA_DECIMAL}.zero or {MA_DECIMAL_CONSTANTS}.zero, they refer all to a unique object whose value is zero.

In {MA_DECIMAL_CONSTANTS}.zero, you have to create a {MA_DECIMAL} instance (line 1:) before being able to call the {MA_DECIMAL}.zero feature (line 2:).

Since this object is just a "proxy" to be able to call the {MA_DECIMAL}.zero feature, I chose to write line 1: which creates a decimal object with 1 significant digit.

Does this make sense to you?

Best regards,

Paul G. Crismer


	zero: MA_DECIMAL is
			-- Neutral element for "+" and "-"
		once
1:			create Result.make (1)
2:			Result := Result.zero
		ensure
			zero_not_void: Result /= Void
		end

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gobo-eiffel-develop mailing list
gob...@li...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

[CRISMER Paul-G. <Pau...@gr...>]

Hello Berend,

{MA_DECIMAL}.make_zero creates one object whose value is zero.
That way, 1 million of objects whose value is zero.

{MA_DECIMAL_CONSTANTS}.zero refers to a single object whose value is
zero.
You can have as many references to {MA_DECIMAL}.zero or
{MA_DECIMAL_CONSTANTS}.zero, they refer all to a unique object whose
value is zero.

In {MA_DECIMAL_CONSTANTS}.zero, you have to create a {MA_DECIMAL}
instance (line 1:) before being able to call the {MA_DECIMAL}.zero
feature (line 2:).

Since this object is just a "proxy" to be able to call the
{MA_DECIMAL}.zero feature, I chose to write line 1: which creates a
decimal object with 1 significant digit.

Does this make sense to you?

Best regards,

Paul G. Crismer


	zero: MA_DECIMAL is
			-- Neutral element for "+" and "-"
		once
1:			create Result.make (1)
2:			Result := Result.zero
		ensure
			zero_not_void: Result /= Void
		end

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

[gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

[Berend de B. <be...@po...>]

Hi Guys,

Anyone an idea why zero is created like this:

	zero: MA_DECIMAL is
			-- Neutral element for "+" and "-"
		once
			create Result.make (1)
			Result := Result.zero
		ensure
			zero_not_void: Result /= Void
		end

There is a create Result.make_zero call, why not use that?

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] geant: notion of local variables

[Jocelyn <ei...@dj...>]

Hi all,

* About use of "unset"
  I have a few scripts making big use of unset
  mainly because local variables are not available, and also .. as 
*dirty* trick to avoid creating too many fake targets.
  In many place, I also prefer to "unset" variable just in case.

  So .. if we have local variables .. and <group /> task
  I guess I could stop using unset. But still, as you said, let's keep 
it to avoid breaking existing scripts.


* Otherwise, I am working (when I find some time), to add <local/> and 
<global/>, to change the <set /> to be smart enough to find out where to 
set the values.

In my working copy, I also have
* support for <group /> element, which behave more or less as an inner 
<target /> except it does not accept <local/>, <global/>, <argument/>.
* I change code to remove the long if elseif elseif ... end  to create 
TASK based on xml element name. Now it is using a hash_table of 
GEANT_TASK_BUILDER [GEANT_TASK create make end]. This should improve 
performance.

And finally, I was thinking of adding an element <option /> at the 
<project/> level to be able to set option in the script such as
    <option name="verbose" value="true" />
or even
    <option name="default_variable_scope" value="global" /> <!-- Current 
behavior, and should be the default -->
    <option name="default_variable_scope" value="local" />
This brings the idea of introducing a way to say .. in this project, the 
variables are local by default. This could be used for transition, in 
the same way PHP did with "safe_globals" ... or similar.

I was wondering if this would make sense to create a branch for geant 
source code, at least to share my change without breaking trunk 
development ?

If not, I might post a patch soon about all those changes, mainly
    - more efficient way to create GEANT_TASK given their names.
    - locals  (I haven't done anything on globals for now)
    - group element

-- Jocelyn


On 2/2/2008 21:15 PM, Sven Ehrke wrote:
> Sven Ehrke wrote:
>   
>> I just did a grep on all build.eant files for '<unset' within gobo and only found
>> two occurrences in 'example/geant/build.eant'. Maybe I forgot in the meanwhile
>>     
>
> I forgot to check other .eant files so I checked again. Gobo uses <unset> in
> misc/eiffel.eant:
>
>   <unset name="xace_format" if="${ISE_5_7}"/>
>
> for example. But I can imagine that it could be solved in a different way
> if local variables are used for this.
>
> - Sven
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>   

Re: [gobo-eiffel-develop] [ gobo-eiffel-Bugs-1830026 ] Precondition violated in XM_XSLT_OUTPUT_ENCODER

[Colin A. <col...@go...>]

I chose to set it to pending as I believed I had fixed the problem. I
knew the tracker would close it after 14 days.

The idea is to give you (the submitter) a chance to confirm or deny the fix.

In this particular case, it might be difficult to test/demonstrate the
fix, because of the status of support for SE in the XPath library.

On 04/02/2008, Eric Bezault <er...@go...> wrote:
> Hi Colin,
>
> I'm not sure why you chose to change the status of this issue to
> Pending, but apparently the Bug Tracker closes any Pending issue
> after a certain period. Perhaps it's better to keep your issues
> Open to avoid such problem.
>
>
> SourceForge.net wrote:
> > Bugs item #1830026, was opened at 2007-11-11 09:40
> > Message generated for change (Comment added) made by sf-robot
> > You can respond by visiting:
> > https://sourceforge.net/tracker/?func=detail&atid=381937&aid=1830026&group_id=24591
> >
> > Please note that this message will contain a full copy of the comment thread,
> > including the initial issue submission, for this request,
> > not just the latest update.
> > Category: xslt
> > Group: trunk
> >> Status: Closed
> > Resolution: Fixed
> > Priority: 5
> > Private: No
> > Submitted By: Eric Bezault (ericb)
> > Assigned to: Colin Paul Adams (colin-adams)
> > Summary: Precondition violated in XM_XSLT_OUTPUT_ENCODER
> >
> > Initial Comment:
> > This bug report supercede bug#1829999.
> >
> > When running 'geant -Dabort test_debug_se' in $GOBO/test/xml/xslt I get the exception trace below. From what I can see, it looks like we call XM_XSLT_OUTPUT_ENCODER.is_valid_string with a string that contains a Null character. This routine then calls `is_bad_character_code' which has a precondition `is_char'. But `is_char' returns False when the code is zero. So my guess is that either `is_char' should return True when the code is zero, or `is_valid_string' should make sure to call `is_bad_character_code' only after having checked that `is_char' holds (or both).
> >
> > ----------------------------------------------------------------------
> >
> >> Comment By: SourceForge Robot (sf-robot)
> > Date: 2008-02-02 19:20
> >
> > Message:
> > Logged In: YES
> > user_id=1312539
> > Originator: NO
> >
> > This Tracker item was closed automatically by the system. It was
> > previously set to a Pending status, and the original submitter
> > did not respond within 14 days (the time period specified by
> > the administrator of this Tracker).
> >
> > ----------------------------------------------------------------------
> >
> > Comment By: Colin Paul Adams (colin-adams)
> > Date: 2008-01-18 11:59
> >
> > Message:
> > Logged In: YES
> > user_id=732953
> > Originator: NO
> >
> > The fix revealed another problem - NULLs were actually getting written out
> > in a few scenarios, so further fixing was necessary.
> >
> > ----------------------------------------------------------------------
> >
> > Comment By: Colin Paul Adams (colin-adams)
> > Date: 2008-01-14 13:07
> >
> > Message:
> > Logged In: YES
> > user_id=732953
> > Originator: NO
> >
> > Zero is not a legitimate character code, even in XML 1.1.
> >
> > So I shall add a check for containing a NULL prior to calling
> > is_bad_character_code.
> >
> > ----------------------------------------------------------------------
> >
> > Comment By: Eric Bezault (ericb)
> > Date: 2007-11-11 09:43
> >
> > Message:
> > Logged In: YES
> > user_id=13278
> > Originator: YES
> >
> > Here is the relevant part of the exception trace:
> >
> > ======================================
> > output XM_XSLT_XML_EMITTER
> > Current = XM_XSLT_HTML_EMITTER#05C23330
> >         [ document_uri = Void
> >           base_uri = ""
> >           is_open = True
> >           is_document_started = True
> >           is_written = True
> >           outputter = #072089A8
> >           output_properties = #052A4940
> >           is_error = False
> >           serializer = #052E8EB8
> >           is_no_declaration_on_close = False
> >           element_qname_stack = #0543BAE4
> >           is_well_formed_document_required = False
> >           is_output_open = True
> >           is_declaration_written = False
> >           is_empty = False
> >           is_open_start_tag = True
> >           raw_outputter = #05377690
> >           encoder_factory = #046AC428
> >           encoding = "ISO-8859-1"
> >           current_element_name_code = 3273
> >           is_hex_preferred = False
> >           allow_undeclare_prefixes = False
> >           name_lookup_table = #04629FF8
> >           name_lookup_table_size = 0
> >           media_type = "text/html"
> >           escape_uri_attributes = True
> >           non_ascii_representation = 2
> >           excluded_representation = 3
> >           in_script = -999998
> >           element_name = "img"
> >           element_uri_code = 0
> >         ]
> > a_character_string = "%U../image/previous.gif%U"
> > line 565 column 28 file
> > C:\DriveE\gobo\gobo\library\xml\xslt\serializer\xm_xslt_
> > xml_emitter.e
> > ======================================
> > <late-binding-wrapper> is_valid_string
> > ======================================
> > is_valid_string XM_XSLT_OUTPUT_ENCODER
> > Current = XM_XSLT_LATIN1_ENCODER#072089A8
> >         [ encoding = "ISO-8859-1"
> >           outputter = #05377690
> >           is_error = False
> >         ]
> > a_character_string = "%U../image/previous.gif%U"
> > Result = True
> > an_index = 1
> > line 74 column 9 file
> > C:\DriveE\gobo\gobo\library\xml\xslt\serializer\xm_xslt_ou
> > tput_encoder.e
> > ======================================
> > is_bad_character_code XM_XSLT_LATIN1_ENCODER
> > Current = XM_XSLT_LATIN1_ENCODER#072089A8
> >         [ encoding = "ISO-8859-1"
> >           outputter = #05377690
> >           is_error = False
> >         ]
> > a_code = 0
> > Result = False
> > line 56 column 26 file
> > C:\DriveE\gobo\gobo\library\xml\xslt\serializer\xm_xslt_o
> > utput_encoder.e
> > =====   Top of run-time stack    =====
> > Exception number 9 not handled.
> > Precondition (require clause) failed.
> >
> > ----------------------------------------------------------------------
> >
> > You can respond by visiting:
> > https://sourceforge.net/tracker/?func=detail&atid=381937&aid=1830026&group_id=24591
> >
> >
> >
>
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] [ gobo-eiffel-Bugs-1830026 ] Precondition violated in XM_XSLT_OUTPUT_ENCODER

[Eric B. <er...@go...>]

Hi Colin,

I'm not sure why you chose to change the status of this issue to
Pending, but apparently the Bug Tracker closes any Pending issue
after a certain period. Perhaps it's better to keep your issues
Open to avoid such problem.


SourceForge.net wrote:
> Bugs item #1830026, was opened at 2007-11-11 09:40
> Message generated for change (Comment added) made by sf-robot
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=381937&aid=1830026&group_id=24591
> 
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: xslt
> Group: trunk
>> Status: Closed
> Resolution: Fixed
> Priority: 5
> Private: No
> Submitted By: Eric Bezault (ericb)
> Assigned to: Colin Paul Adams (colin-adams)
> Summary: Precondition violated in XM_XSLT_OUTPUT_ENCODER
> 
> Initial Comment:
> This bug report supercede bug#1829999.
> 
> When running 'geant -Dabort test_debug_se' in $GOBO/test/xml/xslt I get the exception trace below. From what I can see, it looks like we call XM_XSLT_OUTPUT_ENCODER.is_valid_string with a string that contains a Null character. This routine then calls `is_bad_character_code' which has a precondition `is_char'. But `is_char' returns False when the code is zero. So my guess is that either `is_char' should return True when the code is zero, or `is_valid_string' should make sure to call `is_bad_character_code' only after having checked that `is_char' holds (or both).
> 
> ----------------------------------------------------------------------
> 
>> Comment By: SourceForge Robot (sf-robot)
> Date: 2008-02-02 19:20
> 
> Message:
> Logged In: YES 
> user_id=1312539
> Originator: NO
> 
> This Tracker item was closed automatically by the system. It was
> previously set to a Pending status, and the original submitter
> did not respond within 14 days (the time period specified by
> the administrator of this Tracker).
> 
> ----------------------------------------------------------------------
> 
> Comment By: Colin Paul Adams (colin-adams)
> Date: 2008-01-18 11:59
> 
> Message:
> Logged In: YES 
> user_id=732953
> Originator: NO
> 
> The fix revealed another problem - NULLs were actually getting written out
> in a few scenarios, so further fixing was necessary.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Colin Paul Adams (colin-adams)
> Date: 2008-01-14 13:07
> 
> Message:
> Logged In: YES 
> user_id=732953
> Originator: NO
> 
> Zero is not a legitimate character code, even in XML 1.1.
> 
> So I shall add a check for containing a NULL prior to calling
> is_bad_character_code.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Eric Bezault (ericb)
> Date: 2007-11-11 09:43
> 
> Message:
> Logged In: YES 
> user_id=13278
> Originator: YES
> 
> Here is the relevant part of the exception trace:
> 
> ======================================
> output XM_XSLT_XML_EMITTER
> Current = XM_XSLT_HTML_EMITTER#05C23330
>         [ document_uri = Void
>           base_uri = ""
>           is_open = True
>           is_document_started = True
>           is_written = True
>           outputter = #072089A8
>           output_properties = #052A4940
>           is_error = False
>           serializer = #052E8EB8
>           is_no_declaration_on_close = False
>           element_qname_stack = #0543BAE4
>           is_well_formed_document_required = False
>           is_output_open = True
>           is_declaration_written = False
>           is_empty = False
>           is_open_start_tag = True
>           raw_outputter = #05377690
>           encoder_factory = #046AC428
>           encoding = "ISO-8859-1"
>           current_element_name_code = 3273
>           is_hex_preferred = False
>           allow_undeclare_prefixes = False
>           name_lookup_table = #04629FF8
>           name_lookup_table_size = 0
>           media_type = "text/html"
>           escape_uri_attributes = True
>           non_ascii_representation = 2
>           excluded_representation = 3
>           in_script = -999998
>           element_name = "img"
>           element_uri_code = 0
>         ]
> a_character_string = "%U../image/previous.gif%U"
> line 565 column 28 file
> C:\DriveE\gobo\gobo\library\xml\xslt\serializer\xm_xslt_
> xml_emitter.e
> ======================================
> <late-binding-wrapper> is_valid_string
> ======================================
> is_valid_string XM_XSLT_OUTPUT_ENCODER
> Current = XM_XSLT_LATIN1_ENCODER#072089A8
>         [ encoding = "ISO-8859-1"
>           outputter = #05377690
>           is_error = False
>         ]
> a_character_string = "%U../image/previous.gif%U"
> Result = True
> an_index = 1
> line 74 column 9 file
> C:\DriveE\gobo\gobo\library\xml\xslt\serializer\xm_xslt_ou
> tput_encoder.e
> ======================================
> is_bad_character_code XM_XSLT_LATIN1_ENCODER
> Current = XM_XSLT_LATIN1_ENCODER#072089A8
>         [ encoding = "ISO-8859-1"
>           outputter = #05377690
>           is_error = False
>         ]
> a_code = 0
> Result = False
> line 56 column 26 file
> C:\DriveE\gobo\gobo\library\xml\xslt\serializer\xm_xslt_o
> utput_encoder.e
> =====   Top of run-time stack    =====
> Exception number 9 not handled.
> Precondition (require clause) failed.
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=381937&aid=1830026&group_id=24591
> 
> 
> 


-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Speed of Gestalt compiled with GEC versus ISE

[Colin A. <col...@go...>]

No I didn't.

Doing so does improve the speed dramatically, as you say - now 72 seconds.
Still significantly slower than GECs 40seconds.

Thanks for the tip, anyway.

On 04/02/2008, Jann R=F6der <roe...@et...> wrote:
> Did you turn of exception tracing (this makes a huge difference if you
> have many feature calls) and void call exceptions for ISE ?
>
> Colin Adams wrote:
> > That timing information is rather interesting - on my 5-year old
> > 32-bit intel machine, I get timings of 2:15 for ISE (comparable with
> > yours) and 40 seconds with GEC (at roughly 3.5 times quicker, that is
> > in line with other measurements I have seen).

[gobo-eiffel-develop] Speed of Gestalt compiled with GEC versus ISE

[Colin A. <col...@go...>]

That timing information is rather interesting - on my 5-year old
32-bit intel machine, I get timings of 2:15 for ISE (comparable with
yours) and 40 seconds with GEC (at roughly 3.5 times quicker, that is
in line with other measurements I have seen).

So maybe GEC is less efficient on PPC, or maybe ISE is particularly
well optimized for PPC.

Copying to the Gobo developers list as Eric might be interested in the figu=
res.

On 03/02/2008, Jann R=F6der <roe...@et...> wrote:
> Hi Colin,
> finally I managed to compile gestalt with the latest GEC and GOBO
> libraries. I timed it versus a ISE Eiffel 6.1.7.1477 build with
> Exception tracing and Void call exceptions turned off. It turns out that
> the ISE build is slightly faster: 2:10 vs. 2:20 on my fairly old
> powerbook for the benchmark that needs 14 seconds on your machine.
>
> This is the system-properties output:
>   xsl:version:                          2.0
>   xsl:vendor:                           Colin Adams
>   xsl:vendor-url:                       http://gestalt.sourceforge.net/
>   xsl:product-name:                     Gestalt
>   xsl:product-version:                  1.0.2
>   xsl:is-schema-aware:                  no
>   xsl:supports-serialization:           yes
>   xsl:supports-backwards-compatibility: yes
>   xsl:supports-namespace-axis:          no
>   gexslt:standard-file-collection:      yes
>   gexslt:standard-ftp-collection:
>   gexslt:standard-http-collection:
>
> Do you want me to send you the binaries so you can upload them ?
>
> Jann
>
> Colin Adams wrote:
> > P.S. You will need to refresh Gobo SVN too - and maybe rerun the
> > bootstrap (better safe than sorry).
> >
> > On 31/01/2008, Jann R=F6der <roe...@et...> wrote:
> >> Oh sorry I forgot about that test. However should I also get the gesta=
lt
> >> code from SVN ? Right now I just got the 1.0.1 linux release.
> >>
> >> Jann
> >>
> >> Colin Adams wrote:
> >>> If you don't havesystem_properties.xsl in the gestalt directory, then
> >>> you need to do an svn refresh and rebuild (this was why i was asking
> >>> you to run the test, to see what version you had built).
> >>>
> >>> I do not want a gexslt binary, as this lacks support for http, ftp an=
d mailto.
> >>> But the directory listing test should work with either version anyway=
.
> >>>
> >>> For timing, I sent you a separate test (it takes 14 seconds on my new
> >>> 45nm 64-bit machine).
> >>>
> >>> On 31/01/2008, Jann R=F6der <roe...@et...> wrote:
> >>>> Hi Colin,
> >>>> the gestalt --template=3Dinitial system_properties.xsl call doesn't =
work,
> >>>> it says it can't find system_properties.xsl . As for the timing, the
> >>>> directory listing thing is too quick to measure, and also the ise bi=
nary
> >>>> can't do it since it isn't built with the SVN version of GOBO I thin=
k.
> >>>> So you should probably just upload the GOBO version.
> >>>>
> >>>> Jann
> >>>>
> >>>> Colin Adams wrote:
> >>>>> Thanks Jann.
> >>>>>
> >>>>> Did you time the two executables? If so, what were your results?
> >>>>>
> >>>>> Before I upolad the executable to sourceforge, can you send me the
> >>>>> output of the following command please?
> >>>>>
> >>>>> gestalt --template=3Dinitial system_properties.xsl
> >>>>>
> >>>>> Thank you.
> >>>>>
> >>>>> On 25/01/2008, Jann R=F6der <roe...@et...> wrote:
> >>>>>> These are the PPC builds. One GEC one ISE.
> >>>>>>
> >>>>>> Jann
> >>>>>>
> >>>>>> Colin Adams wrote:
> >>>>>>> I don't think you should attempt cross-compiling. If Ueli can bui=
ld
> >>>>>>> and intel version, that would be great.
> >>>>>>>
> >>>>>>> There are some test scripts in the Gestalt directory.Use like wit=
h
> >>>>>>> that directory as current working directory:
> >>>>>>>
> >>>>>>> gestalt --template=3Dinitial test_collection.xsl
> >>>>>>>
> >>>>>>> This should print an XML listing of the contents of the current
> >>>>>>> working directory on stdout.
> >>>>>>>
> >>>>>>> gestalt ${GOBO}/test/xml/xslt/data/identity.xsl http://www.w3.org
> >>>>>>>
> >>>>>>> This should print the W3C's home page source as XHTML on stdout. =
A
> >>>>>>> warning message will be printed on stderr.
> >>>>>>>
> >>>>>>> On 24/01/2008, Jann R=F6der <roe...@et...> wrote:
> >>>>>>>> Hi Colin,
> >>>>>>>> I managed to compile gestalt with GEC and BoehmGC, however it's =
a PPC
> >>>>>>>> build. And cross compiling seems like a hassle because of the
> >>>>>>>> dependencies. Maybe I can get Ueli to compile it on his Intel Ma=
c. Is
> >>>>>>>> there a way to test if the binary works correctly. I'd like to c=
ompare
> >>>>>>>> it against the version I built with the ISE Eiffel compiler.
> >>>>>>>>
> >>>>>>>> Jann
> >>>>>>>>
> >>>>>>>> Colin Adams wrote:
> >>>>>>>>> You need the current version from subversion.
> >>>>>>>>>
> >>>>>>>>> Gestalt runs at least 3 times faster (well, I only did one test=
, but
> >>>>>>>>> Eric's benchmarks usually indicate a factor of about 6) when co=
mpiled
> >>>>>>>>> with GEC rather than ISE.
> >>>>>>>>>
> >>>>>>>>> On 22/01/2008, Jann R=F6der <roe...@et...> wrote:
> >>>>>>>>>> I got eposix to compile by just pasting the missing definition=
s in the
> >>>>>>>>>> .c file. However my gec version 3.7 doesn't know the --catcall=
 option.
> >>>>>>>>>> Which version of GEC do I need, and why do you want to compile=
 it with
> >>>>>>>>>> GEC in the first place ?
> >>>>>>>>>>
> >>>>>>>>>> Jann
> >>>>>>>>>>
> >>>>>>>>>> Colin Adams wrote:
> >>>>>>>>>>> I think you will have to ask Berend on the ePosix list - goog=
le for
> >>>>>>>>>>> the eposix home page to find it.
> >>>>>>>>>>>
> >>>>>>>>>>> On 22/01/2008, Jann R=F6der <roe...@et...> wrote:
> >>>>>>>>>>>> It seems that if _POSIX_C_SOURCE is defined some of the B* c=
onstants are
> >>>>>>>>>>>>   not defined on Mac OS X, probably they don't belong to the=
 POSIX
> >>>>>>>>>>>> standard ? I'll try to hack around this. However it probably=
 needs a
> >>>>>>>>>>>> real solution.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jann
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jann R=F6der wrote:
> >>>>>>>>>>>>> Hi Colin, I'm having compilation problems with eposix:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> gcc -DHAVE_CONFIG_H -I. -I../../src/supportc -DEIFFEL_VENDO=
R_ise
> >>>>>>>>>>>>> -I/Applications/MacPorts/Eiffel61/studio/spec/macosx-ppc/in=
clude
> >>>>>>>>>>>>> -I../../src/supportc -g -O2 -MT p_termios.lo -MD -MP -MF
> >>>>>>>>>>>>> .deps/p_termios.Tpo -c p_termios.c -o p_termios.o
> >>>>>>>>>>>>> p_termios.c: In function 'const_b57600':
> >>>>>>>>>>>>> p_termios.c:368: error: 'B57600' undeclared (first use in t=
his function)
> >>>>>>>>>>>>> p_termios.c:368: error: (Each undeclared identifier is repo=
rted only once
> >>>>>>>>>>>>> p_termios.c:368: error: for each function it appears in.)
> >>>>>>>>>>>>> p_termios.c: In function 'const_b115200':
> >>>>>>>>>>>>> p_termios.c:373: error: 'B115200' undeclared (first use in =
this function)
> >>>>>>>>>>>>> make[2]: *** [p_termios.lo] Error 1
> >>>>>>>>>>>>> make[1]: *** [all-recursive] Error 1
> >>>>>>>>>>>>> make: *** [all-recursive] Error 1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Any idea what this is ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Jann
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Colin Adams wrote:
> >>>>>>>>>>>>>> http://www.pobox.com/~berend/tmp/eposix-alpha-3.1.0.tar.gz
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Jann Roeder
> >>>>>>>>>>>> <roe...@et...>
> >>>>>>>>>>>> ICQ: #29794099
> >>>>>>>>>>>> PGP key ID: 0xFFA0F51D
> >>>>>>>>>>>>
> >>>>>>>>>>>> Reclaim Your Inbox!
> >>>>>>>>>>>> http://www.mozilla.org/products/thunderbird/
> >>>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jann Roeder
> >>>>>>>>>> <roe...@et...>
> >>>>>>>>>> ICQ: #29794099
> >>>>>>>>>> PGP key ID: 0xFFA0F51D
> >>>>>>>>>>
> >>>>>>>>>> Reclaim Your Inbox!
> >>>>>>>>>> http://www.mozilla.org/products/thunderbird/
> >>>>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jann Roeder
> >>>>>>>> <roe...@et...>
> >>>>>>>> ICQ: #29794099
> >>>>>>>> PGP key ID: 0xFFA0F51D
> >>>>>>>>
> >>>>>>>> Reclaim Your Inbox!
> >>>>>>>> http://www.mozilla.org/products/thunderbird/
> >>>>>>>>
> >>>>>> --
> >>>>>> Jann Roeder
> >>>>>> <roe...@et...>
> >>>>>> ICQ: #29794099
> >>>>>> PGP key ID: 0xFFA0F51D
> >>>>>>
> >>>>>> Reclaim Your Inbox!
> >>>>>> http://www.mozilla.org/products/thunderbird/
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Jann Roeder
> >>>> <roe...@et...>
> >>>> ICQ: #29794099
> >>>> PGP key ID: 0xFFA0F51D
> >>>>
> >>>> Reclaim Your Inbox!
> >>>> http://www.mozilla.org/products/thunderbird/
> >>>>
> >> --
> >> Jann Roeder
> >> <roe...@et...>
> >> ICQ: #29794099
> >> PGP key ID: 0xFFA0F51D
> >>
> >> Reclaim Your Inbox!
> >> http://www.mozilla.org/products/thunderbird/
> >>
>
> --
> Jann Roeder
> <roe...@et...>
> ICQ: #29794099
> PGP key ID: 0xFFA0F51D
>
> Reclaim Your Inbox!
> http://www.mozilla.org/products/thunderbird/
>

Re: [gobo-eiffel-develop] [gobo-eiffel] Re: geant: notion of local variables

[Sven E. <sve...@we...>]

Sven Ehrke wrote:
> I just did a grep on all build.eant files for '<unset' within gobo and only found
> two occurrences in 'example/geant/build.eant'. Maybe I forgot in the meanwhile

I forgot to check other .eant files so I checked again. Gobo uses <unset> in
misc/eiffel.eant:

  <unset name="xace_format" if="${ISE_5_7}"/>

for example. But I can imagine that it could be solved in a different way
if local variables are used for this.

- Sven

Re: [gobo-eiffel-develop] [gobo-eiffel] Re: geant: notion of local variables

[Sven E. <sve...@we...>]

Jocelyn wrote:
> I agree that  <local ../> would be nicer than <setlocal ... />
> 
> but then .. do we consider <local ../> as local declaration, as
> <argument ... />
> and in this case  <set /> and <unset />  would find itself, if they
> apply to local or global ?

I think so.

> And if we use <local /> as declaration, do we allow  unset variable ?
> I mean ...

I just did a grep on all build.eant files for '<unset' within gobo and only found
two occurrences in 'example/geant/build.eant'. Maybe I forgot in the meanwhile
but I do not see a lot of reasons at the moment for '<unset>'. If you can think
of good use-cases for it please tell me. Otherwise I would prefer to remove it but
since we would like to be backwards compatible I suggest to keep it (and it's current behavior) as
it is now and not extend it for local variables.
<set> on the other hand should check if there is a local variable and use it if present, other wise
check for a global one.

> we could even use  <local name="test" value="foobar" />  to initialize
> directly

yes.

> of course I would prefer to have   <set .. /> by default for local
> variables, and use  a <global name="varname" /> but this would break
> existing code...

I suggest to first introduce the local support, then migrate the gobo build files to use
locals and see how it goes. Probably there is still the need for some global variables
and for those I think <global...> as you suggest makes sense because it makes things
more clear.

- Sven

Re: [gobo-eiffel-develop] [gobo-eiffel] Re: geant: notion of local variables

[Jocelyn <ei...@dj...>]

I agree that  <local ../> would be nicer than <setlocal ... />

but then .. do we consider <local ../> as local declaration, as 
<argument ... />
and in this case  <set /> and <unset />  would find itself, if they 
apply to local or global ?
And if we use <local /> as declaration, do we allow  unset variable ?
I mean ...

    <local name="test" />
    <echo message="$$test is not set" unless="$test" />
in this case I guess it is better to allow not set local variable.

we could even use  <local name="test" value="foobar" />  to initialize 
directly

If this is fill everyone's expectation, I can change my patch to have this.

and yes, local will bring better geant scripts :)
more than once, I got trapped by those awful global variable ;)

of course I would prefer to have   <set .. /> by default for local 
variables, and use  a <global name="varname" /> 
but this would break existing code...


--Jocelyn

On 2/2/2008 18:51 PM, Sven Ehrke wrote:
> Yes, I am still around :-)
>
> I would find it very useful to have local variables in geant.
> Note that I did not look into the the details of the patch.
> But what would you think about naming the task <local> instead
> of <setlocal> (just because of the similarity to Eiffel)?
>
> Also I could imagine that <unset> could be
> smart enough to find out itself if it is a local variable or
> a global one.
>
> Actually a long time ago I thought about implementing local variables
> myself but never took the time to do so. But the my feeling was the
> if local variables are supported all (or at least most) of the globals 
> could be
> eliminated and be replaced by locals and parameters which should 
> improve the
> scripts a lot.
>
> Eric Bezault wrote:
>> Hi Jocelyn,
>>
>> Somehow I didn't receive the original message that you sent on
>> January 31rst. I'm glad you copied it below. If Sven has no
>> objection about this addition to geant, then I'm fine with it.
>> Note that I didn't review your code below, but I guess that
>> you know the code of geant better than I do these days.
>>
>> It has been a long time since we didn't hear from Sven in the
>> Gobo mailing lists. Sven, are you still here?
>>
>
>
>

Re: [gobo-eiffel-develop] [gobo-eiffel] Re: geant: notion of local variables

[Sven E. <sve...@we...>]

Yes, I am still around :-)

I would find it very useful to have local variables in geant.
Note that I did not look into the the details of the patch.
But what would you think about naming the task <local> instead
of <setlocal> (just because of the similarity to Eiffel)?

Also I could imagine that <unset> could be
smart enough to find out itself if it is a local variable or
a global one.

Actually a long time ago I thought about implementing local variables
myself but never took the time to do so. But the my feeling was the
if local variables are supported all (or at least most) of the globals could be
eliminated and be replaced by locals and parameters which should improve the
scripts a lot.

Eric Bezault wrote:
> Hi Jocelyn,
> 
> Somehow I didn't receive the original message that you sent on
> January 31rst. I'm glad you copied it below. If Sven has no
> objection about this addition to geant, then I'm fine with it.
> Note that I didn't review your code below, but I guess that
> you know the code of geant better than I do these days.
> 
> It has been a long time since we didn't hear from Sven in the
> Gobo mailing lists. Sven, are you still here?
> 

Re: [gobo-eiffel-develop] Comments in KI_BUFFER

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> You might want to ask Daniel about the functionalities from
    Eric> FreeELKS's UNIX_FILE_INFO that you need in your classes.  Or
    Eric> are they already available in one way or another in SE's
    Eric> kernel library classes?

They are available.
So I would have to write a .ge class - say KL_FILE_INFO.
I'm going to wait a few weeks, to see what the results of his
inquiries are - to see if he will commit to moving in the direction of ECMA.
-- 
Colin Adams
Preston Lancashire