Squeak-dev February 1999

squeak-dev@lists.squeakfoundation.org

148 participants
356 discussions

Possible fix for Form>>bmpColorsFrom:count:depth:
by Kevin Fisher 02 Feb '99

02 Feb '99

Ok I went ahead and tried to fix the problem I was having yesterday with the BMPFile reader in class Form. The problem that I encountered was that if a colour map was read that contained less than the total number of colours possible (specified by 2^depth), then the remainder of the colour map was set to 'nil' as opposed to some valid colour value. This caused problems with other classes that index the colourmap up to the total size of the map as opposed to the total number of colours that are actually in the map (confused yet? :). If you want to see the bug in action just try creating a ThreePhaseButtonMorph using an 8-bit bitmap using less than 256 colours! With my fix there is no problem, the bitmap gets displayed okay. Anyway, here's my fix...I just set any uninitialized entries in the colourmap to 'black'. If there's a more correct way to do this, please let me know! 'From Squeak 2.3 of January 14, 1999 on 2 February 1999 at 1:37:04 pm'! !Form class methodsFor: 'BMP file reading' stamp: 'kgf 2/1/1999 16:04'! bmpColorsFrom: aBinaryStream count: colorCount depth: depth "Read colorCount BMP color map entries from the given binary stream. Answer an array of Colors." | maxLevel colors b g r | colorCount = 0 ifTrue: [ "this BMP file does not have a color map" "default monochrome color map" depth = 1 ifTrue: [^ Array with: Color white with: Color black]. "default gray-scale color map" maxLevel _ (2 raisedTo: depth) - 1. ^ (0 to: maxLevel) collect: [:level | Color gray: (level asFloat / maxLevel)]]. colors _ Array new: (2 raisedTo: depth). 1 to: colorCount do: [:i | b _ aBinaryStream next. g _ aBinaryStream next. r _ aBinaryStream next. aBinaryStream skip: 1. colors at: i put: (Color r: r g: g b: b range: 255)]. colorCount to: (colors size) do: [:i | colors at: i put: (Color r: 0 g: 0 b: 0 range: 255)]. ^ colors ! !

1 0

Re: FileStream (BUGS FIXES)
by David Farber 02 Feb '99

02 Feb '99

>Also tried 'root/fullpathto/ChangeSets/foo.b' and had no problem. This >makes me think that there may be differences in how our various VMs >consider their paths (well, duh) and that we are not yet covering all the >bases. David's original problem looks to me as if his machine is behaving >rather like my Acorn in that the default directory for the OS is not >neccessarily that where Squeak is living. If this is so, then attempting to >open a file 'email\text.1' might be trying to find 'c:\email' rather than >'c:\squeakpath\email' or something like that. yep, that's it, although there is a slight twist. the "root" happens to be the windows desktop! (which is buried several directories deep on the C: drive). i am not sure what the full ramifications of all this is. i need to play with this some more and try to get a better feel for what exactly is going on. hopefully i'll be able to do that this week and report back with a bug fix. dave -- j. david farber oo architect+mentor numenor labs incorporated in sunny boulder colorado dfarber(a)numenor.com www.numenor.com

1 0

Re: Odd behaviour in Sq22 Win32 network code?
by Colin Sarsfield 02 Feb '99

02 Feb '99

>There was a discussion on this list a while ago about it being a generally >Good Thing to use the BSD accept() semantics rather than the MacTCP >semantics. Has anyone got a working VM/VI with the new semantics? If not, >I can write UNIX and NT/95 versions of two new primitives (something like >primSocket:BSDListenOn:depth: and primSocket:BSDAcceptInto:) and the >corresponding system code, plus tweeking bits of current flow. Ian? >Andreas? Do you have anything like these? Other VMers: How much of a pain >would it be to support these, given that even the Mac is losing MacTCP and >going to BSD listen()/accept() semantics? This would be good for BeSqueak (BeOS port) as BeOS API supports a subset of BSD. My only concern would be that the primitives be as forgiving as is reasonable for subset BSD implementations, and be flexible enough for non BSD implementations. Colin Sarsfield

1 0

RE: Windows MIDI utilizes software MIDI, not Mac
by agree＠carltonfields.com 02 Feb '99

02 Feb '99

Tim is, of course, quite correct. On the other hand, such coverage is very substantial and should not be ignored. A rigid view of platform independence would preclude the use of any non-squeak-software-generated sound mechanism, including the MIDI external interface via serial means. I'm simply suggesting that we should not be so squeak-centric as to exclude software sources producing outstanding sound, such as Quicktime when the interface shouldn't be that hard to make. One we allow non-squeak components such as external hardware, why not also provide an interface to leading software components as well? (I know one answer to this, and I'm working on that problem right now.) Anyway, at the end of the day, if people want it, they will build it. If they don't, they won't. -----Original Message----- From: MIME :rowledge@interval.com Sent: Tuesday, February 02, 1999 12:09 PM To: squeak(a)cs.uiuc.edu Subject: RE: Windows MIDI utilizes software MIDI, not Mac On Tue 02 Feb, agree(a)carltonfields.com wrote: > I'm not sure I understand the problem. First, QuickTime is plenty > platform-independent, at least to the extent it adequately covers Mac and PC. > (Is there a Unix Flavor?) Merely covering macs and pcs does not count as platform indepenent :-) -- Microsoft: partying like it's 1899.... Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 842-6110 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim> << File: ENVELOPE.TXT >>

1 0

RE: Windows MIDI utilizes software MIDI, not Mac
by J Chapman 02 Feb '99

