Squeak-dev July 2003

squeak-dev@lists.squeakfoundation.org

187 participants
961 discussions

RE: Large Collections (was: [ENH] WeakIdentityDictionary hashing)
by Brent Vukmer 01 Jul '03

01 Jul '03

> > I'd like to take this opportunity to remind people of the > LargeCollections package on SqueakMap. It is a minor > refactoring of the growth related aspects of the collection framework along with > a couple new types of collections. It is designed to aid in working > with large collections (particularly the case where those large > collections start > to noticeably impact the performance of incremental GC). Stephen, this sounds cool. I think that "Large Collections" along with "Large Lists" should definitely be considered for inclusion in the 3.7 release plan, if someone steps up to sponsor them.

1 0

Dependents and Morphs question
by Roel Wuyts 01 Jul '03

01 Jul '03

Hi all, I am browsing a bit through Squeak code, and encountered the following thing which surprised me... Quite some code (for browsers for example) makes dependents of morphs. But since a Morph is not a Model, these dependents are all kept in the DependentFields class variable on Object. My question is simply: why is Morph not a Model? PS: Note that I was thinking that quite a lot of dependents would be in DependentsField, so I inspected it. Turned out that there were only a couple, so this might be the answer to my question... Since I had quite a number of browsers open, I thought there would be many more. -- Roel Wuyts Software Composition Group roel.wuyts(a)iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org

2 1

RE: [BUG]Scampler-Posting, Authentication, Infinite Loop
by Brent Vukmer 01 Jul '03

01 Jul '03

[snip] > > Note that HTTPSocket is going away - since mir's Network > rewrite, the proper way to implement protocols is to use > Clients. So a better direction might be to help implement the > HTTPClient for the new framework in a way that can be > controlled so that the problem you describe doesn't happen. > > I'm not sure whether Michael still intends to implement > HTTPClient on his own [snip] FYI, I asked Michael about this a few days ago; he said: "I took [HTTP migration to network rewrite] out as too many modifications and innovations are happening in Comanche and Seaside in that area. And it won't really help to just rewrite the HTTPSocket. The URI package came out of the initial attempt to rewrite the HTTP related stuff."

1 0

Re: [BUG]Scampler-Posting, Authentication, Infinite Loop
by Daniel Vainsencher 01 Jul '03

01 Jul '03

Note that HTTPSocket is going away - since mir's Network rewrite, the proper way to implement protocols is to use Clients. So a better direction might be to help implement the HTTPClient for the new framework in a way that can be controlled so that the problem you describe doesn't happen. I'm not sure whether Michael still intends to implement HTTPClient on his own, in which case you can help by testing and reviewing, or not, in which case you might want to start an implementation effort yourself. If you do, a good place to start is reading the HTTP 1.0/1.1 standards, and the existing HTTPSocket, and trying to implement something that covers the same ground as the HTTPSocket, but that passes unit tests based on the standard. Note, BTW, that Squeak already contains an HTTPClient class, but it is something else, that will probably be renamed to keep things consistent with the new naming scheme. Daniel Umur at Writeme <umur(a)writeme.com> wrote: > Scenario is as follows: > 1. You post a form (.e.g. to Swiki, etc.). > 2. The form is successfully processed. > 3) The result you get is a redirection to another page which has a > different authentication (or you prefer to reauthenticate instead of > keeping the pass around). > The problem becomes as follows: > 1) At this point HTTPSocket does the redirection internally. > 2) HTTPSocket now returns the content after redirection. This content is > "Authorization Failed". > 3) Now, HttpUrl object gets this content and applies > checkAuthentication:retry: to it. > 4) As there is a failure, HttpUrl reposts the orginal form. > 5) If the post action does not fail for another reason this reposting > goes on infinitely. > > For example, you can try to create a new swiki book using scamper. > Fortunately you, as swiki does not allow you to create the same book > twice, you will break out of this loop with a failure: "This name > already exists". > > I could not come up with an easy solution as it is involving more than > one heavily used class. > > Note: In order to attempt form posting sensibly, you need to first > fileIn the changeSet included in topic "[FIX] Scamper-Form Submit-umur > ([sm][cd][et])" > > Umur

1 0

Re: KCP 64-90 - comments, questions and approvals
by Daniel Vainsencher 01 Jul '03

01 Jul '03

Yup, that's the way to go. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > On Thursday, June 26, 2003, at 10:01 AM, Daniel Vainsencher wrote: > > > Doug, KCP doesn't show up in BFAV yet, hence this heads up. This > > approves almost all the outstanding KCP stuff. > > > > To business - I really like the way the new deprecation system works > > out. People deprecating all sorts of protocols should really be using > > this. Of course for every deprecation we do, eventually, we'll have to > > remove the deprecated code - maybe we should do this at the beginning > > of > > each alpha? > > That sounds right. We can simply check for all senders of the > deprecatedExplanation/deprecated:explanation: and then delete those > methods. > > > ... > > One place where I think things should be done differently (we talked > > about this before -) 64. > > > > Everything else, that is, 67, 68, 69, 70, 71, 76, 78, 83, 84, 85, 87, > > 88, 90 - approved. > > So is this a reasonable stopping point? If so, I can go ahead and > incorporate these. (excluding 64 for now) > > Here's the list if anyone else is curious (see > http://minnow.cc.gatech.edu/squeak/3257 ) > > KCP-0090-SpaceTally.cs > KCP-0088-FixChangeSet.cs > KCP-0087-MovefullScreenModeToDisplayScreen.cs > For the changes 85 and 84. You will prompted to know if SystemChanges > shouldmarked as undeclared. Then one deprecated method will be > executed: this is normal because the changeset is changing the exact > method that is loading the changesets. So just proceed. > KCP-0085-MoveToChangeSet.cs > KCP-0084-ChangeSetCurrentFixed.cs > KCP-0083-NewBeepENG.cs > KCP-0078-fixDeprecationMechanism.cs > KCP-0076-ValidateSubclassFormatFix.cs > KCP-0071-mvDefaultSelectorForMethod.cs > KCP-0070-FixSmalltalkReferenceInBrowser.cs > KCP-0069-FixChangeSorter.cs > KCP-0068-Imports.cs > KCP-0067-beep.cs > KCP-0064-PictReaderClass.cs > > - Doug Way

1 0

[KCP] SystemChangeNotification: first blurb
by Roel Wuyts 01 Jul '03

01 Jul '03

Hello, Attached a first blurb regarding the system change notification. More info is in the preamble. PS: I attached it to this mail since it is less then 4 kb. Hope it doesn't bother anybody... -- Roel Wuyts Software Composition Group roel.wuyts(a)iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org

2 2

Another problem with the current fileout format
by Stephane Ducasse 01 Jul '03

01 Jul '03

Hi I just want to report the difficulties we experienced with alex when he built a tool to split changesets in part. Our problem was that we had 3.5 complaint changeset and that we wanted to load them in 3.6alpha in which class had been removed in parallel. So alex built a splitter that given a set of removals and a changeset generates a new changeset and a set of changesets for each of the removals. So perfect. Now the problem is that a lot of information in the file is done by side effect or do-its: they act as holes in the analysis. So it would be better to have explicit representation in the file out for those things. For example having objects on top of which we could build real tools. Note that the examples below are not right I just want to give the idea: RenamedCategory on: #MyClass from: #myOldComment to: #myNewComment RenamedClass oldClassNamed: #MyOldClassName newClass: #MyCoolNewClassName vs. 'Smalltalk renamedClass: MyOldClassName into: MyCoolNewClassName' RemoveClass classNamed: #MyOldClassName vs. 'Smalltalk removeClassNamed: #MyOldClassName' With the current version we have to interpret the string to get a meaning, with the solution you get an object you can manipulate. This kind of explicit representation would work well for class definition, Pool Definition, Class initialization too this means that we could load code without executing it and this would support all kinds of cool tools. Note that this was one of the idea behind the file format of Ginsu. Does anybody got the same problem? I guess that les got that too when working on his analysis tool. Avi how do you manage these annoying string in CVS? Just as string I imagine but this means that we cannot really do too much. Stef

6 9

KCP 64-90 - comments, questions and approvals
by Daniel Vainsencher 01 Jul '03

01 Jul '03

Doug, KCP doesn't show up in BFAV yet, hence this heads up. This approves almost all the outstanding KCP stuff. To business - I really like the way the new deprecation system works out. People deprecating all sorts of protocols should really be using this. Of course for every deprecation we do, eventually, we'll have to remove the deprecated code - maybe we should do this at the beginning of each alpha? A small deployment question - I got a deprecation wb at 84, proceeded, and all was fine. This cause me to think something that somewhat related to the above - maybe we should have a preference to decide whether deprecation should be active or not, and set it to false when we want it to work quietly? this could be used to solve this small annoyance, but even better, we could set to off in released images, and to on in alpha/beta/gamma images. This would hide ugliness from end users, but not from the rest of us. What do you think? BTW, why did you add the *Deprecated methods? A note about my review - I didn't check all the code, I only understood the design idea and sampled the implementation to get a taste. IOW, I think we have this process pretty well optimized, and it's not taking me a long time. So we can run with this as quick as the KCP team wants, and I wont mind doing the approvals more frequently, if you tell me when you have a logical part completed. One place where I think things should be done differently (we talked about this before -) 64. The way HTTPSocket is changed makes the dependency on GifReadWriter dynamic/hidden from analysis, but the methods are still ineffective when the media handling classes are missing. I think those are exactly the case where a class extension would be better - if the media code is removed, so should the methods that depend on it. I'm less sure about Form, maybe its media sampling code should be extracted to some ImageReaderWriter too? Everything else, that is, 67, 68, 69, 70, 71, 76, 78, 83, 84, 85, 87, 88, 90 - approved. Daniel

3 2

[ANN] BugFixArchiveViewer 1.23 on SqueakMap
by bvukmer＠blackboard.com 01 Jul '03

01 Jul '03

Check it out! Ned provided these great fixes and enhancements: - enabled load-updates as a background process - enabled keeping the various local archives around in memory until all BFAV windows are closed - enabled keeping an archive around indefinitely by opening a Keeper morph from the tiny-menu - added toggle for groups/individual-posts list view - improved appearance and resizing of text fields pane - added support for sorting the archive in different ways (not in menu yet) - removed Undeclared refs And I put in a few fixes and enhancements: - The BFAV now automatically does a sanity check for gaps in the lists of posts in the local archive, and attempts to load the missing posts, every time that it loads updates. - There is also a new tiny-menu option called "validate local archive" that kicks off the same process. - The "reload post" bug should be fixed with this release. - There were a number of minor enhancements for the KCP archive viewer unfortunately the sanity check for gaps is still a little buggy. - There are new Harvester-friendly mouse menu options for viewing: * unreviewed contributions * reviewed contributions that are not yet approved * approved contributions that are not yet in the update stream There is some cool new functionality in this release, thanks to Ned, Daniel , Tim, Alejandro and Doug for code, testing, bug reports and helpful feedback. < 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

[ENH] BFAVAsyncAndOther-nk ( [closed] rolled into latest release )
by bvukmer＠blackboard.com 01 Jul '03

01 Jul '03

See release 1.23 ( coming soon to a SqueakMap near you... ) < 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

Jump to page: