Squeak-dev February 2003

squeak-dev@lists.squeakfoundation.org

195 participants
766 discussions

[FIX] ClassCommentFix-nk
by Ned Konz 05 Oct '03

05 Oct '03

from preamble: "Change Set: ClassCommentFix-nk Date: 26 November 2002 Author: Ned Konz Version: 3.4a Changing class comments (and reverting them) caused walkbacks. "!

2 1

[FIX][DOC] Fix comment buglet in Dictionary>>valuesDo:
by David T. Lewis 02 Oct '03

02 Oct '03

This fixes the method comment for Dictionary>>valuesDo: which appears to have been incorrectly cut-n-pasted. Comment was: Evaluate aBlock for each of the receiver's keys. Changed to: Evaluate aBlock for each of the receiver's values. Dave

3 2

SqueakMap & monticello feature requests
by Stephen Pair 22 Sep '03

22 Sep '03

First, an easy one...I'd like the ability to browse the code of certain packages on SqueakMap (could just do the easy ones like change sets and *.st packages first)...it would be a little more difficult for SARs, but shouldn't be impossible. Now for a more elaborate request involving SqueakMap and Monticello...what I would like in Monticello is the ability to assign a version string to a package (but still have the auto-generated version numbers). Then I'd like the ability to directly export a package version to another repository. And, I possibly might want to be able to organize repositories in a hierachical fashion and have a "promote" capability that would simply export a package version to the "parent repository" in the hierarchy. The version string would enable me to correlate versions in multiple repositories (since the internal version number would not match up). Package versions would have to have a version string before they are allowed to be exported. Once a package has been exported to another repository, its version string would become immutable (in both repositories). Then, I'd like SqueakMap to be able to register a package that resides in a Monticello repository and have SqueakMap (server or client, whichever works best) be able to communicate with the repository to pull version information, etc for the package. This of course then implies that there needs to be some measure of security in Monticello that would allow read-only access but restrict update access. Why do I want these things? So that I can have a local repository on my laptop for my packages, have a shared private repository for projects that I'm working on with other people, and have a public respository for published projects accessible through SqueakMap. As I work, I'll create versions in my local repository. I'll occassionally publish versions to the shared repository, and when ready, I'll finally push versions out to the public repository. Perhaps a simply hierarchy of repositories would not be sufficient...instead, I might want to simply be able to "link" repositories (and name the repositories) and be able to "push" packages between them. The linking would serve no other purpose than to make it simple to "right click a package version, and 'push' it to one of a list of linked repositories". - Stephen

6 11

[MCP][ENH] self deprecate for crufty methods
by David T. Lewis 19 Jul '03

19 Jul '03

As part of MCP, there has been some discussion about cleaning out unnecessary methods in Morphic. Here is a way to mark methods for future removal. I'm sure this is not a new idea, but maybe it will help with the housekeeping. This change set adds Object>>deprecatedOn:by: to declare a method obsolete and provide a warning to any sender of the message to discourage use of the deprecated method. Send "self deprecatedOn: aDateString by: yourNameOrInitials" in the method being marked for future removal. Dave

3 2

RE: destructors, how?
by Peter Crowther 18 Jul '03

18 Jul '03

> From: Ragnar Hojland Espinosa [mailto:ragnar@linalco.com] > I want to automatically call self terminate on an object on > destruction (or when it goes out of scope..) Smalltalk objects are not 'destroyed'. They are garbage-collected at some time after no other object references them. The 'some time after' could be microseconds or days. > I can't find out how to write a destructor > or something functionally equivalent. Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object. - Peter

17 22

[FIX][Comanche] persistent connections
by Ian Piumarta 01 Apr '03

01 Apr '03

Comanche was not sending the correct 'Connection: {Keep-Alive,Close}' in the response header. The attached fix cures the problem allowing browsers that aggressively use persistent connections (e.g., Safari) to work without endless annoying "connection reset" errors. Ian

4 5

Can Morphic & eToys be improved by "The Humane Interface" cognitive psychology approach?
by Darius 22 Mar '03

22 Mar '03

