Hi everyone, I'm happy to announce Fuel version 5.0.0 today. The changes to 4.0.0 aren't huge but I've had to adjust the format once more. 5.0.0 comes with full support for stateful traits, i.e. traits with instance variables. You can find the release notes here: https://theseion.github.io/Fuel/releases/5.0.0/. Cheers, Max (on behalf of the Fuel team)
Great news!
On 27 Feb 2022, at 19:34, Max Leske <maxleske@gmail.com> wrote:
Hi everyone,
I'm happy to announce Fuel version 5.0.0 today.
The changes to 4.0.0 aren't huge but I've had to adjust the format once more.
5.0.0 comes with full support for stateful traits, i.e. traits with instance variables. You can find the release notes here: https://theseion.github.io/Fuel/releases/5.0.0/ <https://theseion.github.io/Fuel/releases/5.0.0/>.
Cheers, Max (on behalf of the Fuel team)
On Sun, Feb 27, 2022 at 4:42 PM stephane ducasse <stephane.ducasse@inria.fr> wrote:
Great news!
+1 thanks Max! MartÃn
On 27 Feb 2022, at 19:34, Max Leske <maxleske@gmail.com> wrote:
Hi everyone,
I'm happy to announce Fuel version 5.0.0 today.
The changes to 4.0.0 aren't huge but I've had to adjust the format once more.
5.0.0 comes with full support for stateful traits, i.e. traits with instance variables. You can find the release notes here: https://theseion.github.io/Fuel/releases/5.0.0/.
Cheers, Max (on behalf of the Fuel team)
On 27 Feb 2022, at 19:34, Max Leske <maxleske@gmail.com> wrote:
Hi everyone,
I'm happy to announce Fuel version 5.0.0 today.
The changes to 4.0.0 aren't huge but I've had to adjust the format once more.
5.0.0 comes with full support for stateful traits, i.e. traits with instance variables. You can find the release notes here: https://theseion.github.io/Fuel/releases/5.0.0/.
Nice! As soon as the Pharo11 dev cycle starts, I want to use it and look into the state of serialising clean blocks. (Clean blocks are not enabled by default in Pharo10, but I want to push for finishing that soon in Pharo11). Another change I am looking into is to allow Slots on all classes⦠we can not not have indexed instance variables in some classes, but with Slots we can define non-indexed âinstance variablesâ that store somewhere else. E.g. we could implement a subclass of Slot that would realise a Variable âsourceâ on CompiledMethod that would abstract away source code storage mess (just as an example what this can do, not to say that we should do exactly that). Or have a Slot that stores into a property API as we have it on all the Structural entities (from classes down to compiledMethod). Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance variables⦠(which is the right thing to do now), but that would not work here anymore. Marcus
On 28 Feb 2022, at 9:27, Marcus Denker wrote:
On 27 Feb 2022, at 19:34, Max Leske <maxleske@gmail.com> wrote:
Hi everyone,
I'm happy to announce Fuel version 5.0.0 today.
The changes to 4.0.0 aren't huge but I've had to adjust the format once more.
5.0.0 comes with full support for stateful traits, i.e. traits with instance variables. You can find the release notes here: https://theseion.github.io/Fuel/releases/5.0.0/.
Nice! As soon as the Pharo11 dev cycle starts, I want to use it and look into the state of serialising clean blocks.
(Clean blocks are not enabled by default in Pharo10, but I want to push for finishing that soon in Pharo11).
That's going to be interesting :). Ideally this will work out of the box.
Another change I am looking into is to allow Slots on all classes⦠we can not not have indexed instance variables in some classes, but with Slots we can define non-indexed âinstance variablesâ that store somewhere else.
E.g. we could implement a subclass of Slot that would realise a Variable âsourceâ on CompiledMethod that would abstract away source code storage mess (just as an example what this can do, not to say that we should do exactly that).
Or have a Slot that stores into a property API as we have it on all the Structural entities (from classes down to compiledMethod).
Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance variables⦠(which is the right thing to do now), but that would not work here anymore.
Good to know. I'll have to think about how this plays together with the "classic" architecture.
Marcus
Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance variables⦠(which is the right thing to do now), but that would not work here anymore.
Good to know. I'll have to think about how this plays together with the "classic" architecture.
This is why I am in general not a fan of this idea of code trying to be compatible on that level⦠To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do and do *more*. To take the philosophy and push it further⦠but that can *not* be done if one want to 100% backward compatible on an implementation level forever... I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-) Marcus
On 28 Feb 2022, at 20:55, Marcus Denker wrote:
Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance variables⦠(which is the right thing to do now), but that would not work here anymore.
Good to know. I'll have to think about how this plays together with the "classic" architecture.
This is why I am in general not a fan of this idea of code trying to be compatible on that levelâ¦
To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do and do *more*. To take the philosophy and push it further⦠but that can *not* be done if one want to 100% backward compatible on an implementation level forever...
I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-)
lol :D I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll reach a point where it becomes easier to maintain two separate versions. As long as there are users in Squeak I want to support them (maybe I'll do a survey in the Squeak community at that point, it could also be an option to drop support for Squeak if they don't use Fuel).
Marcus
On 28 Feb 2022, at 21:43, Max Leske <maxleske@gmail.com> wrote:
On 28 Feb 2022, at 20:55, Marcus Denker wrote:
Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance variables⦠(which is the right thing to do now), but that would not work here anymore.
Good to know. I'll have to think about how this plays together with the "classic" architecture.
This is why I am in general not a fan of this idea of code trying to be compatible on that levelâ¦
To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do and do *more*. To take the philosophy and push it further⦠but that can *not* be done if one want to 100% backward compatible on an implementation level forever...
I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-)
lol :D
I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll reach a point where it becomes easier to maintain two separate versions. As long as there are users in Squeak I want to support them (maybe I'll do a survey in the Squeak community at that point, it could also be an option to drop support for Squeak if they don't use Fuel).
It was explained to me, when I said âWe did Pharo to have a futureâ, that *nobody* in the Squeak community wants or ever wanted to have a future. So why waste even 5 minutes on that? Marcus
On 28 Feb 2022, at 22:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Feb 2022, at 21:43, Max Leske <maxleske@gmail.com> wrote:
On 28 Feb 2022, at 20:55, Marcus Denker wrote:
Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance variables⦠(which is the right thing to do now), but that would not work here anymore.
Good to know. I'll have to think about how this plays together with the "classic" architecture.
This is why I am in general not a fan of this idea of code trying to be compatible on that levelâ¦
To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do and do *more*. To take the philosophy and push it further⦠but that can *not* be done if one want to 100% backward compatible on an implementation level forever...
I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-)
lol :D
I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll reach a point where it becomes easier to maintain two separate versions. As long as there are users in Squeak I want to support them (maybe I'll do a survey in the Squeak community at that point, it could also be an option to drop support for Squeak if they don't use Fuel).
It was explained to me, when I said âWe did Pharo to have a futureâ, that *nobody* in the Squeak community wants or ever wanted to have a future.
and that this is good for eToys.. I still do not understand that. It just made no sense.But then, in retrospect, not much made sense with Squeak. You will never be able to invent the future if you do not want to have a future. Marcus
participants (5)
-
Chris Muller -
Marcus Denker -
Martin Dias -
Max Leske -
stephane ducasse