- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tests Guard report 20111

by StÃ©phane Ducasse

yes probably because this tests have side effect on the events. Stef On Jun 3, 2012, at 7:58 PM, Pavel Krivanek wrote: > Tests Guard report for update 20111: > http://code.google.com/p/pharo/wiki/TestsGuard > > We have got 6 new tests failures: > KernelTests?.Classes.ClassBuilderFormatTests?.testByteVariableSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testSubclassWithInstanceVariables > KernelTests?.Classes.ClassBuilderFormatTests?.testVariableSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testWeakSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testWordVariableSubclass > > Cheers, > -- Pavel >

June 3, 2012

Re: [Pharo-project] [Vm-dev] Re: Plan/discussion/communication around new object format

by Levente Uzonyi

On Wed, 30 May 2012, Igor Stasenko wrote: > > Here are couple (2) of mine, highly valuable cents :) > > 2^20 for classes? > might be fine (or even overkill) for smalltalk systems, but could be > quite limiting for one who would like experiment and implementing a > prototype-based frameworks, > where every object is a "class" by itself. I think it's more important to have a fast Smalltalk VM, than one that is slower, but might fit for a concrete experiment which might happen sometime and would get some performance boost from the implementation. > > --- > 8: slot size (255 => extra header word with large size) > 3: odd bytes/fixed fields (odd bytes for non-pointer, fixed fields for > pointer, 7 => # fixed fields is in the class) > 4 bits: format (pointers, indexable, bytes/shorts/longs/doubles > indexable, compiled method, ephemerons, weak, etc) > 1: immutability > 3: GC 2 mark bits. 1 forwarded bit > 20: identity hash > 20: class index > --- > what takes most of the space in object header? right - hash! > Now, since we will have lazy become i am back to my idea of having > extra & arbitrary properties > per object. > > In a nutshell, the idea is to not store hash in an object header, but > instead use just a single bit 'hash present'. > > When identity hash of object is requested (via corresponding primitive) > the implementation could check if 'hash present' is set, > then if it's not there , we do a 'lazy become' of existing object to same object > copied into another place, but with hash bit set, and with extra 64-bit field, > where hash value can be stored. > > So, when you requesting an identity hash for object which don't have it, > the object of from: > [header][...data.. ] > copied to new memory region with new layout: > [header][hash bits][...data..] > > and old object, is of course 'corpsed' to forwarding pointer to new location. The weak point of this idea is that you might run of out memory during the allocation of the new object if you ask the identity hash of a larger object or many smaller objects at once. > > Next step is going from holding just hash to having an arbitrary & > dynamic number of extra fields per object. > In same way, we use 1 extra bit, indicating that object having extra properties. > And when object don't have it, we lazy-become it from being > [header][...data.. ] > or > [header][hash bits][...data..] > to: > [header][hash bits][oop][...data..] > > where 'oop' can be anything - instance of Array/Dictionary (depends > how language-side will decide to store extra properties of object) > > This , for instance , would allow us to store extra properties for > special object formats like variable bytes or compiled methods, which > don't have the instance variables. > > Not need to mention, how useful being able to attach extra properties > per object, without changing the object's class. > And , of course the freed 18 bits (20 - 2) in header can be allocated > for other purposes. > (Stef, how many bits you need for experiments? ;) > > ------------ > > About immediates zoo. > > Keep in mind, that the more immediates we have, the more complex implementation > tends to be. > > I would just keep 2 data types: > - integers > - floats > > and third, special 'arbitrary' immediate , which seen by VM as a 60-bit value. > The interpretation of this value depends on lookup in range-table, > where developer specifying the correspondence between the value > interval and class: > [min .. max] -> class > > intervals, of course, cannot overlap. > Determining a class of such immediate might be slower - O(log2(n)) at > best (where n is size of range table), but from other side, > how many different kinds of immediates you can fit into 60-bit value? > Right, it is 2^60. Much more than proposed 8 isn't? :) > > And this extra cost can be mitigated completely by inline cache. > - in case of regular reference, you must fetch the object's class and > then compare it with one, stored in cache. > - in case of immediate reference, you compare immediate value with min > and max stored in cache fields. > And if value is in range, you got a cache hit, and free to proceed. > So, its just 1 extra comparison comparing to 'classic' inline cache. > > And, after thinking how inline cache is organized, now you can scratch > the first my paragraph related to immediates! > We really don't need to discriminate between small integers/floats/rest!! > They could also be nothing more than just one of a range(s) defined in > our zoo of 'special' immediates! > > So, at the end we will have just two kinds of references: > - zero bit == 0 -- an object pointer > - zero bit == 1 -- an immediate > > Voila!. > > We can have real zoo of immediates, and simple implementation to support them. > And not saying that range-table is provided by language-side, so we're > free to rearrange them at any moment. > > And of course, it doesn't means that VM could not reserve some of the > ranges for own 'contracted' > immediates, like Characters, and even class reference for example. > Think about it :) > I like the idea, but I'm not sure how useful it will be in practice. I'd also add characters as third data type. String/Character operations should be as fast as possible. Levente

