Squeak-dev November 2002

squeak-dev@lists.squeakfoundation.org

189 participants
695 discussions

Re: [OT] Inquiring Minds want to know WAS: Re: Envy or Store or what?
by goran.hultgren＠bluefish.se 01 Nov '02

01 Nov '02

Hi richard and all you... others! : -) In-reply-to: <200210310149.g9V1nra4272387(a)atlas.otago.ac.nz> From: goran.hultgren(a)bluefish.se References: <200210310149.g9V1nra4272387(a)atlas.otago.ac.nz> To: squeak-dev(a)lists.squeakfoundation.org "Richard A. O'Keefe" <ok(a)cs.otago.ac.nz> wrote: > It has sort of always been a habit to put it in there. The point of it > is that since a PS appears below the signing this, as Patrik already > explained, clarifies that the PS was written by the same person. > > Postscripts are, as a rule, written by the same person who wrote the rest > of the letter/message. Why call out the (overwhelmingly) commonest case > for special treatment? It is postscripts written by someone _else_ that > need to be flagged. In printed material, it is customary to indicate I was just explaining why we Swedes add this DS thing - it has simply become customary in Swedish and obviously (after searching on Google) we tend to be unaware that this is not something you do in English. And again, the point is that the text is positioned below the signature so by appending DS noone else can "steal" it by signing it afterwards. Or something like that. It doesn't matter - it's just customary. > material written by someone else by putting their role [Ed] or their > initials [D.S., for example] there; so to me, putting "DS" at the end > of a postscript could only mean that the postscript was written by someone > with initials "DS" who HADN'T written the body of the message. > > In a message written in English, abbreviations other than English or > Latin ones are bound to confuse people rather than "clarify" anything. And I hope you realize that I do not argue that it should be used - I just used it because I thought that it was something you should do. When Patrik explained the "den samme" meaning I vaguely remembered it though. > Another thing - what kind of mailinglist greetings do you use? > > As a native speaker of English, I find "greetings" out of place in > messages sent to mailing lists. If one _must_ have such a thing, > what's wrong with "Dear readers" or "Dear Squeakers"? Ah. Interesting. Perhaps I will just dump the greetings then. [SNIP of long quite funny explanation of the word "guy"] > As a homebrewed variant I have been using "Hi all!" but it > limps a bit (might be a Swedish saying). :-) > > While pointless, it is at least inoffensive. :-) > After checking around it also seems that most people think it should be > "PPS" as in "post post scriptum". But somewhere I saw that it could mean > "post scriptum secundum". He. > > www.webster.com > "Etymology: New Latin 'post postscriptum'. > An additional postscript." > > Of course, in e-mail we are at liberty to fold our postscripts back into the > body of the text without tearing up any pages or re-penning anything... Right. But it does indicate an afterthought which in itself is information to the reader. Webster ought to be correct - then PPS it shall be. regards, Göran

3 2

RB and VI4 (was Re: [ANN] SqueakMap RC2 and SM Loader 0.96 out)
by danielv＠netvision.net.il 01 Nov '02

01 Nov '02

Hi Anthony, let me know if there's something in the RB that's being naughty and needs to change. Daniel Vainsencher Anthony Hannan <ajh18(a)cornell.edu> wrote: > "PhiHo Hoang" <phiho.hoang(a)rogers.com> wrote: > > No log file, no crash dump, no DNU, > > the Squeak window is even properly refreshed, > > the VM Preferences menus are still accessible. > > The progress bar for " Loading refactory into Changeset 'Refactory' " > > moves a little bit then sitting there. > > 'Alt- .' doesn't work, but , aha, the second try crashed Squeak. > > Now we have a crash dump. > > Hi PhiHo, > > Are you using the latest VI4 version dated Oct 27. I made a fix after > the first time you reported this problem. If it still doesn't work in > the latest version, let me know, and I will look at it. > > Cheers, > Anthony

1 0

Re: [BUG][DUMB USER] Refactoring Browser
by danielv＠netvision.net.il 01 Nov '02

01 Nov '02

Lex Spoon <lex(a)cc.gatech.edu> wrote: > danielv(a)netvision.net.il wrote: > > > About the naming dialog, actually, I'd like it to auto accept whatever > > is typed in the line above, and lock up the display line, so it can't be > > edited by mistake, but there's much I don't know about Morphic, and > > those two are part of it. I'd be glad to improve that, so if anyone has > > hints, snippets... > > > > > Yeah, this really bugs me as well. Unfortunately I don't see a real > easy way to solve it. > What is wanted, I believe, for accept/cancel to > work on the level of an entire dialogue, but right now it happens with > each input field individually. I usually solve this by having the > target of the "do it" button manually call #accept on all of the text > morphs before proceeding, but it's a very klunky solution. > > I guess a simple thing that would help a little is to make text morphs > auto-accept whenever they lose focus. I notice that this is how some of > the string-editors in the omni-user environment work. It should be > reasonable to add yet one more flag to PluggableTextMorph for this, and > to check for it in mouseLeave:. Thinking about it, this doesn't quite get the effect I am looking for - I wanted the display pane to be a sort of preview of what calls to the method are going to look like. So it should ideally update after every character change in the selector name, giving the user immidiate feedback on the legality and legibility of the selector... > Lex Daniel Vainsencher

1 0

[ANN]SqueakMap 1.0!
by goran.hultgren＠bluefish.se 01 Nov '02

01 Nov '02

Okidoki. It's out, no more release candidate stuff! If you haven't tried SqueakMap yet, read simple instructions to start using it on: http://minnow.cc.gatech.edu/squeak/2726 Reply to this post with any problems whatsoever. regards, Göran PS. Will release SqueakMap Browser as 1.0 today too. No big changes though.

1 2

RE: An uncomfortable question
by Swan, Dean 01 Nov '02

01 Nov '02

Goran, I didn't mean in any way to call your baby ugly, but it *IS* just a database with a user interface that makes it easy to do useful things, and from a USER point of view (as opposed to a package PUBLISHER or DEVELOPER) it is simply a tool for importing new code into a local image. That is what I mean by monolithic image based. The fact that SM supports multiple file formats is wonderful, but that really has nothing to do with the structure of the underlying source code. Unless I've missed something, once you use SM to import a package into an image, there is no easy way to "undo" this package addition. This is also consistent with the "monlithic image model". Please don't misunderstand. I'm not attemtping to criticize any any of the great work being done in Squeak. Microsoft, I am criticizing, but not Squeak or Squeak contributions. If anything I was trying to make the point that flexibility does not come for free, and that I prefer Dan Ingalls's original premise of "the simplest thing that could possibly work". -Dean -----Original Message----- From: goran.hultgren(a)bluefish.se [mailto:goran.hultgren@bluefish.se] Sent: Thursday, October 31, 2002 3:42 AM To: squeak-dev(a)lists.squeakfoundation.org Subject: RE: An uncomfortable question Hi all! "Swan, Dean" <Dean_Swan(a)Mitel.COM> wrote: [SNIP] > And regarding SqueakMap and DVS, realize that these are based on the monolithic image model. They are more or less fancy user interfaces to manage filing in the various change sets (I know I'm oversimplifying a bit, but the point is still valid). Well... No, I think you are oversimplifying a bit too much. SqueakMap is a distributed catalog of packages that can be installed into a Squeak image. It is already supporting different package formats: -.st, .cs, .st.gz, .cs.gz (Simple fileins as you mention) -.pr (Implemented but not released) -.sar (Neds new megaformat capable of anything, probably similar to debs, rpms) -.st DVS (Avi's DVS .st format which both can be filed in conventionally AND filed in using DVS thus making a package more or less upgradeable) My point here is that SM doesn't just handle changesets but any package format. And when the package formats evolve further we will start seeing new ways to deal with them - like a controlled upgrade for example. Or uninstall. I am not sure what you mean with "based on the monolithic image model" but IMHO SqueakMap together with DVS etc is changing this. As a small example, very soon Celeste can be cut out of the image and be published on SM - I think Daniel is itching to do that and we already have all the tools that it takes. In fact SM itself is probably (this is the current proposal) the very first package that is NOT going into the image! Yep, eating my own dogfood. For the curious this means that when SM hits the update stream for 3.2 (we are hopefully talking days now) it will actually only be a little bootstrap script going in - not SM itself. What does this mean in practice? It means that when you update 3.2 you will get a chance to install SM into it "by remote". As the user you will not see the difference but for us package developers it is a huge difference. The SM code that you now have in your image is NOT maintained using the regular update stream. It is maintained outside of the image. When I (being the maintainer of SM) integrate new fixes etc and decide to release a new version of SM I can do that independently and you will be able to upgrade (from within SM) SM itself when you decide to, also independently of other packages. In short, packages published in SM (including SM itself) have their own maintainers, their own "updatestreams" and their own place of storage on the net - so they are completely independent of the image. > Of course, monolithic systems have the issue of shared namespaces which can make it difficult to make different packages play nice together in the same image, so like I said, the problem is non-trivial. Yes, namespaces etc is cool and we will probably end up with it sometime. But we don't need to solve all problems at once - simple class name prefixes go a long way. SqueakMap does work pretty nicely already - and we all know things are missing but we are working on it. The next big step for SM will probably be versions of packages and handling dependencies (in some way - there are different ways to do it) between them. Before that though I want to wrap up the extensions sent to me from Ned and Avi, smack down on a few silly bugs and get 1.0 out the door. regards, Göran

2 1

Re: [ENH] Image Browser: for browsing code in the other .image file
by Steve Elkins 01 Nov '02

01 Nov '02

Another message that's really from Yoshiki. -- Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard

1 0

Best way to wrap fairly short text?
by Ross Boylan 01 Nov '02

01 Nov '02

I am using StringMorph (actually a subclass) to show what are usually brief titles for items. The problem is that sometimes they are not quite that brief, and they exceed the width of the container they are in. In this case I want the text to wrap around, with the morph growing vertically. I'm not sure if I prefer the wrap to break on spaces or not. Conceivably there might not be enough spaces for good breaks. Is there a way to get the StringMorph to do this? (Not that I see; there is a clipping option common to all Morphs, but I want to retain the text and wrap it). If not, what is the most appropriate replacement? TextMorph looks as if it can do this stuff, but it seems pretty heavy weight, and its ability to do more than plain text could be a headache for my app. Finally, the Morph actually needs to be a view on an underlying data model, and adapting TextMorph to behave that way might be delicate. Thanks for any pointers.

1 0

[Q]: is thre a multi-column tree list morph?
by Thierry Reignier 01 Nov '02

01 Nov '02

Hi, I have looked at the different GUI builder tools (CGUI, Prefab) but haven't found the complex Morph I need. I have looked at different Morph coming with the default 3.2 image but same there, haven't found the dreamed widget. (Tree List Widget: ObjectExplorer>>explorerFor: uses a SimpleHierarchicalListMorph. nice Multi column Widget: ArchiveViewer>>createWindow uses a PluggableListMorph and works better with a PluggableMultiColumnListMorph. Celeste class>>buildMorphicTocEntryListFor: uses a PluggableMultiColumnListMorphByItem. But why so many classes multicolumn morphs?) My question is: Is there a combination of both somewhere, ie a multi column tree list morph? Ideally a container morph with scrollbars if needed that can accepts column submorphs, one supporting tree functions (expand, collapse), and as many other simple independent column morphs as needed. A column morph would present one and only attribute of a model - not multiple as ArchiveViewer). Additionally with each column morph accepting a header and online manual resizing of column width. [Hoping for the best]: Hasn't someone built such a widget? Thierry _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Re: Modules, Segments & Versions - A Proposal (was: An uncomfortable question)
by Anthony Hannan 01 Nov '02

01 Nov '02

Anthony Hannan <ajh18(a)cornell.edu> wrote: > Each segment has different versions. However, each version must contain > the same roots (interface) so they are backwards and forward compatible. > Out-pointers specify which other segments they point to, but not which > version. The user determines which version to load. I overlooked the fact that different versions can have very different behavior, even if they have the same interface, and client segments will want to specify which version to use. So change the above to the following: Each segment is a version that must be compatible with its previous version (backward compatible), so it must have the same roots but may have more. Out-pointers of client segments specify the import segment needed and its version number. A configuration (aka image) is a set of compatible segment versions that work together. When loading segments you are loading into a specific configuration. When a higher version of an imported segment is required, it is allowed to replace the lower version as long as its on the same fork. If lower version is required the higher one stays as long as its on the same fork. If they are on different forks of the version tree then the load is aborted and the user is prompted to load into a new empty configuration. Every process runs under a specific configuration, when the VM runs a process that requires a different configuration, its segments are swapped in. Upon save, segments that have changed for the first time are written out as new versions. Segments that already have new versions are just rewritten. Segment versions can be rewritten like this until they are closed. And only closed segments can be copied and shared. Cheers, Anthony

1 0

Re: RB and VI4 (was Re: [ANN] SqueakMap RC2 and SM Loader 0.96 out)
by PhiHo Hoang 01 Nov '02

01 Nov '02

Hi Anthony, > Are you using the latest VI4 version dated Oct 27. I made a fix after > the first time you reported this problem. If it still doesn't work in > the latest version, let me know, and I will look at it. > Yes, I used that latest version to build MobVM. Actually, I just posted a Halloween Release to the list. Please try it and let me know what you think. MobVM now handles both image formats in one VM. Cheers, PhiHo.

1 0

Jump to page: