gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Short options ambiguity in AP_OPTION

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

On Mon, 01 Oct 2007 21:52:12 +0200, Colin Adams  
<col...@ho...> wrote:

>
> I have checked it in now.
>
> Go to example/xml/xslt/serializer and do a geant compile_debug_ise.
>
> Now you can try the commands:
>
> ./serializer -p jim -s fred
>
> and
>
> ./serializer -p fred -p jim
>
> Neither will give any output, nor any error (which is correct).
>
> Now edit serializer.e and change the -s option (--doctype-system) to  
> have -p as its short form, recompile and try again.
> Both commands should now produce an error, but the latter (at least)  
> doesn't.

I cannot find the serializer.e file. It looks like you forgot to check it  
in.

Bernd

Re: [gobo-eiffel-develop] SF.net SVN: gobo-eiffel: [6095] gobo/trunk

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

Sorry - I forgot to copy my config file to my London computer - I will atte=
nd to it next week.
As for the svn:executable, I am at a loss as to how that gets set - it does=
 not appear in my config file at all (except as a comment on *.sh files).

----------------------------------------> Date: Mon, 1 Oct 2007 22:03:31 +0=
200> From: er...@go...> To: gob...@li...=
t> Subject: Re: [gobo-eiffel-develop] SF.net SVN: gobo-eiffel: [6095] gobo/=
trunk>> Hi Colin,>> The following properties are not good again on new file=
s.> They are missing the svn:keywords property which should be> set to "Aut=
hor Date Id Revision". They also should all have> svn:eol-style set to "nat=
ive". svn:mine-type is not really> required, but I guess it does not hurt. =
However I don't> understand why svn:executable is set to "*".>> --> Eric Be=
zault>> col...@us... wrote:>>>> Added Paths:>> -------=
---->> gobo/trunk/example/xml/xslt/serializer/>> gobo/trunk/example/xml/xsl=
t/serializer/build.eant>> gobo/trunk/example/xml/xslt/serializer/system.xac=
e>> gobo/trunk/library/xml/xslt/serializer/>> gobo/trunk/library/xml/xslt/s=
erializer/xm_xslt_serializer.e>>>> Added: gobo/trunk/example/xml/xslt/seria=
lizer/build.eant>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>> =
(Binary files differ)>>>>>> Property changes on: gobo/trunk/example/xml/xsl=
t/serializer/build.eant>> _________________________________________________=
__________________>> Name: svn:executable>> + *>> Name: svn:mime-type>> + a=
pplication/xml>>>> Added: gobo/trunk/example/xml/xslt/serializer/system.xac=
e>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>> (Binary files d=
iffer)>>>>>> Property changes on: gobo/trunk/example/xml/xslt/serializer/sy=
stem.xace>> _______________________________________________________________=
____>> Name: svn:executable>> + *>> Name: svn:mime-type>> + application/xml=
>>>>> Property changes on: gobo/trunk/library/xml/xslt/serializer/xm_xslt_s=
erializer.e>> _____________________________________________________________=
______>> Name: svn:executable>> + *>> Name: svn:mime-type>> + text/plain>> =
Name: svn:eol-style>> + native>>> --> Eric Bezault> mailto:ericb@gobosoft.c=
om> http://www.gobosoft.com>> ---------------------------------------------=
----------------------------> This SF.net email is sponsored by: Microsoft>=
 Defy all challenges. Microsoft(R) Visual Studio 2005.> http://clk.atdmt.co=
m/MRT/go/vse0120000070mrt/direct/01/> _____________________________________=
__________> gobo-eiffel-develop mailing list> gob...@li...u=
rceforge.net> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-deve=
lop

_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk=

Re: [gobo-eiffel-develop] SF.net SVN: gobo-eiffel: [6095] gobo/trunk

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

Hi Colin,

The following properties are not good again on new files.
They are missing the svn:keywords property which should be
set to "Author Date Id Revision". They also should all have
svn:eol-style set to "native". svn:mine-type is not really
required, but I guess it does not hurt. However I don't
understand why svn:executable is set to "*".

--
Eric Bezault

col...@us... wrote:
> 
> Added Paths:
> -----------
>     gobo/trunk/example/xml/xslt/serializer/
>     gobo/trunk/example/xml/xslt/serializer/build.eant
>     gobo/trunk/example/xml/xslt/serializer/system.xace
>     gobo/trunk/library/xml/xslt/serializer/
>     gobo/trunk/library/xml/xslt/serializer/xm_xslt_serializer.e
> 
> Added: gobo/trunk/example/xml/xslt/serializer/build.eant
> ===================================================================
> (Binary files differ)
> 
> 
> Property changes on: gobo/trunk/example/xml/xslt/serializer/build.eant
> ___________________________________________________________________
> Name: svn:executable
>    + *
> Name: svn:mime-type
>    + application/xml
> 
> Added: gobo/trunk/example/xml/xslt/serializer/system.xace
> ===================================================================
> (Binary files differ)
> 
> 
> Property changes on: gobo/trunk/example/xml/xslt/serializer/system.xace
> ___________________________________________________________________
> Name: svn:executable
>    + *
> Name: svn:mime-type
>    + application/xml
> 

> Property changes on: gobo/trunk/library/xml/xslt/serializer/xm_xslt_serializer.e
> ___________________________________________________________________
> Name: svn:executable
>    + *
> Name: svn:mime-type
>    + text/plain
> Name: svn:eol-style
>    + native


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

Re: [gobo-eiffel-develop] Short options ambiguity in AP_OPTION

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

I have checked it in now.

Go to example/xml/xslt/serializer and do a geant compile_debug_ise.

Now you can try the commands:

./serializer -p jim -s fred

and

./serializer -p fred -p jim

Neither will give any output, nor any error (which is correct).

Now edit serializer.e and change the -s option (--doctype-system) to have -=
p as its short form, recompile and try again.
Both commands should now produce an error, but the latter (at least) doesn'=
t.

> Hello Bernd,=20
>=20
> I just tested again with ambiguous short options, and there is still no e=
rror (I have all assertions turned on).=20
>=20
> I will be checking in code shortly, and then I will post instructions on =
how to reproduce the (lack of) error.
_________________________________________________________________
100=92s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk=

[gobo-eiffel-develop] Short options ambiguity in AP_OPTION

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

Hello Bernd,

I just tested again with ambiguous short options, and there is still no err=
or (I have all assertions turned on).

I will be checking in code shortly, and then I will post instructions on ho=
w to reproduce the (lack of) error.
_________________________________________________________________
Celeb spotting =96 Play CelebMashup and win cool prizes
https://www.celebmashup.com=

Re: [gobo-eiffel-develop] AP_STRING_LIST_OPTION?

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

> > Is it committed yet? I will try it out when it is.
>=20
> I has been committed and already been reviewed by Eric (thanks, do you =20
> never sleep? ;-) )

The trick is not in avoiding sleep. It is doing development when you are as=
leep.

> >> PPS: I still have the request open to have `mutually exclusive options=
',
> >> but I have not found a good solution yet.
> >
> > Can't you just have references to other options which are to be regarde=
d =20
> > as mutually exclusive?
>=20
> The problem is not the check itself, but
>=20
> - where to configure it (parser or option)

The option, I would say:

{AP_OPTION}.set_mutually_exclusive (l_other_option)

repeat as many times as necessary.

> - how to generate a nice help text format illustrating it

I don't see any problems here. Just add:

 (mutually exclusive with --some-other-option, --a-second-option and --yet-=
another-option)



_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk=

Re: [gobo-eiffel-develop] AP_STRING_LIST_OPTION?

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

On Sun, 30 Sep 2007 22:25:58 +0200, Colin Adams  =

<col...@ho...> wrote:
>> I am thinking about adding an optional
>> 'split character' to AP_OPTION_WITH_PARAMETER that make '--foo=3Dx,y'=

>> equivalent to '--foo=3Dx --foo=3Dy'.
>
> I suppose that will do (assuming the split character is configurable).=


After having slept for a night, I think this is design overkill. Just  =

developing a special option type should be sufficient.

>> Also, I have strengthend the preconditions for parsing, and now you  =

>> should
>> have a contract violation if you add "two options with the same short=
 or
>> long form" (it is a little more complicated with alternative options
>> lists). The tag of the exception is currently 'valid_options', which =
is
>> not too good, but difficult to change.
>
> Is it committed yet? I will try it out when it is.

I has been committed and already been reviewed by Eric (thanks, do you  =

never sleep? ;-) )

>> PPS: I still have the request open to have `mutually exclusive option=
s',
>> but I have not found a good solution yet.
>
> Can't you just have references to other options which are to be regard=
ed  =

> as mutually exclusive?

The problem is not the check itself, but

- where to configure it (parser or option)
- how to generate a nice help text format illustrating it

Bernd

Re: [gobo-eiffel-develop] AP_STRING_LIST_OPTION?

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

> <col...@ho...> wrote:
>=20
> > It sounds to me like the two should be equivalent. Certainly I do not =
=20
> > need a list of lists. But I suppose if people were to supply multiple =
=20
> > uses of an AP_STRING_LIST_OPTION, then this ought to be a list of lists=
. =20
> > Is it possible to configure an option as not allowing repeats?
>=20
> Hi Colin,
>=20
> I have just added the possibility to specify a `maximum_occurrences' for =
=20
> options. A value of "0" means that there is no upper limit. If you want a=
n =20
> option to be given just once, calling "o.set_maximum_occurrences (1)" =20
> should be sufficient now.

That will do fine.
=20
> About your comma-seperated list of arguments, I am currently thinking =20
> about an elegant way to integrate this into the library. If you have a =20
> good solution, just go forward.=20

I haven't thought about a solution yet.

>I am thinking about adding an optional =20
> 'split character' to AP_OPTION_WITH_PARAMETER that make '--foo=3Dx,y' =20
> equivalent to '--foo=3Dx --foo=3Dy'.

I suppose that will do (assuming the split character is configurable).
=20
> Also, I have strengthend the preconditions for parsing, and now you shoul=
d =20
> have a contract violation if you add "two options with the same short or =
=20
> long form" (it is a little more complicated with alternative options =20
> lists). The tag of the exception is currently 'valid_options', which is =
=20
> not too good, but difficult to change.

Is it committed yet? I will try it out when it is.


> PPS: I still have the request open to have `mutually exclusive options', =
=20
> but I have not found a good solution yet.


Can't you just have references to other options which are to be regarded as=
 mutually exclusive?


_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=

Re: [gobo-eiffel-develop] AP_STRING_LIST_OPTION?

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

On Sun, 30 Sep 2007 19:10:33 +0200, Colin Adams  =

<col...@ho...> wrote:

> It sounds to me like the two should be equivalent. Certainly I do not =
 =

> need a list of lists. But I suppose if people were to supply multiple =
 =

> uses of an AP_STRING_LIST_OPTION, then this ought to be a list of list=
s.  =

> Is it possible to configure an option as not allowing repeats?

Hi Colin,

I have just added the possibility to specify a `maximum_occurrences' for=
  =

options. A value of "0" means that there is no upper limit. If you want =
an  =

option to be given just once, calling "o.set_maximum_occurrences (1)"  =

should be sufficient now.

About your comma-seperated list of arguments, I am currently thinking  =

about an elegant way to integrate this into the library. If you have a  =

good solution, just go forward. I am thinking about adding an optional  =

'split character' to AP_OPTION_WITH_PARAMETER that make '--foo=3Dx,y'  =

equivalent to '--foo=3Dx --foo=3Dy'.

Also, I have strengthend the preconditions for parsing, and now you shou=
ld  =

have a contract violation if you add "two options with the same short or=
  =

long form" (it is a little more complicated with alternative options  =

lists). The tag of the exception is currently 'valid_options', which is =
 =

not too good, but difficult to change.

Bernd

PS: Thanks for helping me to improve the library.
PPS: I still have the request open to have `mutually exclusive options',=
  =

but I have not found a good solution yet.

Re: [gobo-eiffel-develop] AP_STRING_LIST_OPTION?

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

It sounds to me like the two should be equivalent. Certainly I do not need =
a list of lists. But I suppose if people were to supply multiple uses of an=
 AP_STRING_LIST_OPTION, then this ought to be a list of lists. Is it possib=
le to configure an option as not allowing repeats?

> Date: Sun, 30 Sep 2007 15:14:49 +0200
> To: col...@ho...
> Subject: Re: [gobo-eiffel-develop] AP_STRING_LIST_OPTION?
> From: ber...@in...
>=20
> On Sun, 30 Sep 2007 09:42:42 +0200, Colin Adams =20
> <col...@ho...> wrote:
>=20
> >
> > I am in the process of making the XSLT serializer a separate component =
=20
> > (although still dependent on the xslt library.xace) , so that other =20
> > programs can make use of the various serialization options offered by =
=20
> > XSLT (see http://www.w3.org/TR/xslt20/#element-output).
> >
> > Although this isn't quite finished yet, I am writing an example program=
 =20
> > illustrating its usage (it will take an xml file name plus a series of =
=20
> > command-line arguments specifying serialization options). naturally I a=
m =20
> > using the arguments library.
> >
> > Now the xsl:output attribute cdata-section-elements takes a list of =20
> > qnames. The natural way to specify this in the example program is:
> >
> > --cdata-section-elements=3D(qname1,qname2,qname3)
> >
> > I can do this with an AP_STRING_OPTION and parse the resulting string, =
=20
> > but it seems to me it is a reusable pattern and it looks worth creating=
 =20
> > a class AP_STRING_OPTION_LIST.
> >
> > Do people agree?
>=20
> I agree. I am already deliverying a list of parameters, for the case of =
=20
> repeated usage of the opion (--cdata-section-elements=3Dxxx =20
> --cdata-section-elements=3Dyyy). Should the use of comma delimiters be =20
> quivalent, or do we need need to provide a DS_LIST[DS_LIST[STRING]] as =20
> type for `parameters'?
>=20
> Bernd
>=20
>=20
> --=20
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

_________________________________________________________________
Get free emoticon packs and customisation from Windows Live.=20
http://www.pimpmylive.co.uk=

Re: [gobo-eiffel-develop] Argument parser does not complain with multiple identical short options

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

On Sun, 30 Sep 2007 10:30:10 +0200, Colin Adams  
<col...@ho...> wrote:

>
> I just made a typical cut-and-paste-and-edit error - I was adding  
> another command line option very similar to a previous one - but I  
> forgot to edit the short option character. As a result, the parse is  
> ambiuous. But the parser does not complain, which I think it should.

I will have a look at it. Right, it should if there is more than an single  
option in the same parser with the same short form (except if they are  
used in different alternative options lists).

Bernd

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [gobo-eiffel-develop] VE support in eiffel.eant

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

I don't mind it being left there - I was just drawing attention to it in ca=
se it was an oversight.

> Date: Sun, 30 Sep 2007 10:17:49 +0200
> From: er...@go...
> To: col...@ho...
> CC: gob...@li...
> Subject: Re: [gobo-eiffel-develop] VE support in eiffel.eant
>=20
> Colin Adams wrote:
> > I just noticed the misc/eiffel.eant file still generates help text=20
> > indicating support for VE.
>=20
> I let it there, as well as in gexace (ve.xace are still generated),
> because even though Gobo does not support VE anymore, people might
> still find it useful to use geant and eiffel.eant to compile their
> own applications or they might try to see if a Gobo application
> still compiles with VE despite not being supported anymore. But if
> you think it's better to remove them, I'll do it.
>=20
> --=20
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

_________________________________________________________________
Celeb spotting =96 Play CelebMashup and win cool prizes
https://www.celebmashup.com=

[gobo-eiffel-develop] Argument parser does not complain with multiple identical short options

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

I just made a typical cut-and-paste-and-edit error - I was adding another c=
ommand line option very similar to a previous one - but I forgot to edit th=
e short option character. As a result, the parse is ambiuous. But the parse=
r does not complain, which I think it should.

_________________________________________________________________
100=92s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk=

Re: [gobo-eiffel-develop] VE support in eiffel.eant

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

Colin Adams wrote:
> I just noticed the misc/eiffel.eant file still generates help text 
> indicating support for VE.

I let it there, as well as in gexace (ve.xace are still generated),
because even though Gobo does not support VE anymore, people might
still find it useful to use geant and eiffel.eant to compile their
own applications or they might try to see if a Gobo application
still compiles with VE despite not being supported anymore. But if
you think it's better to remove them, I'll do it.

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

[gobo-eiffel-develop] AP_STRING_LIST_OPTION?

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

I am in the process of making the XSLT serializer a separate component (alt=
hough still dependent on the xslt library.xace) , so that other programs ca=
n make use of the various serialization options offered by XSLT (see http:/=
/www.w3.org/TR/xslt20/#element-output).

Although this isn't quite finished yet, I am writing an example program ill=
ustrating its usage (it will take an xml file name plus a series of command=
-line arguments specifying serialization options). naturally I am using the=
 arguments library.

Now the xsl:output attribute cdata-section-elements takes a list of qnames.=
 The natural way to specify this in the example program is:

--cdata-section-elements=3D(qname1,qname2,qname3)

I can do this with an AP_STRING_OPTION and parse the resulting string, but =
it seems to me it is a reusable pattern and it looks worth creating a class=
 AP_STRING_OPTION_LIST.

Do people agree?

_________________________________________________________________
Celeb spotting =96 Play CelebMashup and win cool prizes
https://www.celebmashup.com=

[gobo-eiffel-develop] VE support in eiffel.eant

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

I just noticed the misc/eiffel.eant file still generates help text indicati=
ng support for VE.

_________________________________________________________________
100=92s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk=

Re: [gobo-eiffel-develop] Bootstrap Problems

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

Bernd Schoeller wrote:
> I currently get the following errors when trying to bootstrap GOBO from  
> SVN under Linux:
> 
> ----------------------------------------------------------------------------------
> schoelle@monty:~/libs/gobo/work/bootstrap$ LANG=C ./bootstrap.sh gcc ge
> gec12.c:12728:21: error: windows.h: No such file or directory
> gec12.c:12729:16: error: io.h: No such file or directory
> gcc: gec12.o: No such file or directory
> rm: cannot remove `gec12.o': No such file or directory
> sh: gec: command not found

It should be fixed now.

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

[gobo-eiffel-develop] Bootstrap Problems

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

Hi,

I currently get the following errors when trying to bootstrap GOBO from =
 =

SVN under Linux:

------------------------------------------------------------------------=
----------
schoelle@monty:~/libs/gobo/work/bootstrap$ LANG=3DC ./bootstrap.sh gcc g=
e
gec12.c:12728:21: error: windows.h: No such file or directory
gec12.c:12729:16: error: io.h: No such file or directory
gcc: gec12.o: No such file or directory
rm: cannot remove `gec12.o': No such file or directory
sh: gec: command not found

BUILD FAILED!

BUILD FAILED!
------------------------------------------------------------------------=
----------

"gec12.c" contain Windows specific includes, caused by commit 6074 (Crea=
te  =

a new DOS console when none exists yet in Windows applications). May I  =

suggest the following patch:

------------------------------------------------------------------------=
----------
Index: work/bootstrap/gec12.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- work/bootstrap/gec12.c      (revision 6087)
+++ work/bootstrap/gec12.c      (working copy)
@@ -12725,9 +12725,12 @@
  #define GE_CONSOLE_C

  #include <stdio.h>
+#include <fcntl.h>
+
+#ifdef EIF_WINDOWS
  #include <windows.h>
  #include <io.h>
-#include <fcntl.h>
+#endif

  #ifdef __cplusplus
  extern "C" {
Index: tool/gec/runtime/c/ge_console.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- tool/gec/runtime/c/ge_console.c     (revision 6087)
+++ tool/gec/runtime/c/ge_console.c     (working copy)
@@ -14,9 +14,12 @@
  #define GE_CONSOLE_C

  #include <stdio.h>
+#include <fcntl.h>
+
+#ifdef EIF_WINDOWS
  #include <windows.h>
  #include <io.h>
-#include <fcntl.h>
+#endif

  #ifdef __cplusplus
  extern "C" {
------------------------------------------------------------------------=
----------

Regards,
Bernd

[gobo-eiffel-develop] Use of argument library with gexslt

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

I have just made a start at converting GEXSLT to use the argument library. 
But I think it is not possible to convert the existing syntax, as options 
such as --trace[=file-name] are not supported by the library. Am I correct?

Also, the parameters description needs to vary according to which set of 
alternative options are specified, and I think this is not supported either.

_________________________________________________________________
Get Pimped! FREE emoticon packs from Windows Live -  
http://www.pimpmylive.co.uk

Re: [gobo-eiffel-develop] Crash in DS_HASH_TABLE

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> Eric Bezault wrote:
>>> Wolfgang Jansen wrote:
>>>> some time ago I already asked a related question and you
>>>> gave an answer. But I may have misunderstood something.
>>>> The problem is as follows. I have a class like
>>>>
>>>>   class C
>>>>   inherit
>>>>     DS_EQUALITY_TESTER [KEY_TYPE]
>>>>       redefine test
>>>>     end
>>>>
>>>>   feature
>>>>
>>>>     table: DS_HASH_TABLE [ITEM_TYPE,KEY_TYPE]
>>>>
>>>>     make is
>>>>       do
>>>>         create table.make_with_equality_testers(1000, Void, Current)
>>>>       end
>>>>
>>>>     build(k: KEY_TYPE): ITEM_TYPE is
>>>>       do
>>>>         if table.has(k) then
>>>>           Result := table.item(k)
>>>>         else
>>>>           create Result.make(k)
>>>>           table.force(Result,k)
>>>>         end
>>>>       end
>>>>
>>>>     test(u,v: STRING) is
>>>>       do
>>>>         -- I would like to do this more intelligent,
>>>>         -- but this is a different problem
>>>>         Result := u = v
>>>>       end
>>>>
>>>>    -- other features
>>>>
>>>>   end
>>>>
>>>> This works very well for some time (hundreds of calls)
>>>> but then routine `search_position' enters an infinite loop:
>>>> Lines 590,591 of DS_SPARSE_CONTAINER are
>>>>   prev := i
>>>>   i := clashes_item(i)
>>>> and have the effect that `prev=1', `i=1', i.e. no further
>>>> progress happens. A particular observation:
>>>> `table' has currently 1028 elements.
>>>>
>>>> So, what has gone wrong and how can I fix the bug?
>>> Is the value of the hash_code of your keys changing while
>>> these keys are used in the hash table?
>>>
>> I don't know, the key type is ET_FEATURE.
>> So, you may answer this best yourself.
>
> No, the hash_code is set once and for all when creating the feature
> object.
>
> Here are more questions:
>
> Do you change the value of `key_equality_tester' in your hash table
> at some point in your program?
>
No.
> If you initially create the hash table with a capacity of 2000
> instead of 1000, does it still crash? If so, does it crash with
> the same number of items already inserted?
>
See below.
> Do you have some code that I can use to try to reproduce the problem?
> I guess that the code above will not help me (the feature `test' is
> using STRINGs instead of ET_FEATUREs).
>
Sorry, this was a typo: the arguments are ET_FEATUREs.

After changing some other things (that had to be changed anyway)
the crash does not longer occur. I cannot reproduce the class state of 
interest
(it was an intermediate state of today's work and has not been saved).
So we may forget the trouble for now.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Crash in DS_HASH_TABLE

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

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> Wolfgang Jansen wrote:
>>> some time ago I already asked a related question and you
>>> gave an answer. But I may have misunderstood something.
>>> The problem is as follows. I have a class like
>>>
>>>   class C
>>>   inherit
>>>     DS_EQUALITY_TESTER [KEY_TYPE]
>>>       redefine test
>>>     end
>>>
>>>   feature
>>>
>>>     table: DS_HASH_TABLE [ITEM_TYPE,KEY_TYPE]
>>>
>>>     make is
>>>       do
>>>         create table.make_with_equality_testers(1000, Void, Current)
>>>       end
>>>
>>>     build(k: KEY_TYPE): ITEM_TYPE is
>>>       do
>>>         if table.has(k) then
>>>           Result := table.item(k)
>>>         else
>>>           create Result.make(k)
>>>           table.force(Result,k)
>>>         end
>>>       end
>>>
>>>     test(u,v: STRING) is
>>>       do
>>>         -- I would like to do this more intelligent,
>>>         -- but this is a different problem
>>>         Result := u = v
>>>       end
>>>
>>>    -- other features
>>>
>>>   end
>>>
>>> This works very well for some time (hundreds of calls)
>>> but then routine `search_position' enters an infinite loop:
>>> Lines 590,591 of DS_SPARSE_CONTAINER are
>>>   prev := i
>>>   i := clashes_item(i)
>>> and have the effect that `prev=1', `i=1', i.e. no further
>>> progress happens. A particular observation:
>>> `table' has currently 1028 elements.
>>>
>>> So, what has gone wrong and how can I fix the bug?
>> Is the value of the hash_code of your keys changing while
>> these keys are used in the hash table?
>>
> I don't know, the key type is ET_FEATURE.
> So, you may answer this best yourself.

No, the hash_code is set once and for all when creating the feature
object.

Here are more questions:

Do you change the value of `key_equality_tester' in your hash table
at some point in your program?

If you initially create the hash table with a capacity of 2000
instead of 1000, does it still crash? If so, does it crash with
the same number of items already inserted?

Do you have some code that I can use to try to reproduce the problem?
I guess that the code above will not help me (the feature `test' is
using STRINGs instead of ET_FEATUREs).

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

Re: [gobo-eiffel-develop] Crash in DS_HASH_TABLE

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> some time ago I already asked a related question and you
>> gave an answer. But I may have misunderstood something.
>> The problem is as follows. I have a class like
>>
>>   class C
>>   inherit
>>     DS_EQUALITY_TESTER [KEY_TYPE]
>>       redefine test
>>     end
>>
>>   feature
>>
>>     table: DS_HASH_TABLE [ITEM_TYPE,KEY_TYPE]
>>
>>     make is
>>       do
>>         create table.make_with_equality_testers(1000, Void, Current)
>>       end
>>
>>     build(k: KEY_TYPE): ITEM_TYPE is
>>       do
>>         if table.has(k) then
>>           Result := table.item(k)
>>         else
>>           create Result.make(k)
>>           table.force(Result,k)
>>         end
>>       end
>>
>>     test(u,v: STRING) is
>>       do
>>         -- I would like to do this more intelligent,
>>         -- but this is a different problem
>>         Result := u = v
>>       end
>>
>>    -- other features
>>
>>   end
>>
>> This works very well for some time (hundreds of calls)
>> but then routine `search_position' enters an infinite loop:
>> Lines 590,591 of DS_SPARSE_CONTAINER are
>>   prev := i
>>   i := clashes_item(i)
>> and have the effect that `prev=1', `i=1', i.e. no further
>> progress happens. A particular observation:
>> `table' has currently 1028 elements.
>>
>> So, what has gone wrong and how can I fix the bug?
>
> Is the value of the hash_code of your keys changing while
> these keys are used in the hash table?
>
I don't know, the key type is ET_FEATURE.
So, you may answer this best yourself.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Crash in DS_HASH_TABLE

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

Wolfgang Jansen wrote:
> some time ago I already asked a related question and you
> gave an answer. But I may have misunderstood something.
> The problem is as follows. I have a class like
> 
>   class C
>   inherit
>     DS_EQUALITY_TESTER [KEY_TYPE]
>       redefine test
>     end
> 
>   feature
> 
>     table: DS_HASH_TABLE [ITEM_TYPE,KEY_TYPE]
> 
>     make is
>       do
>         create table.make_with_equality_testers(1000, Void, Current)
>       end
> 
>     build(k: KEY_TYPE): ITEM_TYPE is
>       do
>         if table.has(k) then
>           Result := table.item(k)
>         else
>           create Result.make(k)
>           table.force(Result,k)
>         end
>       end
> 
>     test(u,v: STRING) is
>       do
>         -- I would like to do this more intelligent,
>         -- but this is a different problem
>         Result := u = v
>       end
> 
>    -- other features
> 
>   end
> 
> This works very well for some time (hundreds of calls)
> but then routine `search_position' enters an infinite loop:
> Lines 590,591 of DS_SPARSE_CONTAINER are
>   prev := i
>   i := clashes_item(i)
> and have the effect that `prev=1', `i=1', i.e. no further
> progress happens. A particular observation:
> `table' has currently 1028 elements.
> 
> So, what has gone wrong and how can I fix the bug?

Is the value of the hash_code of your keys changing while
these keys are used in the hash table?

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

[gobo-eiffel-develop] Crash in DS_HASH_TABLE

[Wolfgang J. <wj...@so...>]

High Eric,

some time ago I already asked a related question and you
gave an answer. But I may have misunderstood something.
The problem is as follows. I have a class like

  class C
  inherit
    DS_EQUALITY_TESTER [KEY_TYPE]
      redefine test
    end

  feature

    table: DS_HASH_TABLE [ITEM_TYPE,KEY_TYPE]

    make is
      do
        create table.make_with_equality_testers(1000, Void, Current)
      end

    build(k: KEY_TYPE): ITEM_TYPE is
      do
        if table.has(k) then
          Result := table.item(k)
        else
          create Result.make(k)
          table.force(Result,k)
        end
      end

    test(u,v: STRING) is
      do
        -- I would like to do this more intelligent,
        -- but this is a different problem
        Result := u = v
      end

   -- other features

  end

This works very well for some time (hundreds of calls)
but then routine `search_position' enters an infinite loop:
Lines 590,591 of DS_SPARSE_CONTAINER are
  prev := i
  i := clashes_item(i)
and have the effect that `prev=1', `i=1', i.e. no further
progress happens. A particular observation:
`table' has currently 1028 elements.

So, what has gone wrong and how can I fix the bug?

Regards
WJ

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] bootstrap with se 1.2r7

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

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

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

    Eric> As you may have noticed, I don't use SE 1.2 anymore. I'm not
    Eric> really interested in a compiler that does not say clearly
    Eric> that it will target ECMA Eiffel. Sooner or later we will
    Eric> have to drop it like we did for Visual Eiffel because of
    Eric> that.

I agree. And I'll spend more time on compiling ge versions of my
programs.

- -- 
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/>

iD8DBQFG5ZoRIyuuaiRyjTYRAgzYAJsEd18Mm22QMZv9ZQ7wthq1/a5JNQCgmzpt
iKjWTNcPs1bqks+X6NSSMtQ=
=j/xa
-----END PGP SIGNATURE-----