June 3, 2012

Re: [Pharo-project] Some steps towards headless on OS X

by Mark Smith

On 3 Jun 2012, at 18:27, Sean P. DeNigris wrote: > > Mark Smith wrote >> >> Marking the process as background only will remove the icon, menu etc. but >> it will not stop us from creating that window. >> ... >> Anyway I'd like to keep working on this but I've hit a wall > Are your changes publicly available anywhere? I didn't make many changes yet. The machinery is already there but isn't functional. If you set the LSBackgroundOnly key in Info.plist to YES and run headless you will see that the icon and menu bar are goneâ¦ only the window remains :). With this change in place â When the VM is not run in headless mode it it brings itself into the foreground. Unfortunately this cannot work the other way around because foreground processes cannot become background processes (we'll have to ask Apple why that is exactly :). When the VM is run in headless mode it stays in the background, but our window will be visible. If we can change the VM such that no window is created in headless mode then everything should function as we expect. That's where I get lost. The obvious thing to try (which I tried ;) is to not create a window, but then the VM doesn't start and the application just exits [normally]. I have no idea why starting the VM would have anything to do with the creation of a window but this seem to be the case. That said Mac applications aren't exactly friendly to headless operation. That is that they're sort-of-intended to be graphical. The other solution would be to make a headless VM, similar in operation to perl/python/ruby... which is really what we want. I think ;). > -- > View this message in context: http://forum.world.st/Some-steps-towards-headless-on-OS-X-tp4633047p4633048… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 3, 2012

[Pharo-project] Tests Guard report 20111

by Pavel Krivanek

Tests Guard report for update 20111: http://code.google.com/p/pharo/wiki/TestsGuard We have got 6 new tests failures: KernelTests?.Classes.ClassBuilderFormatTests?.testByteVariableSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testSubclassWithInstanceVariables KernelTests?.Classes.ClassBuilderFormatTests?.testVariableSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testWeakSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testWordVariableSubclass Cheers, -- Pavel

June 3, 2012

Re: [Pharo-project] Some steps towards headless on OS X

by Sean P. DeNigris

Mark Smith wrote > > Marking the process as background only will remove the icon, menu etc. but > it will not stop us from creating that window. > ... > Anyway I'd like to keep working on this but I've hit a wall Are your changes publicly available anywhere? -- View this message in context: http://forum.world.st/Some-steps-towards-headless-on-OS-X-tp4633047p4633048… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2012

[Pharo-project] Some steps towards headless on OS X

by Mark Smith

Hi all, The underlying problem with headless mode in OS X seem to be that we always create a window, even when we run in the background, as we do in headless mode*. Marking the process as background only will remove the icon, menu etc. but it will not stop us from creating that window. Maybe I don't know enough about how Squeak/Pharo works right now but it looks like quite a lot of work to change this. And the code isn't pretty ;). Anyway I'd like to keep working on this but I've hit a wall. I can handle the Cocoa side but don't know anything about the VM's setup process etc. Could someone clarify this? Or maybe there are some docs? Also â What do you guys think about building a headless VM without any of the UI stuff in it? It might be simpler/cleaner than what we have now. All the best, Mark * Creating the window is almost the first thing we do! We do it before we know if we're running headlessâ¦

June 3, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Phil (list)

On Jun 3, 2012, at 11:31 AM, Marcus Denker wrote: > > How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... > ProGuard (http://proguard.sourceforge.net/) is a popular method. In its obfuscation phase it will rename most class and method names (i.e. anything that doesn't need to be externally visible) to meaningless names so MyClass.MyMethod becomes something like a.a. It can also generate a mapping file so that when bug reports / crashes occur, the developer can map the gibberish names back to the original names. Before the obfuscation phase, it has optimization and shrinking phases to eliminate code that doesn't need to be included for release (debugging code etc.) > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > Thanks, Phil

June 3, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Marcus Denker

On Jun 3, 2012, at 5:26 PM, Ben Coman wrote: >> > > Ultimately at that level - there is no security. This only raises the level of difficulty by requiring a certain conjunction of skill, motivation and ethics. It is no worse than the same attack targetted at option (3.). However there is now some incentive for commercial companies to invest the the effort into releasing an App to execute on top of an otherwise open-source platform. The advantage is that it if ten plugins were required to do proprietary calculations on one dataset and integrate the results into a single screen, then running within the one image seems more elegant than ten images running on ten VMs. How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... Marcus -- Marcus Denker -- http://marcusdenker.de

June 3, 2012

Re: [Pharo-project] Trouble loading XML RPC

by garduino

Hi: Sorry the late answer.... If you take an 1.4 stock image, and evaluates (as is commented on http://code.google.com/p/pharo-xmlrpc/) Gofer it url: 'http://ss3.gemstone.com/ss/XMLRPC'; package: 'ConfigurationOfXMLRPC'; load. and then: (ConfigurationOfXMLRPC project version: '1.0-Beta4') load: 'All'. the whole stuff should load. I noticed an error: This package depends on the following classes: TranscriptStream You must resolve these dependencies before you will be able to load these definitions: isTranscriptStream (May be another thing changed in Pharo that I need to know and fix, press proceed to load anyway). But the bad new is that in 1.4 I've some errors on tests, mainly a serious one in server that freeze the image, caution. However, the XMLRPC Client seems to work. XMLRPC is always in my to-do list but a project in what I can invest only a portion of my limited free time. The latest new was that I adapted the Client to use with Zinc, but need still to make the same thing with the server, then all xmlrpc should install and run in a stock image, without need Komanche for example. With respect to Pharo 2.0 I can't help, not tried yet. HTH. GermÃ¡n. -- View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633037.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Ben Coman

Nicolas Cellier wrote: > 2012/6/3 Ben Coman <btc(a)openinworld.com>: > >> Igor Stasenko wrote: >> >>> On 30 May 2012 16:04, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>>> What ideas are floating around about mixing open source and closed source >>>> using Pharo? I am implementing an IEC Standard object model for >>>> electrical >>>> power systems to provide a platform for developing electrical >>>> applications. >>>> I am considering the case where a company may maintain the model of >>>> their >>>> electrical power distribution network in the open source platform, but >>>> then >>>> buy various commercial plug-ins perform different calculations upon the >>>> shared model. Here are the options I can imagine... >>>> >>>> 1. Using fuel to load binary packages within the one image without the >>>> source. Currently available technology but viewing and decompiling >>>> bytecode >>>> is still possible - but to what degree this enables reverse engineering I >>>> am >>>> not sure. >>>> >>>> >>> Decompiler is able to fully reproduce the source code of method. >>> only variable names is lost, but you can see everything else quite clear. >>> >>> >>> >>>> 2. Having VM support for restricting displaying/decompiling bytecode. To >>>> avoid the ease of switching to another VM without this restriction, the >>>> fuel >>>> package could be encrypted with a key match one compiled inside the >>>> required >>>> VM. >>>> >>>> >>> this is not an option. >>> A current Debugger implementation implies that you have access to CM >>> bytecodes. >>> >>> >> A required implication of (2.) would be that you could not debug "through" >> that package. While this might be unfortunate from an open-source debugging >> view point, in comparison to having the whole application delivered >> closed-source with development tools stripped - I would still consider this >> to be a step up. Ignoring the current implementation of Debugger, could >> something like this be reasonably achievable? >> To expand on this with a specific use case... The VM could internally >> generate a public/private key pair. When requesting a plug-in from an App >> Store, the public key is sent which the App Store uses to encrypt the >> bytecode of the plug-in. Once downloaded into the image, upon execution the >> VM receives the encrypted bytecode, decrypts it with its private key and >> caches the decrypted bytecode internally, such that it is never visible to >> the image. >> >> > > Then what prevents an attacker to dump process memory and retrieve the > bytecodes from well known image structure patterns, or a custom image > tracer? > > Nicolas > > Ultimately at that level - there is no security. This only raises the level of difficulty by requiring a certain conjunction of skill, motivation and ethics. It is no worse than the same attack targetted at option (3.). However there is now some incentive for commercial companies to invest the the effort into releasing an App to execute on top of an otherwise open-source platform. The advantage is that it if ten plugins were required to do proprietary calculations on one dataset and integrate the results into a single screen, then running within the one image seems more elegant than ten images running on ten VMs. >> (btw, I'm assuming CM bytecodes was a typo meant to be VM bytecodes? or >> otherwise what is CM?) >> >> >>>> 3. Running multiple images on a single VM such that the VM passing >>>> message >>>> calls efficiently between the two images like an "enterprise bus*" - one >>>> open source and one closed source. Any common base objects between the >>>> images might be shared on a copy-on-write basis. >>>> >>>> >>>> What are your thoughts? >>>> >>>> >>>> >>> I think option 3 is most vital: >>> you can communicate between two images like between two parties who >>> don't trust each other (so images should handshake, use encryption >>> key(s), and try to log-in one to other), then if succeed, one can be >>> able to see source code use remote debugger etc >>> Nothing new under the sun... >>> >>> >>> >>>> cheers -ben >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > >

June 3, 2012