As long as we're reviewing how approachable Morphic is for the novice... Here are some of Jef Raskin's ideas from his book "The Humane Interface" about applying cognitive psychology to make user computer interactions more efficient, consistent, and friendlier. http://humane.sourceforge.net/home/index.html ___ It seems to me that some of these are accomplished very well by Squeak and some could make the whole environment much more approachable for the naive. You can find this summary listed here: http://minnow.cc.gatech.edu/squeak/3026 and http://wiki.osafoundation.org/bin/view/Main/HumaneUserInterface Cheers, Darius ___ * Whole Purpose is to Create - Remember: The whole purpose for using a computer is to create (usually more information, more instructions, or a memory or experience in one's own mind) * Subconscious Finger Habits - Create, utilize, simplify, and support the user's subconscious typing and mouse movement habits. * Tool should Disappear from User's Attention - The use of the tool should disappear from the user's conscious awareness or attention. * Uninterrupted Concentration on Task - Only the tasks or the creation of content should be conscious in the user's awareness. This allows uninterrupted concentration on the task. * Capitalize on User Habituation - Make the habits that a user naturally forms when they interact with any interface work for them instead of against them. Capitalize on user habituation as much as possible. * Instant-On - User should be able to do work immediately without waiting for the computer to boot up. * Never Lose Anything - Never lose anything by accident. Eschew "Save" for "Unlimited Undo". * Never Interrupt the User's Attention - Never interrupt the user's attention/workflow unless absolutely necessary. If a user's decision can be delayed, allow them to attend to the error message when they are ready. * Never Move the Data Input Focus - Never move the data input focus or click focus unless the user requests it. (i.e. change menu entries just before user clicks on prior menu entry, or bring up a dialog box while user is typing so that they press enter on the dialog box rather than their text, or changing window focus while typing.) * Non-Modal - The entire user interface should be non-modal including the command set, the keyboard input, and the mouse button input. (Quasi-modes are OK.) * Data Entry at Any Place and Any Time - Allow the typing of a command or data entry at any place and any time. Allow the user to move the data to an appropriate place after creating it rather than always navigating first to the data entry field and then entering the data after that. * Easily Move Any Unit of Data - Easily move any unit of data, block of data, range of data, or data matching a criteria to any other physical storage place in the system or any other data type. * All Data Presented in a Searchable Liner Sequence - Represent all user-accessible data and user-created data in a searchable liner sequence. Most users think in terms of a serial sequence of data presentation rather than a matrix or multilink network of data representation. * Shortcuts to Quickly Search Forward or Backward - Ability to easily LEAP (r) forward or backward to any data block or any data type by an incremental, sequential search on content or data type label with auto-completion of the search field. * Unified Storage Structure - Only use "documents" for exchanging data with other systems or applications. Keep all data in a shared, indexed, unified storage structure, database, or image. * Multiple Selection of Data for a Single Command - Allow the simultaneous multiple highlighting/selection of items for the items to be operated on by a single command from the command line, key stroke, menu selection, etc.

5 14

Collection-Graphs ? (Graph-MathMorph, Connector, Arrow, T-Gen...)
by Samir Saidani 17 Mar '03

17 Mar '03

Hi I'm planning building a Collection-Graph, for my research (phD). I would like to know if there is such a functional Graph classes ? I know several implementations : - MathMorph (The GraphWrapper implementation seems not to work in 3.2, and http://mathmorphs.swiki.net/44 - GraphAlgorihtms.zip is unavailable :-() - Connector-Morph (It's not truly an implementation of Collection-Graph, but it can be use to display a Graph, with MorphicWrapper). - T-Gen implements a Collection-Graph too, but the implementation is oriented parsing... - Arrow implements a Graph, with a new and original manner, I have to see if it's possible to encapsulate the common abstraction of graphs (I mean nodes, edges...). Do you know others implementations ? Thanks at all ! -- Samir SAIDANI PhD in CS / Doctorant en informatique web : http://www.info.unicaen.fr/~saidani Universite de Caen - Laboratoire GREYC tel : 02-31-56-74-30 Equipe MAD - Campus II - 14032 Caen Cedex fax : 02-31-56-76-30

5 10

Re: Licences Question : Squeak-L Art 6.
by Hannes Hirzel 13 Mar '03

13 Mar '03

Jimmie Houchin <jhouchin(a)texoma.net> wrote: > Due to this I proposed in a different email approaching Apple with a BSD > type license. This covers their legal requirements while being a > reasonably understood and minimal license much in the spirit of the > Squeak community. > > Jimmie Houchin I second this proposal. Hannes Hirzel

5 5

Smalltalk Solutions: 2nd call for participation
by Alan Knight 12 Mar '03

12 Mar '03

Smalltalk Solutions is a primary venue for Smalltalk professionals, regardless of dialect, to meet and exchange ideas. This year's conference is taking place in Toronto, Canada, July 14-16 2003. The program committee is Vassili Bykov - Cincom Systems Eric Clayberg - Instantiations Steve Cline - Knowledge Systems Alan Knight - Cincom Systems Presentations involving Smalltalk technology, are requested in the areas of - Tutorials - Experience Reports - Technology Demonstrations - Technical Presentations The focus areas of this year's conference are business issues and internet applications. Presentations on these areas are particularly of interest, but submissions need not be limited to these topics. Presenters receive a free conference registration (one per presentation). Tutorial speakers will also receive a small stipend. To submit a proposal, please go to http://www.smalltalksolutions.com/participate/participate.htm Proposals should be received by March 15, 2003. -- Alan Knight [|], Program Chair, Smalltalk Solutions 2003 knight(a)acm.org http://www.smalltalksolutions.com

7 9

Jump to page: