January 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] About versions on PharoInbox

by Miguel Enrique CobÃ¡ Martinez

During the uploading of the mcz of Morphic to PharoInbox http://code.google.com/p/pharo/issues/detail?id=1841 I used a 10506 image. The software update gave 0 files and the Monticello browser showed: Morphic-MarkusDenker.392 my changes generated: Morphic-MiguelCoba.395 But when opening the PharoInbox I saw that there are versions like Morphic-nice.494 Morphic-TorstenBergmann.492 Morphic-AlainPlantec.490 and they have date as close as January 13, 2010. But the image has a version very old (or so appears by the version number) and my changes was based in MarkusDenker.392. Can someone explain this? Will this affect the integration of my change to PharoCore? Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 17, 2010

Re: [Pharo-project] System -> About in Dev images

by Miguel Enrique CobÃ¡ Martinez

> > > > Yes, I will do it, but tomorrow. > > Cool!! No hurry.. Well, not precisely "tomorrow" but a few days later is done: http://code.google.com/p/pharo/issues/detail?id=1841 > > My idea is to make this a preference > and the the build script just disable it. > It is a preference for PharoCore 1.0. In your ConfigurationOfPharo add somewhere: Preferences disable: #showUpdateOptionInWorldMenu to drop the option from the System -> Software update Of course, this only hides the option from the users but don't prohibits the image from being updated, just that the update must be done manually by evaluating: Utilities updateFromServer in a workspace. This way, a user that want to update their image can do it but most users won't see the option in the menu. For PharoCore 1.1 I will make the analogous change but using the Settings framework... but tomorrow :) Cheers > > Be careful with the preferences....remember all the changes in 1.1 > > > More tomorrow. > > Cheers > > > > > > cheers, > > > Mike > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > > > > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 17, 2010

[Pharo-project] SystemWindow updatablePanes ivar

by Igor Stasenko

Hello, I completely lost in the logic of this thing. why a SystemWindow cares about something called panes? What if my window don't having/needs any of them? Why Object cares about #updateListsAndCodeIn: aWindow ??? If model is updated, then it should just send #changed, or self changed: #myPaneFoo and if SystemWindow's pane is dependent, it will be updated. What the point in using #verifyContents... This thing needs to be cleaned up. -- Best regards, Igor Stasenko AKA sig.

Jan. 17, 2010

[Pharo-project] [bug] 1.0-10505 Saving image kills version browsers

by Martin McClure

It looks like if you browse versions of a method, and save the image while the versions browser is open, this sets the source pointers in all of the versions in the browser to nil. Then you get a DNU if you click on any of the versions. Workaround: Close the bad version browser, open a new one. Regards, -Martin

Jan. 17, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Eliot Miranda

On Sat, Jan 16, 2010 at 12:33 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > I wrote this test pre-closure. > The problem with closures is that they are optimized to retain a > pointer to the values of outer temporary variable they use when > activated. > Not exactly. > Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity > registeringAnActionAtFinalizationForEachObject all refer to 'hello' > pointed by o1 and its copy pointed by o2. > In other words, o1 and o2 are not the single pointers to the String > 'hello' and its copy. > They are. See below. > thenForcingFinalizationOfObjects only clean o1 and o2, but omit to > clean the closures that still point to 'hello'... > Thus, 'hello' is not finalized. > One possibility is to also clean the closures pointing to 'hello'. > But now the code is tricky... It's aim was to be simple damned :) > There are single pointers to o1 and o2 from all the code in the test. o1 and o2 are stored in an indirect temp vector array created at the start of the method. The compiler puts them there because there is an assignment to each after they are closed over: o1 := o2 := nil. Smalltalk garbageCollect]. All the blocks that reference o1 or o2 actually reference the indirect temp vector, so there is only one reference to o1 and o2 from all code in the method, though a single indirect temp vector. So as soon as o1 := o2 := nil. is executed the only references to o1 & o2 from code have been deleted. > Nicolas > > > here is a corrected version : > > > testFinalizationOfEquals > "self debug: #testFinalizationOfEquals" > > | finalizationProbe o1 o2 > forAnyTwoEqualObjects > ofDifferentIdentity > registeringAnActionAtFinalizationForEachObject > thenForcingFinalizationOfObjects > implyBothRegisteredActionsAreExecuted | > > finalizationProbe := Set new. > o1 := 'hello' copy. > o2 := 'hello' copy. > forAnyTwoEqualObjects := [o1 = o2]. > ofDifferentIdentity := [o1 ~~ o2]. > registeringAnActionAtFinalizationForEachObject := [ > o1 toFinalizeSend: #add: to: finalizationProbe with: 'first > object finalized'. > o2 toFinalizeSend: #add: to: finalizationProbe with: > 'second object > finalized']. > thenForcingFinalizationOfObjects := [ > forAnyTwoEqualObjects := ofDifferentIdentity := > registeringAnActionAtFinalizationForEachObject := nil. > o1 := o2 := nil. Smalltalk garbageCollect]. > implyBothRegisteredActionsAreExecuted := [finalizationProbe size = > 2]. > > self > assert: forAnyTwoEqualObjects; > assert: ofDifferentIdentity; > should: [ > registeringAnActionAtFinalizationForEachObject > value. > thenForcingFinalizationOfObjects value. > implyBothRegisteredActionsAreExecuted value]. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 17, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testBlockNumbering

by Eliot Miranda

On Sat, Jan 16, 2010 at 8:14 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Then blockExtentsToTempsMap values are Arrays of pairs, not exactly > what expected by the test... > The keys are ranges, the values are arrays of arrays of name, index, e.g. a Dictionary( (0 to: 6)->#(#('thisValue' 1) #('binaryBlock' 2) #('nextValue' #(3 1))) (2 to: 4)->#(#('each' 1) #('binaryBlock' 2) #('nextValue' #(3 1))) ) so self assert: tempRefs keys = method startpcsToBlockExtents values asSet. needs to become self assert: tempRefs keys asSet = method startpcsToBlockExtents values asSet. if keys no longer returns a set. Here's the (working) test in my image: testBlockNumberingForInjectInto "Test that the compiler and CompiledMethod agree on the block numbering of Collection>>inject:into: and that temp names for inject:into: are recorded." "self new testBlockNumberingForInjectInto" | methodNode method tempRefs | methodNode := Parser new encoderClass: EncoderForV3PlusClosures; parse: (Collection sourceCodeAt: #inject:into:) class: Collection. method := methodNode generate: #(0 0 0 0). tempRefs := methodNode encoder blockExtentsToTempsMap. self assert: tempRefs keys = method startpcsToBlockExtents values asSet. self assert: ((tempRefs includesKey: (0 to: 6)) and: [(tempRefs at: (0 to: 6)) hasEqualElements: #(('thisValue' 1) ('binaryBlock' 2) ('nextValue' (3 1)))]). self assert: ((tempRefs includesKey: (2 to: 4)) and: [(tempRefs at: (2 to: 4)) hasEqualElements: #(('each' 1) ('binaryBlock' 2) ('nextValue' (3 1)))]) > Nicolas > > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > Correct message is blockExtentsToTempsMap rather than > blockExtentsToTempRefs > > > > But then, method still fails because keys does not answer a Set > > anymore. Use keys asSet. > > > > Nicolas > > > > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > >> The test is incompatible with new CompiledMethod trailer > >> Use generate rather than generate: #(0 0 0 0) > >> > >> Then the method still fails because sending unimplemented > >> #blockExtentsToTempRefs > >> > >> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto > >> > >> Nicolas > >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 17, 2010

[Pharo-project] strange local variable problem

by Tudor Girba

Hi, I have a method that takes OBCommands and returns Actions: actionsFrom: aCollectionOfOBCommandClasses on: aTarget for: aRequestor | command | ^ aCollectionOfOBCommandClasses collect: [ :each | command := each on: aTarget for: aRequestor. GLMAction new icon: command icon; title: command label; action: [:presentation | command execute ]; yourself ] These actions have a block that will be executed at a later time. The problem here was that the command in the action block was always pointing to the same command object, even at each point the command variable was populated correctly. However, when the command is defined inside the block, everything works as expected. actionsFrom: aCollectionOfOBCommandClasses on: aTarget for: aRequestor ^ aCollectionOfOBCommandClasses collect: [ :each | | command | command := each on: aTarget for: aRequestor. GLMAction new icon: command icon; title: command label; action: [:presentation | command execute ]; yourself ] I believe this is a bug. Cheers, Doru -- www.tudorgirba.com "Obvious things are difficult to teach."

Jan. 17, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by John M McIntosh

On 2010-01-16, at 4:08 PM, csrabak(a)bol.com.br wrote: > > Is there a way to download a file of the presentation (be it powerpoint or PDF)? A subset at http://www.esug.org/data/ESUG2006/pres/gctalkjohnmacintosh.pdf Generally I give a talk on the current paper to clients who pay for GC consulting. It takes about 3-4 hours to give at the moment. > >> But really you have to have an understanding of how the GC behaves, >> and then the various parms (which aren't in the 2001 paper). > > OK. Is there other reference? http://www.amazon.com/exec/obidos/ASIN/0471941484/corporatsmalltal http://www.amazon.com/exec/obidos/ASIN/0201116693/corporatsmalltal > >> then some Sunits, and generate charts like slide 92, then decide >> how to alter behaviour. > > <thinking aloud> > Given the multitude of platforms and configurations, perhaps instead (or in addition to) SUnit tests, we should create some script or some code that runs and do a diagnostic suggesting the best tuning for the user. > </thinking aloud> That would be helpful, usual complaints focus on opening and using browser windows as an example. More data from a note to the squeak list a year ago, you'd have to cross check some of the discussion of setting values from that era to today. Ok, the headings would be: statGCTime oldSpaceEnd youngSpaceEnd memoryEnd fullGCs fullGCTime incrGCs incrGCTime tenureCount statMarkCount statSweepCount statMkFwdCount statCompMoveCount statGrowMemory statShrinkMemory statRootTableCount statAllocationCount statSurvivorCount statSpecialMarkCount statIGCDeltaTime pendingFinalizationSignals Most of this data comes from the primitiveVMParameter 0 args: return an Array of VM parameter values; 1 arg: return the indicated VM parameter; 2 args: set the VM indicated parameter. VM parameters are numbered as follows: 1 end of old-space (0-based, read-only) 2 end of young-space (read-only) 3 end of memory (read-only) 4 allocationCount (read-only) 5 allocations between GCs (read-write) 6 survivor count tenuring threshold (read-write) 7 full GCs since startup (read-only) 8 total milliseconds in full GCs since startup (read-only) 9 incremental GCs since startup (read-only) 10 total milliseconds in incremental GCs since startup (read-only) 11 tenures of surving objects since startup (read-only) 12-20 specific to the translating VM 21 root table size (read-only) 22 root table overflows since startup (read-only) 23 bytes of extra memory to reserve for VM buffers, plugins, etc. 24 memory threshold above which shrinking object memory (rw) 25 memory headroom when growing object memory (rw) 26 interruptChecksEveryNms - force an ioProcessEvents every N milliseconds, in case the image is not calling getNextEvent often (rw) 27 number of times mark loop iterated for current IGC/FGC (read-only) includes ALL marking 28 number of times sweep loop iterated for current IGC/FGC (read-only) 29 number of times make forward loop iterated for current IGC/FGC (read-only) 30 number of times compact move loop iterated for current IGC/FGC (read-only) 31 number of grow memory requests (read-only) 32 number of shrink memory requests (read-only) 33 number of root table entries used for current IGC/FGC (read-only) 34 number of allocations done before current IGC/FGC (read-only) 35 number of survivor objects after current IGC/FGC (read-only) 36 millisecond clock when current IGC/FGC completed (read-only) 37 number of marked objects for Roots of the world, not including Root Table entries for current IGC/FGC (read-only) 38 milliseconds taken by current IGC (read-only) 39 Number of finalization signals for Weak Objects pending when current IGC/FGC completed (read-only) 40 BytesPerWord for this image Let's look at the values, so allow me to ramble... statGCTime 123904 This is the millisecond clock time when the sample was taken. The SqueakVMMemoryPolicy will run in two modes, active or passive. In passive mode the SqueakVMMemoryPolicy process wakes up every N (5?) Seconds and takes a reading of the GC statistics. In active mode a semaphore is used to signal the SqueakVMMemoryPolicy process to collect data on every incremental GC event. oldSpaceEnd 26725864 The byte offset of old space end. We don't have the start of memory here, it's a number elsewhere, but using that and this number we would know how many bytes oldspace uses, this boundary moves higher, or lower. youngSpaceEnd 27365792 Memory is broken into old space, youngspace, free, forwarding block reserve. This is the end of allocated young space, the start of free space. memoryEnd 30183488 This byte offset is the end of memory before the forwarding blocks, so let me talk about that space where since we have some other stats on forwarding blocks later. Note: The amount of space reserved for forwarding blocks should be chosen to ensure that incremental compactions can usually be done in a single pass. However, there should be enough forwarding blocks so a full compaction can be done in a reasonable number of passes, say ten. (A full compaction requires N object-moving passes, where N = number of non-garbage objects / number of forwarding blocks). di 11/18/2000 Re totalObjectCount: Provide a margin of one byte per object to be used for forwarding pointers at GC time. Since fwd blocks are 8 bytes, this means an absolute worst case of 8 passes to compact memory. In most cases it will be adequate to do compaction in a single pass. fullGCs 1 The number of full garbage collection count from zero at image startup, on a full GC we do a full GC against all objects in the image. Doing full GC frequently is a bad thing, but perhaps it cannot be avoid, depends on the app. fullGCTime 224 The number of milliseconds accumulative from zero at image startup take in full GC work. incrGCs 1561 Number of incremental garbage collection count from zero at image startup, on a incremental GC we scan objects in the root table and in the young space. incrGCTime 1259 The number of milliseconds accumulative from zero at image startup take in incremental GC work, on machines today you'll note we can do some GC work in less than 1 milliscond, thus this count of 1,259 is less than the total taken, which is 1,561. In order to ensure events that are NEEDED to be triggered with millisecond accuracy we would like to complete a incremental GC (IGC) in 1 ms or less. If for example a IGC took say 25ms, then you would have a 25 error in average on a Delay termination. tenureCount 12 By default we allocation 4,000 objects,then do a IGC, then see if the number of survivors is greater than the survivor count of 2000. If so then we tenure all the objects to old space by moving the oldSpaceEnd higher. This then ages the objects into oldspace and they are not looked at again when doing a IGC. The 4,000/2,000 numbers where picked in the 90's, 16Mhz machines. Some Squeakers report better GC behavior by making the allocation count & threashold count higher. How high is a number that requires some statistical calculations, again you want to ensure an IGC over N objects will take about 1 ms. SqueakVMMemoryPolicy>>calculateGoals contains some sample not used code for consideration and experimentation. Also see SmalltalkImage current vmParameterAt: 5 put: 8000. "do an incremental GC after this many allocations" SmalltalkImage current vmParameterAt: 6 put: 4000. "tenure when more than this many objects survive the GC" statMarkCount 13331 The Squeak GC algorithm uses a mark algorithm to mark which objects are accessible, then a sweep to mark objects that are free versus used, then a move and compacting event that consolidates the free space into one chunk at the end of young space. In this case we know we reached the 4,000 limit of allocation by the statAllocationCount and using the root table and youngspace marked 13,331 as used. statSweepCount 5579 At the end of the IGC we swept 5,579 object, which means 5,579 objects (free or allocated where in young space). The other data statSurvivorCount at 1,591 and the allocation count of 4,000 means on the last IGC there were 1,579 object alive, we allocated 4,000 more, and on the IGC only found 1,591 alive. statMkFwdCount 109 This is a count of the number times thru the forwarding block loop. statCompMoveCount 109 This is a count of the number times thru the compression move block loop. statGrowMemory 1 memoryEnd is the limit of memory, but it might not be the limit of available memory, if so the memoryEnd can move by providing more memory. This counts the number times this happens. This happens when free memory becomes too low, or a large object cannot be allocated. statShrinkMemory 1 When free space becomes too large, then we give some back to the operating system. This counts how many times this happens. The low memory and too much free memory thresholds are arbitrarily set values. 24 memory threshold above which shrinking object memory (rw) 25 memory headroom when growing object memory (rw) Excessive statGrowMemory/statShrinkMemory incrrementing points to a problem where you are cycling between a high/low value exceeding the limits, this is expensive and the thresholds should be adjust to avoid thi. s statRootTableCount 331 "Record that the given oop in the old object area points to an object in the young area. HeaderLoc is usually = oop, but may be an addr in a forwarding block." This is the number of roots, the number of objects in oldspace (usually) that point to some object in young space. The IGC needs this information to determine which objects are live in young space. Other Smalltalk might call this the remember table. Now a bit about Squeak's implementation, some other smalltalk record what the object is and what the slot is, this can require a lot of memory and require memory to be allocated when you can't allocate memory (crash). Squeak records the object, but now if this is a Collection then later when we mark we must visit ALL the slots in the object to determine which object is in young space. How this issue shows up in Squeak is stories about people allocating large collections then for some reason squeak becomes slow, but if they do a full GC, squeak becomes fast. The SqueakVMMemoryPolicy>>calculateGoals attempts to solve this by doing: | target | ... (statMarkCount ) > (statAllocationCount*2) ifTrue: [[Smalltalk forceTenure] on: Error do: [:ex | ]]. "Tenure if we think too much root table marking is going on" If we think took much marking is going on because the root table counting is too high then we invoke Smalltalk forceTenure which tenures everything to oldspace, and hopefully removing the problem object from the root table. Although this seem excessive too much mark scanning means less CPU time for byte code interpretation. statAllocationCount 4000 At the start of the IGC, this is the number of objects that were allocated, this helps determine if the IGC was done as a result of object allocation, or because some other allocation issue required the IGC to run to fix an issue, say a large object being allocated statSurvivorCount 1591 At the end of the IGC this is the number of objects that still were alive, using the statAllocationCount, and statSurvivorCount you might be able to determine values that ensure a IGC doesn't tenure objects, yet finishes in about 1 ms. statSpecialMarkCount 633 count the number of objects we mark which are accessible by the special objects, receiver, method, activecontext, message selector, method class, receiver class,etc, and the internal remapping objects array. statIGCDeltaTime 1 For this IGC, it took 1 ms pendingFinalizationSignals 0 This is the number of weak objects that have "died" in this GC cycle. ------------------------------------------------------- I'll note Squeak out of the box has a bias to compact memory, there is a condition that Squeak can enter into where when you allocate that next object memory is full, then you do a IGC and get back a reasonal number of bytes, you allocate the object, then fail on the next one, then a IGC, get back some bytes, allocate the object, fail on the next one... This then triggers 10 of thousands of IGC events a second, Squeak appears to hang. The [Smalltalk setGCBiasToGrowGCLimit: 8*1024*1024] on: Error do: [:ex | ^self]. [Smalltalk setGCBiasToGrow: 1] on: Error do: [:ex | ^self]. in SqueakVMMemoryPolicy startUp Alters the allocation behaviour to grow memory versus doing just another IGC, so bias to grow memory. However we can't grow memory forever so the setGCBiasToGrowGCLimit to 8MB to indicate where a full GC should occur after 8MB of biased growth. This avoid the bug in the memory allocation logic. On 10-Jan-09, at 3:24 PM, Aidan Gauland wrote: > John M McIntosh <johnmci <at> smalltalkconsulting.com> writes: >> Ok, well why don't you post the first 5 lines of the file and I'll >> explain them. > > Ok, here they are... > > 123904 26725864 27365792 30183488 1 224 1561 1259 12 13331 5579 109 109 1 1 > 331 4000 1591 633 1 0 > 129430 27191724 27961664 30183488 1 224 1567 1265 13 1530 4126 192 > 192 1 1 36 4000 142 351 2 0 > 133846 27191724 29113412 30183488 1 224 1572 1270 13 3441 4341 318 > 318 1 1 44 4000 370 350 2 0 > 139371 27191724 29181436 30183488 1 224 1578 1282 13 3793 4411 270 > 270 1 1 44 4000 418 350 2 0 > 143936 27191724 29757020 30183488 1 224 1583 1294 13 4263 4474 333 > 333 1 1 44 4000 479 314 2 0 > > Oh, and I had to do "SqueakVMMemoryPolicy new; collectStatistics: true; run" to > make it create a file; just "SqueakVMMemoryPolicy run" didn't create a file. > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 17, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by csrabak＠bol.com.br

All these cases only reinforce IMNSHO that the specific 'user' (in fact programmer) input/data entry/conversion routine should be responsible for the critique of the string and we should accept only well formed strings (some standards exist, like RFC-822). Otherwise we'll end up with a lot of quasi similar methods each slightly different to accommodate some very specific need and the effort to document and maintain this will grow bigger than our resources. my 0.001999 -- Cesar Rabak Em 16/01/2010 18:09, John M McIntosh < johnmci(a)smalltalkconsulting.com > escreveu: Well oddly I encounter a simular issue on the iPhone the other week when dealing with Apple's Date Scanner logic. It seems that if a person entered 1/1/09 that would generate jan 1st, 2009. but 1/1/9 would generate jan 1st, year 1 AD I recalling read a novel set in 1715 where they talked about the year 3, meaning 1703 not 3 AD. But I can't recall anyone this millennium using year 9 to refer to 2009 although they might tap that into a entry field. I note you *must* in this case separate the *correct* way of thinking to the *common mostly correct* way of thinking. Most people you met in the USA would think that 1/1/09 means 2009, NOT 1909. Obviously for fields that *could be* a date that could be > 100 years you would have to enforce four digit years, or something, but defaulting to 1909 versus 2009 might have interesting side-effects. Also expiry date 2014 as 1/1/14 this is not assumed to be 1914. On 2010-01-16, at 9:02 AM, csrabak(a)bol.com.br wrote: > I'm afraid the 'fix' is trying to repair something is not broken! > > Date fromString: '6-Jan-10'. giving "6 January 1910" has not anything wrong. Within five year we'll have users/programmers complaining that: > > Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* it should have given "6 January 2015"!! > > Rather document that years given with two figures get counted from 1900 (as it used to be in last century) and have people to use four digits for years in the 2000s. > > Otherwise: > > 1) We need to get used to the concept of an epoch time for Pharo; or > > 2) the number to be tested has to be the current year! > > My 0.019999. . . > > -- > Cesar Rabak > > -- =========================================================================== John M. McIntosh Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by csrabak＠bol.com.br

Em 16/01/2010 18:00, John M McIntosh <johnmci(a)smalltalkconsulting.com> escreveu: John, > On 2010-01-16, at 9:11 AM, csrabak(a)bol.com.br wrote: > > > I agree with the intent but cannot figure out a means for > > evaluating (testing) the tweaking of the parameters in > > 'scientific' way!! > > > Well some clues are in > http://www.smalltalkconsulting.com/papers/GCPaper/GCTalk%202001.htm > See the "Squeak Memory Layout" page Is there a way to download a file of the presentation (be it powerpoint or PDF)? > But really you have to have an understanding of how the GC behaves, > and then the various parms (which aren't in the 2001 paper). OK. Is there other reference? > then some Sunits, and generate charts like slide 92, then decide > how to alter behaviour. <thinking aloud> Given the multitude of platforms and configurations, perhaps instead (or in addition to) SUnit tests, we should create some script or some code that runs and do a diagnostic suggesting the best tuning for the user. </thinking aloud> > Having Sunits is a important criteria since it then tells you if > changes are impacting time to run in a meaningful way, since > altering the values can have a negative effect. > Yes. Some measurable and repeatable way to do it is fundamental in order not to jeopardize the performance of Pharo. The effort to revert bad first impressions would Herculean! -- Cesar Rabak

Jan. 17, 2010