Re: Linux port progress

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. I've not seen external debugging environments that handle
this anywhere near as cleanly.

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.

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

Development of wxSqueak appears to have stalled some time in 2005,
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. Perhaps porting BitBlt over from Squeak would be simpler or
maybe we should code to XWindows.

>
> In any case, you need a UI to bootstrap it all with..  and using an
> existing cross-platform UI that is already built is the shortest
> path.  It's also not throw-away work because eventually much of it
> could be easily ported to Strongtalk when it evolves to have those
> foundations.  The communication layer required is also not throw-away
> work because the idea of having the IDE separated from your running
> image is a good one.

Obviously, there is a significant amount of work to do to get the
existing Strongtalk UI development tools running under Linux. No one
is suggesting that it will be quick or easy.

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