Squeak-dev January 1999

squeak-dev@lists.squeakfoundation.org

143 participants
293 discussions

Re: Squeak on ComputerWorld
by Peter William Lount 27 Jan '99

27 Jan '99

Hi, Ya I had the same result so I downloaded the latest version of the Microsoft player and everything worked fine. There is a link on the stanford web page for downloading the latest player. All the best, Peter W. Lount ---------- From: Randy Siler <rsiler(a)u.washington.edu> To: squeak(a)cs.uiuc.edu Subject: Re: Squeak on ComputerWorld Date: January 27, 1999 1:59 PM > To see streaming video of several of the Symposium presentations, including > Alan Kay's, check out http://stanford-online.stanford.edu/engelbart/ > I'm very interested in listening to this but when I try to I see nothing but black and hear nothing. If I fiddle a bit with it I see some animated graphics about Microsoft but no content follows. Has anyone successfully accessed this content with a Mac? -- "Macintosh - we might not get everything right, but at least we knew the century was going to end." -Douglas Adams

1 0

Small bug fix for host name lookup
by Michael Rutenberg 27 Jan '99

27 Jan '99

This corrects a small bug that prevented the lookup of host names which begin with a digit, such as 100000jobs.de Host names lookup will now be compliant with RFC 1123 section 2.1 Mike mdr(a)scn.org Content-Type: application/x-unknown-content-type-cs_auto_file; name="IPaddress-mdr.27Jan1015pm.cs" Content-Disposition: inline; filename="IPaddress-mdr.27Jan1015pm.cs" Attachment converted: Anon:IPaddress-mdr.27Jan1015pm.cs (????/----) (0000656D)

1 0

Re[2]: Morphic, dataflow and encapsulation
by Jerome.Garcia＠wj.com 27 Jan '99

27 Jan '99

This is exactly why I think there is an advantage to operating directly on parse trees especially if the parse trees include comment nodes. It should be possible to operate on them directly with both syntax directed editors and "graphical" programming systems thus providing for such bi-directional translation. Jerome E. Garcia Adventurous Mind ______________________________ Reply Separator _________________________________ Subject: RE: Morphic, dataflow and encapsulation Author: "Jarvis; Robert P." <Jarvisb(a)timken.com> at INTERNET Date: 1/27/99 7:49 PM In order to be more useful I think a "graphical" programming system must provide bi-directional translation to/from code. Perhaps not from arbitrary code (i.e. given some hand-written UI code it shouldn't be expected or required to generate diagrams), but at least the machine-generated code should be "translatable" back to diagrams. Bob Jarvis The Timken Company > -----Original Message----- > From: Adam Bridge [SMTP:abridge@dcn.davis.ca.us] > Sent: Wednesday, January 27, 1999 2:15 PM > To: swart(a)home.com; squeak(a)cs.uiuc.edu > Subject: RE: Morphic, dataflow and encapsulation > > My problem with graphical programming systems (and here I'm thinking about > a few > very different entities: Prograph is the extreme case, HyperCard and > Interface > Builder for Apple's Yellow Box are more typical ones) is their failure to > produce documentation for what's there or they hide what's going on by > requiring > many different windows to be open. > < good stuff deleted >

1 0

RE: Morphic, dataflow and encapsulation
by Jarvis, Robert P. 27 Jan '99

27 Jan '99

In order to be more useful I think a "graphical" programming system must provide bi-directional translation to/from code. Perhaps not from arbitrary code (i.e. given some hand-written UI code it shouldn't be expected or required to generate diagrams), but at least the machine-generated code should be "translatable" back to diagrams. Bob Jarvis The Timken Company > -----Original Message----- > From: Adam Bridge [SMTP:abridge@dcn.davis.ca.us] > Sent: Wednesday, January 27, 1999 2:15 PM > To: swart(a)home.com; squeak(a)cs.uiuc.edu > Subject: RE: Morphic, dataflow and encapsulation > > My problem with graphical programming systems (and here I'm thinking about > a few > very different entities: Prograph is the extreme case, HyperCard and > Interface > Builder for Apple's Yellow Box are more typical ones) is their failure to > produce documentation for what's there or they hide what's going on by > requiring > many different windows to be open. > > There's no documentation feature which allows someone to tell the > application or > its UI (whatever you're working on) to document itself -- so you end up > hopping > >from place to place, reference to reference, striving to maintain > context. I > HATE this. With a passion. Even Smalltalk can be a pain with three or > four > browsers open at a time while I try to figure out just WHAT object is > going to > respond to a message that has been sent. I must be too old or something. > > One of the things that I liked best about the GUI Builder in > SmalltalkAgents was > that when it built a window it wrote the code for that window which I > could then > see and, if needed, edit. > > In InterfaceBuilder (in Apple's Yellow Box) you build an interface and > hook up > the feature -- but then result is all concealed in a NIB file which is a > black > box -- there's no way to tell IB to write out in human-readable form what > the > contents of that NIB file are. > > This inability to concisely document is, to me, the greatest weakness of > graphical tools. > > Thanks for listening -- pant pant pant.... > > > Adam Bridge >

1 0

Re: Order of precedence
by Ian Bicking 27 Jan '99

27 Jan '99

In message Tue, 26 Jan 1999 09:38:32 -0800, glenn <krasner(a)objectshare.com> writes: > c) cater to adults and children already computer-skilled who have > preconceived notions set by some other computer languages which have > multiple rules, one operator-based and the other left-to-right (or > right-to-left or some such). I'm not saying that the normal, mathematical rules of precedence are easier for children. Quite the contrary -- Smalltalk's simple left-to-right rule is much more intuitive. This is the problem. A child who is introduced to Smalltalk's system would likely have their intuition reinforced, making it all the harder to learn the proper (mathematical notation) rules of precedence. The fact of the matter is, mathematics says that 3+4*5=23. You can't change that -- the mathematical conventions of the world are not going to be changed because they are easier for the computer to parse. In a practical matter, those conventions have been created because they *are* easier to parse (for humans) in real-world situations. They lead to less parenthesis. They group factors. They *are* aesthetic. Perhaps the real answer is to have a view of Squeak where the syntax is fully mathematical. Where 3*sin(x^2+2) works. In this view a child could learn mathematics. But it seems that a better solution could be made, one that encompasses both needs (simplicity and conformity) instead of requiring a break-away syntax. I bring this up because I've been looking at Logo, and one of the big compromises they made in the syntax was to allow infix notation even though it wasn't part of the Lisp tradition and sullied the syntax quite a bit. Now, this is all assuming that a goal of Squeak (distinct from Smalltalk) is as a pedagogical tool. This is by no means necessarily true... though it would be neat if Squeak could be used by children, that doesn't mean it needs to be created for them to learn from it (though, of course, it is impossible to seperate use from learning). Pedagogically, introducing something that looks almost like proper mathematical expressions but isn't is a bad thing to do. This is one reason (not necessarily a huge reason) that I don't think Squeak is ready for children. -- Ian Bicking

4 3

RE: Morphic, dataflow and encapsulation
by Adam Bridge 27 Jan '99

27 Jan '99

My problem with graphical programming systems (and here I'm thinking about a few very different entities: Prograph is the extreme case, HyperCard and Interface Builder for Apple's Yellow Box are more typical ones) is their failure to produce documentation for what's there or they hide what's going on by requiring many different windows to be open. There's no documentation feature which allows someone to tell the application or its UI (whatever you're working on) to document itself -- so you end up hopping >from place to place, reference to reference, striving to maintain context. I HATE this. With a passion. Even Smalltalk can be a pain with three or four browsers open at a time while I try to figure out just WHAT object is going to respond to a message that has been sent. I must be too old or something. One of the things that I liked best about the GUI Builder in SmalltalkAgents was that when it built a window it wrote the code for that window which I could then see and, if needed, edit. In InterfaceBuilder (in Apple's Yellow Box) you build an interface and hook up the feature -- but then result is all concealed in a NIB file which is a black box -- there's no way to tell IB to write out in human-readable form what the contents of that NIB file are. This inability to concisely document is, to me, the greatest weakness of graphical tools. Thanks for listening -- pant pant pant.... Adam Bridge

1 0

Re: 2.3, Unix, and Squeak central
by Lex Spoon 27 Jan '99

27 Jan '99

Bill Cattey <wdc(a)MIT.EDU> wrote: > I've got the 2.3 image and changes file, and I'm running them on my > Solaris and Linux systems in the 2.3beta image I got from inria. I've > noticed that sometimes morphic projects get VERRRRRY slow, and the Play > With Me 3 (16 bits) demo project, when entered hangs the VM and ALT<.> > can't interrupt. > > I figure these may be due to little improvements in 2.3VM that aren't in > the Beta VM. Alas, the 2.3VM has not yet been made available for the > Unix platforms. Is this expected to happen soon, or should I attempt to > reproduce the work of Carl Gruden? > I haven't gotten Play With Me 3 to work, either. However, I haven't seen the slowdowns you mention. One person posted they got a 2.3 VM compiled by: a) generating interp.c from Squeak as normal (comment in CCodeGenerator) b) skipping the translation for GCC that the Unix Makefile normally does. For instance, change "../util/translator" to "/bin/cat" in the makefile. I tried this, and it worked fine.... The only problem is that the VM doesn't contain the truetype code anywhere. Is this in the image somewhere that it can be filed out, or is it platform-specific code that someone the likes of Ian Piumatra will have to write? Lex

1 0

Digitbuffer
by Luciano Notarfrancesco 27 Jan '99

27 Jan '99

SmallInteger has a class variable: Digitbuffer. It is not used in any method, except SmallInteger class|initialize. What is it? Why is it there? Luciano.-

2 1

2.3, Unix, and Squeak central
by Bill Cattey 27 Jan '99

27 Jan '99

I've got the 2.3 image and changes file, and I'm running them on my Solaris and Linux systems in the 2.3beta image I got from inria. I've noticed that sometimes morphic projects get VERRRRRY slow, and the Play With Me 3 (16 bits) demo project, when entered hangs the VM and ALT<.> can't interrupt. I figure these may be due to little improvements in 2.3VM that aren't in the Beta VM. Alas, the 2.3VM has not yet been made available for the Unix platforms. Is this expected to happen soon, or should I attempt to reproduce the work of Carl Gruden? -wdc

2 1

RE: Morphic, dataflow and encapsulation
by johnson＠cs.uiuc.edu 27 Jan '99

27 Jan '99

At 3:56 AM 1/25/99, Hrefna "GumundsdÛttir" wrote: >On Saturday, January 23, 1999 6:56 PM, Andrew C. Greenberg >> I'd be pleased to be educated to the contrary, but it seems to me that >> Jen's suggestion that graphics are always better for "really large" >> programs, indeed, even "always good" for large programs need not always >be >> the case. > >It may a bit 'strong' to say that graphics are 'always good', but can you >point out an area where this does not hold? You have it backward. People have been saying for decades that visual representations for programs are essential. The proponents of VPLs and CASE tools make similar arguments. UML is the latest example. However, there is NOT ONE EXAMPLE of a system that delivers on its promises. Very specialized systems like Stella or GUI builders are certainly useful, and general purpose systems like LabView are good for non programmers. AVL is a nice system, but it has problems, and I bet I could make a better system in Smalltalk that was text-based. Andy's point was that, as a programmer, he had yet to find a system that was as fast and powerful for him as textual programming. I've used VisualAge, for example. It is cute, and great for little demos. It probably helps people get started with Smalltalk. But we found that for big projects, it just gets in the way, and the one large VisualAge project that I am working with has pretty much abandoned the visual builder. This does NOT mean that it is impossible to make a great visual representation of programs. It just means that it is hard, and people have a right to be skeptical. The arguments in favor of graphics are very logical, but experience indicates that there is something wrong with the conclusion. The burden of proof is on the proponents. -Ralph

4 3

← Newer
1
2
3
4
5
6
7
8
9
...
30
Older →

Jump to page: