gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] How to find note items associated with a ET_FUNCTION

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

Additional codes I encounter include:

VWEQ
VUAR-2


On 17 February 2013 14:33, Colin Adams <col...@gm...> wrote:

> Thanks for that.
> In fact, I'm not getting as far as that, as after parsing the ECF,
> last_system.error_handler.has_eiffel_error returns True, as it finds errors
> in
> the ISE standard libraries.
>
> I'm using ES 7.2 (Linux 64-bit), and the Gobo libraries that it ships.
> Would I be better using git HEAD gobo? Or do I possibly just have incorrect
> settings on the parser?
>
> The errors that it finds are:
>
> 1 Syntax error:
> Syntax error:
> line 40 column 39 in
> /home/colin/Eiffel72/library/base/elks/kernel/utf_converter.e
>
>         escape_character: CHARACTER_32 = '%/0xFFFD/'
>                                              ^
>                         -- Unicode replacement character to escape invalid
> UTF-8 or UTF-16 encoding.
>
>
> quite a lot of GVKBU-1 errors. E.g.
>
>
> [GVKBU-1] class REAL_64_REF (78,2): unknown built-in routine
> `positive_infinity' in class REAL_64_REF.
>
> and quite a lot of VEEN-8 errors. E.g.
>
> [VEEN-8] class ARRAYED_LIST (761,10): `l_count' appearing in feature
> `correct_mismatch' or one of its possibly nested inline agents, is an
> object-test local that is used outside of its scope.
>
>
> On 17 February 2013 12:48, Eric Bezault <er...@go...> wrote:
>
>> On 2/16/2013 8:39 PM, Colin Adams wrote:
>>
>>> Having parsed an ECF file to flat degree 3, how can I find which note
>>> items are associated with a function?
>>>
>>
>> It's available in ET_FEATURE.first_indexing.
>> In order to make sure that it is populated by the parser,
>> you have to make sure that it uses an instance of
>> ET_DECORARED_AST_FACTORY, instead of a ET_AST_FACTORY:
>>
>>         l_ast_factory: ET_DECORARED_AST_FACTORY
>>         ...
>>         create l_ast_factory.make
>>         l_system.set_ast_factory (l_ast_factory)
>>
>> --
>> Eric Bezault
>> mailto:er...@go...
>> http://www.gobosoft.com
>>
>
>

Re: [gobo-eiffel-develop] How to find note items associated with a ET_FUNCTION

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

Thanks for that.
In fact, I'm not getting as far as that, as after parsing the ECF,
last_system.error_handler.has_eiffel_error returns True, as it finds errors
in
the ISE standard libraries.

I'm using ES 7.2 (Linux 64-bit), and the Gobo libraries that it ships.
Would I be better using git HEAD gobo? Or do I possibly just have incorrect
settings on the parser?

The errors that it finds are:

1 Syntax error:
Syntax error:
line 40 column 39 in
/home/colin/Eiffel72/library/base/elks/kernel/utf_converter.e

        escape_character: CHARACTER_32 = '%/0xFFFD/'
                                             ^
                        -- Unicode replacement character to escape invalid
UTF-8 or UTF-16 encoding.


quite a lot of GVKBU-1 errors. E.g.


[GVKBU-1] class REAL_64_REF (78,2): unknown built-in routine
`positive_infinity' in class REAL_64_REF.

and quite a lot of VEEN-8 errors. E.g.

[VEEN-8] class ARRAYED_LIST (761,10): `l_count' appearing in feature
`correct_mismatch' or one of its possibly nested inline agents, is an
object-test local that is used outside of its scope.


On 17 February 2013 12:48, Eric Bezault <er...@go...> wrote:

> On 2/16/2013 8:39 PM, Colin Adams wrote:
>
>> Having parsed an ECF file to flat degree 3, how can I find which note
>> items are associated with a function?
>>
>
> It's available in ET_FEATURE.first_indexing.
> In order to make sure that it is populated by the parser,
> you have to make sure that it uses an instance of
> ET_DECORARED_AST_FACTORY, instead of a ET_AST_FACTORY:
>
>         l_ast_factory: ET_DECORARED_AST_FACTORY
>         ...
>         create l_ast_factory.make
>         l_system.set_ast_factory (l_ast_factory)
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>

Re: [gobo-eiffel-develop] How to find note items associated with a ET_FUNCTION

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

On 2/16/2013 8:39 PM, Colin Adams wrote:
> Having parsed an ECF file to flat degree 3, how can I find which note
> items are associated with a function?

It's available in ET_FEATURE.first_indexing.
In order to make sure that it is populated by the parser,
you have to make sure that it uses an instance of
ET_DECORARED_AST_FACTORY, instead of a ET_AST_FACTORY:

	l_ast_factory: ET_DECORARED_AST_FACTORY
	...
	create l_ast_factory.make
	l_system.set_ast_factory (l_ast_factory)

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

