Squeak-dev November 2014

squeak-dev@lists.squeakfoundation.org

41 participants
125 discussions

Re: Spur 64-bits. Ugh, this could be a slog...
by Eliot Miranda 19 Nov '14

19 Nov '14

Hi Ryan, On Tue, Nov 18, 2014 at 7:59 PM, Ryan Macnak <rmacnak(a)gmail.com> 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 think this is taken care of. For example, CompiledMethod>>initialPC already consults wordSize. CompiledMethod>>initialPC "Answer the program counter for the receiver's first bytecode." ^ (self numLiterals + 1) * Smalltalk wordSize + 1 and of course the image bootstrap maps pcs already. i.e. Spur32to64BitBootstrap>>fillInPointerObjectWithPC: obj64 from: obj32 | method | self fillInPointerObject: obj64 from: obj32. (heap64 classIndexOf: obj64) = ClassBlockClosureCompactIndex ifTrue: [method := heap32 fetchPointer: MethodIndex ofObject: (heap32 fetchPointer: ClosureOuterContextIndex ofObject: obj32). self incrementPCField: ClosureStartPCIndex ofObject: obj64 for: method]. (heap64 classIndexOf: obj64) = ClassMethodContextCompactIndex ifTrue: [method := heap32 fetchPointer: MethodIndex ofObject: obj32. self incrementPCField: InstructionPointerIndex ofObject: obj64 for: method] Spur32to64BitBootstrap>>incrementPCField: fieldIndex ofObject: obj64 for: method32 | value nLits | value := heap64 fetchPointer: fieldIndex ofObject: obj64. (heap64 isIntegerObject: value) ifTrue: [nLits := heap32 literalCountOf: method32. heap64 storePointerUnchecked: fieldIndex ofObject: obj64 withValue: (heap64 integerObjectOf: nLits + LiteralStart * 4 + (heap64 integerValueOf: value))] ifFalse: [self assert: (reverseMap at: value) = heap32 nilObject] So I'm more looking for issues where the code implicitly assumes 32-bit pointers, such as digitAt: below. 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 >> > > -- best, Eliot

1 0

Re: [squeak-dev] The Inbox: Collections-ul.587.mcz
by Levente Uzonyi 19 Nov '14

19 Nov '14

Hi All, The reason why I put this into The Inbox instead of The Trunk is that it changes the behavior of #sum when the Interval is empty. The current implementation raises an error - which is correct for a Collection which may contain any object - but I think for Intervals the preferred behavior is to return 0. Any objections? Levente On Tue, 18 Nov 2014, commits(a)source.squeak.org wrote: > A new version of Collections was added to project The Inbox: > http://source.squeak.org/inbox/Collections-ul.587.mcz > > ==================== Summary ==================== > > Name: Collections-ul.587 > Author: ul > Time: 18 November 2014, 11:53:01.797 pm > UUID: 30ba8551-0c97-4cf5-b830-9386f272b8d2 > Ancestors: Collections-ul.586 > > Optimized Interval >> #sum. > > =============== Diff against Collections-ul.586 =============== > > Item was added: > + ----- Method: Interval>>sum (in category 'accessing') ----- > + sum > + "Optimized version. Use the sum(n*i - k, i=a..b) = -1/2*(a - b - 1)*(n * (a + b) - 2 * k) equation with a = 1, n = step, b = self size." > + > + | b | > + b := self size. > + ^b * ((b + 1) * step - (step - start * 2)) / 2! > > >

3 3

The Trunk: Collections-ul.587.mcz
by commits＠source.squeak.org 19 Nov '14

19 Nov '14

Levente Uzonyi uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ul.587.mcz ==================== Summary ==================== Name: Collections-ul.587 Author: ul Time: 18 November 2014, 11:53:01.797 pm UUID: 30ba8551-0c97-4cf5-b830-9386f272b8d2 Ancestors: Collections-ul.586 Optimized Interval >> #sum. =============== Diff against Collections-ul.586 =============== Item was added: + ----- Method: Interval>>sum (in category 'accessing') ----- + sum + "Optimized version. Use the sum(n*i - k, i=a..b) = -1/2*(a - b - 1)*(n * (a + b) - 2 * k) equation with a = 1, n = step, b = self size." + + | b | + b := self size. + ^b * ((b + 1) * step - (step - start * 2)) / 2!

1 0

Re: [Vm-dev] Re: Spur 64-bits. Ugh, this could be a slog...
by David T. Lewis 19 Nov '14

19 Nov '14

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 > >

1 0

The Inbox: Collections-ul.587.mcz
by commits＠source.squeak.org 18 Nov '14

18 Nov '14

A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ul.587.mcz ==================== Summary ==================== Name: Collections-ul.587 Author: ul Time: 18 November 2014, 11:53:01.797 pm UUID: 30ba8551-0c97-4cf5-b830-9386f272b8d2 Ancestors: Collections-ul.586 Optimized Interval >> #sum. =============== Diff against Collections-ul.586 =============== Item was added: + ----- Method: Interval>>sum (in category 'accessing') ----- + sum + "Optimized version. Use the sum(n*i - k, i=a..b) = -1/2*(a - b - 1)*(n * (a + b) - 2 * k) equation with a = 1, n = step, b = self size." + + | b | + b := self size. + ^b * ((b + 1) * step - (step - start * 2)) / 2!

1 0

GC settings in Spur
by Chris Muller 18 Nov '14

18 Nov '14

Hi all, my understanding has been that Squeak's default GC settings are optimized for animated UI's. By doing a lot of frequent incremental GC's ensures they will be small and therefore no noticable pauses in the animated UI. By contrast, the GC settings I stole from Seaside for Magma server's are to reduce the frequency of incremental GC's and instead increase its bias to grow, the expectation being that this will increase overall server throughput because its spending a lower fraction of time in the GC code. Here are those settings: =================================== "Initialize the memory and GC settings to be more liberal with memory in order to reduce garbage-collector impact on the processor." "The following settings affect the rate incremental GCs and tenuring" "Limit incremental GC activity to run every 100k allocations" self vmParameterAt: 5 put: 100000. "allocations between GCs (default: 4000)" "Limit tenuring threshold to only tenure w/ > 35k survivors" self vmParameterAt: 6 put: 35000. "tenuring threshold (default: 2000)" "These settings affect overall memory usage" "Only give memory back to the OS when we have more than 16MB free" self vmParameterAt: 24 put: 16*1024*1024. "default 8MB" "Try to keep 8MB headroom at all times" self vmParameterAt: 25 put: 8*1024*1024. "default 4MB" "These settings describe what to do when we're close to running out of free space" self isRunningSpur ifFalse: [ "Tell the VM that we'd rather grow than spinning in tight GC loops" self setGCBiasToGrow: 1. "default: false" "Tell the VM to do a fullGC for good measure if the above growth exceeded 16MB" self setGCBiasToGrowGCLimit: 16*1024*1024. "default: 0"] ======================================= Moving to Spur is a good time to review and discuss these settings. Any smart advice or feedback is appreciated.. :)

1 0

Re: [squeak-dev] Morphic-dhn.723.mcz (was: Morphic-bf.751.mcz)
by dnorton＠mindspring.com 18 Nov '14

18 Nov '14

-----Original Message----- >From: Bert Freudenberg <bert(a)freudenbergs.de> >Sent: Nov 17, 2014 10:06 AM >To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> >Subject: [squeak-dev] Morphic-dhn.723.mcz (was: Morphic-bf.751.mcz) > >On 17.11.2014, at 12:05, Marcel Taeumel <marcel.taeumel(a)student.hpi.uni-potsdam.de> wrote: > >> Hi, Bert. :) >> >> Looks good, except that the interface of RealEstateAgent seems now strange. >> Here, we make the assumption that either the owner is a world or that the >> selector #maximumUsableAreaInWorld: should be renamed to something more >> generic. In combination with "Preferences fullScreenLeavesDeskMargins" one >> could question such a global preference for this owner-specific >> implementation. >> >> If sytem windows can be embedded in any kind of morph, the thing about desk >> margins should be redesigned and the interface of RealEstateAgent should be >> refactored. >> >> If system windows can only be embedded into paste-up morphs, "self owner" >> seems semantically wrong. >> >> Just for documentation. :) > >Go ahead and rewrite it, or at least add a "todo" comment ;) > >I didn't actually write this, was simply merging Morphic-dhn.723, because it looked innocuous. Who is "dhn"? > >- Bert - > When SystemWindow is embedded in a paste-up morph other than World it will be cropped by fullScreen unless the paste-up is the same size (?) :) There are other problems with the border that I have not isolated. I agree with the point about semantics. How can I get my initials to be recognized in case I submit something else? - Dan Norton "dhn"

3 2

Re: [Seaside] Looking for volunteer for Seaside GRSqueakPlatform (was: Someone to tackle failing tests in Squeak?)
by David T. Lewis 18 Nov '14

18 Nov '14

Hi John, On Mon, Nov 17, 2014 at 09:42:37PM -0500, John McKeon wrote: > Hello Dave, > If you have no other takers, I am willing to do it. > I have worked with Seaside since 2.8 and Squeak since 3.10 > I'd be happy to be able to contribute something of value back to the Squeak > community. John, Excellent! Thank you so much. Please do take the lead on this. I'll try to help you as much as I can. I have some experience with platform specific issues based on my earlier work with OSProcess, and that may be of some value. Tobias Pape (CC) has done a good deal of work preparing Squeak Seaside images, and I am sure that he will be happy to have some help from you (and me I hope) to improve Seaside on Squeak. Thanks, Dave > > On Fri, Nov 14, 2014 at 10:04 AM, David T. Lewis <lewis(a)mail.msen.com> > wrote: > > > On Thu, Nov 13, 2014 at 10:43:48AM +0100, Philippe Marschall wrote: > > > On Thu, Nov 13, 2014 at 3:49 AM, David T. Lewis <lewis(a)mail.msen.com> > > wrote: > > > > On Tue, Nov 11, 2014 at 08:11:33AM +0100, Johan Brichau wrote: > > > >> Hi David, > > > >> > > > >> > On 11 Nov 2014, at 01:44, David T. Lewis <lewis(a)mail.msen.com> > > wrote: > > > >> > > > > >> > Is there a Metacello configuration for Seaside that I should be > > using to get > > > >> > me closer to the correct configuration? > > > >> > > > >> Looks like Paul gave you the necessary instructions. Mind that the > > failing tests are in latest version of Grease, which is loaded for Seaside > > 3.1.x (stable) and Seaside 3.2.0 (which is in development). > > > >> Btw, the Metacello instructions are also mentioned on > > http://seaside.st/download/pharo <http://seaside.st/download/pharo> > > > >> > > > >> Let me know if you need any help. > > > > > > > > Hi Johan, > > > > > > > > I am able to load Grease and Seaside 3.2.0 from the Metacello > > configurations, > > > > which work very well. There is one glitch in loading Seaside, because > > > > WASecureKeyGenerator class>>canSeed tries to use GRPharoPlaform > > subclass, > > > > does not exist. But that seems to be related to the same issue that is > > > > causing the original unit test failures that you are asking about. > > > > > > That should probably not be. I'll have a look. > > > > > > > The failures in WAExternalFileLibraryTest are related to GRPlatform. > > > > GRPlatform is providing a range of compatibility methods that are > > > > vectored through its concrete subclasses, which appear to include > > > > implementations for the various flavors of Pharo, as well as for a > > > > number of versions of Gemstone. > > > > > > > > I do not see any implementation of GRPlatform for Squeak. Presumably > > > > this might be a class called GRSqueakPlatform, but I cannot find this > > > > in any of the repositories, and the "GRPlatform current" idiom does > > > > not answer anything appropriate for generic Squeak. > > > > > > > > Hopefully I am just confused (by far the most likely explanation), but > > > > it seems that either I am not loading the right packages, or (worse) > > > > I am trying to "debug" software that nobody has gotten around to > > writing > > > > yet. > > > > > > > > Are these Travis CI failures actual failures, in the sense that they > > > > are tests that used to work, but now are failing due to some new > > > > problem? Or are they just an indication that GRSqueakPlatform does > > > > not exist, and we need to find someone to implement it? > > > > > > Right GRSqueakPlatform does not exist. The clean solution would be to > > > create a Grease-Squeak-Core and Grease-Tests-Squeak-Core with a > > > GRSqueakPlatform and the necessary class extension methods. That would > > > be very welcome. > > > Because we don't have the resources to do this we currently treat > > > Squeak as similar to Pharo 1.2 (or something) and load a > > > GRPharoPlaform class and some class extensions. If the load scripts > > > have a bug they don't even do that and you just GRPlatform with no > > > subclass. > > > > Squeak-dev: > > > > We need a volunteer to implement a Squeak-specific compatibility > > class in Grease for Seaside, as described by Philippe above. Is > > there someone who might be interested in implementing the missing > > GRSqueakPlatform support? > > > > Most likely, the implementation could be modeled after the existing > > Grease support for Pharo 1.2. Pharo 1.2 was basically the same as > > Squeak 3.9, and the Squeak development stream is generally quite > > good about maintaining compatibility of interfaces required by > > external packages. I expect that this would not be a large project, > > and it would be of great value for the Squeak community as well as > > for Seaside. > > > > Thanks! > > > > Dave > > > > _______________________________________________ > > seaside mailing list > > seaside(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > -- > jmck.seasidehosting.st > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

