Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Christoph Thiede

Hi all,


after updating to the latest OpenSmalltalk VM version (see specs in the subject line), I cannot use simple hotkeys such as Ctrl + a any longer. However, using Alt instead of Ctrl works fine. I run the latest Trunk image side-by-side, one time with the delivered VM from the Trunk download (201911012148), one time with 201911282316. Sensor kbdTest shows the same information for both applications when I press Ctrl + a, however, only the old VM accepts the combination. I even observed that using the new VM, Ctrl + a moves the cursor to the beginning of the editor, Ctrl + d to the end.


Something seems to be wrong here; unfortunately, I have no clue what, so I will be happy to give you all the necessary information.


Best,

Christoph


PS: Closing the VM also looks different, just like in old times, using the new version:




Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Nicolas Cellier
Hi Christoph,
The image side is totally messy, 
The VM side is also messy, so finding a combination that might work is a sport.
There have been long discussions about similar issues https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/396 after a change to recode() function...

This was for linux, but since we now use the same UTF32InputInterpreter on windows, I'm not surprised that we might observe similar behavior
(modulo the fact that (eventBuffer at: 3) is not macRoman encoded anymore on windows, but this is not an issue for CTRL+A AFAIU)

To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

Personnally, I have the Preferences 'Duplicate all control and alt keys' set to true, and can input Ctrl+A as usual.
If I set it off, then Ctrl+A stops working (but it does not move the cursor left...), Ctrl+D becomes equivalent to Ctrl+Shift+D (debug it)

I also have
ActiveHand keyboardInterpreter -> an UTF32InputInterpreter
Locale current -> a Locale(en-English)
Locale current languageEnvironment -> a Latin1Environment

You can try to play with the Alt/Control Preferences and see if you find some combination that fits...

For the future there are a few reasonable things to do like:
1) stop changing the slightest thing (stop innovating and add another layer of dirt each time when upgrading to new OS)
2) disentangle the code on both side (starting at VM side).
One is more reasonable than the other IMO ;)
This is time consuming and requires image+VM sync, so it will be paved with some hiccups

The first step is to gather and write our exact expectations.
I would personnally add new expectations for handling virtual keyboards and gestures on alternate devices of course.
The next step is to study the technical solutions.
SDL2 is one candidate for simplifying (externalizing?) the mess.

Nicolas

Le mar. 10 déc. 2019 à 17:20, Thiede, Christoph <[hidden email]> a écrit :

Hi all,


after updating to the latest OpenSmalltalk VM version (see specs in the subject line), I cannot use simple hotkeys such as Ctrl + a any longer. However, using Alt instead of Ctrl works fine. I run the latest Trunk image side-by-side, one time with the delivered VM from the Trunk download (201911012148), one time with 201911282316. Sensor kbdTest shows the same information for both applications when I press Ctrl + a, however, only the old VM accepts the combination. I even observed that using the new VM, Ctrl + a moves the cursor to the beginning of the editor, Ctrl + d to the end.


Something seems to be wrong here; unfortunately, I have no clue what, so I will be happy to give you all the necessary information.


Best,

Christoph


PS: Closing the VM also looks different, just like in old times, using the new version:





Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Nicolas Cellier
Of course, the bug report was for linux VM and not Windows VM, so it's not at all following the same path inside the VM, just looks like similar...
I hope it's clear (not sure it was in my answer)

Le mar. 10 déc. 2019 à 19:05, Nicolas Cellier <[hidden email]> a écrit :
Hi Christoph,
The image side is totally messy, 
The VM side is also messy, so finding a combination that might work is a sport.
There have been long discussions about similar issues https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/396 after a change to recode() function...

This was for linux, but since we now use the same UTF32InputInterpreter on windows, I'm not surprised that we might observe similar behavior
(modulo the fact that (eventBuffer at: 3) is not macRoman encoded anymore on windows, but this is not an issue for CTRL+A AFAIU)

To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

Personnally, I have the Preferences 'Duplicate all control and alt keys' set to true, and can input Ctrl+A as usual.
If I set it off, then Ctrl+A stops working (but it does not move the cursor left...), Ctrl+D becomes equivalent to Ctrl+Shift+D (debug it)

I also have
ActiveHand keyboardInterpreter -> an UTF32InputInterpreter
Locale current -> a Locale(en-English)
Locale current languageEnvironment -> a Latin1Environment

You can try to play with the Alt/Control Preferences and see if you find some combination that fits...

For the future there are a few reasonable things to do like:
1) stop changing the slightest thing (stop innovating and add another layer of dirt each time when upgrading to new OS)
2) disentangle the code on both side (starting at VM side).
One is more reasonable than the other IMO ;)
This is time consuming and requires image+VM sync, so it will be paved with some hiccups

The first step is to gather and write our exact expectations.
I would personnally add new expectations for handling virtual keyboards and gestures on alternate devices of course.
The next step is to study the technical solutions.
SDL2 is one candidate for simplifying (externalizing?) the mess.

Nicolas

Le mar. 10 déc. 2019 à 17:20, Thiede, Christoph <[hidden email]> a écrit :

Hi all,


after updating to the latest OpenSmalltalk VM version (see specs in the subject line), I cannot use simple hotkeys such as Ctrl + a any longer. However, using Alt instead of Ctrl works fine. I run the latest Trunk image side-by-side, one time with the delivered VM from the Trunk download (201911012148), one time with 201911282316. Sensor kbdTest shows the same information for both applications when I press Ctrl + a, however, only the old VM accepts the combination. I even observed that using the new VM, Ctrl + a moves the cursor to the beginning of the editor, Ctrl + d to the end.


Something seems to be wrong here; unfortunately, I have no clue what, so I will be happy to give you all the necessary information.


Best,

Christoph


PS: Closing the VM also looks different, just like in old times, using the new version:





Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

timrowledge
In reply to this post by Nicolas Cellier


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash



Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Eliot Miranda-2


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.
 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Eliot Miranda-2


On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

marcel.taeumel
Hi Christoph,

could you double check both .ini and preferences? [Ctrl] and [Alt] kind of work here on Windows 10 with a German keyboard layout as follows:



Seems to be that only [alt], which is likely [cmd], is working. Without key duplication, [ctrl] does strange things. Even on my machine. Yes, those mappings in the image side are a mess.

Best,
Marcel

Am 10.12.2019 20:28:11 schrieb Eliot Miranda <[hidden email]>:



On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Christoph Thiede

Hi Marcel!


My preferences match your screenshot exactly, the problem resists.


Concerning Alt F4 quit, I have to retract my statement. If I use the setting from your ini file, I get the right dialog.

However, why is this setting not included into the VM release? Who wants to see this unsqueaky, OS-dependent window instead of a beautiful, explorable DialogWindow? :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 11. Dezember 2019 08:46:36
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,

could you double check both .ini and preferences? [Ctrl] and [Alt] kind of work here on Windows 10 with a German keyboard layout as follows:



Seems to be that only [alt], which is likely [cmd], is working. Without key duplication, [ctrl] does strange things. Even on my machine. Yes, those mappings in the image side are a mess.

Best,
Marcel

Am 10.12.2019 20:28:11 schrieb Eliot Miranda <[hidden email]>:



On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Christoph Thiede

German umlauts (äöü) don't work for me either, despite I just installed all Trunk updates.


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 11. Dezember 2019 09:22:26
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 

Hi Marcel!


My preferences match your screenshot exactly, the problem resists.


Concerning Alt F4 quit, I have to retract my statement. If I use the setting from your ini file, I get the right dialog.

However, why is this setting not included into the VM release? Who wants to see this unsqueaky, OS-dependent window instead of a beautiful, explorable DialogWindow? :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 11. Dezember 2019 08:46:36
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,

could you double check both .ini and preferences? [Ctrl] and [Alt] kind of work here on Windows 10 with a German keyboard layout as follows:



Seems to be that only [alt], which is likely [cmd], is working. Without key duplication, [ctrl] does strange things. Even on my machine. Yes, those mappings in the image side are a mess.

Best,
Marcel

Am 10.12.2019 20:28:11 schrieb Eliot Miranda <[hidden email]>:



On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Nicolas Cellier
Hi Christoph,
you might have to restart the image, or just evaluate:

    LanguageEnvironment clearDefault.
    HandMorph clearInterpreters.


Le mer. 11 déc. 2019 à 10:11, Thiede, Christoph <[hidden email]> a écrit :

German umlauts (äöü) don't work for me either, despite I just installed all Trunk updates.


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 11. Dezember 2019 09:22:26
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 

Hi Marcel!


My preferences match your screenshot exactly, the problem resists.


Concerning Alt F4 quit, I have to retract my statement. If I use the setting from your ini file, I get the right dialog.

However, why is this setting not included into the VM release? Who wants to see this unsqueaky, OS-dependent window instead of a beautiful, explorable DialogWindow? :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 11. Dezember 2019 08:46:36
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,

could you double check both .ini and preferences? [Ctrl] and [Alt] kind of work here on Windows 10 with a German keyboard layout as follows:



Seems to be that only [alt], which is likely [cmd], is working. Without key duplication, [ctrl] does strange things. Even on my machine. Yes, those mappings in the image side are a mess.

Best,
Marcel

Am 10.12.2019 20:28:11 schrieb Eliot Miranda <[hidden email]>:



On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Christoph Thiede

Thank you, restarting the image helped. I was not aware of that.

I just told Marcel that I would find it helpful to put your snippet into a postload script before we release 5.3 ...


Von: Squeak-dev <[hidden email]> im Auftrag von Nicolas Cellier <[hidden email]>
Gesendet: Mittwoch, 11. Dezember 2019 10:27:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,
you might have to restart the image, or just evaluate:

    LanguageEnvironment clearDefault.
    HandMorph clearInterpreters.


Le mer. 11 déc. 2019 à 10:11, Thiede, Christoph <[hidden email]> a écrit :

German umlauts (äöü) don't work for me either, despite I just installed all Trunk updates.


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 11. Dezember 2019 09:22:26
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 

Hi Marcel!


My preferences match your screenshot exactly, the problem resists.


Concerning Alt F4 quit, I have to retract my statement. If I use the setting from your ini file, I get the right dialog.

However, why is this setting not included into the VM release? Who wants to see this unsqueaky, OS-dependent window instead of a beautiful, explorable DialogWindow? :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 11. Dezember 2019 08:46:36
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,

could you double check both .ini and preferences? [Ctrl] and [Alt] kind of work here on Windows 10 with a German keyboard layout as follows:



Seems to be that only [alt], which is likely [cmd], is working. Without key duplication, [ctrl] does strange things. Even on my machine. Yes, those mappings in the image side are a mess.

Best,
Marcel

Am 10.12.2019 20:28:11 schrieb Eliot Miranda <[hidden email]>:



On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

marcel.taeumel
I just did add that script in Multilingual-mt.249.

Best,
Marcel

Am 11.12.2019 10:38:24 schrieb Thiede, Christoph <[hidden email]>:

Thank you, restarting the image helped. I was not aware of that.

I just told Marcel that I would find it helpful to put your snippet into a postload script before we release 5.3 ...


Von: Squeak-dev <[hidden email]> im Auftrag von Nicolas Cellier <[hidden email]>
Gesendet: Mittwoch, 11. Dezember 2019 10:27:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,
you might have to restart the image, or just evaluate:

    LanguageEnvironment clearDefault.
    HandMorph clearInterpreters.


Le mer. 11 déc. 2019 à 10:11, Thiede, Christoph <[hidden email]> a écrit :

German umlauts (äöü) don't work for me either, despite I just installed all Trunk updates.


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 11. Dezember 2019 09:22:26
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 

Hi Marcel!


My preferences match your screenshot exactly, the problem resists.


Concerning Alt F4 quit, I have to retract my statement. If I use the setting from your ini file, I get the right dialog.

However, why is this setting not included into the VM release? Who wants to see this unsqueaky, OS-dependent window instead of a beautiful, explorable DialogWindow? :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 11. Dezember 2019 08:46:36
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
 
Hi Christoph,

could you double check both .ini and preferences? [Ctrl] and [Alt] kind of work here on Windows 10 with a German keyboard layout as follows:



Seems to be that only [alt], which is likely [cmd], is working. Without key duplication, [ctrl] does strange things. Even on my machine. Yes, those mappings in the image side are a mess.

Best,
Marcel

Am 10.12.2019 20:28:11 schrieb Eliot Miranda <[hidden email]>:



On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Jakob Reschke-2
In reply to this post by Eliot Miranda-2
If the code is hidden in ifdefs it will not be visible to the compiler and thus the CI. Then we will not detect when the old ways break. Maybe implement a feature flag that can be switched from the image. New images can switch the old mess off via some primitive, and tests can switch it on to test the mess.

After some time the mess and flag can be removed and old images will no longer be supported.

Eliot Miranda <[hidden email]> schrieb am Di., 10. Dez. 2019, 20:28:


On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Eliot Miranda-2


On Sun, Dec 15, 2019 at 3:14 AM Jakob Reschke <[hidden email]> wrote:
If the code is hidden in ifdefs it will not be visible to the compiler and thus the CI. Then we will not detect when the old ways break. Maybe implement a feature flag that can be switched from the image. New images can switch the old mess off via some primitive, and tests can switch it on to test the mess.

After some time the mess and flag can be removed and old images will no longer be supported.

+1.  But that's a fair amount of work ;-)  These flags are a precious resource.  What I was suggesting below was that the legacy code, protected by ifdef's, was enabled, and stayed there until some major release, at which time it could be disabled.  I agree with you that disabling it by default is wrong.

IOn general with the VM one wants to maintain backward compatibility until a major release arrives that makes it impossible to for the current VM to support some set of older versions.  For example, the Spur VMs we use now cannot run V3 images.  So when Spur VMs were introduced any backward compatibility for pre-Spur images could be jettisoned from the Spur VMs.

So a viable approach is to use ifdefs, to keep the code enabled, and revisit disabling the code pin every major release.
 
Eliot Miranda <[hidden email]> schrieb am Di., 10. Dez. 2019, 20:28:


On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <[hidden email]> wrote:


On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <[hidden email]> wrote:


> On 2019-12-10, at 10:05 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Christoph,
> The image side is totally messy,
> The VM side is also messy, so finding a combination that might work is a sport.

You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.


> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).

I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.

Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.

See can at least comment it and corral the old messy code in ifdef's such as

#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.

I mean:
We can at least comment it and corral the old messy code in ifdef's such as

#if VERSION <= FOO
# define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
#endif
....
#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
...
#endif

so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc. 

Lovely project! ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash





--
_,,,^..^,,,_
best, Eliot


--
_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

K K Subbu
On 16/12/19 3:44 AM, Eliot Miranda wrote:

> +1.  But that's a fair amount of work ;-)  These flags are a precious
> resource.  What I was suggesting below was that the legacy code,
> protected by ifdef's, was enabled, and stayed there until some major
> release, at which time it could be disabled.  I agree with you that
> disabling it by default is wrong.
>
> IOn general with the VM one wants to maintain backward compatibility
> until a major release arrives that makes it impossible to for the
> current VM to support some set of older versions.  For example, the Spur
> VMs we use now cannot run V3 images.  So when Spur VMs were introduced
> any backward compatibility for pre-Spur images could be jettisoned from
> the Spur VMs.

A third option is to separate image loading from interpreter. The
top-level executable will be the image loader. It will load and
interpret the header, determine the variant and then spawn a
variant-specific interpreter with appropriate arguments to interpret the
image. So we just ship one loader (say squeakvm) and one or more
interpreters (squeak-trunk, squeak-cog, squeak-spur32, squeak-spur64 etc).

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

timrowledge
Dave (pretty sure it was Dave) has done this for *nix with a simple script that uses the image format checking code to decide. Probably a simpler approach than breaking up the VM.

I did actually suggest much the same idea - a core vm with loadable interpreter/translator/gc versions/etc back in 1989 in conversations with Peter Deutsch & Allan Schiffman at OOPSLA.

> On 2019-12-15, at 10:32 PM, K K Subbu <[hidden email]> wrote:
>
> On 16/12/19 3:44 AM, Eliot Miranda wrote:
>> +1.  But that's a fair amount of work ;-)  These flags are a precious resource.  What I was suggesting below was that the legacy code, protected by ifdef's, was enabled, and stayed there until some major release, at which time it could be disabled.  I agree with you that disabling it by default is wrong.
>> IOn general with the VM one wants to maintain backward compatibility until a major release arrives that makes it impossible to for the current VM to support some set of older versions.  For example, the Spur VMs we use now cannot run V3 images.  So when Spur VMs were introduced any backward compatibility for pre-Spur images could be jettisoned from the Spur VMs.
>
> A third option is to separate image loading from interpreter. The top-level executable will be the image loader. It will load and interpret the header, determine the variant and then spawn a variant-specific interpreter with appropriate arguments to interpret the image. So we just ship one loader (say squeakvm) and one or more interpreters (squeak-trunk, squeak-cog, squeak-spur32, squeak-spur64 etc).
>
> Regards .. Subbu
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Business ethics



Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

K K Subbu
On 16/12/19 11:33 PM, tim Rowledge wrote:
> Dave (pretty sure it was Dave) has done this for *nix with a simple
> script that uses the image format checking code to decide. Probably a
> simpler approach than breaking up the VM.

Yes, it is Dave. He posted his run script way back in 2015. It would be
nice to see this absorbed into opensmalltalk-vm code so that it becomes
truly cross-platform.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

timrowledge


> On 2019-12-16, at 8:34 PM, K K Subbu <[hidden email]> wrote:
>
> On 16/12/19 11:33 PM, tim Rowledge wrote:
>> Dave (pretty sure it was Dave) has done this for *nix with a simple
>> script that uses the image format checking code to decide. Probably a
>> simpler approach than breaking up the VM.
>
> Yes, it is Dave. He posted his run script way back in 2015. It would be nice to see this absorbed into opensmalltalk-vm code so that it becomes truly cross-platform.

The shell script idea works on *nix, probably on Mac OS and I suppose something faintly similar may be possible on DOS? A possible alternate path might be an actual executable that does the same process but a smidge faster.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DMZ: Divide Memory by Zero