Feedback: Using Output as the Next Input
Locked
Feedback: Using Output as the Next Input
 
|
Howdy,
A class is instantiated and produces output in a data structure (array, collection, dictionary, ...). Upon each later (maybe months later) instantiation, the previous output is needed as input. What is the best way to do this for modest (not huge) output? Some possibilities: Externally - file out and file in Within the class - compile class methods containing the output; save with Montecello I'm interested in how to dynamically compile a class method. Can Browser be invoked dynamically? In studying Browser and friends, it looks complicated. Am I missing something or attempting something foolish or ...? - Dan _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
> On 04.12.2014, at 23:14, Dan <[hidden email]> wrote: > > Howdy, > > A class is instantiated and produces output in a data structure (array, collection, dictionary, > ...). Upon each later (maybe months later) instantiation, the previous output is needed as > input. What is the best way to do this for modest (not huge) output? Some possibilities: > Externally - file out and file in > Within the class - compile class methods containing the output; save with Montecello > > I'm interested in how to dynamically compile a class method. Can Browser be invoked > dynamically? In studying Browser and friends, it looks complicated. Am I missing something > or attempting something foolish or ...? - Bert - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
smime.p7s (5K)
Re: Feedback: Using Output as the Next Input
|
|
In reply to this post by Dan Norton
On 5 Dec 2014 at 1:13, Bert Freudenberg wrote:
> > > On 05.12.2014, at 00:49, Dan <[hidden email]> wrote: > > > > On 4 Dec 2014 at 23:22, Bert Freudenberg wrote: > > > >> > >>> On 04.12.2014, at 23:14, Dan <[hidden email]> wrote: > >>> > >>> Howdy, > >>> > >>> A class is instantiated and produces output in a data > structure > >> (array, collection, dictionary, > >>> ...). Upon each later (maybe months later) instantiation, the > >> previous output is needed as > >>> input. What is the best way to do this for modest (not huge) > >> output? Some possibilities: > >>> Externally - file out and file in > >>> Within the class - compile class methods containing the > output; > >> save with Montecello > >>> > >>> I'm interested in how to dynamically compile a class method. > Can > >> Browser be invoked > >>> dynamically? In studying Browser and friends, it looks > >> complicated. Am I missing something > >>> or attempting something foolish or ...? > >> > >> Why wouldn't you just keep the "output" in the image and save > it? > >> 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. > Terse Guide to Squeak? > > 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... ;) > > 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 Montecello. > 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. - Dan _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
In reply to this post by Dan Norton
> > > On 05.12.2014, at 00:49, Dan <[hidden email]> wrote:
>>> I'm interested in how to dynamically compile a class method.
It's easy (Thanks, Stephane):
You can invoke directly the compiler
for example in Pharo (there is a nice pharo-user mailing-list)
you can do
MyClass compile: ‘myMethod ^ 42’
and you method is compiled and added to the class.
You can also create a class doing
Compiler evaluate: 'Object subclass: #Box2
instanceVariableNames: ''height width''
classVariableNames: ''''
category: ''AABox’''
- Dan
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
In reply to this post by Dan Norton
On 05.12.2014, at 12:15, Dan <[hidden email]> wrote:
> > On 5 Dec 2014 at 1:13, Bert Freudenberg wrote: > >> On 05.12.2014, at 00:49, Dan <[hidden email]> wrote: >>> >>> On 4 Dec 2014 at 23:22, Bert Freudenberg wrote: >>> >>>> Why wouldn't you just keep the "output" in the image and save >> it? >>>> 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? SomeClass compile: code classified: category. E.g. MyClass compile: 'hello ^6*9' classified: 'foo'. MyClass new hello ==> 54 Or 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 > Montecello. >> 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. 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. - Bert - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
On 12/5/14, Bert Freudenberg <[hidden email]> wrote:
> On 05.12.2014, at 12:15, Dan <[hidden email]> wrote: >> >> On 5 Dec 2014 at 1:13, Bert Freudenberg wrote: >> >>> On 05.12.2014, at 00:49, Dan <[hidden email]> wrote: >>>> >>>> On 4 Dec 2014 at 23:22, Bert Freudenberg wrote: >>>> >>>>> Why wouldn't you just keep the "output" in the image and save >>> it? >>>>> 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. > > E.g. > MyClass compile: 'hello ^6*9' classified: 'foo'. > MyClass new hello > ==> 54 > > Or > > 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 >> Montecello. > > 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 > "quaint". > >>> 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 Metacello). 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 (http://goran.krampe.se/2009/03/16/tirade-a-file-format-for-smalltalkers/ 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! HTH Hannes _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
In reply to this post by Dan Norton
There is no best way. There are many different ways, each with advantages and disadvantages.
Suppose you have a workspace that makes some objects and stores them in workspace variables. The workspace contains a lot of different expressions that use these variables. Some of the expressions might assign to one of the variables, some might use them to change the objects stored in the variables, some might pop up windows on the variables, etc. You use the workspace by selecting expressions and executing them. You can run the expressions in any order, of course, though often some of them assume that variables have been initialized. If you do this, you can use your image as a database. You can save your image any time you want, and when you restart it, you will be right back where you left off. All the workspace variables will have the same values they did before. All the same windows will be up. Of course, if your machine (or image) crashes then you have to restore the last save, and you lose the work you did since then. A bigger problem is that the data is hard to give to someone else. You'd have to give him your entire image. This is a good way to save data when you are in the initial process of developing your program. But once you get into the phase where you are using your program to analyze a lot of different data, you probably want a way of storing data to files. There are lots of ways of storing data to files. You could store it as XML or CSVs. You could store it in a relational database. The simplest way of storing it is as serialized objects. The other ways of storing data to files require figuring out how to map objects to the data format that you pick, while serializing objects lets you avoid that work. On the other hand, it can only be read back by other images. Since you are seem to be learning Smalltalk, I would suggest doing everything in a workspace at first, and using your image as a database. This will force you to learn Smalltalk faster. When you think you understand it, come back and ask us about all the problems of using an image as a database. -Ralph Johnson On Thu, Dec 4, 2014 at 4:14 PM, Dan <[hidden email]> wrote: Howdy, _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
Dumb questions can have uses after all. Thank you Hannes and Ralph for your thoughtful
responses. You must have been digging into the archives - my original post was nearly a year ago. Perhaps it is time to say what I chose to do. Design of Secret Santa was driven by: 1. A desire for simplicity 2. Relatively infrequent use (annual) Input is a text file listing the names of participants. A pair of names on the same line denotes a couple. Output consists of the result of drawing names, compiled as a class method. Method names are serialized: drawn2012, drawn2013, ... The Transcript shows the latest drawing, as a Dictionary, which is compiled. Below that in the Transcript are the statistics (iterations, rule violations). The image must be saved. I would appreciate any thoughts on application delivery. The above is a very crude, if not non-existent, way to deliver an app. Use of external files for output would improve things a little. Isn't it possible to do better than this for a Smalltalk app? What if the user is not a fan of computers? - Dan _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
Writing to a file is very similar to writing to the transcript. You need to open a writestream on the file, then you write to it. If I were writing the data out, I'd probably try to write it out as a CSV (comma separated values) so that I could read it into a spreadsheet. If you want to make it easy for people who don't like computers, perhaps you should make a GUI for it. The GUI might list all the drawings in the top pane. When you select a drawing, you get to see its contents in the bottom pane. I assume that when you run drawn2012 it returns some kind of data structure that gives you the drawing for 2012? My son had something like this. He had his program send each person email, telling them who they drew. If you wanted to do this, you could focus on how to send email instead of on how to make a GUI. I'm not sure what your motivation is here. Is your main aim to learn a little Smalltalk? To make a useful tool for yourself? To make a useful tool for someone else? These are all worthy goals. My advice would depend on your goal. And of course, goals change. You might have started out just wanting to learn Smalltalk but now you just want to make a tool that someone else can use so you don't have to be in charge any more. On Sat, May 2, 2015 at 8:07 AM, Dan Norton <[hidden email]> wrote: Dumb questions can have uses after all. Thank you Hannes and Ralph for your thoughtful _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
Writing and reading files can be done easily. For Cuis, I summarized the protocol in World >
Help... > Terse Guide to Cuis > File Streams. If a file is used for the output, then it will have to
be parsed in some way in the future. By compiling it into a class method which answers a
Dictionary accessed by the drawing methods, no further parsing is needed.
A GUI might be appropriate for a user who does not like computers, but a definite
requirement IMO is to not have the IDE obvious.
I'd like to use this discussion to provoke comment on app delivery in Squeak and Cuis. If you google 'Future of Smalltalk' you'll find a concise statement of the problem: "One of the big problems ... which prevents the take-up of any "workspace" based language (Smalltalk, APL, Forth etc.) is that it's really hard to work out what it is that is delivered to the customer." - Frank Carver http://www.efsol.com/FrankCarver.html. On 2 May 2015 at 9:26, Ralph Johnson wrote:
>
> Writing to a file is very similar to writing to the transcript.
> You need to open a writestream on the
> file, then you write to it.
>
> If I were writing the data out, I'd probably try to write it out as
> a CSV (comma separated values) so
> that I could read it into a spreadsheet.
>
> If you want to make it easy for people who don't like computers,
> perhaps you should make a GUI
> for it. The GUI might list all the drawings in the top pane.
> When you select a drawing, you get to
> see its contents in the bottom pane.
>
> I assume that when you run drawn2012 it returns some kind of data
> structure that gives you the
> drawing for 2012?
>
> My son had something like this. He had his program send each
> person email, telling them who
> they drew. If you wanted to do this, you could focus on how to
> send email instead of on how to
> make a GUI.
>
> I'm not sure what your motivation is here. Is your main aim to
> learn a little Smalltalk? To make a
> useful tool for yourself? To make a useful tool for someone
> else? These are all worthy goals. My
> advice would depend on your goal. And of course, goals change.
> You might have started out just
> wanting to learn Smalltalk but now you just want to make a tool that
> someone else can use so you
> don't have to be in charge any more.
>
> On Sat, May 2, 2015 at 8:07 AM, Dan Norton <[hidden email]>
> wrote:
> Dumb questions can have uses after all. Thank you Hannes and
> Ralph for your thoughtful
> responses. You must have been digging into the archives - my
> original post was nearly a
> year ago.
>
> Perhaps it is time to say what I chose to do. Design of Secret
> Santa was driven by:
> 1. A desire for simplicity
> 2. Relatively infrequent use (annual)
>
> Input is a text file listing the names of participants. A pair
> of names on the same line
> denotes
> a couple. Output consists of the result of drawing names,
> compiled as a class method.
> Method names are serialized: drawn2012, drawn2013, ...
>
> The Transcript shows the latest drawing, as a Dictionary, which
> is compiled. Below that in
> the
> Transcript are the statistics (iterations, rule violations). The
> image must be saved.
>
> I would appreciate any thoughts on application delivery. The
> above is a very crude, if not
> non-existent, way to deliver an app. Use of external files for
> output would improve things a
> little. Isn't it possible to do better than this for a Smalltalk
> app? What if the user is not a fan
> of
> computers?
>
> - Dan
> _______________________________________________
> Beginners mailing list
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
On Sat, May 2, 2015 at 2:33 PM, Dan Norton <[hidden email]> wrote:
A file can be AN output, not THE output. In general, it is useful to have a variety of outputs. I was thinking of creating text files in addition to what you are doing now. But, yes, one alternative is for the history of the drawings to be kept in a file and read in when you start up. That would require parsing the file. But I was assuming that was not what you meant.
Horrors! Don't show the IDE unless the user is a programmer! 1) The trivial way to hide the IDE (while making it easy to get it back if you want it) Open the window for the application (assuming you built a GUI for your application). Close all other windows, especially windows for the IDE. Save the image. Now, when people start up the image, the first thing they see will be the window for the application. On the other hand, they can still get a menu to create a browser if they want to, so the IDE is only slightly hidden. 2) A much more complete way to hide the IDE. When the virtual machine starts up an image, it runs a bit of code (I think it actually runs a block that is stored in a class variable somewhere, but it has been a long time since I have looked at it) that redraws the windows and starts up a process to follow the mouse and the keyboard. You can change this to have it start up your own application. This is useful if you are trying to build a video game in Squeak. If you do this, you can hide everything except your application. There will be no way to get a browser, though usually you will still get a debugger if there is an error, and you can then evaluate an expression to open up a browser. If you REALLY want to hide the browser, delete its classes from the system. Of course, that makes debugging hard if you find an error later. In either case, it is possible to merge the image file with the virtual machine file to create a single, double-clickable file. That way, your customer can just double-click the file and run the application. It has been many years since I have done this, but I have often told students about it and they tell me it isn't hard. See http://wiki.squeak.org/squeak/778.diff?id=42 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
In reply to this post by Dan Norton
Frank, App delivery depends on your goals. If you are a miserly Scrooge at heart, you'll consider all your code proprietary or your customers too stupid to learn Smalltalk, so you can write your code in your own collection, keep it out of the System Browser, and hide it in a single variable, or adopt a restricted sandbox GUI like eToys uses which hides the Browser. But if you have a more loving view of your customers, you might decide to give them everything plus a tutorial on how to modify the source Smalltalk to suit their individual desires. Most business customers will find it cheaper to hire you to make changes either way since you'll have the knowledge and skill to do it faster than they could. One of the most disastrous miserly tactics I've ever heard of was a vendor put a time check on his code and if it wasn't updated every month it would fail to work, thus insuring continued payments he figured. But his tricking the customer failed when he went on vacation and didn't supply an upgrade one month, the system crashed, and the customer had to find a new solution. Kirk Fraser This is being done in poverty www.reliablerobots.com On Sat, May 2, 2015 at 12:33 PM, Dan Norton <[hidden email]> wrote:
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
Heart inspect ifFalse: [Preferences disableProgrammerFacilities]
SCNR, Herbert P.S. disableProgrammerFacilities has a good comment which I suggest reading. Am 02.05.2015 um 22:58 schrieb Kirk
Fraser:
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
:D Unfortunately #disableProgrammerFacilities doesn't.
On 3 May 2015 at 6:37, Herbert König wrote: > > Heart inspect ifFalse: [Preferences disableProgrammerFacilities] > SCNR, > Herbert > > P.S. disableProgrammerFacilities has a good comment which I suggest > reading. > > Am 02.05.2015 um 22:58 schrieb Kirk Fraser: > Frank, > > App delivery depends on your goals. If you are a miserly > Scrooge at heart, you'll consider > all your code proprietary or your customers too stupid to learn > Smalltalk, so you can write > your code in your own collection, keep it out of the System > Browser, and hide it in a single > variable, or adopt a restricted sandbox GUI like eToys uses > which hides the Browser. But if > you have a more loving view of your customers, you might decide > to give them everything > plus a tutorial on how to modify the source Smalltalk to suit > their individual desires. Most > business customers will find it cheaper to hire you to make > changes either way since you'll > have the knowledge and skill to do it faster than they could. > > One of the most disastrous miserly tactics I've ever heard of > was a vendor put a time check > on his code and if it wasn't updated every month it would fail > to work, thus insuring > continued payments he figured. But his tricking the customer > failed when he went on > vacation and didn't supply an upgrade one month, the system > crashed, and the customer > had to find a new solution. > > Kirk Fraser > This is being done in poverty www.reliablerobots.com > > On Sat, May 2, 2015 at 12:33 PM, Dan Norton > <[hidden email]> wrote: > Writing and reading files can be done easily. For Cuis, I > summarized the protocol in > World > Help... > Terse Guide to Cuis > File Streams. If a file > is used for the output, > then it will have to be parsed in some way in the future. By > compiling it into a class > method which answers a Dictionary accessed by the drawing > methods, no further > parsing is needed. > > A GUI might be appropriate for a user who does not like > computers, but a definite > requirement IMO is to not have the IDE obvious. > > I'd like to use this discussion to provoke comment on app delivery > in Squeak and Cuis. If you > google 'Future of Smalltalk' you'll find a concise statement of the > problem: "One of the big > problems ... which prevents the take-up of any "workspace" based > language (Smalltalk, > APL, Forth etc.) is that it's really hard to work out what it is > that is delivered to the > customer." - Frank Carver http://www.efsol.com/FrankCarver.html. > > On 2 May 2015 at 9:26, Ralph Johnson wrote: > > > > > Writing to a file is very similar to writing to the > transcript. > > You need to open a writestream on the > > file, then you write to it. > > > > If I were writing the data out, I'd probably try to write it > out as > > a CSV (comma separated values) so > > that I could read it into a spreadsheet. > > > > If you want to make it easy for people who don't like > computers, > > perhaps you should make a GUI > > for it. The GUI might list all the drawings in the top > pane. > > When you select a drawing, you get to > > see its contents in the bottom pane. > > > > I assume that when you run drawn2012 it returns some kind of > data > > structure that gives you the > > drawing for 2012? > > > > My son had something like this. He had his program send > each > > person email, telling them who > > they drew. If you wanted to do this, you could focus on how > to > > send email instead of on how to > > make a GUI. > > > > I'm not sure what your motivation is here. Is your main aim > to > > learn a little Smalltalk? To make a > > useful tool for yourself? To make a useful tool for > someone > > else? These are all worthy goals. My > > advice would depend on your goal. And of course, goals > change. > > You might have started out just > > wanting to learn Smalltalk but now you just want to make a > tool that > > someone else can use so you > > don't have to be in charge any more. > > > > On Sat, May 2, 2015 at 8:07 AM, Dan Norton > <[hidden email]> > > wrote: > > Dumb questions can have uses after all. Thank you > Hannes and > > Ralph for your thoughtful > > responses. You must have been digging into the > archives - my > > original post was nearly a > > year ago. > > > > Perhaps it is time to say what I chose to do. Design > of Secret > > Santa was driven by: > > 1. A desire for simplicity > > 2. Relatively infrequent use (annual) > > > > Input is a text file listing the names of > participants. A pair > > of names on the same line > > denotes > > a couple. Output consists of the result of drawing > names, > > compiled as a class method. > > Method names are serialized: drawn2012, drawn2013, > ... > > > > The Transcript shows the latest drawing, as a > Dictionary, which > > is compiled. Below that in > > the > > Transcript are the statistics (iterations, rule > violations). The > > image must be saved. > > > > I would appreciate any thoughts on application > delivery. The > > above is a very crude, if not > > non-existent, way to deliver an app. Use of external > files for > > output would improve things a > > little. Isn't it possible to do better than this for a > Smalltalk > > app? What if the user is not a fan > > of > > computers? > > > > - Dan > > _______________________________________________ > > Beginners mailing list > > [hidden email] > > > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Feedback: Using Output as the Next Input
|
|
Sorry,
I noticed it in Preferences and thought it had made it into the image by now. In the days of 3.8 you would have to load SqueakLockdown-nk.1.cs prior to sending #disableProgrammerFacilities. If you can't find that file I can send it to you. But Squeak changed a lot so not sure if it still works. But I managed to find the folder where I had more or less automated the generation of locked down images because my customer at that time insisted on getting images (well programs as he called it) where an accidental click or keypress would not bring up strange things. Maybe you open a new thread on Squeak dev about this. Cheers, Herbert Am 03.05.2015 um 19:52 schrieb Dan Norton: > :D Unfortunately #disableProgrammerFacilities doesn't. > > On 3 May 2015 at 6:37, Herbert König wrote: > >> Heart inspect ifFalse: [Preferences disableProgrammerFacilities] >> SCNR, >> Herbert >> >> P.S. disableProgrammerFacilities has a good comment which I suggest >> reading. >> >> Am 02.05.2015 um 22:58 schrieb Kirk Fraser: >> Frank, >> >> App delivery depends on your goals. If you are a miserly >> Scrooge at heart, you'll consider >> all your code proprietary or your customers too stupid to learn >> Smalltalk, so you can write >> your code in your own collection, keep it out of the System >> Browser, and hide it in a single >> variable, or adopt a restricted sandbox GUI like eToys uses >> which hides the Browser. But if >> you have a more loving view of your customers, you might decide >> to give them everything >> plus a tutorial on how to modify the source Smalltalk to suit >> their individual desires. Most >> business customers will find it cheaper to hire you to make >> changes either way since you'll >> have the knowledge and skill to do it faster than they could. >> >> One of the most disastrous miserly tactics I've ever heard of >> was a vendor put a time check >> on his code and if it wasn't updated every month it would fail >> to work, thus insuring >> continued payments he figured. But his tricking the customer >> failed when he went on >> vacation and didn't supply an upgrade one month, the system >> crashed, and the customer >> had to find a new solution. >> >> Kirk Fraser >> This is being done in poverty www.reliablerobots.com >> >> On Sat, May 2, 2015 at 12:33 PM, Dan Norton >> <[hidden email]> wrote: >> Writing and reading files can be done easily. For Cuis, I >> summarized the protocol in >> World > Help... > Terse Guide to Cuis > File Streams. If a file >> is used for the output, >> then it will have to be parsed in some way in the future. By >> compiling it into a class >> method which answers a Dictionary accessed by the drawing >> methods, no further >> parsing is needed. >> >> A GUI might be appropriate for a user who does not like >> computers, but a definite >> requirement IMO is to not have the IDE obvious. >> >> I'd like to use this discussion to provoke comment on app delivery >> in Squeak and Cuis. If you >> google 'Future of Smalltalk' you'll find a concise statement of the >> problem: "One of the big >> problems ... which prevents the take-up of any "workspace" based >> language (Smalltalk, >> APL, Forth etc.) is that it's really hard to work out what it is >> that is delivered to the >> customer." - Frank Carver http://www.efsol.com/FrankCarver.html. >> >> On 2 May 2015 at 9:26, Ralph Johnson wrote: >> >> > >> > Writing to a file is very similar to writing to the >> transcript. >> > You need to open a writestream on the >> > file, then you write to it. >> > >> > If I were writing the data out, I'd probably try to write it >> out as >> > a CSV (comma separated values) so >> > that I could read it into a spreadsheet. >> > >> > If you want to make it easy for people who don't like >> computers, >> > perhaps you should make a GUI >> > for it. The GUI might list all the drawings in the top >> pane. >> > When you select a drawing, you get to >> > see its contents in the bottom pane. >> > >> > I assume that when you run drawn2012 it returns some kind of >> data >> > structure that gives you the >> > drawing for 2012? >> > >> > My son had something like this. He had his program send >> each >> > person email, telling them who >> > they drew. If you wanted to do this, you could focus on how >> to >> > send email instead of on how to >> > make a GUI. >> > >> > I'm not sure what your motivation is here. Is your main aim >> to >> > learn a little Smalltalk? To make a >> > useful tool for yourself? To make a useful tool for >> someone >> > else? These are all worthy goals. My >> > advice would depend on your goal. And of course, goals >> change. >> > You might have started out just >> > wanting to learn Smalltalk but now you just want to make a >> tool that >> > someone else can use so you >> > don't have to be in charge any more. >> > >> > On Sat, May 2, 2015 at 8:07 AM, Dan Norton >> <[hidden email]> >> > wrote: >> > Dumb questions can have uses after all. Thank you >> Hannes and >> > Ralph for your thoughtful >> > responses. You must have been digging into the >> archives - my >> > original post was nearly a >> > year ago. >> > >> > Perhaps it is time to say what I chose to do. Design >> of Secret >> > Santa was driven by: >> > 1. A desire for simplicity >> > 2. Relatively infrequent use (annual) >> > >> > Input is a text file listing the names of >> participants. A pair >> > of names on the same line >> > denotes >> > a couple. Output consists of the result of drawing >> names, >> > compiled as a class method. >> > Method names are serialized: drawn2012, drawn2013, >> ... >> > >> > The Transcript shows the latest drawing, as a >> Dictionary, which >> > is compiled. Below that in >> > the >> > Transcript are the statistics (iterations, rule >> violations). The >> > image must be saved. >> > >> > I would appreciate any thoughts on application >> delivery. The >> > above is a very crude, if not >> > non-existent, way to deliver an app. Use of external >> files for >> > output would improve things a >> > little. Isn't it possible to do better than this for a >> Smalltalk >> > app? What if the user is not a fan >> > of >> > computers? >> > >> > - Dan >> > _______________________________________________ >> > Beginners mailing list >> > [hidden email] >> > >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> > >> >> >> >> _______________________________________________ >> Beginners mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> >> >> >> >> >> _______________________________________________ >> Beginners mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> >> > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
«
Return to Squeak - Beginners
|
1 view|%1 views
| Free forum by Nabble | Edit this page |