02 Feb '99

>(Is there a Unix Flavor?) Even so, why wouldn't it make sense for the MIDI >synthesizer to be componentized, so that the "front-end" can be used with a >host of applications including, but not limited to Squeak, the several MIDI >synthesizers available via serial lines AND Quicktime, Microsoft Media, etc? There are any number of MIDI players for Unix operating systems. I'm not sure of its status, but Apple is meant to have a Quicktime for Java, which would increase its portability a great deal. The remaining question, of course, is whether Quicktime for Java is as good and featureful as a native code implementation.

1 0

Re: Windows MIDI utilizes software MIDI, not Mac
by Mark Guzdial 02 Feb '99

02 Feb '99

At 2:38 PM -0800 2/1/99, Stephen Travis Pope wrote: >> The Mac has such a software MIDI synthesizer built-in, available through >> QuickTime. Is it possible to be able to access it the same way that >> Windows Squeakers can access their software synthesizer? > >The OMS MIDI libraries support the QuickTime MIDI instruments as another >output, and >can play from Squeak through the Siren primitives quite well. And it's really fabulous quality! But it's not as cross-platform as we'd like for our purposes. Our application is a cooperative radio station. Currently, we have a Swiki on which users can upload WAV, AIF, or MIDI files and can edit a PlayList. We have a JukeBox process reading the playlist and playing the files through Mac audio and an external MIDI synthesizer. The output of the Mac audio and the external MIDI synthesizer is piped into an FM Transmitter. This gives us a cooperative radio. While the FM Transmitter is the maximum power allowed without an FCC License (under Section 15 rules), it's still pretty low-powered. Because of machine rooms, fire walls, and the like, we can't reach most of our College building. We've built an AM Transmitter (and I have the soldering iron burns to prove it :-), but it's really hard to get as clear a signal with AM. So, now we're exploring putting the JukeBox process on each users' desk. Aibek Musaev is building a Squeak JukeBox that reads the playlists and all files off the Web, and does the MIDI synthesis from Squeak. Cross-platform is a "must" here -- we run the whole range in this building. But we'd like to get higher quality than the current Squeak MIDI Synthesizer. Maybe we could use Siren for Macs, base Squeak for Windows using the Soundblaster/Yamaha synthesizers, and base Squeak for UNIX with sound patches like Lex's for Linux. But it would be easier for us if we could just write for Squeak (or Siren) and not have to manage multiple versions. Thanks for the suggestion! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

1 0

translation of #to:by:do:
by Luciano Notarfrancesco 02 Feb '99

02 Feb '99

While playing with the pluggable primitives I noticed that the translator to C assumes that the step in #to:by:do: is always positive... so for negative steps the translated code fails. Luciano.-

1 0

RE: Odd behaviour in Sq22 Win32 network code?
by Peter Crowther 02 Feb '99

02 Feb '99

> There's a Grade 1 bug in Microsoft's TCP/IP > stack (PSS ID Q177074 of 12 Nov 1998) that basically means that spawning > new > listening sockets may fail *silently* until all sockets that were children > of the original listening socket (all 1 of them in the current > implementation) are closed. No known fix. > My mistake, NT Service Pack 4 fixes it. Not that I fancy applying that to Windows 95 :-). My comments about writing a couple of new primitives still apply. - Peter

1 0

Re: 2.3 for Unix
by Bert Freudenberg 02 Feb '99

02 Feb '99

On Tue, 2 Feb 1999, Markus Kohler wrote: > Ian Piumarta wrote: > > > > ftp://alix.inria.fr/pub/squeak/unix/2.3 contains the usual stuff for: > > > > alpha-osf1-v4.0 > > i386-linux-2.0.36 (linked against glibc-2.0.7) > > i386-linux-2.1.24 (linked against libc-5.4.38) > > sparc-solaris-2.5.1 > > sparc-sunos-4.1.4 > > > > Can anyone confirm that Ballon works on these platforms ? It runs like a charm. What doesn't work so far is the new CursorWithMask (I see a larger, but still black Cursor) One thing I noticed is that glibc is a lot slower?! See this Integer benchmarks: Ian's i386-linux-2.0.36 (glibc): 14662000 Ian's i386-linux-2.1.24 (libc): 21097000 My i386-linux-2.0.33 (libc): 19841000 Any explanation? Bert -- Bert Freudenberg Department of Simulation and mailto:bert@isg.cs.uni-magdeburg.de Computer Graphics http://isgwww.cs.uni-magdeburg.de/isg/bert.html Univ. of Magdeburg

1 0

RE: Squeak in IEEE Software
by Ralph Johnson 02 Feb '99

02 Feb '99

>How do you measure 'progress' in projects written in O-O languages? If we can measure the progress of projects not involving software, we should be able to do it for any software project. Make a list of all the features that your project should support. Make a list of the various deliverables, ESPECIALLY having the feature running in the system, but including earlier design stages. Make a schedule of all the deliverables. If a date comes, and you haven't delivered, you are off schedule. As long as you keep producing deliverables, you are making progress. Of course, some deliverables are better indicators than others. In my experience, design documents are not nearly as good an indication of progress as working and tested code. You are better off if you can build your system in lots of small increments, because then the only measure you need is "system passes tests for feature X". If you have 500 features, and it passes the tests for 250 of them, you are probably half done. For a more complete description of this (well, actually it is a complete methodology, in which this is just a piece) see http://c2.com/cgi/wiki?ExtremeProgramming -Ralph

1 0

Jump to page: