Squeak-dev November 2000

squeak-dev@lists.squeakfoundation.org

106 participants
325 discussions

[ENH]MPEGPlayerMorph (a little tweaking)
by Karl Ramberg 24 Nov '00

24 Nov '00

I made a little improvement to the logic of the gui. I now has two buttons. One to open up a file and one to play or stop. I had to make some ugly code to make this work: videoPlayerProcess ifNil:[ video _ true] ifNotNil:[(videoPlayerProcess suspendedContext asString = 'UndefinedObject>>DoIt') ifTrue:[ video _ true] ifFalse:[ video _ false]]. Maybe someone knows a better way to signal that the process has terminated ? Because it's still referred to it hangs around but referred to as a UndefinedObject>>DoIt. Are there some examples of the new layout system ? I love to make use of them but it's easiest to learn if I can read some code :-) In MPEGPlayer2>>playVideo: you can find the lines "fum displayAt: self videoMorph topLeft." videoMorph changed. I love to get some feedback on playback speed on these two different mechanisms. Thanks to Joshua Gargus for some fixing to make this still work under the new layout rules.

2 1

Slightly off-topic: Spacewar!
by Kevin Fisher 24 Nov '00

24 Nov '00

Recently I was reading that old Rolling Stone article about Spacewar (http://www.wheels.org/spacewar/stone/rolling_stone.html) and lamenting that I was born too late. :) I was just wondering...at the end of the article are some code snippets attributed to Alan Kay. It looks Smalltalk-ish...what dialect of Smalltalk is that? :) And how can I convince my employer to build a beanbag-chair room like the one in the picture? (I really enjoyed reading this article...what fabulous snapshot of a very exciting time to be involved with computers...the ARPAnet was only 2 years old at the time of writing, and already they were talking about internet games, and music sharing a-la Napster!)

2 2

Re: jpython anyone?
by russell.allen＠firebirdmedia.com 24 Nov '00

24 Nov '00

Hi Henrik, The area that I'm working on is legal AI, which probably is somewhat different to general AI, but does (I think) have some overlap. Some of the earliest attempts to model the process of legal reasoning did follow the path of talking to the computer in 'Math-like languages' - the Imperial College of Science and Technology in London translated the British Nationality Act into PROLOG, for example. In the field of law it very quickly became apparent that this approach was getting nowhere. Leaving aside more complex issues of the underlying legal reasoning process (which isn't pure logic) the main problem was that of syntax. The substantial difference between the syntax of law and maths meant that the costs involved with creating the rulebases and maintaining them were prohibitive, and that even if you did do this, you quickly ran into the problem that the exact phrasing of the legal materials was vital. You can't paraphrase law without causing potential problems. As a result, much of what I consider to be successful application of AI to law were based upon systems designed to allow the use of the original structure and phrasing of the law. This includes large scale commercial applications, and (incidently) some test applications built using ROSIE. I would argue that this need for a system that allows the use of the original structure and phrasing of the law outweighs the downside of confusing the users and developers with a syntax which looks more intuitive then it is. On the flipside, using Smalltalk has greatly influenced my attitude towards moving beyond simple text editors and compilers to supportive development environments. Hopefully these environments can help users through the immensely difficult task of attempting to think like a computer. Cheers, Russell Henrik Gedenryd <Henrik.Gedenryd(a)lucs.lu.se> wrote: > > > I had expected to see more in this direction over the years. A famous > > (in its time and place) precursor with this approach was ROSIE, a > > very nice expert systems language done at RAND in the late 70s and > > early 80s. Have you seen it? > > There was some by now classical research done on natural language interfaces > in the early 80s. Put simply, the general conclusion was that it is a bad > idea to make a computer mimic humans, because users will then attribute > human capabilities to it that it doesn't have. (Think ELIZA.) This is a > basic social principle that we need in order to interact with others (we > can't read their minds). When we then attribute too much to the computer, > the breakdown that follows is very harsh, much more costly than what is > gained by familiarity when it works. > > It is much better to present the computer so that we will make reasonable > attributions. Math-like languages make us regard it as a math machine, which > is not that unreasonable. > > But of course, this didn't affect AI researchers much. The real reason we > haven't heard about progress in AI is that there hasn't been any to speak > of. The small successes in restricted, well-chosen domains have never > generalized, be it natural language processing, computer vision, symbolic > induction, or whatever. The term "AI winter" was coined in the Lisp > community in the late eighties. Today it seems that Bill Gates is about the > only one who still thinks that AI will be "the next big breakthrough". For > the last 40 years, AI news stories have begun like this: "Soon they will be > here--computers that xxxx". "Don't hold your breath" is one of my favorite > American expressions. > > > The trick in most of these systems is not how hard it is for the > > system to recognize a restricted English syntax, but how hard is it > > for a random human to learn to write in the restricted syntax. > > Would another way to put this be that the supposed advantage, being easier > to learn than more standard programming syntaxes, is not there? "Restricted" > here means that it looks like it's ordinary language but it isn't. It > doesn't let people use ordinary language. > > In fact, a main feature of natural language is not the syntax--but the fact > that most of the time we needn't be very precise at all with the syntax to > be understandable. _This_ is what a "natural" syntax suggests to a user. And > this is not what you want a user/programmer to belive, right? > > Syntax is a big deal in programming languages but not real ones; this is a > point that CS researches miss all the time. In fact, eg. Chomsky's theories > apply much better to programming languages than real ones. With all the > research on syntax, Markov chains (statistics about what words occur close > to each other) are still better predictors of word order in "real" natural > language than any theory of syntax. > > The hard problem in programming is figuring out what to do--you have to > understand the domain of available means (the language capabilities) as well > as well as the problem you are solving. Addressing syntax leaves this alone, > it only concerns how you express the solution once you have figured it out. > Programming languages are just meant to be means for expressing solutions. > What you need to address is the process of reaching solutions. The > interactive environment of Smalltalk is the most important advance that has > been made so far: a compiler merely processes the solution, whereas an > interactive environment supports you while working out a solution. > > So to condense my point: we need to shift the focus from the form of the > expressed solution, to the process which produces it (and tools to support > this). But the nature of such cognitive tools has only begun to be addressed > in the last 5-10 years. > > > Oops, there I did that rant again. > > Henrik ---------------------------------------- Russell Allen russell.allen(a)firebirdmedia.com ----------------------------------------

1 0

Re: question on Dynabook
by Richard A. O'Keefe 24 Nov '00

24 Nov '00

Are you thinking of Speak'n'Spell ('n'Read, 'n'Math, etc.)? Those were fun. They didn't speak very well. The first thing one said to me was "rork". It took me dozens of attempts before I realised that it meant "rock". I guess you had to be a native speaker of some American dialect. Why are the voices in Squeak (and for that matter, the ones that MacOS 8.6 uses to read alert boxes to you) so much less intelligible than the old Macintalk?

1 0

Historical request: original Smalltalk-80 release tapes
by Eric Smith 24 Nov '00

24 Nov '00

I have a request that's a bit off-topic, but several people suggested that I should post it here: I'm looking for copies of the four original Smalltalk-80 release tapes that were sent to the early Xerox licensees, as documented in the Green Book (_Smalltalk-80 Bits of History, Words of Advice_). Some people I've asked about this have told me to just use Squeak instead. This misses the point, which is that I am looking for these old release tapes for historical interest, not for current use. If copies of these tapes turn up, I'd like to make sure that The Computer Museum History Center (www.computerhistory.org) gets a copy. I'm also looking for the native Lisa port of Smalltalk-80. (*NOT* the Macintosh port.) I have suitable means to copy nine-track tapes and Lisa Twiggy diskettes. If anyone can make the media available, I'll be happy to pay shipping both ways, and to return a copy on CD-R as well. Thanks! Eric Smith

3 2

Re: Historical request: original Smalltalk-80 release tapes
by Tim Rowledge 24 Nov '00

24 Nov '00

Alan Kay wrote: > Eric -- > > Try Adele Goldberg (if you haven't already) at Adele Goldberg > <adele(a)neometron.com> . My guess is that Glenn Krasner might be a better bet for this. Try krasner(a)cincom.com tim

1 0

Re: jpython anyone?
by Henrik Gedenryd 23 Nov '00

23 Nov '00

> I had expected to see more in this direction over the years. A famous > (in its time and place) precursor with this approach was ROSIE, a > very nice expert systems language done at RAND in the late 70s and > early 80s. Have you seen it? There was some by now classical research done on natural language interfaces in the early 80s. Put simply, the general conclusion was that it is a bad idea to make a computer mimic humans, because users will then attribute human capabilities to it that it doesn't have. (Think ELIZA.) This is a basic social principle that we need in order to interact with others (we can't read their minds). When we then attribute too much to the computer, the breakdown that follows is very harsh, much more costly than what is gained by familiarity when it works. It is much better to present the computer so that we will make reasonable attributions. Math-like languages make us regard it as a math machine, which is not that unreasonable. But of course, this didn't affect AI researchers much. The real reason we haven't heard about progress in AI is that there hasn't been any to speak of. The small successes in restricted, well-chosen domains have never generalized, be it natural language processing, computer vision, symbolic induction, or whatever. The term "AI winter" was coined in the Lisp community in the late eighties. Today it seems that Bill Gates is about the only one who still thinks that AI will be "the next big breakthrough". For the last 40 years, AI news stories have begun like this: "Soon they will be here--computers that xxxx". "Don't hold your breath" is one of my favorite American expressions. > The trick in most of these systems is not how hard it is for the > system to recognize a restricted English syntax, but how hard is it > for a random human to learn to write in the restricted syntax. Would another way to put this be that the supposed advantage, being easier to learn than more standard programming syntaxes, is not there? "Restricted" here means that it looks like it's ordinary language but it isn't. It doesn't let people use ordinary language. In fact, a main feature of natural language is not the syntax--but the fact that most of the time we needn't be very precise at all with the syntax to be understandable. _This_ is what a "natural" syntax suggests to a user. And this is not what you want a user/programmer to belive, right? Syntax is a big deal in programming languages but not real ones; this is a point that CS researches miss all the time. In fact, eg. Chomsky's theories apply much better to programming languages than real ones. With all the research on syntax, Markov chains (statistics about what words occur close to each other) are still better predictors of word order in "real" natural language than any theory of syntax. The hard problem in programming is figuring out what to do--you have to understand the domain of available means (the language capabilities) as well as well as the problem you are solving. Addressing syntax leaves this alone, it only concerns how you express the solution once you have figured it out. Programming languages are just meant to be means for expressing solutions. What you need to address is the process of reaching solutions. The interactive environment of Smalltalk is the most important advance that has been made so far: a compiler merely processes the solution, whereas an interactive environment supports you while working out a solution. So to condense my point: we need to shift the focus from the form of the expressed solution, to the process which produces it (and tools to support this). But the nature of such cognitive tools has only begun to be addressed in the last 5-10 years. Oops, there I did that rant again. Henrik

2 1

Re: jpython anyone?
by Stefan Matthias Aust 23 Nov '00

23 Nov '00

At 11:08 22.11.00 -0800, you wrote: >I would be interested in finding a JPython-like >language implemented in Squeak. A few months ago I spent a day to two on creating a parser for a subset of Python in Squeak but never finished that. I thought, it would be an interesting experiment to be able to use a python-like syntax. bye -- My eyes adapted to the darkness... finally I can see clearly now

2 1

Smalltalk-72 information (was Re: Historical request: original Smalltalk-80 release tapes)
by Thomas Kuehne 23 Nov '00

23 Nov '00

> Perhaps as interesting (or more so historically) is that Dan does > have one or more versions of the Smalltalk-72 and -76 systems [...] Is anybody aware of documentation (articles, white papers, manuals, etc.) about these languages? I'd be interested to learn in particular about the flexible syntax approach where each class specified its own parsing rules. Would that not be a good approach for an *extensible* scripting system? Cheers, Thomas -- Dr. Thomas Kuehne 0178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne The difficulty in doing research is to find the right questions so that all the answers come easily. -- TK

1 0

[BUG] Bit logic
by Bert Freudenberg 23 Nov '00

23 Nov '00

I just ran "Integer testBitLogic" and it fails because (-1 bitShift: 31) bitShift: -31 answers -2 instead of -1. This is a Linux 2.8 VM (#2359), image updated to #2915. -- Bert

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
33
Older →

Jump to page: