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.
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.
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@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.
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@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@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.
On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko siguctua@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.
2009/2/6 Steve Wart steve.wart@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@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.
2009/2/6 Eliot Miranda eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko siguctua@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.
2009/2/6 Steve Wart steve.wart@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@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.
On Fri, Feb 6, 2009 at 11:32 AM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/6 Eliot Miranda eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko siguctua@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@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@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.
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@gmail.comwrote:
On Fri, Feb 6, 2009 at 11:32 AM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/6 Eliot Miranda eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 10:13 AM, Igor Stasenko siguctua@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@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@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.
2009/2/6 Steve Wart steve.wart@gmail.com:
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.
On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/6 Steve Wart steve.wart@gmail.com:
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)
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 eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/6 Steve Wart steve.wart@gmail.com:
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.
On Fri, Feb 6, 2009 at 5:26 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/7 Eliot Miranda eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko siguctua@gmail.com
wrote:
2009/2/6 Steve Wart steve.wart@gmail.com:
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.
OK, so the FFI does *not* support threads. It is merely thread-safe so that multiple hydra instances can be making FFI call-outs at the same time.
That is an entirely different thing to an FFI that is multithreaded. I think you should claim only that the Hydra FFI is thread-safe, not that it is multi-threaded. It isn't. The common understanding of a multi-threaded FFI is one that allows one to call-out and call-ack on multiple threads.
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. :)
It is *not* an event hook. It is a means of invoking behaviour in the system being called. Call-back is the common term for this.
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 :)
I disagree. I think event hooks are far more specific tan call-backs.
Anyway...
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.
Best Eliot
2009/2/7 Eliot Miranda eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 5:26 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/7 Eliot Miranda eliot.miranda@gmail.com:
On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/2/6 Steve Wart steve.wart@gmail.com:
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.
OK, so the FFI does *not* support threads. It is merely thread-safe so that multiple hydra instances can be making FFI call-outs at the same time. That is an entirely different thing to an FFI that is multithreaded. I think you should claim only that the Hydra FFI is thread-safe, not that it is multi-threaded. It isn't. The common understanding of a multi-threaded FFI is one that allows one to call-out and call-ack on multiple threads.
I known there's Alien flying around, which supports FFI callbacks. And we have two choices: adopt Alien, or add callbacks to current FFI implementation :)
A God has gathered all living creatures in same place and said: - beatiful ones, stand to left side - intelligent ones, stand to right side. All animals choosed own side quickly, and only ape keeps standing in a centre. - Why you not moving, didn't you heard what i just said? - asks God. - Its hard to choose, because i'm both beatiful and intelligent.
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. :)
It is *not* an event hook. It is a means of invoking behaviour in the system being called. Call-back is the common term for this.
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 :)
I disagree. I think event hooks are far more specific tan call-backs. Anyway...
Okay then, a i understood, by callback, you mean passing a function pointer anywhere you like to, and expect it to be called from any thread at any moment since then. Its a most generic way, which covers all use cases, except those when developer is complete idiot :)
2009/2/7 Igor Stasenko siguctua@gmail.com:
2009/2/7 Eliot Miranda eliot.miranda@gmail.com:
I known there's Alien flying around, which supports FFI callbacks. And we have two choices: adopt Alien, or add callbacks to current FFI implementation :)
A God has gathered all living creatures in same place and said:
- beatiful ones, stand to left side
- intelligent ones, stand to right side.
All animals choosed own side quickly, and only ape keeps standing in a centre.
- Why you not moving, didn't you heard what i just said? - asks God.
- Its hard to choose, because i'm both beatiful and intelligent.
ouch my bad...
A God has gathered all living creatures in same place and said:
- who wants to be beatiful , stand to left side - who wants to be intelligent, stand to right side.
All animals choosed own side quickly, and only ape keeps standing in a centre.
- Why you not moving, didn't you heard what i just said? - asks God.
- Its hard to choose, because i want to be beatiful and intelligent both.
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@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@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.
Lawson English wrote:
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,
Mark Fulmer just gave me one of those Homer Simpson DOH!!! moments:
The Second LIfe interface already has a webbrowser that you can open inside Second LIfe. Serve a localhost webpage from Squeak and provide some user interface goodness in it, and you have a more or less full GUI interface to Squeak from within Second Life.
The same pattern would work with any application that can handle localhost webpages. No need to define some complicated user interface with Squeak. All you need is the webpage and some way of passing raw commands/data to/from your target app.
Lawson
Lawson English wrote:
Mark Fulmer just gave me one of those Homer Simpson DOH!!! moments:
The Second LIfe interface already has a webbrowser that you can open inside Second LIfe. Serve a localhost webpage from Squeak and provide some user interface goodness in it, and you have a more or less full GUI interface to Squeak from within Second Life.
The same pattern would work with any application that can handle localhost webpages. No need to define some complicated user interface with Squeak. All you need is the webpage and some way of passing raw commands/data to/from your target app.
Matthew Fulmer (Doh!)....
Lawson
On Thu, Aug 06, 2009 at 11:00:12PM -0700, Lawson English wrote:
Lawson English wrote:
Mark Fulmer just gave me one of those Homer Simpson DOH!!! moments:
The Second LIfe interface already has a webbrowser that you can open inside Second LIfe. Serve a localhost webpage from Squeak and provide some user interface goodness in it, and you have a more or less full GUI interface to Squeak from within Second Life.
The same pattern would work with any application that can handle localhost webpages. No need to define some complicated user interface with Squeak. All you need is the webpage and some way of passing raw commands/data to/from your target app.
Matthew Fulmer (Doh!)....
Haha. I always get called Mark when someone can't remember my name
Matthew Fulmer wrote:
On Thu, Aug 06, 2009 at 11:00:12PM -0700, Lawson English wrote:
Lawson English wrote:
Mark Fulmer just gave me one of those Homer Simpson DOH!!! moments:
The Second LIfe interface already has a webbrowser that you can open inside Second LIfe. Serve a localhost webpage from Squeak and provide some user interface goodness in it, and you have a more or less full GUI interface to Squeak from within Second Life.
The same pattern would work with any application that can handle localhost webpages. No need to define some complicated user interface with Squeak. All you need is the webpage and some way of passing raw commands/data to/from your target app.
Matthew Fulmer (Doh!)....
Haha. I always get called Mark when someone can't remember my name
A Homer Simpson moment leading to a senior moment. <sigh>
Anyway, so after finding my javascript book and playing around with sample scripts online, it seems trivial to implement a simplified Smalltalk browser interface on a webpage. Of course, if someone already has a sample of this (javascript only--needs to run inside SL for immersion effect), feel free to point it out.
Lawson
On Friday, Lawson English wrote (about Second Life):
Anyway, so after finding my javascript book and playing around with sample scripts online, it seems trivial to implement a simplified Smalltalk browser interface on a webpage. Of course, if someone already has a sample of this (javascript only--needs to run inside SL for immersion effect), feel free to point it out.
If I understand your needs, Seaside already has what you want:
* http://www.seaside.st/about/screenshots (click on Code Browser)
* http://www.seaside.st/documentation/tutorials/A+Walk+on+the+Seaside#17279537...
(On the PierCMS, the icon to open the Class Browser is not a wrench but a notepad.)
On Fri, Aug 07, 2009 at 08:16:41AM -0700, Lawson English wrote:
Matthew Fulmer wrote:
On Thu, Aug 06, 2009 at 11:00:12PM -0700, Lawson English wrote:
Lawson English wrote:
Mark Fulmer just gave me one of those Homer Simpson DOH!!! moments:
The Second LIfe interface already has a webbrowser that you can open inside Second LIfe. Serve a localhost webpage from Squeak and provide some user interface goodness in it, and you have a more or less full GUI interface to Squeak from within Second Life.
The same pattern would work with any application that can handle localhost webpages. No need to define some complicated user interface with Squeak. All you need is the webpage and some way of passing raw commands/data to/from your target app.
Matthew Fulmer (Doh!)....
Haha. I always get called Mark when someone can't remember my name
A Homer Simpson moment leading to a senior moment. <sigh>
Anyway, so after finding my javascript book and playing around with sample scripts online, it seems trivial to implement a simplified Smalltalk browser interface on a webpage. Of course, if someone already has a sample of this (javascript only--needs to run inside SL for immersion effect), feel free to point it out.
Lively Kernel uses javascript and svg to recreate Morphic in a web browser, entirely client side:
http://research.sun.com/projects/lively/
Would it be possible to call Squeak using interprocess calls or sockets and still get reasonable behavior like calling a DLL? Aik-Siong Koh
askoh 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 <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.
Aidan Gauland schrieb:
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.
I would say: all public classes and methods that are not obvious (intention revealing) shall be documented. And there should be an introduction or overview on package level.
Sigh, I am a dreamer...
Regards Andreas
On Sat, Feb 7, 2009 at 6:22 PM, Aidan Gauland wgsilkie@ihug.co.nz wrote:
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.
What would be extremely useful (to me at least) is to provide example usage for some of the more cryptic and difficult classes. The person writing them has the best understanding and probably had to test things out anyway. So why not just publish that code in the class comment? For example...
I've been struggling for 2 days trying to get a TCP client socket dialog with a telnet server. In VisualWorks, I would do something like:
wire := ( SocketAccessor newTCPclientToHost: 'telnetHostname' port: 23 ) readAppendStream.
I can then use:
wire throughAll
and
wire nextPutAll:
among other stream methods, to handle the communication.
I do notice the SocketStream has a HTTP example, but I don't think SocketStream is for TCP (I could be wrong, but there is no documentation either way).
I haven't figured it out yet in Squeak. I thought I could do something like this:
wire := SocketStream openConnectionToHostNamed: 'telnetHostname' port: 23.
and then use
wire upToAll:
and
wire nextPutAll:
but this just 'hangs' and I have to alt+. to abandon the process.
Is this even possible in Squeak? Or do I have to load something else into the image?
Sockets are very hard to debug and I don't want to have to use the Socket class. That is way too low level for me. The purpose of Smalltalk is to make things easy, no? ;-)
Daniel Klein
"You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein.
Daniel Klein wrote:
I do notice the SocketStream has a HTTP example, but I don't think SocketStream is for TCP (I could be wrong, but there is no documentation either way).
You are wrong. SocketStream is for TCP.
I haven't figured it out yet in Squeak. I thought I could do something like this:
wire := SocketStream openConnectionToHostNamed: 'telnetHostname' port: 23.
and then use
wire upToAll:
and
wire nextPutAll:
but this just 'hangs' and I have to alt+. to abandon the process.
No, it works just fine. For example:
stream := SocketStream openConnectionToHostNamed: 'www.squeak.org' port: 80. stream nextPutAll: 'GET / HTTP/1.0', String crlf, String crlf. stream flush. header := stream upToAll: String crlf, String crlf. content := stream upToEnd.
Cheers, - Andreas
Daniel Klein wrote:
I've been struggling for 2 days trying to get a TCP client socket dialog with a telnet server. In VisualWorks, I would do something like:
[SNIP]
SocketStream is what you want, as you noticed too.
I do notice the SocketStream has a HTTP example, but I don't think SocketStream is for TCP (I could be wrong, but there is no documentation either way).
It is definitely for TCP. I think the class comment says so.
[SNIP]
Is this even possible in Squeak? Or do I have to load something else into the image?
No, just use SocketStream, easy. I wrote the current SocketStream code so just ask. And also, it is heavily used in KomHttpServer etc so this is code that works.
regards, Göran
Aidan Gauland escreveu:
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.
+1
I would also suggest some things:
* Definition of a set that can be considered as foundation classes. * Within this set, standardization of docs and also external documentation. * Within this set, standardization of style. * Within this set, compatibility between all the classes (meaning, no hang-ups during install, no hang-ups during execution due to cross effects, etc). * When a new class is considered suitable to be included inside the "foundation classes" set, it must comply with above requirements. * A police for deprecation that avoids conflicts with new classes.
I agree: Squeak is a great development system that is getting better all the time. Besides have a finest community supporting it.
Best regards,
CdAB
squeak-dev@lists.squeakfoundation.org
-
Aidan Gauland -
Andreas Raab -
Andreas Wacknitz -
askoh -
Casimiro de Almeida Barreto -
Daniel Klein -
David Corking -
Eliot Miranda -
Giuseppe Luigi Punzi -
Göran Krampe -
Igor Stasenko -
Lawson English -
Matthew Fulmer -
Steve Wart