[gobo-eiffel-develop] How to find note items associated with a ET_FUNCTION

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

Having parsed an ECF file to flat degree 3, how can I find which note items
are associated with a function?

Re: [gobo-eiffel-develop] [eiffel_software] Converting UTF8 to LATIN1

[Emmanuel S. <ma...@ei...>]

You can use our encoding library to perform the conversion. Here are some
information:

http://dev.eiffel.com/Encoding_library

Manu

> -----Original Message-----
> From: eif...@ya...
> [mailto:eif...@ya...] On Behalf Of CRISMER Paul-
> Georges
> Sent: Friday, July 27, 2012 01:45
> To: eif...@ya...; gobo-eiffel-
> de...@li...
> Subject: [eiffel_software] Converting UTF8 to LATIN1
> 
> Hello,
> 
> Using GOBO-xml parser, I get UTF-8 Strings.
> I need LATIN-1 encoded strings.
> 
> How can an UTF-8 String converted to LATIN-1 ?
> 
> Best regards,
> 
> Paul G. Crismer
> 
> ***** Group S disclaimer *****
> http://www.groupes.be/1_mail-disclaimer.htm
> 
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/eiffel_software/
> 
> <*> Your email settings:
>     Individual Email | Traditional
> 
> <*> To change settings online go to:
>     http://groups.yahoo.com/group/eiffel_software/join
>     (Yahoo! ID required)
> 
> <*> To change settings via email:
>     eif...@ya...
>     eif...@ya...
> 
> <*> To unsubscribe from this group, send an email to:
>     eif...@ya...
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/

[gobo-eiffel-develop] Converting UTF8 to LATIN1

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

Hello,

Using GOBO-xml parser, I get UTF-8 Strings.
I need LATIN-1 encoded strings.

How can an UTF-8 String converted to LATIN-1 ?

Best regards,

Paul G. Crismer

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

[gobo-eiffel-develop] Converting UTF8 to LATIN1

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

Hello,

Using GOBO-xml parser, I get UTF-8 Strings.
I need LATIN-1 encoded strings.

How can an UTF-8 String converted to LATIN-1 ?

Best regards,

Paul G. Crismer

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

Re: [gobo-eiffel-develop] 'Select' errors for a deferred class

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

Hi Howard,

I think that the problems comes form the fact that when compiling
with gec, it uses the non-void-safe version of EiffelBase.
And EiffelVision2 from $ISE_EIFFEL/library/vision2 is not meant
to be compiled against this version of EiffelBase. You should
try to use the version from $ISE_EIFFEL/compatible/library/vision2
instead.

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


On 5/26/2012 6:28 PM, Howard Thomson wrote:
> Hi Eric,
>
> Having done a bootstrap build of 'gec' from the latest git repo today, I
> can confirm that the issue below is, or appears to me to be,
> outstanding.
>
> I did do some browsing of the code in the tools library, but have not
> yet identified how the issue arises or is treated differently by gec vs
> EiffelStudio.
>
> I am using the Eiffel 7.0 Vision2 interface and implementation_interface
> clusters, with my own implementation cluster, essentially everything
> else coming from the current ${GOBO} path ...
>
> I will attempt to create a minimal compilation that demonstrates the
> compilation error, possibly while I am in Prague for the TOOLS 2012
> conference next week [departing at some unearthly hour tomorrow
> morning !].
>
> Cheers,
>
> Howard
>
>
> -----Original Message-----
> From: Eric Bezault<er...@go...>
> To: Gobo Developers Mailing List
> <gob...@li...>
> Cc: Howard Thomson<how...@di...>
> Subject: Re: 'Select' errors for a deferred class
> Date: Thu, 24 May 2012 13:16:16 +0200
>
> Hi Howard,
>
> On 5/7/2012 12:19 AM, Howard Thomson wrote:
>> I am using gec and ec to compile a program that uses the Vision2 library
>> from the Eiffel Software distribution.
>>
>> Compiling with gec reports an error:
>>
>> [VMRC-2] class EV_WIDGET_LIST (29,2): replicated features
>> EV_DYNAMIC_LIST.put, EV_CONTAINER.cl_put have not been selected.
>>
>> However, compiling the Vision2 example 'widgets' program, which also
>> uses  EV_WIDGET_LIST, with ec does not report such an error.
>>
>> Does the fact that EV_WIDGET_LIST is a deferred class have anything to
>> do with the difference in error treatment, or is this a probable bug in
>> the current gec implementation ?
>
> Did you manage to understand what the problem was?
> What version of EiffelVision2 did you use? I already compiled
> classes from EiffelVision2 with Gobo in the past, and never
> saw this kind of problem.
>
>

Re: [gobo-eiffel-develop] 'Select' errors for a deferred class

[Howard T. <how...@di...>]

Hi Eric,

Having done a bootstrap build of 'gec' from the latest git repo today, I
can confirm that the issue below is, or appears to me to be,
outstanding.

I did do some browsing of the code in the tools library, but have not
yet identified how the issue arises or is treated differently by gec vs
EiffelStudio.

I am using the Eiffel 7.0 Vision2 interface and implementation_interface
clusters, with my own implementation cluster, essentially everything
else coming from the current ${GOBO} path ...

I will attempt to create a minimal compilation that demonstrates the
compilation error, possibly while I am in Prague for the TOOLS 2012
conference next week [departing at some unearthly hour tomorrow
morning !].

Cheers,

Howard


-----Original Message-----
From: Eric Bezault <er...@go...>
To: Gobo Developers Mailing List
<gob...@li...>
Cc: Howard Thomson <how...@di...>
Subject: Re: 'Select' errors for a deferred class
Date: Thu, 24 May 2012 13:16:16 +0200

Hi Howard,

On 5/7/2012 12:19 AM, Howard Thomson wrote:
> I am using gec and ec to compile a program that uses the Vision2 library
> from the Eiffel Software distribution.
>
> Compiling with gec reports an error:
>
> [VMRC-2] class EV_WIDGET_LIST (29,2): replicated features
> EV_DYNAMIC_LIST.put, EV_CONTAINER.cl_put have not been selected.
>
> However, compiling the Vision2 example 'widgets' program, which also
> uses  EV_WIDGET_LIST, with ec does not report such an error.
>
> Does the fact that EV_WIDGET_LIST is a deferred class have anything to
> do with the difference in error treatment, or is this a probable bug in
> the current gec implementation ?

Did you manage to understand what the problem was?
What version of EiffelVision2 did you use? I already compiled
classes from EiffelVision2 with Gobo in the past, and never
saw this kind of problem.


-- 
Howard Thomson <how...@di...>

Re: [gobo-eiffel-develop] 'Select' errors for a deferred class, Vision2 gec compilation problems

[Howard T. <how...@di...>]

Hi Eric,

I confirmed today that the syntax issue below has been fixed in the git
repo, having done a bootstrap build ...

Regards,

Howard



-----Original Message-----
From: Eric Bezault <er...@go...>
To: how...@di...
Cc: Gobo Developers Mailing List
<gob...@li...>
Subject: Re: [gobo-eiffel-develop] 'Select' errors for a deferred class,
Vision2 gec compilation problems
Date: Fri, 25 May 2012 18:19:25 +0200

On 5/25/2012 12:55 AM, Howard Thomson wrote:
> In the meantime, since updating to using EiffelStudio version 7.0.8.8074
> and attempting to compile [today] with gec, compiling with my 'guide'
> version and gec [albeit from ~ 15-June-2011], I get a syntax error in
> the class EV_COMBO_BOX:
>
> Syntax error:
> line 113 column 51 in /data/Eiffel70/library/vision2/interface/widgets/primitives/ev_combo_box.e
> 		ensure
> 			text_set: check_text_modification ({STRING_32} "", a_text.as_string_32)
> 			                                               ^
> 		end

I think that this fixed in the latest version in git.


-- 
Howard Thomson <how...@di...>

Re: [gobo-eiffel-develop] 'Select' errors for a deferred class, Vision2 gec compilation problems

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

On 5/25/2012 12:55 AM, Howard Thomson wrote:
> In the meantime, since updating to using EiffelStudio version 7.0.8.8074
> and attempting to compile [today] with gec, compiling with my 'guide'
> version and gec [albeit from ~ 15-June-2011], I get a syntax error in
> the class EV_COMBO_BOX:
>
> Syntax error:
> line 113 column 51 in /data/Eiffel70/library/vision2/interface/widgets/primitives/ev_combo_box.e
> 		ensure
> 			text_set: check_text_modification ({STRING_32} "", a_text.as_string_32)
> 			                                               ^
> 		end

I think that this fixed in the latest version in git.

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

Re: [gobo-eiffel-develop] 'Select' errors for a deferred class, Vision2 gec compilation problems

[Howard T. <how...@di...>]

Hi Eric,

I have since done a git merge from the current gobo-eiffel on GitHub,
with the last reconciliation done more than a year ago, so this may have
been fixed, and I will do some further checking on the currency of the
problem.

In the meantime, since updating to using EiffelStudio version 7.0.8.8074
and attempting to compile [today] with gec, compiling with my 'guide'
version and gec [albeit from ~ 15-June-2011], I get a syntax error in
the class EV_COMBO_BOX:

Syntax error:
line 113 column 51 in /data/Eiffel70/library/vision2/interface/widgets/primitives/ev_combo_box.e
		ensure
			text_set: check_text_modification ({STRING_32} "", a_text.as_string_32)
			                                               ^
		end

With other projects on the go, working with the vision2 code has lagged,
but I will be getting back to that shortly ...

Regards,

Howard



-----Original Message-----
From: Eric Bezault <er...@go...>
To: Gobo Developers Mailing List
<gob...@li...>
Cc: Howard Thomson <how...@di...>
Subject: Re: 'Select' errors for a deferred class
Date: Thu, 24 May 2012 13:16:16 +0200

Hi Howard,

On 5/7/2012 12:19 AM, Howard Thomson wrote:
> I am using gec and ec to compile a program that uses the Vision2 library
> from the Eiffel Software distribution.
>
> Compiling with gec reports an error:
>
> [VMRC-2] class EV_WIDGET_LIST (29,2): replicated features
> EV_DYNAMIC_LIST.put, EV_CONTAINER.cl_put have not been selected.
>
> However, compiling the Vision2 example 'widgets' program, which also
> uses  EV_WIDGET_LIST, with ec does not report such an error.
>
> Does the fact that EV_WIDGET_LIST is a deferred class have anything to
> do with the difference in error treatment, or is this a probable bug in
> the current gec implementation ?

Did you manage to understand what the problem was?
What version of EiffelVision2 did you use? I already compiled
classes from EiffelVision2 with Gobo in the past, and never
saw this kind of problem.


-- 
Howard Thomson <how...@di...>

Re: [gobo-eiffel-develop] 'Select' errors for a deferred class

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

Hi Howard,

On 5/7/2012 12:19 AM, Howard Thomson wrote:
> I am using gec and ec to compile a program that uses the Vision2 library
> from the Eiffel Software distribution.
>
> Compiling with gec reports an error:
>
> [VMRC-2] class EV_WIDGET_LIST (29,2): replicated features
> EV_DYNAMIC_LIST.put, EV_CONTAINER.cl_put have not been selected.
>
> However, compiling the Vision2 example 'widgets' program, which also
> uses  EV_WIDGET_LIST, with ec does not report such an error.
>
> Does the fact that EV_WIDGET_LIST is a deferred class have anything to
> do with the difference in error treatment, or is this a probable bug in
> the current gec implementation ?

Did you manage to understand what the problem was?
What version of EiffelVision2 did you use? I already compiled
classes from EiffelVision2 with Gobo in the past, and never
saw this kind of problem.

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

Re: [gobo-eiffel-develop] Moving to READABLE_STRING_GENERAL

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

On 5/10/2012 3:32 AM, Berend de Boer wrote:
> Hi All,
>
> Is it a good idea to move to READABLE_STRING_GENERAL instead of
> STRING wherever possible?
>
> Anyone objecting committing those changes to Gobo?

I suggest that we wait for ISE to complete the interface
of READABLE_STRING_GENERAL before making the move.

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

[gobo-eiffel-develop] Moving to READABLE_STRING_GENERAL

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

Hi All,

Is it a good idea to move to READABLE_STRING_GENERAL instead of
STRING wherever possible?

Anyone objecting committing those changes to Gobo?


-- 
All the best,

Berend de Boer


          ------------------------------------------------------
          Awesome Drupal hosting: https://www.xplainhosting.com/

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

[<mon...@em...>]

Thank you Frank. It's really helpful.

-----Original Message-----
From: Franck Arnaud [mailto:fr...@ne...] 
Sent: Wednesday, September 07, 2011 8:31 PM
To: Godo Develop
Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

Hi,

Yes you should use Gobo's XML library, whose code started with Nenie XML
many years ago, and Nenie XML hasn't been maintained since it moved to
Gobo. I'm almost surprised it still works at all on current compilers
after all those years :-).

I think Alexander is on the thing re the reason, I don't recall the
exact details but I had read something wrong from the standard on
normalization and fixed it once it was in Gobo (actually I think there
might be some remaining issues in that area, either of inelegant
implementation or some obscure normalisation case that you don't
actually hit in real life, or something).

Well done with the detective work btw ;-).

Cheers
Franck

On Wednesday, September 07, 2011 4:16 AM, mon...@em... wrote:
> I c.
> Thanks.
> 
> From: Colin Adams [mailto:col...@gm...]
> Sent: Wednesday, September 07, 2011 3:57 PM
> To: Wang, Monica
> Cc: gob...@li...
> Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing
> library
> 
> Eric can correct me if I'm wrong, but Nenie was Franck Arnaud's
> domain/library, and Franck was the most recent maintainer of the Gobo XML
> parser, so you should use the Gobo parser which has many updates. It
> should fully comply with XML 1.0 edition 2 (or edition 3 or edition 4,
> but not edition 5, which was the W3C's way of breaking with
> backwards-compatibility without incrementing the version number of XML -
> i.e. it should have been XML 1.2).
> On 7 September 2011 08:47,
> <mon...@em...<mailto:mon...@em...>> wrote:
> Thank you Alexander and Collin!
> 
> My xml document is quite simple( prolog and main node ), with no DTD or
> CDATA.
> That means the spaces in attributes' value should always be preserved, no
> matter the parser is validating or not.
> 
> It seems that Nenie xml parser should be corrected (it collapses the
> spaces and remove leading and tailing spaces unexpectedly.)
> I intend to patch Nenie xml parser with the diff I find in
> gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097<http://gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097>
> 
> But that one is for gobo xml parser, although I find the code is almost
> the same with Nenie xml parser.
> Do you know the history between these two parsers?
> And what's the better choice for me, patch Nenie xml parser, or replace
> the Nenie with gobo xml parser?
> 
> Thank you in advance.
> 
> 
> 
> -----Original Message-----
> From: Colin Paul Adams
> [mailto:co...@co...<mailto:co...@co...>]
> Sent: Wednesday, September 07, 2011 12:55 PM
> To:
> gob...@li...<mailto:gob...@li...>
> Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing
> library
> 
> >>>>> "Alexander" == Alexander Kogtenkov <kw...@ah...<mailto:kw...@ah...>> writes:
> 
>    Alexander> My feeling is that the processing expectations depend on
>    Alexander> whether the XML parser is validating or not. The rule
>    Alexander> that prevents the parser from attribute normalization is
> 
>    Alexander>     All attributes for which no declaration has been read
>    Alexander> SHOULD be treated by a non-validating processor as if
>    Alexander> declared CDATA.
> 
>    Alexander> And if attribute declarations are present we have
> 
>    Alexander>     If the attribute type is not CDATA, then the XML
>    Alexander> processor MUST further [collapse white spaces].
> 
>    Alexander> So, a non-validating XML parser should not collapse the
>    Alexander> white space characters, while the behaviour of the
>    Alexander> validating one depends on the associated attribute
>    Alexander> declaration.
> 
> And to spell it out, the Gobo XML parser is non-validating.
> --
> Colin Adams
> Preston Lancashire
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org<http://www.asciiribbon.org>   - against
> proprietary attachments
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...<mailto:gob...@li...>
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...<mailto:gob...@li...>
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage 
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 

------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
gobo-eiffel-develop mailing list
gob...@li...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

[Franck A. <fr...@ne...>]

Hi,

Yes you should use Gobo's XML library, whose code started with Nenie XML
many years ago, and Nenie XML hasn't been maintained since it moved to
Gobo. I'm almost surprised it still works at all on current compilers
after all those years :-).

I think Alexander is on the thing re the reason, I don't recall the
exact details but I had read something wrong from the standard on
normalization and fixed it once it was in Gobo (actually I think there
might be some remaining issues in that area, either of inelegant
implementation or some obscure normalisation case that you don't
actually hit in real life, or something).

Well done with the detective work btw ;-).

Cheers
Franck

On Wednesday, September 07, 2011 4:16 AM, mon...@em... wrote:
> I c.
> Thanks.
> 
> From: Colin Adams [mailto:col...@gm...]
> Sent: Wednesday, September 07, 2011 3:57 PM
> To: Wang, Monica
> Cc: gob...@li...
> Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing
> library
> 
> Eric can correct me if I'm wrong, but Nenie was Franck Arnaud's
> domain/library, and Franck was the most recent maintainer of the Gobo XML
> parser, so you should use the Gobo parser which has many updates. It
> should fully comply with XML 1.0 edition 2 (or edition 3 or edition 4,
> but not edition 5, which was the W3C's way of breaking with
> backwards-compatibility without incrementing the version number of XML -
> i.e. it should have been XML 1.2).
> On 7 September 2011 08:47,
> <mon...@em...<mailto:mon...@em...>> wrote:
> Thank you Alexander and Collin!
> 
> My xml document is quite simple( prolog and main node ), with no DTD or
> CDATA.
> That means the spaces in attributes' value should always be preserved, no
> matter the parser is validating or not.
> 
> It seems that Nenie xml parser should be corrected (it collapses the
> spaces and remove leading and tailing spaces unexpectedly.)
> I intend to patch Nenie xml parser with the diff I find in
> gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097<http://gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097>
> 
> But that one is for gobo xml parser, although I find the code is almost
> the same with Nenie xml parser.
> Do you know the history between these two parsers?
> And what's the better choice for me, patch Nenie xml parser, or replace
> the Nenie with gobo xml parser?
> 
> Thank you in advance.
> 
> 
> 
> -----Original Message-----
> From: Colin Paul Adams
> [mailto:co...@co...<mailto:co...@co...>]
> Sent: Wednesday, September 07, 2011 12:55 PM
> To:
> gob...@li...<mailto:gob...@li...>
> Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing
> library
> 
> >>>>> "Alexander" == Alexander Kogtenkov <kw...@ah...<mailto:kw...@ah...>> writes:
> 
>    Alexander> My feeling is that the processing expectations depend on
>    Alexander> whether the XML parser is validating or not. The rule
>    Alexander> that prevents the parser from attribute normalization is
> 
>    Alexander>     All attributes for which no declaration has been read
>    Alexander> SHOULD be treated by a non-validating processor as if
>    Alexander> declared CDATA.
> 
>    Alexander> And if attribute declarations are present we have
> 
>    Alexander>     If the attribute type is not CDATA, then the XML
>    Alexander> processor MUST further [collapse white spaces].
> 
>    Alexander> So, a non-validating XML parser should not collapse the
>    Alexander> white space characters, while the behaviour of the
>    Alexander> validating one depends on the associated attribute
>    Alexander> declaration.
> 
> And to spell it out, the Gobo XML parser is non-validating.
> --
> Colin Adams
> Preston Lancashire
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org<http://www.asciiribbon.org>   - against
> proprietary attachments
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...<mailto:gob...@li...>
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...<mailto:gob...@li...>
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage 
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

[<mon...@em...>]

I c.
Thanks.

From: Colin Adams [mailto:col...@gm...]
Sent: Wednesday, September 07, 2011 3:57 PM
To: Wang, Monica
Cc: gob...@li...
Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

