Squeak-dev July 2003

squeak-dev@lists.squeakfoundation.org

187 participants
961 discussions

RE: Jabber question/remote pair programming...
by Daniel Vainsencher 01 Jul '03

01 Jul '03

I think it can be an interesting basis for the way to interact with a versioning system - * You get automatic updates about changes anyone (or interesting parties) make to any code (or just specific packages). * The way the versioning system gets its information is that it is simply another player in this game - getting updates from everyone that's working - except that instead of displaying something, it would simply save the state of each session it is connected to. So each session is recorded as a diff against a known version on the server. There is still a question of what the basis should be - the pristine version of Squeak at that update level + those packages? BTW, of course we'd need some client flexibility to allow one to control what and when is published. Not all code should be recorded publically. Daniel Avi Bryant <avi(a)beta4.com> wrote: > Yes, I think the proposed JabberingBrowser and Hydra are in a similar > space - I don't necessarily need to see everyone's text selection like in > Hydra, but I'd like to be able to open a browser that tracks which > class/method someone else is looking at, and updates my code every time > they accept. > > Somehow it seems like this could be the basis for a versioning system, but > I'm fuzzy on exactly how it would work... > > Avi

2 1

XML-RPC package-version dependencies?
by Brent Vukmer 01 Jul '03

01 Jul '03

I see that the XMLRPC package depends on: - YAXO - Spy-XML-RPC ( http://bleu.west.spy.net/~dustin/projects/smalltalk-xmlrpc.xtp ) - Comanche Does the XMLRPC package work with the latest versions of YAXO and Comanche? What versions of these packages are required?

2 1

[FIX] TTCFontFixes-nk
by Ned Konz 01 Jul '03

01 Jul '03

This merges: Yoshiki Ohshima's TrueTypeTextStyle version 5 from SqueakMap TrueTypeTextStyle version 6 beta and Tom Blanchard's VeraTTFCompatibility.2.cs additions. It can be safely loaded into a image with version 5 loaded, or into a virgin image. It should also do the right thing when loading old instances in projects. DO NOT load Tom's BitstreamVera SAR on top of this, since it will break things. -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

8 18

[Q] Browser-Model interaction wrt stepping
by Brian Brown 01 Jul '03

01 Jul '03

Hi all! I've got a subclass of PackagePaneBrowser, which is the model in a SystemWindow... I would like to the stepping mechanism in that SystemWindow send a message to the model, but I can't override the methods in SystemWindow, as I am a derived from Model, not SystemWindow (which is from MorphicModel...) Any thoughts? thanks! Brian

2 2

playing with Nebraska
by Lex Spoon 01 Jul '03

01 Jul '03

Here are some things you can glue together, once you have the efficient remote interaction Nebraska gives you. 1. You can give people flaps that live on the local machine, and let them drag and drop things into and out of the shared world. 2. Conversely, you can swap modes and have the shared stuff be in a flap, for times when you are primarily working locally but want to have a collaboration window available. 3. You can have a large shared world that is scrollable, like the original Kansas (in fact, the reason Kansas got its name). This way multiple people can really bump elbows. :) 4. You could set it up to display only, and thus have a very efficient format for Squeak movies or Squeak streaming presentations. There are also other nice things that could be done: 1. NetworkTerminalMorph should have a border, so that you can interact with it on the client. 2. The password-handling code I posted a while ago should be integrated into the main system. Have a blast! Nebraska is just one of a load of components in Squeak that you can combine in lots of interesting ways. A little bit of programming can take you a long way, if you are programming in Squeak. Lex

2 1

Omnibase forgetAllGrabcommandsFrom: problem
by Derek Brans 01 Jul '03

01 Jul '03

CommandHistory class>>forgetAllGrabCommandsFrom: This method gets executed when saving and quitting the image. The method seems to enumerate a whole bunch of objects in the image, starting at nil. It eventually gets to an ODBObjectID and then locks up, waiting for some semaphore. This is where I find the thread when I interrupt: June 30, 2003 15:45 VM: Win32 - Squeak3.4 of 1 March 2003 [latest update: #5170] Image: Squeak3.5 [latest update: #5180] Semaphore>>critical: Receiver: a Semaphore() Arguments and temporary variables: mutuallyExcludedBlock: [] in ODBFileStream>>atPosition:getBytesFor:len: blockValue: nil Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 0 ODBFileStream>>atPosition:getBytesFor:len: Receiver: ODBFileStream on: 'C:\Documents and Settings\brans\My Documents\Document Directory\Project...etc... Arguments and temporary variables: anInteger: 288 aByteCollection: a ByteArray(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) len: 16 Receiver's instance variables: position: 160 fileHandle: StandardFileStream: 'C:\Documents and Settings\brans\My Documents\D...etc... pathName: 'C:\Documents and Settings\brans\My Documents\Document Directory\Proj...etc... seekingMutex: a Semaphore() ODBObjectIndexFile>>at: Receiver: an ODBObjectIndexFile Arguments and temporary variables: anInteger: 10 bytes: a ByteArray(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) Receiver's instance variables: stream: ODBFileStream on: 'C:\Documents and Settings\brans\My Documents\Documen...etc... valueLength: 16 pageSize: nil start: 144 gcPosition: nil gcBuffer: nil gcCount: nil var1: nil ODBContainer>>at: Receiver: an ODBContainer Arguments and temporary variables: index: 10 bytes: nil Receiver's instance variables: objectManager: an ODBObjectManager id: 1 name: 'Default' path: 'C:\Documents and Settings\brans\My Documents\Document Directory\Projects...etc... indexFile: an ODBObjectIndexFile dbFiles: an ODBWeakValueIdentityDictionary dataFileA: an ODBObjectStorage dataFileB: nil activeDataFile: an ODBObjectStorage byteStorageQueue: an OrderedCollection() queueSize: 0 --- The full stack --- Semaphore>>critical: ODBFileStream>>atPosition:getBytesFor:len: ODBObjectIndexFile>>at: ODBContainer>>at: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ODBObjectManager>>holderAt: [] in ODBLocalTransaction(ODBTransaction)>>transactionObjectAt: BlockContext>>ensure: BlockContext>>valueUnpreemptively ODBLocalTransaction(ODBTransaction)>>transactionObjectAt: ODBDemandLoader>>getObject ODBDemandLoader>>perform:withArguments: ODBReference>>doesNotUnderstand: [] in CommandHistory class>>forgetAllGrabCommandsFrom: BlockContext>>on:do: BlockContext>>ifError: CommandHistory class>>forgetAllGrabCommandsFrom: [] in CommandHistory class>>forgetAllGrabCommandsFrom: [] in BlockContext>>ifError: Error(Exception)>>handlerAction Error(Exception)>>signal Error(Exception)>>signal: StandardFileStream(Object)>>error: StandardFileStream(Object)>>primitiveFailed StandardFileStream>>primSetPosition:to: StandardFileStream>>position: [] in ODBFileStream>>atPosition:getBytesFor:len: [] in Semaphore>>critical: BlockContext>>ensure: Semaphore>>critical: ODBFileStream>>atPosition:getBytesFor:len: ODBObjectIndexFile>>at: ODBContainer>>at: ODBObjectManager>>holderAt: [] in ODBLocalTransaction(ODBTransaction)>>transactionObjectAt: BlockContext>>ensure: BlockContext>>valueUnpreemptively ODBLocalTransaction(ODBTransaction)>>transactionObjectAt: ODBDemandLoader>>getObject ODBDemandLoader>>perform:withArguments: ODBReference>>doesNotUnderstand: [] in CommandHistory class>>forgetAllGrabCommandsFrom: BlockContext>>on:do: BlockContext>>ifError: CommandHistory class>>forgetAllGrabCommandsFrom: CommandHistory class>>resetAllHistory CommandHistory class>>shutDown: [] in SystemDictionary>>send:toClassesNamedIn:with: OrderedCollection>>do: SystemDictionary>>send:toClassesNamedIn:with: SystemDictionary>>processShutDownList: SystemDictionary>>snapshot:andQuit:embedded: SystemDictionary>>snapshot:andQuit: TheWorldMenu>>saveAndQuit TheWorldMenu>>doMenuItem:with: [] in MenuItemMorph>>invokeWithEvent: BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: -- and more not shown -- 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

3 3

Re: Feedback on SystemChangeNotification
by Alexandre Bergel 01 Jul '03

01 Jul '03

Hello Roel! First I would like to apology for not having answered to your proposition sooner. I am actively working on the classboxes, so I spend much less time to read the squeak mailing list than before. Before I expose my feeling, I would like to say I have nearly never work with a registration/notification/whatever mechanism, so perhaps I am missing some critical points. First I explain how I could use it for with classboxes, and then I expose some comments about the model. 1-Do I need High Level Event? ---------------------------- ---------------------------- Probably the high level event will be needed for my work. Basically, the system event mechanism will filter for me only the event I need (e.g., I do not want to be bothered by a method recompilation if I manage some coarse grain such as classbox, and I only care about dependancies between classboxes). Let me provide two examples arguments: -a new class is added in a classbox -a new method is added in a class, contained in a classbox 1.1-New Class is Added in a Classbox ------------------------------------ I would write something like: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= SystemChangeNotifier>>newClassNamed: aClassname inClassbox: aClassboxName (SystemAddedEvent item: aClassName kind: #class parent: aClassboxName kind: #classbox) trigger: eventSource -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Let take the case where a classbox CX1 imports a classbox CX2 (i.e., CX1 imports all the classes which are under the scope of CX2). Such event would be useful to check some conflicts (if a class named C is defined in CX1, a conflict appears if a class named C is added/created in CX2--In the V1 of Classboxes, there is no aliasing). In this case, I would have these events: --- |basic--added |item: #B kind: #class |parent: #CX1 kind: #classbox --- and the high level events would be (ordered as emit order): --- |high-changed |item: #B kind: #class --- --- |high-changed |item: #CX1 kind: #classbox --- 1.2-New Method Added in a Class, Contained in a Classbox -------------------------------------------------------- Note for this example I rise an issue not pointed in your implementation, about parameters passed to event. The interface should provide me something like: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= SystemChangeNotifier>>newMethodNamed: aMethodName forClass: aClassName inClassbox: aClassboxName ... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= For any new method, the low level event would be: --- |basic-added |item: aMethodName kind: #method |args: #(#(aClassboxName #classbox)) |parent: aClassName kind: #classbox --- and the high level events would be (still ordered as emit-order): --- |high-changed |item: aClassName kind: #class |args: #(#(aMethodName #method) --- --- |high-modified |item: aClassboxName kind: #classbox --- In the both example, I would really prefer to be notified only by the high level event, and not on the low one. 2-Some comments: --------------- --------------- -Everything expressed with low events cannot be expressed with high events. In your first example in the unit-test, a class is added in a category: the high events does not provide any clue (except by refering to the low event (original)) if the class is added or removed. I think it is not an important issue. If anyone need to be notified by such "low level" event, it just have to register to them. -Have you thought about passing arguments? -The "changed event" is emitted first, followed by the "modified" one. Why did you choose this order? According to my examples, it seems more natural to the opposite order (i.e., first I would like to get notified when a classbox is modified, and then look at the class changed). -the precedent point make me think about "how to design the client". Right now, the client does not have any control on how to get notified. Do you think we should provide a queuing mechanism? I am not saying we should generalize that, but perhaps to provide some easy-to-use mechanism. -In the mailing list, I have seen there were some discussion about having events synchronized or not. From my experience (I get with mobile agents when I was working at INRIA), having asynchronized events is difficult to handle... And right now I do not see any convincing example for having them asynch. -How do you handle changing a superclass? I really like what you have done. Cheers, Alexandre On Tue, Jul 01, 2003 at 08:45:53AM +0200, Roel Wuyts wrote: > Hi guys, > > can you have a look at the stuff I sent around yesterday? If things are > not clear, then just write a mail or phone me on the following number > ++32 15 51 47 66. Or on my Swiss phone, but then it gets more expensive > for me :-) > > What I really want to know is whether you can use the 'higherLevel' > events or not. The idea is that clients can register to receive only > basic events (a class is removed, a method is added), or that they can > receive 'higher-level' events that are sent by the system after the > basic event (for example, when a method is removed from a class, I also > sent a 'class modification' higher level event). I think that this can > be useful, but tell me... > > PS: Note that I am at the hospital between 1:30 and 6 today, so I'll > not be available then. > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.iam.unibe.ch/~bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

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

01 Jul '03

BTW, installing "Large Collections" in 3.6 breaks because B3DIndexedQuad is nil.

1 0

Thank Brent and BugFixArchive contributors
by Stephane Ducasse 01 Jul '03

01 Jul '03

Hi I really have the impression that BugFixArchiveBrowser is a key tool for Squeak future. So I wanted to thank brent and all the guys that contributed. This makes the feeling that Squeak is moving. People will really get the feeling that if they fix their post will be taken into account and this is the best we can offer to the community and fast harvesting process encouraging changes. Excellent. Stef

1 0

[BUG][FIX] Breakpoint package conflicts with Telnet package
by bvukmer＠blackboard.com 01 Jul '03

01 Jul '03

from preamble: "Change Set: Breakpoint-Telnet-bkv Date: 1 July 2003 Author: Brent Vukmer <bvukmer(a)blackboard.com> The Telnet package is unhappy because #Break is already defined in the system. This changeset renames the class Break to BreakPoint and edits Object >> break so that it referenced BreakPoint, allowed Telnet to install."!

1 0

Jump to page: