[Newbies] Feedback: Using Output as the Next Input
hannes.hirzel at gmail.com
Fri May 1 08:07:13 UTC 2015
On 12/5/14, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 05.12.2014, at 12:15, Dan <dnorton at mindspring.com> wrote:
>> On 5 Dec 2014 at 1:13, Bert Freudenberg wrote:
>>> On 05.12.2014, at 00:49, Dan <dnorton at mindspring.com> wrote:
>>>> On 4 Dec 2014 at 23:22, Bert Freudenberg wrote:
>>>>> Why wouldn't you just keep the "output" in the image and save
>>>>> When you restart it months later, it will be there.
>>>>> - Bert -
>>>> That surely is simpler than trying to compile a method.
>>> Not that compiling a method is hard.
>> That is encouraging. Is it something similar to "Dynamic Message Calling"
>> described in the
>> Terse Guide to Squeak?
> Like this:
> SomeClass compile: code classified: category.
> MyClass compile: 'hello ^6*9' classified: 'foo'.
> MyClass new hello
> ==> 54
> MyClass class compile: 'helloAgain ^13r42' classified: 'bar'.
> MyClass helloAgain
> ==> 54
>>>> I might put something like this in a package.
>>> I'm not sure what you mean by that.
>> I mean a package on SqueakMap where one can download it and try it out. I
>> see there are
>> over 700 packages out there for the choosing. A great variety. It's
>> unfortunate that not all run
>> on the current release of Squeak but maybe with a little work... ;)
> SqueakMap is just a catalog for finding useful code. You first need to put
> your stuff somewhere else, SqueakMap would be the last step.
>>>> Would users find saving the image as... to be the expected way of
>>> doing things?
>>>> - Dan
>>> Depends on who your users are. If you were the user ... you're
>>> saving your image all the time, right?
>> Um, not exactly. But more often than in the past. I feel most comfortable
>> saving with
> Smalltalk is a personal computing environment, first and foremost. Source
> code is secondary. We basically just resort to source code when we want to
> share stuff with other people. Source code in files has been called
>>> Maybe you should be more specific in what data you want to store,
>>> how you want to distribute it, and who is going to use it.
>> I have in mind a list of names which are matched randomly in pairs then
>> filtered according to
>> a set of rules. The output is a dictionary and the rules specify that no
>> pair can be the same as
>> previous (up to 3) instances. There are other rules and often hundreds of
>> iterations take
>> place before all pairs obey all the rules.
>> It might be used, as it is in our family, to draw names for Christmas. The
>> person who runs the
>> program distributes the results to those on the list.
> Keeping it in the image is certainly the simplest, especially if you intend
> to use it by just running an expression in a workspace.
> If you build it as an app so the user does not have to deal with Smalltalk,
> then it is advisable to treat the deployed image as read-only. In that case
> you would have to store the data in a separate file.
> What makes no sense at all is storing that data in source code.
Quite a number of people using Smalltalk "live" in an image. The image
file is treated like a "database" which contains the work (data and
code acting on it). For that what you do is to save the image and keep
backups. And continue to work with the very same image. This is what
Bert refers to.
Another way is to multiple images. Or work with a group of others
where you need to share the data. Everybody has his or her own image.
Then keeping data in source code makes a lot of sense in particular if
you are using a DSL (very easy in Smalltalk) which describes the data
in a way decodable for non-Smalltalk users. Having the data in a class
and filing it out as source code allows you to move your data easily
to another image. You may have a package with your 'Resources', i.e.
the data as code which people can load to get your work (as you write
There are however other ways for data exchange as well, search in the
Squeak mailing list for SIXX (XML based) and Fuel (binary) for
example. They have their own merits.
I think for your question ' Using Output as the Next Input' to have
the output encoded in source code and use it maybe months later (in a
different image, maybe in a different Smalltalk system, e.g. Cuis or
Pharo) makes a lot of sense if that works for you.
As you have seen in the answer provided by Bert and others generating
Smalltalk code is straightforward.
Depending on your (internal) DSL you use to describe your data you may
as well parse it with another system. Six years ago Goran Krampe
came up with a (Smalltalk) file format he called 'Tirade' and there
was some discussion on it on the Squeak list
and check out the list archives).
I suggest you have a look at it and then maybe ask more about it
here or on the Squeak, Pharo or Cuis list.
Actually you asked a great question!
More information about the Beginners