Squeak-dev October 2011

squeak-dev@lists.squeakfoundation.org

47 participants
160 discussions

Re: The Inbox: Kernel-ael.643.mcz
by Aran Lunzer 20 Oct '11

20 Oct '11

Hi I just posted a one-method proposed change to EventSensor, as a way to enable use of both yellow- and blue-button clicks in a Cog VM running on Windows. Background: Running a Squeak image with Cog on Windows (for example, the 4.3alpha image on Cog 4.0.0 of Oct 9, 2011) it seems there is no way to have both yellow-click (e.g., context menu) and blue-click (e.g., halo) available at the same time. Without enabling either of the VM (F2) 1-button or 3-button mouse settings, the behaviour of the right button of a 2-button mouse is determined by the swapMouseButtons preference. With swapMouseButtons enabled, the available clicks are Left: red Ctrl-left: [morphic menu] Alt-left: red Right: blue With swapMouseButtons disabled, the only change is Right: yellow On MacOS there is additional scope for configuration, through info.plist. But not on Windows. Proposed fix: It seems that what's needed is a call of mapButtons:modifiers: from EventSensor>>processEvent: With this step included (for non-MacOS platforms only), we can obtain the following mapping: [swapMouseButtons disabled] Left: red Ctrl-left: [morphic menu] Alt-left: blue Right: yellow ...so finally we have a way to get blue *and* a way to get yellow (with thanks to Bert Freudenberg for helping track down where the mapping should be done). What I don't understand is how other people have been doing this up to now. Surely there are some Windows users of Cog?? Aran -- Aran Lunzer Viewpoints Research

4 3

Re: [squeak-dev] Linux VM packages (was: Squeak Oversight Board minutes ? 10/18/11)
by David T. Lewis 20 Oct '11

20 Oct '11

On Thu, Oct 20, 2011 at 10:55:46AM -0300, Jecel Assumpcao Jr. wrote: > David T. Lewis wrote: > > On Wed, Oct 19, 2011 at 04:49:33PM -0300, Jecel Assumpcao Jr. wrote: > > > [my old Linux system] > > > > To check my understanding, you are using the 4.0.3-2202 because you > > are stuck on an older Linux version, and the newer VMs do not run on > > that older platform due to runtime library differences on the older > > Linux system that you use versus the newer Linux system on which the > > VM was compiled. Is that right? > > I have not yet tested newer VMs, but there is a good chance that they > will work even on Fedora 10. What I was trying to say is that there are > many different situations out there and we should not attempt to support > most of them, like mine. About people being "smart enough", we have to > pick some situations where they aren't and make it "just work" for them > and, unfortunately, let the rest take care of themselves. Thanks, I understand and fully agree! > In another email you suggested a role of an official Squeak ambassador > for dealing with the various package mantainers in the Linux > distributions, right? I think that is a good idea - most such mantainers > take care of many packages other than Squeak and don't have time to pay > too much attention to what we do nor do they know very much about it. If > someone had the emails of all these people and could keep them updated > and answer their questions it would help a lot. I do not know much about the people actually doing the work of package maintenance (and I would say that Bert has the most expertise and experience here), but I would think that maintaining a VM package for any given Linux distribution would be a big enough job for one person. It requires a lot of knowledge, as well as a willingness to look after the issues over a period of years. I think that Bert has acted as our unofficial ambassador for a long time, but keeping track of the various distros is far more than one person could ever do, and somebody has to do the real work of package maintenance for each of the distros. Dave

2 1

Re: [squeak-dev] Linux VM packages (was: Squeak Oversight Board minutes ? 10/18/11)
by David T. Lewis 20 Oct '11

20 Oct '11

On Wed, Oct 19, 2011 at 04:49:33PM -0300, Jecel Assumpcao Jr. wrote: > > There are two different use cases we are interested in handling. The > first is making things nicer in the future for Linux users. That can be > done with new or changed code on both the image side and the VM > packages. The second use case, which the survey will be for, is making > the 4.3 image usable for users who got their current VMs from their > distribution instead of from squeak.org. In this situation we can't make > any modifications to the VM since these won't get included in all > distributions soon enough to help. > > Of course, we have to be reasonable. I am stuck in Fedora 10, for > example (their installation system can deal with RAID in the root > partition, but their upgrade system can't). And during a long time I was > stuck with a 3.7-7 VM because newer ones broke diacritical marks for all > but the Etoys images. It wouldn't make any sense to try to support > someone in that situation. That has been fixed and I now use a > 4.0.3-2202 VM. Using that with a proposed 4.3 image gets me > > + exec padsp /usr/local/lib/squeak/4.0.3-2202/squeakvm > Squeak4.3alpha-11636.image > This interpreter (vers. 6502) cannot read image file (vers. 6505). To check my understanding, you are using the 4.0.3-2202 because you are stuck on an older Linux version, and the newer VMs do not run on that older platform due to runtime library differences on the older Linux system that you use versus the newer Linux system on which the VM was compiled. Is that right? For reference: The 4.0.3-2202 VM cannot read a Cog (6505) image. Any VM labeled 4.3.3-xxxx or newer has the ability to read this image format (where the "4.3.3" part refers to VMMaker version, and "xxxx" is version level of the associated platform support code). The current released VM version for Unix/Linux on http://www.squeakvm.org/unix/ is 4.4.7-2357, and this is the version in the Squeak 4.2 All-in-one link on squeak.org. If we still have links pointing users to the old 4.0.3-2202 VM, that is probably something that should be fixed. All versions of Cog and StackVM from Eliot or Igor support the 6505 image format, and any image saved from any of these VMs is fully functional on any of the others. Dave

2 1

The Trunk: Kernel-ael.643.mcz
by commits＠source.squeak.org 20 Oct '11

20 Oct '11

Bert Freudenberg uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ael.643.mcz ==================== Summary ==================== Name: Kernel-ael.643 Author: ael Time: 19 October 2011, 4:09:37.67 pm UUID: 1fb9163b-7fc4-7946-a812-27626936cc50 Ancestors: Kernel-nice.642 Proposed change for enabling both Yellow and Blue buttons from a two-button mouse in Cog VM =============== Diff against Kernel-nice.642 =============== Item was changed: ----- Method: EventSensor>>processEvent: (in category 'private-I/O') ----- processEvent: evt "Process a single event. This method is run at high priority." + | type buttons | - | type | type := evt at: 1. "Tackle mouse events first" type = EventTypeMouse + ifTrue: [buttons := (ButtonDecodeTable at: (evt at: 5) + 1). + evt at: 5 put: (Smalltalk platformName = 'Mac OS' + ifTrue: [ buttons ] + ifFalse: [ self mapButtons: buttons modifiers: (evt at: 6) ]). - ifTrue: [evt - at: 5 - put: (ButtonDecodeTable at: (evt at: 5) - + 1). self queueEvent: evt. self processMouseEvent: evt . ^self]. "Store the event in the queue if there's any" type = EventTypeKeyboard ifTrue: [ "Check if the event is a user interrupt" ((evt at: 4) = 0 and: [((evt at: 3) bitOr: (((evt at: 5) bitAnd: 8) bitShift: 8)) = interruptKey]) ifTrue: ["interrupt key is meta - not reported as event" ^ interruptSemaphore signal]. "Else swap ctrl/alt keys if neeeded. Look at the Unicode char first, then ascii." KeyDecodeTable at: {evt at: 6. evt at: 5} ifPresent: [:a | evt at: 6 put: a first; at: 5 put: a second]. KeyDecodeTable at: {evt at: 3. evt at: 5} ifPresent: [:a | evt at: 3 put: a first; at: 5 put: a second]. self queueEvent: evt. self processKeyboardEvent: evt . ^self ]. "Handle all events other than Keyborad or Mouse." self queueEvent: evt. !

1 0

Re: [squeak-dev] The Trunk: Kernel-nice.641.mcz
by Juan Vuletich 20 Oct '11

20 Oct '11

This is so much fun! The attach includes yet another version of #nthRoot: and a test that shows the kind of case it fixes: Receivers too big for Float arithmetic but without exact answer, and a better float than infinity is possible. Besides, a small performance tweak: don't call 'selfAsFloat nthRoot: aPositiveInteger' if the result will be infinity, i.e. if the receiver is infinity. Cheers, Juan Vuletich commits(a)source.squeak.org wrote: > Nicolas Cellier uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-nice.641.mcz > > ==================== Summary ==================== > > Name: Kernel-nice.641 > Author: nice > Time: 19 October 2011, 8:44:12.297 pm > UUID: e31730ef-2db4-42e3-aa0e-299e45c955ac > Ancestors: Kernel-nice.640 > > Correct #nthRootTruncated: (it did call #nthRootFloor:) > Let #nthRoot: retry in exact arithmetic if ever Float overflows. > > =============== Diff against Kernel-nice.640 =============== > > ... 'From Cuis 3.3 of 2 June 2011 [latest update: #1024] on 19 October 2011 at 11:02:07 pm'! !Integer methodsFor: 'mathematical functions' stamp: 'jmv 10/19/2011 22:39'! nthRoot: aPositiveInteger "Answer the nth root of the receiver. See #nthRootAlt: for an alternative implementation." | selfAsFloat floatResult guess delta higher lower raised | selfAsFloat _ self asFloat. "If we can't do Float arithmetic because we are too big, then look for an exact answer in exact arithmetic" selfAsFloat isInfinite ifTrue: [ guess _ self nthRootTruncated: aPositiveInteger. (guess raisedToInteger: aPositiveInteger) = self ifTrue: [ ^ guess ]. "Nothing else can be done. No exact answer means answer must be a Float. Answer the best we have." ^guess asFloat ]. floatResult _ selfAsFloat nthRoot: aPositiveInteger. guess _ floatResult rounded. "If got an exact answer, answer it." raised _ guess raisedToInteger: aPositiveInteger. raised = self ifTrue: [ ^ guess ]. "In this case, maybe it failed because we are such a big integer that the Float method gets inexact, even if we are a whole square number. Note 1(jmv): This algorithm is faster than #nthRootTruncated: for big n (aPositiveInteger) but fails if self asFloat isInfinite. Note 2(jmv): The algorithms I found for computing the nthRoot would havily use very large fractions. I wrote this one, that doesn't create fractions." selfAsFloat abs >= (Float maxExactInteger asFloat raisedToInteger: aPositiveInteger) ifTrue: [ raised > self ifTrue: [ higher _ guess. delta _ floatResult predecessor - floatResult. [ floatResult _ floatResult + delta. lower _ floatResult rounded. (lower raisedToInteger: aPositiveInteger) > self ] whileTrue: [ delta _ delta * 2. higher _ lower ] ] ifFalse: [ lower _ guess. delta _ floatResult successor - floatResult. [ floatResult _ floatResult + delta. higher _ floatResult rounded. (higher raisedToInteger: aPositiveInteger) < self ] whileTrue: [ delta _ delta * 2. lower _ higher ]]. [ higher - lower > 1 ] whileTrue: [ guess _ lower + higher // 2. raised _ guess raisedToInteger: aPositiveInteger. raised = self ifTrue: [ ^ guess ]. raised > self ifTrue: [ higher _ guess ] ifFalse: [ lower _ guess ]]]. "We need an approximate result" ^floatResult! ! !IntegerTest methodsFor: 'tests - mathematical functions' stamp: 'jmv 10/19/2011 22:59'! testBigReceiverInexactNthRoot " IntegerTest new testBigReceiverInexactNthRoot " "Inexact 3rd root (not a whole cube number), so a Float must be answered. However, receiver is too big for Float arithmethic." | bigNum result | bigNum _ (100 factorial raisedTo: 3) + 1. "Add 1 so it is not a whole cube" self assert: bigNum asFloat isInfinite. "Otherwise, we chose a bad sample" result _ bigNum nthRoot: 3. self assert: result class == Float. self deny: result isInfinite. self assert: result = 100 factorial asFloat. "No other float is closer. See following line" self assert: 100 factorial asFloat = (100 factorial+1) asFloat! ! Integer removeSelector: #nthRootAlt:!

1 0

Daily Commit Log
by commits＠source.squeak.org 20 Oct '11

20 Oct '11

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2011-October/005036.ht… Name: ToolBuilder-Morphic-cmm.82 Ancestors: ToolBuilder-Morphic-dtl.81, ToolBuilder-Morphic-cmm.80 Merged dtl.81. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2011-October/005037.ht… Name: Morphic-cmm.586 Ancestors: Morphic-cmm.585 - Added a setter for the #clearFilterAutomatically preference. - Improved comments. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2011-October/005038.ht… Name: ToolBuilder-Kernel-cmm.52 Ancestors: ToolBuilder-Kernel-dtl.51 Fix ability to safely catch Notification so that, if #displayProgressAt:from:to:during: is sent, will actually execute the during block. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2011-October/005039.ht… Name: ToolBuilder-SUnit-cmm.15 Ancestors: ToolBuilder-SUnit-nice.14 Added test for handling Notification inside a progress block. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2011-October/005040.ht… Name: Kernel-nice.641 Ancestors: Kernel-nice.640 Correct #nthRootTruncated: (it did call #nthRootFloor:) Let #nthRoot: retry in exact arithmetic if ever Float overflows. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2011-October/005041.ht… Name: KernelTests-nice.206 Ancestors: KernelTests-nice.205 More tests for #nthRoot: and #nthRootTruncated: ============================================= http://lists.squeakfoundation.org/pipermail/packages/2011-October/005042.ht… Name: Kernel-nice.642 Ancestors: Kernel-nice.641 Correct my own bugs, (-3/2) log should raise a DomainError, not an infinite loop... =============================================

1 0

The Inbox: Kernel-ael.643.mcz
by commits＠source.squeak.org 20 Oct '11

20 Oct '11

A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ael.643.mcz ==================== Summary ==================== Name: Kernel-ael.643 Author: ael Time: 19 October 2011, 4:09:37.67 pm UUID: 1fb9163b-7fc4-7946-a812-27626936cc50 Ancestors: Kernel-nice.642 Proposed change for enabling both Yellow and Blue buttons from a two-button mouse in Cog VM =============== Diff against Kernel-nice.642 =============== Item was changed: ----- Method: EventSensor>>processEvent: (in category 'private-I/O') ----- processEvent: evt "Process a single event. This method is run at high priority." + | type buttons | - | type | type := evt at: 1. "Tackle mouse events first" type = EventTypeMouse + ifTrue: [buttons := (ButtonDecodeTable at: (evt at: 5) + 1). + evt at: 5 put: (Smalltalk platformName = 'Mac OS' + ifTrue: [ buttons ] + ifFalse: [ self mapButtons: buttons modifiers: (evt at: 6) ]). - ifTrue: [evt - at: 5 - put: (ButtonDecodeTable at: (evt at: 5) - + 1). self queueEvent: evt. self processMouseEvent: evt . ^self]. "Store the event in the queue if there's any" type = EventTypeKeyboard ifTrue: [ "Check if the event is a user interrupt" ((evt at: 4) = 0 and: [((evt at: 3) bitOr: (((evt at: 5) bitAnd: 8) bitShift: 8)) = interruptKey]) ifTrue: ["interrupt key is meta - not reported as event" ^ interruptSemaphore signal]. "Else swap ctrl/alt keys if neeeded. Look at the Unicode char first, then ascii." KeyDecodeTable at: {evt at: 6. evt at: 5} ifPresent: [:a | evt at: 6 put: a first; at: 5 put: a second]. KeyDecodeTable at: {evt at: 3. evt at: 5} ifPresent: [:a | evt at: 3 put: a first; at: 5 put: a second]. self queueEvent: evt. self processKeyboardEvent: evt . ^self ]. "Handle all events other than Keyborad or Mouse." self queueEvent: evt. !

1 0

Re: [squeak-dev] The Trunk: ToolBuilder-Kernel-cmm.52.mcz
by Levente Uzonyi 19 Oct '11

19 Oct '11

On Wed, 19 Oct 2011, commits(a)source.squeak.org wrote: > Chris Muller uploaded a new version of ToolBuilder-Kernel to project The Trunk: > http://source.squeak.org/trunk/ToolBuilder-Kernel-cmm.52.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Kernel-cmm.52 > Author: cmm > Time: 18 October 2011, 8:12:42.168 pm > UUID: 54416a65-63c1-4ba4-959e-7f1f7db3aa62 > Ancestors: ToolBuilder-Kernel-dtl.51 > > Fix ability to safely catch Notification so that, if #displayProgressAt:from:to:during: is sent, will actually execute the during block. I don't like this change, because it breaks existing code and supports a bad pattern. For example ComplexProgressIndicator and Installer assumes that ProgressInitiationException >> #resume just resumes with nil without any side effects, so these are broken now. Catching all Notifications and just resuming them is something that doesn't work, because there may be other handlers which expect to catch them, so you should #pass the notifications that you don't want to swallow. Using Notification instead of specific subclasses is also a bad idea unless you really want to process all notifications. Maybe we should raise an error when someone is trying to signal a Notification, because that class is just a marker and not something that should be used as a Notification (I could say it's abstract, but I don't like this term, because in Smalltalk it doesn't have a well-defined meaning). Levente > > =============== Diff against ToolBuilder-Kernel-dtl.51 =============== > > Item was changed: > ----- Method: ProgressInitiationException>>defaultAction (in category 'as yet unclassified') ----- > defaultAction > + self resume! > - > - | result | > - result := UIManager default > - displayProgress: progressTitle > - at: aPoint > - from: minVal > - to: maxVal > - during: workBlock. > - self resume: result! > > Item was added: > + ----- Method: ProgressInitiationException>>defaultResumeValue (in category 'as yet unclassified') ----- > + defaultResumeValue > + ^ UIManager default > + displayProgress: progressTitle > + at: aPoint > + from: minVal > + to: maxVal > + during: workBlock! > > >

3 4

The Inbox: Kernel-nice.644.mcz
by commits＠source.squeak.org 19 Oct '11

19 Oct '11

Nicolas Cellier uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-nice.644.mcz ==================== Summary ==================== Name: Kernel-nice.644 Author: nice Time: 19 October 2011, 10:26:06.268 pm UUID: 612f5a8e-66ec-4531-86ab-ebc494038a94 Ancestors: Kernel-nice.642 Add Integer>>bitCount to count the bits set (to 1) in an Integer. =============== Diff against Kernel-nice.642 =============== Item was added: + ----- Method: Integer>>bitCount (in category 'bit manipulation') ----- + bitCount + "Count the number of bits set to 1 in self" + + | bitCount | + self < 0 ifTrue: [self error: 'Cannot count bits of negative integers']. + bitCount := 0. + 1 to: self digitLength do: [:i | + bitCount := bitCount + (self digitAt: i) bitCountOfByte]. + ^bitCount! Item was added: + ----- Method: SmallInteger>>bitCountOfByte (in category 'bit manipulation') ----- + bitCountOfByte + "Count the number of bits set to 1 in a byte." + + ^#[0 1 1 2 1 2 2 3 1 2 2 3 2 3 3 4 1 2 2 3 2 3 3 4 2 3 3 4 3 4 4 5 1 2 2 3 2 3 3 4 2 3 3 4 3 4 4 5 2 3 3 4 3 4 4 5 3 4 4 5 4 5 5 6 1 2 2 3 2 3 3 4 2 3 3 4 3 4 4 5 2 3 3 4 3 4 4 5 3 4 4 5 4 5 5 6 2 3 3 4 3 4 4 5 3 4 4 5 4 5 5 6 3 4 4 5 4 5 5 6 4 5 5 6 5 6 6 7 1 2 2 3 2 3 3 4 2 3 3 4 3 4 4 5 2 3 3 4 3 4 4 5 3 4 4 5 4 5 5 6 2 3 3 4 3 4 4 5 3 4 4 5 4 5 5 6 3 4 4 5 4 5 5 6 4 5 5 6 5 6 6 7 2 3 3 4 3 4 4 5 3 4 4 5 4 5 5 6 3 4 4 5 4 5 5 6 4 5 5 6 5 6 6 7 3 4 4 5 4 5 5 6 4 5 5 6 5 6 6 7 4 5 5 6 5 6 6 7 5 6 6 7 6 7 7 8] at: self + 1 + + "Evaluate this expression to form above byte array: + ((0 to: 255) + collect: [:i | + | bitCount n | + n := i. + bitCount := 0. + [n = 0] + whileFalse: + [bitCount := bitCount + 1. + n := n bitAnd: n - 1]. + bitCount] + as: ByteArray)"!

1 0

Re: [squeak-dev] Squeak Oversight Board minutes – 10/18/11
by Chris Cunnington 19 Oct '11

19 Oct '11

As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download the image and vm separately, from different sources. Say you get your vm from apt-get, rpm, or yum. And then we release a new image. Maybe people will just see everything fail. The Cog vm is a big jump. You use it, and you can't readily go back to the interpreter. Jecel is going to look at what vms Linux users are using. Are they still 3.x vms? That sort of thing. The mechanism for Linux users to get what we make is a little different. But since you clearly are in the loop, I don't think any of this kind of delay would apply to you. I'd say its more a communications thing than a technical challenge. Chris

6 7

← Newer
1
2
3
4
5
6
7
8
9
...
16
Older →

Jump to page: