Squeak-dev September 2005

squeak-dev@lists.squeakfoundation.org

157 participants
266 discussions

new Magma (was: Dictionaries broken in 3.9a)
by Chris Muller 23 Sep '05

23 Sep '05

In light of the recent discussion regarding nil keys in Dictionaries, I have removed the anti-fixes related to this (including the #associationsDo: override in WeakKeyIdentityDictionary) from their "System overrides for ma object serialization" package of Magma. Magma is back to 100% pure*, making no system changes that have not been approved for at least 3.9. [*] I left the 3.9-approved fixes in, however, for <= 3.8 users. I have also removed all use of Ma*Dictionary's. They were written to fix the performance bug with #removeKey: for which they are 1000x (or more) faster than their standard counterparts but are a bit slower for other operations. Magma now avoids removeKey: altogether, so going back to the standard Dictionary's you should enjoy a minor performance improvement. A few more improvements too: - More robust network error handling for when other end drops unexpectedly. - Tests now only open transcript in conductor image. Besides being faster, Squeak was locking up loading a font or something, no time to debug it. - Fixed possible error when opening partially-written commitPackages file. Let me know if any questions or issues. - Chris

3 4

Is Set growth thread-safe?
by Ross Boylan 23 Sep '05

23 Sep '05

My recent adventures led me to this code: Set>>grow "Grow the elements array and reinsert the old elements" | oldElements | oldElements _ array. array _ Array new: array size + self growSize. tally _ 0. oldElements do: [:each | each == nil ifFalse: [self noCheckAdd: each]] If another squeak thread (NOT native thread) interrupts this operation, isn't there a possibility for bad things to happen? This operation might be triggered any time an element is added to a set. A variation that constructed the new array first might be a bit safer, but it could still have problems if something was added or removed from the set in midstream. Subclasses of Set seem to have similar issues. I thought smalltalk was supposed to be thread-safe with respect to its own threads. Am I mistaken in that belief, or in my analysis that the operation is not thread safe? I'm aware that the solution would exact several kinds of penalties (clarity, speed, memory). Ross Boylan

5 6

[ANN]A directory with Companies using Smalltalk
by Noury Bouraqadi 23 Sep '05

23 Sep '05

Dear Smalltalkers, I'm glad to announce you the availability of a directory with companies using Smalltalk around the world. http://www.esug.org/companiesdevelopinginsmalltalk/ This directory is of course totally free. It's just yet another action of ESUG to promote Smalltalk. I spent some time gathering web links. But, the amount of data is just huge. A lot of companies are still missing. If yours is not in the list, or if the link is broken, please send me an email with your company's: -name -web site -country (headquarters location) Kind regards, Noury -------------------------------------------------------------- Dr. Noury Bouraqadi - Enseignant/Chercheur Ecole des Mines de Douai - Dept. G.I.P http://csl.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org Squeak: an Open Source Smalltalk http://www.squeak.org --------------------------------------------------------------

3 3

Is a SkyHook Safe[Re: Is Set growth thread-safe?]
by jwalsh＠bigpond.net.au 23 Sep '05

23 Sep '05

Sorry for the rude subject line. Most may not know what a SkyHook is, and for those who don't, it is a joke. There is a limit to the number of "work-arounds", even for Smalltalk. Smalltalk is simply not designed for it. [yet]. Ref: http://en.wikipedia.org/wiki/RISC > RISC: Definition and Much More From Answers.com : I think the above definition is not bad and will a serve as a solid Principle upon which to build anArgument: 1. Smalltalk as an IDE should not need to call upon extranious program support, unless it respects the rules of Smalltalk. That is why it is called IDE. 2. The Smalltalk problems are ALL introduced ones. 3. Smalltalk demands the "Software be Designed First and Programmed Later". If the intended Application Software Design, prior to coding Smalltalk (or any other language for that matter), were given the same RISC teatment in software, as in RISC hardware, then we'd have less RISK. Furthermore, I sugget, many of the tactics provided so far , would be unecessary. What say you? ---- Bert Freudenberg <bert(a)impara.de> wrote: > Am 22.09.2005 um 20:43 schrieb Ross Boylan: > > > > By the usual logic of > > providing thread-safety around classes as needed, wouldn't it be > > better for Object, Model, and EventModel to protect the update > > mechanisms appropriately? > > No, because those mechanisms are intended to be used from the main UI > thread. You should not send "changed" messages from a non-UI process, > because they are handled synchronously (sending "update" messages > etc). You need to asynchronously let the UI process know it should act. > > There are several ways to accomplish this. A commonly used one in > Morphic is this: > > WorldState addDeferredUIMessage: [...] > > You can call this from a background process, the block will later be > executed in the UI process. Internally, it uses a SharedQueue holding > the blocks. > > - Bert - > >

3 2

Re: [Esug-list] [ANN]A directory with Companies using Smalltalk
by Noury Bouraqadi 23 Sep '05

23 Sep '05

Hi Tim, Le 22 sept. 05, à 09:34, Verwaart, Tim a écrit : > Hi Noury, > > I wonder if you are interseted only in smalltalk service companies, or > also organisations using/developing smalltalk applications for their > own > use. Both of them :-) > In the latter case you may add LEI (www.lei.nl) to your list. Done. > Also > in the netherlands: Soops (www.soops.nl), but i trust they will inform > you. Yes Reinout already showed up. Thanks, Noury -------------------------------------------------------------- Dr. Noury Bouraqadi - Enseignant/Chercheur Ecole des Mines de Douai - Dept. G.I.P http://csl.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org Squeak: an Open Source Smalltalk http://www.squeak.org --------------------------------------------------------------

1 0

How to do things in an MC update stream world
by Daniel Vainsencher 23 Sep '05

23 Sep '05

Hi all. We've been discussing on the packages list how to make life easier on harvesters and everyone else that cares about what goes on in the alpha, development stages. Here are some things that you might consider. I am not stating agreed policy, just a proposal for such. 1. Use MC as much as possible. IOW, try not to submit cs files. The .mcz files should correspond to the packages in the image - do not create new packages if you're trying to fix several methods in different packages. Just create a new version of each of the affected packages. Write a small paragraph describing what versions of what packages are related and how, and copy-paste this into all the versions you're submitting. Submit all your versions together into the submissions project of source.sqf.org when you feel they're ready for possible inclusion. The reason to use mcz files, though it might be easier for you to use cs files, is that mcz files give harvesters more tools to work with. For example, CS files can get stale (include old versions of code that has since been updated), and cause hard to detect collisions, which are automatically detected by MC. 2. Use proper repositories (such as the one mentioned above), not Mantis. Mantis can contain a link to an mcz file in a repository, that is as easy for you to use as an attachment. But having the actual file in a public repository helps accountability, because then anyone can easily get the original submitted version and inspect it. If you think a change is not ready for the submissions project, create your own personal project on source.sqf.org and use that. 3. Register for the sources.squeakfoundation.org RSS feed (I just found out about this). This way you get notified about every version that gets proposed or accepted. This allows you to be active in reviewing other peoples stuff, to see when your proposed changes get accepted, and generally know what's going on. This is now the equivalent of reading the BFAV, except you can do it from your friendly RSS client, without any special installation beyond subscribing to the feed. BTW, the squeaksource.com feed is also interesting. Daniel Vainsencher

5 7

[newbee] smallwiki2 installation
by Cdrick 23 Sep '05

23 Sep '05

3 2

[ANN] A new Coordinator!
by goran＠krampe.se 23 Sep '05

23 Sep '05

Hi people! We are happy to announce that Ken Causey is joining the Coordinator group as of... eh, yesterday. :) This means we are now Göran Krampe, Doug Way, Cees de Groot, Marcus Denker and Ken Causey. As you all know Ken has been in the Squeak community for quite a while and has already been pulling his fair share of community related tasks over the years - for example box administration, the great janitor team and general BFAV heroic deeds etc. And he is very often around to help people on the #squeak channel on IRC (irc.freenode.net). In short - he is a great guy and we appreciate the reinforcement. :) So... welcome Ken! regards, Göran PS. Currently the "recruitment process" to the group is based on the "we call you"-principle. ;) And btw, we aim to grow with one more ASAP.

4 3

Squeak Chat Monday September 26th 21:00 GMT
by Ken Causey 23 Sep '05

23 Sep '05

Just a reminder that the next Squeak Chat will take place between 21:00 (9 PM) GMT Monday September 26th and 01:00 (1 AM) GMT Tuesday September 27th, 2005. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html This is a good time to contribute to the development of Squeak by participating in the Harvesting Process. One of the main ways to contribute is by Reviewing submitted fixes and enhancements. For information about the Harvesting Process see http://minnow.cc.gatech.edu/squeak/3152 If you have the time please attend and work toward the future of Squeak. The next seven chats are scheduled for 01:00 (01:00 AM) GMT Saturday October 01, 2005 05:00 (05:00 AM) GMT Wednesday October 05, 2005 09:00 (09:00 AM) GMT Sunday October 09, 2005 13:00 (01:00 PM) GMT Thursday October 13, 2005 17:00 (05:00 PM) GMT Monday October 17, 2005 21:00 (09:00 PM) GMT Friday October 21, 2005 01:00 (01:00 AM) GMT Wednesday October 26, 2005

1 0

[ANN][OSPP][VM] 64-bit OSProcessPlugin, XDisplayControlPlugin, AioPlugin on SM
by David T. Lewis 23 Sep '05

23 Sep '05

The OSProcessPlugin, XDisplayControlPlugin, and AioPlugin plugins are now updated for the 64-bit Squeak VM. They compile, run, and pass all OSProcess/CommandShell unit tests. Testing was done on both 32 bit Squeak and 64 bit Squeak image/VM, as well as on both 32 bit and 64 bit hardware (Intel and AMD hardware with Linux). They can be built on the latest (64-bit capable) VMMaker and SubVersion sources, and also on older sources such as the source bundles from Ian's web site. These are available on SqueakMap. Dave

6 9

← Newer
1
2
3
4
5
6
7
8
9
...
27
Older →

Jump to page: