Status of SmartEiffel 1.2 project

[Colin Paul Adams]

I assume this project is officially finished now, seeing as we haven't
had any postings for 16 months.

Daniel, can you confirm this?

Would anyone like to take up maintenance of the compiler? If not, the
Gobo project will have to drop support for it in the not too distant
future, I think.

[Daniel F Moisset]

Post by Colin Paul Adams
I assume this project is officially finished now, seeing as we haven't
had any postings for 16 months.
Daniel, can you confirm this?

I can confirm that the activity (development, and obviously, the list)
has been idle in about 14 months. My life hasn't, instead, and that's
part of the reason :)

However, I consider the project not dead as long as I keep using it
(which forces me to patch some stuff from time to time). And I still
have a bit of old code that still want to migrate to SE2, using 1.2 as a
tool.

In fact I've got some kind of release plan (what to include, not
timeframes, but november is quite possible) for at least one extra r8
release

Post by Colin Paul Adams
Would anyone like to take up maintenance of the compiler? If not, the
Gobo project will have to drop support for it in the not too distant
future, I think.

Even if I keep mantaining it, some help could be really appreciated :)

Regards,
Daniel

[Colin Paul Adams]

Daniel> In fact I've got some kind of release plan (what to
Daniel> include, not timeframes, but november is quite possible)
Daniel> for at least one extra r8 release

{DOUBLE}.truncated_to_integer_64 would be nice.

[Colin Paul Adams]

Daniel> Even if I keep mantaining it, some help could be really
Daniel> appreciated :)

Well, I'd be willing to do a little, such as implement
truncated_to_integer_64, but I would need commit access to svn, and
access to the test suite, to test my changes.

[Colin Paul Adams]

Daniel> In fact I've got some kind of release plan (what to
Daniel> include, not timeframes, but november is quite possible)
Daniel> for at least one extra r8 release

Any plans for STRING_32/STRING_8/STRING_GENERAL?

[Daniel F Moisset]

Post by Colin Paul Adams
Daniel> In fact I've got some kind of release plan (what to
Daniel> include, not timeframes, but november is quite possible)
Daniel> for at least one extra r8 release
Any plans for STRING_32/STRING_8/STRING_GENERAL?

None at this time

[Daniel F Moisset]

Post by Colin Paul Adams
Daniel> In fact I've got some kind of release plan (what to
Daniel> include, not timeframes, but november is quite possible)
Daniel> for at least one extra r8 release
Any plans for STRING_32/STRING_8/STRING_GENERAL?

Can you tell me more what is what gobo needs here? I imagine that the
idea is having a common STRING_GENERAL ancestor to STRING_8 (an alias of
SmartEiffel's STRING) and to STRING_32 (an alias of SmartEiffel's
UNICODE_STRING)... is that right?

Regards,
Daniel

[Colin Paul Adams]

Post by Colin Paul Adams
Any plans for STRING_32/STRING_8/STRING_GENERAL?

Daniel> Can you tell me more what is what gobo needs here? I
Daniel> imagine that the idea is having a common STRING_GENERAL
Daniel> ancestor to STRING_8 (an alias of SmartEiffel's STRING)
Daniel> and to STRING_32 (an alias of SmartEiffel's
Daniel> UNICODE_STRING)... is that right?

Yes. This is specified in the ECMA standard (personally I don't think
it is a good idea, but there it is).

[Colin Paul Adams]

Post by Colin Paul Adams
Any plans for STRING_32/STRING_8/STRING_GENERAL?

Daniel> Can you tell me more what is what gobo needs here? I
Daniel> imagine that the idea is having a common STRING_GENERAL
Daniel> ancestor to STRING_8 (an alias of SmartEiffel's STRING)
Daniel> and to STRING_32 (an alias of SmartEiffel's
Daniel> UNICODE_STRING)... is that right?

Colin> Yes. This is specified in the ECMA standard (personally I
Colin> don't think it is a good idea, but there it is).

Actually I think more urgent is NATURAL/_8/16/32/64 - I have started
to use these in the Unicode regular expression engine I am
writing. Whilst it would be possible to revert to using INTEGER, it
will be less pleasant to do so.