We were thinking about using Hydra for a recent project for this reason. Our
FFI calls were doing network I/O that made it impossible to maintain an
acceptable frame rate in Croquet.

Unfortunately I didn't find the time to dig into this but our image size was
already a problem and I assumed that this approach would make that problem
worse. Maybe a Pharo image could exist on one thread to do network I/O and a
regular Croquet thread could run on another thread?

I recall that Hydra was released early because it was unexpectedly
successful, but I haven't heard much about it since then.

Steve

On Fri, Feb 6, 2009 at 12:59 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
> On Fri, Feb 6, 2009 at 11:32 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>> 2009/2/6 Eliot Miranda <eliot.miranda at gmail.com>:
>> >
>> >
>> > On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko <siguctua at gmail.com>
>> 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.
>> >
>> > I either solved these issues or found they were non-issues in the
>> context of
>> > VisualWorks in 1997/98 and made it function as a Web browser plugin.  I
>> used
>> > my threaded FFI that allows different threads to call-in and out of the
>> VM,
>> > so that the Smalltalk image was fully active all the time even when the
>> > browser was not calling into it.  The VM was loadable as a DLL and was
>> > supplied with an image file (which can be embedded as data, e.g. in a
>> > Windows exe's resources) in an init call which returns once the image as
>> > loaded.  The entry-points in the DLL can then be called from code that
>> has
>> > loaded the DLL.  Inside these entry-points are rendezvous-style
>> call-backs
>> > that the single-threaded Vm responds to.
>> > I think (ok, know) the issue is not the image but the lack of a threaded
>> > FFI.
>> > For reference, the external doc to my thrteaded interconnect is at
>> >
>> http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VisualWorks+THAPI
>> > I have internal doc somewhere which belongs to Cincom so if anyone is
>> > interested I'll ask Cincom for permission to publish it and if they say
>> yes
>> > then I'll make it available, e.g. on my web site.
>>
>> i know there is a squeak browser plugin for a while. But its not
>> really a solution.
>> Its mainly a patches everywhere in VM to allow it to interoperate with
>> browser, but nothing more. There is no any API which can be used to
>> speak with VM from any host application.
>> Of course, a host application may disguise itself as a plugin and use
>> a plugin interpreter proxy protocol.
>> So, it can be seen as an embedded VM, with only exception, that scheme
>> is reverse: VM plays role as a master, and your application - slave,
>> and VM telling you what to do by calling primitives.
>> The most significant part of functionality is lacking: there is no
>> support of a message send from host application to VM. Making it
>> available would make writing a host applications much easier.
>
>
> I understand.  My message said that I have solved the problem of allowing
> "a message send from host application to VM" in the VisualWorks VM using a
> threaded FFI.  This solution is also applicable to Squeak.
>
> So if you want to solve this in the current Squeak a low-cost way is to
> write a threaded FFI, i.e. extend the current FFI to support threads.
>
>>
>>
>> >>
>> >> 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >>
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090206/a65e146d/attachment.htm