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

Re: [Pharo-dev] [squeak-dev] New Cog VMs available

by Douglas McPherson

And ARMv6 stack VMs updated accordingly. (There is some unrelated problem with the v7 VMs, however the v6 versions do work on a v7). Doug On Nov 24, 2014, at 14:34 , Eliot Miranda wrote: > at http://www.mirandabanda.org/files/Cog/VM/VM.r3148/. > > Normal service has resumed after the recent instability due to 64-bit work. > > CogVM binaries as per VMMaker.oscog-eem.956/r3148 > > Fix regression in primitive[SmallFloat]Truncated > > Fix some warnings and some 64-bit issues with the ThreadedFFIPlugin. > > Fix positive64BitIntegerFor: by fixing new generateSignedShiftRight:on:indent:. > Symptom is LargePositiveInteger results from primGetPosition: for SmallInteger > values. > -- > best, > Eliot >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by phil＠highoctane.be

400 megs ? O_o Le 25 nov. 2014 08:08, "stepharo" <stepharo(a)free.fr> a Ã©crit : > > Let's see then.. >> > > Hilaire > > Guille is spending hour one having a bootstrapped kernel based on pavel > images. with about 400 Mb and removing dependencies. > Everybody can help. > We aask a student to develop a nice tools to spot wrong dependencies: > lookat PharoExtras ToolsDependencyAnalyser > And send fixes. > Once the bootstrap arrives to a reasonable state we will work on creating > configuration of for image level. > I have been splitting (and still continuing) polymorph and removing some > complexity. > Now this is a *****DIFFICUL******* and not sexy (where is the fame?) to > reduce and modularise a system. > So if you are concerned about the size, give a try to help. > > >> Le 24/11/2014 21:39, Esteban Lorenzano a Ã©crit : >> >>> wellâ¦ fthis days stay with the micro-concept of image sizes of ancient >>> times does not looks like a reasonable approach. Lots of conditions changed >>> and nowadays RAM is very cheap (and even tablets has enough of them) >>> but then, there are some points to observe that can help you: >>> >>> - Pharo4 will not have 32m, this is still a alpha version. It will be a >>> lot smaller (I suppose a bit bigger than Pharo3, but not much more) >>> - We are also producing the Pharo-minimal images as part of the process, >>> which are stripped versions with (for now) 6m size. Of course this one does >>> not have a lot of things that has to be reintroduced if desired (like >>> morphic), but I think is easy to have an image smaller than 10m with all >>> you need when going production in a tablet. >>> >>> nowâ¦ about small is beauty. We incorporated a lot of new cool stuff >>> (many that no one will ever notice, or use), and we need to improve in the >>> cleaning sideâ¦ there are tons of things to clean or remove there. >>> >> >> > >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by phil＠highoctane.be

Well, I am working with a couple startups in the mobile space. You see that people uninstall larger apps. It is not an opinion it is a metric. Also I am speaking about RAM too. Nexus devices are special as they usually manage storage well and have more than other devices. I have a nexus 7 around. Some apps are not able to go to the external SD card and with devices with 4 or 8 GB internal storage it becomes an issue once you factor in pictures, movies etc. Cleanmaster not withstanding. I use it too. But not everyone knows about it. Lower end smartphones aren't as good. I want Pharo to be relevant on my mobe as a dev platform through HTML5. Maybe not today but ultimately. Part of that is reducing the footprint. Java runs on the mobe in a smaller footprint. So can Pharo. A modular Pharo is the key and it is not easy to achieve it seems. PharoME - "Micro Edition" is a powerful value proposition for a lot of use cases. Coupled with things like what Goran does with Nim could open interesting avenues. I agree that machines are getting more powerful and this will not matter in the long run. But for getting in the game now it does. That's the whole point I think. Phil Le 25 nov. 2014 00:48, "kilon alios" <kilon.alios(a)gmail.com> a Ã©crit : > my opinion is this : if something needs to go because it does not add to > the usefulness of the package , then kill it without hesitation and kill > it with fire. > > But if you kill it just for the sake of keeping the distribution small > then yes I have a problem with that especially for platforms that size is > not an issue for the vast majority of users. > > Other than that I leave it to the good judgement of pharoers , obviously > sometime is not a simple decision and will depend on the particulars of the > situation. >

Nov. 25, 2014

Re: [Pharo-dev] Mess in Theme hierarchy again

by Marcus Denker

> On 24 Nov 2014, at 21:50, Hilaire <hilaire(a)drgeo.eu> wrote: > > It just appear the Theme hierarchy is mess again, with what look like > basic functionality methods appearing down in the hierarchy! > Result: switching between theme makes text color unreadable. > > https://pharo.fogbugz.com/f/cases/14524/WateryTheme-broken-again Nobody did anything (the only thing I did is to remove *a lot* of duplicated methods im the hierarchy). I guess the fix you did was not actually ever integrated. (I asked, you said âsure, itâs inâ, and closed the report). Remember: everything, even the most tinty, dumb, trivial thing only is done when it is done. *Nothing* (and please stop here and thing about it: Absolutely nothing) happens by itself. Sometimes I have the feeling that people think that simple things (especially related to cleaning up things) somehow magically are happing all by itself. For sure itâs not my wonderful brain that ever needs to be concerned with it? for sure! I only do the âThe importantâ stuff! Just joking... Marcus

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by stepharo

> Let's see then.. Hilaire Guille is spending hour one having a bootstrapped kernel based on pavel images. with about 400 Mb and removing dependencies. Everybody can help. We aask a student to develop a nice tools to spot wrong dependencies: lookat PharoExtras ToolsDependencyAnalyser And send fixes. Once the bootstrap arrives to a reasonable state we will work on creating configuration of for image level. I have been splitting (and still continuing) polymorph and removing some complexity. Now this is a *****DIFFICUL******* and not sexy (where is the fame?) to reduce and modularise a system. So if you are concerned about the size, give a try to help. > > Le 24/11/2014 21:39, Esteban Lorenzano a Ã©crit : >> wellâ¦ fthis days stay with the micro-concept of image sizes of ancient times does not looks like a reasonable approach. Lots of conditions changed and nowadays RAM is very cheap (and even tablets has enough of them) >> but then, there are some points to observe that can help you: >> >> - Pharo4 will not have 32m, this is still a alpha version. It will be a lot smaller (I suppose a bit bigger than Pharo3, but not much more) >> - We are also producing the Pharo-minimal images as part of the process, which are stripped versions with (for now) 6m size. Of course this one does not have a lot of things that has to be reintroduced if desired (like morphic), but I think is easy to have an image smaller than 10m with all you need when going production in a tablet. >> >> nowâ¦ about small is beauty. We incorporated a lot of new cool stuff (many that no one will ever notice, or use), and we need to improve in the cleaning sideâ¦ there are tons of things to clean or remove there. >

Nov. 25, 2014

Re: [Pharo-dev] NativeBoost

by stepharo

Le 25/11/14 00:48, Ben Coman a Ã©crit : > Esteban Lorenzano wrote: >> both are integrated into the image. while NB has been maintained >> directly, athens should still be loadable (if not the caseâ¦ we have a >> problem for the future :P). >> >> yes, we are slowly moving in the opposite direction of âall >> maintained in the imageâ, and eventually we plan/dream to have a >> small kernel and a bunch of configurations to produce Pharo. >> now, about NB, we do not have special plans. it is in the image and >> it will be maintained as part of Pharo. > > Maybe a package can be uploaded indicating ".movedIntoPharoImage" or > similar ? > >> >> now, since the most common use of NB is for FFI, and NB is not >> present in all platforms, we are working (Ronie, in this case) in a >> âunified FFIâ, which will provide a common abstraction layer for >> several FFI frameworks (NB, OldFFI, Alienâ¦). With that, we can choose >> which one of the frameworks we use depending on the situation (but >> ideally, we will maintain just one, the one that fits better in >> Pharo). Againâ¦ this are just ideas for the future :) >> >> Esteban > > I see in [vm-dev] a question about FFI callbacks fro SqueakJS. Will > Javascript be able to work with unifiedFFI ? First we need a good FFI for C and then we will see. Let us not over constraints the solution we want. > cheers -ben > >> >> >> >>> On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess(a)web.de >>> <mailto:nicolaihess@web.de>> wrote: >>> >>> 2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares(a)gmx.de >>> <mailto:astares@gmx.de>>: >>> >>> Hi, >>> >>> were is NB currently maintained? Only within the image as it is >>> integrated >>> or still with an external config and on STHub? >>> >>> The reason why I ask: when I load the latest NB-Core package >>> from STHub it looks like this one is outdated and back from >>> Pharo3 day >>> (trying to load it gives problems from changes in Pharo 4). >>> >>> So it looks like NB was originally developed external using STHub, >>> then integrated >>> into standard image and now it is only internally in-image >>> managed. OK. >>> >>> But the future goal is as far as I understood to manage more and >>> more packages using external configs again. >>> >>> What is the status and future plan for NB? Will the repo get >>> synchronized? Or will it stay internal only? >>> >>> Thx >>> T. >>> >>> >>> I was about to ask the same question for Athens, the packages in >>> pharo4 and sthub diverge. >>> I can merge the sthub and pharo4 version for Athens (and mabe NB), I >>> just don't know what >>> is the plan for the feauture, manage packages for Athens and NB in >>> the image or on sthub. >>> >> > > > >

Nov. 25, 2014

callback explanation

by stepharo

Begin forwarded message: From: Eliot Miranda <eliot.miranda(a)gmail.com> Subject: Re: [Vm-dev] FFI callbacks Date: 25 Nov 2014 03:19:49 GMT+1 To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Hi Bert, On Mon, Nov 24, 2014 at 2:49 PM, Bert Freudenberg <bert(a)freudenbergs.de> wrote: How do they actually work? I want to know what information the thunk needs, and what happens when it is activated. I think SqueakJS would benefit from callback support. I'll try and write this up properly in a blog post tomorrow. But... Callback is a wrapper round a piece of executable code, a block, and a "signature" (see below). The executable code is wrapped by an FFICallbackThunk, an Alien, which is just a pointer to this code. Th code is allocated from a special pool of memory marked as executable. The address of the code is unique and is hence used as a key to identify the Callback and hence locate the block from the thunk. The FFI marshalling code should pass the address of the thunk when passing the Callback. Right now that has to be done explicitly. The thunk, when called, invokes thunkEntry, which is defined in e.g. platforms/Cross/plugins/IA32ABI/ia32abicc.c (it needs a different definition for each API). On x86 thinkEntry needs only to be invoked with the think and the stack pointer, since on x86 all arguments are accessible from the stack. On other platforms thunkEntry will need to be invoked with the register arguments. thunkEntry's job is to store the state necessary to return from the callback in an instance of either VMCallbackContext32 or VMCallbackContext64. These are aliens for the following structure: typedef struct { void *thunkp; char *stackptr; long *intRegArgs; double *floatRegArgs; void *savedCStackPointer; void *savedCFramePointer; union { long vallong; struct { int low, high; } valleint64; struct { int high, low; } valbeint64; double valflt64; struct { void *addr; long size; } valstruct; } rvs; jmp_buf trampoline; } VMCallbackContext; The structure lives in the stack frame of thunkEntry, hence one per callback. It does three things: 1. it identifies all the input arguments. These are accessible, depending on platform, through stackptr, intRegArgs and floatRegArgs. 2. it maintains the jmp_buf which can be used to longjmp back to the callback to return from it. 3. it has slots to hold the result to be returned from the callback (the union rvs). The argument to the longjmp (the value returned from the setjmp in thinkEntry) tells thunkEntry how to return the result, i.e. as a 32-bit value, a 64-bit value, a double or a struct. Once thinkEntry has packed up the state in its local VMCallbackContext, it uses if ((flags = interpreterProxy->ownVM(0)) < 0) { fprintf(stderr,"Warning; callback failed to own the VM\n"); return -1; } to "own" the VM. If the VM is single-threaded then this can check that the callback is being made on the same thread as the VM, and fail otherwise. If the VM is multi-threaded ownVM can block until the thread can enter the VM. It then calls-back into the VM using interpreterProxy->sendInvokeCallbackContext(&vmcc); which sends the message (found in the specialObjectsArray) #invokeCallbackContext: which is understood by Alien (see Alien class>>#invokeCallbackContext:). This method wraps up the input argument (the raw address of thunkEntry's VMCallbackContext) in the relevant Alien and invokes Callback's entry point: invokeCallbackContext: vmCallbackContextAddress "<Integer>" "^<FFICallbackReturnValue>" "The low-level entry-point for callbacks sent from the VM/IA32ABI plugin. Return via primReturnFromContext:through:. thisContext's sender is the call-out context." | callbackAlien type | callbackAlien := (Smalltalk wordSize = 4 ifTrue: [VMCallbackContext32] ifFalse: [VMCallbackContext64]) atAddress: vmCallbackContextAddress. [type := Callback evaluateCallbackForContext: callbackAlien] ifCurtailed: [self error: 'attempt to non-local return across a callback']. type ifNil: [type := 1. callbackAlien wordResult: -1]. callbackAlien primReturnAs: type fromContext: thisContext The sendInvokeCallbackContext machinery just constructs an activation of invokeCallbackContext: on top of the current process's stack, which is usually the process that called out through the FFI. Bit it doesn't have to be. threaded callbacks are too detailed for this brief message. Callback then locates the relevant marshalling method for the callback's signature (actually it does this when the Callback is created, but the effect is the same). Callback uses methods that identify themselves via pragmas to choose the relevant marshaller. e.g. for a qsort sort function callback the marshaller on x86 is Callback methods for signatures voidstarvoidstarRetint: callbackContext sp: spAlien <signature: #(int (*)(const void *, const void *)) abi: 'IA32'> ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5))) So it fetches the arguments from the stack using Alien accessors, evaluates the block with them and then assigns the result via wordResult, and answers the type code back to invokeCallbackContext:, e.g. VMCallbackContext32 methods for accessing wordResult: anInteger "Accept any value in the -2^31 to 2^32-1 range." anInteger >= 0 ifTrue: [self unsignedLongAt: 25 put: anInteger] ifFalse: [self signedLongAt: 25 put: anInteger]. ^1 Then invokeCallbackContext: invokes the primitive to longjmp back to thunkEntry, supplying the return code that will allow thunkEntry to return the reslt correctly: VMCallbackContext32 methods for primitives primReturnAs: typeCode "<SmallInteger>" fromContext: context "<MethodContext>" <primitive: 'primReturnAsFromContextThrough' module: 'IA32ABI' error: ec> ^self primitiveFailed Then thunkEntry switches on the return code and returns to the caller. Note that sendInvokeCallbackContext and primReturnAsFromContextThrough conspire to save, set and restore the VM's notion of what the C stack is in the VMCallbackContext's savedCStackPointer & savedCFramePointer, growing the stack on callback, and cutting it back on return. There's a variable in the VM, previousCallbackContext, that primReturnAsFromContextThrough uses to make sure returns are LIFO. I imagine that somehow the VM's state needs to be saved, then the context that defined the block is activated, and then the VM would run the block until it returns (or until the return prim is called?), then the VM's state would need to be restored to what it was, and the result is passed back by the thunk returning. That's right. Am I close? Since the callback can happen at any time, and it could do anything, saving the whole VM state seems daunting. Provided that the callback occurs from the context of a callout there are no problems. Threaded callbacks take some more doing. Basically the VM needs to b sharable between threads. This is the threaded VM prototype. If you absolutely need threaded callbacks we should have a serious talk. This is not trivial to productise. HTH -- best, Eliot

Nov. 25, 2014

