<br><br><div class="gmail_quote">On Mon, Dec 3, 2012 at 10:42 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 3 December 2012 16:25, Bob Arning <<a href="mailto:arning315@comcast.net">arning315@comcast.net</a>> wrote:<br>
><br>
> On 12/3/12 11:01 AM, Blake McBride wrote:<br>
><br>
> The interaction would be slower, and the installation / integration would be<br>
> more complex.<br>
><br>
> I'd like to understand better what sort of calls you wanted to make from C<br>
> to Squeak. I was thinking the reason you wanted Squeak included was for some<br>
> non-trivial processing, so the socket time might not matter much. If you are<br>
> calling Squeak to convert a character from upper to lowercase, then<br>
> interaction would be noticeably slower. Could you give an example or two?<br>
><br>
> Back then, all we did was install the exe on the server. Client computer<br>
> connection merely loaded the latest exe. No need to startup another app and<br>
> share a socket, etc.. This would never work in instances where you have 100<br>
> users all on different machines. You'd have one conflict after another.<br>
><br>
> So, in your ideal world, where did Squeak get installed? Bundled in the C<br>
> app on each client? As a separate app on each client? Once on a server<br>
> somewhere?<br>
><br>
><br>
> Also, doing it in a client/server motif as you describe means that any<br>
> global state information made by one call would affect other calls.<br>
><br>
> Why would there be any global information? If client #27 sent a request to<br>
> the squeak app, the squeak app could limit its response to data that client<br>
> would need to know.<br>
><br>
> In true reentrancy each recursive call would essentially get their own VM.<br>
><br>
> They could, but what's in the VM that they really need a separate copy of?<br>
<br>
</div>It's not the VM, it's the shared state of the image that would cause a<br>
problem (if anything did). I would think, at least.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Cheers,<br>
> Bob<br>
><br>
><br>
> Thanks.<br>
><br>
> Blake<br>
><br>
><br>
><br>
> On Mon, Dec 3, 2012 at 9:39 AM, Bob Arning <<a href="mailto:arning315@comcast.net">arning315@comcast.net</a>> wrote:<br>
>><br>
>> Seems like you could do that fairly easily without making the VM<br>
>> re-entrant (whatever that might mean/entail). If you thought of your Squeak<br>
>> app and your C app as two computers on a network, they could send each other<br>
>> requests and responses all day long. No magic required.<br>
>><br>
>> Cheers,<br>
>> Bob<br>
>><br>
>><br>
>> On 12/3/12 10:10 AM, Blake McBride wrote:<br>
>><br>
>> Greetings,<br>
>><br>
>> I tried to integrate Squeak to a C based application more than six years<br>
>> ago. The project failed because we were not able to have our application<br>
>> call Squeak, then have Squeak call the application, and then the application<br>
>> call Squeak again recursively. An analysis of the Squeak VM revealed a<br>
>> kernel design consisting of a lot of global variables - quite unnecessarily.<br>
>> The unnecessary use of global variables over a localized structure for<br>
>> example unnecessarily prevented the use of Squeak as an extension language<br>
>> (unless you had no recursion). I spent several days trying to re-structure<br>
>> the Squeak kernel but I kept running into problems and just ran out of time.<br>
>><br>
>> As a side note, that company I was with ended up making a lot of<br>
>> investment in Scheme because we were easily able to integrate that language<br>
>> with our application. Now, not only is Scheme used heavily within that<br>
>> company but many of their clients use it too to customize their application.<br>
>><br>
>> This brings me to my question, is COG reentrant? If not, as the author of<br>
>> COG, I would think it relatively easy to restructure it to be so. Such a<br>
>> design capability can make a huge difference to COG's acceptance to many.<br>
>> It may even be the reason to switch to COG.<br>
>><br>
>> Just sharing some thoughts. Thanks.<br>
>><br>
>> Blake McBride<br>
>><br>
>> On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> ...in <a href="http://www.mirandabanda.org/files/Cog/VM/VM.r2628" target="_blank">http://www.mirandabanda.org/files/Cog/VM/VM.r2628</a>.<br>
>>><br>
>>> These fix a bug with pc mapping that could cause the Vm to crash on<br>
>>> simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i|<br>
>>> 1=1]). They also cause the instantiation primitives to pop all their<br>
>>> arguments rather than assume their argument count is 0 or 1. More change<br>
>>> info available in the directory.<br>
>>> --<br>
>>> best,<br>
>>> Eliot<br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>