Squeak-dev November 2005

squeak-dev@lists.squeakfoundation.org

163 participants
269 discussions

Re: MC passwords in images?
by Andreas Raab 04 Nov '05

04 Nov '05

Bert Freudenberg wrote: > Since Monticello-bf.266, passwords were removed at image startup. It > does not remove the user name, instead, you are asked for the password > if a user name is set but no password. > > Because people did not like having to re-enter the password after each > image start, Monticello-bf.268 changed that to reset the passwords only > if the author initials were reset, too. Ouch!!! This is so unbelievably naive I can hardly believe it. Does anyone besides me realize *when* exactly the author initials get cleared? It's when the full path to the image is different. So, let's say I have an image which at C:\Squeak\SqueakX.Y.image and I give that to somebody else and that person puts the image into C:\Squeak\ what do we get? We get all the passwords in nice and plain text. Cheers, - Andreas

3 3

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

Building lightweight things
by Chris Muller 04 Nov '05

04 Nov '05

For building lightweight things, this might be a good place to start and expand on it: http://www.bernardbelanger.com/computing/NaDa/index.php

2 1

Re: [croquet] MC passwords in images?
by Bert Freudenberg 04 Nov '05

04 Nov '05

Am 04.11.2005 um 20:08 schrieb Andreas Raab: > Hi Folks, > > I just noticed that I handed out a whole bunch of images with plain- > text passwords for various of the more sensitive repositories, > thanks a lot (and no, if you have one of those it won't work any > longer - I changed them). So for those of you who use MC and at > times pass images around it is probably useful to check who's been > in those repositories recently. Since Monticello-bf.266, passwords were removed at image startup. It does not remove the user name, instead, you are asked for the password if a user name is set but no password. Because people did not like having to re-enter the password after each image start, Monticello-bf.268 changed that to reset the passwords only if the author initials were reset, too. > Oh, and is anyone out there interested in implementing a password > manager that stores passwords *outside* of an image in a reasonably > secure location? I did, a while ago (in Monticello-bf.238 from 14 April 2005): userAndPasswordFromSettingsDo: aBlock "The mcSettings file in ExternalSettings preferenceDirectory should contain entries for each account: account1: *myhost.mydomain* user:password account2: *otherhost.mydomain/somerep* dXNlcjpwYXNzd29yZA== That is it must start with 'account', followed by anything to distinguish accounts, and a colon. Then comes a match expression for the repository url, and after a space the user:password string. To not have the clear text password on your disc, you can base64 encode it: (Base64MimeConverter mimeEncode: 'user:password' readStream) contents " - Bert -

1 0

Re: [SqueakAudio] PortAudio Port Help Request
by Stephen Travis Pope 04 Nov '05

04 Nov '05

I guess the first comment should be that the VW interface doesn't work reliably and has been adandoned. I'll describe it and explain. In VW, you can use the DLLCC (dynamic linked library and C connect) API to link ST80 with external APIs. It's supposedly easier to use than the user primitives interface. The tool can parse a C header file and create a Smalltalk mirror class with glue code for calling the C functions. Users can write C code that signals Smalltalk semaphores or creates other callbacks. The PortAudio API is based on registering a callback function with the sound driver; this gets called for every buffer of output, i.e., on the order of every couple msec or so. In a well-behaved app., the callback simply copies sample data from a stored buffer into the requested buffer, signals the "producer" thread, and returns. I think that the VW semaphore mechanism is too slow for this, but never got around to tracing it more closely. My work in ST80 is mainly about controlling external synthesis SW from Smalltalk, meaning that we use the OpenSoundControl protocol (OSC) to control synthesis servers, instead of doing the synthesis and sound output from ST. This is why I never finished the sound IO stuff, though it would be really interesting to have working... At any rate, the glue code I have for PortAudio in VW ought to be quite useable for a Squeak FFI interface, *if* the callback triggering method is fast enough to service the callbacks. I'll attach a smaller zip file with just the related C and ST code. Take a look at the README file and the ST source for the glue code (the external interface classes) and the "port" classes. stp -- Stephen Travis Pope -- http://create.ucsb.edu/~stp Dept. of Music and Grad. Program in Media Arts and Technology University of California, Santa Barbara Begin forwarded message: > From: Brad Fuller <brad(a)sonaural.com> > Date: November 3, 2005 8:26:19 AM PST > To: Stephen Travis Pope <stp(a)create.ucsb.edu>, > squeakaudio(a)create.ucsb.edu > Subject: Re: [SqueakAudio] PortAudio Port Help Request > > > Stephen Travis Pope wrote: > > >> >> Hey, this sounds interesting! We've built loads of PortAudio >> interfaces, including for VisualWorks. It's all pretty easy, but >> you have to manage the timing of the audio call-backs and >> Smalltalk semaphores carefully to avoid dropping buffers. There's >> cross- platform VW wrapper code (using the DLLCC Smalltalk-to-C >> API) in the Siren7 release (http://www.create.ucsb.edu/Siren/ >> Siren7.2.tgz). >> >> stp >> > > Thanks Stephen! > I know nothing about WV wrapper method. How (dis)similiar is it to > Squeak primitives or FFI? Any more wisdom of your PortAudio<->VW > journey is most welcome. > > What version of PortAudio have you linked to? > > >> >> -- >> Stephen Travis Pope -- http://create.ucsb.edu/~stp >> Dept. of Music and Grad. Program in Media Arts and Technology >> University of California, Santa Barbara >> >> >> Begin forwarded message: >> >> >>> From: Brad Fuller <brad(a)sonaural.com> >>> Date: November 1, 2005 10:43:33 AM PST >>> To: Squeak List <squeak-dev(a)lists.squeakfoundation.org>, >>> squeakaudio(a)create.ucsb.edu >>> Subject: [SqueakAudio] PortAudio Port Help Request >>> >>> Anyone interested in working with me on porting PortAudio >>> (http:// portaudio.com/) to Squeak? I've never built a primitive >>> before although I've gotten the Linux 3.8 VM to build using >>> VMMaker (whew.) So, if you have experience in this area, that >>> would be an added bonus! >>> >>> I want to start on Linux first using v19 preferably with the >>> JACK (http://jackit.sourceforge.net/) interface,. But ALSA >>> (http://alsa- project.org/) would be fine for now. Linux >>> primarily because of the free C tools - I have no C tools for >>> Windows or Mac. But, if someone would like to help and start >>> with Windows, I could get tools. (I don't have a MAC at my >>> disposal right now. But, if you'd like to start on MAC, I could >>> potentially get one.) >>> >>> Please let me know online or off if you're interested. I think >>> it would make a great addition to the usefulness of Squeak for >>> audio and video. >>> >>> thanks, >>> >>> brad >>> >> >> >> >> >> > > > -- > Brad Fuller > (408) 799-6124 > ** Sonaural Audio Studios ** > (408) 799-6123 West San Jose > (408) 799-6124 Cambrian > ________________________________ > Hear us online: www.Sonaural.com > See me on O'Reilly: http://www.oreillynet.com/pub/au/2184 >

1 0

no queue class in base?
by Martin Kuball 04 Nov '05

04 Nov '05

Hi! I'm looking for a queue class in squeak. The only class I found is SharedQueue. But I don't need synchronization. Sure, if there is really none I could write one in minutes. But I wonder if it makes sense to add such an elementary data structure to the base collection stuff. Martin

5 5

Integration of ToolsPlus
by stéphane ducasse 04 Nov '05

04 Nov '05

Hi andreas was it in your code that ChangeSorter lost some of his ClassVar: AllChangeSets PreviousSet TextMorphEditor ParagraphEditor I'm trying to understand what happened? Stef

2 4

Pending Mac Carbon VM 3.8.9b7 posted
by John M McIntosh 04 Nov '05

04 Nov '05

I've posted a macintosh VM 3.8.9b7 See http://www.smalltalkconsulting.com/squeak.html It's fixes to issues raised by the 3.8.9b5 distribution. If there are no complaints raised over the next day or two (please check) then I'll ask if this can go into the current mac distribution dmg on the main download site. 3.8.9b7 sqMacMain.c #ifdef change to enable compile under os-9 sqMacUIAppleEvents.c Handle case where the file name ends with *.image but we have no hfs meta data. sqMacUIEvents.c #ifdef change to enable compile under os-9. sqMacWindow.c Recheck window handle on window open, or window title set. 3.8.9b2,b3,b4,b6 had limited distribution for testing This VM also contains the OS-9 executable in the bundle. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

6 12

Re: RFD - Envy-like MC repository
by Chris Muller 04 Nov '05

04 Nov '05

> getting rid of the changes file). Then, saving an MC version is merely > a matter of noting the current versions of all the classes/methods in > the MC package, Yea persisting object-representations of the code-domain directly would be real nice; it would eliminate all of the redundancy and wasted disk space that comes with building a new mcz every time. While Magma can currently be used as a Monticello repository out of the box, but I doubt whether the redundancy is eliminated because I think Monticello builds an entirely new object-structure to fully represent each version, there is no sharing. > It gets hairy when I start to think about multiple images being > connected to the db - how do you keep your stuff apart? I haven't > thought much about all that, so therefore an RFD here. If people have > ideas to share, or comments on the code, I'd be delighted to hear it. How often do you want the 100th version ago of a method dated back forever? I actually kind of like how getting a new image starts clean with all of the method histories. I usually only care to know what I've been doing *lately*. As great as ENVY was, I don't really miss it; Monticello is too good. BUT it is short the same thing that ENVY was missing; object resources. While Magma can deliver an arbitrary object-model with a Monticello code repository, there is no associating versions of code with versions of the object model.. - Chris

4 4

Light-weight monitor implementation?
by Andreas Raab 04 Nov '05

04 Nov '05

Hi Folks, I was looking for a simple monitor implementation (e.g., a mechanism for mutual exclusion which allows the same process to enter it multiple times) and looked at the implementation of Monitor that is present in 3.9. Much to my surprise, I found that this monitor implementation is a very heavyweight version of what should essentially be three methods, e.g., #enter, #leave, and #critical:. The extra heavy-weight behavior might be useful in certain specific cases but I wonder about its general applicability (personally I find it more confusing than helpful because it hides the nature of a monitor under a lot of extra baggage). I think it would be tremendously useful to do a little refactoring which a) makes a tiny class Monitor and b) makes a heavy-weight EventMonitor which has all the extra stuff (timeout, events) that is now in Monitor. What do other people think? Is there any reason for Monitor being such a heavy-weight object by default? Is it necessary that a monitor support all of the extra functionality besides the basic "allow a process to enter it multiple times"? Cheers, - Andreas

13 28

Jump to page: