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 <arning315 at comcast.net 
> <mailto: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 <mailto:eliot.miranda at gmail.com>> wrote:
>>
>>         ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628
>>         <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/5f19071f/attachment.htm