SqueakCogSpur32x86.xcworkspace

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

SqueakCogSpur32x86.xcworkspace

johnmci
 
I have provided a SqueakCogSpur32x86.xcworkspace in 
Cog/build.macos32x86/squeak.cog.spur/ 

This builds a Cog Spur 32bit i386 VM, using the Cocoa UI. Ya.

However the Objective-C 'legacy' runtime does not support ARC (automatic reference counting), but the UI is all ARC aware. This means the app leaks memory like crazy, so don't even think of using it for anything but testing. 

I have to now look into what is required to backport the pre-arc source changes to the cog branch for i386 usage. 

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

Eliot Miranda-2
 
Hi John,

    what do the current Pharo vm's Cocoa sources do?  Can we not merge with that code base?

_,,,^..^,,,_ (phone)

On Sep 26, 2015, at 12:37 PM, John McIntosh <[hidden email]> wrote:

I have provided a SqueakCogSpur32x86.xcworkspace in 
Cog/build.macos32x86/squeak.cog.spur/ 

This builds a Cog Spur 32bit i386 VM, using the Cocoa UI. Ya.

However the Objective-C 'legacy' runtime does not support ARC (automatic reference counting), but the UI is all ARC aware. This means the app leaks memory like crazy, so don't even think of using it for anything but testing. 

I have to now look into what is required to backport the pre-arc source changes to the cog branch for i386 usage. 

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

johnmci
 
I merged most of their changes already. I have to make an inventory of the changes then consolidate 

Sent from my iPhone

On Sep 26, 2015, at 8:24 PM, Eliot Miranda <[hidden email]> wrote:

Hi John,

    what do the current Pharo vm's Cocoa sources do?  Can we not merge with that code base?

_,,,^..^,,,_ (phone)

On Sep 26, 2015, at 12:37 PM, John McIntosh <[hidden email]> wrote:

I have provided a SqueakCogSpur32x86.xcworkspace in 
Cog/build.macos32x86/squeak.cog.spur/ 

This builds a Cog Spur 32bit i386 VM, using the Cocoa UI. Ya.

However the Objective-C 'legacy' runtime does not support ARC (automatic reference counting), but the UI is all ARC aware. This means the app leaks memory like crazy, so don't even think of using it for anything but testing. 

I have to now look into what is required to backport the pre-arc source changes to the cog branch for i386 usage. 

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

Eliot Miranda-2
 
Hi John,

On Sep 26, 2015, at 9:05 PM, [hidden email] wrote:

I merged most of their changes already. I have to make an inventory of the changes then consolidate 

Ok, but the other part of my question is important.  What does the Pharo code do to avoid leaking memory, or is it leaking memory now?


Sent from my iPhone

On Sep 26, 2015, at 8:24 PM, Eliot Miranda <[hidden email]> wrote:

Hi John,

    what do the current Pharo vm's Cocoa sources do?  Can we not merge with that code base?

_,,,^..^,,,_ (phone)

On Sep 26, 2015, at 12:37 PM, John McIntosh <[hidden email]> wrote:

I have provided a SqueakCogSpur32x86.xcworkspace in 
Cog/build.macos32x86/squeak.cog.spur/ 

This builds a Cog Spur 32bit i386 VM, using the Cocoa UI. Ya.

However the Objective-C 'legacy' runtime does not support ARC (automatic reference counting), but the UI is all ARC aware. This means the app leaks memory like crazy, so don't even think of using it for anything but testing. 

I have to now look into what is required to backport the pre-arc source changes to the cog branch for i386 usage. 

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

johnmci
 
99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.

Now I have to backport the code to a format that works in both environments. 

Sent from my iPhone

On Sep 27, 2015, at 12:39 AM, Eliot Miranda <[hidden email]> wrote:

Hi John,

On Sep 26, 2015, at 9:05 PM, [hidden email] wrote:

I merged most of their changes already. I have to make an inventory of the changes then consolidate 

Ok, but the other part of my question is important.  What does the Pharo code do to avoid leaking memory, or is it leaking memory now?


Sent from my iPhone

On Sep 26, 2015, at 8:24 PM, Eliot Miranda <[hidden email]> wrote:

Hi John,

    what do the current Pharo vm's Cocoa sources do?  Can we not merge with that code base?

_,,,^..^,,,_ (phone)

On Sep 26, 2015, at 12:37 PM, John McIntosh <[hidden email]> wrote:

I have provided a SqueakCogSpur32x86.xcworkspace in 
Cog/build.macos32x86/squeak.cog.spur/ 

This builds a Cog Spur 32bit i386 VM, using the Cocoa UI. Ya.

However the Objective-C 'legacy' runtime does not support ARC (automatic reference counting), but the UI is all ARC aware. This means the app leaks memory like crazy, so don't even think of using it for anything but testing. 

I have to now look into what is required to backport the pre-arc source changes to the cog branch for i386 usage. 

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

Colin Putney-3
 


On Sun, Sep 27, 2015 at 1:02 AM, <[hidden email]> wrote:
 
99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.

Now I have to backport the code to a format that works in both environments. 

IIUC, that means the Pharo VM is *not* ARC-aware, which is why it doesn't leak memory. What you've posted now is a step forward from all that, but not yet complete. Is that right?

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

Re: SqueakCogSpur32x86.xcworkspace

johnmci
 
Yes, I have to go back and re-introduce something that lets us build a non-arc version for 32bit, and a arc aware version for os-x 64bit, an iOS 32/64bit

On Sun, Sep 27, 2015 at 1:19 AM, Colin Putney <[hidden email]> wrote:
 


On Sun, Sep 27, 2015 at 1:02 AM, <[hidden email]> wrote:
 
99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.

Now I have to backport the code to a format that works in both environments. 

IIUC, that means the Pharo VM is *not* ARC-aware, which is why it doesn't leak memory. What you've posted now is a step forward from all that, but not yet complete. Is that right?

-Colin 




--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

Ben Coman

On Mon, Sep 28, 2015 at 3:25 AM, John McIntosh
<[hidden email]> wrote:
>
> Yes, I have to go back and re-introduce something that lets us build a non-arc version for 32bit, and a arc aware version for os-x 64bit, an iOS 32/64bit

This is the first I heard of ARC, so I've read a bit and now I'm just
curious about a few things mentioned at [1].

Will you have one vm "platform" with #ifdefs for different ARC &
non-ARC code paths, or is it better to treat ARC and non-ARC code as
two separate platforms?  It seems part of the arc advantage of concise
code is negated by additional #ifdefs.  This is maybe suggested by [1]
(but I don't know if "separate xcodeproj" implies a "separate
platform" for us)

ARC seems ObjC based? Is the os-x vm code written in ObjC rather than C?

Does the vm code use Core Foundation much?  [1] implies there are
added complications.

Does the vm code do math on pointers?  [1] implies there are added
complications.

With the ARC-vm code doing reference counted garbage collection, does
this encompass the memory the vm allocates to objects inside the
Image?  Can we forgo our traditional scanning garbage collection?  Or
do you opt out of ARC for the code that hands memory to the Image so
there are not two layers of garbage collection?

Someone's comment [1] from 2012 "There is one serious downside that
wasn't mentioned: cross-compatibility. For us brave and foolish souls
that face the wastelands known as cross-platform programming, ARC
simply isn't an option, at least not until GNU expand upon their ObjC
runtime and compiler features again (they say more is on the way)."
Is this now covered in gcc?  Or is different complier used?


[1] http://stackoverflow.com/questions/8760431/to-arc-or-not-to-arc-what-are-the-pros-and-cons

cheers -ben


>
> On Sun, Sep 27, 2015 at 1:19 AM, Colin Putney <[hidden email]> wrote:
>>
>>
>>
>>
>> On Sun, Sep 27, 2015 at 1:02 AM, <[hidden email]> wrote:
>>>
>>>
>>> 99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.
>>>
>>> Now I have to backport the code to a format that works in both environments.
>>
>>
>> IIUC, that means the Pharo VM is *not* ARC-aware, which is why it doesn't leak memory. What you've posted now is a step forward from all that, but not yet complete. Is that right?
>>
>> -Colin
>>
>
>
>
> --
> ===========================================================================
> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
> ===========================================================================
>
Reply | Threaded
Open this post in threaded view
|

Re: SqueakCogSpur32x86.xcworkspace

johnmci
 


Sent from my iPhone

> On Sep 27, 2015, at 6:51 PM, Ben Coman <[hidden email]> wrote:
>
>
> On Mon, Sep 28, 2015 at 3:25 AM, John McIntosh
> <[hidden email]> wrote:
>>
>> Yes, I have to go back and re-introduce something that lets us build a non-arc version for 32bit, and a arc aware version for os-x 64bit, an iOS 32/64bit
>
> This is the first I heard of ARC, so I've read a bit and now I'm just
> curious about a few things mentioned at [1].
>
> Will you have one vm "platform" with #ifdefs for different ARC &
> non-ARC code paths, or is it better to treat ARC and non-ARC code as
> two separate platforms?  It seems part of the arc advantage of concise
> code is negated by additional #ifdefs.  This is maybe suggested by [1]
> (but I don't know if "separate xcodeproj" implies a "separate
> platform" for us)
Only a few percentages of the code base require something to deal with arc/non-arc so there will only be one source file, not two


>
> ARC seems ObjC based? Is the os-x vm code written in ObjC rather than C?

The OS X VM code is mostly all objective-c with some C code, for example the sound plugin is objective-c, but for sockets we just use the UNIX C code

>
> Does the vm code use Core Foundation much?  [1] implies there are
> added complications.

There is a bit of that, and yes you have be careful, less so for non-arc

>
> Does the vm code do math on pointers?  [1] implies there are added
> complications.

No we don't do that

>
> With the ARC-vm code doing reference counted garbage collection, does
> this encompass the memory the vm allocates to objects inside the
> Image?  Can we forgo our traditional scanning garbage collection?  Or
> do you opt out of ARC for the code that hands memory to the Image so
> there are not two layers of garbage collection?

The Squeak VM is an implementation that requires a hosting environment that supports various services which are mostly documented at https://isqueak.org/PlatformVMAPI

You can compile the VM code then start adding the various C calls that turn up as unimplemented.

When we start up the VM with a targeted image, the image header/meta data is read, the amount of memory needed to run the image is allocated, then the image file is read or mapped into that memory space and the VM code is called to swizzle pointers, fix endian changes and the like.  Then VM state data is loaded and the VM continues from the execution point of the saved snapshot.

Squeak objects aren't managed by the operating system memory management excluding specific mallocs needed for direct API calls for FFI for example.  

>
> Someone's comment [1] from 2012 "There is one serious downside that
> wasn't mentioned: cross-compatibility. For us brave and foolish souls
> that face the wastelands known as cross-platform programming, ARC
> simply isn't an option, at least not until GNU expand upon their ObjC
> runtime and compiler features again (they say more is on the way)."
> Is this now covered in gcc?  Or is different complier used?
>

GCC is dead, long live LLVM


>
> [1] http://stackoverflow.com/questions/8760431/to-arc-or-not-to-arc-what-are-the-pros-and-cons
>
> cheers -ben
>
>
>>
>>> On Sun, Sep 27, 2015 at 1:19 AM, Colin Putney <[hidden email]> wrote:
>>>
>>>
>>>
>>>
>>>> On Sun, Sep 27, 2015 at 1:02 AM, <[hidden email]> wrote:
>>>>
>>>>
>>>> 99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.
>>>>
>>>> Now I have to backport the code to a format that works in both environments.
>>>
>>>
>>> IIUC, that means the Pharo VM is *not* ARC-aware, which is why it doesn't leak memory. What you've posted now is a step forward from all that, but not yet complete. Is that right?
>>>
>>> -Colin
>>
>>
>>
>> --
>> ===========================================================================
>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
>> ===========================================================================
>>

smime.p7s (3K) Download Attachment