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
<dnor...@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
<dnor...@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
