Squeak-dev April 2000

squeak-dev@lists.squeakfoundation.org

141 participants
506 discussions

RE: Playing Movie Files?
by Jeff Szuhay 28 Apr '00

28 Apr '00

At 9:34 AM +0200 4/27/00, Torsten.Bergmann(a)phaidros.com wrote: > It's a squeak special movie file type. I'v created > an example on the wiki telling you how to create an > own movie files > > http://minnow.cc.gatech.edu/squeak/978 > Well, after thinking about it a bit (thank you, Bert and Alan), I must apologize for my original post on this matter to Torsten. I was misguided in thinking there was already an open source movie codec. A working means of doing something is far better than none. Too bad the movie codecs are not yet open source. (now that would be a new standard I'd welcome... an open source movie codec -- is the issue mostly around compression algorithms?). 8-) -- **************************************** Jeff Szuhay <mailto:jeff@szuhay.org> Oakmont, Penna. <http://www.szuhay.org>

2 1

[ENH] Celeste sends attachments
by Daniel Vainsencher 28 Apr '00

28 Apr '00

Allows sending attachments, shows incoming parts even if recursively embedded. Comments, bugs, whatever - most welcome. Oh, I know, it must seem suspect - "Why doesn't he use his own ENHs?" Well, I can't seem to remember where the heck in my filesystem I left my net configuration files, so I can't configure Celeste! 8-(

1 0

RE: Squeak vs. Java
by Boyers, Albert 27 Apr '00

27 Apr '00

The embrace and extend model works best. I think that writing a Java VM in squeak would have far reaching positive implications. I suspect it would not be that hard (but I'm just a lurker not a squeaker, yet). Squeak would pick up a huge API from Java (not necessarily a good thing), and Java developers would have access to sophisticated debug/developing environments. Smalltalk would always be there waiting to be used. The flip side, smalltalk in java (http://www.architur.de/talks2/ which is truly cool) does nothing for smalltalk. -al > -----Original Message----- > From: Stefan Matthias Aust [mailto:sma@3plus4.de] > Sent: Thursday, April 27, 2000 4:09 PM > To: squeak(a)cs.uiuc.edu > Subject: Squeak vs. Java > > > Jalapeno is a Java VM by IBM written in Java. Does this sound > familiar? An interesting paper about this JVM lists > arguments why Jalapeno > is superior to existing VMs (including HotSpot) on the server > side. Keep > reading, I'll explain why I list them in a minute. Here are > the topics: > > 1. Exploitation of high performance processors > 2. SMP scalability > 3. No Thread limits > 4. Continuous availability > 5. Rapid response > 6. Library usage > 7. Graceful degradation > > And here are the arguments, slightly rephrased together with > my comparison > with Squeak. > > ad 1. Current JITs don't do enough optimization. By using a > high-level > language to implement their VM, they can handle the complexity and > correctly implement more complex optimizations. This isn't > supported by > Squeak (yet), but most other arguments are also true for > Squeak and that's > IMHO amazing. > > ad 2+3. By not using native thread but doing their own > simulation they get > a better scalability and don't run in operation system thread limit > (Windows NT, I think, support only less than 2000 threads for > example). Squeak also has this feature. > > ad 4. Servers must run pretty damn stable, several months (or > at least as > long as the underlying operation system supports :-) and > using Java with no > pointers, safe GC, bound checking of arrays and so on helps > to omit (the > usual) memory leaks. Squeak also has this feature, at least > as long as you > test the simulated VM. > > ad 5. A non-incremental GC (as this often is implemented to stop all > threads before doing a global collection) may cause long > delays. As I > think Squeak as an incremental GC, it doesn't suffer as > Jalapeno does not. > > ad 6. Jalapeno optimizes and compiles not only code but also existing > libraries including its own normally "native" runtime code > which helps to > do inlining and type check suppression by better type > inference. A similar > think is true with Squeak, as all primitives are written in > Squeak, you can > selectively compile some of them to C or not, the code will > always run, > although faster or slower. If this would be automatic, we'd > have the same > advantages as Jalapeno. > > ad 7. A server should not crash when overloaded but should > try to stay > alive and at least continue slowly. Not crashing under all > circumstances > is also true for Squeak. > > So I'd say, Squeak is a pretty good platform for implementing server > applications - especially once we get a Jitter for even better > performance. It's memory footprint is even smaller than for > typical JVMs > and so probably also for Jalapeno. > > Comments? > > bye > -- > Stefan Matthias Aust // ...dancing on the dark side of moon >

1 0

GalleyView
by Smilie 27 Apr '00

27 Apr '00

Attached is the code for my GalleyViewer. I created it as part of my Sr. project. It is a flat class viewer, that contains the entire class within one window. From inside of this window, you can edit and compile your code. Enjoy. -------------------- Jen a.k.a. Smilie :-P smilie(a)cc.gatech.edu

2 1

Re: Squeak vs. Java
by Peter William Lount 27 Apr '00

27 Apr '00

Hi, Stefan Matthias Aust > as all primitives are written in Squeak While this is true for most primitives it's not true for the "operating system" support "interface" files and primitives that are currently written in C. Also the Squeak threads are not true pre-emptive threads (if I'm not mistaken that is)... Will they be pre-emptive in the new jitter? All the best, Peter William Lount peter(a)smalltalk.org

1 0

Refactorings (was RE: [Newbie] Dolphin Smalltalk Tutorial)
by Doug Way 27 Apr '00

27 Apr '00

(Sorry to respond a little late to this thread...) On Mon, 24 Apr 2000, Stefan Matthias Aust wrote: > + Instead of waiting for the big redesign-time which will never come, > continuous small refactorings (together with deprecating compatibility > methods and documenting the goal towards one will refactor) will > probably reach the goal faster. Just wanted to pipe in and agree with this. I think this is especially true for a lot of Morphic. Squeak Central may or may not do a big redesign of Morphic in the future. (Last I heard, it wasn't in their schedule, but I'm not positive about this. Any status?) Refactoring smaller parts of Morphic so that something is expressed more clearly, or duplicated code is factored out, is a good thing either way, and should be encouraged. A successful small refactoring of something should make a major redesign at a later time *easier*, not harder. So, let's see some refactorings submitted to this list, along with the [FIX]es and [ENH]ancements! :-) I know there are people out there who have refactored/cleaned up parts of Morphic, but have been reluctant to post their changes, since they thought a major redesign was coming soon. (Stefan's point about documenting, and deprecating compatibility methods is important, too...) - Doug Way EAI/Transom Technologies, Ann Arbor, MI http://www.transom.com dway(a)mat.net, @eai.com

1 0

[BUG][FIX] CORRECTED: PNGReadWriter tweaks
by Duane Maxwell 27 Apr '00

27 Apr '00

Sorry - attached the wrong changeset - correct one attached. ---------------------------------- Change Set: PNGTweaks Date: 27 April 2000 Author: Duane Maxwell/EntryPoint This is a changeset to Squeak 2.8a #2040. It deals with a couple of bugs in the PNGReadWriter class. 1) fixes bug with unusual-depth odd-sized non-interlaced indexed images 2) fixes bug with extremely small interlaced images (even Netscape has a bug here) With this changeset, all of the non-corrupt images at: http://www.cdrom.com/pub/png/pngsuite.html should be correctly rendered to the degree we support PNG's esoterica. Note that this page contains three intentionally corrupt images which may cause walkbalks.

1 0

[BUG][FIX] PNGReadWriter tweaks
by Duane Maxwell 27 Apr '00

27 Apr '00

Change Set: PNGTweaks Date: 27 April 2000 Author: Duane Maxwell/EntryPoint This is a changeset to Squeak 2.8a #2040. It deals with a couple of bugs in the PNGReadWriter class. 1) fixes bug with unusual-depth odd-sized non-interlaced indexed images 2) fixes bug with extremely small interlaced images (even Netscape has a bug here) With this changeset, all of the non-corrupt images at: http://www.cdrom.com/pub/png/pngsuite.html should be correctly rendered to the degree we support PNG's esoterica. Note that this page contains three intentionally corrupt images which may cause walkbalks.

1 0

Re: [FIX][ENH] SortedCollection robustness & speedup
by Florin X Mateoc 27 Apr '00

27 Apr '00

Georg, I am afraid your implementation of the #includes: method only works for the particular cases where the object is arithmetically compared directly. I took a stab at (re)implementing #includes and #indexOf: for the SequenceableCollection classes. 'From Squeak2.8alpha of 19 January 2000 [latest update: #2042] on 26 April 2000 at 4:01:18 pm'! !SequenceableCollection methodsFor: 'accessing' stamp: 'fm 4/26/2000 15:13'! indexOf: anElement "Answer the index of anElement within the receiver. If the receiver does not contain anElement, answer 0." 1 to: self size do: [:i | (self at: i) = anElement ifTrue: [^ i]]. ^ 0! ! !SequenceableCollection methodsFor: 'testing' stamp: 'fm 4/26/2000 15:36'! includes: anObject ^(self indexOf: anObject) ~~ 0! ! !OrderedCollection methodsFor: 'accessing' stamp: 'fm 4/26/2000 15:39'! indexOf: anObject firstIndex to: lastIndex do: [:index | anObject = (array at: index) ifTrue: [^index + 1 - firstIndex]]. ^ 0! ! !SortedCollection methodsFor: 'accessing' stamp: 'fm 4/26/2000 15:08'! indexOf: newObject | index low | low := self indexForInserting: newObject. sortBlock isNil ifTrue: [ index := low -1. ^[index >= firstIndex and: [(array at: index) = newObject] ] ifTrue: [low - firstIndex] ifFalse: [0]] ifFalse: [ index := low -1. [index >= firstIndex and: [(sortBlock value: (array at: index) value: newObject) and: [sortBlock value: newObject value: (array at: index)]]] whileTrue: [(array at: index) = newObject ifTrue: [^index + 1 - firstIndex]. index := index - 1]. index := low. [index <= lastIndex and: [(sortBlock value: (array at: index) value: newObject) not and: [(sortBlock value: newObject value: (array at: index)) not]]] whileTrue: [(array at: index) = newObject ifTrue: [^index + 1 - firstIndex]. index := index + 1]. ^0]! ! Cheers, Florin P.S. I have also included the above code as an attachement(See attached file: collections.1.cs) <snip> !SortedCollection methodsFor: 'testing' stamp: 'go 4/27/2000 13:05'! includes: anObject "Answer whether anObject is one of the receiver's elements." | idx | idx := self indexForInserting: anObject. ^(array atPin: idx) = anObject or: [(array atPin: idx - 1) = anObject ]! ! <snip>

1 0

Squeak vs. Java
by Stefan Matthias Aust 27 Apr '00

27 Apr '00

Jalapeno is a Java VM by IBM written in Java. Does this sound familiar? An interesting paper about this JVM lists arguments why Jalapeno is superior to existing VMs (including HotSpot) on the server side. Keep reading, I'll explain why I list them in a minute. Here are the topics: 1. Exploitation of high performance processors 2. SMP scalability 3. No Thread limits 4. Continuous availability 5. Rapid response 6. Library usage 7. Graceful degradation And here are the arguments, slightly rephrased together with my comparison with Squeak. ad 1. Current JITs don't do enough optimization. By using a high-level language to implement their VM, they can handle the complexity and correctly implement more complex optimizations. This isn't supported by Squeak (yet), but most other arguments are also true for Squeak and that's IMHO amazing. ad 2+3. By not using native thread but doing their own simulation they get a better scalability and don't run in operation system thread limit (Windows NT, I think, support only less than 2000 threads for example). Squeak also has this feature. ad 4. Servers must run pretty damn stable, several months (or at least as long as the underlying operation system supports :-) and using Java with no pointers, safe GC, bound checking of arrays and so on helps to omit (the usual) memory leaks. Squeak also has this feature, at least as long as you test the simulated VM. ad 5. A non-incremental GC (as this often is implemented to stop all threads before doing a global collection) may cause long delays. As I think Squeak as an incremental GC, it doesn't suffer as Jalapeno does not. ad 6. Jalapeno optimizes and compiles not only code but also existing libraries including its own normally "native" runtime code which helps to do inlining and type check suppression by better type inference. A similar think is true with Squeak, as all primitives are written in Squeak, you can selectively compile some of them to C or not, the code will always run, although faster or slower. If this would be automatic, we'd have the same advantages as Jalapeno. ad 7. A server should not crash when overloaded but should try to stay alive and at least continue slowly. Not crashing under all circumstances is also true for Squeak. So I'd say, Squeak is a pretty good platform for implementing server applications - especially once we get a Jitter for even better performance. It's memory footprint is even smaller than for typical JVMs and so probably also for Jalapeno. Comments? bye -- Stefan Matthias Aust // ...dancing on the dark side of moon

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
51
Older →

Jump to page: