Squeak-dev October 2018

squeak-dev@lists.squeakfoundation.org

41 participants
130 discussions

[ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
by David T. Lewis 18 Oct '18

18 Oct '18

I added a SqueakMap entry for UTCDateAndTime so that it can be easily loaded in the new Squeak 5.2 release. http://wiki.squeak.org/squeak/6197 This project is a few years old now and I use it in my own images. There is no easy way to uninstall it, so please back up your image before trying it out. My primary motivation for this was to make DateAndTime easier to understand and easier to test. A happy side effect is that it is also substantially faster on unix VMs, so I would be interested in hearing if it provides similar improvement on Windows and OS X. Some Chronology tests will fail. This is intentional, as I did not attempt to make the tests green in cases where current behavior (or implementation of the test itself) may be questionable. After living with this for a couple of years, I think there may be a good case for moving it to trunk. But there are potential side effects for things like serializers (Fuel and Ma Serializer, SmartRefStream is already handled) and databases (Magma, Glorp, others?). So feedback in any of these areas would be welcome. If no objections, I will plan to push this to trunk in the not too distant future. Please yell at me if you think this is a bad idea. Dave

3 4

The Trunk: Tools-eem.832.mcz
by commits＠source.squeak.org 18 Oct '18

18 Oct '18

Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.832.mcz ==================== Summary ==================== Name: Tools-eem.832 Author: eem Time: 16 October 2018, 4:20:50.731928 pm UUID: 9aa4b922-fe6a-41cb-8cba-974b14632177 Ancestors: Tools-cmm.831 Fix a bug with DebuggerMethodMap and full blocks (Sista V1 bytecode set). DebuggerMethodMap must be careful to use the right kind iof dictionry (Dictionary vs IdentityDictionary) for mapping startKeys to block starts and block starts to temps. startKeys may be values (startpc with embedded blocks) or objects (initialPC and block itself for full blocks). And blockExtentsToTempRefs must always be a Dictionary ince block extents are ranges. =============== Diff against Tools-cmm.831 =============== Item was changed: ----- Method: DebuggerMethodMapForClosureCompiledMethods>>privateTempRefsForContext:startKeysToBlockExtents: (in category 'private') ----- privateTempRefsForContext: aContext startKeysToBlockExtents: theContextsStartKeysToBlockExtents "Answer the sequence of temps in scope in aContext in the natural order, outermost arguments and temporaries first, innermost last. Each temp is a pair of the temp's name followed by a reference. The reference can be integer - index of temp in aContext #( indirectionVectorIndex tempIndex ) - remote temp in indirectionVector at index in aContext #( outer. temp reference ) - a temp reference in an outer context." blockExtentsToTempRefs ifNil: [blockExtentsToTempRefs := (aContext method holdsTempNames ifTrue: [aContext method] ifFalse: [methodNode]) blockExtentsToTempsMap. + blockExtentsToTempRefs + ifNil: ["an empty method. shouldn't be able to step into here but it + can happen in weird circumstances (i.e. with MethodWrapper)." + blockExtentsToTempRefs := Dictionary new. + blockExtentsToTempRefs + at: (theContextsStartKeysToBlockExtents at: aContext startKey) + put: {}] + ifNotNil: + [(blockExtentsToTempRefs isKindOf: IdentityDictionary) ifTrue: + [blockExtentsToTempRefs := Dictionary withAll: blockExtentsToTempRefs associations]]. + startKeysToTempRefs := aContext homeMethod newBlockStartMap]. - blockExtentsToTempRefs ifNil: - ["an empty method. shouldn't be able to step into here but it - can happen in weird circumstances (i.e. with MethodWrapper)." - blockExtentsToTempRefs := Dictionary new. - blockExtentsToTempRefs - at: (theContextsStartKeysToBlockExtents at: aContext startKey) - put: {}]. - startKeysToTempRefs := Dictionary new]. ^startKeysToTempRefs at: aContext startKey ifAbsentPut: [| localRefs | localRefs := blockExtentsToTempRefs at: (theContextsStartKeysToBlockExtents at: aContext startKey) ifAbsent: [#()]. aContext outerContext ifNil: [localRefs] ifNotNil: [:outer| | outerTemps | "Present temps in the order outermost to innermost left-to-right, but replace copied outermost temps with their innermost copies" outerTemps := (self privateTempRefsForContext: outer startKeysToBlockExtents: theContextsStartKeysToBlockExtents) collect: [:outerPair| localRefs detect: [:localPair| outerPair first = localPair first] ifNone: [{ outerPair first. { #outer. outerPair last } }]]. outerTemps, (localRefs reject: [:localPair| outerTemps anySatisfy: [:outerPair| localPair first = outerPair first]])]]!

3 3

The Trunk: KernelTests-pre.350.mcz
by commits＠source.squeak.org 18 Oct '18

18 Oct '18

Patrick Rein uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-pre.350.mcz ==================== Summary ==================== Name: KernelTests-pre.350 Author: pre Time: 17 October 2018, 4:51:14.818895 pm UUID: ca4e331b-75b7-da42-bbc4-cc15a7476fc0 Ancestors: KernelTests-pre.349 Restores the float gradual undeflow test disabled for the 5.2 release =============== Diff against KernelTests-pre.349 =============== Item was removed: - ----- Method: FloatTest>>expectedFailures (in category 'failures') ----- - expectedFailures - - ^#(testTimesTwoPowerGradualUnderflow)! Item was changed: ----- Method: FloatTest>>testTimesTwoPowerGradualUnderflow (in category 'testing - arithmetic') ----- testTimesTwoPowerGradualUnderflow "Here is a vicious case where timesTwoPower is inexact because it underflows. And two consecutive inexact operations lead to a different result than a single one. Typically expressed as multiple of Float fmin in base 2, 2r1011*Float fmin shifted by -3 with round to nearest, tie to even mode: -> round(1.011) -> 1.0 = fmin But if first shifted by -2 then by -1: -> round(10.11) -> 11.0 = 3*fmin -> round(1.1) -> 10.0 = 2*fmin Or first shifted by -1 then by -2: -> round(101.1) -> 110.0 = 6*fmin -> round(1.1) -> 10.0 = 2*fmin A naive implementation that split the shift uncarefully might fail to handle such case correctly." | f | f := 2r1011 asFloat. "scan the whole range of possible exponents for this significand" Float fmin exponent + f exponent to: Float fmax exponent - f exponent do: [:exp | | g | g := f timesTwoPower: exp. + self assert: (g timesTwoPower: Float fmin exponent - g exponent) = Float fmin].! - self assert: (g timesTwoPower: Float fmin exponent - g exponent) = Float fmin]. - - "Forces a failure for 5.2 release. The test result seems to depend on the word size of the VM --pre" - self assert: false. !

2 1

Date hash is broken
by Chris Cunningham 18 Oct '18

18 Oct '18

Hi. Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: d1 := DateAndTime now asDate. d2 := Date today. d1 = d2. "true" d1 hash = d2 hash. "false" I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. Thanks, cbc

5 8

Selected item in object explorer
by Stéphane Rollandin 17 Oct '18

17 Oct '18

Hello all, In an object explorer, when one clicks twice on a list item it gets displayed in red. This is supposed to indicate that the item is selected, but actually selecting another item does not update the previous one, which stays highlighted. This seems like a bug. Also, is that notion of selected item used by the object explorer at all? If not, we may get rid of the color cue altogether. Stef

2 1

Re: [squeak-dev] The Trunk: Graphics-pre.404.mcz
by Chris Muller 17 Oct '18

17 Oct '18

Hi Patrick, Thanks for your contributions. If you are using the word, "try" then that is an indication we should start it out in the Inbox. Thanks for your cooperation. Best Regards, Chris On Wed, Oct 17, 2018 at 10:42 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote: > > Hi everyone, > > apologies for the confusions. I was doing this in between other things which obviously did not work out too well :) > > I will try this again in a few days but with some more structure. My idea is to first get a better idea of the scope of this change by finding all tests relying on the old behavior and writing some new tests capturing the use cases which should be possible with the new behavior. After that I will remove that line again and we (hopefully) have some more insight into the extent of the effects of that change. > > Bests > Patrick > > > > > > >On Tue, Oct 16, 2018 at 3:17 PM Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > >On Tue, Oct 16, 2018 at 10:29 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote: > > > >Hi all, > > > >the change is reverted now but I would like to document our findings and our insights for future changes. > > > >From Berts mail I gathered that the 255-0-0-0 to be transparent is required for 16bit -> 32bit conversion to work. As this has been around for quite some time some code relies on it. At the same time this regularly leads to problems when working with images loaded from external sources. For example, loading a PNG and using collectColor: to recolor it does not work if the PNG includes pure rgb black pixels. For this to work we would have to map pure black to Squeak Form black on loading and reconvert it on storing. This would however destroy information as we can not distinguish between 0-0-1 and 0-0-0 anymore. The other way to go would be to change the 16bit -> 32bit conversion to set alpha explicitly, but I do not know whether that is actually possible efficiently. > > > >Are there other aspects which I am missing? Is it likely for external packages to heavily rely on this functionality? > > > > > >I didn't say you need to revert this change ;) > >I was only explaining where the odd convention comes from. > >Now, early in the dev cycle is a good time to try this. There are certainly other places that need clean up (e.g. isTransparent). > >If we can limit the odd color treatment to the 16 bpp case (and only do it when between 16 and 32) I'd be pretty happy. > >+1. Why don't we reinstitute the change in trunk and fix as required? > > > >- Bert - > > > > > >_,,,^..^,,,_ > >best, Eliot --0000000000003e52660578629c63-- >

1 0

The Trunk: Tools-eem.833.mcz
by commits＠source.squeak.org 17 Oct '18

17 Oct '18

Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.833.mcz ==================== Summary ==================== Name: Tools-eem.833 Author: eem Time: 17 October 2018, 9:19:18.006868 am UUID: df9e1979-bd01-4f51-9e12-40fd3b872978 Ancestors: Tools-cmm.831 Fix a bug with DebuggerMethodMap and full blocks (Sista V1 bytecode set). DebuggerMethodMap must be careful to use the right kind iof dictionry (Dictionary vs IdentityDictionary) for mapping startKeys to block starts and block starts to temps. startKeys may be values (startpc with embedded blocks) or objects (initialPC and block itself for full blocks). And blockExtentsToTempRefs must always be a Dictionary ince block extents are ranges. [N.B. Tools-eem.832 contained a broken fix for this bug, sending the message homeMethod to aContext, instead of aContext home method] =============== Diff against Tools-cmm.831 =============== Item was changed: ----- Method: DebuggerMethodMapForClosureCompiledMethods>>privateTempRefsForContext:startKeysToBlockExtents: (in category 'private') ----- privateTempRefsForContext: aContext startKeysToBlockExtents: theContextsStartKeysToBlockExtents "Answer the sequence of temps in scope in aContext in the natural order, outermost arguments and temporaries first, innermost last. Each temp is a pair of the temp's name followed by a reference. The reference can be integer - index of temp in aContext #( indirectionVectorIndex tempIndex ) - remote temp in indirectionVector at index in aContext #( outer. temp reference ) - a temp reference in an outer context." blockExtentsToTempRefs ifNil: [blockExtentsToTempRefs := (aContext method holdsTempNames ifTrue: [aContext method] ifFalse: [methodNode]) blockExtentsToTempsMap. + blockExtentsToTempRefs + ifNil: ["an empty method. shouldn't be able to step into here but it + can happen in weird circumstances (i.e. with MethodWrapper)." + blockExtentsToTempRefs := Dictionary new. + blockExtentsToTempRefs + at: (theContextsStartKeysToBlockExtents at: aContext startKey) + put: {}] + ifNotNil: + [(blockExtentsToTempRefs isKindOf: IdentityDictionary) ifTrue: + [blockExtentsToTempRefs := Dictionary withAll: blockExtentsToTempRefs associations]]. + startKeysToTempRefs := aContext home method newBlockStartMap]. - blockExtentsToTempRefs ifNil: - ["an empty method. shouldn't be able to step into here but it - can happen in weird circumstances (i.e. with MethodWrapper)." - blockExtentsToTempRefs := Dictionary new. - blockExtentsToTempRefs - at: (theContextsStartKeysToBlockExtents at: aContext startKey) - put: {}]. - startKeysToTempRefs := Dictionary new]. ^startKeysToTempRefs at: aContext startKey ifAbsentPut: [| localRefs | localRefs := blockExtentsToTempRefs at: (theContextsStartKeysToBlockExtents at: aContext startKey) ifAbsent: [#()]. aContext outerContext ifNil: [localRefs] ifNotNil: [:outer| | outerTemps | "Present temps in the order outermost to innermost left-to-right, but replace copied outermost temps with their innermost copies" outerTemps := (self privateTempRefsForContext: outer startKeysToBlockExtents: theContextsStartKeysToBlockExtents) collect: [:outerPair| localRefs detect: [:localPair| outerPair first = localPair first] ifNone: [{ outerPair first. { #outer. outerPair last } }]]. outerTemps, (localRefs reject: [:localPair| outerTemps anySatisfy: [:outerPair| localPair first = outerPair first]])]]!

1 0

Re: [squeak-dev] The Trunk: Graphics-pre.404.mcz
by Bert Freudenberg 17 Oct '18

17 Oct '18

On Tue, Oct 16, 2018 at 10:29 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote: > Hi all, > > the change is reverted now but I would like to document our findings and > our insights for future changes. > > From Berts mail I gathered that the 255-0-0-0 to be transparent is > required for 16bit -> 32bit conversion to work. As this has been around for > quite some time some code relies on it. At the same time this regularly > leads to problems when working with images loaded from external sources. > For example, loading a PNG and using collectColor: to recolor it does not > work if the PNG includes pure rgb black pixels. For this to work we would > have to map pure black to Squeak Form black on loading and reconvert it on > storing. This would however destroy information as we can not distinguish > between 0-0-1 and 0-0-0 anymore. The other way to go would be to change the > 16bit -> 32bit conversion to set alpha explicitly, but I do not know > whether that is actually possible efficiently. > > Are there other aspects which I am missing? Is it likely for external > packages to heavily rely on this functionality? > I didn't say you need to revert this change ;) I was only explaining where the odd convention comes from. Now, early in the dev cycle is a good time to try this. There are certainly other places that need clean up (e.g. isTransparent). If we can limit the odd color treatment to the 16 bpp case (and only do it when between 16 and 32) I'd be pretty happy. - Bert -

3 2

Where is ExternalForm?
by Eliot Miranda 17 Oct '18

17 Oct '18

Hi All, clueless here... the Squeak 5.2 release notes state: "Balloon - Balloon primitive methods now return default values instead of failing if there is no plugin available - ExternalForm from the EToys package has been added" but there is no such class as ExternalForm n the image. And I can't find the package. Was it Graphics-External or FFI-External? And where is it? _,,,^..^,,,_ best, Eliot

2 4

5.2 announcement and link to release notes
by Chris Muller 16 Oct '18

16 Oct '18

Hi all, While 5.2 is still hot off the press, we should let the world know at squeak.org. There is only the link to the new bundles, but no other mention of 5.2, when I click on "News" the newest entry is from last February. I still haven't seen the release notes, but I'm about to go hunting on the swiki for them. - Chris

3 2

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