Squeak-dev November 2006

squeak-dev@lists.squeakfoundation.org

157 participants
223 discussions

[Socket] [Bug?] Setting time-to-live option for IGMP
by Noury Bouraqadi 29 Nov '06

29 Nov '06

Hi, On Squeak 3.9-7067, I'm trying to setup the time-to-live for a group communication socket. It works for a ttl lower than 10 and fails for the rest. Attached the sunit test. Am I missing something or is it a bug ? Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur ARMINES - Ecole des Mines de Douai - Dept. I.A. http://csl.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org Squeak: a Free Smalltalk http://www.squeak.org ------------------------------------------------------------------

1 0

Squeak and Namespaces
by Torsten Bergmann 29 Nov '06

29 Nov '06

Mikael Kindborg wrote >...namespace system... >Would be a good idea to put this into the next release. +1 Bye Torsten -- "Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

1 0

People.SqueakFoundation.org People (time for some cleanup)
by Ken Causey 29 Nov '06

29 Nov '06

We now have 342 users registered at http://people.squeakfoundation.org of those 68 have never been certified by anyone and I suspect a large number of those are invalid/non-Squeak community accounts. I would like to call on everyone to go through the list of people paying particular attention to those marked as Observer. If you know the person, and are reasonably certain they created the account, and if the person has any real interest in Squeak at all, go ahead and assign them at least Apprentice certification. If you know the person but are unsure whether they created the account, please check with them to be sure before certifying them. If you know them but know that their interest in Squeak was merely fleeting, or they registered on the site not realizing that it had anything to do with actual community status, please ask them whether they are sure they need the account. If so, at least request that they add some real information about themselves so it makes it easier to tell the real from the bogus accounts. If not, please have them contact me and I would be quite happy to remove their account. Similarly I see that a few people have created more than one account. Possibly because they forgot they had the account or because they forgot the password to their original account. Again if this fits you contact me and we will discuss what to do. Also, everyone should go through their own account information and make sure it is accurate and reasonably up to date. If you have forgotten your password, contact me. Thanks, Ken

2 3

Today's Server Outage
by Ken Causey 28 Nov '06

28 Nov '06

I would like to apologize for the server outage which has resulted in quiet lists and pretty much zero response for website requests for the services hosted on the community server. A lack of communication resulted in a stack of backed up backup processes which ate up the usage. I was finally able to clean up and things should be more or less back to normal. For now the daily backup schedule has been suspended until we work out a replacement setup. Ken

2 2

Re-2: Skylark Theme and Squeak 3.9
by Frank Urbach 28 Nov '06

28 Nov '06

Hi, Use the flap at the right sight "Tools". There is a litte Icon called "File List". Drag this and drop it into the world outside of the flap. Go to the directory containing the .cs File and click in the top-right window on the .cs-File. After this use the button "install". Hope this helps Cheers, Frank -------- Original Message -------- Subject: Re: Skylark Theme and Squeak 3.9 (28-Nov-2006 6:03) From: GeertC <geert.wl.claes(a)gmail.com> To: frank.urbach(a)schmees.com > > Newbie question: how do I use the Skylark theme? I have just installed > Squeak > 3.9 and downloaded the Skylark2.cs file. Whats next? > > > Pavel Krivanek wrote: > > > > Hi all, > > > > LookEnhancements have very negative impact on speed of Squeak. So I > > have tried to update my Skylark Theme for Squeak 3.9. It's only > > testing version and it's not perfect but if you want to have faster > > interface, try it. The test (without TTF and gradient background) with > > opening of 30 browsers shows that it needs about 60% of time for this > > operation. And it was about two times faster than Squeak 3.7 during > > opening of 100 empty windows. > > > > Download and here: http://www.comtalk.net/Squeak/87 > > > > -- Pavel > > > > > > > > -- > View this message in context: http://www.nabble.com/Skylark-Theme-and- > Squeak-3.9-tf2268198.html#a7573433 > Sent from the Squeak - Dev mailing list archive at Nabble.com. > >

1 0

Re: squeak ldap attribute modification
by Vladimir Plšek 28 Nov '06

28 Nov '06

Thanks Milan, vp Milan Zimmermann wrote: > Vlado, > > I won't be able to help, justa a note, if you do not get any comments on > this list, it may be a good idea to ask on the squeak-dev mailing list, it > is quite specific question, so squeak-dev can be better, > > Milan > > On 2006 November 24 03:08, Vladimir Plšek wrote: >> Hi, >> I was playing with ldap litlle bit and I found some strange behavior. >> >> >> When I am trying to do some attribute modification I got error "Improper >> store into indexable object". >> example: >> (I uesed syntax from ldap test class) >> >> ld modify:(ldr dn) with: {LDAPAttrModifier addTo: 'employeeNumber2' >> values: {'123' }}. >> >> (where ld is ldap connection, ldr is first resultentry) >> >> I debuged it and found that I should use: >> >> ld modify:(ldr dn asString) with: {LDAPAttrModifier >> addTo: 'employeeNumber2' values: {'123' }}. >> >> ldr dn is instance of ByteArray class, but ld modify: with: expect it as >> string. >> >> Am I doing anything wrong? >> or it is correct to use it that way. >> >> >> vlado plsek >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/beginners

1 0

Atomic loading of Monticello packages
by Ralph Johnson 28 Nov '06

28 Nov '06

Stephane said that the biggest problem he had with Monticello was that loading a package was not atomic. It compiles methods one at a time, and sometimes you need to load an entire package at once, because loading half a package might break the compiler or some part of the system that the package system depends on. I decided to take a look at Monticello, because I've built other tools that had to solve this problem. I have attached a first attempt at a solution. This change makes loading a package atomic, but not unloading it. I will create a similar solution for unloading if people like this. I did not test it on any packages that require atomic loading because I don't have any packages like that. However, it does run the Monticello tests, and I tested it on a couple of other packages. The tests only pass if you load the Make39Green.cs patch. I don't know why, but I will figure it out some other time. I am going to give a description of what I did. Feel free to ignore everything after this, but to just try out the code. If you discover a package that does not load properly, please let me know. I particularly want to know how this works on packages that couldn't load before. The Monticello code is fairly easy to read in spite of lacking comments. Class comments in particular would be useful. There is a large test suite that did a good job of pointing out my errors. The key method is the basicLoad method in class MCPackageLoader. The original version is basicLoad errorDefinitions := OrderedCollection new. [[additions do: [:ea | self tryToLoad: ea] displayingProgress: 'Loading...'. removals do: [:ea | ea unload] displayingProgress: 'Cleaning up...'. self shouldWarnAboutErrors ifTrue: [self warnAboutErrors]. errorDefinitions do: [:ea | ea loadOver: (self obsoletionFor: ea)] displayingProgress: 'Reloading...'. additions do: [:ea | ea postloadOver: (self obsoletionFor: ea)] displayingProgress: 'Initializing...'] on: InMidstOfFileinNotification do: [:n | n resume: true]] ensure: [self flushChangesFile] The problem with this is that classes and methods are loaded by the tryToLoad: method, one at a time. In fact, they are also added by the loadOver: method a little later. I think that an errorDefinition is a method that started out in additions but couldn't compile, so the PackageLoader will wait until all the classes are defined and then try to compile it again. tryToLoad: wraps loadOver: in an exception handler and, if anything goes wrong, puts the offending method definition in errorDefinitions. loadOver: calls a method in ClassDescription to compile the method, and then calls the following method to insert the method in the class. addAndClassifySelector: selector withMethod: compiledMethod inProtocol: category notifying: requestor | priorMethodOrNil | priorMethodOrNil _ self compiledMethodAt: selector ifAbsent: [nil]. self addSelectorSilently: selector withMethod: compiledMethod. SystemChangeNotifier uniqueInstance doSilently: [self organization classify: selector under: category]. priorMethodOrNil isNil ifTrue: [SystemChangeNotifier uniqueInstance methodAdded: compiledMethod selector: selector inProtocol: category class: self requestor: requestor] ifFalse: [SystemChangeNotifier uniqueInstance methodChangedFrom: priorMethodOrNil to: compiledMethod selector: selector inClass: self requestor: requestor]. Note that addSelectorSilently:withMethod: finally inserts the method into the class. This is the step that must be avoided. So, I changed this method to leave out this message, and instead returned the compiled method. The new method is MCaddAndClassifySelector: selector withMethod: compiledMethod inProtocol: category notifying: requestor | priorMethodOrNil | priorMethodOrNil _ self compiledMethodAt: selector ifAbsent: [nil]. SystemChangeNotifier uniqueInstance doSilently: [self organization classify: selector under: category]. priorMethodOrNil isNil ifTrue: [SystemChangeNotifier uniqueInstance methodAdded: compiledMethod selector: selector inProtocol: category class: self requestor: requestor] ifFalse: [SystemChangeNotifier uniqueInstance methodChangedFrom: priorMethodOrNil to: compiledMethod selector: selector inClass: self requestor: requestor]. Note that the new method tells the SystemChangeNotifier that a method was added but doesn't actually add it until later. I hope this doesn't cause a problem! An alternative would be to first insert the methods and then to notify the SystemChangeNotifier, but to do it all at the end of basicLoad. I changed the method that calls it to return the compiled method. MCcompile: text classified: category withStamp: changeStamp notifying: requestor logSource: logSource "Note that I return methodAndNode, while the old version returned a selector" | methodAndNode | methodAndNode := self compile: text asString classified: category notifying: requestor trailer: self defaultMethodTrailer ifFail: [^nil]. logSource ifTrue: [ self logMethodSource: text forMethodWithNode: methodAndNode inCategory: category withStamp: changeStamp notifying: requestor. ]. self MCaddAndClassifySelector: methodAndNode selector withMethod: methodAndNode method inProtocol: category notifying: requestor. self instanceSide noteCompilationOf: methodAndNode selector meta: self isClassSide. ^ methodAndNode So now, we can define methods in MCMethodDefinition. loadOver is a method that compiles the method. It was changed to return the method rather than installing it. load will both compile and install the method. loadOver: aDefinition "Note that this doesn't actually load the method, it just compiles it and returns the compiled method for loading later." ^self actualClass MCcompile: source classified: category withStamp: timeStamp notifying: (SyntaxError new category: category) logSource: self actualClass acceptsLoggingOfCompilation load | methodAndNode | methodAndNode := self loadOver: nil. self actualClass addSelectorSilently: selector withMethod: methodAndNode method Here is the new version of basicLoad in MCPackageLoder. Note that it uses tryToLoad:in: to compile methods, but saves them in methodsToLoad instead of installing them. It collects some more methods from errorDefinitions, and then installs all methods after it has processed the errorDefinitions. Note that the installing just uses pairsDo: on OrderedCollection and addSelectorSilently:withMethod: on Class. So, it basically uses only Collection and Behavior methods. I could make it use even less code if that were important. basicLoad | methodsToLoad | errorDefinitions := OrderedCollection new. methodsToLoad := OrderedCollection new: 10. [[additions do: [:ea | self tryToLoad: ea in: methodsToLoad] displayingProgress: 'Loading...'. removals do: [:ea | ea unload] displayingProgress: 'Cleaning up...'. self shouldWarnAboutErrors ifTrue: [self warnAboutErrors]. errorDefinitions do: [:ea | self load: ea in: methodsToLoad] displayingProgress: 'Reloading...'. methodsToLoad pairsDo: [:class :eachMaN | class addSelectorSilently: eachMaN selector withMethod: eachMaN method ]. additions do: [:ea | ea postloadOver: (self obsoletionFor: ea)] displayingProgress: 'Initializing...'] on: InMidstOfFileinNotification do: [:n | n resume: true]] ensure: [self flushChangesFile]

3 6

Clean way to process XML
by Ramūnas Gutkovas 27 Nov '06

27 Nov '06

Hello Squeakers! I am trying to implement XML based protocol in Squeak. And was wondering how to do it cleanly in Smalltalk. My take is to write general DSL (something like DTD, but bit more powerfull with types) for this that whould generate classes which object fields whould be maped to object instance variables. This way I could have protocol objects as native Smalltalk objects. But I am not shore if this is the best solution. Maybe there is one (by googling I didn't find anything)? Or how a real smalltalker whould tackle this?

2 2

[Q] Why a Chevy is not a Rolls Royce ?
by Edgar J. De Cleene 27 Nov '06

27 Nov '06

On search of automatic package download for see a common ground or intersection point between MinimalMorphic and 3.10alpha If by example you wish no SUnit in your image (silly idea, but is YOUR image) (MCPackage named: 'SUnitGUI') unload. SmalltalkImage current fixObsoleteReferences. Say still you have obsoletes. For not having , you should, in order. Open the Tools Flaps , delete Sunit IconicButton CommandHistory resetAllHistory. TheWorldMenu removeObsolete. SystemOrganization removeEmptyCategories. Now , no SUnitGUI in your image. Hope you realize now why a Chevy is not a Rolls Royce. Edgar PS> Not write you have a Mercedes :=) __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar

1 0

release team proposal
by Ralph Johnson 27 Nov '06

27 Nov '06

Here is the proposal I sent to the Squeak board. ---------------- The Squeak 3.10 release team is going to focus on developing a simple, visible and reliable process for creating new releases. The alpha 3.10 release will have an image and a set of core packages. Each will have a test suite, and all tests in the test suites will pass when any subset of the packages is loaded into the image. Each subsequent version will continue to keep the existing packages working. We expect the alpha release and all later releases to be usable. We want people to feel comfortable using the latest version so that 3.10 will be heavily used long before the final version and most bugs will be discovered. Our plan is to have the alpha release by the end of January and to accept major changes for the next three months, i.e. til the end of April. "Major changes" will include moving code from the image into packages and making new core packages. We are not expecting any major new features in the image. The last month will be only bug fixes, and a final version of 3.10 will be the end of May. The main focus will be on developing a good process for creating releases. So, we expect to experiment with the process. Ideally, the final process would be so easy to follow that it would be easy to be in charge of producing a release. The current process plan is that all requests for change would go through Mantis. Each bug fix would have a test that shows the bug and that shows that it is fixed. The release team would periodically (once or twice a week, perhaps every day) go through Mantis, test each change to make sure it doesn't break anything, and commit them to the current release. The releases would be distributed in several ways. There will be a "package universe" of all the core packages, and perhaps one of non-core packages, as well. There will be an update server so that people do not have to load new images to stay up to date. There will be a Montecello repository of all the changes so that everything we do will be repeatable. We will try to make it easy for people to use the release that is under active development. Current members of the release team are Ralph Johnson and Edgar J. De Cleeene. -------------- Reading it again, I can think of some comments. The main one is that this is explaining what the Squeak team will do, which is to develop a process for making releases and shrinking the image. Part of the process is making it easy for other people to fix bugs and add features. I am not opposed to adding features! You could think that from this proposal. I just think that adding features should be what everybody does, not just the release team. As part of fixing the process, a large part of my job will be getting people to participate. I expect that the social engineering will be more work than the software engineering. The software engineering is, in my opinion, very standard and routine, though I am sure I will get some argument about that. The social engineering will require more creativity. -Ralph

12 16

Jump to page: