Squeak-dev February 2005

squeak-dev@lists.squeakfoundation.org

191 participants
430 discussions

MAC Bug?
by stéphane ducasse 25 Feb '05

25 Feb '05

Hi john when I do full screen then full screen off I do not get back the window title bar so this means that I missed a part of the squeak window and I cannot move the squeak window as any other window. I have a save, quit and relaunch to get this effect. Stef

1 0

Re: Improving Squeak's Multimedia - Part 2 Followup
by Brad Fuller 25 Feb '05

25 Feb '05

Thanks for the reply Russell. See below Russell Penney wrote: > Brad, > > I am seeing a lot of synergy actually. You do the audio tidy up, > Blake does tools and doco, Dean does some very cool low level stuff > which I sure forms the basis of a bunch of later work (i.e. better > algorithms for OGG, etc than straight ports of "C"), Yoshiki, Martin > and others do video, I handle file formats (with lots of help :) and > the others test. > > > > The main things I see happening from here that we need to resolve ASAP > are a bunch of questions. > > What do people see as the interfaces? > > What have others seen in a multimedia framework? Is there a good one > we can steal, I mean be influenced by. > > What are the lowest common denominators? > > What functionality does everyone want? > I think it's a bit more than that, at least in the audio area clean up -- not hard, but we need agreement from a few more people that are smarter than me. I don't want to go about changing the concept of the audio functionality (which is needed IMHO) w/o agreement from both the people who will use it, and from the general community on how it will fit into the overall design/usability of Squeak. From my experience, some audio classes are intertwined. For instance: something you probably already found, AbstractSound has instance methods that store audio files. Some of these methods use other audio class methods. As an example: AbstractSound>>storeAIFFSamplesOn: uses the SoundPlayer samplingRate class variable -- and this class variable is hard coded at initialize -- not good for the SoundPlayer tool and worse, it makes storeAIFFSamplesOn: not reusable. This isn't a hard problem to fix in code -- but it is in the overall design of the system: I think it boils down to what object should maintain attributes of the audio capture -- a design issue. I think it's obvious, but we just need agreement before we change the design. (ok, maybe it's not a great example cause it's easy. But, I've had to override audio classes so that I could make them usable -- I didn't want to fork off and not be compatible with future versions.) Other things are easier to tidy up. For instance, the same method uses an instance method named AbstractSound>>isStereo --- but it is hard coded to return 'false'. yuck. So, for me, I think we need to look at all the audio classes, uncover the problems, and come up with a design (and I'm not saying a complete redesign) and a plan to execute. > > > Just as an example what about these? > > aURI playVideo > > aURI playAudio > > aURI play "uses a specific player based on the file type" > > aURI edit "opens a specific editor based on the file type" > > aURI editAudio "opens an audio editor on just the audio > stream of the file" > > > > When we figure out where we want to get to, we can work out how to get > there. > > > > As for the question below, yes I am interested in re-useability, > something that everyone raves about for OO and Smalltalk but something > that Squeak is very bad at doing in practice. > > I am not a "programmer" although I program ;) so I will write code for > the framework. I already have a simple MM framework but I need some > help with the design, I am not experienced enough to know which are > the better OO ways of doing things. > > > > Russell > Can you explain more about what you mean by framework? What are you proposing and at what level? Is this an analysis of the current design? Or is this from a user perspective as you described above (aURI playAudio) If you take my example above that focuses on audio only, and blow it up to add other MM types, it becomes a bigger and more complicated design issue. Thus, my initial cry to the Squeak community. It's not rocket-surgery, but it's bigger than me. brad

1 0

[UPDATES] 7 more
by Michael Rueger 25 Feb '05

25 Feb '05

"Change Set: FixupAfterBigChange Date: 24 February 2005 Author: Yoshiki Ohshima Resolve the conflict and adds a few methods." "Change Set: Latin1supportedLang Date: 24 February 2005 Author: Yoshiki Ohshima Make sure all the languages in Latin1 get listed." "Change Set: localPlatform Date: 24 February 2005 Author: Yoshiki Ohshima CurrentPlatform class var should be set when you change the locale." "Change Set: FTPMultiLineFix-nk Date: 24 February 2005 Author: Ned Konz Fixes fetchNextResponse so that it properly handles multi-line FTP responses. " "Change Set: commentsFeb24 Date: 24 February 2005 Author: Yoshiki Ohshima Comments." "Change Set: OldSocketRefFixes-nk Date: 24 February 2005 Author: Ned Konz When Socket was renamed to OldSocket, references to the class weren't renamed. This CS does that renaming. " "Change Set: AnimatedImageFix-bf Date: 25 February 2005 Author: Bert Freudenberg Fixes incremental animated images as reported by Scott Wallace"

3 3

new MacOS Spoon VM available
by Craig Latta 25 Feb '05

25 Feb '05

Hi-- With help from John McIntosh (thanks!), I built a new MacOS (Carbon) Spoon VM. Stéphane had pointed out that the previous one had very poor graphics performance (when running a snapshot with graphics support :). This one feels "normal" to me. There are no new Spoon VM changes here, so I'm not sure why the last one was so slow. http://www.netjam.org/spoon/releases/current/bits/MacOSSpoonVM.zip thanks, -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org [|] Proceed for Truth! -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org [|] Proceed for Truth!

2 1

Re: [FIX] WatcherDoubleClickFix-nk ([closed] on Mantis 0000901)
by Larry Trutter 25 Feb '05

25 Feb '05

This fix has been posted on Mantis. thanks, Larry Trutter ned(a)squeakland.org wrote: >from preamble: > >"Change Set: WatcherDoubleClickFix-nk >Date: 24 February 2005 >Author: Ned Konz > >Double-clicking quickly on simple watcher just to the right of the >number causes a walkback because the editor has already been deleted. > >I believe that this bug was introduced in CS >6566-0385muchBetterWatchers-sw. > >This change set fixes that problem. > >"! > > >------------------------------------------------------------------------ > > > >

1 0

[FIX] CategorizerFix
by hmm＠heeg.de 25 Feb '05

25 Feb '05

from preamble: "Change Set: CategorizerFix Date: 25 February 2005 Author: Hans-Martin Mosner Fixes a bug with reading class organizations containing nil, true or false as message selectors. The cause of the bug: Recent Squeak versions changed parsing of literal vectors such that nil, true and false are not stored as Symbols but as the respective objects."!

2 1

Team proposal: Morphic Splitters
by Cees de Groot 25 Feb '05

25 Feb '05

Hi All, After the deafening silence on our plans, I take it you all agree with it but are just to shy to speak up in public ;) Anyway, here's a team proposal. I'm Team Leader Ad Interim - if someone else wants the job, there's a good chance I'll step down because I'll be busy enough as it is. Goal: split up Morphic into 'Mini Morphic' and 'Rest Of Morphic' Timeline: June/July Acknowledgements: Avi and Dan, I think. Details: Morphic has grown a bit big and ugly. This has had various reasons, all probably very good design decisions at the time they were made, but it's about time to clean up this legacy. A very big part of Morphic is 'just' there to support eToys (let me stress that we squeak-dev'ers are a minority user group!). We're lugging it with us, trying to keep it in shape, but we hardly use it. Also, because Morphic+eToys has grown such a big thing it is nigh impossible to clean it up. So, the immediate plan is to untangle this Gordian Knot - we have one handicap that Alexander didn't have: swords are not allowed ;) The MINIMAL deliverable of this project is: - CoreMorphic package. World/project support + the UI bits for ToolBuilder to operate. - FatMorphic package. All the rest of it. - eToys package. These packages should all be loadable/unloadable on demand. We'd like Squeak to become UI-neutral, so it must become simple to swap Morphic for MVC or vice versa (or for Tweak, wxSqueak, ...). CONDITIONS: - The community accepts that if this team is instated AND delivers at least the minimal deliverables, these deliverables will become part of the next release of Squeak after delivery. OPTIONAL deliverables: - While we're at it, make MVC a loadable/unloadable package; - Refactoring. Cutting out dead wood from especially FatMorphic that's not needed; - Further splitups of FatMorphic, if it turns out to be logical. DEPENDENCIES: - We use ToolBuilder to define what CoreMorphic is. I.e., whatever ToolBuilder needs, lands in CoreMorphic. Whatever ToolBuilder does not need, does not land into CoreMorphic. The project assumes that ToolBuilder will be in the image that will be used to release the Team's deliverables. NON-DEPENDENCIES: - We are not going to assume that any output from any package/modules team is ready in time. So straight PackageInfo is our basis. I repeat that a conditio sine qua non for this project is that eToys becomes loadable/unloadable and keeps working. So it's not a matter, as the 'strippers' do, of just cutting off the excess fat; it needs to be carefully trimmed of and kept apart. Which makes it a job not much more glorious than Ken's 'Janitors' Team ;). After we've delivered, the idea is to have people sign up for maintenance of these various packages, where my expectation is that the Squeaklanders will start taking care of the eToys package. Joining: Announce here on the list or through private mail to me. When no objections from the community arise and there are enough people that join up, I'll ask my colleague coordinators to declare it as a Team and setup list+swiki+MC storage. If you want to become the Team leader for this, please drop me a mail with motivation etcetera. Regards, Cees

8 16

animated gifs & frame-differencing
by Scott Wallace 25 Feb '05

25 Feb '05

It seems that Squeak does not take frame-differencing into account when internalizing and rendering animated gif files -- instead, it treats all frames as if they were full-animation frames. The result is that only the first frame of an animated GIF that uses frame-differencing is correctly rendered. Has anyone else encountered this bug? Anyone have a fix? Anyone inclined to *produce* a fix? Here's an example of an animated gif that uses frame-differencing: http://www.gifs.net/animate/alterego.gif If you view this from a web browser or any standard graphics tool, you'll see it in its intended form. Try viewing it in Squeak and you'll see the bug immediately. Cheers, -- Scott NOTE: To load *any* animated gif into Squeak (3.7 and beyond) you'll need Ned's fix from the other day (thank you, Ned!), which you can find at: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088875…

2 2

REMINDER: Harvesting Party Saturday February 26th 08:00 GMT
by Ken Causey 25 Feb '05

25 Feb '05

Just a reminder that the next Harvesting Party will take place between 08:00 (8 AM) and 12:00 (Noon) GMT Saturday February 26th, 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 Information about the Harvesting Party idea can be found at http://people.squeakfoundation.org/article/29.html If you have the time please attend and work toward the future of Squeak. The next seven parties are scheduled for 12:00 (12:00 PM) GMT Wednesday March 02, 2005 16:00 (04:00 PM) GMT Sunday March 06, 2005 20:00 (08:00 PM) GMT Thursday March 10, 2005 00:00 (12:00 AM) GMT Tuesday March 15, 2005 04:00 (04:00 AM) GMT Saturday March 19, 2005 08:00 (08:00 AM) GMT Wednesday March 23, 2005 13:00 (01:00 PM) GMT Sunday March 27, 2005

1 0

Shrinking sucks!
by Cees de Groot 25 Feb '05

25 Feb '05

I've been busy shrinking a 3.6(wx) image today. What a mess. My definitive, permanent, and irreversible conclusion is that writing package unloading/shrinking methods is probably even a more senseless activity than clubbing seals or writing Java code. I think that this is a very wrong way for moving towards a more managebly sized image. The community will probably take a couple of years to write, and maintain, package unload/discard methods (because the targets will be constantly changing - try any Removal method from SqueakMap and you'll see what I mean), and when there's a small image, at last, all that work can be, err, discarded. What a waste. My suggestion for whatever version comes next: - Take an existing 2Mb or so image (Edgar De Cleene has a 5429 image that includes MVC, tools, networking); - Read the update stream since the image was made and filter out everything that doesn't apply to that image; - Apply the rest; - Publish what was applied and what not for review; - Publish, test, and call that 3.x core. - Have some people pledge to build distributions based on that image. I will happily work towards building a wxSqueak and a Seaside distro. - Take it from there. Personally, I fear that trying to strip something that doesn't want to be stripped will take a lot of time, waste a lot of energy, raise a lot of frustration, and will not have a better end result than following the route I propose above. That route will hurt a lot initially and will require a lot of politics etcetera to keep teams from forking based on the old stuff (but at the moment, risks that people will fork out of frustration are just as big). But that will be done in maybe 6 months and then we can direct our energy towards actually doing useful stuff (better dependencies, universes, bringing in Traits, and for some die-hard 'Core Squeak' believers, tearing down even that 2Mb image).

23 109

← Newer
1
...
6
7
8
9
10
11
12
...
43
Older →

Jump to page: