[ANN] SIXX 0.2 is now available for VisualWorks

Hi,

We have upgraded SIXX to 0.2.
The new version is available for all platforms (Squeak, VisualWorks, 
and Dolphin Smalltalk).

SIXX 0.2:
http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html
(You can install SIXX from Cincom Public Store Repository).

SIXX now supports 'shape changed' class deserialization.
Even if class definitions are changed between SIXX file and the 
current image, you can read the file via SixxShapeChangeReadStream.

Other features:
- Safer Boolean reading
- Added a new option "SixxSettings>>useNCR"
    - You can specify whether to write multi byte string by numeric 
    character references or not.
- Unicode string (de)serialization support (Squeak, VW)
- Added more hook methods for customizing serialization/
deserialization.

More details are described here:
http://swikis.ddo.jp/umejava/40

Enjoy!
---
[:masashi | ^umezawa]

[Question][vw7.3.1][BASE][EllipticalArc] -- is there a way to constrain the number of points calculated for the EllipticalArc, by using the clipping box in the graphicsContext

The following generates a huge amount of points during display (as the
polygon representation is constructed), but it all gets clipped:

            win := ScheduledWindow new.
	win component: (graphics := CompositePart new).
	win openIn: (30 <at> 30 extent: 500 <at> 500).
	arc := EllipticalArc boundingBox: (356 <at> 61 corner: 3.5d8 <at> 3.5d8)
startAngle: 259 sweepAngle: -80.
	arc displayStrokedOn: win graphicsContext

I want my & in my labels

Can somebody save me the headache I want to use the following as a label:

R & D

yep, you guessed it Receivables and Deliverables

btw, which I am using the painter to set.

anyhow, the end result is that R & D turns into R _D i.e. it thinks I want  
a shorcut key. This apparently was not the case in 3.0.

Is there already a clean way of handling this or do I have to explicitly  
prevent labels from behaving so.

thanks in advance

-Charles

--

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

RE: I want my & in my labels

R && D

-Boris

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

boris <at> deepcovelabs.com

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Charles A. Monteiro [mailto:charles <at> ocit.com] 
Sent: Thursday, February 01, 2007 10:57 AM
To: vwnc <at> cs.uiuc.edu
Subject: I want my & in my labels

Can somebody save me the headache I want to use the following as a

Re: I want my & in my labels

much oblidged :)

On Thu, 01 Feb 2007 13:57:18 -0500, Boris Popov <boris <at> deepcovelabs.com>  
wrote:

> R && D
>
> -Boris
>

--

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: VM Crashes on G4/Mac

Well, the truly latest 7.5-preview VM runs the image just fine, so I  
guess they must have fixed the problem in the mean time...

Thanks for all your suggestions.

stp

--
    Stephen Travis Pope  --  Santa Barbara, California, USA
    http://HeavenEverywhere.com     http://FASTLabInc.com

  

On Jan 29, 2007, at 9:40 AM, Stephen Travis Pope wrote:

>
> The latest Mac VM crashes too; here's the dump
>
> ----
> Date/Time:      2007-01-29 09:39:10.653 -0800
> OS Version:     10.4.8 (Build 8L127)
> Report Version: 4
>
> Command: vwmacxgui
> Path:    /Users/stp/Code/Smalltalk/visual_Mac.app/Contents/MacOS/ 
> vwmacxgui
> Parent:  WindowServer [308]

Re: [Question][vw7.3.1][BASE][EllipticalArc] -- is there a way to constrain the number of points calculated for the EllipticalArc, by using the clipping box in the graphicsContext

mark.b.ballard <at> exgate.tek.com a écrit :
> The following generates a huge amount of points during display (as the
> polygon representation is constructed), but it all gets clipped:
> 
>             win := ScheduledWindow new.
> 	win component: (graphics := CompositePart new).
> 	win openIn: (30 <at> 30 extent: 500 <at> 500).
> 	arc := EllipticalArc boundingBox: (356 <at> 61 corner: 3.5d8 <at> 3.5d8)
> startAngle: 259 sweepAngle: -80.
> 	arc displayStrokedOn: win graphicsContext
> 
> 

I already patched EllipticalArc in ObjectWorks long time ago
- there is no use to computePoint if we just need the bounds
- there are some inaccuracy in computePoints

Unfortunately #outlineIntersects: and #regionIntersects: also call 
computePoints to handle clipping.
They would also need a new implementation for obvious economy reasons.

Then your code will invoke #displayArcBoundedBy:startAngle:sweepAngle: 
and the primitive will fail i think due to large numbers (most screen 
primitive work only with SmallIntegers).

This will try and round the point, fail again, revert to a 
#displayGeneralArcBBoxOrigin:extent:startAngle:sweepAngle: that will 
compute the points again and invoke primDisplayPolygon: that will fail, 
round points, and fail again due to at least two limitations
- small integers

Re: [Question][vw7.3.1][BASE][EllipticalArc] -- is there a way to constrain the number of points calculated for the EllipticalArc, by using the clipping box in the graphicsContext

just another point.

It is stupid to compute points rounded to a pixel since we do not even 
know the size of the pixel...

GraphicsContext are able of scaling and have their own idea of what is a 
pixel (Screen resolution is not PostScript resolution). Only in such a 
context can the rounding to pixel make sense.

Nicolas

Re: How to escape special characters in string literals?

Steven Kelly a écrit :
> *From:* Eliot Miranda [mailto:eliot.miranda <at> gmail.com]
> 
> 
> On 1/31/07, *Steven Kelly* <stevek <at> metacase.com 
> <mailto:stevek <at> metacase.com>> wrote:
> 
> #('
> ') works for me. You can do the same with lf, e.g. pasting into the 
> string body after this:
> ParagraphEditor currentSelection: (String with: Character lf)
> 
> 
> it works until... you file-out on e.g. Windows (which turns it into a 
> CR-LF pair) or on Unix (which turns it into an LF), and file it in 
> somewhere else. 
> 
>  
> 
> If you mean good old chunk fileout, that's true but somewhat unfair: if 
> you move a text file to a different platform, you're responsible for 
> line end conversion etc. My experience is that if you did the 
> appropriate conversion this worked OK with chunk format in VW3, although 
> later changes to "source" encoding may have messed it up.
> 
>  
> 
> If you mean XML, VW maintains the difference between CR and LF as simple 
> characters when saving. When reading back in, the problem is XML itself, 
> which demands that all line feeds be munged to LF when reading,  thus 

Integer bitAt: should be faster

Hello,
Integer>>bitAt: is based on bitShift: and bitAnd: operations.
This is generic but a little slow in LargeInteger arithmetic (creates 
useless intermediary LargeIntegers)

Faster implementation is quite trivial

LargePositiveInteger>>bitAt: i
     "this is optimized because super is slow"

     (i <= 0 or: [i > (self digitLength * 8)]) ifTrue: [^0].
     ^(self digitAt: (i - 1) // 8 + 1) bitAt: (i - 1) \\ 8 + 1

For LargeNegativeInteger, result is different only in higher bits...

LargeNegativeInteger>>bitAt: i
     | abs |
     abs := self abs.
     ^i > abs highBit
         ifTrue: [1]
         ifFalse: [abs bitAt: i]

This is in public store SYSMOD-LargeIntegerFastUp

Note that SmallInteger can also be slow.

| x |
x := 1.
Time millisecondsToRun: [10000 timesRepeat: [x bitAt: 8000]]