gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Arguments for UT_URI creation procedures

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

Colin Paul Adams wrote:
> Would there be a problem if these were changed from STRING(_8) to READABLE_STRING_GENERAL?

Yes: READABLE_STRING_GENERAL does not exist in ISE 6.2.
As a first step, we could use STRING_GENERAL while waiting
for the move to ISE 6.3.

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

[gobo-eiffel-develop] Arguments for UT_URI creation procedures

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

Would there be a problem if these were changed from STRING(_8) to READABLE_STRING_GENERAL?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

2008/8/19 Franck Arnaud <fr...@ne...>:

>> If the compiler can implement tail recursion, why can't you?
>
> well you can actually:

Me?? I was asking about you!

>>     Franck> all else fails you can always fallback on recursion but
>> Oh no you can't!
>
> in what way?

You will run out of stack space.

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

> No it doesn't. What about variant and invariant? Does it go without
> saying that you are going to remove invariant?

It goes without saying for variant, and it goes without saying that the
non-loop invariant stays.

> And until might want to be re-used.

yes, I'm only talking of the looping construct, it might indeed be an
opportunity to reuse the keywords, keyword reuse would require some
saying.
 
>     Franck> INTEGER_INTERVAL.do_all, I'd use recursion, it would help
>     Franck> if the compiler recognises it in some way so that the
>     Franck> generated code does not use stack space, but it's the only
>     Franck> place where you need a slight implementation-level cheat.
> 
> If the compiler can implement tail recursion, why can't you?

well you can actually:

class INTEGER_INTERVAL
...
  do_all (a_agent: PROCEDURE [ANY, TUPLE[INTEGER])
     -- Apply to all integers between 'lower' and 'upper'.
    local
      i: INTEGER
    do
       if i <= count then
         a_agent.call ([i + lower])
         i := i + 1
         raise ("forth")
       end -- else exit loop
    rescue
       retry
    end
end

arguably that's a bit sick. but it also confirms that we have too many
looping constructs as we stand. also a drawback is that when I will
suggest removing "retry" you're going to argue that we need it to
implement INTEGER_INTERVAL :-).

>     Franck> as for loops which are open ended and not index-based, (1
>     Franck> |..| Maximum_integer).do_until should be OK, and again if
> 
> Not for network servers which implement do forever until shutdown
> request. This might well exceed Maximum_integer.

that's debatable. with 64 bit integers you can do_forever 1 billion
times a second for 100 years, which is a hell of an uptime for a network
server, and a hell of a lot of transaction throughput. for 32 bit it is
perhaps slightly more debatable but then you can implement 64 bit one on
top of 2 32 bits ones.

>     Franck> all else fails you can always fallback on recursion but
> Oh no you can't!

in what way?

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

>>>>> "Franck" == Franck Arnaud <fr...@ne...> writes:

    >> Are you going to remove "from" and "until" as well?

    Franck> it goes without saying.

No it doesn't. What about variant and invariant? Does it go without
saying that you are going to remove invariant? And until might want to
be re-used.

    Franck> INTEGER_INTERVAL.do_all, I'd use recursion, it would help
    Franck> if the compiler recognises it in some way so that the
    Franck> generated code does not use stack space, but it's the only
    Franck> place where you need a slight implementation-level cheat.

If the compiler can implement tail recursion, why can't you?

    Franck> as for loops which are open ended and not index-based, (1
    Franck> |..| Maximum_integer).do_until should be OK, and again if

Not for network servers which implement do forever until shutdown
request.
This might well exceed Maximum_integer.

    Franck> all else fails you can always fallback on recursion but

Oh no you can't!
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

> Are you going to remove "from" and "until" as well?

it goes without saying.

