GNU vs. Squeak vs. VW

Hello,

I am a long-time Smalltalk addict with a lot of Dolphin-based code.  I
would be completely happy were it not for what I see as a disturbing
trend of bloat, bugs, and licensing hassles from Microsoft.  Every OS
revision brings a round of "what did they break this time?"  I hate to
think what Vista would be like.

Dolphin on Wine is one possible solution, though I worry about how Wine
decides which bugs to emulate, the quality of their reverse engineering,
etc.

Visual Works' runtime fees scare me.  Imagine the conversation with my
department's accountant: "...What's it cost?  Well, they want to know
what it's worth to us."  His office is on the fourth floor - that's a
long fall :)

Squeak is probably my leading contender, though it needs some serious
work before I could use it.  In its favor, it appears to be rock solid.
I have yet to uncover an old Squeak image that would not load.  I have
managed to crash it doing 3D graphics, but even that is rare.

What's wrong with Squeak?  The underscore madness is annoying.  I
connect to various externally-designed databases that use them in table
and field names (the latter making good choices for selectors), they
appear in structure names, and even some external function names.
Aesthetics aside, I "need" to be able to to use them (avoiding them
would cause a fair amount of extra work).

Squeak's GUI feel is horrible.  The look I can live with and/or fix, but
feel is a bit more trouble to correct on my own.  I do _not_ need native
widgets; I can live with them, and will even use them when provided, up
to a point.  I ended up having to make an emulated widget framework for
some situations, and would port it to any system that "forces" native
widgets on me.

Squeak's streams bother me.  IMHO

    'hello' readStream next:20

should raise an error; #nextAvailable: offers a way to "safely" get
truncated results.  I care because I do a lot of sometimes very strict
parsing, and want to know ASAP when something is not as expected.

Other items such as database connectivity, SSL sockets, etc. are either
available or are evolving.  My reading about GNU suggests you have at
least strong starts in many useful areas.

Re GNU, licensing is of some concern.  I have seen some
softening/clarification of the terms to favor proprietary software.
There are things I am willing to give away, but I would be crazy to open
everything, so I need a system that will accommodate internal production
use as well as commercial deployment.  For now, let's assume things are
ok, though comments are welcome.

Your headless core is great.  I am concerned that you seem to focus on
it largely to the exclusion of a GUI.  I am not a believer in eXtreme
Programming[*], but I _am_ a believer and practitioner of several of its
components.  Automated testing and programming in the debugger are big
on my list.  A graphical debugger is the center of my world.  Sadly, I
am probably not enough of a VM guru to begin to write one.

Are you at all interested in stretching GNU Smalltalk to compete with VW
as a platform for building GUI software?  Putting that question to the
Squeak community yields answers such as "don't break our toy, " which
IMHO is a shame.  I am looking for a tool that can build toys, robust
server software, bleeding edge interfaces, and even some plain old
boring stuff to meet users' expectations.  If those objectives appeal to
you, please let me know; I would fully expect to contribute to making it
happen.  The caveat would be that I need to be able to maintain
ownership of and even sell things that are unique to my work while
helping to improve the open system.

Happy Smalltalking!

Bill


[*] no offense, I see it as sloppy configuration management, and aging
comments (3, 6, 12 months "ago") have saved my back side several times.
XP bad; refactoring good; automated testing VERY good.




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Squeak is probably my leading contender, though it needs some serious
> work before I could use it.  In its favor, it appears to be rock solid.
> I have yet to uncover an old Squeak image that would not load.  I have
> managed to crash it doing 3D graphics, but even that is rare.

Agreed.

> Squeak's GUI feel is horrible.

Agreed :-)

> Other items such as database connectivity, SSL sockets, etc. are either
> available or are evolving.  My reading about GNU suggests you have at
> least strong starts in many useful areas.

I'll put things straight: DB connectivity is limited to MySQL but Glorp
is there (ported to MySQL).  It may suffer a little bitrot but nothing
paramount and it is on my to-do list to fix it.

SSL sockets are not there though I think that GnuTLS bindings are not
hard to do.  Seaside may come at next Camp Smalltalk, though I won't
swear anything until I see it.

> Re GNU, licensing is of some concern.  I have seen some
> softening/clarification of the terms to favor proprietary software.

Yes, that's mostly related to not worry writers of proprietary software
that use bindings to external libraries.

> Are you at all interested in stretching GNU Smalltalk to compete with VW
> as a platform for building GUI software?  Putting that question to the
> Squeak community yields answers such as "don't break our toy, "

My answer is: this is free software developed by volunteers.  I had
better concentrate *my* free-time energies to produce something
concrete, and that turns out to be a headless tool.  But if somebody
wants to *add* something more, I'm all good with that and (lo and
behold) RMS happens to desire that more than having a great headless
Smalltalk!

My only sort of "request" would be to have a mechanism to aid
re-exporting as files the stuff developed in graphical environments.
Right now the browser is mostly used as a "browser", but if people start
using it more I'd say it would become more important.

Anyway, let's not make it a "vs." as I believe that everything has its
own unique place in the world.

> The caveat would be that I need to be able to maintain
> ownership of and even sell things that are unique to my work while
> helping to improve the open system.

Please clarify, though I am pretty positive that there is nothing to
worry about.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Bill Schwab wrote:
> I am a long-time Smalltalk addict with a lot of Dolphin-based code.  I
> would be completely happy were it not for what I see as a disturbing
> trend of bloat, bugs, and licensing hassles from Microsoft.  Every OS
> revision brings a round of "what did they break this time?"  I hate to
> think what Vista would be like.
>
> Dolphin on Wine is one possible solution, though I worry about how Wine
> decides which bugs to emulate, the quality of their reverse engineering,
> etc.

I assume that you are looking for a way to move to GNU/Linux or another
Free UN*X-y OS.

> Squeak's streams bother me.  IMHO
>
>     'hello' readStream next:20
>
> should raise an error; #nextAvailable: offers a way to "safely" get
> truncated results.  I care because I do a lot of sometimes very strict
> parsing, and want to know ASAP when something is not as expected.

Would be hard to change without reopening a Smalltalk standardization
process.

> Re GNU, licensing is of some concern.  I have seen some
> softening/clarification of the terms to favor proprietary software.
> There are things I am willing to give away, but I would be crazy to open
> everything, so I need a system that will accommodate internal production
> use as well as commercial deployment.  For now, let's assume things are
> ok, though comments are welcome.

Probably; see Section 1.5 "Licensing of GNU Smalltalk" in the current
manual.  It's not so much "favoring" proprietary software as allowing
for the possibility of its existence.

Paolo Bonzini wrote:
 > But if somebody
 > wants to *add* something more, I'm all good with that and (lo and
 > behold) RMS happens to desire that more than having a great headless
 > Smalltalk!

Wha-what's going on here?

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
But you know how reluctant paranormal phenomena are to reveal
themselves when skeptics are present. --Robert Sheaffer, SkI 9/2003


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Bill--

I feel the same sort of frustrations with using Smalltalk to develop
free (or commercial) software. All the Smalltalks have various issues --
just different ones. It is very frustrating.

Squeak has licensing issues and is not modular, but it is very
cross-platform and has a big community. GST is modular and well
licensed, but can be difficult to install and has a small community and
the GUI is incomplete and not very complete or cross-platform (things
continue to improve off course). VisualWorks is modular and very
cross-platform but it isn't free-as-in-freedom (or even
free-to-distribute-commercial as in buy it once). VW also lost ENVY
which I liked. OTI had a great embedded Smalltalk but it is very
proprietary. Dolphin is windows only and not free-as-in-freedom.
Smalltalk/X has a sort-of-free license but not quite IIRC, and no
history as a free software community. The Java Smalltalks are orphaned
for the most part and incomplete (but cross-platform and mostly free,
except for the Squeak-derived ones which suffer from the Squeak
licensing issues).

Because of their communities, it seems to me that GST and Squeak are the
major players if you want a free platform going forward.

You can see my comments on Squeak when I was active on the Squeak-dev
list, say here:
  "Belling the cat of complexity (was: Ship it with Squeak)"
http://liststest.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html
That was one reason I experimented with creating "Embedded Squeak"
  http://www.kurtz-fernhout.com/squeak/readme.txt
(which was a headless Squeak, like GNU Smalltalk in some ways) though
that code is so old don't use it. :-)
You can see an example of my frustration with the Squeak licensing here:
http://osdir.com/ml/lang.smalltalk.squeak.foundation/2003-04/msg00046.html
http://osdir.com/ml/lang.smalltalk.squeak.foundation/2003-04/msg00045.html
Even though they are (many years) trying to fix it now, I still question
if they are getting a proper copyright assignment from *Disney* which
has a copyright statement in the code. But I can hope.

Beyond the licensing issue, here are other related links on Squeak
issues from around 2000:
http://liststest.squeakfoundation.org/pipermail/squeak-dev/2000-June/013722.html
http://liststest.squeakfoundation.org/pipermail/squeak-dev/2000-June/021045.html
http://liststest.squeakfoundation.org/pipermail/squeak-dev/2000-June/022013.html

>From that middle link:
"I'm sorry if I keep coming across as a broken record in most of my
posts to the list over the past few years. A major thrust of what I say
is always the same (perhaps becoming clearer over time as other people
refine it).
To become a serious platform, Squeak needs:
* to be modular (namespaces, buildable image, maybe inter-VM/"object
space" debugging),
* to have at least one stable, easy to use, lockable, scalable GUI,
* to be event driven, and
* to interface easily with the outside world of code.
"

I wanted to fix the Squeak issues and was willing to put time into them
(way back when) but the community just wasn't focused on fixing the
deeper issues of modularity or licensing -- in general the responses on
that topic were very discouraging -- and without fixing the license, the
changes might be worthless, and without fixing modularity, they would
likely or not just have been lost. In some ways I think Squeak killed
Smalltalk more than Java:
  "Bambi Meets Godzilla: I watched Smalltalk die."
  http://www.oreillynet.com/ruby/blog/2006/01/bambi_meets_godzilla.html
because Squeak was exciting and had the big names attached to it, but it
also had this fundamental licensing problem which prevented any real
progress or diversification as either "open source" or "free" software.
I think if the licensing issues finally get cleaned up, we may see some
real progress there. Alan Kay himself says he wants to be a
Smalltalk/Squeak slayer and get something better -- but the Squeak
community doesn't seem to understand or accept this; when ever I
proposed doing things in that direction, it never went down well.
http://lists.squeakfoundation.org/pipermail/squeakfoundation/2002-January/000357.html

Which leaves only GST as a Smalltalk with a truly free license and
somewhat of a community. I'm not sure how much of installability would
be fixed by just having a bigger community for more testing -- I suspect
it would somewhat (though the build process still seems overly
convoluted). The other specific issues can be fixed, as Paolo says, and
he seems willing to integrate back in the changes.

I've wandered around the idea of rolling my own Smalltalk on Java,
perhaps drawing from GST. But that was not straightforward because GST
has (forgive me) some excessive internal complexity in how it defines
itself which it was not easy to see how to map onto Java. I still think
it is a good idea to have a Smalltalk that runs well on Java though --
ideally one that, like Python, runs on Java and runs on C.

One possibility I have wondered about is the possibility of a
Squeak-like GUI core for GST as an alternative to TK, where essentially
you have one or more framebuffers (as windows) with event loops (GUI
events) and draw emulated widgets. Then, as with Squeak, the only
cross-platform stuff needed is a thin layer of a few hundred lines of C
code to interface with bitmap windows on various OS's -- and that part
could likely be borrowed from Squeak under some licensing arrangement,
or at the very least, one can look at Squeak to see how the base
interface to the OS is done (all that stuff except for the original old
Mac GUI primitives in Squeak was contributed so direct relicensing is
possible too). That's probably a few person-weeks of work at least to
get one platform up like, say, GNU/Linux -- most of it making the basic
widgets -- the actual platform specific code is probably only a day or
two. I think that could be a big win for GST, to bring in some of the
Squeak ideas onto its more solid base.

But I always get distracted then by wanting prototypes (like in Self)...
Although I am perhaps moving past that phase:
  http://patapata.sourceforge.net/critique.html

In practice, in the past I've ended up using Python for lots of various
reasons (licensing, libraries, easy syntax to sell to C++ or Java shops,
Jython-Java integration, etc.). It also has always been free, which I
think has direct implications in the type of community around it, see
for example my comments on that here:
  "Python & Smalltalk (was Re: OLPC related: pyGTK)"
  http://mail.python.org/pipermail/edu-sig/2006-December/007476.html
But I still miss the Smalltalk syntax which I think is still the best
ever developed for the kind of way I generally want to write software.
And the Python community simply does not get the value of "edit and
continue" like coding in the debugger or why Python should be altered to
do that, see for example:
  "More OLPC chatter (PataPata; Edit&Continue)"
  http://mail.python.org/pipermail/edu-sig/2007-July/007993.html
That lack of "Edit and continue" brings down my productivity in Python
compared to a good Smalltalk by a factor of three I guess. If there is
one community and version of Smalltalk that has the potential to be more
like Python, I would think it is probably GST more than any other one IMHO.

When/if I ever get some spare cycles again though, I'm hoping to revisit
the Smalltalk issue. If I could rewind time, I think it might have been
better to have invested the time and emotion I put into Squeak and
Python and Jython into improving GST (but drawing on ideas from Squeak
and Python and Jython on Self). But I can't, so I'm stuck with things
the way they are for now. :-)

--Paul Fernhout







_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paul D. Fernhout <[hidden email]> wrote:

> Bill--
>
> I feel the same sort of frustrations with using Smalltalk to develop
> free (or commercial) software. All the Smalltalks have various issues --
> just different ones. It is very frustrating.

I have enjoyed reading Paul's and Bill's comments and thought I might
jump in and ask how the regular GNU Smalltalk users go about using GNU
Smalltalk.

Both mentioned their desire for a GUI and for for the debugger.

I certainly agree, in general.  I feel the need especially for a
debugger (and browser and inspector) but I wonder if the GST regulars
are already doing the equivalent in some way?  Perhaps by using Emacs?

I often use Emacs with several programming languages but especially with
Common Lisp.  I don't even use the fancy Emacs SLIME interface to Lisp,
just the default interface that comes with Emacs.  (Position the cursor
at the end of a form and press C-x C-e to execute the form, sending the
results to the Lisp buffer that is open, etc.)

Could the regular users of GST describe how they go about developing and
debugging in GST?


--
Frank


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, 2007-07-14 at 09:17 -0400, Paul D. Fernhout wrote:
> I've wandered around the idea of rolling my own Smalltalk on Java,
> perhaps drawing from GST. But that was not straightforward because GST
> has (forgive me) some excessive internal complexity in how it defines
> itself which it was not easy to see how to map onto Java. I still think
> it is a good idea to have a Smalltalk that runs well on Java though --
> ideally one that, like Python, runs on Java and runs on C.

Feel free to join us in #gnu-smalltalk on irc.freenode.net, where
regular Sukoshi is looking into doing just this to support a commercial
project, using Per Bothner's gnu.bytecode Java package to compile
Smalltalk classes to Java classes that can work somehow with Java code.

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech column
     "Portals" on page B1 of The Wall Street Journal

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paul D. Fernhout a écrit :
Squeak licencing isssues will soon be old story. Squeak 1.1 was
relicensed by Apple under the Apache License 2.0 last year and all the
developers have been asked to relicensed their work under MIT, so we
have a complete free system.

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111467.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111438.html

The work for the modularisation is also underway : for example there is
a now a Squeak image for developers called squeak-dev
(http://damien.cassou.free.fr/squeak-dev/) with the last developers
goodies and you can add and remove packages with the Universe Browser.


-- Serge Stinckwich
http://doesnotunderstand.free.fr/



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Serge Stinckwich wrote:
> Squeak licencing isssues will soon be old story. Squeak 1.1 was
> relicensed by Apple under the Apache License 2.0 last year and all the
> developers have been asked to relicensed their work under MIT, so we
> have a complete free system.
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111467.html
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111438.html

[By the way, the embedded link to the contributors list at the second
link doe not work anymore.]

I can hope you are right, and I admire the vast amount of work going
into the license change, and it feels great that the Squeak community
has finally made it a priority, but "Disney" is apparently not on the
list of contributors needing to sign a waiver last I looked (a few
months ago). Disney has a blanket copyright statement in the image (or
had). The Squeak community is essentially left with a few comments that
could be interpreted as that somehow those previous contributions by
SqueakC members were OK to rerelease under a new license because of
general aspects of Disney's contract with SqueakC members, but if that
was true, then why was the Disney copyright statement in there in the
first place? Disney has almost singlehandedly driven copyright extension
-- they are for that reason one company from which not to take anything
for granted on copyright.

One thing the FSF sometimes gets scorn about is for its very strict
attitude towards copyright assignment or usage permission for any
contribution to GNU free software, but I think this Squeak situation
shows the benefit of the FSF procedures. That's why GNU Smalltalk will
likely always be in a better licensing position as a system to extend or
draw from.

> The work for the modularisation is also underway : for example there is
> a now a Squeak image for developers called squeak-dev
> (http://damien.cassou.free.fr/squeak-dev/) with the last developers
> goodies and you can add and remove packages with the Universe Browser.

Again, I can hope you are right, and it does seem like good progress is
being made on that issue (finally).

Remember, I wrote that comment many years ago and only after years of
frustration by myself and several others with getting the community or
SqueakC to consider these issues of modularity and "free" licensing to
be of importance.

--Paul Fernhout


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

I second this question!

I'm also curious how (or if) people connect to an already-running gnu
smalltalk instance remotely.

Mark.

--
Mark Aufflick
  contact info at http://mark.aufflick.com/about/contact


On 7/15/07, Frank Sergeant <[hidden email]> wrote:

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, 2007-07-14 at 12:57 -0500, Frank Sergeant wrote: See section 4.3 "Smalltalk interactor mode" in (gst.info)Interactor::.
It provides a similar experience to the run-lisp interface you describe.
I do not describe all its features; please see that node.

After running M-x gst, I mostly rely on C-c f, which files in a file,
defaulting to the current.  I occasionally use C-c c, which sends the
current method, when trying to fix test failures.

I have never had a need for a debugger outside of C and C++, even when
one was available.  So I cannot help you with this.

I have only one wishlist item here, that M-. could take a symbol and pop
up an interactive buffer of methods, using the FileSegments stored as
source code when filing in to provide file jumps.  This would no longer
work with STInST, and given that I mostly code in local areas now, I'm
not sure that I would even use it anymore.  I did use it sometimes with
SLIME, though.

Incidentally, I also run gst with some ulimits set to avoid runaway
allocation, as with the 'HashedCollection empty' issue fixed a while ago
as well as potential problems in my own code:

ulimit -d 175000
ulimit -m 175000
ulimit -v 250000

Change as appropriate for your free memory.

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech column
     "Portals" on page B1 of The Wall Street Journal

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Sergeant wrote:
[...]
> Could the regular users of GST describe how they go about developing and
> debugging in GST?

Back when I used to do Smalltalk development I did it in traditional Unix
style: vi (or possibly nedit in those days) and discrete program runs.
Debugging happens with print.

I'll admit that I've never been terribly happy with the Smalltalk browser
big-pile-'o-code system of development. IMO, you lose all the meta information
about how your code is organised, i.e. what file it's in and where in the file
it is; it means that you can't put disparate code chunks next to each other.
Of course, there are other categorisation systems such as, er, categories, but
they never seem as useful to me.

What's more, I generally distrust the business of developing code in an image.
Without periodic resets and recompiles from scratch, you run the risk of
ending up with unreproducible state in the image; for example, if your app
built a data structure with code that you then removed, the image will still
work but any rebuild will fail.

(It's interesting to note that the professionals tend to serialize their
images to CVS periodically --- typically daily --- and start each session with
a fresh image. Which means that they are, to a certain extent, following
traditional compile-run-debug methodology...)

Of course, I come from a traditional Unix background, and tend to prefer the
methodologies and programming styles that I'm used to. Enough enterprise-level
Smalltalk code has been written using different methodologies that I'm sure it
all works very well for people who are used to that. But that's not what you
asked...

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───────────────────
│
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnqALf9E0noFvlzgRAhEVAKDbeEr3hKTe714rWWmrq2Z3HHOy/QCcDKE4
we8ao3lKj1hk3LuVOZvZ/tQ=
=3Qhj
-----END PGP SIGNATURE-----



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paul D. Fernhout a écrit :

The link is : http://www.netjam.org/squeak/contributors/

Check the authors list if you had some code inside the Squeak image.


-- Serge Stinckwich
http://doesnotunderstand.free.fr/



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

David Given a écrit :

No one use an image for a too long time. Generally Smalltalkers use code
repository like Monticello (Squeak) or Store (VW).

-- Serge Stinckwich
http://doesnotunderstand.free.fr/



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> See section 4.3 "Smalltalk interactor mode" in (gst.info)Interactor::.
> It provides a similar experience to the run-lisp interface you describe.
> I do not describe all its features; please see that node.
>
> After running M-x gst, I mostly rely on C-c f, which files in a file,
> defaulting to the current.  I occasionally use C-c c, which sends the
> current method, when trying to fix test failures.

The same, together with prints.

There's also a crude gdb-like debugger, but it's not that much of a
performance boost.

Needless to say, unit tests are fundamental if debugging is a little
harder.  Up to a while ago I was lazy and used a "test" method which had
to print only "true"s, but now I saw the light and many more GST
packages come with SUnit testsuites (more on that next week).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, 2007-07-20 at 09:20 +0300, Paolo Bonzini wrote:
> Needless to say, unit tests are fundamental if debugging is a little
> harder.  Up to a while ago I was lazy and used a "test" method which had
> to print only "true"s, but now I saw the light and many more GST
> packages come with SUnit testsuites (more on that next week).

In my reckoning, debugging is hardly a replacement for unit tests, where
unit tests can partially substitute for debugging, so I just write unit
tests anyway.  See Test-Presource.st in
http://nocandysw.com/starchive/NoCandyPresource.star for an example;
packages/stinst/parser/RewriteTests.st was originally written just to
guarantee behavior I rely on in Presource, because rewriting is such a
useful way to write message macros.

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech column
     "Portals" on page B1 of The Wall Street Journal

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Stephen Compall wrote:
> On Fri, 2007-07-20 at 09:20 +0300, Paolo Bonzini wrote:
>> Needless to say, unit tests are fundamental if debugging is a little
>> harder.  Up to a while ago I was lazy and used a "test" method which had
>> to print only "true"s, but now I saw the light and many more GST
>> packages come with SUnit testsuites (more on that next week).
>
> In my reckoning, debugging is hardly a replacement for unit tests, where
> unit tests can partially substitute for debugging

Agreed.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> The same, together with prints.
>
> There's also a crude gdb-like debugger, but it's not that much of a
> performance boost.
>
> Needless to say, unit tests are fundamental if debugging is a little
> harder.  Up to a while ago I was lazy and used a "test" method which had
> to print only "true"s, but now I saw the light and many more GST
> packages come with SUnit testsuites (more on that next week).

I will add that my experience is a little different than the usual
because I work 99% of the time in the GNU Smalltalk build tree rather
than with an installed copy.  Actually I'm interested in whether other
people do the same.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

David Given <[hidden email]> wrote:

> > debugging in GST?

> Back when I used to do Smalltalk development I did it in traditional Unix
> style: vi (or possibly nedit in those days) and discrete program runs.
> Debugging happens with print.

Thank you, David and Stephen and Paolo, for your comments on how you use
gst, and to Bill for (more or less) bringing up the subject.


--
Frank


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk