Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

That Other Use for Squeak
by Mark Guzdial 03 Jul '00

03 Jul '00

All the discussion on the "Ship it with Squeak" and "Belling the cat" threads has reminded me of my more favorite use for Squeak. There are at least two uses for programming. The common one that most people optimize for is building applications or other software to sell. The other one is "ad hoc" programming, where you use programming for yourself, perhaps for learning or maybe just demonstrating ideas (the way people sketch today). (As people I pester on the SqueakAudio list know, my current personal focus is learning computer music with Squeak.) It's not at all clear that these are similar kinds of activities or even if you'd want to use the same language for both. For the former use, you worry about code repositories, adequate documentation of your interfaces, and well factored code. For the latter...Ha! Who's going to see my code? I'm throwing it away as fast as I write it! More seriously, the issues of how one creates an expressive, easy-to-learn, and widely-applicable programming language for the latter kind of use are not explored much nowadays. Those issues used to be hot, and programming language experts used to explore different languages that helped people in different ways. Nowadays, efficiency and provability seem to have taken over programming language conferences, which are much more former-use issues than latter-use issues. Maybe because former-use has more economic benefits than latter-use...until you get close. Then the common-daily-use market is MUCH larger than the applications market. Andy diSessa, a longtime proponent of "Computing Literacy," tells a great story about what it takes to make programming really take off in the common-daily-use sense in his book "Changing Minds." Newton's intellectual achievement of inventing calculus to demonstrate his scientific points about motion was astounding. But Leibnitz invented calculus at about the same time, and it's his notation (the dx/dt stuff) that we use today. Why? Well, Leibnitz's notation is easier to use and it makes expressing some hard theorems almost simple. But does it matter all that much? It took almost two hundred years for Calculus to become commonplace part of the curriculum. It was in the early part of the 1900's that teachers tried to teach Calculus to undergrads, and succeeded enough that later classes assumed Calculus knowledge: it became infrastructural. But what if, Andy asks, Calculus was 10% harder? What if it was harder to teach it and people were less successful learning it? Would it have still become commonplace? It's an interesting conjecture, but I'm not sure that I agree with it. Andy is using the story to argue that "Once we get the right notation, perhaps programming WILL become commonplace." Yet, it's clear that we are hopelessly unsuccessful teaching programming, and we still require a great many undergrads to study programming. (Everyone at Georgia Tech must take a first course in Scheme.) The fact that we are hopelessly unsuccessful teaching programming is quite well supported in research and experience. Only about 30% of the students who come out of a college-level intro to programming class know how to write a program to average positive integers, avoiding the negative ones until a flag value comes in. Only about 50% of the CS majors in their Sophomore year can write that one without screwing up the negative or flag test. (If you're a teacher, I challenge you to try this or a similar test on your own students! We just did at Tech last year, and we're all still reeling from the results.) The part I completely agree with Andy on is that common programming languages are nowhere easy enough to learn yet, and I hope that the right notation does lead to common-daily-use. And while I applaud the efforts to come up with a Squeak that's great to write applications in (and my group would certainly use and perhaps contribute to such an effort), it's the potential for using Squeak toward that common-daily-use that I find so intriguing and daunting. Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

3 2

Re: That Other Use for Squeak
by Lawson English 03 Jul '00

03 Jul '00

I said: > av = sum/p > > > > He came up with the answer on-the-fly, with almost no pauses at all. I neglected to ask about the case where there WAS no input... ...He said to add a test for p = 0 and dont' make any output in that case [now leave me alone, Mom and I are playing Tetris!]. BTW, Alan, he's agreed to learn Squeak and critique it for you from the point-of-view of a young VB programmer. -- Reform Party members should be advised that there will be TWO names on the Reform Party presidential nomination ballot: John Hagelin <http://www.hagelin.org> Pat Buchanan <http://www.buchanan.org> Make an informed choice! --

1 0

Re: Why not News?
by Jon Hylands 02 Jul '00

02 Jul '00

On Sun, 2 Jul 2000 16:03:31 +0800, "Wisher" <wisher(a)ms6.hinet.net> wrote: > The point is: why not host a News service instead? > So everyone could use their own NewsReader to read them neatly in threads > & date-order. Nice and easy. Rather than to browse the old ones in a 15K > lines so-slow-to-load index page, or those not-easy-to-follow new threads. Get a decent mail reader, and you get this also... I use Agent, and it treats email pretty much exactly the same as news. Later, Jon -------------------------------------------------------------- Jon Hylands Jon(a)huv.com http://www.huv.com/jon Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com

2 1

Re: Better solution [was: Re: [BUG][Linux] VM2.8 port eats processorcycles]
by Stephan Rudlof 02 Jul '00

02 Jul '00

"David T. Lewis" wrote: > > On Thu, Jun 29, 2000 at 10:15:28PM +0200, Bert Freudenberg wrote: > > On Thu, 29 Jun 2000, Tim Rowledge wrote: > > > > > > nanosleep(&sleepTime, &reminderTime); > > > Excellent - do you know if it actually portable to most unices, or is it > > > likely to be a hit and miss affair? > > > > It's a POSIX standard function. I checked (the manpages) on Irix and > > SunOS. For Suns, it seems you have to link with libposix4 though ... > > > > -- Bert > > > It will be somewhat hit and miss. > For example, BDSI does not seem to have it. > > bash-2.02$ uname > BSD/OS > bash-2.02$ man nanosleep > man: no entry for nanosleep in the manual. Raivis Bucis wrote: > > : On Fri, 30 Jun 2000, David T. Lewis wrote: > : > : Maybe in BSD there is some other short sleep than usleep? > > Yes. Look at select or poll (without any descriptor). > > Raivis Hmm, select() seems to be the gcd of all platforms. Probably we should use this instead of nanosleep(). But what is the better variant: To force to initialize the Socket module, which leads to indirectly calling select(), or to call it directly in ioRelinquishProcessorForMicroseconds(int microSeconds)? I prefer the latter, because the Socket module could be nonexistent. But we have to handle the case where microSeconds are 0, because select() could block then (this is errorneous in my previous nanosecond() proposal, too). Other opinions? Greetings, Stephan >From the man page: SELECT(2) Linux Programmer's Manual SELECT(2) NAME select, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - synchronous I/O multiplexing SYNOPSIS #include <sys/time.h> #include <sys/types.h> #include <unistd.h> int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); FD_CLR(int fd, fd_set *set); FD_ISSET(int fd, fd_set *set); FD_SET(int fd, fd_set *set); FD_ZERO(fd_set *set); DESCRIPTION select waits for a number of file descriptors to change status. ... NOTES Some code calls select with all three sets empty, n zero, and a non-null timeout as a fairly portable way to sleep with subsecond precision. ... -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

2 2

Re: Belling the cat of complexity (License issues)
by Andrew C. Greenberg 02 Jul '00

02 Jul '00

>We are talking about two sets of issues here. One is the clarity and >implications of the Squeak license. The other is the specific licensing >terms of various specific contributions, and further, whether those >contributions were legally made. Right, as to the first, I suppose we are in agreement there is no issue. As to the second, I'm alive to this. This is a difficulty of all open source software to some extent. Oddly enough, it hasn't stopped the GNU/Linux movement, or the wide and pervasive deployment of its software, even in major corporations. As to your questions about the licensing status of components, I respectfully reiterate my prior disagreement. A careful reading of the license and its viral nature does not limit it, notwithstanding the express naming of Apple. >Another license issue is when using Squeak specifically for embedded >work. In this case it is not completely clear where the VM boundaries >begins and ends -- so if you link code into the VM to call MP3 audio >compression/decompression routines, does this mean you need to also >release a huge body of work that does MP3 functions? I don't know for >sure. The safe answer is "yes". If you say so. This has to be answered on a case by case basis. The addition of stand-alone pluggable primitive modules resolves almost all potential issues in this regard. >The least risky course of action seems to me to be to go back to the >original Apple Squeak, modularize it, and then have each and every >contribution accompanied by a statement of orginality similar in spirit >to that Python uses. With all due respect to the interesting issues raised by Paul, I think they raise no barrier to use that I can see for most circumstances, but his mileage may vary. IMHO, going back to the "original Apple Squeak" for "recertification" would be an extraordinary waste of time. I, for one, am not fond of the notion of a centralized Pythonesque repository, which is most clearly the exception rather than the rule. If you wish to resolve these issues, gather up the sources of all the changesets. Despite thousands of them, there are probably under a hundred contributers, and see if you can get e-mail ratification of whatever legal documents you may require. While I don't think it is necessary at all, I don't think it would be a bad idea to have an express statement along the lines of "distributed under Squeak-L" expressly or impliedly as a matter of course, or for Disney to insist that all contributions it includes embrace an express >I don't think Squeak can grow beyond a research toy without grappling >and resolving these issues as a community at some point. It already has for others. Perhaps not for Paul. The problems raised by Paul do not impede broad deployment and commercial exploitation of Berkeley or GPL, and related software in proprietary form, though the same issues (except for his license interpretation points and concern about the definition of "over the line" and "under the line" of the VM) occur everywhere else. Despite contributions from folks all over the world in a zillion different places, few would try to argue that the present versions of gcc, BIND, sendmail or dhclient (or the products built around or incorporating them) are "research toys." As I noted, specific requirements may differ from company to company and application to application -- if you have questions, rely on a lawyer you have retained to apply the particular facts to the applicable law. In the meanwhile, while I'm not seriously troubled by the issues Paul raises, and don't share his conclusions at all, I think there are some hygiene issues far short of the proposed Pythonesque cetification process that will do quite well. -- Andrew C. Greenberg acg(a)netwolves.com V.P. Eng., R&D, 813.885.2779 (office) NetWolves Corporation 813.885.2380 (facsimile) www.netwolves.com Please use werdna(a)mucow.com instead of werdna(a)gate.net

2 1

Re: Ship it with Squeak
by 320089961391-0001＠t-online.de 02 Jul '00

02 Jul '00

> From: "Jay Carlson" <nop(a)nop.com> [ skins -> C vs. Scheme semantics ] Where did I say anything about bridging incompatible semantics? How would this be useful? Please, that's just a complete straw man. I mean, I say I have a perfectly fine car and you say it doesn't fly you to the moon. Well, flying to the moon has never been in the requirements for a perfectly fine car. Once again, I was talking about "skins", like the different skins for Squeak-Smalltalk now showing. An XML-based encoding (marshalling) of parse-trees could serve as a skin-neutral storage format. And could probably be easily translated into (some) other OO languages as well. > > Anyway, look at SOAP for an example of *easy* interoperability. You > > can write SOAP commands using any old text editor, or even via > > direct telnet connection. That's very low overhead for trying > > something out and doing things in an ad-hoc way. > > Doing this has no support for any kind of input-side validity. Exactly! The point is that extremely light-weight or ad-hoc access is possible without all that overhead, while at the same time fully validated access is just as easy (or easier) than with the heavy-weight equivalents. [more of same snipped] > > Try the same with a > > CORBA ORB!! > > Why? I can do the same kind of thing from bsh or Tcl or Python when I want > to play around with CORBA interfaces. The responsibility for validity is > split between client and server. Compare the overhead of the two solutions: On the client side, a simple text editor or even just telnet, both of which are simply available vs. a whole programming language plus an integrated ORB, which has to implement IDL-parsing, IIOP parsing/generation and all the other services, none of which leverage common technologies but have to implemented just for CORBA! On the server side, you can hook up one of the many, many XML parsers available off the shelf and then just read out the DOM (or handle the SAX events), again compared to a full CORBA ORB with all the trappings and no common components. The point here is that the barriers to entry are just incredibly low. If you want to do something very simple, you can do so with very simple means. If you want to do something complex or highly secure, you need to spend more. But the people who want to do something simple should not be penalized because some people want to do something complex, and it would be good if both could use the same basic protocol, and they can. > > As for interoperability, the format is easy to > > parse/generate with just about any language/OS I can think of. > > It's only easy to generate if you don't care about correctness and > robustness. String manipulation is a truly awful basis for the core of > computation, and I'll even give you an example of how it loses: > http://www.cert.org/advisories/CA-2000-02.html XML parsers and generators are commonly available and easy to write. If you think XML-parsing should be done by regex-matching or strcmp(), you get what you deserve. The CERT advisory clearly only talks about incorrect servers, and you will note that my scenarious have been about easy, ad-hoc *client* access. Furthermore, the problem in the CERT advisory is really the insecurity of having script access enabled. If you have that turned on, you're wide open to attacks anyhow, the only difference with being that the audience you're wide open to has increased. Still I'll wager with you that a SOAP server requires a fraction of the code of a fully functioning CORBA ORB. (Not that I am a SOAP fan, but the general idea of encoding messages as XML has a lot of appeal and SOAP is one spec I am aware of). > Deeply, the problem is that generating HTML or XML is *not* about > concatenating strings together. Of course not, whowever said that it is? For programmatic access, you should build the (simple) libs that do it properly. However, you *can* reasonably build or edit a simple XML file in a text editor, which you can't reasonably do with various binary formats, and you can also *examine* XML files in a text editor. > Generating HTML or XML is about building > trees of elements and then marshalling them into ASCII. Yes of course. Where did I say anything different? I always groan when I see code that concatenates HTML/XML tags to strings in an ad-hoc fashion. My own XML-framework (for Objective-C) both has a proper parser and a generator, with the generator being a type of EncodingFilter. > OK, so maybe this is a straw man. Exactly! > You probably agree with me that real XML > and SOAP applications need a library or set of classes to > generate/parse/validate their data, since it's not strings. My point from the start is that it is *both* trees of semantically rich objects *and* strings, though one has to take care, because it is not simple strings. > But once you > have that library and code to it, the particular advantages of SOAP over > (say) CORBA doesn't look so one-sided. Yes it does. You get to leverage common components, the overall complexity is much lower, you get a human-readable (and debuggable), standardized interchange format/wire protocol, you get easy ad-hoc usage, etc. > Some of the magic binary bits are well-known and documented via OLE storage. AFAIK, the whole word file format is now documented (somewhere). That doesn't change the fact that writing custom binary-format parsers is going to be a lot more complex than (a) just opening the XML file in a text-editor and *looking* at it and/or (b) using one of dozens/hundreds of off-the-shelf XML tools with it. > > XML files can be self-describing: > > Yes, I agree, with a qualification: XML files *can* have self-describing > syntax. But you still have to understand what that syntax means. Yes, if the semantics are inherently complex or intentionally obscured, XML won't solve that, because, as I've explained before, that's outside of the domain of problems it is trying to solve. However, with XML you at least have a good chance of understanding what is there, assuming that the creator of the schema is not an adversary trying to confuse you. <Quantity>1</Quantity> vs (hex) fc00000001 or was that fc01000000? > > > > Furthermore, it combines the worlds of UNIX (everything is a text > > > > file) > > > > > > This is a strawman (I hope). If everything is a text file, why aren't > > > vi+pipelines the only applications I use to edit and view things? > > > > I think you misunderstood: the "everything is a text file" is an > > assumption that most of the UNIX tools are built around. It makes > > many powerful things possible, especially for *ad hoc* processing. > > However, it loses out on richer structures, for example those typical > > in OO systems. XML is a way of combining the two worlds. > > Again, only if you're willing to give up correctness, or do a lot more work > to try to patch around end cases. The right way to process objects is as > objects. The "right" way depends on your application and on the economics of the situation. For example, say you have two databases and you need to dump the contents of one into the other, once. They have schemas that are principally compatible but differ slightly. Now, you could (and it seems you argue one should) build complete class hierarchies modelling the schemas of the two databases, routines reading correct object-graphs out of one database (potentially running out of memory), transforming the object-graphs in memory (running out again) and then writing the resulting object graph to the other database. Or you could dump one DB out to XML-format (with an off-the-shelf tool), use an off-the-shelf generic XML-transformation tool that remaps the file purely syntactically (with your knowledge of the semantics controlling the syntactic transformations) and import the resulting XML-file into database two. Notice that I didn't say "use sed", because that won't work. > Purely syntactic queries are limited to identity queries, which aren't > terribly useful. Where do you get that idea? With an XML-aware tool, I could certainly do more, based on structure, context and values. The user of the tools can have knowledge (or make assumptions) about the semantics. > You can move up to queries based on string operations (is > this attribute value in the canonical Unicode sort order between "Carlson" > and "Weiher"?) but that's not much better. What would prevent me from doing queries based on structural or numerical relationships? Structural queries are even in the base XPointer, XML query languages such as Quilt support rich queries expanding on those available in SQL. ( see http://www.almaden.ibm.com/cs/people/chamberlin/quilt_euro.html) > IMO what XML provides now is three things: > > o A not-so-awful generic syntax o self describing, human readable, editable, robust > o that has a framework for discussing, documenting, and standardizing the > semantics, and o is usable *without* a machine encoded semantics o thus providing a low barrier to entry, just like HTML/HTTP o but scales to higher demands just as well > o A political atmosphere where information and service providers are > expected to do so. > XML hype is *good* as long as it's a tool to accomplish that last goal. But > we shouldn't forget that it's just one of many possible vehicles to get > this, and even with full documentation of formats there is a vast amount of > work in creating interoperation, which often starts with standardization on > models. Yes, in many cases that is the case, and it is happening. Just watch www.oasis.org to see industries scrambling to get their common vocabularies defined. But once again, it is possible to do partial, but correct, processing of files even when you don't know what half (or more) of it means. Marcel

1 0

A new default look for Squeak, revisited
by Henrik Gedenryd 02 Jul '00

02 Jul '00

A few days ago there was a call for us to come up with suggestions for a new defult look. For what it's worth, in the absence of others, I've included a couple of pictures of the look I have put together myself when I've been bored with my 'real' job, mostly to play around with translucency. There is not really any conscious design behind this, except to keep it simple, I guess. I don't like things that are flashy at first but become too much in the long run. I've included two images here that I've tried to keep small. One puts together most of the look's elements in a small space, so it looks rather messy to get it all into a small space. (And yes, it shows the general problem with tranlucency as well.) The other, really tiny one, shows what the 'window resizing dot' looks like, here I have placed the arrow on the line between two panes in a browser. (The dot is normally yellow.) I did it as an experiment with translucent gradients. I've placed a bigger, less cramped image on the web, which should give a better impression of what it actually looks like to work with (220k): http://www.lucs.lu.se/people/Henrik.Gedenryd/Squeak/bigedit.jpg A second one looks pretty much the same, but with more menus to illustrate how well the translucency works for text on text: http://www.lucs.lu.se/people/Henrik.Gedenryd/Squeak/largewmenu.jpg Speaking in general (and I'm not sure my ad hoc toying around is a good example of this), I think an interface should exploit the unique capabilities of Squeak, and not try to imitate something else (and imitations are only either bad, or at best similar to the original, which isn't very exciting anyway). Perhaps the translucency (& when combined with gradients) are examples of this. Oh, yeah, morphs & windows should be translucent when dragged--but I haven't quite figured the best way to do that yet. To digress a little, to improve also the quality (and not merely apply lipstick), Squeak should become more object- and less window/widget-oriented also in the interface, towards Direct Manipulation. Eg. today's menus are mostly merely lightly glorified typed commands--and in some confused arrangement, (help menu->preferences, projects in at lest 3 places, etc.) For instance, instead of a change set browser (two in fact) where you can see the sets, there should be change set morphs that _are_ the sets, and so on. But back to the issue at hand. If people would like this included in the distribution, I'll package it up as a change set. (It's quite simple in fact, to 95% some changed color parameters in various places.) The font is the only thing that can't be expected to work generally (yet), and (as usual) it is intended for LCD screens anyway. I can browse the X11 fonts et al and see what I find. Secondly, the window titles are an unrelated feature, which I nevertheless can include. They merely describe what's in the window (good when it's collapsed or partially covered) instead of writing "System Browser" etc. in five places on the screen. If you want that, I can include it as well. (I'll leave the close box on the left as well, it just ended up on the right at one point). Henrik

2 3

Apple fonts
by John M McIntosh 02 Jul '00

02 Jul '00

I've been watching the font issue with interest. I happen to know where one can get a set of windows fonts that are bit identical to Apple bitmapped fonts. Of course having created them 10 odd years ago helps. However they are the property of a previous business venture. These fonts are used by Informix, PowerBuilder (Sybase), and Blyth Software/Omnis, so they do have wide distribution. These fonts were created by hand from images of Apple fonts, and if I recall Apple's legal dept told us at the time that was legal as long as the font names were different and no Apple copyrighted algorithm were used to create the typeface. (Since of course you aren't deriving these images from truetype files that point is a non-issue). I could look into getting a licence for Squeak so to speak if there is interest. The issue of course will be getting the windows bit map font files into something Squeak will enjoy. Anyone done work with reading raw Windows bit font files? I guess I'll see if I can get a copy of the license agreement to see what the issues are, and if they are more acceptable than the current Squeak licence regarding the apple fonts. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================

2 1

[VM] SourceForge status
by Stephan Rudlof 02 Jul '00

02 Jul '00

VM-Hackers, what is the status of your SourceForge efforts? I have looked into http://sourceforge.net/projects/squeak/ and it seems to be *empty*. I have just made an improvement (not tested yet) for Tim's VM2.8 Linux port and would like to have the ability to - see the versions of other platforms, - post it there (after some testing, of course)... When do you think there is a first source tree? Who is/feels responsible to start with it? Possibly Tim's port would be a good start... Greetings, Stephan -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

4 4

Re: Ship it with Squeak
by Bob Arning 01 Jul '00

01 Jul '00

On Sat, 1 Jul 2000 14:21:33 -0400 (EDT) Bob Arning <arning(a)charm.net> wrote: >It would be easy to add attributes of TextFontReference to selected text in much the same manner that sizes and colors are done today. Well, here it is. It changes ParagraphEditor>>offerFontMenu (cmd-k) so that all availbale fonts are shown. Cheers, Bob ===== code follows ===== 'From Squeak2.9alpha of 13 June 2000 [latest update: #2440] on 1 July 2000 at 2:36:34 pm'! "Change Set: manyFonts Date: 1 July 2000 Author: Bob Arning Changes ParagraphEditor>>offerFontMenu to offer all known fonts as options for changing the font of the current selection."! !ParagraphEditor methodsFor: 'editing keys' stamp: 'RAA 7/1/2000 14:33'! offerFontMenu "Present a menu of available fonts/sizes, and if one is chosen, apply it to the current selection. Use ALL Fonts!! " | reply niceNames realFonts | niceNames _ OrderedCollection new. realFonts _ OrderedCollection new. StrikeFont familyNames do: [ :fam | (TextStyle named: fam) fontArray do: [ :sf | niceNames add: sf name withoutTrailingDigits, ' ', sf pointSize printString. realFonts add: sf. ] ]. reply _ (SelectionMenu labelList: niceNames selections: realFonts) startUp ifNil: [^self]. self replaceSelectionWith: ( Text string: self selection asString attribute: (TextFontReference toFont: reply) ) ! !

1 0

Jump to page: