Squeak-dev August 2005

squeak-dev@lists.squeakfoundation.org

157 participants
234 discussions

veryDeepCopy, ImageSegments, and actionMaps
by Ned Konz 17 Aug '23

17 Aug '23

Any Object can have dependents whether or not it has an instance variable to keep track of them (these are kept in the DependentsFields class variable of Object). The only class that keeps its own dependents is Model. Any Object can have an actionMap. These are supplied by EventManager class by default, and are stored in the ActionMaps class variable of EventManager. The only class that keeps its own action maps is Morph. When we veryDeepCopy an object we also copy the global dependents (see DeepCopier>>fixDependents). However, we don't copy the actionMap in those cases where it's held by the EventManager class. When we file out an object that uses DependentsFields out into an ImageSegment, we also file out the dependents (see ImageSegment>>dependentsSave:) if it's in a project. We do this by adding a project parameter called #GlobalDependentsInProject. However, we don't file out the actionMap in those cases where it's held by the EventManager class. My question is this: should we fix these behaviors (copying and serialization) to include these "global action maps" just like we already include the "global dependents"? Or should we discourage the use of the "global action maps"? -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

3 2

Trying to build SerialPlugin for IrDA under MPW (MacOS 8.6)
by Hans-Martin Mosner 24 May '12

24 May '12

Hi, I recently got a serial IrDA adapter and wanted to play around with it under Squeak. This adapter has a baudrate switching mechanism which depends on toggling the DTR and RTS lines in the correct sequence. To support this, I wanted to build a new SerialPlugin with an additional primitive. However, the plugin as built with MPW does not seem to be accepted by the VM, which still uses the internal plugin in all cases. I've tried placing the plugin in a 'Plugins' subfolder of the VM's folder, and then directly into the VM folder, without any success. I have considered placing debug outputs in appropriate places in the VM, but building a complete VM with MPW is not easy - I would have to create an MPW makefile for the whole shebang, which is more work than I can invest at the moment. Does any of you Mac aficionados have an idea where the problem could be? I have appended the plugin and corresponding source files in a ZIP file (it's not big) so if you want to try it out you could do it right now :-) BTW, would it make sense to incorporate support for switching serial port parameters of an open port into the standard plugin? Closing and opening a port just to change the baud rate seems a little overkill... Cheers, Hans-Martin

6 14

hash method
by Houssam Fakih 31 Jan '07

31 Jan '07

Hi, When I redefine the = operation for a class I should redefine its hash method. My question is about the definition of the hash method. I read that the method must return a SmallInteger whose value is related to the receiver. I would like to know if there is a general pattern adopted in Squeak for that. I get a look in the Squeak classes but it doesnt help. Thanks, Houssam ____ "Le paradis touche les pieds des mères..." >>> http://csl.ensm-douai.fr/fakih

4 4

RE: Progrmaming in Bytecode?
by Swan, Dean 24 Nov '06

24 Nov '06

>> It's not uncommon to find x86 code padded with a lot of NOPs >> that weren't in the original source. > >Cowardly assembler! ;-) > >> [NOPs...] Sometimes they're there to pad the execution pipeline, and >> sometimes it's just because the code generator allocates a whole large >> enough for the largest form of an instruction to simplify the branch >> target calculations. > >We must be talking about M$oft assemblers here. ;^p) Yes. This has been pretty characteristic of MS assemblers as far back as I can remember (i.e. about MASM 2.0 - I remember being quite excited when MASM 4.0 came out - '186 and '286 code!). >The real problem is that the solution in general might require N >iterations for a piece of code with N branches -- if promoting one of them >from short to long causes the next (or, much more problematically, a >preceding) one to become long too. You're such an optimist. O(n) is close to best case for this problem. >This is a weak form of what I suppose one might call an "oscillating >constraints" problem. (Hands up anyone who has ever seen [La]TeX get Hence, stochastic optimization. Even MS uses stochastic optimizers now, even in vb. (didn't want to say that too loud here. ;) ) >The usual cause for "padding" in (capable) assemblers (other than for >prefetch alignment, as you point out) is due to dynamic linking where the >size of call sites isn't known until link time. (On modern systems the Not only prefetch alignment. I have heard, although I don't know the details that sometimes it's desirable to force a dead cycle in the execution pipeline. I can only guess that this would be to influence the scheduling of the execution units for complex instructions, but I consider myself to be only a "casual observer" with respect to this kind of thing. >In Smalltalk you've also got a bigger problem: for very long methods the >range of even unconditional branches might not be enough, at which point >I know this has nothing whatsoever to do with Smalltalk...) Well, to kind of tie this back into something relevant to Squeak - I know a few people have talked about "new" VM instruction sets. It seems that it might help to think about a VM where all instructions are the same size. This could simplify code generation (i.e. compiling methods), and possibly improve performance and *reduce* code size (at least in the case of long methods). The anticipated performance improvement would come from forcing aligned fetches more often and potentially simpler instruction decoding. It's really nice to work with an architecture where all instructions take up one word of memory, take one cyle to execute, and sometimes can cause five or six different useful things to occur during that one cycle. (ok, so I write a lot of DSP code...) The single cycle thing isn't necessarily relevant for Smalltalk, but those "extended" bytecodes are really distasteful to me. -Dean

10 15

[ANN] Audio Video Library
by Martin Kuball 07 Oct '06

07 Oct '06

Hi I would like to annonce my project to build a Library for processing audio and video material with squeak. I put a 1st version on the SqueakSource at kilana.unibe.ch. It's not much yet. But you can load and analyze avi container with mpeg 4 video and mp2 and mp3 audio content. I did this because I needed a tool to repair some broken avi files. Other tools I tried just failed badly. Try this: RIFFArchive openOn: 'test.avi' "use explore it to get a nice tree view of the chunks in the avi" "open a transcript and execute the following to get some information about the contents" (RIFFArchive openOn: 'test.avi') analyzeVideoStream "To extract the streams inside the avi container do:" (RIFFArchive openOn: 'some.avi') extractAllStreamsToFile: 'base_fileName'. "If you have raw streams you can create an avi this way:" | avi | avi := AVIFile with: (M4VStream on: 'video.m4v') with: (MPAStream on: 'audio.mp3'). avi runtime: 100. avi frameRate: 24000 / 1001. avi createIndex. "not working yet" avi writeTo: (StandardFileStream newFileNamed: 'test.avi') Here is my tentative todo list. - write more documentation and tests - cleanup and speedup - add more container formats like mp4, matroska - add mpeg2 handling (-> dvd authoring???) - connect with the other multimedia bits in squeak (sound, video playing, ...) The project is of course open for everyone to join. Enjoy, Martin

5 6

[BUG] SM2 Burps after loading Breakpoint support or ColorDevTools
by Thomas A Petersen 05 Dec '05

05 Dec '05

Herman, Goran, et. al, I don't think your Jacaranda script is the problem. I tried the same exercise from a clean 3.7 5566 image and loading SM2 Loader first thing. I get the same crash with Breakpoint Support and ColorDevTools. Checking the change sorter shows that things are installed. There appears to be something going on as SM2 finishes things. Goran, Oh Great Sage of SM.... Can you enlihton us? Thanks much, tap P.S. Here's the debug log. Could this be a side effect of the translation stuff?? ----------------------------------------------------- MessageNotUnderstood: Character>>first 1 December 2003 3:22:52 pm VM: Win32 - Squeak3.5 of '11 April 2003' [latest update: #5180] Image: Squeak3.7alpha [latest update: #5566] Character(Object)>>doesNotUnderstand: #first Receiver: $5 Arguments and temporary variables: aMessage: a Message with selector: #first and arguments: #() Receiver's instance variables: value: 53 SMSqueakMap>>installedVersionOf: Receiver: a SMSqueakMap Arguments and temporary variables: aPackage: SMPackage[Breakpoint Support] Receiver's instance variables: packages: a Dictionary(an UUID ('010894c3-0b8a-47fc-8deb-7c08996bfa71')->SMPackage[OSProcessPlugin] an UUID('017b1882-9376-4bf7-b...etc... accounts: a Dictionary(an UUID ('034ab782-a939-de49-976c-b009701b4406')->SMAccount[Todd Blanchard] an UUID ('035d2bda-c301-6049-b...etc... objects: a Dictionary(an UUID ('007e8c1c-02fa-45fc-97be-7ea4d2f67134')->SMCategory: Package group an UUID ('008c9940-4caf-ac49-a...etc... categories: nil dir: 'sm' transactionCounter: 3011 firstTransactionNumber: 2929 daysBacklog: 182 adminPassword: nil installedPackages: a Dictionary(an UUID ('07469ced-289a-4b6f-bd17-27ec567e681a')->'1.25' an UUID ('1200100f-1a95-...etc... installCounter: nil fileCache: a SMFileCache users: nil --- The full stack --- Character(Object)>>doesNotUnderstand: #first -----------------------------------------------------

5 4

OpenAL 1.1
by Brad Fuller 04 Nov '05

04 Nov '05

The Game Developers Conference ended this week and Creative discussed OpenAL 1.1. This new version includes some extensions that may be beneficial to me and potentially to others. In a previous msg Mark mentioned that OpenAL plugins have been made and are used in Croquet. I have a few questions: * How can Squeak users obtain the plugins and use it in our current images? * How can OpenAL plugins be integrated into 3.9 to be available for all? * Has there been any discussion regarding extending the plugins to OpenAL v1.1? * To facilitate the migration from 1.0 to 1.1, the OpenAL community is providing a few extensions to v1.0. One of the main issues of OpenAL, for me anyway, is that it does not have facilities for recording. Fortunately, this has changed in v1.1. The 1.0 recording extension is: EXT_capture. Has anyone started work on this or on any other extensions? (more info on extensions: http://openal.org/extensions.html) brad -- ________________________________ Hear us online: www.Sonaural.com Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian

4 5

Request for Comment: MethodAnnotations for 3.9alpha
by Marcus Denker 14 Sep '05

14 Sep '05

Hello squeakers, Of the long and exiting list of things that are in consideration for 3.9a, one is MethodAnnotations. This is a changeset that was done by Andreas long time ago (2002, I think) and it's used extensively in Tweak. At SCG, we have used it for ByteSurgeon and are using it for another ongoing project. What are MethodAnnotations? --------------------------------------- MethodAnnotations can be seen from two perspectives: 1) storing state in CompiledMethod objects. In Squeak, CompiledMethod is a strange class. One thing you can't do is adding an instance variable. This makes experimentation awfully complicated, e.g. people made hacks to store state in the literalFrame or in class vars... see MethodWrappers for an example. MethodAnnotations just provides a general, nice and easy way to store stuff in compiledMethods, no need for hacks anymore. e.g. store: (Object>>#halt) setProperty: #hello toValue: 5. and read: (Object>>#halt) valueOfProperty: #value; 2) Syntax for Method Annotations. We can set annoations to methods using the syntax we already know for primitives (which are, in a sense, just an annotation): Object>>mumble <hello: 4> Tweak uses these annotations to describe when a method should be activated. How are they implemented? -------------------------------------- Andreas' orginal implemention used a big WeakIdentityKeyDictionary in a class var of CompiledMethods to store the IdentityDictionary for each method. This turns out to have some nice properties (no space is used for non-annotated methods) and a bad one: Performance. For ByteSurgeon, after annotation all methods (40.000), it was unusably slow. So we hacked a version that used the literealFrame instead, after discussing this with Andreas, we now use the second-last literal Frame entry. The reasoning is the following: The first one is already used for some primitives, the last one encodes the class in the case that there is a supersend in the method. So if we use the last entry to store the class for each method (supered or not), we can put the annoations in the one before and don't need to test for anything. Putting the class (or Trait) in the last litereal has the nice side-effect of making a fast #who possible. The changesets attached are a first step: We are right now adding the class binding to all methods but quickmethods (need to fix that), the second last literal is initialized with nil and will lazy initalize the property dictionary if it's accessed. Please note that the attached changesets need to be files in in-order and the first one will recompile the whole image. Filling the last literal with the class (or trait) for all methods will be done in an addional step after the annotation cs is in 3.9. Then we will change the implementation of compiledMethod>>who to use this information. Any comments? Does anyone see a problem with the annotations itself or the implementation? Marcus

13 28

About MAC VM
by stéphane ducasse 13 Sep '05

13 Sep '05

hi john I hope your travel back was good. It was good to have you around at ESUG. I wanted to know if this would be possible that when we double click on an image and that there is already one squeak running, we get another one. Because now we are all copying VM around. Stef

5 8

New edition of LookEnhancements
by John Pierce 10 Sep '05

10 Sep '05

Hi all, LookEnhancements version 19 is now on http://squeak.saltypickle.com. In a moment of inspiration this morning I added a fix per Stephan Ducasse (to make Monticello tool windows follow suit with respect to the buttons). I also added a nice mouse over highlight effect to the buttons. In this case PluggableButtonMorph was modified. I did not modify SimpleButtonMorphs for the time being. Let me know what you think and if you think we should open this package to community editing or inclusion in the base image. Right now keep any comments coming -- I'll try to keep on top of the suggestions that fit the style I'm trying to put in place. Regards, John -- It's easy to have a complicated idea. It's very very hard to have a simple idea. -- Carver Mead

4 4

Jump to page: