[squeak-dev] Winds of change

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

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

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

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