[squeak-dev] Winds of change

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.

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 <[hidden email]>:

> 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 <[hidden email]> 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.

2009/2/6 Eliot Miranda <[hidden email]>:

>
>
> On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko <[hidden email]> 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.

>>
>> 2009/2/6 Steve Wart <[hidden email]>:
>> > 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 <[hidden email]> 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.

On Fri, Feb 6, 2009 at 11:32 AM, Igor Stasenko <[hidden email]> wrote:

2009/2/6 Eliot Miranda <[hidden email]>:

>
>
> On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko <[hidden email]> 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 <[hidden email]>:
>> > 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 <[hidden email]> 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.

2009/2/6 Steve Wart <[hidden email]>:

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

Yes Hydra FFI is multithreaded already.

But all thread safety problems which may arise when you using foreign
modules are on your hands, of course.


--

Best regards,
Igor Stasenko AKA sig.

2009/2/7 Eliot Miranda <[hidden email]>:

>
>
> On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> 2009/2/6 Steve Wart <[hidden email]>:
>> > 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.
>> >
>>
>> Yes Hydra FFI is multithreaded already.
>
> Does it support callbacks from threads?  Does it support callbacks from
> threads other than threads that have called-out?   (I call these callbacks
> foreign callbacks because they come from threads the Vm doesn't know exist
> until they callback)

there is no extra functionality (callbacks) in addition to what
original FFI plugin provides.
I'm only made sure that plugin's own state which used during
conversion of values is thread safe.

A callback support , added by Andreas, is not related to FFI. It can
be used by plugins , and the only plugin i saw which using it was a
python bridge.

As for 'foreign' callbacks.. heh..
I would rather name it an async event/hook. :)

To my understanding a 'callback' term, its pattern which invented by
C-ers for passing a closure deeper into a stack i.e. callback function
should be called from within a function which takes it as argument and
never after it returns :

[1] sort(array, mySortFn);

[2]-> fnptr(x,y)
[callback] ... in mySortFn
[2]<-  return from mySortFn

[1]<- return from sort()

where [1] is caller context, and [2] is function which using callback argument.

If it not behaves like this, then its not a callback anymore - call it
a hook, event or something else :)

>>
>> But all thread safety problems which may arise when you using foreign
>> modules are on your hands, of course.
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>

--

Best regards,
Igor Stasenko AKA sig.

Giuseppe Luigi Punzi <glpunzi <at> lordzealon.com> writes:
> We have elections soon.
>
> I'ts time to think about the project. What we search? What new
> developers search?

For me, the biggest problem with Sqeuak at the moment is its lack of class and
method comments (but not every method needs an overview comment).  I would like
to say to all developers of the uncommented system classes: "Will you please go
back and comment, all the methods and classes you wrote, but failed to
document!"  And I know I'm not the only one who feels this way.  Hold back on
new features for just a minute, and give what we already have a quick polish.
I've wasted many hours trying to puzzle out how to use complex yet undocumented
methods (some weren't even documented on the Squeak Swiki).  The basic
collection classes, and the core system classes are well commented.

 -Aidan

P.S No hard feelings, just some frustration.  Sqeuak is a great development
system, and seems to keep getting better.