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

Re: [Pharo-dev] Monticello and Fuel

by Eliot Miranda

Hi Thierry, On Thu, Dec 4, 2014 at 2:31 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi all, > > I'm just wondering. > > Would it work to have a package format based on Fuel? > It doesn't have to be based on Fuel. Monticello .mcz's are just zips that contain any number of files: Archive: trunkpackages/Kernel.spur-eem.866.mcz Length Date Time Name -------- ---- ---- ---- 15 08-07-14 09:12 package 294780 08-07-14 09:12 version 1370995 08-07-14 09:12 snapshot/source.st 1442870 08-07-14 09:12 snapshot.bin -------- ------- 3108660 4 files Right now package and version are juts textual, and you've been complaining about the parsing speed. It would be easy to extend the package to include e.g. version.fuel. It is also a huge advantage to keep both the .bin (a not-as-fast binary loading format similar in use to Fuel but more primitive) along side the source code, because the source can be extracted without a running system, and can be compiled if, for some reason, binary loading fails. So instead of changing the format you could simply augment it with a snapshot.fuel, modifying the writer to include it, and modify the reader to use the .fuel if it exists. Would that make loading faster? > Yes. But not hugely because the .bin already loads faster than the .st. You might do some profiling? > Does it already exist? > Much of what you need is there. Use the Pharo, Luke. > > Thanks, > > Thierry > -- best, Eliot

Dec. 4, 2014

Re: [Pharo-dev] GTPlayground cache

by Tudor Girba

Done. It will be available in the next GT release. Doru On Thu, Dec 4, 2014 at 4:02 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 04 Dec 2014, at 15:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 04 Dec 2014, at 15:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Aha. So, that's a bug, right? > > > I think Playground needs to be resetted on #cleanUpForRelease. > > Else the image on the server thinks that it already has a playground file. > > > Add to GTPlayBook > > cleanUp > self reset > > > Then this will be called on the build server. > > Marcus > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 4, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break

by Eliot Miranda

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

Dec. 4, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Eliot Miranda

Hi Thierry, On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Yes, but *I* care about the Monticello metadata. IMO its *better* than >> the git metadata. >> > > Eliot, you'll have to do better than just IMO on that one. > Quite right. One benefit is that Monticello metadata, at least per-method time stamps, are available for introspection inside the image. Just today I was alerted of some bad code by a particular author and it was very convenient to read all the methods by that particular author, which helped me find another problem. I also like the free frorm of the middle of method timestamps; I can and do annotate with labels for specific refactorings. Another benefit is that Monticello is amenable for scripting much more easily than git. I've been working on the SPur bootstrap fro a while now. It is essentially complete. What the bootstrap does in Monticello is construct patched versions of four packages, substituting specific methods with replacements. Each patched package inherits both from its patched ancestor and the package that was patched (a ladder like structure). This allows Spur to keep up-to-date automatically w.r.t. Squeak trunk. I'm also delighted that work like Chris Muller's version server is out there. This is very nicely integrated to allow me to find out which package versions contain versions of a particular method or class definition. Some of us work with *both*, and have code for going back and forth, so the > *better*; bah. > > I also happens to know how long it takes to parse hundreds of monticello > metadata files... and I wasn't impressed with the result. > Yes, but this can be reengineered. Most things can be optimized. This could be with a little effort. What's needed is to generate and maintain momentum. That's what worries me about git integration. It's a slippery slope towards giving up Monticello and just using git. And git itself will one day be viewed as old-hat. Monticello should be easy to keep evolving. It's in Smalltalk few chrissake. > >> What's really lacking in Monticello is a) it's not high school so one >> can't preen in front of the world on github and b) it has no support for >> external files. Well, a) will be solved by growing up and b) can be solved >> by building the solution. I know what I'd rather do. >> >> >> [and apologies for being deliberately incendiary but I *hate* the >> movement away from tools in Squeak/Pharo. It is a movement towards stasis >> and death, and personally I'm enjoying life too much]. >> > > You then have noticed that those threads are about working on tools? > Yes, and that's why I'm writing to the thread. I hope that work on integrating foreign file support, and integrating things like Chris Muller's version server continues in the Pharo community. More than anything I hope that Monticello remains a bridge between the Squeak and Pharo communities. > > > Thierry > > > > -- best, Eliot

Dec. 4, 2014

Semaphore seems to timeout prematurely

by Jan Vrany

Hi there, I have encountered a situation where semaphore timeouts prematurely when run in "non-interactive" mode (eval cmdline handler). Setup (script prepare.sh) 1) Fresh Pharo image (3.0 / 4.0, both exhibits the same behaviour) 2) Evaluate: == Smalltalk at: #WaitBlock put: [:sema :tout | (sema waitTimeoutSeconds: tout) ifTrue:[ Halt now ] ]. == 3. Save image Run 1: 1) Run the image, open workspace 2) Evaluate: == | sema | sema := Semaphore new. [ 100 factorial. sema signal ] fork. (Smalltalk at: #WaitBlock) value: sema value: 60*60. 'OK' == Returns 'OK' as expected (100 factorial should not take more than hour :-) Run 2 (script test.sh) 1) The same, but evaluate using command line handler: ./pharo Test.image eval "\ | sema |\ \ sema := Semaphore new.\ [ 100 factorial. sema signal ] fork.\ (Smalltalk at: #WaitBlock) value: sema value: 60*60.\ 'OK'\ " Halt triggers, which is what I would not expect. Why is that? Bug? Or Am I missing something obvious? Best, Jan

Dec. 4, 2014

Re: [Pharo-dev] Monticello and Fuel

by Ben Coman

Thierry Goubier wrote: > Hi all, > > I'm just wondering. > > Would it work to have a package format based on Fuel? > > Would that make loading faster? > > Does it already exist? > > Thanks, > > Thierry What is your use case for needing it faster? * Just every day developer use? * CI automation? * Something in production? * Other? cheers -ben

Dec. 4, 2014

Re: [Pharo-dev] Woden and inspectors

by Ben Coman

phil(a)highoctane.be wrote: > 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 > <https://www.youtube.com/watch?v=1Nze9tnwYxY&feature=youtu.be> > > Is there a way to have both the old and new inspector active? > Can the old inspector become a tab in GTInspector? --> stop gap best of both worlds. > Phil > >

Dec. 4, 2014

Re: [Pharo-dev] [ANN] Transition of Ubuntu PPA maintenance

by Ben Coman

Markus Fritsche wrote: > Hello, > > The maintenance of the Ubuntu Pharo VM and .source Packages is being > transferred from Damien Cassou to myself, Markus Fritsche. By trade, I > am a Business Intelligence consultant, but always following what's going > on with smalltalk/ pharo. > > If you experience any problems with the ubuntu packages, please feel > free to contact me. I might not be able to help right away, but I'll try > my best! > > Best regards, > Markus > > Thanks for this Markus. cheers -ben

Dec. 4, 2014

Re: [Pharo-dev] Twittering Smalltalk

by Ben Coman

Torsten Bergmann wrote: > See attachement, Pharo is on the right track ;) > > Bye > T. Nice. I really like this one... "Choosing a language because it has cheaper developers is like building a house with Lego so you can hire anyone as a construction worker." Pharo might adopt that somewhere on their home page or conference slide presentations. cheers -ben

Dec. 4, 2014

Monticello and Fuel

by Thierry Goubier

Hi all, I'm just wondering. Would it work to have a package format based on Fuel? Would that make loading faster? Does it already exist? Thanks, Thierry

Dec. 4, 2014