Cannot build successfully latest VM

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

Cannot build successfully latest VM

Clément Bera-4
 
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,

--
Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 
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 <[hidden email]>:
 
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,

--


Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

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

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--



Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--




Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--





Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 
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
2017-11-25 22:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--






Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 


2017-11-26 16:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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

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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--







Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 


2017-11-26 16:40 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 16:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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

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


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


2017-11-25 22:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--








Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 


2017-11-26 17:14 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 16:40 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 16:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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

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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--









Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 


2017-11-26 17:34 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 17:14 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 16:40 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 16:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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

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


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


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


2017-11-25 22:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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,

--










Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Holger Freyther
 

> On 27. Nov 2017, at 00:59, Nicolas Cellier <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 


2017-11-26 18:14 GMT+01:00 Holger Freyther <[hidden email]>:


> On 27. Nov 2017, at 00:59, Nicolas Cellier <[hidden email]> 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 ;)

Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Clément Bera-4
 
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 <[hidden email]> wrote:
 


2017-11-26 18:14 GMT+01:00 Holger Freyther <[hidden email]>:


> On 27. Nov 2017, at 00:59, Nicolas Cellier <[hidden email]> 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 ;)





--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Nicolas Cellier
 


2017-11-26 21:04 GMT+01:00 Clément Bera <[hidden email]>:
 
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...










On Sun, Nov 26, 2017 at 6:28 PM, Nicolas Cellier <[hidden email]> wrote:
 


2017-11-26 18:14 GMT+01:00 Holger Freyther <[hidden email]>:


> On 27. Nov 2017, at 00:59, Nicolas Cellier <[hidden email]> 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 ;)





--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq


Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Ben Coman
 


On 27 November 2017 at 04:15, Nicolas Cellier <[hidden email]> wrote:
 


2017-11-26 21:04 GMT+01:00 Clément Bera <[hidden email]>:
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

timrowledge
 

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

Excellent. 1 & 3 were jobs Andreas & I planned to tackle *years* ago, part of our original ideas for the plugin stuff that just never got done. 2 of course wasn’t even a fantasy back then because no Cog, and I’d guess that several of the methods might run faster when Cogged than as typical primitives.

I would suggest adding the Bitmap methods to the BitBltPlugin, the SampleSound method to SoundGenerationPlugin (and repeat job 1 on that similarly messed plugin) and the ByteString methods to… well I’d like to say the core VM, but maybe a StringPrimsPlugin might be better. Maybe that would be a place to test out WideString equivalents, too.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.


Reply | Threaded
Open this post in threaded view
|

Re: Cannot build successfully latest VM

Clément Bera-4
In reply to this post by Nicolas Cellier
 


On Sun, Nov 26, 2017 at 5:14 PM, Nicolas Cellier <[hidden email]> wrote:
 


2017-11-26 16:40 GMT+01:00 Nicolas Cellier <[hidden email]>:


2017-11-26 16:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
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

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:

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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
Hmm, I tried to fix declaration of unskew, but it does not seem enough...

2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 
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
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq