Squeak-dev August 2004

squeak-dev@lists.squeakfoundation.org

154 participants
394 discussions

[ENH][MVC] Deferred UI actions moved into Controller, plus ProcessBrowser fix
by David T. Lewis 04 Aug '04

04 Aug '04

This change set merges the functions of DeferredActionStandardSystemController into Controller. Class DeferredActionStandardSystemController is retained as an stub subclass in order to protect external packages that refer to it (e.g. CommandShell). It should be removed one release cycle after this change set is incorporated. For both MVC and Morphic, deferred UI messages can now be scheduled by: Project addDeferredUIMessage: something The ProcessBrowser has been updated to use this idiom. In addition, some changes are made to ProcessBrowser to permit clean image restart for an active ProcessBrowser with auto-update enabled. Implementation note: The deferred action queue is moved up to Controller rather than StandardSystemController so that scheduling of deferred UI actions works regardless of which controller is currently active. This is important when, for example, deferred actions are scheduled during system startup and a ScreenController is the active controller (ProcessBrowser may do this during startup). ProcessBrowser note: For simplicity, any active instances of ProcessBrowser will have their auto-update processes stopped prior to this update. After the update is complete, new instances of ProcessBrowser will be able to maintain auto-update following an image restart; however, the current instances will still lack this ability. Just open new ProcessBrowsers and all should be well. Both the DeferredActionSystemController and ProcessBrowser are created by Ned Konz. This change set adds no new functionality except as described above. Dave

2 1

[FIX] DecompileAnonymousMethodFix-nk ( [er] looks good )
by karl.ramberg＠chello.se 04 Aug '04

04 Aug '04

1 0

[FIX] TextMorphBuglet
by bparsia＠email.unc.edu 04 Aug '04

04 Aug '04

from preamble: "Change Set: TextMorphBuglet Date: 1 December 2003 Author: Bijan Parsia Another in a series of microfixes. This showed up when using the codeProvenance button to toggle colorPrinting from prettyPrinting. Since the actually characters didn't change, the display wouldn't update until you went to another method, or cycled through some other display mode. This fix follows the advice in Text>>=. I expect it'll slow somethings down, especially for complex texts (e.g., with embedded morphs). It may be better to change how this test logic works, but now, at least, the behavior is correct."!

2 1

[ENH] UsableSiblingInstanceFix-nk
by Ned Konz 04 Aug '04

04 Aug '04

from preamble: "Change Set: UsableSiblingInstanceFix-nk Date: 11 October 2003 Author: Ned Konz Morph>>usableSiblingInstance was always adding the created sibling to the World, even though many of its callers would turn around and immediately add the result to other morphs or delete them from the World. This change set makes #usableSiblingInstance not add the newly created Morph to the World. This makes several uses of #usableSiblingInstance more bug-free and efficient. "!

2 1

[BUG][FIX] Morphic: File Selection Dialog [was MVC: File Selectio n Dialog]
by Magistrello Alejandro (SFA) 04 Aug '04

04 Aug '04

>De: Boris Gaertner [SMTP:Boris.Gaertner@gmx.net] >Asunto: Re: [BUG][FIX] MVC: File Selection Dialog (shows another bug) > >I tried to execute > (PluggableFileList oldFileMenu: (FileDirectory on: 'c:\windows\fonts')) > startUpWithCaption: 'Select a File, please:' >in a Mrophic project and receive a strange effect, that I cannot quickly >fix: >I put that statement into a workspace that I place more or less centered >on the screen. When I execute the statement, the selection dialog is >displayed above the workspace. This looks good, but as soon as a >call up one of the menues of the dialog, the selected text of the workspace >comes into the foreground. >I think that in PluggableFileList>>open one should have something like > Smalltalk isMorphic > ifTrue: [<...>] > ifFalse: [<...>] > >I tried to do that, the result can be found in MorphicFSD.1.cs <<MorphicFSD.1.cs>> >In SystemWindow>>update: I added a reaction to the >message #close. >In PluggableFileList>>openAsMorphLasbel:inWorld: >I added an event loop. The condition of the loop uses the >fact that the model of a SystemWindow is niled when the >window is deleted. >I am not very experienced user of the Morphic interface, >so comments are highly wellcome. > > >Greetings, >Boris > if you use the closeButton you'll get a walkback. btw, this is pretty similar to FileList2 modalFileSelector regards, Alejandro

2 1

RE: [BUG][BFAV][m17n]Attachments download
by Frank Shearar 04 Aug '04

04 Aug '04

Karl Ramberg wrote: > > Frank Shearar wrote: > > > > > -----Original Message----- > > > From: Karl Ramberg [mailto:karl.ramberg@chello.se] > > > Sent: 30 July 2004 11:53 > > > To: Squeak > > > Subject: [BUG][BFAV][m17n]Attachments download > > > > > > > > > Attachments downloaded with BAFV when m17n is installed > are corrupted. > > > > Does this happen because of the encoding issues in the m17n > stuff reported by others? That Latin1/UTF-8 discussion of last week? > > > I'm not sure where and how it happens. Emails appear nicely > in the email > pane of > BFAV. Files/ Attachments with the right filename are made and put in > the right > folder. But they are not gzip files. > I don't understand the BFAV model and how it pulls down stuff from the > server etc. > so it's hard to be more specific. > How are stuff stored on and downloaded from the BFAV server? BFAV just stores the attachments as-is - when you download the post (say post 20254) it puts the attachment in (for example) C:\Program Files\Squeak-3.2.2\email-file-repository\bfav.squeakfoundation.org\emails\20254-attachments which contains FixCorrectSelector-fbs.cs.gz Do these files contain non-gzip data? > Maybe it's the decompression after it's downloaded from the BFAV server that do this. I suspect unzipping of the attachment within the Squeak image corrupts the stream. I think you can verify this if you check the attachment on the file system. If that contains a corrupted attachement then I think we can say that BFAV corrupted the attachment. If BFAV saved the attachment on disk uncorrupted, but displays corrupted attachements in, say, a DecentReviewerNotePad, then I'd suspect the m17n stuff of corrupting the stream. That might well happen simply because BFAV doesn't set the right encoder - if I remember the m17n discussion correctly the default encoder uses UTF-8 but you can set it to something with a 1-1 mapping (like Latin1). frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

2 2

Re: new m17n built
by Hannes Hirzel 04 Aug '04

04 Aug '04

Hello Yoshiki Ohshima wrote: > Alex, > > >>TTCFontReader encodingTag: Latin1Environment leadingChar. >>TTCFontSet newTextStyleFromTTFile: 'C:\WINDOWS\Fonts\arial.TTF'. >>s := (MultiCharacter leadingChar: 1 code: 16r107) asString. >>Display getCanvas drawString: s at: 120@120 font:((TextStyle named: 'MultiArial') fontOfSize: 36) color: Color black. >> >>Now that's fun! HOORAY! :) > > > encoding tag "1" is reserved for backward compatibility for old > version of Japanese Squeak. The right thing is to have one entry in > fontArray of TTCFontSet for Arial for now (until Arabic or Russian is > officially supported) and create a character with > > MultiCharacter leadingChar: 0 code: 16r107. > > (#leadingChar:code: should be at Character.) I filed in the huge m17n release of today http://impara.de/drop/m17n/install-m17n-503.zip and I tried the same thing with the font 'Lucida Sans Unicode' and it worked successfully as well ;-) TTCFontReader encodingTag: Latin1Environment leadingChar. TTCFontSet newTextStyleFromTTFile: 'C:\WINDOWS\Fonts\L_10646.TTF'. s := (MultiCharacter leadingChar: 1 code: 16r107) asString. Display getCanvas drawString: s at: 240@120 font:((TextStyle named: 'MultiLucidaSansUnicode') fontOfSize: 36) color: Color black. Then I tried to do a character map Display restoreAfter: [strFnt _ (TextConstants at: #MultiLucidaSansUnicode) fontOfSize: 30. f _ Form extent: 500@900. 0 to: 16r2A do: [:i | i hex displayOn: f at: 10@(20*i). 0 to: 16rF do: [:j | ccode _ 16*i+j . s_(MultiCharacter leadingChar:1 code: ccode) asString. f getCanvas drawString: s at: ((20*j+50)@(20*i)) font: strFnt color: Color black] ]. f displayAt: 20@40. GIFReadWriter putForm: f onFileNamed: 'chartable.gif']. The character map did show the characters correctly but they are not nicely drawn. I am using the VM "3.6.1. Tea 1.9 VM (release) Nov 2 2003" Is there a newer VM with a different font plugin I should use? And I have the impression that the font size is not correct as well. Thank you, Yoshiki and Michael for your work. This is great that Unicode now gets included in Squeak 3.8a. Hannes

1 0

String>>asInteger does not like negative integers
by Nevin Pratt 04 Aug '04

04 Aug '04

Anybody have any insight on why String>>asInteger doesn't seem to think negative integers are really integers? It is "fixable" with #asNumber, as follows: '-1' asInteger --> 1 '-1' asNumber asInteger --> -1 Shouldn't String>>asInteger be smarter than that, and not ignore negative integers? This behavior is verified on 3.5, 3.6, and 3.7. So, it's been around for awhile. Nevin

2 2

[UPDATES] 5 for Squeak3.7gamma
by dway＠mailcan.com 04 Aug '04

04 Aug '04

These are the last updates before I put out a gamma candidate image tomorrow. A couple of important fixes from Ned, and some pre-release related updates from me. One of these tweaks the window titlebar font to be non-bold if it is a TrueType font, since all of the TT fonts are considerably thicker/wider than the non TT fonts... way too wide when bold, as people have complained. (We could revert this in the future if we come across some good skinny TT fonts.) To create the gamma candidate, I'll execute the new SmalltalkImage>>prepareReleaseImage method, which performs various cleanups. (Be sure to look at this method to see if I've left anything out or done anything harmful. There's a bit of redundancy in there but that should be okay.) Then I'll run a script to regenerate the window titlebars to clean those up. I'll also add a "New in 3.7" section to the Welcome window, summarizing the new features in 3.7. That will be it for 3.7-basic. Full is still a bit up in the air as to what the image will look like, but if all else fails we can just load in the Full packages which are working and call it Full. In SmalltalkImage>>prepareReleaseImage, these were the only possibly questionable things which I left in from the longer scripts which Michael had created: ScriptingSystem deletePrivateGraphics. "?" References keys do:[:k| References removeKey: k]. "?" Smalltalk forgetDoIts. "?" Smalltalk flushClassNameCache. "?" There could still possibly be an update or two for gamma after the candidate is released, but hopefully there will be none. We could shoot for this weekend for 3.7 final if things look okay. - Doug ------------------------------ 5979NewParagraphComposeFix-nk -- Ned Konz -- 23 June 2004 We have had the problem in the past with broken text morphs being distributed in the image. This change set adds a guard in NewParagraph to avoid the problems caused by the (uncommon) case of a paragraph with inconsistent state. 5980TTCFontSizeRepair-nk -- Ned Konz -- 18 July 2004 The changes to the TTCFonts done in CS 5923PSPointSizeFix-nk didn't clear out the derivative fonts cache. This left some fonts with a discrepancy between the size of the regular and bold derivatives. Where this is noticeable is where you had a default font (perhaps the window title font or the etoys font) set to a TTCFont (like ComicSansMS). This CS forces the TTCFonts with bad derivative sizes to rebuild themselves. This fixes a problem with the distribution image and also makes the old windows look better. It cures the problem that we've seen with bad flap and window title bar layout with some TTCFonts. Then it does what it can to update all the users of those fonts. As a side effect, it updates the buttons of old windows like the ones in the distribution image. It also fixes AbstractFont>>textStyle to always answer a TextStyle, even if we have to create a new one. This avoids problems with some users of #textStyle. 5981UndeclaredCleanup-dew -- Doug Way -- 22 July 2004 Delete 4 unused methods which reference nonexistent instance variables. (They would have been removed already except that the SM installer depended on Monticello (which is not part of the basic image yet in 3.7) to correctly delete old methods.)" 5982SysWinInitLabelArea-dew -- Doug Way -- 29 July 2004 Simple cut & paste refactoring which splits out an initializeLabelArea method called from SystemWindow>>initialze. This makes regenerating label areas (titlebars) on existing windows (e.g. for the gamma image preparation) doable. Also fixes centering of label in the titlebar, and only uses bold with non-TT fonts for the window title (since the bold TT fonts are quite a bit thicker/wider than bold strikefonts)." 5983PrepareReleaseImage-dew -- Doug Way -- 1 August 2004 Adds SmalltalkImage>>prepareReleaseImage which can be executed to perform various cleanups in preparation for a gamma candidate release image." <This automated message brought to you by the UpdateIncorporationTool.> <See the UpdateIncorporationTool package on SqueakMap for details.>

3 2

Re: Questions on Squeak's threading architecture -- why can't Squeak do SMP yet?
by lex＠cc.gatech.edu 04 Aug '04

04 Aug '04

Two quick answers. If you are happy with separate memories and message passing, then you can use good old fork() and pipes. Look at the OSProcess package for details. If you want it to work with shared memory, then I don't think anyone is working on that in Squeak. It could be done if you want to invest some engineering into it. The main thing that is missing is a thread-safe object memory. > Of course, locks are necessary around structures whose shared > memory components may be in flux when another object tries to > interrogate it. But Squeak's message-passed requests are more polite > than conventional function calls to object methods, and this can > facilitate a more polite "be with you in a few microseconds" response if > something is locked than a simple fail. Of course, not all classes and > methods and SqueakVM threads are suitable for forking into OS and > processor threads. Those that are or aren't can be tagged with one bit > (maybe call it "isSMPThreadable"). In practice, it is VERY hard to achieve proper locking for shared memory threading, even in tiny programs. So don't go down that path without a good reason -- after all, do you care how fast the answer is computed if it may have been garbled? Polite message passing is much easier to get right. -Lex

1 0

← Newer
1
...
32
33
34
35
36
37
38
39
40
Older →

Jump to page: