Smalltalk › Squeak › Squeak VM

[OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

David T Lewis

[OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

I have built and tested aarch64 builds on
Raspbery Pi 3B / Arch Linux / MUSL+Busybox
Chromebook Two / Linux / libc

The mvm "-O1" seems to work in both cases -- no need to go to "-O0"

Please ignore the spurious sqSCCSVersion.h -- I don't know how to elide this.

The getwd() -> getcwd() in sqUnixSecurityPlugin.c should likewise be harmless [no getwd() in MUSL]

Not a time concern. I don't know of anyone asking for this.

You can view, comment on, or merge this pull request online at:

https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450

Commit Summary

MUSL for AlpineLinux
MUSL for AlpineLinux

File Changes

M build.linux64ARMv8/squeak.stack.spur/build.debug/mvm (7)
M build.linux64ARMv8/squeak.stack.spur/build/mvm (10)
M platforms/Cross/plugins/sqPluginsSCCSVersion.h (8)
M platforms/Cross/vm/sqSCCSVersion.h (14)
M platforms/Cross/vm/sqVirtualMachine.c (5)
M platforms/unix/plugins/SecurityPlugin/sqUnixSecurity.c (3)
M platforms/unix/vm/sqUnixMain.c (5)

Patch Links:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

Please ignore the spurious sqSCCSVersion.h -- I don't know how to elide this.

This is explained in the README:

Important notice for Developers:

We rely on source file substitutions in the src tree, specifically, any sq*SCCSVersion.h files anywhere in the tree are processed to replace $Rev$, $Date$, and $URL$ with the current revision (defined as the timestamp %Y%m%d%H%M of the latest commit), the human readable date of that commit, and the url of the origin repository these sources were cloned from.

The first time you clone this repository, you must therefore run this command:
./scripts/updateSCCSVersions
This will install filters, post-commit, and post-merge hooks to update the sq*SCCSVersion.h files anytime you commit or merge.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

In reply to this post by David T Lewis

Tobias,

Thanks for the help.

More details.

Got messed up somewhere. Symptom is

Alpine:aarch64:~ >>> cd OpenSmalltalk/oscogvm/
Alpine:aarch64:~/OpenSmalltalk/oscogvm >>> scripts/updateSCCSVersions 
error: patch failed: platforms/Cross/plugins/sqPluginsSCCSVersion.h:9
error: platforms/Cross/plugins/sqPluginsSCCSVersion.h: patch does not apply
error: patch failed: platforms/Cross/vm/sqSCCSVersion.h:28
error: platforms/Cross/vm/sqSCCSVersion.h: patch does not apply
Alpine:aarch64:~/OpenSmalltalk/oscogvm >>>

Recloned the KenDickey/opensmalltalk-vm as kens-vm,
ran the scripts/updateSCCSVersion
and all shows well.

But how do I get git to tell GitHub to clean this?

Thanks much again,
-KenD

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

In reply to this post by David T Lewis

@KenDickey pushed 1 commit.

efb837d libevdev test code for SqueakVM

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

In reply to this post by David T Lewis

(sorry, short on Time atm.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

pierre misse

Slang's type inference and typing

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that. Are there offsets to find objects in the object memory? Are there cast as pointers?

Thank you in advance :)

Pierre.

On 16/12/2019 08:27, Tobias Pape wrote:

 
(sorry, short on Time atm.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450?email_source=notifications\u0026email_token=AIJPEW7MIZ52B4XAWLM3UPDQY4UXFA5CNFSM4JYBTAVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG5YPYI#issuecomment-565938145", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450?email_source=notifications\u0026email_token=AIJPEW7MIZ52B4XAWLM3UPDQY4UXFA5CNFSM4JYBTAVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG5YPYI#issuecomment-565938145", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

Guillermo Polito

Re: Slang's type inference and typing

Coucou,

El 16 dic 2019, a las 13:07, pierre misse <[hidden email]> escribió:
I'm currently trying to understand Slang's type inference, and to do so trying to write tests.
I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Did you look at the methods

- #returnType[:]

- #typeFor:in:

and their senders?

There is also a method protocol “type inference” with methods that may seem interesting.

Check for senders to try to understand the callgraph backwards :)

Also, I have been wondering what is the semantic of sqInt.

sqInt was introduced, if I’m not mistaken, to abstract the vm for the underlying exact type used.

This was for the initial effort of compiling the VM both for 32 and 64 bits (thus redefining sqInt for the correct one depending on the case).

I found out it was an alias for a long, but i couldn't find better than that.

Which in linux and osx is 64bit long ;)

In Windows a long is 32bits but either there is a conditional define for that case stating a long long, or we are super tied to gcc/clang.

To check the actual definition/size, you can try to do a textual search on the entire vmmaker using “method source with it”.

Are there offsets to find objects in the object memory?

Objects in memory have variable sizes (an array of 10 elements is larger than an array of 2) so there is no such thing as fixed offsets.

Instead, each object has its own size encoded in its header (hidden from the image).

The VM uses that size to find where the object finishes, and where the next object starts.

You may check:

- #objectAfter:

- https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/

Are there cast as pointers?

Well, technically sqInts are used as pointers.

Check #longAt: and senders.

Thank you in advance :)

Pierre.

On 16/12/2019 08:27, Tobias Pape wrote:
 
(sorry, short on Time atm.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

pierre misse

Re: Slang's type inference and typing

On 16/12/2019 15:02, Guillermo Polito wrote:

 
Coucou,

El 16 dic 2019, a las 13:07, pierre misse <[hidden email]> escribió:

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Did you look at the methods

- #returnType[:]

- #typeFor:in:

and their senders?

There is also a method protocol “type inference” with methods that may seem interesting.

Indeed, but didn't find something that would allow me to launch type inference on something.

Check for senders to try to understand the callgraph backwards :)

I did, got stuck several times, hence me asking.

Also, I have been wondering what is the semantic of sqInt.

sqInt was introduced, if I’m not mistaken, to abstract the vm for the underlying exact type used.

This was for the initial effort of compiling the VM both for 32 and 64 bits (thus redefining sqInt for the correct one depending on the case).

I found out it was an alias for a long, but i couldn't find better than that.

Which in linux and osx is 64bit long ;)
In Windows a long is 32bits but either there is a conditional define for that case stating a long long, or we are super tied to gcc/clang.

To check the actual definition/size, you can try to do a textual search on the entire vmmaker using “method source with it”.

Are there offsets to find objects in the object memory?

Objects in memory have variable sizes (an array of 10 elements is larger than an array of 2) so there is no such thing as fixed offsets.

Instead, each object has its own size encoded in its header (hidden from the image).

The VM uses that size to find where the object finishes, and where the next object starts.

I know that part, but I was thinking that an OOP might be an offsets from the start of the object memory, which would point to the start of the object.

You may check:

- #objectAfter:

- https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/

Are there cast as pointers?

Well, technically sqInts are used as pointers.

Check #longAt: and senders.

Thank you in advance :)

Pierre.

Pierre

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

In reply to this post by David T Lewis

On 2019-12-15 23:27, Tobias Pape wrote:

> (sorry, short on Time atm.)

Ah! Sorry here too. You can ignore this latest.

I had not realize the push would impact the MUSL pull request.

FYI, what I am working toward is getting vm-display-fbdev up using
libevdev. Basically moving from the ol' PS2 drivers to USB drivers for
mouse and keyboard. Part of this is mutating the stand-alone evtest.c
code to enable/show the connection to the SqueakVM mouse and keyboard
api.

Of course, I have to understand what is there first. Bottom up working
code lets me travel there a bit at a time so to speak. ;^)

Oh, yea. Ignore the guy behind the curtain!
-KenD

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Eliot Miranda-2

Re: Slang's type inference and typing

In reply to this post by pierre misse

Hi Pierre,

On Mon, Dec 16, 2019 at 4:07 AM pierre misse <[hidden email]> wrote:

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

Is it your intention to contribute those tests back to VMMaker.oscog on source.squeak.org?

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Here's some doit that run Slang including type inference:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/Slang%20Test%20Workspace.text

If you use https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh to build a VMMaker image it'll create an image containing g this and other useful workspaces that contain doit to launch a VM under the simulator, etc.

Type inference is driven by this loop in CCodeGeneraror>>inferTypesForImplicitlyTypedVariablesAndMethods which iterates, inferring types until no more types can b e inferred (until the algorithm has reached a fixed point).

"now iterate until we reach a fixed point"

[| changedReturnType |

changedReturnType := false.

allMethods do:

[:m|

m inferTypesForImplicitlyTypedVariablesIn: self.

(m inferReturnTypeIn: self) ifTrue:

[changedReturnType := true]].

changedReturnType] whileTrue.

Type information is derived from explicit return types in methods (the <returnTypeC: > pragma), types for "kernel" sends from CCodeGenerator>>#returnTypeForSend:in:ifNil:, and for types propagated to returns from variables that themselves are either explicitly typed using <var: ... type: ...> and <var: ... declareC: ...> pragmas, or get their types in assignments of the results of methods, where the type they acquire is the return types of those methods.

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that.

#sqInt is first of all a pun for "squint", a shortening of Squeak Integer. It is an integer type of the same size as an "ordinary object pointer", or "oop". #usqInt, #sqLong & #usqLong are other important types. #sqLong & #usqLong are 64-bit types. #sqInt & #usqInt are 32-bit types in 32-bit VMs and 64-bit types in 64-bit VMs.

Are there offsets to find objects in the object memory?

A #sqInt is typically used to hold the oop for an object and indeed it points to the header word of the object. The object is preceded by an overflow header word if it has more than 254 slots.

Are there cast as pointers?

Yes. See the functions and macros in platforms/Cross/vm/sqMemoryAccess.h.

Thank you in advance :)

Pierre.

_,,,^..^,,,_

best, Eliot

pierre misse

Re: Slang's type inference and typing

Hi Eliot,

Thanks for the detailed answer and all the pointers !

I must have misunderstood #inferTypesForImplicitlyTypedVariablesAndMethods when I first came across it.

Have a nice day :)

Pierre

On 17/12/2019 01:14, Eliot Miranda wrote:

 
Hi Pierre,

On Mon, Dec 16, 2019 at 4:07 AM pierre misse <[hidden email]> wrote:

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

Is it your intention to contribute those tests back to VMMaker.oscog on source.squeak.org?

If I am able to, it is my intention.

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Here's some doit that run Slang including type inference:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/Slang%20Test%20Workspace.text

If you use https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh to build a VMMaker image it'll create an image containing g this and other useful workspaces that contain doit to launch a VM under the simulator, etc.

Type inference is driven by this loop in CCodeGeneraror>>inferTypesForImplicitlyTypedVariablesAndMethods which iterates, inferring types until no more types can b e inferred (until the algorithm has reached a fixed point).

"now iterate until we reach a fixed point"

[| changedReturnType |

changedReturnType := false.

allMethods do:

[:m|

m inferTypesForImplicitlyTypedVariablesIn: self.

(m inferReturnTypeIn: self) ifTrue:

[changedReturnType := true]].

changedReturnType] whileTrue.

Type information is derived from explicit return types in methods (the <returnTypeC: > pragma), types for "kernel" sends from CCodeGenerator>>#returnTypeForSend:in:ifNil:, and for types propagated to returns from variables that themselves are either explicitly typed using <var: ... type: ...> and <var: ... declareC: ...> pragmas, or get their types in assignments of the results of methods, where the type they acquire is the return types of those methods.

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that.

#sqInt is first of all a pun for "squint"

nice , I was wondering if that was the case too :D

, a shortening of Squeak Integer. It is an integer type of the same size as an "ordinary object pointer", or "oop". #usqInt, #sqLong & #usqLong are other important types. #sqLong & #usqLong are 64-bit types. #sqInt & #usqInt are 32-bit types in 32-bit VMs and 64-bit types in 64-bit VMs.

Are there offsets to find objects in the object memory?

A #sqInt is typically used to hold the oop for an object and indeed it points to the header word of the object. The object is preceded by an overflow header word if it has more than 254 slots.

Are there cast as pointers?

Yes. See the functions and macros in platforms/Cross/vm/sqMemoryAccess.h.

Thank you in advance :)

Pierre.

_,,,^..^,,,_

best, Eliot

Eliot Miranda-2

Re: Slang's type inference and typing

Hi Pierre, and welcome.

On Dec 16, 2019, at 10:19 PM, pierre misse <[hidden email]> wrote:

Hi Eliot,

Thanks for the detailed answer and all the pointers !

I must have misunderstood #inferTypesForImplicitlyTypedVariablesAndMethods when I first came across it.

Have a nice day :)

thank you :)

Pierre

On 17/12/2019 01:14, Eliot Miranda wrote:

Hi Pierre,

On Mon, Dec 16, 2019 at 4:07 AM pierre misse <[hidden email]> wrote:

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

Is it your intention to contribute those tests back to VMMaker.oscog on source.squeak.org?

If I am able to, it is my intention.

Thank you. It be warmly appreciated.

One thing yo look at in your tests is instabilities in the algorithm, typically caused by the use of hashed collections (eg Set) that have different enumerations from run to run, usually due to hashes being pseudo-randomly computed. If you look at the last commit of the Spur cointerp.c’s you’ll see one variable that changes type from sqInt to usqInt. This points to such a bug. I’ll try and provide you with specifics soon.

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Here's some doit that run Slang including type inference:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/Slang%20Test%20Workspace.text

If you use https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh to build a VMMaker image it'll create an image containing g this and other useful workspaces that contain doit to launch a VM under the simulator, etc.

Type inference is driven by this loop in CCodeGeneraror>>inferTypesForImplicitlyTypedVariablesAndMethods which iterates, inferring types until no more types can b e inferred (until the algorithm has reached a fixed point).

"now iterate until we reach a fixed point"

[| changedReturnType |

changedReturnType := false.

allMethods do:

[:m|

m inferTypesForImplicitlyTypedVariablesIn: self.

(m inferReturnTypeIn: self) ifTrue:

[changedReturnType := true]].

changedReturnType] whileTrue.

Type information is derived from explicit return types in methods (the <returnTypeC: > pragma), types for "kernel" sends from CCodeGenerator>>#returnTypeForSend:in:ifNil:, and for types propagated to returns from variables that themselves are either explicitly typed using <var: ... type: ...> and <var: ... declareC: ...> pragmas, or get their types in assignments of the results of methods, where the type they acquire is the return types of those methods.

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that.

#sqInt is first of all a pun for "squint"

nice , I was wondering if that was the case too :D

, a shortening of Squeak Integer. It is an integer type of the same size as an "ordinary object pointer", or "oop". #usqInt, #sqLong & #usqLong are other important types. #sqLong & #usqLong are 64-bit types. #sqInt & #usqInt are 32-bit types in 32-bit VMs and 64-bit types in 64-bit VMs.

Are there offsets to find objects in the object memory?

A #sqInt is typically used to hold the oop for an object and indeed it points to the header word of the object. The object is preceded by an overflow header word if it has more than 254 slots.

Are there cast as pointers?

Yes. See the functions and macros in platforms/Cross/vm/sqMemoryAccess.h.

Thank you in advance :)

Pierre.

_,,,^..^,,,_

best, Eliot

Cheers

pierre misse

Re: Slang's type inference and typing

My first approach is very simple

create a CCodeGenerator
add only my current class with independent methods
infer the type
check the types.

testConstantInt32
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: self class.
    tMethod := ccg compileToTMethodSelector: #anInt32 in: self class.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    ccg typeFor: tMethod statements first expression variable in: tMethod. "#sqInt"
    tMethod inferReturnTypeFromReturnsIn: ccg."a TMethod (SlangTypeInferenceTests>>anInt32)"
    tMethod returnType."nil"

Applied in this case to:

anInt32
| a |
^ a := 30

Maybe I misunderstood the type Inference that I read so far, but based on #TMethod >> #typeFor:in:,
I would expect the ccg to keep the type information somewhere, which doesn't seem to be the case.

Maybe it's because my set up is wrong?

This part of the comment puzzles me "deferring to aCodeGen (which defers to the vmClass)", gonna dig into this method.

Thank you,

Pierre

On 17/12/2019 07:33, Eliot Miranda wrote:

 
Hi Pierre, and welcome.

On Dec 16, 2019, at 10:19 PM, pierre misse [hidden email] wrote:

Hi Eliot,

Thanks for the detailed answer and all the pointers !

I must have misunderstood #inferTypesForImplicitlyTypedVariablesAndMethods when I first came across it.

Have a nice day :)

thank you :)
Pierre

On 17/12/2019 01:14, Eliot Miranda wrote:

Hi Pierre,

On Mon, Dec 16, 2019 at 4:07 AM pierre misse <[hidden email]> wrote:

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

Is it your intention to contribute those tests back to VMMaker.oscog on source.squeak.org?

If I am able to, it is my intention.
Thank you. It be warmly appreciated.
One thing yo look at in your tests is instabilities in the algorithm, typically caused by the use of hashed collections (eg Set) that have different enumerations from run to run, usually due to hashes being pseudo-randomly computed. If you look at the last commit of the Spur cointerp.c’s you’ll see one variable that changes type from sqInt to usqInt. This points to such a bug. I’ll try and provide you with specifics soon.

Thanks for the warning. I was actually already aware of this bug, but now I also know the cause !

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Here's some doit that run Slang including type inference:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/Slang%20Test%20Workspace.text

If you use https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh to build a VMMaker image it'll create an image containing g this and other useful workspaces that contain doit to launch a VM under the simulator, etc.

Type inference is driven by this loop in CCodeGeneraror>>inferTypesForImplicitlyTypedVariablesAndMethods which iterates, inferring types until no more types can b e inferred (until the algorithm has reached a fixed point).

"now iterate until we reach a fixed point"

[| changedReturnType |

changedReturnType := false.

allMethods do:

[:m|

m inferTypesForImplicitlyTypedVariablesIn: self.

(m inferReturnTypeIn: self) ifTrue:

[changedReturnType := true]].

changedReturnType] whileTrue.

Type information is derived from explicit return types in methods (the <returnTypeC: > pragma), types for "kernel" sends from CCodeGenerator>>#returnTypeForSend:in:ifNil:, and for types propagated to returns from variables that themselves are either explicitly typed using <var: ... type: ...> and <var: ... declareC: ...> pragmas, or get their types in assignments of the results of methods, where the type they acquire is the return types of those methods.

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that.

#sqInt is first of all a pun for "squint"

nice , I was wondering if that was the case too :D

, a shortening of Squeak Integer. It is an integer type of the same size as an "ordinary object pointer", or "oop". #usqInt, #sqLong & #usqLong are other important types. #sqLong & #usqLong are 64-bit types. #sqInt & #usqInt are 32-bit types in 32-bit VMs and 64-bit types in 64-bit VMs.

Are there offsets to find objects in the object memory?

A #sqInt is typically used to hold the oop for an object and indeed it points to the header word of the object. The object is preceded by an overflow header word if it has more than 254 slots.

Are there cast as pointers?

Yes. See the functions and macros in platforms/Cross/vm/sqMemoryAccess.h.

Thank you in advance :)

Pierre.

_,,,^..^,,,_

best, Eliot

Cheers

pierre misse

Re: Slang's type inference and typing

Hi,

I saw my previous mistake, and corrected this.
This is a sample test, for a very simple inference.

testReturnFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnAFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: tMethod returnType equals: #double

I need to work on ones with ambiguity.

Pierre

On 17/12/2019 07:49, pierre misse wrote:

 
My first approach is very simple

create a CCodeGenerator
add only my current class with independent methods
infer the type
check the types.

testConstantInt32
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: self class.
    tMethod := ccg compileToTMethodSelector: #anInt32 in: self class.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    ccg typeFor: tMethod statements first expression variable in: tMethod. "#sqInt"
    tMethod inferReturnTypeFromReturnsIn: ccg."a TMethod (SlangTypeInferenceTests>>anInt32)"
    tMethod returnType."nil"

Applied in this case to:

anInt32
    | a |
    ^ a := 30

Maybe I misunderstood the type Inference that I read so far, but based on #TMethod >> #typeFor:in:,
I would expect the ccg to keep the type information somewhere, which doesn't seem to be the case.

Maybe it's because my set up is wrong?

This part of the comment puzzles me "deferring to aCodeGen (which defers to the vmClass)", gonna dig into this method.

Thank you,

Pierre

On 17/12/2019 07:33, Eliot Miranda wrote:
 
Hi Pierre, and welcome.

On Dec 16, 2019, at 10:19 PM, pierre misse [hidden email] wrote:

Hi Eliot,

Thanks for the detailed answer and all the pointers !

I must have misunderstood #inferTypesForImplicitlyTypedVariablesAndMethods when I first came across it.

Have a nice day :)

thank you :)
Pierre

On 17/12/2019 01:14, Eliot Miranda wrote:

Hi Pierre,

On Mon, Dec 16, 2019 at 4:07 AM pierre misse <[hidden email]> wrote:

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

Is it your intention to contribute those tests back to VMMaker.oscog on source.squeak.org?

If I am able to, it is my intention.
Thank you. It be warmly appreciated.
One thing yo look at in your tests is instabilities in the algorithm, typically caused by the use of hashed collections (eg Set) that have different enumerations from run to run, usually due to hashes being pseudo-randomly computed. If you look at the last commit of the Spur cointerp.c’s you’ll see one variable that changes type from sqInt to usqInt. This points to such a bug. I’ll try and provide you with specifics soon.
Thanks for the warning. I was actually already aware of this bug, but now I also know the cause !

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Here's some doit that run Slang including type inference:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/Slang%20Test%20Workspace.text

If you use https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh to build a VMMaker image it'll create an image containing g this and other useful workspaces that contain doit to launch a VM under the simulator, etc.

Type inference is driven by this loop in CCodeGeneraror>>inferTypesForImplicitlyTypedVariablesAndMethods which iterates, inferring types until no more types can b e inferred (until the algorithm has reached a fixed point).

"now iterate until we reach a fixed point"

[| changedReturnType |

changedReturnType := false.

allMethods do:

[:m|

m inferTypesForImplicitlyTypedVariablesIn: self.

(m inferReturnTypeIn: self) ifTrue:

[changedReturnType := true]].

changedReturnType] whileTrue.

