Squeak-dev January 2005

squeak-dev@lists.squeakfoundation.org

134 participants
235 discussions

[BUG][Partial Fix] Paragraph>>asForm
by Michael Latta 30 Jan '05

30 Jan '05

Image 3.7 current full version. This method behaves contrary to the example included in the method, and contrary to my expectation. The method forces foreground color to black and background to white. It goes to great lengths to do this to support a ColorForm with 2 colors, except that in the case of a TTCStyle it uses a Form with depth 32. It looks like a clear bug. I have yet to figure out how to create the form with all transparent pixels. The constructor creates it as black fill, and using "over" or other rules do not replace it with Color transparent. Michael asForm "Answer a Form made up of the bits that represent the receiver's displayable text." | theForm oldBackColor oldForeColor | oldBackColor _ backColor. oldForeColor _ foreColor. textStyle isTTCStyle ifTrue: [ theForm _ (Form extent: compositionRectangle extent depth: 32) offset: offset. theForm fill: theForm boundingBox rule: Form erase fillColor: Color transparent. ] ifFalse: [ theForm _ (ColorForm extent: compositionRectangle extent) offset: offset; colors: (Array with: (backColor == nil ifTrue: [Color transparent] ifFalse: [backColor]) with: (foreColor == nil ifTrue: [Color black] ifFalse: [foreColor])). backColor _ Color white. foreColor _ Color black. ]. self displayOn: theForm at: 0@0 clippingBox: theForm boundingBox rule: Form over fillColor: nil. backColor _ oldBackColor. foreColor _ oldForeColor. ^ theForm "Example: | p | p _ 'Abc' asParagraph. p foregroundColor: Color red backgroundColor: Color black. p asForm displayOn: Display at: 30@30 rule: Form over"

2 1

Re: Squeak is an unsuccessful open source project (was RE: Let usface reality)
by Lex Spoon 30 Jan '05

30 Jan '05

This is a very helpful list, Brent. How about posting some reports on bugs.impara.de ? I started to do it for you, but I'm not sure I can do it justice... I agree these things should be a high priority, and that fixes to them should be analyzed as quickly as possible... -Lex "Brent Pinkney" <brent.pinkney(a)aircom.co.za> wrote: > 1. There are 3 HttpClient implementations, which is fully HTPP1.1 > compliant. > 2. Comanche is not HTTP1.1 compliant. > 3. There are multiple Socket implementation in various states of > completion. > > Pretty important for a community which, in this thread at least, has > emphasised, the importance of networking. > > 4. The old compiler does not have closures. > 5. The new closure compiler is slow (see Andreas Raab's comments) and does > not decompile blocks. >

1 0

[BUG][VM] long Delay schedules a deferred image crash
by David T. Lewis 30 Jan '05

30 Jan '05

Here's a tasty little bug. If you schedule a Delay with a duration long enough to be a LargeInteger, it will sit happily in the SuspendedDelays queue until such time as it becomes the next Delay to be activated. At that time, #primitiveSignalAtMilliseconds is called. The primitive is only able to handle SmallIntegers, so it fails, whereupon #primSignal:atMilliseconds: attempts to throw 'a primitive has failed', which bolluxes up the works in the process scheduler. As far as I can tell, this is an unrecoverable error condition. The following illustrates the problem and will usually crash your image: | bigDelay | bigDelay := Delay forSeconds: SmallInteger maxVal + 1. [bigDelay wait. Transcript show: 'I have been waiting a long time for this'; cr] fork. (Delay forSeconds: 1) wait. Smalltalk garbageCollect "=> image will hang after failed primitive" Two things need to be addressed: 1) The primitive should accept large integer arguments. Note that the longest possible delay with a small integer is only about 12 days: Duration seconds: (SmallInteger maxVal / 1000) asInteger => 12:10:15:41 2) Delay class>>primSignal:atMilliseconds: should do something other than #primitiveFailed when the primitive fails. Perhaps writing something to the Transcript would make sense, or just ignore the failure entirely? This is #854 on Mantis. Dave

2 1

Concerns regarding Squeak design quality
by Michael Latta 30 Jan '05

30 Jan '05

I am trying to use Squeak in a new project. I really want to use Squeak, and keep running into questions about the quality of the Squeak image, and would like some community comment on the following observations. 1) The VM seems quite solid and has decent performance. This is not the current concern. 2) The implementation of Balloon is only partially complete. The handling of text and transforms is not done. 3) The old ST80 image had a lot of design elegance in the classes, while too much of the Squeak image I am running into seems less organized. 4) Where in the ST80 image there was a hierarchy of objects ending in Paragraph that deal with displaying, in Morphic I find NewParagraph that has no superclass other than Object. This in and of itself is not a problem, but that asParagraph returns the old one, and it can not be directly displayed on a Canvas is an issue. It looks almost like Morphic was really ported from Self and was not tied into the Smalltalk class library more than was minimally necessary. What I guess I am questioning is whether the image has enough integrity / quality of design to use in a production project. If there are a lot of unfinished stuff in the image, then our maintenance effort grows with the amount of the existing code we try to use. Nothing is without bugs, but part of what I associate with "Smalltalk" is more attention to design elegance. If I had plenty of time I might be tempted to take it down to the base image (minimal computing model) and build it up with a clean OpenGL based UI. But, that would be way too much effort for the advantages Smalltalk offers. I do not mind fixing bugs, but the regularity of lost time on them is getting old, and it is very difficult to know what the proper behavior is in too many cases. Michael

2 2

Non-debuggerable situation
by Chris Muller 30 Jan '05

30 Jan '05

While testing proxy classes that inherit from ProtoObject, I frequently get myself into a bad situation where Squeak is trying to open a debugger, but apparently encountering an error while trying to open it. It then tries to open a debugger on *that* but has the same problem. Of course, the image won't last long at this point as the many thousands of suspended processes ready to be debugged quickly chew up memory. It's easy to reproduce: ProtoObject basicNew "print it" Does anyone know how this can be made debuggable with the debugger (e.g. "debuggerable" :) )? Thanks! Chris

4 3

[FIX] PreferredKeyboardPosition-fbs ( Ok )
by bergel＠iam.unibe.ch 30 Jan '05

30 Jan '05

a couple of methods renamed.

1 0

[ENH] ObjectExplorerWrapperEnh
by bergel＠iam.unibe.ch 30 Jan '05

30 Jan '05

from preamble: "Change Set: ObjectExplorerWrapperEnh Date: 30 January 2005 Author: Dean Tribble Display the classname when an error occurs. Packed by Alexandre Bergel"!

1 0

[ENH] IsArray
by bergel＠iam.unibe.ch 30 Jan '05

30 Jan '05

from preamble: "Change Set: IsArray Date: 30 January 2005 Author: Dean Tribble, Alexandre Bergel Add a testing method isArray in Object and Array. Add a method category named testing in Array, and move the method isLiteral from the category printing to testing"!

1 0

[ENH] DecompileTree
by bergel＠iam.unibe.ch 30 Jan '05

30 Jan '05

from preamble: "Change Set: DecompileTree Date: 30 January 2005 Author: Dean Tribble, Alexandre Bergel Allow a single method to be properly decompiled."!

1 0

[ENH] Remove unused temp name cache in CompiledMethod
by Ben Schroeder 29 Jan '05

29 Jan '05

Hi everyone, I recently ran into some trouble with CompiledMethod's TempNameCache. I investigated and found out that the cache is no longer read. The attached changeset removes the cache. I was doing some experiments with image segments. The cache was holding onto the most recently compiled method. This caused problems when I wanted to include the method in my segment - it would stay as an "out pointer". This changeset removes the cache. >From the preamble: "Change Set: RemoveUnusedTempNameCache-bvs Date: 6 January 2005 Author: Benjamin Schroeder CompiledMethod keeps a cache of temporary names for a single CompiledMethod instance. The cache is set after compilation and during certain debugger operations. However, it is never read. Keeping the cache creates an extra reference to the most recently compiled method. This can be a problem in certain obscure situations, such as including the method in an image segment. This changeset removes the cache." Regards, Ben Schroeder <<RemoveUnusedTempNameCache-bvs.1.cs.gz>>

2 1

← Newer
1
2
3
4
5
6
7
...
24
Older →

Jump to page: