Andreas,
Some random thoughts:
The standard (and not altogether unreasonable) answer to "no support for x on y" is "Want FFI on Solaris? Write it." You are correct in pointing out the deficiencies; "they" are correct in pointing out that "we" could help more. Sadly, I suspect many would help more if help were more aggressively accepted.
I accept some blame for failing to make it easier to write certain apps. I really should put an MVP wrapper around some of the morphic chaos. Various things have distracted me, including learning more about Linux - Squeak is of dubious value to me if I stay on Windows, hence the diversion. Ubuntu installs quite easily, though an upgrade to 7.10 fried my VPN (getting to be a pain) and added/revealed some largely cosmetic bugs. I also want to get craftier with shell scripts. I am starting to think fondly of "reinstall, run custom script, return to find re-configured machine." Come to think of it, I want the same thing for Squeak, getting the latest version of various things (Gary's work being high on the list) w/o having to click and wait my way through a GUI. No lack of gratitude implied; the GUIs are great, but sometimes a script is the better way to go.
I also looked at ST/X, and found pretty much what you did. It has strong supporters, but early experiments left me concerned that it would fail a lot too easily for my taste and needs.
Re Squeak's GUI speed, have you tried some older versions? IIRC, Squeak took a real speed hit somewhere around 3.8 or 3.9???? That's not to say "downgrade or suck it up," but I _am_ curious if older versions are faster. One nice thing about slow platforms is that slow code crawls all the more on them.
To add a concern to your list, what about incompatibilities with other dialects? To continue my rant about streams,
'hello' at:200
raises an error, but 'hello' readStream next:200 truncates. Hmmmm. Dolphin and VW get this one right. Nile includes some beginning efforts to rewrite some methods to use its streams, but to really fix it (I think) requires a breaking change. I am tempted to turn the RB loose to turn #next into #nextOrNil and #next into #nextAvailable: (there might be others I have yet to recognize), and then begin work in the new image after adding some methods and/or switching to Nile. Add confusion over that to my list of reasons/excuses for delay in MVP ;) Humor aside, it *is* a concern to me.
So, what are we going to do to fix all of this stuff?
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
A.Wacknitz@gmx.de 01/30/08 4:20 PM >>>
The following is from a different subject but I find it more appropriate
for the "Promote Squeak/Smalltalk" thread:
Bill Schwab schrieb:
Lukas,
Gary provided the authoritative answer, to which I will add that a
stray
method to set the various preferences might be helpful. We will all have our own variants, but it is getting hard to tell which options
are
not truly independent. FWIW, it is a great problem to have.
As far as keyboard focus being off topic: it is **ON TOPIC**. I wish you guys could have heard Aileen type. Failing that, watch a clerk
who
has learned how to work without a mouse (and hates having to stop to touch it) pound on a keyboard. We should be able to meet their expectations.
Meeting expectations is a good catchword. And to make a long story short: Squeak is often advertised as being "multi platform" and having a decent
class library. In my experience the reality is different: Windows is supported best, followed by Mac and Linux x86. Every other platform has more or less problems: - On Solaris (x86 and SPARC): FFI is not supported and thus no depending
packages like ODBC (so no generic database connectivity). - Are there any actual VMs and images for ARM, MIPS or something similar? - What about Linux on non-Intel?
Another, often discussed problem area for Squeak is its not standard conforming GUI. It may be that Morphic is in many areas superior to most other GUI frameworks. Nevertheless it is very difficult and annoying to create GUIs for standard business applications (eg. the aforementioned bank account SW).
Code quality and documentation is another major concern. There is a lot of brilliant code in the Squeak base. But there is also a lot of mess in it. And you can be sure that most experienced programmers will find many more occurrences of mess than brilliant code. At least the mess is more likely to be remembered. Furthermore it is quite easy to find problems and annoyances in the tools of a standard image. (BTW I have similar experiences with ST/X. It takes only a few minutes to find MNUs in the standard tools.)
Did I mention that Squeak is sometimes painfully slow on my Sun Blade 2000 (equipped with two US-III+ processors and 8GB RAM)? This has two causes: gcc produces slow code for SPARC (and Sun C and its tool chain is not quite supported) and Morphic (or at
least most of Squeak's GUI) is painfully slow.
Regards Andreas
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Bill Schwab schrieb:
Andreas,
Some random thoughts:
The standard (and not altogether unreasonable) answer to "no support for x on y" is "Want FFI on Solaris? Write it." You are correct in pointing
I know this, alas this is not so easy as it sounds. FFI uses libffi. And libffi is now a part of gcc. It seems as if I had to tame that beast and some other dependencies first.
out the deficiencies; "they" are correct in pointing out that "we" could help more. Sadly, I suspect many would help more if help were more aggressively accepted.
I accept some blame for failing to make it easier to write certain apps. I really should put an MVP wrapper around some of the morphic chaos. Various things have distracted me, including learning more about Linux - Squeak is of dubious value to me if I stay on Windows, hence the
I once was a big Linux fan. That changed when I realized that there is no such thing like "Linux the operating system". There is "Linux the kernel" that is used by different companies and organizations to build their own Linux based operating systems. But they are free to add/patch/remove things to the Linux kernel and combine this with any kind or version of X11, KDE, GNOME, ... and so on. This is a support nightmare for a software creator. Sooner or later one recognizes a new kind of dependency hell. This was the major motivation for me to choose Solaris. Alas with Solaris you have to fight the Linuxisms and GNUisms because everybody expects the C compiler to be gcc and most other GNU tools in the tool chain.
diversion. Ubuntu installs quite easily, though an upgrade to 7.10 fried my VPN (getting to be a pain) and added/revealed some largely cosmetic bugs. I also want to get craftier with shell scripts. I am starting to think fondly of "reinstall, run custom script, return to find re-configured machine." Come to think of it, I want the same thing for Squeak, getting the latest version of various things (Gary's work being high on the list) w/o having to click and wait my way through a GUI. No lack of gratitude implied; the GUIs are great, but sometimes a script is the better way to go.
I also looked at ST/X, and found pretty much what you did. It has strong supporters, but early experiments left me concerned that it would fail a lot too easily for my taste and needs.
Re Squeak's GUI speed, have you tried some older versions? IIRC, Squeak took a real speed hit somewhere around 3.8 or 3.9???? That's not to say "downgrade or suck it up," but I _am_ curious if older versions are faster. One nice thing about slow platforms is that slow code crawls all the more on them.
Of course I have. And in fact the older versions feel more responsive. But older versions lack some things that were introduced in 3.9 and 3.10. And older versions look more terrible than 3.9 or 3.10 for me. Furthermore I have the feeling that you have to follow bugs.squeak.org for bug reports and fixes and have to patch your image on your own as most of the fixes are only incorporated in the version that is actually being worked on.
To add a concern to your list, what about incompatibilities with other dialects? To continue my rant about streams,
'hello' at:200
raises an error, but 'hello' readStream next:200 truncates. Hmmmm. Dolphin and VW get this one right. Nile includes some beginning efforts to rewrite some methods to use its streams, but to really fix it (I think) requires a breaking change. I am tempted to turn the RB loose to turn #next into #nextOrNil and #next into #nextAvailable: (there might be others I have yet to recognize), and then begin work in the new image after adding some methods and/or switching to Nile. Add confusion over that to my list of reasons/excuses for delay in MVP ;) Humor aside, it *is* a concern to me.
So, what are we going to do to fix all of this stuff?
Yes, this is a big concern for Smalltalkers using different Smalltalk dialects. You can add non-standard GUI frameworks, sockets and nearly all things not defined by the ANSI standard to this list. But this is usually not a problem during the first experiments of newcomers.
Regards Andreas