- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NativeBoost

by Esteban Lorenzano

> On 25 Nov 2014, at 14:06, Torsten Bergmann <astares(a)gmx.de> wrote: > > Please enlighten me as well. I also do not yet understand the idea of this unification layer. > > So far we have > 1. FFI -> not maintained very well, no callbacks thatâs quitte not true anymore. Eliot has revived this old FFI and added the callback support ported from Alien. this is not yet ported to Pharo, so we are restrained to use Alien. > 2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination since Eliot merge with FFI, Alien is considered âin maintenance modeâ, but since it uses same primitives than regular FFIâ¦ is just about the image implementation. > 3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2. yesâ¦ but callbacks are better supported in FFI plugin, Iâm afraid. > > According to my knowledge it was the goal to continue with NB, integrate it (which is done) > and move it forward as the single solution for external calls and callbacks. > > So why do we need another layer (and mixed approach with still old FFI) instead of working > on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there > already work for AsmJit for ARM? NativeBoost will never with with iOS and some other vendors are going in the âcloseâ direction with security reasons/arguments. Also, now we will have pinned objects and a whole new infrastructure to make fast FFI (lua speeds, they say :P) so we will still need to adaptâ¦ better to have a common interface because we cannot be sure how will be the FFI of the future :( Esteban > > Thx > T. > >> Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr >> Von: "Markus Fritsche" <mfritsche(a)reauktion.de> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] NativeBoost >> >> On 2014-11-24 23:34, Esteban Lorenzano wrote: >> >>> 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). >> >> I feel that providing a common abstraction layer on top of the various >> approaches to interface to C/ C++ libraries won't be useful and should >> be considered a waste of resources. From what I understood from the >> documentation, NativeBoost seems to be the most complete interface >> technology yet. I would rather (as in: If I was capable) try to get >> NativeBoost into Squeak and add the functionality missing that still >> justifies the existence of FFI and Alien than creating an abstraction >> layer that can't cope with the differences in the tools (which was the >> reason for their first creation despite the available ones). >> >> I tried to play around with FFI and creating plugins in Squeak and >> failed (I didn't try very hard though). NativeBoost was the first thing >> I was able to wrap a DLL myself and understand how to do it. The only >> thing that I wasn't able to wrap my mind around was finalization, but >> that is also due to the fact that I couldn't find understandable (read: >> understandable to me) documentation about the underlying concept in >> Pharo. >> >> (OT: Finalization and concurrency probably is more about the concept >> rather than the implementation in Pharo?) >> >> This is a piece of opinion. We all know, that unfortunately, one doesn't >> have to have knowledge to have an opinion, so if my opinion is wrong due >> to lack of knowledge, please ignore it. >> >> Best regards, >> Markus >> >> >> >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Sebastian Sastre

if you use declarative style and make Jenkings build images for production, you can include in your deops pipeline to remove Monticello too What good that would make to size*? sebastian o/ * BTW also mobile would 99% probably not be using Monticello > On 25/11/2014, at 05:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Now this image has all tests and all tools. #cleanUpForProduction removes > Versionner and unloads all tests. > > ===> down to 17,8 MB

Nov. 25, 2014

Re: [Pharo-dev] NativeBoost

by Torsten Bergmann

Please enlighten me as well. I also do not yet understand the idea of this unification layer. So far we have 1. FFI -> not maintained very well, no callbacks 2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination 3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2. According to my knowledge it was the goal to continue with NB, integrate it (which is done) and move it forward as the single solution for external calls and callbacks. So why do we need another layer (and mixed approach with still old FFI) instead of working on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there already work for AsmJit for ARM? Thx T. > Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr > Von: "Markus Fritsche" <mfritsche(a)reauktion.de> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] NativeBoost > > On 2014-11-24 23:34, Esteban Lorenzano wrote: > > > 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). > > I feel that providing a common abstraction layer on top of the various > approaches to interface to C/ C++ libraries won't be useful and should > be considered a waste of resources. From what I understood from the > documentation, NativeBoost seems to be the most complete interface > technology yet. I would rather (as in: If I was capable) try to get > NativeBoost into Squeak and add the functionality missing that still > justifies the existence of FFI and Alien than creating an abstraction > layer that can't cope with the differences in the tools (which was the > reason for their first creation despite the available ones). > > I tried to play around with FFI and creating plugins in Squeak and > failed (I didn't try very hard though). NativeBoost was the first thing > I was able to wrap a DLL myself and understand how to do it. The only > thing that I wasn't able to wrap my mind around was finalization, but > that is also due to the fact that I couldn't find understandable (read: > understandable to me) documentation about the underlying concept in > Pharo. > > (OT: Finalization and concurrency probably is more about the concept > rather than the implementation in Pharo?) > > This is a piece of opinion. We all know, that unfortunately, one doesn't > have to have knowledge to have an opinion, so if my opinion is wrong due > to lack of knowledge, please ignore it. > > Best regards, > Markus > > >

Nov. 25, 2014

Re: [Pharo-dev] contributing to Pharo testing effort

by Marcus Denker

> On 23 Nov 2014, at 19:45, sheridan(a)sheridan-mahoney.com wrote: > > Hi there, > I am interested in helping out with writing tests in Pharo, and was wondering where would be a good place to start. I am familiar with Smalltalk from working at GemStone Systems in their QA department some years ago, but am somewhat new to Pharo. Any advice would be very appreciated. > Good questionâ¦ I think tests where done kind of randomly until now. For answering the question âwhere would test be of helpâ, I think we should look into using test coverage tools. There is http://smalltalkhub.com/#!/~ObjectProfile/S2py <http://smalltalkhub.com/#!/~ObjectProfile/S2py> But not much explanation on how to use itâ¦ Marcus

Nov. 25, 2014

Re: [Pharo-dev] NativeBoost

by Markus Fritsche

On 2014-11-24 23:34, Esteban Lorenzano wrote: > 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). I feel that providing a common abstraction layer on top of the various approaches to interface to C/ C++ libraries won't be useful and should be considered a waste of resources. From what I understood from the documentation, NativeBoost seems to be the most complete interface technology yet. I would rather (as in: If I was capable) try to get NativeBoost into Squeak and add the functionality missing that still justifies the existence of FFI and Alien than creating an abstraction layer that can't cope with the differences in the tools (which was the reason for their first creation despite the available ones). I tried to play around with FFI and creating plugins in Squeak and failed (I didn't try very hard though). NativeBoost was the first thing I was able to wrap a DLL myself and understand how to do it. The only thing that I wasn't able to wrap my mind around was finalization, but that is also due to the fact that I couldn't find understandable (read: understandable to me) documentation about the underlying concept in Pharo. (OT: Finalization and concurrency probably is more about the concept rather than the implementation in Pharo?) This is a piece of opinion. We all know, that unfortunately, one doesn't have to have knowledge to have an opinion, so if my opinion is wrong due to lack of knowledge, please ignore it. Best regards, Markus

Nov. 25, 2014

Fwd: [ci-announces] Storage maintenance planned tomorrow (2014/11/25)

by Christophe Demarey

Hello, Pleas find below an announce of a maintenance on the Inria CI infrastructure. It means we will have to shutdown our slaves this afternoon and no CI job run will be available before tomorrow. Regards, Christophe. DÃ©but du message rÃ©expÃ©diÃ© : > De : Emmanuel Jeanvoine <emmanuel.jeanvoine(a)inria.fr> > Date : 24 novembre 2014 09:47:56 HNEC > Ã : ci-announces(a)inria.fr > Objet : [ci-announces] Storage maintenance planned tomorrow (2014/11/25) > RÃ©pondre Ã : Emmanuel Jeanvoine <emmanuel.jeanvoine(a)inria.fr> > > Dear users, > > A maintenance of the storage infrastructure is planned on 2014/11/25 from > 5pm to 11pm. In order to avoid issues, you are strongly encouraged to shut > down the virtual machines of your project before 5pm. > After that, the remaining virtual machines will be shut down by the IT > team. > > If you are interested in following this maintenance you can have a look > there: https://wiki.inria.fr/ciportal/Event_20141125_storage > > Thank you for your understanding, > Emmanuel > > -- > Emmanuel Jeanvoine Research Engineer > Inria Nancy - Grand Est Office B118 > http://www.inria.fr/nancy Tel +33 3 54 95 86 21

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Marcus Denker

Of course there are issues on the tracker for all of them... > > > -> some artefact of the build process that the stack is saved > open the image and save it > down to 31.2MB https://pharo.fogbugz.com/f/cases/14367 <https://pharo.fogbugz.com/f/cases/14367> > -> the ScriptLoader package (with >123 KLOC now) > down to 25.5MB https://pharo.fogbugz.com/f/cases/14359 <https://pharo.fogbugz.com/f/cases/14359> > -> Monticello meta data > down to 22.5MB > https://pharo.fogbugz.com/f/cases/2711 <https://pharo.fogbugz.com/f/cases/2711> > And this is even not what we will have for the release, as there is e.g. 500KB of loreIpsum > strings in the imageâ¦ that should be removed. (they are for testing the editor) > https://pharo.fogbugz.com/f/cases/14315 <https://pharo.fogbugz.com/f/cases/14315> Marcus

Nov. 25, 2014

CI down local time 17h-tomorrow

by Marcus Denker

Hi, Ci will be down local time 1700 till tomorrow: > A maintenance of the storage infrastructure is planned on 2014/11/25 from > 5pm to 11pm. In order to avoid issues, you are strongly encouraged to shut > down the virtual machines of your project before 5pm. > After that, the remaining virtual machines will be shut down by the IT > team.

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Thierry Goubier

2014-11-25 8:30 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Isn't Oz giving us images without UI tools? > > Where do we stand on the remote browser thing? ( A la Spoon browser ). > > Thierry, > > Do you think we could have AltBrowser do that remote thing > I've never thought of that. Well, I did a bit, but not enough to be able to give you a man-month (or a man-week) target. It would be cool to factor out the IDE to system protocol so that you could remote it for any browser. Steph, what would be the situation for you with an internship to do something like that? As an aside, are the minimal images available from the zeroconf scripts? I could play a bit around with that (something like the GitFileTree-MergeDriver does not require a GUI, and it would be cool to be able to write an install makefile with a minimal image). Thierry > Phil >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by kilon alios

Ok here are the apps I use that loads of people also have in their phones that are more than 30 MBs 1) PDF Reader - 237MB 2) Facebook - 178 MB 3) Chrome - 148 MB 4) Respawnables (Game) 133 MB 5) Yahoo Mail - 126 MB 6) Firefox - 98 MB 7) Candy Crash Saga - 65 MB 8) G+ - 56 MB 9) Pet Rescue Saga - 53 MB 10) Google Search - 50MB 11) GMAIL - 43MB 12) Facebook Messenger - 35 MB 13) Google Maps - 32 MB 14) Twitter - 30 MB Also a +1.000.000 to Marcus about the fact that in a few years 4 GB Ram will be the standard for mobile platforms. Squeak is around 8Mbs but then I dont use it because it has all sort of issues on android.

Nov. 25, 2014