- Pharo-dev - lists.pharo.org

Woden
by volkert＠nivoba.de Dec. 5, 2014

Dec. 5, 2014

I want to play a bit with Woden. What are the system requirements? What VM do i need? I tried to load Woden it into Pharo 3.0 (with Default Pharo VM) System: Ubuntu 14.04 x64. Volkert

1 0

Code retrieval on primitive failed
by Blondeau Vincent Dec. 4, 2014

Dec. 4, 2014

Hello everyone, I am doing some developments with NativeBoost and unfortunaly I succeed to save my image in a unstable state. I am using the last moose image i.e.: Pharo3.0 - Latest update: #30860. So when I want to launch my image, I get a primitive faillure. The interesting part of the stack trace is : Stack backtrace: [07EE7A1B] ??? + 0 in (null) [00539AB5] ??? + 1284789 in Pharo.exe Smalltalk stack dump: 0x2410b8 M NBFFICallout class(NBNativeCodeGen class)>retrySend: 0x4c70b4c: a(n) NBFFICallout class 0x2410ec I NBFFICallout class(NBNativeCodeGen class)>retrySend: 0x4c70b4c: a(n) NBFFICallout class 0x78a0d90 s RDoubleVector(OrderedCollection)>at: Then I wanted to retrieve my changes on a new image but, as the doIts are not recorded, I have neither the method deletions nor all the operations on classes nor the trait methods that are recorded as Doits with preamble: Trait method. I tried to launch my image with squeak (which doesn't support NativeBoost) to hope saving or commit my code. But as I am calling a primitive at startup of the image to initialize the external environement. I got the following trace : [31m==== Startup Error: PrimitiveFailed: primitive #isEnabled in NativeBoost class failed [0mNativeBoost class(Object)>>primitiveFailed: NativeBoost class(Object)>>primitiveFailed NativeBoost class>>isEnabled NativeBoost class>>forCurrentPlatform NativeBoost class>>loadSymbol:fromModule: RSession class(Object)>>nbGetSymbolAddress:module: So what can I do to retrieve all my code without loose a day to rewrite it? Thanks in advance Vincent ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

3 5

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