I'm trying to learn enough Squeak to allow it to be used as an external 
plugin to Second Life. At this point, all it does [will do] is 
send/receive packets via IPC from an existing "gridproxy" app that can 
selectively intercept/inject standard SL packets on their way to/from 
the SL server.

This should allow for some interesting prototyping for SL. A more 
powerful implementation  might [someday] use an interface to the 
internal events of the second life client.  Which leads me to the 
question: what kind of events should be defined to allow a reasonably 
robust interaction of an external app and Squeak?

It would be trivial enough to send "make new window" to the event 
handler, assuming that such an event existed and to receive simple mouse 
movement/updates for Squeak-side processing (e.g. in an offscreen 
drawing buffer), but what about more complex and sophisticated 
interactions required for implementing things like a Squeak class 
browser in the GUI of the main application? What events would be needed 
to handle that level of interaction?

It seems to me that it might be easier to go with the standalone 
implementation of Squeak talking to the main app via high level events 
defined for these things, than try to rewrite the Squeak VM to work as 
an embedded VM that needs to directly call the host app's API.



What kind of events would be useful in this scenario? Any thoughts, 
suggestions, references to already implemented examples, etc?

Thanks,

Lawson


Igor Stasenko wrote:
> The main reason, which prevents squeak to use as embedded solution is
> a structure of VM.
> - there are many points when it assuming that it runs standalone
> - the main interpret() function is an endless loop and not reentrant,
> which makes it hard to interoperate with host process , like Lua does.
> recent updates added a callbacks, so they can be used as a kind of
> workaround to solve that issue.
>
> 2009/2/6 Steve Wart <steve.wart at gmail.com>:
>   
>> That's an interesting idea. Quite a lot of the momentum in Python, Lua,
>> ECMAScript, etc. come from their embedded-ness.
>>
>> Smalltalk was built embedded in an OS that it was never entirely comfortable
>> with, although there have been many attempts at scripting Smalltalk from
>> other programs, Seaside being the most notable success.
>>
>> I suggest that this ideal already exists. The benefits come from specific
>> implementations.
>>
>> It would be interesting to see a Croquet variant with a modern game engine.
>> Smalltalk and C++ should be able to play well together.
>>
>> Steve
>>
>> On Fri, Feb 6, 2009 at 8:53 AM, askoh <askoh at askoh.com> wrote:
>>     
>>> I think it is good you dare to speak your mind. I also think that the
>>> Squeak
>>> community can take that. Keep your ideas coming.
>>>
>>> I would like Squeak to be callable from other programs so that it can be
>>> used as plugins.
>>>
>>> Aik-Siong Koh
>>>
>>>
>>>
>>> Giuseppe Luigi Punzi Ruiz wrote:
>>>       
>>>> We have elections soon.
>>>>
>>>> I'ts time to think about the project. What we search? What new
>>>> developers search?
>>>>
>>>> I think, probably, Squeak, needs a refactoring on the ideas behind. The
>>>> people thath wants etoys, use etoys image. Croquet uses his own image.
>>>> Now, at the moment (2009), I'm 90% sure, the people thath go to
>>>> squeak.org, and get the latest Squeak, now, are developers searching a
>>>> good smalltalk (something similar to VW but opensource I means) to use
>>>> in their projects, not the use of Squeak as multimedia, or something
>>>> similar. I know this for all spanish people ask me about Squeak, or
>>>> developers "going out the list" searching Pharo, an approach to the
>>>> things I say.
>>>>
>>>> I like the idea about a console squeak (like GST) with the objects
>>>> living in memory, but not dependent of the "World", launching the actual
>>>> Squeak World as an object (I don't know if is the actual behaviour, I
>>>> only dream) if you want, or launching something like VW (or Dolphin)
>>>> working over TK or GTK or WxWidgets or technologys like XUL
>>>> instead.....I like the idea of an UI Painter....I like the idea of all
>>>> Squeak tools running over web too..well, this idea don't like it very
>>>> much :)..but I don't have the skills for all of this, for this I offer
>>>> the ideas. But most important, is the community has vote for this
>>>> things. The community needs to stay informed about the movements. I
>>>> think, this, is the right direction.
>>>>
>>>> I don't know what you all think, but IMHO, it's the moment to get a new
>>>> Squeak 4 from zero, trying to preserve the core classes, with new ideas
>>>> and ambitions.
>>>>
>>>> I don't like very much the idea about all list hating me, but, after
>>>> this mail, I know you hate me :P
>>>>
>>>> P.D.: Yes, probably, I'm crazy too.
>>>>
>>>>
>>>>
>>>>         
>>> --
>>> View this message in context:
>>> http://www.nabble.com/-squeak-dev--Winds-of-change-tp21872826p21876368.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>
>>>
>>>       
>>
>>
>>
>>     
>
>
>
>