1 0

New Cog VMs available
by Eliot Miranda 17 Nov '14

17 Nov '14

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/. CogVM binaries as per VMMaker.oscog-eem.934/r3133 These VMs should be functionally identical to the 3126 VMs; the core VM differs only in having been compiled from generated source that has been refactored to enable convenient 32-bit to 64-bit Spur image bootstrap. I'm building and releasing them mostly to test that refactoring. However, there is new DNS support on Windows and SSL support on Unix. See below. Simulator/Slang: Refactor to allow 32-bit and 64-bit Spur to coexist in the simulator, thereby allowing a 64-bit bootstrap. Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively. Make sure these are still output as the manifest constants in the generated C. Eliminate use of bytesPerSlot in favour of bytesPerOop. The use of sends is similar to those in trunk VMMaker, but I don't have time to merge. Sorry :-(. Work-around use of sends for bytesPerOop in e.g. generateToByDo:on:indent: and users of isConstantNode:valueInto:. Do a better job at inlining via inlineCodeOrNilForStatement:in:. Comment in isNode:substitutableFor:inMethod:in: explains. Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret. Eliminate use of LargeContextSize in the stack and cog VMs. Alas haven't yet eliminated the frame offset constants such as FoxCallerSavedIP et al. We only need one of the two word sizes of interpreter to be executable in the bootstrap. And remember to generate the GdbARMPlugin Add accessorDepths for the exported browser plugin primitives for Spur. Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix. See http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249 http://bugs.squeak.org/view.php?id=7824 Have the Unix & Mac VMs print the process id and working directory when blocking on error or assert fail. Add scripts for the ARM VM archives. -- best, Eliot

6 15

Re: The Trunk: Morphic-bf.751.mcz
by Marcel Taeumel 17 Nov '14

17 Nov '14

Hi, Bert. :) Looks good, except that the interface of RealEstateAgent seems now strange. Here, we make the assumption that either the owner is a world or that the selector #maximumUsableAreaInWorld: should be renamed to something more generic. In combination with "Preferences fullScreenLeavesDeskMargins" one could question such a global preference for this owner-specific implementation. If sytem windows can be embedded in any kind of morph, the thing about desk margins should be redesigned and the interface of RealEstateAgent should be refactored. If system windows can only be embedded into paste-up morphs, "self owner" seems semantically wrong. Just for documentation. :) Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-Morphic-bf-751-mcz-tp4790392p4790613.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

2 1

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