gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Cost of Unicode strings for ASCII data

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

I came across very slow behaviour for gexslt compared with saxon when 
dealing with a 21MB string.

I decided to investigate whether UC_UTF8_STRING performance was a major 
contributor to this, or not.

Well, I havent been able to answer this definitively, but I do have an 
interesting measure.

In a test Eiffel program, I read the entire file into a STRING_8, and I then 
created a new string from that data. The elapsed time of the program depends 
upon the dynamic type of the resulting string. Here are my timings:

STRING_8: 7 seconds
STRING_32: 13 seconds
UC_UTF8_STRING: 14 seconds.

Note that the STRING_8 was created by a call:

create {STRING_8} l_text.make_from_string (l_text). Is this doing a copy? If 
it is, then the overhaed is very heavy.

_________________________________________________________________
Tell Hotmail about an email that changed your life!  
http://www.emailbritain.co.uk/

[gobo-eiffel-develop] New release: Gobo 3.6

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

Hello,

A new release of Gobo is available from the usual locations:

     http://www.gobosoft.com/
     https://sourceforge.net/projects/gobo-eiffel/

This version should work with the forthcoming release of
ISE's EiffelStudio 6.0.

Note that the license has been changed since the last release.
Gobo packages are now released under the MIT license.

Also, in order to avoid binary file incompatibilities between
operating systems, the Gobo package does not contain executables
anymore. Instead of that, the directory $GOBO/bin contains the
C files of the Gobo Eiffel compiler which will be used by a script
to populate this directory with the binary files for your platform.
When installing the Gobo package, you will now have to run either:

     %GOBO%\install.bat msc

under Windows, or:

     $GOBO/install.sh gcc

under Unix/Linux in order to generate the binary files
of the Gobo tools in the directory $GOBO/bin.

Finally, note that the Visual Eiffel compiler is not
supported anymore. Indeed Visual Eiffel does not support
Agents, Tuples, INTEGER_64 among other things. The Gobo
project tried not to use these constructs so far, but
this is becoming too constraining.

For more details about this new release of Gobo, please
read the Readme file and the online documentation:

     http://www.gobosoft.com/eiffel/gobo/Readme.txt
     http://www.gobosoft.com/eiffel/gobo/index.html

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

Re: [gobo-eiffel-develop] Next release

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

>From: Eric Bezault <er...@go...>

>to hurry up and make a release of Gobo this week, before the
>"official" release of EiffelStudio 6.0. It would be nice if
>you could refrain from adding new stuff to Gobo SVN during this
>time. Thanks.

I added two fixes on the night of the 12th, but this message only showed up 
on the morning of the 13th.

_________________________________________________________________
Txt a lot? Get Messenger FREE on your mobile.  
https://livemessenger.mobile.uk.msn.com/

Re: [gobo-eiffel-develop] Next release

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

Emmanuel Stapf [ES] wrote:
>> One solution could be that we release Gobo 3.6 just after the 
>> last release candidate of EiffelStudio 6.0, and then it's the 
>> responsibility of ISE to test that Gobo 3.6 still works with 
>> the official EiffelStudio 6.0. How does that sound?
> 
> Sounds fine to me.

OK, I was waiting for the release candidates of EiffelStudio
to show up before starting the next release of Gobo, but I
just realized that there was no release candidates (at least
they have not been advertised as such). Therefore I will try
to hurry up and make a release of Gobo this week, before the
"official" release of EiffelStudio 6.0. It would be nice if
you could refrain from adding new stuff to Gobo SVN during this
time. Thanks.

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

Re: [gobo-eiffel-develop] [gobo-eiffel] Gobo and ISE 5.6

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

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Are there some people still using Gobo with ISE 5.6?  In
>     Eric> other words, should the next release of Gobo still work with
>     Eric> ISE 5.6?
> 
> I do, but more because of eposix 3, and because Gobo didn't support
> 5.7, I haven't switched. Happy to switch though.

Note that Gobo has been tested and works with ISE 5.7 and 6.0.
Not officially supporting 5.7 was just a political decision
to make ISE realize that introducing ECF was a bad thing and
that they should step back before it's too late. Unfortunately
to no avail since it is still in 6.0 ;-(

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

Re: [gobo-eiffel-develop] Gobo and ISE 5.6

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

Paul Cohen wrote:
>> In other words, should the next release of Gobo still work with ISE 5.6?
> 
> Yes, pretty please! Is it a big deal?

No big deal, it's just that it takes more time to test
many versions of the compiler and didn't want to waste
my time if nobody cared.

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

Re: [gobo-eiffel-develop] Gobo and ISE 5.6

[Paul C. <pac...@gm...>]

Hi,

On 5/30/07, Eric Bezault <er...@go...> wrote:
> Are there some people still using Gobo with ISE 5.6?

Yes.

> In other words, should the next release of Gobo still work with ISE 5.6?

Yes, pretty please! Is it a big deal?

/Paul

Re: [gobo-eiffel-develop] [gobo-eiffel] Gobo and ISE 5.6

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

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

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

    Eric> Are there some people still using Gobo with ISE 5.6?  In
    Eric> other words, should the next release of Gobo still work with
    Eric> ISE 5.6?

I do, but more because of eposix 3, and because Gobo didn't support
5.7, I haven't switched. Happy to switch though.

- -- 
All the best,

Berend de Boer


PS: This email has been digitally signed if you wonder what the strange
characters are that your email client displays.
PGP public key: http://www.pobox.com/~berend/berend-public-key.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFGXeZHIyuuaiRyjTYRAkPDAKC49t+oaGDR/Zl6hunLuDd9wfPMCQCdF+f2
hoJPqCgzV5GYVWS4cdJ/5WM=
=iBjM
-----END PGP SIGNATURE-----

[gobo-eiffel-develop] Gobo and ISE 5.6

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

Are there some people still using Gobo with ISE 5.6?
In other words, should the next release of Gobo still work with ISE 5.6?

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

[gobo-eiffel-develop] Bug in XML parser

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

I think this is an old bug. Anyway, I am going to add it to the tracker 
later today, and assign it to Franck.

I have just added an option to gexslt, --suppress-dtd, to suppress reading 
of external DTDs.
This is an occaisionally useful option, I think, but my reason for adding it 
was to attempt to compile the docbook XSLT 2.0 stylesheets, bypassing the 
known xml parser bugs.

Unfortunately, this doesn't work, since docbook quite sensibly uses internal 
DTD subsets, which can be bypassed. Still, this provides me with a way of 
tracking where the problems were.

The first one is, when parsing:

<!ENTITY sep '" "'>

I get:

sep:1:2:parse error

_________________________________________________________________
New, exclusive and FREE - Download Madonna's "Hey You" now!  
http://www.liveearth.msn.com

Re: [gobo-eiffel-develop] indenting text output filter

[Bernd S. <ber...@in...>]

At Thu, 24 May 2007 13:18:20 +0200,
Andreas Leitner wrote:
> KL_TEXT_OUTPUT_FILTER -- just having the forwarding bits, doing no
> transformation at all
> 
> KL_INDENTED_TEXT_OUTPUT_STREAM | _FILTER -- just containing the
> indentation bits
> 
> Your name is intuitive and conveys the idea very well though, so if we
> decide to hide the filtering metaphor, that's fine with me.

I fully agree, having the concept of output filter would be nice for
many applications. In the long run, might even consider building a
cluster of filters.

> > Or should the indentation facility be part of KI_TEXT_OUTPUT_STREAM
> > with an option to enable it or not? In fact we probably don't need
> > an option, the fact that `indent' is never called (and hence
> > `indentation' is kept to 0) should be enough. The questions are:
> > is it acceptable to add 2 attributes to class KI_TEXT_OUTPUT_STREAM,
> > and will the test to figure out that there is actually no indentation
> > to be printed be noticeable in terms of performance?
> 
> That would actually be nice, since you don't need to build a pipeline.
> On the other hand, I think a pipeline is quite intuitive and easy to
> build (once you know the pattern) and it spreads the functionality so
> that KI_TEXT_OUTPUT_STREAM itself is more easy to understand.

Hmm - I think we should keep interfaces small to make it easy to
implement new output streams. Blowing up interfaces with indentation
facilities seems wrong. Filters are the better way to go.
 
> > Note your implementation is not bullet-proof. It won't work if we
> > call `put_string' with an argument that contains newlines. Is that
> > acceptable? If yes, it should be clearly stated.
> 
> Yeah, that's a very good point. I made it a habit of never writing
> manifest newlines so it is not an issue. Processing `put_string' for
> newline is a potential performance problem. So I would opt for leaving
> it like it is. You are absolutely right though, we should state it in
> the header comment and maybe even in the indexing clause.

Best would be if we can toogle replacing newlines in strings with
'put_string' on- and off. Also, if it is off, do we need a
precondition in put_string to enforce that the string does not contain
newlines?

I would even vote for switching it on by default, because it is the
little more universal (though less efficient) choice.

Bernd

Re: [gobo-eiffel-develop] indenting text output filter

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

Andreas Leitner wrote:
>> Or should the indentation facility be part of KI_TEXT_OUTPUT_STREAM
>> with an option to enable it or not? In fact we probably don't need
>> an option, the fact that `indent' is never called (and hence
>> `indentation' is kept to 0) should be enough. The questions are:
>> is it acceptable to add 2 attributes to class KI_TEXT_OUTPUT_STREAM,
>> and will the test to figure out that there is actually no indentation
>> to be printed be noticeable in terms of performance?
> 
> That would actually be nice, since you don't need to build a pipeline.
> On the other hand, I think a pipeline is quite intuitive and easy to
> build (once you know the pattern) and it spreads the functionality so
> that KI_TEXT_OUTPUT_STREAM itself is more easy to understand.

OK, so we have a "filter" that introduces indentation. Should
KI_TEXT_OUTPUT_STREAM be implemented as a filter as well, which
introduces new-lines to character output streams? It looks too
heavy to me. So, where is the border-line between having things
in the stream and other things in a filter?

Also, for example for `put_character', the header-comment is
not correct. It says nothing about the indentation. What would
have happened if assertions could have been written to explicitly
state that the character `v' and only this character was written?

I understand that the filter pattern (it should have another
name in the GoF book) is very convenient because we can add
functionalities that we didn't think about when we wrote the
class, and we can combine them together in different ways.
The question is when should a functionality be added to the
class and when should it be added to a filter.

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

Re: [gobo-eiffel-develop] indenting text output filter

[Andreas L. <ale...@ra...>]

Hi Eric,

thanks for the quick reply.

On Thu, 2007-05-24 at 11:42 +0200, Eric Bezault wrote:

> I'm just trying to find a better name. If it *is* an output stream,
> then it is not a filter. What about KL_INDENTED_TEXT_OUTPUT_STREAM
> (should it really be in the kernel library, or elsewhere (where?))?

I wanted to call it something with OUTPUT_STREAM too initially, but then
I did think it was a little more than an outputstream. It is an output
stream that forwards things slightly modified to another output stream.
Which I think is just what is also called a filter in the xml event
cluster. In fact now that I think of it, the class could be split in
two:

KL_TEXT_OUTPUT_FILTER -- just having the forwarding bits, doing no
transformation at all

KL_INDENTED_TEXT_OUTPUT_STREAM | _FILTER -- just containing the
indentation bits

Your name is intuitive and conveys the idea very well though, so if we
decide to hide the filtering metaphor, that's fine with me.


> Or should the indentation facility be part of KI_TEXT_OUTPUT_STREAM
> with an option to enable it or not? In fact we probably don't need
> an option, the fact that `indent' is never called (and hence
> `indentation' is kept to 0) should be enough. The questions are:
> is it acceptable to add 2 attributes to class KI_TEXT_OUTPUT_STREAM,
> and will the test to figure out that there is actually no indentation
> to be printed be noticeable in terms of performance?

That would actually be nice, since you don't need to build a pipeline.
On the other hand, I think a pipeline is quite intuitive and easy to
build (once you know the pattern) and it spreads the functionality so
that KI_TEXT_OUTPUT_STREAM itself is more easy to understand.

> Note your implementation is not bullet-proof. It won't work if we
> call `put_string' with an argument that contains newlines. Is that
> acceptable? If yes, it should be clearly stated.

Yeah, that's a very good point. I made it a habit of never writing
manifest newlines so it is not an issue. Processing `put_string' for
newline is a potential performance problem. So I would opt for leaving
it like it is. You are absolutely right though, we should state it in
the header comment and maybe even in the indexing clause.

Andreas

Re: [gobo-eiffel-develop] indenting text output filter

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

Andreas Leitner wrote:
> Hi all:
> 
> I have been generating a lot of code over the years. Printing
> indentation was always a messy issue. It involved lots of unreadable '%
> T's.  I very much liked Eric's approach in gec where you have a tripple
> of rouintes (one for increasing indentation, one for decreasing and one
> for printing the current level).
> 
> I have generalized this approach now for Erl-G into an output filter. It
> is a class that you put in front of your actual text output stream. This
> class _is_ an outputstream with the two additional public commands of
> `indent' and `detent' (better names welcome!) and transparently prints
> indentation for every line to a given target output stream.
> 
> I have attached the class as it might be useful to others. Eric if you
> like it please feel free to include it in Gobo.

I'm just trying to find a better name. If it *is* an output stream,
then it is not a filter. What about KL_INDENTED_TEXT_OUTPUT_STREAM
(should it really be in the kernel library, or elsewhere (where?))?
Or should the indentation facility be part of KI_TEXT_OUTPUT_STREAM
with an option to enable it or not? In fact we probably don't need
an option, the fact that `indent' is never called (and hence
`indentation' is kept to 0) should be enough. The questions are:
is it acceptable to add 2 attributes to class KI_TEXT_OUTPUT_STREAM,
and will the test to figure out that there is actually no indentation
to be printed be noticeable in terms of performance?

Note your implementation is not bullet-proof. It won't work if we
call `put_string' with an argument that contains newlines. Is that
acceptable? If yes, it should be clearly stated.

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

[gobo-eiffel-develop] indenting text output filter

[Andreas L. <ale...@ra...>]

Hi all:

I have been generating a lot of code over the years. Printing
indentation was always a messy issue. It involved lots of unreadable '%
T's.  I very much liked Eric's approach in gec where you have a tripple
of rouintes (one for increasing indentation, one for decreasing and one
for printing the current level).

I have generalized this approach now for Erl-G into an output filter. It
is a class that you put in front of your actual text output stream. This
class _is_ an outputstream with the two additional public commands of
`indent' and `detent' (better names welcome!) and transparently prints
indentation for every line to a given target output stream.

I have attached the class as it might be useful to others. Eric if you
like it please feel free to include it in Gobo.

Andreas

Re: [gobo-eiffel-develop] Comment in {DS_LINEAR}.after misleading?

[Stefan S. <sie...@st...>]

> >The description "Is there no valid position to right of internal cursor?"
> >made
> >me think that 'after' is true whenever the cursor is on the _last_ item of
> >the linear (and not beyond). I assumed that "no valid position to the
> >right"
> >means that the next position will not point to an item of the container
> >anymore.
>
> That assumption is incorrect. The internal cursor has a valid position
> after the last item - the after-life sentinel (my (joke) terminiology).
>
> The point is that when you are on the last item, it is still valid to call
> `forth'. This will move the cursor forward (hence it's name), and the
> cursor has to go somewhere. It goes to the after-sentinel position. Now
> there is no longer a valid position, so you may no longer call `forth'.
Sorry for not being precise enough. Now I know that there's a valid position 
after the last item.
But I was not aware of this when I read the Description of 'after'.  To be 
honest, I was only interested in the items (to iterate through them), so I 
guess this is the reason why I didn't think of the sentinels before and after 
the items.

The description is 100% correct, I just interpreted it in a wrong way. Thus I 
assumed that there will be possibly other people who will get it wrong, too. 
Therefore I thought, it could be worth to think about the description.

Re: [gobo-eiffel-develop] Comment in {DS_LINEAR}.after misleading?

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

>From: Stefan Sieber <sie...@st...>

>
>Hi,
>
>The description of {DS_LINEAR}.after fooled me this morning ;) Andreas 
>Leitner
>suggested to contact the gobo mailing list, so this is what I'll do now...
>
>Here's {DS_LINEAR}.after:
>
>	after: BOOLEAN is
>			-- Is there no valid position to right of internal cursor?
>		do
>			Result := cursor_after (internal_cursor)
>		end
>
>The description "Is there no valid position to right of internal cursor?" 
>made
>me think that 'after' is true whenever the cursor is on the _last_ item of
>the linear (and not beyond). I assumed that "no valid position to the 
>right"
>means that the next position will not point to an item of the container
>anymore.

That assumption is incorrect. The internal cursor has a valid position after 
the last item - the after-life sentinel (my (joke) terminiology).

The point is that when you are on the last item, it is still valid to call 
`forth'. This will move the cursor forward (hence it's name), and the cursor 
has to go somewhere. It goes to the after-sentinel position. Now there is no 
longer a valid position, so you may no longer call `forth'.

_________________________________________________________________
The next generation of Hotmail is here! http://www.newhotmail.co.uk

[gobo-eiffel-develop] Comment in {DS_LINEAR}.after misleading?

[Stefan S. <sie...@st...>]

Hi,

The description of {DS_LINEAR}.after fooled me this morning ;) Andreas Leitner 
suggested to contact the gobo mailing list, so this is what I'll do now...

Here's {DS_LINEAR}.after:

	after: BOOLEAN is
			-- Is there no valid position to right of internal cursor?
		do
			Result := cursor_after (internal_cursor)
		end

The description "Is there no valid position to right of internal cursor?" made 
me think that 'after' is true whenever the cursor is on the _last_ item of 
the linear (and not beyond). I assumed that "no valid position to the right" 
means that the next position will not point to an item of the container 
anymore.

I don't know if I can propose any better description, as I'm no library 
designer and I believe that you had your reasons to choose this description. 
All i can say is that I expected something more in the style of "Is the 
internal cursor on the position after the last item?". Unfortunately this 
doesn't contain the information that the position right to the cursor is 
invalid, which is quite important, too.

Regards,

Stefan

Re: [gobo-eiffel-develop] Next release

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

> One solution could be that we release Gobo 3.6 just after the 
> last release candidate of EiffelStudio 6.0, and then it's the 
> responsibility of ISE to test that Gobo 3.6 still works with 
> the official EiffelStudio 6.0. How does that sound?

Sounds fine to me.

Thanks,
Manu

Re: [gobo-eiffel-develop] Bug tracker on sourceforge

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

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

    Eric> Colin Paul Adams wrote:
    >> In any case, one of the annoying things about the sourceforge
    >> trackers is you can NEVER delete a category or group once you
    >> have created one.  So we are stuck with this now (it would be
    >> too confusing to have both XSLT and xml/xslt).

    Eric> We cannot delete, but we can rename (that's why I created
    Eric> them before waiting for your answer). So it is still
    Eric> possible to rename xslt as xml/xslt.

I wish I had known that long ago! I made a complete mess of the
gestalt bug-tracker classifications.

I think xml/xslt is unnecessarily complicated.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Bug tracker on sourceforge

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

Colin Paul Adams wrote:
> In any case, one of the annoying things about the sourceforge trackers
> is you can NEVER delete a category or group once you have created one.
> 
> So we are stuck with this now (it would be too confusing to have both
> XSLT and xml/xslt).

We cannot delete, but we can rename (that's why I created them before
waiting for your answer). So it is still possible to rename xslt as
xml/xslt.

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

Re: [gobo-eiffel-develop] Bug tracker on sourceforge

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

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

    Eric> Eric Bezault wrote:
    >> Colin Paul Adams wrote:
    >>>>>>>> "Bernd" == Bernd Schoeller <ber...@in...>
    >>>>>>>> writes:
    >>> >> I received no suggestions yet for Categories and Groups to
    >>> be >> used in the bug tracker.
    >>> 
    Bernd> - For "Category", we go for the different subfolders under
    Bernd> "library" and unter "src". Also, we might add "Other"
    >>>  I would like XSLT, XPath and XPointer added as separate
    >>> categories.
    >> Oops, not done yet.

    Eric> Done now.

    Eric> I wonder whether it should actually be xml/xslt, xml/xpath
    Eric> and xml/xpointer in order to show that they are under xml in
    Eric> the library hierarchy.

I wouldn't have thought so.

In any case, one of the annoying things about the sourceforge trackers
is you can NEVER delete a category or group once you have created one.

So we are stuck with this now (it would be too confusing to have both
XSLT and xml/xslt).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Bug tracker on sourceforge

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

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

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> I did that. I was not sure whether we should just have a
    >> Bug
    Eric> Tracker, or also a Feature Request Tracker. What's your
    Eric> opinion?
    >> I think yes.  And any feature requests not self-assigned by
    >> anyone after one month, can be assigned to the requester :-)

    Eric> Unfortunately I don't see an option to do that
    Eric> automatically.

I was only joking.
We can only assign to people with a sourceforge id which is a
developer for the project, I think.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Bug tracker on sourceforge

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> I did that. I was not sure whether we should just have a Bug
>     Eric> Tracker, or also a Feature Request Tracker. What's your
>     Eric> opinion?
> 
> I think yes.
> 
> And any feature requests not self-assigned by anyone after one month,
> can be assigned to the requester :-)

Unfortunately I don't see an option to do that automatically.

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

Re: [gobo-eiffel-develop] Bug tracker on sourceforge

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>>>>>>> "Bernd" == Bernd Schoeller <ber...@in...> writes:
>>     >> I received no suggestions yet for Categories and Groups to be
>>     >> used in the bug tracker.
>>
>>     Bernd> - For "Category", we go for the different subfolders under
>>     Bernd> "library" and unter "src". Also, we might add "Other"
>>
>> I would like XSLT, XPath and XPointer added as separate categories.
> 
> Oops, not done yet.

Done now.

I wonder whether it should actually be xml/xslt, xml/xpath
and xml/xpointer in order to show that they are under xml
in the library hierarchy.

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