On Mon, Dec 3, 2012 at 10:42 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> 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.
>

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 <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/e19854fa/attachment.htm