Re: [Pharo-dev] NativeBoost

by Ben Coman

Esteban Lorenzano wrote: > both are integrated into the image. > while NB has been maintained directly, athens should still be loadable > (if not the caseâ¦ we have a problem for the future :P). > > yes, we are slowly moving in the opposite direction of âall maintained > in the imageâ, and eventually we plan/dream to have a small kernel and a > bunch of configurations to produce Pharo. > > now, about NB, we do not have special plans. > it is in the image and it will be maintained as part of Pharo. Maybe a package can be uploaded indicating ".movedIntoPharoImage" or similar ? > > now, since the most common use of NB is for FFI, and NB is not present > in all platforms, we are working (Ronie, in this case) in a âunified > FFIâ, which will provide a common abstraction layer for several FFI > frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one of > the frameworks we use depending on the situation (but ideally, we will > maintain just one, the one that fits better in Pharo). > Againâ¦ this are just ideas for the future :) > > Esteban I see in [vm-dev] a question about FFI callbacks fro SqueakJS. Will Javascript be able to work with unifiedFFI ? cheers -ben > > > >> On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> 2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares(a)gmx.de >> <mailto:astares@gmx.de>>: >> >> Hi, >> >> were is NB currently maintained? Only within the image as it is >> integrated >> or still with an external config and on STHub? >> >> The reason why I ask: when I load the latest NB-Core package >> from STHub it looks like this one is outdated and back from Pharo3 day >> (trying to load it gives problems from changes in Pharo 4). >> >> So it looks like NB was originally developed external using STHub, >> then integrated >> into standard image and now it is only internally in-image >> managed. OK. >> >> But the future goal is as far as I understood to manage more and >> more packages using external configs again. >> >> What is the status and future plan for NB? Will the repo get >> synchronized? Or will it stay internal only? >> >> Thx >> T. >> >> >> I was about to ask the same question for Athens, the packages in >> pharo4 and sthub diverge. >> I can merge the sthub and pharo4 version for Athens (and mabe NB), I >> just don't know what >> is the plan for the feauture, manage packages for Athens and NB in the >> image or on sthub. >> >

Nov. 24, 2014

Re: [Pharo-dev] What is the limit

by kilon alios

my opinion is this : if something needs to go because it does not add to the usefulness of the package , then kill it without hesitation and kill it with fire. But if you kill it just for the sake of keeping the distribution small then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users. Other than that I leave it to the good judgement of pharoers , obviously sometime is not a simple decision and will depend on the particulars of the situation.

Nov. 24, 2014

Re: [Pharo-dev] What is the limit

by Tudor Girba

I think this discussion answers the wrong question. The question should not be if something is large or small compared with the size of the disc. The question should be: is it larger than it has to be for what it does? It is precisely this question that will keep Pharo slim. Nowadays, the greatest problem in software engineering is the limit of the human brain, not of the machine. Doru On Tue, Nov 25, 2014 at 12:18 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > >> On mobile, large apps are not staying installed for long as they are > all competing for the always too small space. > > >> If say Twitter will do with is huge size, other apps will be compared > to it. Which means that a 30 mÃ©gas app us a monster asking for removal. > > >> I rooted my phone to be able to remove vendor apps in order to get some > more space. > > who said 30mbs are large for mobile phones ? > > Twitter is reporting 57mbs memory consumption on my phone. Its a Google > Nexus 4 , its 1 year and a half old now. It has 2 gb of Ram, 1 GB is free. > > Storage wise, both Android and iOS have loads of Games that require at > least a 1 GB download. Loads of people usually complain and rage on the > comment section why the game does not run on their smartphone that does not > stop the game from being highly rated and having hundrends of millions of > downloads. > > I use the famous clean master it reports cleaning 1 GB data at least once > per month (is reporting that has cleaned 20 GBs so far) and I dont even use > my smartphone that frequently. I use it like 1 hour per day. That data is > stuff downloaded by twitter and chrome for caching etc . > > Most users have no clue how much they download and what exactly. > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 24, 2014