portable smalltalk, how ?

(read "portable" as "running with no changes on as many smalltalk platforms as possible")

I know that a certain level of portability is achieved by the ansi standard.

But what if:

... the program I am going to write has GUI, graphics and network access,
... may either take command line arguments or not,
... must handle cr-lf-crlf or even UTF  

- and I still want it to be as portable (in the above sense) as possible.

seaside, grease, or sport - or something different? Or something yet to be written?

does the absence of replies imply that there is no portability layer offering a dialect-independent API to GUI, graphics and network functions yet ?

--
Mariano
http://marianopeck.wordpress.com

hm. To me this sounds like writing dialect- and platform-independent
applications were close to impossible unless I either limit myself to ansi or
encapsulate & wrap any non-ansi function I use - ?

It also sounds to me like along with each of my non-ansi smalltalk programs
I'd have to save the image and the VM version used in development if I haven't
time or motivation to port my programs from one image version to the next or
from one platform to another.

On 30 Nov 2011, at 17:58, t olschewski wrote:

> does the absence of replies imply that there is no portability layer offering
> a dialect-independent API to GUI, graphics and network functions yet ?

(Most people are on the pharo-dev list and read pharo-users only casually I guess).

Writing true portable Smalltalk code is plain hard: not just of language differences but more because of library differences.

This is not that different from the C world I guess.

There is only one big portable Smalltalk program that I know of: Seaside.

Sven

For UI portability the only way to go is to have a clean separation
between model and view. OmniBrowser, Glamour, ToolBuilder, Magritte,
Pier, ... are examples of models that are independent of their view.

Sport provides platform independence for files, sockets and
exceptions. When we evaluated Sport for Seaside it only worked on VW
and sockets were at the wrong abstraction level. Also to consider is
that exceptions are pretty portable today.

Grease is merely a collection of utilities to deal with strings,
collections, encoding, message sends, versions and packages. It also
includes a large collection of ANSI tests documenting what Seaside
expects from the platform.

For networking it depends on what you want to do. If you want sockets,
then Sport is probably the way to go. If you want to serve HTTP then
Seaside-Core is what I would pick: This does not include WAComponent
and WASession, it provides platform independent request/response
objects. Through adaptors it runs identically on all platforms that
support Seaside and with many different web servers (for Pharo this is
Zinc, Kom, KomLight, Swazoo, FastCGI, and probably others).

As you see, all these examples work because they separate code that
works on one platform and with one output format from the rest of the
code. You can do this in any domain, but it is the easiest if you
build on something that already works.

An exception is PetitParser: It works on many platform without changes
because it expects only a tiny subset of ANSI, the rests it simply
implements itself or packages separately.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

S, Lukas Renggli piše:

> Sport provides platform independence for files, sockets and
> exceptions. When we evaluated Sport for Seaside it only worked on VW
> and sockets were at the wrong abstraction level. Also to consider is
> that exceptions are pretty portable today.

Sockets on wrong abstraction level? Which abstraction level is then a
right one? Only questionable thing is that Sport API is influenced
strongly on VisualWorks. But this is hard characterize simply as wrong.

In any case, Sport is so far most successful attempt to make portable
Times, Files, and Sockets. Specially last two are very different from
dialects and Sport enables easy portability of projects like Swazoo web
server and Aida web framework. When Sport is ported to some dialect, all
other projects based on Sport became portable there almost instantly.

Another reason is also that both Swazoo and Aida are written with
portability in mind by avoiding  non-portable dialect features and
libraries and therefore don't need Grease for that, just Sport.
Remaining dialect dependencies are marked simply by method comment, like
"VW specific". End result is very simple code, yet maintainable and
portable.

Sport is supported on GNU Smalltalk, VA Smalltalk, Squeak/Pharo,
VisualWorks/ObjectStudio, Dolphin Smalltalk.

News from this year ESUG Edinburg: Sport will become MIT licensed, now
is namely GPL.

I therefore invite specially network/web guys to write more portable
code using Sport and therefore spread your work around all Smalltalks.

Best regards
Janko



--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

2011/12/2 Janko Mivšek <[hidden email]>:
> I therefore invite specially network/web guys to write more portable
> code using Sport and therefore spread your work around all Smalltalks.

Janko, I have not looked it in more depth for quite some time, but
where is the best place to look to learn the API that Sport provides?
(especially for someone who does not have in depth knowledge and
access to VW api)?

Thanks!

Davorin Rusevljan
http://www.cloud208.com/

My 2 cents.

It depends, what sense you put into portability.
SqueakNOS can run on any intel-based architecture. But you don't have
OS and need to implement all low-level stuff by yourself.
No matter what software, I think you can claim that it is portable
only to certain degree.

To my opinion, it is better to have software which runs perfectly on
some concrete platform, rather than have buggy/incomplete  and with
limited feature set (because of minimum common denominator) software
which runs everywhere.
Apple's success with IOS platform is a good showcase for that.

An opposite example is web "platform". Despite the great progress in
last decade, it is still far behind from desktop-based software in
terms of responsiveness, speed and resource usage.


--
Best regards,
Igor Stasenko.

S, Davorin Rusevljan piše:
> 2011/12/2 Janko Mivšek <[hidden email]>:

>> I therefore invite specially network/web guys to write more portable
>> code using Sport and therefore spread your work around all Smalltalks.

> Janko, I have not looked it in more depth for quite some time, but
> where is the best place to look to learn the API that Sport provides?
> (especially for someone who does not have in depth knowledge and
> access to VW api)?

Thanks to über cool browsing feature of forthcoming SmalltalkHub you can
look at Sport here:

        http://smalltalkhub.com/user/janko/Sport/commits/Sport-2.031

Best regards
Janko


--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Sven Van Caekenberghe wrote

This is not that different from the C world I guess.

I think the C world is slightly different in one important respect. In the C
world layers are rather cleanly separated from one another: C (or C++)
compiler, standard library, framework + application specific libraries.

In the C (or C++) world it is possible to - more or less freely - combine
compiler A with IDE B, using framework C and external libraries D.  After
compiling the executable does not depend e.g. on the IDE anymore.

In smalltalk, if I decide to use dialect A then I feel more or less bound to
using library A, IDE A and GUI framework A. The program still depends on the
image type I was using in development (or even on the VM) unless I limit
myself to a well-defined kernel like ansi which doesn't provide portable
graphics + network APIs.

My tool developed in squeak 4.1/pharo 1.1 in this spring does not run in
squeak 4.2/pharo 1.3 without modifications.

On 04 Dec 2011, at 11:11, t olschewski wrote:

Yes, Smalltalk is an integrated system.

But look at C's autoconfig, all the #ifdefs and so on; try porting from *nix to Windows or vice versa: it never will just work, and it will require a lot of work, and you will be limited to certain APIs that you depend on.

Granted, the C world has more experience with this and there are much more options, but the problem remains the same.

I can't imagine the amount of work required to write/port a modern hit game of PS3, Xbox 360, Wii, PC, PSP and DS for example.

> My tool developed in squeak 4.1/pharo 1.1 in this spring does not run in
> squeak 4.2/pharo 1.3 without modifications.

It all depends on what you were using, the porting itself should not be that difficult, unless it is completely depedent on something that has gone.

Sven