(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? -- View this message in context: http://forum.world.st/portable-smalltalk-how-tp4118832p4118832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
does the absence of replies imply that there is no portability layer offering a dialect-independent API to GUI, graphics and network functions yet ? -- View this message in context: http://forum.world.st/portable-smalltalk-how-tp4118832p4123793.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <janko.mivsek@eranova.si>:
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 <janko.mivsek@eranova.si>:
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. -- View this message in context: http://forum.world.st/portable-smalltalk-how-tp4118832p4156504.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 04 Dec 2011, at 11:11, t olschewski wrote:
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.
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
On Tue, Nov 29, 2011 at 12:38 PM, t olschewski <t-o@gmx.org> wrote:
(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?
I think even if using grease/sport they do not cover things like command line argument, UI/graphics, etc. Maybe (I have no idea) a little bit about networking and encoding is supported by grease/sport, but I doubt it. Cheers
-- View this message in context: http://forum.world.st/portable-smalltalk-how-tp4118832p4118832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- 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. -- View this message in context: http://forum.world.st/portable-smalltalk-how-tp4118832p4129355.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (7)
-
Davorin Rusevljan -
Igor Stasenko -
Janko Mivšek -
Lukas Renggli -
Mariano Martinez Peck -
Sven Van Caekenberghe -
t olschewski