> How do you intend to implement {G}.do_all (where G is ARRAY, etc.)?

 do_all (a_agent: PROCEDURE[ANY, TUPLE[G]])
   do
     (lower |..| upper).do_all (agent do_one (a_agent, ?))
   end

 do_one (a_agent: PROCEDURE[ANY, TUPLE[G]; a_index: INTEGER)
   do
     a_agent.call ([item (a_index)])
   end

I feel you're going to ask how I implement INTEGER_INTERVAL.do_all, I'd
use recursion, it would help if the compiler recognises it in some way
so that the generated code does not use stack space, but it's the only
place where you need a slight implementation-level cheat.

as for loops which are open ended and not index-based, (1 |..|
Maximum_integer).do_until should be OK, and again if all else fails you
can always fallback on recursion but you shouldn't have to. I think all
loops I have written in the past few years are either straightforward
container loops or fit well within the Maximum_integer boundary.

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

Are you going to remove "from" and "until" as well?

How do you intend to implement {G}.do_all (where G is ARRAY, etc.)?

2008/8/14 Franck Arnaud <fr...@ne...>:
>> But I digress, this is not the place for language ideas. I should write
>> a wiki page on the idea.
>
> Are they good ideas in the first place? Both the "file" and the "cursor"
> problems can be dealt with by using the existing language constructs.
>
> For cursors, CONTAINER.do_all captures most cases where you used to use
> cursors directly in the past, and we could add a do_until if you're
> worried about having to prefix your do_all agent with a "if not stopped"
> for partial traversals. It manages the cursor for you, no leak possible,
> plus termination guarantee and it makes the code more amenable to
> automatic code analysis.
>
> The legacy construct "loop" is rarely needed in day to day programming
> nowadays, and when it is, it's often because the appropriate container
> is missing the right agent API.
>
> For files, I think our files API may not have been updated yet, but you
> can trivially devise an agent-based API that handles file closure
> nicely, e.g.
>
>  read_file (a_filename: STRING; a_line_processor: PROCEDURE [ANY, TUPLE
>  [STRING]])
>
> I don't think you should add more clutter to the language when the
> existing features cope with the problem very nicely.
>
> I think I'll go and write a wiki page on my proposal to remove "loop"
> from the language :-).
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

> But I digress, this is not the place for language ideas. I should write 
> a wiki page on the idea.

Are they good ideas in the first place? Both the "file" and the "cursor"
problems can be dealt with by using the existing language constructs.

For cursors, CONTAINER.do_all captures most cases where you used to use
cursors directly in the past, and we could add a do_until if you're
worried about having to prefix your do_all agent with a "if not stopped"
for partial traversals. It manages the cursor for you, no leak possible,
plus termination guarantee and it makes the code more amenable to
automatic code analysis.

The legacy construct "loop" is rarely needed in day to day programming
nowadays, and when it is, it's often because the appropriate container
is missing the right agent API.

For files, I think our files API may not have been updated yet, but you
can trivially devise an agent-based API that handles file closure
nicely, e.g.

  read_file (a_filename: STRING; a_line_processor: PROCEDURE [ANY, TUPLE
  [STRING]])

I don't think you should add more clutter to the language when the
existing features cope with the problem very nicely.

I think I'll go and write a wiki page on my proposal to remove "loop"
from the language :-).

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

[Paul B. <pa...@ei...>]

Weak references is something I have been asking for, for a while now. I 
remember Manu telling me it would be possible to implement that now with 
support from existing classes, but it would be far better if there was 
ECMA specification support. Another way would be to perform automatic, 
safe clean up via language support:

using {f: RAW_FILE} create {RAW_FILE}.make_open_write (fn)
	f.put ("hello world")
end

On completion of the code block f.dispose is called, even if there was 
an exception. That way the file is close during both normal and abnormal 
operations. Then if the Gobo cursor structures implemented DISPOSABLE to 
perform the clean up, then it would be simple:

using (c: DS_LINEAR_CURSOR [STRING]} list.new_cursor
	...
end

But I digress, this is not the place for language ideas. I should write 
a wiki page on the idea.

Paul.

Bernd Schoeller wrote:
> Hi Paul,
> 
> it is indeed a "know issue" that GOBO cursors can produce these memory  
> leaks. The "solution" is to make sure that the cursor is always off after  
> an iteration. That way it is not referenced by the data structure anymore  
> and will get garbage collected.
> 
> The proper solution would be to introduce weak references into the Eiffel  
> language. I am not sure if there is any work on this as part of ECMA.
> 
> Bernd
> 
> On Mon, 11 Aug 2008 20:41:31 +0200, Paul Bates <pa...@ei...> wrote:
> 
>> We've detected a memory leak when using gobo data structure cursors that
>> do not run to the end, and currently there is no way to clean them up
>> nicely.
>>
>> Take the following code
>>
>> f (a_list: !DS_LINEAR [?ANY])
>>    local
>>      l_cursor: DS_LINEAR_CURSOR [?ANY]
>>      l_stop: BOOLEAN
>>    do
>>      l_cursor := a_list.cursor
>>      from l_cursor.start until l_cursor.after or l_stop loop
>>        l_stop := l_cursor.item = Void
>>        if not l_stop then
>>          l_cursor.forth
>>        end
>>      end
>>    end
>>
>> Passing a linear structure to 'f' where any item is Void will cause the
>> leak because the list never goes 'off'. We cannot call
>> DS_TRAVERSABLE.remove_traversing_cursor and it is not a good idea to do
>> so because it may have not been added the the managed list or cursors,
>> given the current lazy-eval implementation.
>>
>> The current solution is to run out the cursor in another loop or run out
>> the cursor in the original loop but conditionally process the loop's
>> functional body. Neither of which look that nice.
>>
>> Best,
>> Paul.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great  
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the  
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 
> 

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

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

Hi Paul,

it is indeed a "know issue" that GOBO cursors can produce these memory  
leaks. The "solution" is to make sure that the cursor is always off after  
an iteration. That way it is not referenced by the data structure anymore  
and will get garbage collected.

The proper solution would be to introduce weak references into the Eiffel  
language. I am not sure if there is any work on this as part of ECMA.

Bernd

On Mon, 11 Aug 2008 20:41:31 +0200, Paul Bates <pa...@ei...> wrote:

> We've detected a memory leak when using gobo data structure cursors that
> do not run to the end, and currently there is no way to clean them up
> nicely.
>
> Take the following code
>
> f (a_list: !DS_LINEAR [?ANY])
>    local
>      l_cursor: DS_LINEAR_CURSOR [?ANY]
>      l_stop: BOOLEAN
>    do
>      l_cursor := a_list.cursor
>      from l_cursor.start until l_cursor.after or l_stop loop
>        l_stop := l_cursor.item = Void
>        if not l_stop then
>          l_cursor.forth
>        end
>      end
>    end
>
> Passing a linear structure to 'f' where any item is Void will cause the
> leak because the list never goes 'off'. We cannot call
> DS_TRAVERSABLE.remove_traversing_cursor and it is not a good idea to do
> so because it may have not been added the the managed list or cursors,
> given the current lazy-eval implementation.
>
> The current solution is to run out the cursor in another loop or run out
> the cursor in the original loop but conditionally process the loop's
> functional body. Neither of which look that nice.
>
> Best,
> Paul.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great  
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the  
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop



-- 
Bernd Schoeller, PhD, CTO
Comerge AG, Technoparkstrasse 1, CH-8005 Zurich, Switzerland

Re: [gobo-eiffel-develop] Memory leak with cursors and data structures

[Paul B. [ES] <pa...@ei...>]

I did subscribe but I didn't search the entire newsgroup, my apologies. 

The reason I do not code a loop as suggested is because with heavy
loaded list this would be inefficient because the whole loop has to be
processed.

Paul.

On Tue, 2008-08-12 at 08:40 +0200, Eric Bezault wrote:
> Paul Bates wrote:
> > We've detected a memory leak when using gobo data structure cursors that 
> > do not run to the end, and currently there is no way to clean them up 
> > nicely.
> > 
> > Take the following code
> > 
> > f (a_list: !DS_LINEAR [?ANY])
> >    local
> >      l_cursor: DS_LINEAR_CURSOR [?ANY]
> >      l_stop: BOOLEAN
> >    do
> >      l_cursor := a_list.cursor
> >      from l_cursor.start until l_cursor.after or l_stop loop
> >        l_stop := l_cursor.item = Void
> >        if not l_stop then
> >          l_cursor.forth
> >        end
> >      end
> >    end
> > 
> > Passing a linear structure to 'f' where any item is Void will cause the 
> > leak because the list never goes 'off'. We cannot call 
> > DS_TRAVERSABLE.remove_traversing_cursor and it is not a good idea to do 
> > so because it may have not been added the the managed list or cursors, 
> > given the current lazy-eval implementation.
> > 
> > The current solution is to run out the cursor in another loop or run out 
> > the cursor in the original loop but conditionally process the loop's 
> > functional body. Neither of which look that nice.
> 
> You "discovered" something that is not new:
> 
>    http://www.gobosoft.com/eiffel/gobo/structure/traversal.html
> 
> Look at the red comment. Why don't you write your code like this:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> f (a_list: !DS_LINEAR [?ANY])
>     local
>       l_cursor: DS_LINEAR_CURSOR [?ANY]
>     do
>       l_cursor := a_list.cursor
>       from l_cursor.start until l_cursor.after loop
>         if l_cursor.item = Void then
>           ... do something interesting here ...
>           l_cursor.go_after
>         else
>           l_cursor.forth
>         end
>       end
>     end
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> as suggested in the doc? Note that `go_after' is a routine that
> I miss very much in the EiffelBase containers.
> 
> 
> PS: Please subscribe to the mailing list before posting.
> 
-- 
------------------------------------------------------------------------  
Eiffel Software 
805-685-1006 ext. 107
http://www.eiffel.com

Blog: http://www.eiffelroom.com/blog/paulbates
Wiki: http://dev.eiffel.com
------------------------------------------------------------------------  

[gobo-eiffel-develop] Memory leak with cursors and data structures

[Paul B. <pa...@ei...>]

We've detected a memory leak when using gobo data structure cursors that 
do not run to the end, and currently there is no way to clean them up 
nicely.

Take the following code

f (a_list: !DS_LINEAR [?ANY])
   local
     l_cursor: DS_LINEAR_CURSOR [?ANY]
     l_stop: BOOLEAN
   do
     l_cursor := a_list.cursor
     from l_cursor.start until l_cursor.after or l_stop loop
       l_stop := l_cursor.item = Void
       if not l_stop then
         l_cursor.forth
       end
     end
   end

Passing a linear structure to 'f' where any item is Void will cause the 
leak because the list never goes 'off'. We cannot call 
DS_TRAVERSABLE.remove_traversing_cursor and it is not a good idea to do 
so because it may have not been added the the managed list or cursors, 
given the current lazy-eval implementation.

The current solution is to run out the cursor in another loop or run out 
the cursor in the original loop but conditionally process the loop's 
functional body. Neither of which look that nice.

Best,
Paul.

Re: [gobo-eiffel-develop] gobo/gcc error message

[Müller G. <glm...@st...>]

Hi Franck Arnaud

Sorry my fault I meant in fact milliseconds. I had also
already written something measuring milliseconds. 
Not sure why you didnt get that email tho so i attach it
again.

To this list: I made a second typo: 
I wrote something like "ISE Eiffel _compiler_ crashes"
What i meant is that the Eiffel Studio crashes. 

Does anyone know how to use the ISE compiler on the
comand line? I am using Mac.


Thanks for your help

Gloria

Re: [gobo-eiffel-develop] gobo/gcc error message

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

Müller Gloria:

> Something unrelated. I wanted to time my code. Is it really that Eiffel
> can only measure time up to a precision of seconds? If I want to time 
> my code I need at least nanoseconds.

"at least"? you know typical CPUs have a frequency of about 2GHz that is
1 cycle is about 0.5 nanoseconds. I don't think anyone needs to measure
any kind of high level code at that level of granularity. besides I
don't think you can implement that precision, just the operation of
taking the measurement (in so far as there is any hardware you can buy
that has the capability) and giving it back to you is going to take
multiple instructions thus already way above your precision...

that said, depending on the application, milliseconds might be useful.

> Using command line "time" is inconvenient.

and it's not going to give you nanosecond precision either.

Re: [gobo-eiffel-develop] gobo/gcc error message

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

Forwarded to the list.

Eric Bezault wrote:
> Müller Gloria wrote:
>> ~~~~~~~~~~~~~~~~~~~~
>>     make(first_item: G) is
>>         local
>>             tmp: INTEGER_64
>>         do
>>             tmp := 2
>>             tmp ?= first_item
>>             print (tmp)
>>         end
>> ~~~~~~~~~~~~~~~~~~~~
>>
>>> the program will print 2, and not 1 or 0. It's because ISE does not
>>> change the value of the target when the assignment attempt fails.
>> But in my example the assignment shoudln't fail because G is INTEGER_32. 
> 
> INTEGER_32 does not conform to INTEGER_64, so the assignment
> attempt fails. There is no conversion involved in assignment
> attempts, so the fact that INTEGER_32 converts to INTEGER_64
> does not help.
> 

Re: [gobo-eiffel-develop] gobo/gcc error message

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

Forwarded to the list.

Müller Gloria wrote:
> Hi Eric
> 
> 
> ~~~~~~~~~~~~~~~~~~~~
> 	make(first_item: G) is
> 		local
> 			tmp: INTEGER_64
> 		do
> 			tmp := 2
> 			tmp ?= first_item
> 			print (tmp)
> 		end
> ~~~~~~~~~~~~~~~~~~~~
> 
>> the program will print 2, and not 1 or 0. It's because ISE does not
>> change the value of the target when the assignment attempt fails.
> But in my example the assignment shoudln't fail because G is INTEGER_32. 
> 
> But never mind ISE I don't use it. I can't fiddle around with something that
> constantly crashes because of "internal errors".
> Gobo has "internal errors" too. But at least gobo doesn't crash so it doesn't 
> bother me.
> 
>> You would have to find an Eiffel date/time library which supports
>> nanoseconds, or write one if one does not exist yet. The Gobo
> Yes I was wondering whether anyone knows of an existing one. 
> I have already written something. It's not a library though but it
> does what I need.
> 
> 
> Kind regards,
> 
> Gloria
> 

Re: [gobo-eiffel-develop] (timing)

[Müller G. <glo...@st...>]

Hi,

Thanks for the quick answer! 
I have already written something (see the attachment).
It does nanoseconds, at least on mac. I'd be interested if
it also works on Linux. I assume it should. 

> If you do wrap HPET I would be glad to use it! ;-)

Is this of any use to you?



Kind regards,


Gloria

Re: [gobo-eiffel-develop] gobo/gcc error message

[Paul C. <pa...@se...>]

Hi,

On Wed, Aug 6, 2008 at 12:03 PM, Eric Bezault <er...@go...> wrote:
> Müller Gloria wrote:
>> Something unrelated. I wanted to time my code. Is it really that Eiffel can only measure
>> time up to a precision of seconds? If I want to time my code I need at least nanoseconds.
>> Any idea how to do this? Using command line "time" is inconvenient. I want to measure
>> time of little code pieces not of the entire app.
>
> You would have to find an Eiffel date/time library which supports
> nanoseconds, or write one if one does not exist yet. The Gobo
> date/time library is indeed limited to milliseconds. You may have
> a look at ISE's EiffelTime library, but I think that it has the same
> limitation when calling `make_now'.

High precision timing is very dependent on the hardware and operating
system you are using. Millisecond resolution should be good enough for
most non-embedded situations.

On Linux you could try wrapping the High Precision Event Timer (HPET)
and you could maybe achieve nanoseconds resolution. I'm not sure. See:

    http://en.wikipedia.org/wiki/High_Precision_Event_Timer

See here for an example C program using HPET:

    http://www.mjmwired.net/kernel/Documentation/hpet.txt

If you do wrap HPET I would be glad to use it! ;-)

/Paul

-- 
Paul Cohen
mobile: +46 730 787 035
e-mail: pau...@se...

Re: [gobo-eiffel-develop] gobo/gcc error message

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

Hi Gloria,

Müller Gloria wrote:
> I found a way to make gec produce this:
> 
> feiffel1.c: In function ‘T22c1’:
> feiffel1.c:272: warning: assignment makes integer from pointer without a cast
> 
> 
> To do this you create a class with a generic parameter e.g. like this:
> 
> 
> class
> 	BUG_REPORT_1_SHORT[G]
> 	
> create
> 	make
> 
> feature -- Initialization
> 
> 	make(first_item: G) is
> 		local
> 			tmp: INTEGER_64
> 		do
> 			tmp ?= first_item
> 		end
> 		
> end -- class
> 
> 
> Then you call make from another class, e.g. like this:
> 
> 
> 		local
> 			i: INTEGER
> 			sw: BUG_REPORT_1_SHORT[INTEGER]
> 		do
> 			create sw.make(1)
> 		end

I now fixed it in the version in SVN to have the same behavior as
ISE, and the C compilation warning should be fixed as well.

The problem was that this code should have been flagged with a
VJRV validity error according to ETL2 (this construct does not
exist anymore in ECMA Eiffel, replaced by object-tests) because
the target is expanded. I had removed this validity error checking
in Gobo because ISE also removed it a while ago, but I had forgotten
to update the code generation.

However note that the behavior in ISE (and now in Gobo) may be weird
at first. In your example, if I remplace the routine `make' by:

~~~~~~~~~~~~~~~~~~~~
	make(first_item: G) is
		local
			tmp: INTEGER_64
		do
			tmp := 2
			tmp ?= first_item
			print (tmp)
		end
~~~~~~~~~~~~~~~~~~~~

the program will print 2, and not 1 or 0. It's because ISE does not
change the value of the target when the assignment attempt fails.
Note that it would have made more sense to set the target to its
default value in that case (which would be 0 for INTEGER_64) in
order to have a behavior similar to the case of reference types
where the target is set to Void (which is nothing else than the
default value of reference types).

> Something unrelated. I wanted to time my code. Is it really that Eiffel can only measure
> time up to a precision of seconds? If I want to time my code I need at least nanoseconds.
> Any idea how to do this? Using command line "time" is inconvenient. I want to measure
> time of little code pieces not of the entire app.

You would have to find an Eiffel date/time library which supports
nanoseconds, or write one if one does not exist yet. The Gobo
date/time library is indeed limited to milliseconds. You may have
a look at ISE's EiffelTime library, but I think that it has the same
limitation when calling `make_now'.

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

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Hi Eric,

I was very busy during the last weeks. As soon as I find some time, I 
will have a look at the classes once again to make some more 
improvements, as the one you mentioned.

Regards,
Daniel

Eric Bezault wrote:
> Hi Daniel,
>
> Your binary search tree classes are now committed to SVN in
> the SourceForge Gobo project. As agreed, I made some name
> changes and some header comments and reformatting to better
> match Gobo's style guildelines. I also removed the unnecessary
> `void_is_valid_key' and merged `equality_tester' with `comparator'.
> I probably did some other minor changes, such as making sure
> that "key" features are not exported in the set classes
> (set classes don't have the notion of keys in their interface).
>
> I didn't review the binary search tree algorithms. But I think
> that some improvements can be made. For example, would it be
> possible to redefine `cursor_search_forth' and `cursor_search_back'
> in DS_BINARY_SEARCH_TREE_SET, to take advantage that the items
> are sorted, and hence avoid linear traversal?
>
> Also, I think that `internal_put' and `internal_put_new' deserve
> some postconditions that should match those of DS_SET and DS_TABLE
> so that when they are used to implement the corresponding features
> in set and table variants the code is correct in terms of DbC.
>

[gobo-eiffel-develop] gobo/gcc error message

[Müller G. <glo...@st...>]

Hi all


I found a way to make gec produce this:

feiffel1.c: In function ‘T22c1’:
feiffel1.c:272: warning: assignment makes integer from pointer without a cast


To do this you create a class with a generic parameter e.g. like this:


class
	BUG_REPORT_1_SHORT[G]
	
create
	make

feature -- Initialization

	make(first_item: G) is
		local
			tmp: INTEGER_64
		do
			tmp ?= first_item
		end
		
end -- class


Then you call make from another class, e.g. like this:


		local
			i: INTEGER
			sw: BUG_REPORT_1_SHORT[INTEGER]
		do
			create sw.make(1)
		end


Kind regards,

Gloria


PS: 
Something unrelated. I wanted to time my code. Is it really that Eiffel can only measure
time up to a precision of seconds? If I want to time my code I need at least nanoseconds.
Any idea how to do this? Using command line "time" is inconvenient. I want to measure
time of little code pieces not of the entire app.

Re: [gobo-eiffel-develop] ma_decimal update

[Paul G. C. <pau...@sc...>]

Hello Ivan,

Do you mean you'll use the GDA specification 1.68 which is the same as 
the latest IEEE 754r standard?
Will you use the testcases from http://www2.hursley.ibm.com/decimal/ ?

I'm very committed to backward compatibility. How will you achieve such 
compatibility between te current MA_DECIMAL and the IEEE754R one ?

Best regards,

Paul G. Crismer

itt wrote:
> Hi list and especially Paul,
>
> I am going to update the MA_DECIMAL to the latest IEEE-SA 754r spec. I
> will work with Eric to get the updates committed to SVN.
>
> Cheers,
> Ivan
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>
>   

[gobo-eiffel-develop] svn update

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

If you get a new version from SVN using 'update', you will
have to run:

    geant clobber
    geant install

Otherwise you might get several classes with the same name.

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

Re: [gobo-eiffel-develop] Bug in gec ?

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

Hi Lothar,

This is an exact / precise collector.

The primary requirement, above all else, is that it be reliable and to
that end I have been including vast [it seems] numbers of assertions
in the C implementation.

It is not yet either compacting or generational. Until I can reliably
demonstrate that marking the stack is a precise process, anything
else is superfluous.

A derivative of the primary requirement is that I must be able to understand
it (!), which will also help once I put it out for others to use in the fairly
near future, subject to it working correctly when integrated with gec.

I want to be able to implement long running daemon programs using gec,
[my variant of it] with multi-threading, and I while I am happy that Boehm et al
works in a single thread system, I am not convinced that it would work the
way I want it to for my planned systems.

Regards,

Howard

On Friday 25 Jul 2008, Lothar Scholz wrote:
> Hello Howard,
> 
> Thursday, July 24, 2008, 11:00:52 PM, you wrote:
> 
> HT> Thanks Eric for the fix as below.
> 
> HT> I am continuing to develop my custom Garbage Collector for gec, with
> HT> four outstanding routines needed before stress testing.
> 
> Is this a conservative or an exact garbage collector.
> Sometimes i dream about a precise concurrent compacting garbage collector.
> 



-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Bug in gec ?

[Lothar S. <ll...@we...>]

Hello Howard,

Thursday, July 24, 2008, 11:00:52 PM, you wrote:

HT> Thanks Eric for the fix as below.

HT> I am continuing to develop my custom Garbage Collector for gec, with
HT> four outstanding routines needed before stress testing.

Is this a conservative or an exact garbage collector.
Sometimes i dream about a precise concurrent compacting garbage collector.

-- 
Best regards,
 Lothar                            mailto:ll...@we...