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

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

Re: [Pharo-dev] What is the limit

by Marcus Denker

> On 24 Nov 2014, at 21:29, Hilaire <hilaire(a)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? Keeping mind that most of this is -> some artefact of the build process that the stack is saved open the image and save it down to 31.2MB -> the ScriptLoader package (with >123 KLOC now) down to 25.5MB -> Monticello meta data down to 22.5MB 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) Now yes, there is more code in the image than for Pharo 1.4: - Metacello. This is *HUGE* - Versionner - Kommitter - OSWindow - Rubrick editor + tests - Glamour + GT with tests - â¦... 22.5 MB is not a lot for all that. Now this image has all tests and all tools. #cleanUpForProduction removes Versionner and unloads all tests. ===> down to 17,8 MB Not too bad! Questions to ask: - is 22MB really big? Many of the apps on my phone are *much* larger than that. Even very simple ones. People these days complain when phones come with âonly 1GB of RAMâ. - Time is on our side. Moore Law for storage says we can double every year and stay constant. And I am willing to invest that for more expressive power, at least some years. - If we would *really* care for space: Wouldnât we start to e.g. start to do thing like string sharing and compression of some unused data? As always: nothing happens by itselfâ¦. Marcus

Nov. 25, 2014

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

by phil＠highoctane.be

Marcus, I am ever amazed on your delivery abilities. That's just awesome. Phil Le 25 nov. 2014 08:16, "Marcus Denker" <marcus.denker(a)inria.fr> a Ã©crit : > > > 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] NativeBoost

by Esteban Lorenzano

> 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. > 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 phil＠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? Phil

Nov. 25, 2014