Squeak-dev August 2003

squeak-dev@lists.squeakfoundation.org

171 participants
757 discussions

[FIX][3.6a] DeadServerFix-nk ( [update - 5361] )
by dway＠riskmetrics.com 04 Aug '03

04 Aug '03

< I'm a bug-fixing machine! > This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214 < I'm a bug-fixing machine! >

1 0

[FIX][3.6b] YALexiconDepFix-nk ( [update - 5360] )
by dway＠riskmetrics.com 04 Aug '03

04 Aug '03

1 0

[FIX] ProjectSubclassesOK-nk ( [update - 5359] )
by dway＠riskmetrics.com 04 Aug '03

04 Aug '03

1 0

[FIX] renameEuropeanMirror-bf ( [update - 5358] )
by dway＠riskmetrics.com 04 Aug '03

04 Aug '03

1 0

[FIX] ContextCleanupDebugFix ( [update - 5357] )
by dway＠riskmetrics.com 04 Aug '03

04 Aug '03

1 0

Update servers?
by Derek Brans 04 Aug '03

04 Aug '03

Trying to update my Squeak3.5-5180.image, I couldn't find any update servers. Derek Brans Nerd on a Wire Web design that's anything but square http://www.nerdonawire.com mailto: brans(a)nerdonawire.com phone: 604.874.6463 toll-free: 1-877-NERD-ON-A-WIRE

2 1

Re: [BUG] FileDIrectory>isAFileNamed: considered vile
by Richard A. O'Keefe 04 Aug '03

04 Aug '03

Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: I mean yuck. Blech. Testing for the existence of a file by trying to open it? OK, if one is utterly restricted to only the support guaranteed in a an ansi library maybe we can make an excuse. When I worked on the Quintus Prolog library I faced exactly this question. The answer turned out to be "distinguish and conquer". There are several *different* questions: (1) Does such-and-such a file exist? (Answers: yes, no, not allowed to tell you.) (2) Should I create such-and-such a file because it doesn't exist? (Answers: yes, no, not allowed to tell you, it doesn't exist but you are not allowed to create it.) (3) Would I be allowed to read such-and-such a file? (Answers: yes, no.) (4) If I tried to open such-and-such a file for input, would that work? (Answers: yes, no, can't tell for sure.) (5) When I try to open such-and-such a file for input, will that work? Given the range of operating systems we were trying to support (several flavours of UNIX, IBM MVS, IBM CMS, DEC VMS, Xerox Interlisp-D) there was in fact *no* portable method (Xerox Lisp machines didn't run C). But in all cases, even using undocumented interfaces, the only way to answer question (4) was to actually *try* to open the file. Of course, the question people were generally interested in was really (5), and we never could figure out a way to answer that question, even if question (4) was answered "yes". (Because another process might remove, rename, or change the protection on the file or one of its ancestral directories, or remove/dismount a (virtual) disc.) All the cases we were aware of where people asked question (1), they were tacitly assuming that the only answers were yes and no. They aren't. We did provide (1), (3), and (4); each required different code.

1 0

Re: Extending FileList with CrLf
by Richard A. O'Keefe 04 Aug '03

04 Aug '03

Daniel Vainsencher <danielv(a)netvision.net.il> quoted mention of the Python PEP for "Universal Newline Support" but wrote: Note that they implemented the library so it requires an explicit parameter for it to enter "universal" mode. That is exactly what I'm proposing we do. This is not what CLFS does. Note also what the PEP says in the very next paragraph: Universal newline support is also used when importing modules and when executing a file with the execfile() function. This means that Python modules can be shared between all three operating systems without needing to convert the line-endings. It's also worth reading the rational in the actual PEP itself. There are basically two problems: (1) backwards compatibility (not something Squeak is known for, so not an issue in this mailing list) (2) the low-level code in Python wasn't defined with this in mind, so there is too much code that does writing to C FILE* and cannot therefore be told to use "u" convention; this means that they can't figure out how to do "wu". This again is NOT a problem that Squeak faces. In short, none of the reasons for Python having "ru" explicit and no "r+u" or "au" or "wu" seem to apply to Squeak; we are free to do the right thing. One clear emphasis in the Python PEP is that they would like to have Python source code in a file system that can be mounted by operating systems with differeng end-of-line conventions and just have it work; the analogue for Squeak would at a minimum be having change sets "just work" whatever their end of line convention. Is it possible to reach agreement that change sets should "just work" no matter what end of line convention they use? This question can be separated from the issue of what happens when programmers open files themselves.

1 0

[BUG][FIX]FileDirectory>directoryExists: a bit silly
by tim＠sumeru.stanford.edu 04 Aug '03

04 Aug '03

Currently to see if a directory exists we do a crazy amount of work.. First we split the path name up and make theparent directory - which we send #exists to see if it exists. Then we enumerate all the entries in the parent and filter out the files to leave the directories which we then scan for one that matches the requisite name. Spotted the logical nonsense yet? Yup, note the #exists message; it checks for the existence of a directory by using a fast prim. Why not use the damned prim to check for the directory we actually want to check for? I did a trivial hack to try out the idea and it turns out to be 600 times faster on my machine! I doubt it will make such a difference on all platforms but I bet it will help on all of them. The revised code is :- ++++++++++++++ directoryExists: filenameOrPath "Answer true if a directory of the given name exists. The given name may be either a full path name or a local directory within this directory." "FileDirectory default directoryExists: FileDirectory default pathName" | fName dir | FileDirectory activeDirectoryClass splitName: filenameOrPath to: [:filePath :name | fName _ name. filePath isEmpty ifTrue: [dir _ self] ifFalse: [dir _ FileDirectory on: filePath]]. ^self isCaseSensitive ifTrue:[dir directoryNames includes: fName] ifFalse:[(dir directoryNamed: fName) exists]. +++++++ which is very simplitic but shows the effect. I _think_ that we can drop the whole isCaseSensitive bit. As I see it, if the OS is case sensitive you want the exact match in which case plain old (dir directoryNamed: fName) exists should be correct and if the OS is case insensitive then (dir directoryNamed: fName) exists will work as well. It seems ok on Mac & Acorn. I'm fairly sure that +++++++ directoryExists: filenameOrPath "Answer true if a directory of the given name exists. The given name may be either a full path name or a local directory within this directory." "FileDirectory default directoryExists: FileDirectory default pathName" ^(FileDirectory default directoryNamed: filenameOrPath ) exists ++++++++++++++ would actually be correct tim < I'm a bug-fixing machine! > This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214 < I'm a bug-fixing machine! >

1 0

Re: B3dSceneExplorerMorph not really deleted
by Bob Arning 03 Aug '03

03 Aug '03

On Sun, 3 Aug 2003 15:53:15 +0200 Martin Kuball <MartinKuball(a)web.de> wrote: >I tried the following in a 3.5 image on Linux: > B3DSceneExplorerMorph new openInWorld >After playing with it I deleted the morph using the x in it's halo. Than I >went to the trash and told it to erase it's content. Now every time I switch >to squeak from another window I see a black box of the size and at the >position of the B3DSceneExplorerMorph. How do I get ridd of it? Did you turn on hardware acceleration? If so, the simplest fix may be to reboot your computer, or at least quit squeak and start it again. Cheers, Bob

2 1

← Newer
1
...
68
69
70
71
72
73
74
75
76
Older →

Jump to page: