Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

Hi Clement, I let a comment on line 1972 of src/plugins/BitBltPlugin/BitBltPlugin.c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed#diff-e013b6766a05037812d48960702c0910 on commit https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ 1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed

and another one in https://github.com/OpenSmalltalk/opensmalltalk- vm/commit/4ff34235c24ea2fd690287f96a73834e744ad6c9

The problem is that a local variable unskew was generated as unsigned int instead of int in BitBlt, but we then test if unskew < 0 which is obviously going to be eliminated as dead code...

I did not try to compile the VM, but I'm pretty sure this is related.

2017-11-23 17:00 GMT+01:00 Clément Bera bera.clement@gmail.com:

...

Hi,

The latest VM that I build from open-smalltalk VM 2278 or 2280 does not work (Stack overflow at start-up OR bugged UI with strange color making any text impossible to read).

I have the problem on 2 different computers, Mac OS X and Linux.

I am able to build successfully the VM from 2274 but I can do it only with a previous version of the platform files (else I got a linking error - scavengeLog: used but not implemented).

I am not sure the problem comes from the recent platform files or the recent changes in the VMMaker packages since they need each other to be able to be compiled.

What is the right way to work around this problem ?

I am about to commit on VMMaker package Sista update but I cannot merge with 2280 since I can't compile a working VM from there, so I'll commit without merging if I cannot solve this problem

Thanks,

-- Clément Béra https://clementbera.wordpress.com/

Since I experienced mangled display when generating source with VMMaker.oscog-cb.2274, I suspect that the problem is related to genPrimitiveStringReplace introduced in VMMaker.oscog-cb.2273

2017-11-24 16:45 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

I can generate a working Win64 squeak cog spur VM at least up to VMMaker.oscog-cb.2272, no time to finish bissecting right now...

2017-11-24 11:37 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:

...

Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

Hi Clement, I let a comment on line 1972 of src/plugins/BitBltPlugin/BitBltPlugin.c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed#diff-e013b6766a05037812d48960702c0910 on commit https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd 1a9c0d61ed1c367fb226e59ce0386af3bf5ed

and another one in https://github.com/OpenSmallta lk/opensmalltalk-vm/commit/4ff34235c24ea2fd690287f96a73834e744ad6c9

The problem is that a local variable unskew was generated as unsigned int instead of int in BitBlt, but we then test if unskew < 0 which is obviously going to be eliminated as dead code...

I did not try to compile the VM, but I'm pretty sure this is related.

2017-11-23 17:00 GMT+01:00 Clément Bera bera.clement@gmail.com:

...

Hi,

The latest VM that I build from open-smalltalk VM 2278 or 2280 does not work (Stack overflow at start-up OR bugged UI with strange color making any text impossible to read).

I have the problem on 2 different computers, Mac OS X and Linux.

I am able to build successfully the VM from 2274 but I can do it only with a previous version of the platform files (else I got a linking error - scavengeLog: used but not implemented).

I am not sure the problem comes from the recent platform files or the recent changes in the VMMaker packages since they need each other to be able to be compiled.

What is the right way to work around this problem ?

I am about to commit on VMMaker package Sista update but I cannot merge with 2280 since I can't compile a working VM from there, so I'll commit without merging if I cannot solve this problem

Thanks,

-- Clément Béra https://clementbera.wordpress.com/

2017-11-26 16:20 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

Hmm, my bad, I fail to find a bug in genPrimitiveStringReplace It appears that I messed up with git client... (bissecting on two different machines is not a good idea anyway) What I find now is this:

• mac osx 64 squeak.cog.spur cog HEAD segv
• mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and

src/plugins/* from head is not OK (mangled)

• mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and

src/plugins/* taken from old commit is OK https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ 3010e4465405f6ec7a289fc3a3d21eb324816a8f#diff- 2ecd46f56f9702ad7a50219dd086a8c5

So that's at least two different problems, one in the plugins, one in

The problem in generated plugins is in MiscPrimitivePlugin.c There are not many changes, so I'll see if I can identify the problem and fix it in VMMaker.

Then there will be the problem of the 64bit cog spur vm...

2017-11-25 22:20 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@

gmail.com>:

...

Since I experienced mangled display when generating source with VMMaker.oscog-cb.2274, I suspect that the problem is related to genPrimitiveStringReplace introduced in VMMaker.oscog-cb.2273

2017-11-24 16:45 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

I can generate a working Win64 squeak cog spur VM at least up to VMMaker.oscog-cb.2272, no time to finish bissecting right now...

2017-11-24 11:37 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

Hi Clement, I let a comment on line 1972 of src/plugins/BitBltPlugin/BitBl tPlugin.c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed#diff-e013b6766a05037812d48960702c0910 on commit https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd 1a9c0d61ed1c367fb226e59ce0386af3bf5ed

and another one in https://github.com/OpenSmallta lk/opensmalltalk-vm/commit/4ff34235c24ea2fd690287f96a73834e744ad6c9

The problem is that a local variable unskew was generated as unsigned int instead of int in BitBlt, but we then test if unskew < 0 which is obviously going to be eliminated as dead code...

I did not try to compile the VM, but I'm pretty sure this is related.

2017-11-23 17:00 GMT+01:00 Clément Bera bera.clement@gmail.com:

...

Hi,

The latest VM that I build from open-smalltalk VM 2278 or 2280 does not work (Stack overflow at start-up OR bugged UI with strange color making any text impossible to read).

I have the problem on 2 different computers, Mac OS X and Linux.

I am able to build successfully the VM from 2274 but I can do it only with a previous version of the platform files (else I got a linking error - scavengeLog: used but not implemented).

I am not sure the problem comes from the recent platform files or the recent changes in the VMMaker packages since they need each other to be able to be compiled.

What is the right way to work around this problem ?

I am about to commit on VMMaker package Sista update but I cannot merge with 2280 since I can't compile a working VM from there, so I'll commit without merging if I cannot solve this problem

Thanks,

-- Clément Béra https://clementbera.wordpress.com/

2017-11-26 17:14 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

2017-11-26 16:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:

...

2017-11-26 16:20 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

Hmm, my bad, I fail to find a bug in genPrimitiveStringReplace It appears that I messed up with git client... (bissecting on two different machines is not a good idea anyway) What I find now is this:

• mac osx 64 squeak.cog.spur cog HEAD segv
• mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and

src/plugins/* from head is not OK (mangled)

• mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and

src/plugins/* taken from old commit is OK https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/301 0e4465405f6ec7a289fc3a3d21eb324816a8f#diff-2ecd46f56f9702ad7 a50219dd086a8c5

So that's at least two different problems, one in the plugins, one in

The problem in generated plugins is in MiscPrimitivePlugin.c There are not many changes, so I'll see if I can identify the problem and fix it in VMMaker.

So I have fixed the code of primitiveDecompressFromByteArray from MiscPrimitivePlugin but IT'S NOT IN VMMaker... I fixed the Squeak trunk version (Graphics-nice.385), I presume there is a similar thing in Pharo. We can't continue with this Misc thing, it's not manageable.

I've also pushed the fix on github.

Now remains the 64bits cog spur VM problem

And the VM problem is the one that I reported in the other thread "Something wrong in latest code generation"

There's a buggy inversion in primitiveAdd and primitiveSubtract, where we test for primitiveFailure BEFORE generating primitive failure (or success).

We should fix code generation in VMMaker, regenerate, then this should restore Opensmalltalk-vm health

Then there will be the problem of the 64bit cog spur vm...

...

2017-11-25 22:20 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai

...

l.com>:

...

Since I experienced mangled display when generating source with VMMaker.oscog-cb.2274, I suspect that the problem is related to genPrimitiveStringReplace introduced in VMMaker.oscog-cb.2273

2017-11-24 16:45 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

I can generate a working Win64 squeak cog spur VM at least up to VMMaker.oscog-cb.2272, no time to finish bissecting right now...

2017-11-24 11:37 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

> Hi Clement, > I let a comment on line 1972 of src/plugins/BitBltPlugin/BitBl > tPlugin.c > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed#diff-e013b6766a05037812d48960702c0910 > on commit > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd > 1a9c0d61ed1c367fb226e59ce0386af3bf5ed > > and another one in https://github.com/OpenSmallta > lk/opensmalltalk-vm/commit/4ff34235c24ea2fd690287f96a73834e744ad6c9 > > The problem is that a local variable unskew was generated as > unsigned int instead of int in BitBlt, but we then test if unskew < 0 which > is obviously going to be eliminated as dead code... > > I did not try to compile the VM, but I'm pretty sure this is related. > > 2017-11-23 17:00 GMT+01:00 Clément Bera bera.clement@gmail.com: > >> >> Hi, >> >> The latest VM that I build from open-smalltalk VM 2278 or 2280 does >> not work (Stack overflow at start-up OR bugged UI with strange color making >> any text impossible to read). >> >> I have the problem on 2 different computers, Mac OS X and Linux. >> >> I am able to build successfully the VM from 2274 but I can do it >> only with a previous version of the platform files (else I got a linking >> error - scavengeLog: used but not implemented). >> >> I am not sure the problem comes from the recent platform files or >> the recent changes in the VMMaker packages since they need each other to be >> able to be compiled. >> >> What is the right way to work around this problem ? >> >> I am about to commit on VMMaker package Sista update but I cannot >> merge with 2280 since I can't compile a working VM from there, so I'll >> commit without merging if I cannot solve this problem >> >> Thanks, >> >> -- >> Clément Béra >> https://clementbera.wordpress.com/ >> >> >

On 27. Nov 2017, at 00:59, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:

Dear Nicolas,

But Eliot did already fixed the code generation in VMMaker.oscog-eem.2280 (it was TMethod >> inlineSend: aSendNode directReturn: directReturn exitVar: exitVar in: aCodeGen)

So we just have to regenerate code...

thank you for your work tracking down the issues! You sure had other things planned?! Wouldn't it be nice if this event could be used to embrace automation?

cheers

holger

Hi,

Thanks Nicolas. I will try anytime soon (Wednesday at worst) to regenerate the code.

About MiscPlugin...

I have set-up a project with my student for next semester (January-May). The idea is to: 1) Port Misc to standard plugin architecture. 2) Evaluate the performance of specific primitives in JIT intrinsic (I mean rewritten like SmallInteger>>#+ in the JIT), especially findSubString and compareString, both with standard instructions of Cog's RTL and with SSE4.2 string instructions. 3) Based on evaluation, consider to move 1 or 2 primitives from plugin to core VM primitives and add the intrinsic version in production.

I did 3 steps so the project is interesting and allows to work with different part of the VM, but I think only 1) is guaranteed to be done with the student level. I expect therefore the Misc problem to be solved by the end of March (If my student don't do it I will do it).

If you want to collaborate on this at a rate of one ~15 min skype meeting per month please tell me, I will introduce you to the student (we're all French speakers).

By the way, I think the new Misc should be renamed ByteObjectPlugin since this is about ByteString & ByteArray (hash, comparison, indexOf:, findSubString, ...) and BitMap (compression/decompression). What do you think ?

On Sun, Nov 26, 2017 at 6:28 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:

2017-11-26 18:14 GMT+01:00 Holger Freyther holger@freyther.de:

...

...

On 27. Nov 2017, at 00:59, Nicolas Cellier <

nicolas.cellier.aka.nice@gmail.com> wrote:

...

Dear Nicolas,

...

But Eliot did already fixed the code generation in

VMMaker.oscog-eem.2280

...

(it was TMethod >> inlineSend: aSendNode directReturn: directReturn

exitVar: exitVar in: aCodeGen)

...

So we just have to regenerate code...

thank you for your work tracking down the issues! You sure had other things planned?! Wouldn't it be nice if this event could be used to embrace automation?

cheers

    holger

Hi Holger, Most often, heroic actions are counter productive. They may delay adoption of better practices (including more sustainable ones). So beside what I had planned or not, this is a good question anyway ;)

On 27 November 2017 at 04:15, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:

2017-11-26 21:04 GMT+01:00 Clément Bera bera.clement@gmail.com:

...

Hi,

Thanks Nicolas. I will try anytime soon (Wednesday at worst) to regenerate the code.

...

About MiscPlugin...

I have set-up a project with my student for next semester (January-May). The idea is to:

1. Port Misc to standard plugin architecture.
2. Evaluate the performance of specific primitives in JIT intrinsic (I

mean rewritten like SmallInteger>>#+ in the JIT), especially findSubString and compareString, both with standard instructions of Cog's RTL and with SSE4.2 string instructions. 3) Based on evaluation, consider to move 1 or 2 primitives from plugin to core VM primitives and add the intrinsic version in production.

I did 3 steps so the project is interesting and allows to work with different part of the VM, but I think only 1) is guaranteed to be done with the student level. I expect therefore the Misc problem to be solved by the end of March (If my student don't do it I will do it).

If you want to collaborate on this at a rate of one ~15 min skype meeting per month please tell me, I will introduce you to the student (we're all French speakers).

By the way, I think the new Misc should be renamed ByteObjectPlugin since this is about ByteString & ByteArray (hash, comparison, indexOf:, findSubString, ...) and BitMap (compression/decompression). What do you think ?

Yes, good idea, and while at it, we will make the String comparison return -1, 0 or 1 insted of 1,2,3. Maybe ByteObjectAcceleratorPlugin, but it's a bit long...

"Accelerator" seems redundant. Isn't that semantic implicit in making a plugin?

cheers -ben

On Sun, Nov 26, 2017 at 5:14 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:

2017-11-26 16:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:

...

2017-11-26 16:20 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

Hmm, my bad, I fail to find a bug in genPrimitiveStringReplace It appears that I messed up with git client... (bissecting on two different machines is not a good idea anyway) What I find now is this:

• mac osx 64 squeak.cog.spur cog HEAD segv
• mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and

src/plugins/* from head is not OK (mangled)

• mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and

src/plugins/* taken from old commit is OK https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/301 0e4465405f6ec7a289fc3a3d21eb324816a8f#diff-2ecd46f56f9702ad7 a50219dd086a8c5

So that's at least two different problems, one in the plugins, one in

The problem in generated plugins is in MiscPrimitivePlugin.c There are not many changes, so I'll see if I can identify the problem and fix it in VMMaker.

So I have fixed the code of primitiveDecompressFromByteArray from MiscPrimitivePlugin but IT'S NOT IN VMMaker... I fixed the Squeak trunk version (Graphics-nice.385), I presume there is a similar thing in Pharo. We can't continue with this Misc thing, it's not manageable.

I added that:

https://pharo.fogbugz.com/f/cases/20778/primitiveDecompressFromByteArray-inc...

But the long term solution is what we discussed

I've also pushed the fix on github.

Now remains the 64bits cog spur VM problem

Then there will be the problem of the 64bit cog spur vm...

...

2017-11-25 22:20 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai

...

l.com>:

...

Since I experienced mangled display when generating source with VMMaker.oscog-cb.2274, I suspect that the problem is related to genPrimitiveStringReplace introduced in VMMaker.oscog-cb.2273

2017-11-24 16:45 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

I can generate a working Win64 squeak cog spur VM at least up to VMMaker.oscog-cb.2272, no time to finish bissecting right now...

2017-11-24 11:37 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

> Hi Clement, > I let a comment on line 1972 of src/plugins/BitBltPlugin/BitBl > tPlugin.c > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed#diff-e013b6766a05037812d48960702c0910 > on commit > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd > 1a9c0d61ed1c367fb226e59ce0386af3bf5ed > > and another one in https://github.com/OpenSmallta > lk/opensmalltalk-vm/commit/4ff34235c24ea2fd690287f96a73834e744ad6c9 > > The problem is that a local variable unskew was generated as > unsigned int instead of int in BitBlt, but we then test if unskew < 0 which > is obviously going to be eliminated as dead code... > > I did not try to compile the VM, but I'm pretty sure this is related. > > 2017-11-23 17:00 GMT+01:00 Clément Bera bera.clement@gmail.com: > >> >> Hi, >> >> The latest VM that I build from open-smalltalk VM 2278 or 2280 does >> not work (Stack overflow at start-up OR bugged UI with strange color making >> any text impossible to read). >> >> I have the problem on 2 different computers, Mac OS X and Linux. >> >> I am able to build successfully the VM from 2274 but I can do it >> only with a previous version of the platform files (else I got a linking >> error - scavengeLog: used but not implemented). >> >> I am not sure the problem comes from the recent platform files or >> the recent changes in the VMMaker packages since they need each other to be >> able to be compiled. >> >> What is the right way to work around this problem ? >> >> I am about to commit on VMMaker package Sista update but I cannot >> merge with 2280 since I can't compile a working VM from there, so I'll >> commit without merging if I cannot solve this problem >> >> Thanks, >> >> -- >> Clément Béra >> https://clementbera.wordpress.com/ >> >> >