On 3 December 2012 16:25, 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?
>
> 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 <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
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>