New Cog VMs available

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

New Cog VMs available

Eliot Miranda-2
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?  If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot







Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Bob Arning-2
Seems like you could do that fairly easily without making the VM re-entrant (whatever that might mean/entail). If you thought of your Squeak app and your C app as two computers on a network, they could send each other requests and responses all day long. No magic required.

Cheers,
Bob

On 12/3/12 10:10 AM, Blake McBride wrote:
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?  If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot








    



Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
The interaction would be slower, and the installation / integration would be more complex.  Back then, all we did was install the exe on the server.  Client computer connection merely loaded the latest exe.  No need to startup another app and share a socket, etc..  This would never work in instances where you have 100 users all on different machines.  You'd have one conflict after another.

Also, doing it in a client/server motif as you describe means that any global state information made by one call would affect other calls.  In true reentrancy each recursive call would essentially get their own VM.

Thanks.

Blake



On Mon, Dec 3, 2012 at 9:39 AM, Bob Arning <[hidden email]> wrote:
Seems like you could do that fairly easily without making the VM re-entrant (whatever that might mean/entail). If you thought of your Squeak app and your C app as two computers on a network, they could send each other requests and responses all day long. No magic required.

Cheers,
Bob


On 12/3/12 10:10 AM, Blake McBride wrote:
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?  If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot








    







Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Bob Arning-2

On 12/3/12 11:01 AM, Blake McBride wrote:
The interaction would be slower, and the installation / integration would be more complex. 
I'd like to understand better what sort of calls you wanted to make from C to Squeak. I was thinking the reason you wanted Squeak included was for some non-trivial processing, so the socket time might not matter much. If you are calling Squeak to convert a character from upper to lowercase, then interaction would be noticeably slower. Could you give an example or two?
Back then, all we did was install the exe on the server.  Client computer connection merely loaded the latest exe.  No need to startup another app and share a socket, etc..  This would never work in instances where you have 100 users all on different machines.  You'd have one conflict after another.
So, in your ideal world, where did Squeak get installed? Bundled in the C app on each client? As a separate app on each client? Once on a server somewhere?

Also, doing it in a client/server motif as you describe means that any global state information made by one call would affect other calls.
Why would there be any global information? If client #27 sent a request to the squeak app, the squeak app could limit its response to data that client would need to know.
 In true reentrancy each recursive call would essentially get their own VM.
They could, but what's in the VM that they really need a separate copy of?

Cheers,
Bob

Thanks.

Blake



On Mon, Dec 3, 2012 at 9:39 AM, Bob Arning <[hidden email]> wrote:
Seems like you could do that fairly easily without making the VM re-entrant (whatever that might mean/entail). If you thought of your Squeak app and your C app as two computers on a network, they could send each other requests and responses all day long. No magic required.

Cheers,
Bob


On 12/3/12 10:10 AM, Blake McBride wrote:
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?  If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot















    



Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Frank Shearar-3
On 3 December 2012 16:25, Bob Arning <[hidden email]> wrote:

>
> On 12/3/12 11:01 AM, Blake McBride wrote:
>
> The interaction would be slower, and the installation / integration would be
> more complex.
>
> I'd like to understand better what sort of calls you wanted to make from C
> to Squeak. I was thinking the reason you wanted Squeak included was for some
> non-trivial processing, so the socket time might not matter much. If you are
> calling Squeak to convert a character from upper to lowercase, then
> interaction would be noticeably slower. Could you give an example or two?
>
> Back then, all we did was install the exe on the server.  Client computer
> connection merely loaded the latest exe.  No need to startup another app and
> share a socket, etc..  This would never work in instances where you have 100
> users all on different machines.  You'd have one conflict after another.
>
> So, in your ideal world, where did Squeak get installed? Bundled in the C
> app on each client? As a separate app on each client? Once on a server
> somewhere?
>
>
> Also, doing it in a client/server motif as you describe means that any
> global state information made by one call would affect other calls.
>
> Why would there be any global information? If client #27 sent a request to
> the squeak app, the squeak app could limit its response to data that client
> would need to know.
>
>  In true reentrancy each recursive call would essentially get their own VM.
>
> They could, but what's in the VM that they really need a separate copy of?

It's not the VM, it's the shared state of the image that would cause a
problem (if anything did). I would think, at least.

frank

> Cheers,
> Bob
>
>
> Thanks.
>
> Blake
>
>
>
> On Mon, Dec 3, 2012 at 9:39 AM, Bob Arning <[hidden email]> wrote:
>>
>> Seems like you could do that fairly easily without making the VM
>> re-entrant (whatever that might mean/entail). If you thought of your Squeak
>> app and your C app as two computers on a network, they could send each other
>> requests and responses all day long. No magic required.
>>
>> Cheers,
>> Bob
>>
>>
>> On 12/3/12 10:10 AM, Blake McBride wrote:
>>
>> Greetings,
>>
>> I tried to integrate Squeak to a C based application more than six years
>> ago.  The project failed because we were not able to have our application
>> call Squeak, then have Squeak call the application, and then the application
>> call Squeak again recursively.  An analysis of the Squeak VM revealed a
>> kernel design consisting of a lot of global variables - quite unnecessarily.
>> The unnecessary use of global variables over a localized structure for
>> example unnecessarily prevented the use of Squeak as an extension language
>> (unless you had no recursion).  I spent several days trying to re-structure
>> the Squeak kernel but I kept running into problems and just ran out of time.
>>
>> As a side note, that company I was with ended up making a lot of
>> investment in Scheme because we were easily able to integrate that language
>> with our application.  Now, not only is Scheme used heavily within that
>> company but many of their clients use it too to customize their application.
>>
>> This brings me to my question, is COG reentrant?  If not, as the author of
>> COG, I would think it relatively easy to restructure it to be so.  Such a
>> design capability can make a huge difference to COG's acceptance to many.
>> It may even be the reason to switch to COG.
>>
>> Just sharing some thoughts.  Thanks.
>>
>> Blake McBride
>>
>> On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]>
>> wrote:
>>>
>>> ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.
>>>
>>> These fix a bug with pc mapping that could cause the Vm to crash on
>>> simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i|
>>> 1=1]).  They also cause the instantiation primitives to pop all their
>>> arguments rather than assume their argument count is 0 or 1.  More change
>>> info available in the directory.
>>> --
>>> best,
>>> Eliot
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Bob Arning-2

On 12/3/12 11:42 AM, Frank Shearar wrote:
>>   In true reentrancy each recursive call would essentially get their own VM.
>> >
>> >They could, but what's in the VM that they really need a separate copy of?
> It's not the VM, it's the shared state of the image that would cause a
> problem (if anything did). I would think, at least.
If that were the case, then he would need not only his own VM, but his
own image. If these calls from C are expecting a virgin image with the
ability to execute arbitrary smalltalk code and never see anybody else's
data, then a separate image (or at leat super sandbox) would seem a
requirement. OTOH, if he wanted to make use of some BitBlt functions,
e.g., then he could ship a bitmap to Squeak, request some transformation
and receive a new bitmap in return. In this case, one Vm and one image
would seem to do nicely.

Cheers,
Bob

Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
In reply to this post by Bob Arning-2
Responses inline below.

On Mon, Dec 3, 2012 at 10:25 AM, Bob Arning <[hidden email]> wrote:

On 12/3/12 11:01 AM, Blake McBride wrote:
The interaction would be slower, and the installation / integration would be more complex. 
I'd like to understand better what sort of calls you wanted to make from C to Squeak. I was thinking the reason you wanted Squeak included was for some non-trivial processing, so the socket time might not matter much. If you are calling Squeak to convert a character from upper to lowercase, then interaction would be noticeably slower. Could you give an example or two?

Squeak would be used as an extension language to a C based app.  Sometimes the C code would be enumerating through a bunch of records.  If a certain flag was set it would indicate that that client had a custom calculation being performed.  So Squeak would be called for each record read by the C code in order to perform the custom calculations.

In other circumstances, the C app would call Squeak, and Squeak would generate a custom screen (recursively) calling the C app to create the custom screen in a totally native way.  While processing the screen, Squeak may call C to perform a calculation, and that calculation may recursively call Squeak to do a portion of it.

The app is millions of lines long and integrates with its extension language in many, many places.  The calls can occur in a variety of sequences.  Each call must be thought of as totally independent of all the other calls and the recursive layers.

So, the answer to your question is that the calls to Squeak could be very trivial, and very non-trivial.


 

Back then, all we did was install the exe on the server.  Client computer connection merely loaded the latest exe.  No need to startup another app and share a socket, etc..  This would never work in instances where you have 100 users all on different machines.  You'd have one conflict after another.
So, in your ideal world, where did Squeak get installed? Bundled in the C app on each client? As a separate app on each client? Once on a server somewhere?

First I made a typo.  It should be 1000 and not 100 users.

I would want to statically link the Squeak kernel to my app.   Only one instance of the app exists on a shared drive on the server.  Each client loads their own copy of the shared exe.

 


Also, doing it in a client/server motif as you describe means that any global state information made by one call would affect other calls.
Why would there be any global information? If client #27 sent a request to the squeak app, the squeak app could limit its response to data that client would need to know.

You may be correct if I was writing all the extension code but that is not true.  Many other developers would be creating the extensions.  I could never guarantee that no one would create any global state.  I need to be able to let them do whatever they like, and that it all gets erased when they exit the call.  This keep each piece of code isolated from the other.

 

 In true reentrancy each recursive call would essentially get their own VM.
They could, but what's in the VM that they really need a separate copy of?

All the global variables in the C Squeak kernel.
 

Cheers,
Bob


Thanks.

Blake



On Mon, Dec 3, 2012 at 9:39 AM, Bob Arning <[hidden email]> wrote:
Seems like you could do that fairly easily without making the VM re-entrant (whatever that might mean/entail). If you thought of your Squeak app and your C app as two computers on a network, they could send each other requests and responses all day long. No magic required.

Cheers,
Bob


On 12/3/12 10:10 AM, Blake McBride wrote:
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?  If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot















    







Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
In reply to this post by Frank Shearar-3


On Mon, Dec 3, 2012 at 10:42 AM, Frank Shearar <[hidden email]> wrote:
On 3 December 2012 16:25, Bob Arning <[hidden email]> wrote:
>
> On 12/3/12 11:01 AM, Blake McBride wrote:
>
> The interaction would be slower, and the installation / integration would be
> more complex.
>
> I'd like to understand better what sort of calls you wanted to make from C
> to Squeak. I was thinking the reason you wanted Squeak included was for some
> non-trivial processing, so the socket time might not matter much. If you are
> calling Squeak to convert a character from upper to lowercase, then
> interaction would be noticeably slower. Could you give an example or two?
>
> Back then, all we did was install the exe on the server.  Client computer
> connection merely loaded the latest exe.  No need to startup another app and
> share a socket, etc..  This would never work in instances where you have 100
> users all on different machines.  You'd have one conflict after another.
>
> So, in your ideal world, where did Squeak get installed? Bundled in the C
> app on each client? As a separate app on each client? Once on a server
> somewhere?
>
>
> Also, doing it in a client/server motif as you describe means that any
> global state information made by one call would affect other calls.
>
> Why would there be any global information? If client #27 sent a request to
> the squeak app, the squeak app could limit its response to data that client
> would need to know.
>
>  In true reentrancy each recursive call would essentially get their own VM.
>
> They could, but what's in the VM that they really need a separate copy of?

It's not the VM, it's the shared state of the image that would cause a
problem (if anything did). I would think, at least.

The image is fine.  The problem was the global variables used in the kernel.  When creating an instance of the kernel all the C "global" variables in the kernel should be in a structure that gets allocated when you create the instance.  This way, when you call recursively, a new set of VM kernel variables gets allocated and one instance is totally unrelated to the others.

 

frank

> Cheers,
> Bob
>
>
> Thanks.
>
> Blake
>
>
>
> On Mon, Dec 3, 2012 at 9:39 AM, Bob Arning <[hidden email]> wrote:
>>
>> Seems like you could do that fairly easily without making the VM
>> re-entrant (whatever that might mean/entail). If you thought of your Squeak
>> app and your C app as two computers on a network, they could send each other
>> requests and responses all day long. No magic required.
>>
>> Cheers,
>> Bob
>>
>>
>> On 12/3/12 10:10 AM, Blake McBride wrote:
>>
>> Greetings,
>>
>> I tried to integrate Squeak to a C based application more than six years
>> ago.  The project failed because we were not able to have our application
>> call Squeak, then have Squeak call the application, and then the application
>> call Squeak again recursively.  An analysis of the Squeak VM revealed a
>> kernel design consisting of a lot of global variables - quite unnecessarily.
>> The unnecessary use of global variables over a localized structure for
>> example unnecessarily prevented the use of Squeak as an extension language
>> (unless you had no recursion).  I spent several days trying to re-structure
>> the Squeak kernel but I kept running into problems and just ran out of time.
>>
>> As a side note, that company I was with ended up making a lot of
>> investment in Scheme because we were easily able to integrate that language
>> with our application.  Now, not only is Scheme used heavily within that
>> company but many of their clients use it too to customize their application.
>>
>> This brings me to my question, is COG reentrant?  If not, as the author of
>> COG, I would think it relatively easy to restructure it to be so.  Such a
>> design capability can make a huge difference to COG's acceptance to many.
>> It may even be the reason to switch to COG.
>>
>> Just sharing some thoughts.  Thanks.
>>
>> Blake McBride
>>
>> On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]>
>> wrote:
>>>
>>> ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.
>>>
>>> These fix a bug with pc mapping that could cause the Vm to crash on
>>> simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i|
>>> 1=1]).  They also cause the instantiation primitives to pop all their
>>> arguments rather than assume their argument count is 0 or 1.  More change
>>> info available in the directory.
>>> --
>>> best,
>>> Eliot
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
In reply to this post by Bob Arning-2


On Mon, Dec 3, 2012 at 10:55 AM, Bob Arning <[hidden email]> wrote:

On 12/3/12 11:42 AM, Frank Shearar wrote:
  In true reentrancy each recursive call would essentially get their own VM.
>
>They could, but what's in the VM that they really need a separate copy of?
It's not the VM, it's the shared state of the image that would cause a
problem (if anything did). I would think, at least.
If that were the case, then he would need not only his own VM, but his own image. If these calls from C are expecting a virgin image with the ability to execute arbitrary smalltalk code and never see anybody else's data, then a separate image (or at leat super sandbox) would seem a requirement. OTOH, if he wanted to make use of some BitBlt functions, e.g., then he could ship a bitmap to Squeak, request some transformation and receive a new bitmap in return. In this case, one Vm and one image would seem to do nicely.


Yes, separate instance of the image.  It would be self-managed for free of the global variables in the VM kernel were eliminated.  A simple clone already loaded image function could make this work relatively fast.

 

Cheers,
Bob




Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Bob Arning-2

On 12/3/12 12:03 PM, Blake McBride wrote:


On Mon, Dec 3, 2012 at 10:55 AM, Bob Arning <[hidden email]> wrote:

On 12/3/12 11:42 AM, Frank Shearar wrote:
  In true reentrancy each recursive call would essentially get their own VM.
>
>They could, but what's in the VM that they really need a separate copy of?
It's not the VM, it's the shared state of the image that would cause a
problem (if anything did). I would think, at least.
If that were the case, then he would need not only his own VM, but his own image. If these calls from C are expecting a virgin image with the ability to execute arbitrary smalltalk code and never see anybody else's data, then a separate image (or at leat super sandbox) would seem a requirement. OTOH, if he wanted to make use of some BitBlt functions, e.g., then he could ship a bitmap to Squeak, request some transformation and receive a new bitmap in return. In this case, one Vm and one image would seem to do nicely.


Yes, separate instance of the image.  It would be self-managed for free of the global variables in the VM kernel were eliminated.  A simple clone already loaded image function could make this work relatively fast.

So, it sounds like what you need is
- a virgin squeak image for each call
- virgin VM globals pertaining to that image

And what you could, potentially, share is the VM excutable code. Since the VM code is a small part of the footprint, I think your requirements are basically met by a new VM/image for each call. Not sure there is much to be saved getting a new image and keeping the same VM.


Cheers,
Bob
 

Cheers,
Bob





    



Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
In reply to this post by Blake McBride
Actually, here is a better description of the scenario, that would help explain the solution.

Let's say I have a many-iteration-loop that needs to execute some Squeak code.  

1.  I first create a new instance of the Squeak VM with a cloned image.  ONE TIME

2.  I then execute Squeak code to cause it to load some custom code needed for that particular use case.  ONE TIME

3.  I then enter my C loop repeatedly calling the VM instance I just created and initialized.  MANY TIMES

4.  When the loop is over I dispose of the Squeak instance.

There can be many of these scenarios running recursively at the same time.  Each is totally independent.


On Mon, Dec 3, 2012 at 11:03 AM, Blake McBride <[hidden email]> wrote:


On Mon, Dec 3, 2012 at 10:55 AM, Bob Arning <[hidden email]> wrote:

On 12/3/12 11:42 AM, Frank Shearar wrote:
  In true reentrancy each recursive call would essentially get their own VM.
>
>They could, but what's in the VM that they really need a separate copy of?
It's not the VM, it's the shared state of the image that would cause a
problem (if anything did). I would think, at least.
If that were the case, then he would need not only his own VM, but his own image. If these calls from C are expecting a virgin image with the ability to execute arbitrary smalltalk code and never see anybody else's data, then a separate image (or at leat super sandbox) would seem a requirement. OTOH, if he wanted to make use of some BitBlt functions, e.g., then he could ship a bitmap to Squeak, request some transformation and receive a new bitmap in return. In this case, one Vm and one image would seem to do nicely.


Yes, separate instance of the image.  It would be self-managed for free of the global variables in the VM kernel were eliminated.  A simple clone already loaded image function could make this work relatively fast.

 

Cheers,
Bob





Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
In reply to this post by Bob Arning-2
I think you are correct.

On Mon, Dec 3, 2012 at 11:19 AM, Bob Arning <[hidden email]> wrote:

On 12/3/12 12:03 PM, Blake McBride wrote:


On Mon, Dec 3, 2012 at 10:55 AM, Bob Arning <[hidden email]> wrote:

On 12/3/12 11:42 AM, Frank Shearar wrote:
  In true reentrancy each recursive call would essentially get their own VM.
>
>They could, but what's in the VM that they really need a separate copy of?
It's not the VM, it's the shared state of the image that would cause a
problem (if anything did). I would think, at least.
If that were the case, then he would need not only his own VM, but his own image. If these calls from C are expecting a virgin image with the ability to execute arbitrary smalltalk code and never see anybody else's data, then a separate image (or at leat super sandbox) would seem a requirement. OTOH, if he wanted to make use of some BitBlt functions, e.g., then he could ship a bitmap to Squeak, request some transformation and receive a new bitmap in return. In this case, one Vm and one image would seem to do nicely.


Yes, separate instance of the image.  It would be self-managed for free of the global variables in the VM kernel were eliminated.  A simple clone already loaded image function could make this work relatively fast.

So, it sounds like what you need is
- a virgin squeak image for each call
- virgin VM globals pertaining to that image

And what you could, potentially, share is the VM excutable code. Since the VM code is a small part of the footprint, I think your requirements are basically met by a new VM/image for each call. Not sure there is much to be saved getting a new image and keeping the same VM.


Cheers,
Bob
 

Cheers,
Bob





    







Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Eliot Miranda-2
In reply to this post by Blake McBride
Hi Blake,

On Mon, Dec 3, 2012 at 7:10 AM, Blake McBride <[hidden email]> wrote:
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?

Yes it is.  It supports call-outs and call-ins.  But currently there is no support for Cog to be packaged as a DLL.  You have to start by calling C from Squeak.  

 
 If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Yes indeed.   The issue is of course funding to spend the time to make the necessary changes.


Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot











--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Blake McBride
Hello Eliot,

On Mon, Dec 3, 2012 at 1:09 PM, Eliot Miranda <[hidden email]> wrote:
 
Hi Blake,

On Mon, Dec 3, 2012 at 7:10 AM, Blake McBride <[hidden email]> wrote:
Greetings,

I tried to integrate Squeak to a C based application more than six years ago.  The project failed because we were not able to have our application call Squeak, then have Squeak call the application, and then the application call Squeak again recursively.  An analysis of the Squeak VM revealed a kernel design consisting of a lot of global variables - quite unnecessarily.  The unnecessary use of global variables over a localized structure for example unnecessarily prevented the use of Squeak as an extension language (unless you had no recursion).  I spent several days trying to re-structure the Squeak kernel but I kept running into problems and just ran out of time. 

As a side note, that company I was with ended up making a lot of investment in Scheme because we were easily able to integrate that language with our application.  Now, not only is Scheme used heavily within that company but many of their clients use it too to customize their application.

This brings me to my question, is COG reentrant?

Yes it is.  It supports call-outs and call-ins.  But currently there is no support for Cog to be packaged as a DLL.  You have to start by calling C from Squeak.

I believe the regular Squeak supports call-outs and call-ins as well.  The real question is if it can be done recursively.

Can you initialize a new instance of the VM in the middle of a nested call-in / callout?

Can an instance be cloned?  Destroyed?


Thanks.

Blake

 
 

 
 If not, as the author of COG, I would think it relatively easy to restructure it to be so.  Such a design capability can make a huge difference to COG's acceptance to many.  It may even be the reason to switch to COG.

Yes indeed.   The issue is of course funding to spend the time to make the necessary changes.


Just sharing some thoughts.  Thanks.

Blake McBride

On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.

These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]).  They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1.  More change info available in the directory.
--
best,
Eliot











--
best,
Eliot