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

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

Re: [Pharo-dev] What is the limit

by phil＠highoctane.be

Le 25 nov. 2014 08:59, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > > >> On 25 Nov 2014, at 08:27, phil(a)highoctane.be wrote: >> >> 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. > > in iOS, pharo does not load all image into RAM for running, it just loads a paginated version, so you do not have all image in memory at a time. > this was a cool solution at the moment. > the problem why pharo is not more used in mobile is because it was slower than a native app, and there were some problems due the absence of FFI on ARM. > With Nick Ager we even did an extension to transform the main window of an iPhone into a WebView, handled (at the moment) by a seaside app using jquery mobile. > results were interesting (although I disagree with html5 supporters and I think it is still ages far from truly native). I saw some of that in the iOS VM. It is nice. HTML5 is not native speed indeed. But I am on the HTML5 bandwagon, so, that's what I do use. Hence my interest in Amber for example. Phil > > Esteban > >> 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

Voyage,Mongo and Seaside...

by olivier auverlot

Where must i initialize a mongo connection in a Seaside application when I use Voyage ? My application use the singleton mode of Voyage. What is the good place to create the singleton ? * in the initialize class method of mySeaside root WAComponent (It will called one time when Seaside initialize the hosted applications) * in the instance method initialize of my Seaside root WAComponent (It will called each time that's a user start to use the application) The second case seems to be better because the connection time is probably limited by Mongo or the connection could be broken. Someone have experimented good practices at this problematic ? Best regards Olivier ;-)

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by phil＠highoctane.be

I am working hard on that one :-) And deploying production Pharo stuff on quite a couple of systems. I hope to be able to demo that in January. Phil Le 25 nov. 2014 08:42, "stepharo" <stepharo(a)free.fr> a Ã©crit : > Phil > > If you put money on the table this can change the game. > Now our resources are CONSTRAINED> > > Stef > > 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] What is the limit

by Esteban Lorenzano

> On 25 Nov 2014, at 08:27, phil(a)highoctane.be wrote: > > 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. > in iOS, pharo does not load all image into RAM for running, it just loads a paginated version, so you do not have all image in memory at a time. this was a cool solution at the moment. the problem why pharo is not more used in mobile is because it was slower than a native app, and there were some problems due the absence of FFI on ARM. With Nick Ager we even did an extension to transform the main window of an iPhone into a WebView, handled (at the moment) by a seaside app using jquery mobile. results were interesting (although I disagree with html5 supporters and I think it is still ages far from truly native). Esteban > 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 <mailto:kilon.alios@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