[squeak-dev] New Cog VMs available

Blake McBride blake at mcbride.name
Mon Dec 3 16:57:57 UTC 2012


Responses inline below.

On Mon, Dec 3, 2012 at 10:25 AM, Bob Arning <arning315 at comcast.net> 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 <arning315 at comcast.net> 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 <eliot.miranda at gmail.com>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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121203/97771a0b/attachment.htm


More information about the Squeak-dev mailing list