Eric can correct me if I'm wrong, but Nenie was Franck Arnaud's domain/library, and Franck was the most recent maintainer of the Gobo XML parser, so you should use the Gobo parser which has many updates. It should fully comply with XML 1.0 edition 2 (or edition 3 or edition 4, but not edition 5, which was the W3C's way of breaking with backwards-compatibility without incrementing the version number of XML - i.e. it should have been XML 1.2).
On 7 September 2011 08:47, <mon...@em...<mailto:mon...@em...>> wrote:
Thank you Alexander and Collin!

My xml document is quite simple( prolog and main node ), with no DTD or CDATA.
That means the spaces in attributes' value should always be preserved, no matter the parser is validating or not.

It seems that Nenie xml parser should be corrected (it collapses the spaces and remove leading and tailing spaces unexpectedly.)
I intend to patch Nenie xml parser with the diff I find in
gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097<http://gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097>

But that one is for gobo xml parser, although I find the code is almost the same with Nenie xml parser.
Do you know the history between these two parsers?
And what's the better choice for me, patch Nenie xml parser, or replace the Nenie with gobo xml parser?

Thank you in advance.



-----Original Message-----
From: Colin Paul Adams [mailto:co...@co...<mailto:co...@co...>]
Sent: Wednesday, September 07, 2011 12:55 PM
To: gob...@li...<mailto:gob...@li...>
Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

>>>>> "Alexander" == Alexander Kogtenkov <kw...@ah...<mailto:kw...@ah...>> writes:

   Alexander> My feeling is that the processing expectations depend on
   Alexander> whether the XML parser is validating or not. The rule
   Alexander> that prevents the parser from attribute normalization is

   Alexander>     All attributes for which no declaration has been read
   Alexander> SHOULD be treated by a non-validating processor as if
   Alexander> declared CDATA.

   Alexander> And if attribute declarations are present we have

   Alexander>     If the attribute type is not CDATA, then the XML
   Alexander> processor MUST further [collapse white spaces].

   Alexander> So, a non-validating XML parser should not collapse the
   Alexander> white space characters, while the behaviour of the
   Alexander> validating one depends on the associated attribute
   Alexander> declaration.

And to spell it out, the Gobo XML parser is non-validating.
--
Colin Adams
Preston Lancashire
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org<http://www.asciiribbon.org>   - against proprietary attachments

------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
gobo-eiffel-develop mailing list
gob...@li...<mailto:gob...@li...>
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop


------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
gobo-eiffel-develop mailing list
gob...@li...<mailto:gob...@li...>
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

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

Eric can correct me if I'm wrong, but Nenie was Franck Arnaud's
domain/library, and Franck was the most recent maintainer of the Gobo XML
parser, so you should use the Gobo parser which has many updates. It should
fully comply with XML 1.0 edition 2 (or edition 3 or edition 4, but not
edition 5, which was the W3C's way of breaking with backwards-compatibility
without incrementing the version number of XML - i.e. it should have been
XML 1.2).

On 7 September 2011 08:47, <mon...@em...> wrote:

> Thank you Alexander and Collin!
>
> My xml document is quite simple( prolog and main node ), with no DTD or
> CDATA.
> That means the spaces in attributes' value should always be preserved, no
> matter the parser is validating or not.
>
> It seems that Nenie xml parser should be corrected (it collapses the spaces
> and remove leading and tailing spaces unexpectedly.)
> I intend to patch Nenie xml parser with the diff I find in
>
> gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097
>
> But that one is for gobo xml parser, although I find the code is almost the
> same with Nenie xml parser.
> Do you know the history between these two parsers?
> And what's the better choice for me, patch Nenie xml parser, or replace the
> Nenie with gobo xml parser?
>
> Thank you in advance.
>
>
>
> -----Original Message-----
> From: Colin Paul Adams [mailto:co...@co...]
> Sent: Wednesday, September 07, 2011 12:55 PM
> To: gob...@li...
> Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing
> library
>
> >>>>> "Alexander" == Alexander Kogtenkov <kw...@ah...> writes:
>
>    Alexander> My feeling is that the processing expectations depend on
>    Alexander> whether the XML parser is validating or not. The rule
>    Alexander> that prevents the parser from attribute normalization is
>
>    Alexander>     All attributes for which no declaration has been read
>    Alexander> SHOULD be treated by a non-validating processor as if
>    Alexander> declared CDATA.
>
>    Alexander> And if attribute declarations are present we have
>
>    Alexander>     If the attribute type is not CDATA, then the XML
>    Alexander> processor MUST further [collapse white spaces].
>
>    Alexander> So, a non-validating XML parser should not collapse the
>    Alexander> white space characters, while the behaviour of the
>    Alexander> validating one depends on the associated attribute
>    Alexander> declaration.
>
> And to spell it out, the Gobo XML parser is non-validating.
> --
> Colin Adams
> Preston Lancashire
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

[<mon...@em...>]

Thank you Alexander and Collin!

My xml document is quite simple( prolog and main node ), with no DTD or CDATA.
That means the spaces in attributes' value should always be preserved, no matter the parser is validating or not.

It seems that Nenie xml parser should be corrected (it collapses the spaces and remove leading and tailing spaces unexpectedly.)
I intend to patch Nenie xml parser with the diff I find in 
gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097

But that one is for gobo xml parser, although I find the code is almost the same with Nenie xml parser.
Do you know the history between these two parsers? 
And what's the better choice for me, patch Nenie xml parser, or replace the Nenie with gobo xml parser?

Thank you in advance.



-----Original Message-----
From: Colin Paul Adams [mailto:co...@co...] 
Sent: Wednesday, September 07, 2011 12:55 PM
To: gob...@li...
Subject: Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

>>>>> "Alexander" == Alexander Kogtenkov <kw...@ah...> writes:

    Alexander> My feeling is that the processing expectations depend on
    Alexander> whether the XML parser is validating or not. The rule
    Alexander> that prevents the parser from attribute normalization is

    Alexander>     All attributes for which no declaration has been read
    Alexander> SHOULD be treated by a non-validating processor as if
    Alexander> declared CDATA.

    Alexander> And if attribute declarations are present we have

    Alexander>     If the attribute type is not CDATA, then the XML
    Alexander> processor MUST further [collapse white spaces].

    Alexander> So, a non-validating XML parser should not collapse the
    Alexander> white space characters, while the behaviour of the
    Alexander> validating one depends on the associated attribute
    Alexander> declaration.

And to spell it out, the Gobo XML parser is non-validating.
-- 
Colin Adams
Preston Lancashire
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
gobo-eiffel-develop mailing list
gob...@li...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

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

>>>>> "Alexander" == Alexander Kogtenkov <kw...@ah...> writes:

    Alexander> My feeling is that the processing expectations depend on
    Alexander> whether the XML parser is validating or not. The rule
    Alexander> that prevents the parser from attribute normalization is

    Alexander>     All attributes for which no declaration has been read
    Alexander> SHOULD be treated by a non-validating processor as if
    Alexander> declared CDATA.

    Alexander> And if attribute declarations are present we have

    Alexander>     If the attribute type is not CDATA, then the XML
    Alexander> processor MUST further [collapse white spaces].

    Alexander> So, a non-validating XML parser should not collapse the
    Alexander> white space characters, while the behaviour of the
    Alexander> validating one depends on the associated attribute
    Alexander> declaration.

And to spell it out, the Gobo XML parser is non-validating.
-- 
Colin Adams
Preston Lancashire
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

[Alexander K. <kw...@ah...>]

My feeling is that the processing expectations depend on whether the XML
parser is validating or not. The rule that prevents the parser from attribute
normalization is

    All attributes for which no declaration has been read SHOULD be treated
    by a non-validating processor as if declared CDATA.

And if attribute declarations are present we have

    If the attribute type is not CDATA, then the XML processor MUST further
    [collapse white spaces].

So, a non-validating XML parser should not collapse the white space
characters, while the behaviour of the validating one depends on the
associated attribute declaration.

Regards,
Alexander Kogtenkov


----- Original Message ----- 
From: "Eric Bezault" <er...@go...>
To: "Gobo Developers Mailing List" <gob...@li...>
Sent: Wednesday, September 07, 2011 12:34 AM
Subject: [gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library




-------- Original Message --------
Subject: Question about Gobo xml parsing library
Date: Tue, 6 Sep 2011 05:40:50 -0400
From: <mon...@em...>
To: <gob...@li...>



Hi,

Sorry for the distribution of this mail, but I’ve no idea which person
should I send to.

Recently I’m get quite confused about the space normalization in Eiffel
xml parsing library.

I’m using nenie_mods and neniexml-01 library to parse xml, and I find
the spaces inside an attribute value will be collapsed, and the leading
and trailing spaces be discarded.

It seems that this behavior exactly conforms with the “Attribute-Value
Normalization” section in XML 1.0.

However, other xml parsing libaray, like Xerces C++ and JAXB, preserve
the spaces.

Also, when searched on Internet, I got this diff file applied to file
xm_eiffel_scanner.l:

http://gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097

My question is, which behavior is the right one? And why Xerces C++,
JAXB, and the patched gobo xml library don’t conform with XML 1.0?

Thank you very much!

Regards,

Wang, Monica

Shanghai China

Telephone: 86 021 60951100 2243 

[gobo-eiffel-develop] Fwd: Question about Gobo xml parsing library

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

-------- Original Message --------
Subject: 	Question about Gobo xml parsing library
Date: 	Tue, 6 Sep 2011 05:40:50 -0400
From: 	<mon...@em...>
To: 	<gob...@li...>



Hi,

Sorry for the distribution of this mail, but I’ve no idea which person
should I send to.

Recently I’m get quite confused about the space normalization in Eiffel
xml parsing library.

I’m using nenie_mods and neniexml-01 library to parse xml, and I find
the spaces inside an attribute value will be collapsed, and the leading
and trailing spaces be discarded.

It seems that this behavior exactly conforms with the “Attribute-Value
Normalization” section in XML 1.0.

However, other xml parsing libaray, like Xerces C++ and JAXB, preserve
the spaces.

Also, when searched on Internet, I got this diff file applied to file
xm_eiffel_scanner.l:

http://gobo-eiffel.git.sourceforge.net/git/gitweb.cgi?p=gobo-eiffel/gobo;a=commitdiff;h=374c3367994f573e2699e9df7ccb9e9372196097

My question is, which behavior is the right one? And why Xerces C++,
JAXB, and the patched gobo xml library don’t conform with XML 1.0?

Thank you very much!

Regards,

Wang, Monica

Shanghai China

Telephone: 86 021 60951100 2243

Re: [gobo-eiffel-develop] Which version of Gobo does compile out-of-the-box with ISE 6.7 ?

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

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

    Eric> SourceForge does not allow me to fix this information on the
    Eric> Web page.  So I might end up moving it to:

Move Gobo to origo?

But they might be svn only perhaps.

-- 
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] Which version of Gobo does compile out-of-the-box with ISE 6.7 ?

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

On 1/18/2011 9:00 AM, CRISMER Paul-Georges wrote:
> Hello,
> Which version of Gobo does compile out-of-the-box with ISE 6.7 ?
> Version 3.9 does not.
> Which version should I choose?
> I favor a version from the Gobo repository instead of the one packed by ISE.

Although not void-safe, the version from Gobo's git repository
on SourceForge compiles out-of-the-box with ISE 6.7.

Contrary to what SourceForge claims, the location of the git
repository is:

git://gobo-eiffel.git.sourceforge.net/gitroot/gobo-eiffel/gobo

SourceForge does not allow me to fix this information on the Web page.
So I might end up moving it to:

git://gobo-eiffel.git.sourceforge.net/gitroot/gobo-eiffel/gobo-eiffel

in order to be in sync with what SourceForge claims.

If you don't have git installed, you might find it convenient to
have a look at:

https://github.com/gobo-eiffel/gobo

It's a mirror of the SourceForge repository which I try to keep
in sync. Github has a download facility. Just click on the Download
big button and select either .tar.gz or .zip.

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