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
On 04.12.2014, at 23:14, Dan dnorton@mindspring.com 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 -
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 dnorton@mindspring.com 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 ...?
- Dan
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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
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 dnorton@mindspring.com 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:
- A desire for simplicity
- 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 dnorton@mindspring.com 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 SecretSanta was driven by: 1. A desire for simplicity 2. Relatively infrequent use (annual)
Input is a text file listing the names of participants. A pairof 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, whichis 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. Theabove 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Sat, May 2, 2015 at 2:33 PM, Dan Norton dnorton@mindspring.com 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.
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.
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.
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
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 dnorton@mindspring.com 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 dnorton@mindspring.com 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 SecretSanta was driven by: 1. A desire for simplicity 2. Relatively infrequent use (annual)
Input is a text file listing the names of participants. A pairof 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, whichis 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. Theabove 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 http://www.reliablerobots.com
On Sat, May 2, 2015 at 12:33 PM, Dan Norton <dnorton@mindspring.com mailto:dnorton@mindspring.com> 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 <dnorton@mindspring.com <mailto:dnorton@mindspring.com>> > 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 >Beginners@lists.squeakfoundation.org <mailto:Beginners@lists.squeakfoundation.org> >http://lists.squeakfoundation.org/mailman/listinfo/beginners > _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org <mailto:Beginners@lists.squeakfoundation.org> http://lists.squeakfoundation.org/mailman/listinfo/beginners
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
: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 miserlyScrooge 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 ofwas 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 Nortondnorton@mindspring.com 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 likecomputers, 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 thetranscript. > 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 dnorton@mindspring.com > 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 > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners >
_______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 miserlyScrooge 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 ofwas 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 Nortondnorton@mindspring.com 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 likecomputers, 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 thetranscript. > 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 dnorton@mindspring.com > 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 > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners >
_______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
Dan -
Dan Norton
-
Herbert König -
Kirk Fraser -
Ralph Johnson