Re: Linux port progress

On Dec 17, 10:39 pm, Ian Upright <[email protected]> wrote:
> On Dec 13, 4:07 am, talksmall <[email protected]> wrote:
>
>
>
> > On Dec 13, 9:00 am, Ian Upright <[email protected]> wrote:
>
> > > Hi Guys,
>
> > > I've always liked the idea of having the Smalltalk IDE separated from
> > > the running Smalltalk image process.  I think this is a good idea for
> > > dozens of reasons..  For one, doing serious changes to some
> > > fundamental classes shouldn't take out your IDE if you make a serious
> > > mistake..  Your client image process should crash and burn, and then
> > > you might think that your change wasn't so smart.
>
> > > An IDE can be written in anything -- Squeak, or some other Smalltalk..
> > > and connect to a running Strongtalk image.  It is considerable amount
> > > of work to get a comprehensive UI framework created -- either get
> > > Squeak's lit up, wxWidgets, or what have you.  What isn't a
> > > considerable amount of work is to fire up a socket or some
> > > communication mechanisim to communicate to a running image, and be
> > > able to manipulate it -- from Squeak, or whatever.  This would be the
> > > first step in creating a GUI debugger, traditional code browsers, etc.
>
> > Personally, I think this is a more complex issue than you make out. It
> > is not just a question of the technicalities of implementing a remote
> > debug/control mechanism. It also touches on differences in how people
> > work when developing Smalltalk code within a Smalltalk IDE versus how
> > they work developing C++, Java in IDEs such as Eclipse or
> > VisualStudio. The ability to interact with your running code at
> > fundamental level (such as implementing a missing method during the
> > process of debugging and then restarting the running code from the
> > point of failure) has always been a prized feature of Smalltalk
> > development environments. I'm not convinced that it is the UI element
> > that is the hardest part of getting this type of behaviour working in
> > Strongtalk.
>
> What I'm trying to say is that implementing that type of capability, I
> don't think is as difficult as it might first appear.  The first step
> would be to some type of simple distributed-smalltalk system..  Not
> extremely simple, but probably lots of existing stuff out there to
> leverage off of.  Next would be to build some foundations to make this
> remote and interactive environment play nicely with the whole
> system..  Sure, a little work, but IMO not a ridiculous amount of
> work.
>
> Building extensive GUI frameworks however, such as wrappering
> wxWidgets and whatnot, is a substantial effort.  I was just trying to
> put efforts in comparison.

I am not at all convinced that developing a distributed smalltalk
environment is less work than wrappering an existing GUI framework. In
particular, porting the Squeak BitBlt implementation to Strongtalk
does not mean starting from scratch, and offers the potential to port
Morphic and quite a lot of other Squeak tools with a lot less effort
than a native GUI framework whether wrapped by SWIG or otherwise.

That said, I don't mean to discourage you if you want to put some
effort into implementing distributed support for Strongtalk. I am keen
to encourage anyone who has the time and skills to devote to the
project. Dive in and get you hands dirty!

>
> > I've not seen external debugging environments that handle
> > this anywhere near as cleanly.
>
> Sure, I haven't either.. but IMO it's more a VM issue than it is one
> of an IDE issue..  It's the VM's that make this interactiveness
> difficult, hence Java, etc..  Given a good Smalltalk VM, this type of
> idea shouldn't be all that difficult to achieve.
>
> > If you are volunteering to generate such a remote debugging/control
> > mechanism, more power to you. If it helps us get a UI based
> > development environment up and running quickly then I am sure we would
> > all be interested in it. In addition to the remote control mechanism,
> > you would also need development tools at the other end capable of
> > interacting with a remote image, rather than the environment they are
> > running in. I'm not aware that these tools exist yet.
>
> Sure, and these tools would have to be created.. still, since we can
> build them in Squeak or environments that already have good tools,
> frameworks, debuggers, etc.  it's not as hard of a problem.
>
>
>
> > > Since you don't need (any) gui on linux, and all your GUI is in
> > > Squeak, you're work is then done!  We score points for productivity,
> > > not elegance.. but it's immediately productive, and the ball can roll
> > > much quicker.  This allows the bootstrapping process of getting more
> > > GUI tools (perhaps wxWidgets) and others all happy on linux/windows/
> > > osx/etc..  Without good IDE's and debuggers, the work of creating such
> > > a wxWidgets framework would be ridiculous, especially for a resource-
> > > starved project such as this.  It would be much quicker to do all that
> > > deveopment work on Squeak and then have it ported wholesale to
> > > Strongtalk, and that is probably how it will go.  Improving and fixing
> > > up wxSqueak is one option.  The other is to take some of the SWIG work
> > > I've done (http://commonsmalltalk.wikispaces.com/) and generate a
> > > wxWidgets (or maybe QT) interface using SWIG (even on Squeak), and
> > > perhaps merging that with some of the wxSqueak code, and improving
> > > that on Squeak first.. then once it's working the way we want, we
> > > could just generate the same interface on Strongtalk and for the most
> > > part it should essentially light up.  Or maybe getting the Squeak GUI
> > > would be an easier task.
>
> > In fact we can enhance the image today using the existing command line
> > tools and a simple text editor. If you have access to a Windows
> > environment, there is already a UI that runs under Windows consisting
> > of a number of development tools (though as yet no UI-based debugger,
> > only the command line based evaluator). Since both Windows and Linux
> > share the same image format, code developed under Windows is
> > accessible under Linux and vice versa.
>
> Sure, but then the GUI/IDE/tools would only work on a Win32 system for
> a long while. doable, sure.. but not exciting.  Also, then all the GUI
> work we do on the Win32 Strongtalk environment is presumably a throw-
> away, because likely in the end we will replace it with something else
> and cross-platform.

Actually Artur Lejowski is working on using Eclipse as an IDE, based
on the recent dynamic language support. This would at least offer a
more comfortable environment that bang-delimited source files.

>
> > Development of wxSqueak appears to have stalled some time in 2005,
>
> Taking existing work and morping is sometimes easier than starting
> from scratch..

Maybe, depending on how complete and well documented it is. wxSqueak
seemed quite a bit short of the mark to me.

>
> > there may be licensing issues in using Qt, and wxWidgets appears to
> > depend on C++ inheritance which won't work with the Strongtalk object
> > format.
>
> This I don't understand at all.. what do you mean it won't work with
> the Strongtalk object format?  If we're using SWIG which generates the
> C++ wrapper for us, as well as all the Strongtalk C++ classes/code
> that maps to it, just like wxPython does, what is the problem?
>
> Cheers, Ian

Am I missing something? Looking at the SWIG for Smalltalk link
everything appeared to be Windows centric. Is there SWIG/Smalltalk
support for Linux too? If so, can you provide a link. In any case,
separate Strongtalk bindings would need to be defined for the SWIG
generated so file. If this was fully automated, then I could see an
advantage, but failing that I am not sure why this is much better than
using say GTK+.

Regards, Steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---