November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Emergency tool instead of the debugger starting (caused by issue #14469 in update #40373)

by Marcus Denker

> On 19 Nov 2014, at 01:05, Torsten Bergmann <astares(a)gmx.de> wrote: > > The expression > > 1 halt > > or any other part that has to be debugged gives the emergency tool > instead of the debugger. > > Pharo 4.0 #40372 image is working (gives the usual debugger) > Pharo 4.0 #40373 image not working (emergency evaluator) > > The problem seems to be related to the fix/slice > "SLICE-Issue-14469-Merge-back-OrderPreservingDictionary-improvements-MarcusDenker.1" > for issue 14469. > > When one manually merges the slice from issue #14469 into Pharo 4.0 #40372 > one can reproduce this problem. > OrderedDictionary is missing: asValueHolder ^ DictionaryValueHolder value: self (OrderedIdentityDictionary used to be a subclass of Dictionary, which has this) Marcus

Nov. 19, 2014

Re: [Pharo-dev] [Vm-dev] Re: Spur 64-bits. Ugh, this could be a slog...

by David T. Lewis

On Tue, Nov 18, 2014 at 07:59:30PM -0800, Ryan Macnak wrote: > > What about bytecode pc's? These are indexed based on the physical size of > the literals. I don't like the idea of debugging pc -> source mappings, pc > coverage data, etc needing invalidation after starting an image on a > platform with a different word size. I may be misunderstanding your question, but I do not think that this will be an issue. All byte addressible objects need to work properly in any image, including 32 and 64 bit images. If that part does not work, then the image will not run, so no problem ;-) With respect to platform word size (e.g. 64 bit OS versus 32 bit OS), the images should all run bit-identically regardless of platform word size. A 64-bit image can (and does) run on a 32-bit host platform, given a suitably compiled VM. And a 32-bit image will run on a 64-bit host platform, given a suitably compiled VM (or more commonly, a 32-bit VM with 32-bit compatibility libraries installed on the platform). Dave > > On Tue, Nov 18, 2014 at 7:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > Hi All, > > > > I'm making good progress on 64-bit Spur in the Stack VM simulator. > > But I've just noticed an image-level issue which could be indicative of > > lots of 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems. > > > > SmallInteger>>digitAt: n > > "Answer the value of an indexable field in the receiver. > > LargePositiveInteger uses bytes of base two number, and each is a 'digit' > > base 256. Fail if the argument (the index) is not an Integer or is out of > > bounds." > > n>4 ifTrue: [^ 0]. > > self < 0 > > ifTrue: > > [self = SmallInteger minVal ifTrue: > > ["Can't negate minVal -- treat specially" > > ^ #(0 0 0 64) at: n]. > > ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] > > ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF] > > > > This assumes that SmallInteger is only ever 4 bytes, which is unacceptably > > wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are > > 61-bit 2's complement. > > > > I'm raising this example at this point to see if the community might find > > similar issues and bring them to my attention. > > -- > > best, > > Eliot > >

Nov. 19, 2014

Re: [Pharo-dev] [Vm-dev] Spur 64-bits. Ugh, this could be a slog...

by David T. Lewis

On Tue, Nov 18, 2014 at 07:12:12PM -0800, Eliot Miranda wrote: > > Hi All, > > I'm making good progress on 64-bit Spur in the Stack VM simulator. But > I've just noticed an image-level issue which could be indicative of lots of > 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems. > > SmallInteger>>digitAt: n > "Answer the value of an indexable field in the receiver. > LargePositiveInteger uses bytes of base two number, and each is a 'digit' > base 256. Fail if the argument (the index) is not an Integer or is out of > bounds." > n>4 ifTrue: [^ 0]. > self < 0 > ifTrue: > [self = SmallInteger minVal ifTrue: > ["Can't negate minVal -- treat specially" > ^ #(0 0 0 64) at: n]. > ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] > ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF] > > This assumes that SmallInteger is only ever 4 bytes, which is unacceptably > wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are > 61-bit 2's complement. > > I'm raising this example at this point to see if the community might find > similar issues and bring them to my attention. There will be quite a few issues like this scattered throughout the image. My suggestion would be to focus first on getting the 64-bit Spur image running with no changes to SmallInteger minVal and maxVal. Then, as a separate follow up step, expand the range of SmallInteger in the image and work out all the changes required to support it. Another possible way to attack the problem is to start with a Squeak trunk image in 68002 image format (64-bit image), and work out the issues associated with extending SmallInteger minVal and maxVal to take advantage of the larger immediate integers range. This could be independent of the work you are doing now, so if someone else wanted to work on the "expand range of SmallInteger" aspect of the project, I expect that this can be done in the existing 68002 image, such that the resulting changes would be directly applicable to the format 68019 (64-bit) Spur images. Dave

Nov. 19, 2014

Spur 64-bits. Ugh, this could be a slog...

by Eliot Miranda

Hi All, I'm making good progress on 64-bit Spur in the Stack VM simulator. But I've just noticed an image-level issue which could be indicative of lots of 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems. SmallInteger>>digitAt: n "Answer the value of an indexable field in the receiver. LargePositiveInteger uses bytes of base two number, and each is a 'digit' base 256. Fail if the argument (the index) is not an Integer or is out of bounds." n>4 ifTrue: [^ 0]. self < 0 ifTrue: [self = SmallInteger minVal ifTrue: ["Can't negate minVal -- treat specially" ^ #(0 0 0 64) at: n]. ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF] This assumes that SmallInteger is only ever 4 bytes, which is unacceptably wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are 61-bit 2's complement. I'm raising this example at this point to see if the community might find similar issues and bring them to my attention. -- best, Eliot

Nov. 19, 2014

Emergency tool instead of the debugger starting (caused by issue #14469 in update #40373)

by Torsten Bergmann

The expression 1 halt or any other part that has to be debugged gives the emergency tool instead of the debugger. Pharo 4.0 #40372 image is working (gives the usual debugger) Pharo 4.0 #40373 image not working (emergency evaluator) The problem seems to be related to the fix/slice "SLICE-Issue-14469-Merge-back-OrderPreservingDictionary-improvements-MarcusDenker.1" for issue 14469. When one manually merges the slice from issue #14469 into Pharo 4.0 #40372 one can reproduce this problem. https://pharo.fogbugz.com/f/cases/14496

Nov. 19, 2014

Re: [Pharo-dev] Can we make this fast ?

by Eliot Miranda

On Tue, Nov 18, 2014 at 3:24 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > Le 18 nov. 2014 22:52, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > > > > > > > On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > > > > > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: > > >> See > > >> https://news.ycombinator.com/item?id=8625280 > > >> > > >> [ (1 to: 100000000) sum ] timeToRun > > >> > > >> Here we get out of the SmallInteger range... > > >> > > >> Apart FFI'ing the thing, do we have other options? > > >> > > >> Phil > > > Choose a better algorithm: > > > [100000000 * 10000001 / 2] timeToRun > > > should beat yours by several orders of magnitude. > > > > > > Andreas > > > > Haha, great ! > > > > > > Sure cool. > > Now Pharo is slow on these loops with arithmetics and it is painful. > Yes, but that particular loop is low because in part it uses the sum convenience. e.g. Collection>>sum "Compute the sum of all the elements in the receiver" ^self reduce:[:a :b| a + b] Collection>>reduce: binaryBlock "Apply the argument, binaryBlock cumulatively to the elements of the receiver. For sequenceable collections the elements will be used in order, for unordered collections the order is unspecified." | first nextValue | first := true. self do: [ :each | first ifTrue: [ nextValue := each. first := false ] ifFalse: [ nextValue := binaryBlock value: nextValue value: each ] ]. first ifTrue: [ self errorEmptyCollection ]. ^nextValue | n | n := 100000000. { [ (1 to: n) sum ] timeToRun. [| s | s := 0. (1 to: n) do: [:i| s := s + i]] timeToRun. [| s | s := 0. 1 to: n do: [:i| s := s + i]] timeToRun. [n * (n + 1) / 2] timeToRun} #(10112 9538 8432 0) > Eliot, why is a class variable faster? > The expression is a constant. You can e.g. compute it at class initialization and for descriptive purposes store the result in a class variable. That's usually quicker than computing anything every time. Standard examples are specialized dispatch tables, dictionaries, etc. Class variables are a convenient way of holding onto precomputed objects. Alex, I'll a look at OpenCL. > > Also, I tried with a whileTrue: loop which was 3 times faster than the sum > on Collection. > > How to profile these kinds of tight loops? The standard profiler is kind > of useless. > Is AndreasProfiler the way to go > IMO yes. It is much more accurate about primitives than the standard profiler. -- best, Eliot

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by phil＠highoctane.be

Le 18 nov. 2014 22:52, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > > > On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: > >> See > >> https://news.ycombinator.com/item?id=8625280 > >> > >> [ (1 to: 100000000) sum ] timeToRun > >> > >> Here we get out of the SmallInteger range... > >> > >> Apart FFI'ing the thing, do we have other options? > >> > >> Phil > > Choose a better algorithm: > > [100000000 * 10000001 / 2] timeToRun > > should beat yours by several orders of magnitude. > > > > Andreas > > Haha, great ! > > Sure cool. Now Pharo is slow on these loops with arithmetics and it is painful. Eliot, why is a class variable faster? Alex, I'll a look at OpenCL. Also, I tried with a whileTrue: loop which was 3 times faster than the sum on Collection. How to profile these kinds of tight loops? The standard profiler is kind of useless. Is AndreasProfiler the way to go? Phil

Nov. 18, 2014

Re: [Pharo-dev] Merge conflict for "META Case: restructure Tests and test packages"

by Nicolai Hess

2014-11-18 23:00 GMT+01:00 Torsten Bergmann <astares(a)gmx.de>: > Hi Nicolai, > > For https://pharo.fogbugz.com/f/cases/14427 (renaming CompressionTests) > and https://pharo.fogbugz.com/f/cases/14426 (BaloonTests) it worked > without a problem. > yes? there are still merge conflicts (for the monkey). > > For others I got the mentioned merge conflict now from the monkey > validation. > > I tried manually using Monticello tools and it seems that the manual merge > fails in 40374 because PSMCChangesGrouper #visitClassTraitDefinition: gives > a DNU which another problem. > But not for all. (I saw this on other slices too, some time ago.) > > I opened a new issue for this: > > https://pharo.fogbugz.com/f/cases/14494/PSMCChangesGrouper-is-missing-visit… > > and I provide a naive fix. > > If possible someone should review #14494 or help with the others. Anyone > some Banana to feed to the monkey? > > Thx > T. > > > Gesendet: Dienstag, 18. November 2014 um 22:50 Uhr > Von: "Nicolai Hess" <nicolaihess(a)web.de> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: "Torsten Bergmann" <astares(a)gmx.de> > Betreff: Merge conflict for "META Case: restructure Tests and test > packages" > > for example : > https://pharo.fogbugz.com/default.asp?14433[https://pharo.fogbugz.com/defau… > I don't why there is a merge conflict, maybe it is how the slice is > created.I think the restructuring (moving all classes from > XXXTest to XXX-Tests) would work if we delete the empty XXXTests package > before > creating the slice. > > nicolai >

Nov. 18, 2014

Re: [Pharo-dev] Merge conflict for "META Case: restructure Tests and test packages"

by Torsten Bergmann

Hi Nicolai, ForÂ https://pharo.fogbugz.com/f/cases/14427Â (renaming CompressionTests) and https://pharo.fogbugz.com/f/cases/14426 (BaloonTests)Â it worked without a problem. For others I got the mentioned merge conflict now from the monkey validation.Â I tried manually using Monticello tools and it seems that the manual merge fails in 40374 because PSMCChangesGrouper #visitClassTraitDefinition: gives a DNU which another problem. I opened a new issue for this: https://pharo.fogbugz.com/f/cases/14494/PSMCChangesGrouper-is-missing-visit… and I provide a naive fix.Â If possible someone should review #14494 or help with the others. Anyone some Banana to feed to the monkey? Â Thx T. Â Gesendet:Â Dienstag, 18. November 2014 um 22:50 Uhr Von:Â "Nicolai Hess" <nicolaihess(a)web.de> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Cc:Â "Torsten Bergmann" <astares(a)gmx.de> Betreff:Â Merge conflict for "META Case: restructure Tests and test packages" for example : https://pharo.fogbugz.com/default.asp?14433[https://pharo.fogbugz.com/defau… Â I don't why there is a merge conflict, maybe it is how the slice is created.I think the restructuring (moving all classes from XXXTest to XXX-Tests) would work if we delete the empty XXXTests package before creating the slice. nicolai

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Sven Van Caekenberghe

> On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: >> See >> https://news.ycombinator.com/item?id=8625280 >> >> [ (1 to: 100000000) sum ] timeToRun >> >> Here we get out of the SmallInteger range... >> >> Apart FFI'ing the thing, do we have other options? >> >> Phil > Choose a better algorithm: > [100000000 * 10000001 / 2] timeToRun > should beat yours by several orders of magnitude. > > Andreas Haha, great !

Nov. 18, 2014