Squeak-dev March 2005

squeak-dev@lists.squeakfoundation.org

147 participants
281 discussions

Re: Are what the janitors are doing, what needs to be done?
by Peace Jerome 03 Apr '05

03 Apr '05

>> Jerome Peace wrote: >>> >>> Are what the janitors are doing, what needs to be >>> done? Doug Way replied: > >The Janitors are doing something that needs to be done, although it is >only a subset of all that needs to be done. :) I tried to choose my question and words so as not to dispute this. Remember my idea of the proper goal is getting things 1) fixed and 2) included in the image with 3) the least amount of effort on everyones part. Also my perceptions have grown somewhat. Having someone who can direct traffic and educate bug reporters to make better reports would assist these goals. I still hold that the problem solvers need to be there else all you�ve got is an on ramp with no highway. > >The initial focus of the Janitors was just to make sure all issues were >tracked in Mantis (by moving bugs/fixes over there from this list). >But I think I managed to talk Ken into expanding the scope a bit, to >include Mantis and other process improvements as well. (See the >helpful "How to Report a New Squeak Issue" doc which Ken added to the >Mantis docs page.) I couldn�t find this. Where should I look? I tried the doc link on mantis but that only gets general doc there is no project specific doc. >Eventually, hopefully all of steps 1 & 2 from the >original Harvesting Process: http://minnow.cc.gatech.edu/squeak/3152 > >But step 3 from the Harvesting Process (incorporation) is more >complicated, and will be affected by the process of splitting the base >image into packages by the Packages team. Can you be more specific. Do fixes wait until packages are split? Will each package have someone who can commit fixes to it? And what happens when a fix spans several packages??? >Some of the discussion on the v3dot9 list has been about this and the >update stream. > >>> Quite frankly, My perception is the janitors will >>> generate a lot of noise and result in very little of >>> the actual problems being solved. It will obscure the >>> fact that what is needed is problem solvers and bug >>> fixers and not just text processors. > >Note also that the bug-transfer aspect of the Janitors mission should >be relatively short-term... eventually people will realize that the old >way is no longer supported. Ok. Time will tell. The noise is not a great problem if it does not distract from getting the fixes in. The resources needed are the problem solvers and the recruiters of problem solvers. Yours in service, -- Jerome Peace > > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

2 1

[BUG][FIX] WriteBarrier at:put: fix for variable classes
by Chris Muller 03 Apr '05

03 Apr '05

The WriteBarrier class-comment states: - any methods that potentially modify instance variables will be overriden in this new class. The overridden method stores the original values of the instance variable in temps, then calls the super method, and then compares the current inst var values with the originals. - If the instance variable values have changed, the WriteBarrier will be notified with a send to #modified:, with the object that was modified as the single argument. - For variably-sized classes, #at:put: is also overridden to provide the same notification. While integrating WriteBarrier into Magma, I noticed my Array test was actually slower than without WriteBarrier. The problem is in WBClassBuilder>>installAtPutOverrides, which do not check whether the value is changed, it signals #modified no matter what. To demonstrate this: | a wb | a _ Array with: true. wb _ DirtySetWriteBarrier new. wb add: a. a at: 1 put: true. wb dirtySet includes: a This script should return false. After loading the attached fix, it will. Also, I have a question. Are there any caveats to overriding instVarAt:put: to check for a new value as well? The same class-comment says: - The WriteBarrier is semi-permeable: if you want to modify an object directly without triggering notifications, you can use #instVarAt:put: and #basicAt:put:. This reduces transparency albeit just a little; and this same permeability could be achieved by temporarily removing from the WriteBarrier. Is there any reason not to do it? Regards, Chris

3 2

Squeak on Handhelds, Status?
by Stefan Krecher 02 Apr '05

02 Apr '05

Hello, the topic "Squeak on Handhelds" has been discussed several times on this list in the past. I'd just like to ask, what's the state of the art, if there are people working with/ on Squeak for Handhelds, an maybe if there's some help needed. Background: Smalltalk is my favorite programming language, and a couple of years ago i worked with Visual Age for Smalltalk. In the past years I played around with Squeak, but i'm far away from beeing a Squeak-expert. At the time i have to implement a UI for a Handheld running WindowsCE (iPaq). The UI shall control actions served by an ejb/ servlet-container (jboss) via HTTP-GET-Requests to a servlet. For the first version of the control-sw we used ewe, a free Java-Implementation for Handhelds (www.ewesoft.org). Unfortunately the UI was not "sexy" enough for our customer. Now I'm trying Squeak, because Morphic as a lot of possibilities to implement graphics/ animation/ sound and other "sexy" things. (btw. "sexy" in this context means: colorful, animated, playful etc.). For the first tests I used the SqueakVM 3.0 compiled for ARM (http://www.is.titech.ac.jp/~ohshima/squeak/WinCE/) and a default 3.2-image. Everything seems to work fine, i built funny buttons, lists and so on. Networking works fine too (WLAN). I'd like to know if there are any pitfalls - for now everything seems to be a bit too easy. Do you have any hints/ tips for stripping down the image? Any ideas on how to implement an automatic installer (an executable that installs the sw on the iPaq)? I heard of the possibility to "close" the image (prevent the user from opening a world-menu etc.). Thanks in advance for any hints, tips or resources. And if there's any help needed, let me know. regards, Stefan -- GPG fingerprint = 2E77 C256 47B1 27B8 AE07 94BE D7A1 2A3C C716 2BE9 GPG public key: http://krecher.de/pubkey.asc ICQ #84067348 "A specter ist haunting the modern world, the specter of crypto anarchy" The Crypto Anarchist Manifesto, Timothy C. May

5 5

Smalltalk/JVM
by Jason Jones 01 Apr '05

01 Apr '05

We were looking for feedback on turning Smalltalk/JVM into an open source project. Smalltalk/JVM is a Smalltalk Compiler that compiles to Java bytecodes and class files. Is this something any of you out there in the programming community are interested in? We would love some feedback. Mission Software, Inc. has created a Smalltalk compiler for the JVM. This compiler allows Smalltalk to run on any JVM. The compiler currently produces 100% Java class files fully compatible with the Sun JVM specification. This allows Smalltalk and Java code to interact seamlessly and allows Smalltalk programs to run anywhere Java runs. a.. Compiler compiles Smalltalk classes into Java .class files a.. Java code callable from Smalltalk code a.. Smalltalk code callable from Java code a.. Java classes subclassing Smalltalk classes a.. Smalltalk classes subclassing Java classes a.. Development is done in a "surrogate" Smalltalk environment a.. Execution in any JVM environment a.. Support for Smalltalk blocks a.. Support for JIT Compilers a.. Ability to write Servlets in Smalltalk a.. Ability to write Applets in Smalltalk (No plug-in required) a.. No special VM required Please email any questions to me at jsj(a)ksc.com -- Jason Jones Knowledge Systems Corporation Smalltalk Industry Council 919.789.8549 x.21 www.ksc.com www.missionsoft.com

3 2

[BUG] InterpreterSimulator
by Noury Bouraqadi 01 Apr '05

01 Apr '05

Hi, I run in Squeak 3.7 full (InterpreterSimulator new openOn: Smalltalk imageName) test But it failed quickly. I searched the web and found that Nathanel alreardy pointed this bug in may 2004. But, found no fix. Any hint? 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 --------------------------------------------------------------

5 4

funny issue with #valueWithArguments:
by Cees de Groot 01 Apr '05

01 Apr '05

I have an event registration with three static arguments (nil, objectA, objectB). This event is triggered with a collection as the argument, making the call with arguments (collection,objectA,objectB). The funny (well.... funny) thing is that if this just runs, it throws up. Something is messed up in WeakMessageSend>>valueWithArguments: so that the #perform:withArguments: in there is sent to the (dynamic) argument array, with selector being the intended recipient and argArray is messed up, it looks like there's even a methodContext in there (but with the wrong number of actual temps w.r.t. the selector name so that the method context won't print). When single stepping, everything works like a charm. That makes it really strange... This happens on my machine, on a colleague's machine, and also when I restart from my base image loading everything into it. I'm completely lost here - does anyone have an idea what this could be?

3 7

Re: Monticello dependencies
by Chris Muller 01 Apr '05

01 Apr '05

Thank you Colin and Avi for your supportive attitudes. And yes, Colin, I shouldn't have said "anywhere in the system" I meant anywhere just in my packages. Here is a suggestion for moving forward; we can use SqueakSource to create a test-project where (I hope!!) I can reproduce the test-condition. I'll describe my exact steps to reproduce and then you'll be able to do it in this same context. I have to go now, but if that approach sounds good to you, I'll try getting it set up sometime tomorrow. - Chris --- Colin Putney <cputney(a)wiresong.ca> wrote: > Chris Muller wrote: > > Monticello is wonderful for one-click loading, but one-click saving still > > eludes me. > > > > I just want to work on code anywhere in the system and then save my root > > package to a repository and feel confident that it and the subpackages will > be > > recreated in the loading image just as they exist in my saving image. > > > > Does Monticello purport to meet this requirement or not? > > It depends on what you mean by "anywhere in the system." > > If you mean anywhere in the packages that you're managing with > Monticello, then yes, saving your root package will do everything > necessary to recreate the state of your dependent packages when you load > that version of the root again. If it doesn't, it's a bug. I rely on > this pretty heavily when developing OB, and haven't had any problems. > > If "anywhere in the system" could include any code in the image, then > no, Monticello doesn't support the requirement. > > > If so, am I the only one experiencing this? Perhaps I am overusing > > dependencies; I counted and have dependencies that run *eight* levels deep. > Is > > this insane? Is there anything I can do to assist the maintainers in > > reproducing this? > > What are you experiencing? I interpret what you've said above to mean > that you're not confident that dependencies behave the way you expect. > Have you encountered behavior that you didn't expect? > > 8 levels is a bit more than I have in OB, but it's not at all > unreasonable. With that big a tree you might want to check that you > haven't missed a dependency somewhere, but otherwise it ought to be fine. > > Colin > > >

1 0

Monticello dependencies
by Chris Muller 01 Apr '05

01 Apr '05

Monticello is wonderful for one-click loading, but one-click saving still eludes me. I just want to work on code anywhere in the system and then save my root package to a repository and feel confident that it and the subpackages will be recreated in the loading image just as they exist in my saving image. Does Monticello purport to meet this requirement or not? If not, fine, end of story. I'll shut-up about it and just be sure to verify my out-going dependency links every time I save. If so, am I the only one experiencing this? Perhaps I am overusing dependencies; I counted and have dependencies that run *eight* levels deep. Is this insane? Is there anything I can do to assist the maintainers in reproducing this? - Chris

4 5

looking for Squeak speaker in Ottawa
by Alan Knight 01 Apr '05

01 Apr '05

Hello All, I'm one of the organizers of the Ottawa-Carleton (Canada) Smalltalk User Group, http://smalltalk.ottawa.on.ca and we're thinking that for an upcoming meeting we'd like to get an update/demo on Squeak. I sent a mail to our internal list, but didn't get any volunteers. So if there's anyone in the Ottawa are who'd be interested in doing a talk in the next little while, please let me know. Thanks, Alan -- Alan Knight [|], Cincom Smalltalk Development knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

2 1

Re: My first Magma experience
by Chris Muller 01 Apr '05

01 Apr '05

> MaObjectSerializationSecurityViolation signal: Serializations beyond 10 > megabytes are not allowed. What does your FHKC834Header>>addMember: do? My guess is it is still building the entire linked list in one giant commit. This is not allowed. Put a Transcript>>show: in your commit-loop; you are expecting to see a bunch of small-commits right? I'll bet you will not see any because it's doing it all in one. Try opening the debugger and then select "Full Stack". You will see the frames where it is traversing your object graph; I'll bet you see a ton in those FHKC834Members even though you were only expecting one. Try cutting the file down to just a few members and use your same script. Then see if it succeeds in one commit (which would presumably be less than 10-meg). If you don't get anywhere, send me your script and file and I'll run it.. - Chris

1 0

Jump to page: