Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Application deployment in Squeak

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Kevin-231

[squeak-dev] Application deployment in Squeak

Message

Okay, so my project of the moment is to package a simple game app developed and running
in Squeak into a lightweight and easily-distributable runtime. This isn't really a
request for help or anything, and might be off topic for the list, (let me know if so)
but might be of interest to some. More important to me :-) I might get some feedback
that sends me in a better direction. So, if I sound like I need to know something,
feel free to hit me with it. (Also, btw, none of this should be seen as criticism; I'm

kind of falling in love with Squeak system, and my point here is to try to find ways

to spend more of my time doing more of it)

Options:

- Stripped Squeak image: I've picked up hints of various attempts at this (Dependency-
walker type things, and scripts that disable developer tools). Seems that this is a
hard problem though, between type-inferencing where variables can take on arbitrary types,
and reflection, and dynamic evaluation, and so on. So, for now at least this is kind
of a cumbersome and unwieldy way to deal with app deployment.

I need to look into the VM generation stuff. There's the whole thing about the Slang
subset and C code generation of Smalltalk code, so there's already-existing knowlege and
code to build on.

Seems like it would be a good fit to go a level higher, and translate a bigger subset of
Smalltalk into a higher-level language like C#, or maybe Java or C++. You'd be able to
automatically translate a lot more of your Smalltalk codebase, and for the parts where
you can't or don't want to (say to avoid bringing along the whole Morphic thing) you'd
have a much better fit for plugging in a replacement library.

RBParser/RBFormatter

So how much of Smalltalk libraries/image could be auto-dumped into C# classdefs? I'm
looking at the RBParser/RBFormatter stuff now, and liking it -- nice little Visitor
pattern for walking the parse nodes, and really a pretty small set of implementation
methods to do the code generation. At a quick look it doesn't look hard to make a
C# code generator out of it.

UI libraries

Anything currently running in squeak is probably going to be doing UI the squeak way
-- which seems to mean one of several different, apparently kind of monstrous, packages,
the which I haven't even begun to get a good handle on. All that Morphic (for example)
stuff might be kind of cool, and might be necessary in a seriously cross-platform
environment like Squeak, --but what about something like what Newspeak apparently did?

I've only skimmed this so far, but apparently they'd got running to some extent at least
a UI system that uses native widgets for speed and simplicity. Their Hopscotch browser
shows dynamic switching between Morphic and their native-style UI.

So here's what I'd like to do. I think I heard that Newspeak got open-sourced due to
lack of funding. So, I'm thinking that if I bring the Newspeak UI stuff into Squeak,
and use it as the UI layer to develop in Squeak, I get the benefits of the rapid-
prototyping/RAD Smalltalk style, using all the tools available therein. And I get the
ability (maybe) to take the resulting Squeak application code, run an auto-translator
on it to generate for example C# or Java versions of the application-specific classes,
and link that code against a (so far non-existing) library that mimics the Newspeak UI
classes.

Anybody got thoughts on all this, or 'already been solved' kinds of comments?
--A little bit of experimenting around in VW and in Dolphin Smalltalks shows that
they at least have some kind of auto-deployment, at least for Windows. Am I missing
the Squeak version of that, or am I right in thinking it's something that needs to
be done?

Kevin Kelley

kelleysoft.com

Hans-Martin Mosner

Re: [squeak-dev] Application deployment in Squeak

Kevin schrieb:

>
> Options:
>
> - Stripped Squeak image: I've picked up hints of various attempts at
> this (Dependency-
> walker type things, and scripts that disable developer tools). Seems
> that this is a
> hard problem though, between type-inferencing where variables can take
> on arbitrary types,
> and reflection, and dynamic evaluation, and so on. So, for now at
> least this is kind
> of a cumbersome and unwieldy way to deal with app deployment.

If you skip the fancy type-inference stuff and just throw out the
compiler and development tools, you might get a pretty OK result without
much hassle. Of course there would be room for space improvement, but in
today's desktop environments this is mostly a non-issue.
>
>
>
> I need to look into the VM generation stuff. There's the whole thing
> about the Slang
> subset and C code generation of Smalltalk code, so there's
> already-existing knowlege and
> code to build on.
Forget it. The VM generation stuff is very limited and not designed for
this kind of code.

>
> Seems like it would be a good fit to go a level higher, and translate
> a bigger subset of
> Smalltalk into a higher-level language like C#, or maybe Java or C++.
> You'd be able to
> automatically translate a lot more of your Smalltalk codebase, and for
> the parts where
> you can't or don't want to (say to avoid bringing along the whole
> Morphic thing) you'd
> have a much better fit for plugging in a replacement library.

Well, compiling Smalltalk into some other high-level language has been
attempted a number of times, but the fact that all existing Smalltalk
implementations work differently should raise some doubts about the
practicality.
You mentioned the type inferencing "hard problem". Guess what? The same
problem raises its ugly head when you try to compile Smalltalk to any of
the statically typed languages. The way out of the dilemma is to
essentially simulate Smalltalk's method lookup, which basically results
in a badly-written and bloated re-implementation of the Squeak VM. You
might just as well use The Real Thing.
At the end of the day, Squeak images run fairly well on Squeak VMs...

>
>
> So here's what I'd like to do. I think I heard that Newspeak got
> open-sourced due to
> lack of funding. So, I'm thinking that if I bring the Newspeak UI
> stuff into Squeak,
> and use it as the UI layer to develop in Squeak, I get the benefits of
> the rapid-
> prototyping/RAD Smalltalk style, using all the tools available
> therein. And I get the
> ability (maybe) to take the resulting Squeak application code, run an
> auto-translator
> on it to generate for example C# or Java versions of the
> application-specific classes,
> and link that code against a (so far non-existing) library that mimics
> the Newspeak UI
> classes.

The Newspeak UI libraries might be a good choice for getting native
widgets into your app, but I doubt that translating Smalltalk code into
Java or C# gives you much more than a sizable headache.
Investing some time into getting a stripping mechanism to return nice
usable images is most likely the most promising choice.

Cheers,
Hans-Martin

Michael Rueger-6

Re: [squeak-dev] Application deployment in Squeak

Hans-Martin Mosner wrote:

> If you skip the fancy type-inference stuff and just throw out the
> compiler and development tools, you might get a pretty OK result without
> much hassle. Of course there would be room for space improvement, but in
> today's desktop environments this is mostly a non-issue.

There is still one reason why you would want to keep your image as small
as possible: garbage collection.
What would help would be what in VW is called PermSpace. Eliot probably
knows best how much that would save on GCs and/or what the trade offs are.

Michael

Ralph Johnson

Re: [squeak-dev] Application deployment in Squeak

In reply to this post by Kevin-231

>
> Options:
>
> - Stripped Squeak image: I've picked up hints of various attempts at this
> (Dependency-
> walker type things, and scripts that disable developer tools). Seems that
> this is a
> hard problem though, between type-inferencing where variables can take on
> arbitrary types,
> and reflection, and dynamic evaluation, and so on. So, for now at least
> this is kind
> of a cumbersome and unwieldy way to deal with app deployment.

Since you are just going to be packaging a game that you are
developing in Squeak, this is what you should do. Forget
type-inferincing. Just go with your understanding of your application
and trial and error. I've had students use this to package games they
made in Squeak, and it only took them a week or two to get it to work.
The other possibilities are all long-range research projects.
Compared to those ideas, stripping an image is boring and unwieldy.
However, it is what people use today when they want to deploy an
application in Squeak that is as small as possible.

-Ralph Johnson