- Pharo-dev - lists.pharo.org

GTPlayground cache
by Nicolai Hess Dec. 4, 2014

Dec. 4, 2014

Since 40393 the play-cache is not read when you open the first GTPlayground in a fresh image.

3 7

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
by Eliot Miranda Dec. 4, 2014

Dec. 4, 2014

On Thu, Dec 4, 2014 at 2:46 PM, Ben Coman <btc(a)openinworld.com> wrote: > Bert Freudenberg wrote: > >> On 04.12.2014, at 04:18, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> Hi Eliot, >>> >>> On Wed, 3 Dec 2014, Eliot Miranda wrote: >>> >>> SmallFloat64 is an immediate tagged representation, like SmallInteger, >>>> so >>>> they fit within an object pointer and have no header. In 64-bit Spur >>>> there >>>> is a 3-bit tag, leaving 61 bits. SmallFoat64 steals 3 bits from the >>>> 11-bit >>>> exponent to donate to the tags, representing a full double precision >>>> floating-point value that is restricted to the ~ +/-10^+/-38 range. >>>> There's really no practical way to shoe-horn a usable range of 64-bit >>>> float >>>> into a 30-bit value. Its possible but so few values would fit that the >>>> effort would be counter-productive. DOes this make sense now? >>>> >>> I didn't mean to use 30-bit values. I meant to use the same 61-bit >>> representation as with the 64-bit Spur. >>> The object header is 64 bits long in both 32-bit and 64-bit Spur, right? >>> If yes, then why is it not possible to detect the tag of SmallFloat64 in >>> a 32-bit VM, and treat the object as immediate? >>> >> >> Because that is not what "immediate" means. There is no header, and not >> even an object. The value is encoded in the oop itself. You can't fit 61 >> bits in a 32 bit oop. >> >> I explained this previously, but I'll paste again: >> >> The Squeak VM (and Cog and Spur) traditionally use 32 bits to identify >>> an object. When you store a reference to an object into some other object, >>> the VM actually stores a 32 bit word to some place in main memory. >>> >>> When you use a Float in your code, the VM actually allocates 96 bits >>> somewhere in memory (a 32-bit header for house keeping and 64 bits for the >>> IEEE double) and gives you a 32-bit word back, which is a pointer to that >>> object (we also call that an "oop"). This is called "boxing", it wraps the >>> double inside an object. When you add two floats (say 3.0 + 4.0), the VM >>> actually creates two objects and hands you back their oops (e.g. the two >>> hexadecimal numbers @12345600 and @1ABCDE00). Then to add them, the VM >>> reads 64 bits from the memory addresses 12345604 and 1ABCDE04 (skipping the >>> object header), adds these two doubles, allocates another 96 bits in memory >>> (say @56780000), and writes 64 bits of the result to the address 56780004. >>> If this sounds expensive to you, that's because it is. It is even more >>> expensive than that because we have just created 3*96 = 288 bits of garbage >>> that needs to be cleaned up later, otherwise we would soon run out of >>> memory if we keep allocating. Since everything in Smalltalk is an object, >>> that is what the VM has to do. >>> >>> But there is a trick. The VM uses it to avoid all this allocating and >>> memory fetching for the most common operations, namely working with >>> smallish integers, which are used everywhere. >>> >>> That trick is to hide some data in the oop itself. In the 32 bits of >>> object pointers, the lowest two bits are actually always 0, because objects >>> are always allocated at addresses that are a multiple of 4 (32 bits = 4 >>> bytes). If these are always 0, we don't actually need to store them. But >>> since there is no good way to store just 30 bits, we can also use those two >>> bits for something else. >>> >>> And we do. The VM currently just uses one bit, the least significant bit >>> (LSB). If the LSB is 0, this is a regular pointer to an object in main >>> memory. If the LSB is 1, then the VM uses the other 31 bits to store an >>> integer. Inside the oop itself, not at some place in memory! It does not >>> need to be allocated, or garbage-collected. It's just there, hidden inside >>> the 32-bit oop. >>> >>> This makes operations on these "small integers" extremely efficient. To >>> add e.g. 3 and 4, the VM gets the oops @00000007 and @00000009, shifts them >>> 1 bit to get the actual integers (7 >> 1 = 3 and 9 >> 1 = 4), adds them, >>> and shifts it back, sets the LSB, and answers @0000000F. All this happens >>> in CPU registers, no memory access needed, which is why this is so fast. >>> Access to main memory is orders of magnitude slower than register access. >>> >>> We call that an "immediate object". The Squeak VM currently uses only >>> one kind of immediate objects, although there could be more, since we still >>> have an unused bit. It would be great to speed up floating point >>> operations, too. But there is no way to hide a 64-bit double in a 32 bit >>> oop. >>> >>> Which brings us to the proposed 64-bit object format. Objects are >>> allocated in chunks of 64 bits = 8 bytes, meaning addresses are multiples >>> of 8, leaving the the 3 lowest bits for identifying immediate objects. >>> >>> But there still is no way to hide a 64-bit double inside a 64-bit oop, >>> because the VM needs at least 1 bit to distinguish between regular object >>> pointers and immediate objects. >>> >>> So Eliot is proposing a 61-bit immediate Float which (just like >>> SmallIntegers) the VM can process using register operations only. This will >>> be a major boost for most floating point operations (as long as your values >>> are not larger than 10^38). >>> >> > btw, I forgot to say so when you last wrote that, it was enlightening - > thanks for taking the time to write it. > If the information was in a class comment somewhere would you have found it and read it? > cheers -ben > > -- best, Eliot

1 0

Woden and inspectors
by phil＠highoctane.be Dec. 4, 2014

Dec. 4, 2014

I have been playing with Woden. That's a place where the GTInspector would be welcome to edit values.. See: https://www.youtube.com/watch?v=1Nze9tnwYxY&feature=youtu.be Is there a way to have both the old and new inspector active? Phil

2 1

[pharo-project/pharo-core]
by GitHub Dec. 4, 2014

Dec. 4, 2014

Branch: refs/tags/40399 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 4e94db: 40399
by GitHub Dec. 4, 2014

Dec. 4, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 4e94db5d93bc17024a1017215f62aae5e4f265bc https://github.com/pharo-project/pharo-core/commit/4e94db5d93bc17024a101721… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-04 (Thu, 04 Dec 2014) Changed paths: M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/helper/newBytecodeGen.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script399.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40399.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40399 14570 OCBytecodeGeneratorTest using hardcoded bytecode generator https://pharo.fogbugz.com/f/cases/14570 http://files.pharo.org/image/40/40399.zip

1 0

[ANN] Pharo Consortium New Academic Partner Univ. Prague
by Marcus Denker Dec. 4, 2014

Dec. 4, 2014

The Pharo Consortium is very happy to announce that the Faculty of Information Technology of the Czech Technical University in Prague has joined the Consortium as an Academic Partner. About - Czech Technical University in Prague, Faculty of Information Technology: http://www.fit.cvut.cz/en - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

1 0

failing test in writing files
by sheridan＠sheridan-mahoney.com Dec. 4, 2014

Dec. 4, 2014

Hi there, I have a failing test and was wondering if anyone would have a sense as to why: | testString filename file | testString := 'ascii String'. filename := 'test-file-' , 99 atRandom printString , '.txt'. filename asFileReference ensureDelete. file := filename asFileReference writeStreamDo: [ :stream | stream nextPutAll: testString; crlf ]. self assert: file species = FileStream. Many thanks, Sheri

3 2

fixing 'format on display' and 'format on accept'
by Paul DeBruicker Dec. 4, 2014

Dec. 4, 2014

Hi - I'm going to get 'format on display' and 'format on accept' working in Nautilus. In Pharo 3 in the settings browser under 'code browsing' there is a 'pretty print' check box. As far as I can tell it doesn't affect code displaying at all in Nautilus. Is it OK to repurpose that checkbox as a control for 'format on display' and to also add a check box right there for 'format on accept' ? If not what would be better? Thanks Paul

4 6

tests coverage of minimal Pharo
by Pavel Krivanek Dec. 4, 2014

Dec. 4, 2014

Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2… To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel

6 8

Meaning of VirtualMachine>>incrementalGCCount
by Jan Vrany Dec. 4, 2014

Dec. 4, 2014

Hi there, what's exact meaning of VirtualMachine>>incrementalGCCount? Comment says: "Answer the total number of incremental GCs since startup (read-only)." But what exactly is called 'incremental CG' in context of PharoVM? Again, thanks for any clarification :-) Jan

2 2