- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] NativeBoost

by Esteban Lorenzano

> On 25 Nov 2014, at 08:31, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 25 Nov 2014, at 00:48, Ben Coman <btc(a)openInWorld.com> wrote: >> >> 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 ? > > I donât think so. > Also, we are not planning to run pharo over JS right now, there are a lot of things to solve before, like: no matters if VM works, none of the plugins (including FFI) will work, so they need to be rewritten, etc., etc., etc. also, I have to say that SqueakJS is for now not more than a cool experiment. eToys guys are working on it because they have a valid use case: they want to run eToys in the browser. But: - our VM will always be a lot more efficient than some translation to javascript, then run using V8. - web applications are far more complicated than running a boxed-app inside a browser, as applets debacle shows. cheers, Esteban > >> 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

Re: [Pharo-dev] What is the limit

by stepharo

Le 25/11/14 08:30, phil(a)highoctane.be a Ã©crit : > > Isn't Oz giving us images without UI tools? > It is a prototype and as you know a prototype require engineering manpower. > 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? > > Phil >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by stepharo

Le 25/11/14 08:28, phil(a)highoctane.be a Ã©crit : > > 400 megs ? O_o > Sorry classes. He has the seaside counter with 500 k > Le 25 nov. 2014 08:08, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@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 stepharo

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 > <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

Re: [Pharo-dev] What is the limit

by Esteban Lorenzano

> On 24 Nov 2014, at 23:48, phil(a)highoctane.be 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. > the average size of any app in iPhone is around 25m (or it was in 2012, nowadays should be more), so I hardly believe that :) Esteban > I rooted my phone to be able to remove vendor apps in order to get some more space. > > Phil > > Le 24 nov. 2014 22:31, "kilon alios" <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> a Ã©crit : > I have an OS (Yosemite) thats takes 5 out my 8 GB of Ram. Google Chrome with opened 20 tabs that consumes around 1 GB of Ram. Games that eat Ram like peanuts and I do 3d graphics with blender which also can consume GBs like no tommorow. Music productions was not much diffirent either. I watch movies which are several GBs each. I have 1 TB drive its already half full (mainly because of movies). > > 32 mb is nothing. XCode with an empty project cosumes 130 MB. Dont forget that it loads no libraries like Pharo and definetly is no live coding enviroment. > > Pharo consumes around 80MBs > > Emacs with zero guis still consumes 40mbs. > > Small is not beautiful its irrelevant. > > Unless you are on a platform that has real problem with sizes. > > On Mon, Nov 24, 2014 at 10:29 PM, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: > Pharo 1.4 image = 15MB > Pharo 3 image = 22MB > Pharo4 image = 32MB > > Don't know about Pharo 2.0 as, skip it. > > Is there a limit? > > Hopefully I gave up on the idea of tablet use but aren't we loosing the > sight on small is beautiful? > > Hilaire > > -- > Dr. Geo - http://drgeo.eu <http://drgeo.eu/> > iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> > > >

Nov. 25, 2014

Re: [Pharo-dev] editing the default window size of glamour inspector

by Tudor Girba

Hi, Ok. Can you open a ticket about finding a solution for custom Inspector window size? Doru On Mon, Nov 24, 2014 at 3:54 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 2014-11-24 13:11 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Sorry for not replying earlier. Thanks Nicolai for picking this one up. I >> missed the initial mail. >> >> The initialExtent does not make sense for presentation, and anyway, you >> would not want to change an inspector when you are inside a flow. If I >> understand correctly, Clement would want that when he spawns an inspector >> window on a new object, to set the window size to something else. >> >> The idea of having a gtInitialWindowExtent is intriguing, but it won't >> really work. The problem is that an object can have associated >> presentations in several external packages, so defining the initial extent >> in one of them might not work for the other ones. >> >> But, I was more thinking of a different mechanism that remembers the size >> of the inspector every time you change it, and have the next window take >> that size into account. I am even considering having this size cached by >> the class of the object (not sure yet if that makes sense). What do you >> think? >> > > Hello Doru, > > If we have a mechanism to remember the last size of the inspector per > class, it would be nice to provide in addition APIs to change this value. > Perhaps I could put on a start-up script something like: > MyClass initialInspectorSize: 1000@1000. > > My issue is that on specific classes the inspector shows a big roassal > visualization. When I inspect in a new window one of these objects, I need > each time to enlarge the window to see the full visualization. If the > previous size is saved or I can set the size somehow, it's fine for me. > > Cheers, > > Clement > >> >> Cheers, >> Doru >> >> >> On Mon, Nov 24, 2014 at 12:57 PM, Nicolai Hess <nicolaihess(a)web.de> >> wrote: >> >>> 2014-11-12 15:14 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>>> Hello, >>>> >>>> I would like for specific objects to change the default window size of >>>> the glamour inspector (Basically a bigger window will be opened by default >>>> for these objects). This is because I extended my inspectors to provide >>>> roassal visualization that are quite large. >>>> >>>> How can I do it ? >>>> >>>> For example I would like something like that: >>>> >>>> MyObject>>#gtInitialWindowExtent >>>> < gtInitialWindowExtent > >>>> ^ 800@1000 >>>> >>>> Clement >>>> >>>> >>> >>> I think this is not doable. >>> You can change the method with the inspector pragma to be called with >>> the context (inspector instance) >>> >>> gtInspectorItemsIn: composite inContext: aGTInspector >>> <gtInspectorPresentationOrder: 30> >>> >>> instead of >>> >>> gtInspectorItemsIn: composite >>> <gtInspectorPresentationOrder: 30> >>> >>> this way you have access to the glamour inspector. Unfortunately it does >>> not have any >>> window extent property. >>> >>> Maybe we can move the initialExtent property from GLMBrowser up to >>> GLMPresentation? >>> That way it would be accessible and usable for this aGTInspector >>> argument. >>> >>> >>> >>> Nicolai >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 25, 2014