Type information is derived from explicit return types in methods (the <returnTypeC: > pragma), types for "kernel" sends from CCodeGenerator>>#returnTypeForSend:in:ifNil:, and for types propagated to returns from variables that themselves are either explicitly typed using <var: ... type: ...> and <var: ... declareC: ...> pragmas, or get their types in assignments of the results of methods, where the type they acquire is the return types of those methods.

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that.

#sqInt is first of all a pun for "squint"

nice , I was wondering if that was the case too :D

, a shortening of Squeak Integer. It is an integer type of the same size as an "ordinary object pointer", or "oop". #usqInt, #sqLong & #usqLong are other important types. #sqLong & #usqLong are 64-bit types. #sqInt & #usqInt are 32-bit types in 32-bit VMs and 64-bit types in 64-bit VMs.

Are there offsets to find objects in the object memory?

A #sqInt is typically used to hold the oop for an object and indeed it points to the header word of the object. The object is preceded by an overflow header word if it has more than 254 slots.

Are there cast as pointers?

Yes. See the functions and macros in platforms/Cross/vm/sqMemoryAccess.h.

Thank you in advance :)

Pierre.

_,,,^..^,,,_

best, Eliot

Cheers

Eliot Miranda-2

Re: Slang's type inference and typing

Hi Pierre,

On Tue, Dec 17, 2019 at 9:50 AM pierre misse <[hidden email]> wrote:

Hi,

I saw my previous mistake, and corrected this.
This is a sample test, for a very simple inference.

testReturnFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnAFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: tMethod returnType equals: #double

And perhaps have SlangTypeInferenceTestsClass inherit from StackInterpreter or InterpreterPrimitives. That will give you much more context.

I need to work on ones with ambiguity.

The instability I saw was in getErrorObjectFromPrimFailCode; its two locals clone & errObj are sometimes typed as squint and sometimes as usqInt. Some times numPointerSlotsOf ends up with a return type of usqInt, some times as sqInt. I've recently had success in another project substituting OrderedDictionary et al for Dictionary. So I'm sure that solutions can be found easily.

Pierre

On 17/12/2019 07:49, pierre misse wrote:
 
My first approach is very simple

create a CCodeGenerator
add only my current class with independent methods
infer the type
check the types.

testConstantInt32
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: self class.
    tMethod := ccg compileToTMethodSelector: #anInt32 in: self class.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    ccg typeFor: tMethod statements first expression variable in: tMethod. "#sqInt"
    tMethod inferReturnTypeFromReturnsIn: ccg."a TMethod (SlangTypeInferenceTests>>anInt32)"
    tMethod returnType."nil"

Applied in this case to:

anInt32
    | a |
    ^ a := 30

Maybe I misunderstood the type Inference that I read so far, but based on #TMethod >> #typeFor:in:,
I would expect the ccg to keep the type information somewhere, which doesn't seem to be the case.

Maybe it's because my set up is wrong?

This part of the comment puzzles me "deferring to aCodeGen (which defers to the vmClass)", gonna dig into this method.

Thank you,

Pierre

On 17/12/2019 07:33, Eliot Miranda wrote:
 
Hi Pierre, and welcome.

On Dec 16, 2019, at 10:19 PM, pierre misse [hidden email] wrote:

Hi Eliot,

Thanks for the detailed answer and all the pointers !

I must have misunderstood #inferTypesForImplicitlyTypedVariablesAndMethods when I first came across it.

Have a nice day :)

thank you :)
Pierre

On 17/12/2019 01:14, Eliot Miranda wrote:

Hi Pierre,

On Mon, Dec 16, 2019 at 4:07 AM pierre misse <[hidden email]> wrote:

Hi,

I'm currently trying to understand Slang's type inference, and to do so trying to write tests.

Is it your intention to contribute those tests back to VMMaker.oscog on source.squeak.org?

If I am able to, it is my intention.
Thank you. It be warmly appreciated.
One thing yo look at in your tests is instabilities in the algorithm, typically caused by the use of hashed collections (eg Set) that have different enumerations from run to run, usually due to hashes being pseudo-randomly computed. If you look at the last commit of the Spur cointerp.c’s you’ll see one variable that changes type from sqInt to usqInt. This points to such a bug. I’ll try and provide you with specifics soon.
Thanks for the warning. I was actually already aware of this bug, but now I also know the cause !

I'm using CCodeGenerator >> #compileToTMethodSelector:in: to get the TMethod, but i cannot seem to find how to use the type inference on this TMethod (or in the instance of CCodeGenerator).

Here's some doit that run Slang including type inference:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/Slang%20Test%20Workspace.text

If you use https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh to build a VMMaker image it'll create an image containing g this and other useful workspaces that contain doit to launch a VM under the simulator, etc.

Type inference is driven by this loop in CCodeGeneraror>>inferTypesForImplicitlyTypedVariablesAndMethods which iterates, inferring types until no more types can b e inferred (until the algorithm has reached a fixed point).

"now iterate until we reach a fixed point"

[| changedReturnType |

changedReturnType := false.

allMethods do:

[:m|

m inferTypesForImplicitlyTypedVariablesIn: self.

(m inferReturnTypeIn: self) ifTrue:

[changedReturnType := true]].

changedReturnType] whileTrue.

Type information is derived from explicit return types in methods (the <returnTypeC: > pragma), types for "kernel" sends from CCodeGenerator>>#returnTypeForSend:in:ifNil:, and for types propagated to returns from variables that themselves are either explicitly typed using <var: ... type: ...> and <var: ... declareC: ...> pragmas, or get their types in assignments of the results of methods, where the type they acquire is the return types of those methods.

Also, I have been wondering what is the semantic of sqInt. I found out it was an alias for a long, but i couldn't find better than that.

#sqInt is first of all a pun for "squint"

nice , I was wondering if that was the case too :D

, a shortening of Squeak Integer. It is an integer type of the same size as an "ordinary object pointer", or "oop". #usqInt, #sqLong & #usqLong are other important types. #sqLong & #usqLong are 64-bit types. #sqInt & #usqInt are 32-bit types in 32-bit VMs and 64-bit types in 64-bit VMs.

Are there offsets to find objects in the object memory?

A #sqInt is typically used to hold the oop for an object and indeed it points to the header word of the object. The object is preceded by an overflow header word if it has more than 254 slots.

Are there cast as pointers?

Yes. See the functions and macros in platforms/Cross/vm/sqMemoryAccess.h.

Thank you in advance :)

Pierre.

_,,,^..^,,,_

best, Eliot

Cheers

_,,,^..^,,,_

best, Eliot

pierre misse

Re: Slang's type inference and typing

On 18/12/2019 03:52, Eliot Miranda wrote:

 
Hi Pierre,

On Tue, Dec 17, 2019 at 9:50 AM pierre misse <[hidden email]> wrote:

Hi,

I saw my previous mistake, and corrected this.
This is a sample test, for a very simple inference.

testReturnFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnAFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: tMethod returnType equals: #double

And perhaps have SlangTypeInferenceTestsClass inherit from StackInterpreter or InterpreterPrimitives. That will give you much more context.

I was currently inheriting from interpreterPlugin, but I can indeed switch.

My tests currently were as simple as it gets:

constantNode
Returm constant
return Explicit argument
return Explicit Temporary
return temp assigned by constant.

So it wasn't necessary.

Only surprising result is the return temp assigned by constant, which looses the type. This seems to be easily improvable in the future if you'd like.

returnTempFloatConstantNode
    | t |
    t := 1.0.
    ^ t

testReturnTempFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnTempFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: (ccg typeFor: tMethod statements first variable in: tMethod) equals: #sqInt.
    self assert: tMethod returnType equals: #sqInt.

    self error "wait what"

I need to work on ones with ambiguity.

The instability I saw was in getErrorObjectFromPrimFailCode; its two locals clone & errObj are sometimes typed as squint and sometimes as usqInt. Some times numPointerSlotsOf ends up with a return type of usqInt, some times as sqInt. I've recently had success in another project substituting OrderedDictionary et al for Dictionary. So I'm sure that solutions can be found easily.

Thanks for the pointer !

Pierre

pierre misse

Re: Slang's type inference and typing

On 18/12/2019 07:36, pierre misse wrote:

 
On 18/12/2019 03:52, Eliot Miranda wrote:
 
Hi Pierre,

On Tue, Dec 17, 2019 at 9:50 AM pierre misse <[hidden email]> wrote:

Hi,

I saw my previous mistake, and corrected this.
This is a sample test, for a very simple inference.

testReturnFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnAFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: tMethod returnType equals: #double

And perhaps have SlangTypeInferenceTestsClass inherit from StackInterpreter or InterpreterPrimitives. That will give you much more context.
I was currently inheriting from interpreterPlugin, but I can indeed switch.

My tests currently were as simple as it gets:

constantNode
Returm constant
return Explicit argument
return Explicit Temporary
return temp assigned by constant.

and return message send (which returns a constant)*

So it wasn't necessary.

Only surprising result is the return temp assigned by constant, which looses the type. This seems to be easily improvable in the future if you'd like.

returnTempFloatConstantNode
    | t |
    t := 1.0.
    ^ t

testReturnTempFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnTempFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: (ccg typeFor: tMethod statements first variable in: tMethod) equals: #sqInt.
    self assert: tMethod returnType equals: #sqInt.

    self error "wait what"

I need to work on ones with ambiguity.

The instability I saw was in getErrorObjectFromPrimFailCode; its two locals clone & errObj are sometimes typed as squint and sometimes as usqInt. Some times numPointerSlotsOf ends up with a return type of usqInt, some times as sqInt. I've recently had success in another project substituting OrderedDictionary et al for Dictionary. So I'm sure that solutions can be found easily.

Thanks for the pointer !

Pierre

Eliot Miranda-2

Re: Slang's type inference and typing

In reply to this post by pierre misse

Hi Pierre,

On Tue, Dec 17, 2019 at 10:36 PM pierre misse <[hidden email]> wrote:

On 18/12/2019 03:52, Eliot Miranda wrote:
 
Hi Pierre,

On Tue, Dec 17, 2019 at 9:50 AM pierre misse <[hidden email]> wrote:

Hi,

I saw my previous mistake, and corrected this.
This is a sample test, for a very simple inference.

testReturnFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnAFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: tMethod returnType equals: #double

And perhaps have SlangTypeInferenceTestsClass inherit from StackInterpreter or InterpreterPrimitives. That will give you much more context.
I was currently inheriting from interpreterPlugin, but I can indeed switch.

I think you have it right. interpreterPlugin should be fine.

My tests currently were as simple as it gets:

constantNode
Returm constant
return Explicit argument
return Explicit Temporary
return temp assigned by constant.

So it wasn't necessary.

Only surprising result is the return temp assigned by constant, which loses the type. This seems to be easily improvable in the future if you'd like.

returnTempFloatConstantNode
    | t |
    t := 1.0.
    ^ t

Its its return type isn't inferred to be #double then that's a bug.

testReturnTempFloatConstantNode
    | ccg tMethod |
    ccg := CCodeGenerator new.
    ccg addClass: SlangTypeInferenceTestsClass.
    ccg inferTypesForImplicitlyTypedVariablesAndMethods.
    tMethod := ccg methodNamed: #returnTempFloatConstantNode.

    self assert: tMethod isNotNil.
    self assert: (ccg typeFor: tMethod statements first in: tMethod) equals: #double.
    self assert: (ccg typeFor: tMethod statements first variable in: tMethod) equals: #sqInt.
    self assert: tMethod returnType equals: #sqInt.

Well, t is untyped and it is assigned a double. So I would expect that the inferencer infer the ty[e #double for f. Then it should infer the type #double for returnTempFloatConstantNode since it answers t.

self error "wait what"

I need to work on ones with ambiguity.

The instability I saw was in getErrorObjectFromPrimFailCode; its two locals clone & errObj are sometimes typed as squint and sometimes as usqInt. Some times numPointerSlotsOf ends up with a return type of usqInt, some times as sqInt. I've recently had success in another project substituting OrderedDictionary et al for Dictionary. So I'm sure that solutions can be found easily.

Thanks for the pointer !

Pierre

Thanks for looking!! It will be great to have tests for this, if only for good documentation. I never had the time, and always look at the diffs of the generated code. But that doesn't mean I don't want these tests. Thank you for your energy!

_,,,^..^,,,_

best, Eliot

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

In reply to this post by David T Lewis

@nicolas-cellier-aka-nice commented on this pull request.

In platforms/Cross/plugins/sqPluginsSCCSVersion.h:

> @@ -9,10 +9,10 @@
  */
 
 #if SUBVERSION
-static char SvnRawPluginsRevisionString[] = "$Rev$";
+static char SvnRawPluginsRevisionString[] = "$Rev: 201911192350 $";

As Tobias noticed, the changes to this file should be reverted

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)

In reply to this post by David T Lewis

@nicolas-cellier-aka-nice commented on this pull request.

In platforms/Cross/vm/sqSCCSVersion.h:

> @@ -28,13 +28,13 @@
 
 #if SUBVERSION
 # define PREFIX "r"
-static char SvnRawRevisionString[] = "$Rev$";
+static char SvnRawRevisionString[] = "$Rev: 201911192350 $";

Idem, please revert the changes to this file

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.