- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What is the limit

by Esteban A. Maringolo

Kilon, The comparison you're doing is wrong, you're comparing apples to oranges. To start with, I have Android KitKat where a clean Facebook app takes 33MB (as per the latest release), Chrome 65MB, etc. You might be counting app data as total size, but the data+cache part is variable and subject to each device. 20+ Megs for mobile is HUGE, the only reason to use and download such apps is if they are (or are perceived) as "indispensable", like social network, mail or browsing. Games fall into a different category, the average size for such apps take more space (but are also the first ones to be removed when available storage starts to reach its limit). On the other hand you should compare Pharo apps/with other development languages/IDEs/toolkits. Leaving aside GUI-less/file based tools (which are smaller) Pharo shines during the development stage taking an order of magnitude less than many of the IDEs out there. But the produced artifacts, being indistinguishable from the development image itself, takes the same size. Because it is "self contained" it uses only a few shared libraries or even complete frameworks like JRE/.net. Pros and Cons of this approach. The resource requirements of Pharo (and most Smalltalks) is linear as you add more images, you can't leverage "common" code between them. My servers are "simple web apps" that take ~40MB of image + 100+ MB of changes. All built from a clean Pharo image, with all caches flushed. For me that is A LOT. Not to mention the constant 5% CPU idling. I can live with that because the benefits I get outweighs the cons mentioned before, but saying that 40MB is not big for a program is not true, and it's plainly false on mobile. And in my opinion, and take this as 100% personal taste/experience, but being reckless about size/cpu requirements of the software you build leads to bloatware. Regards! El Tue Nov 25 2014 at 5:07:26 AM, kilon alios <kilon.alios(a)gmail.com> escribiÃ³: > 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] Mess in Theme hierarchy again

by Hilaire

Thanks Le 25/11/2014 15:30, Marcus Denker a Ã©crit : > >> On 25 Nov 2014, at 15:24, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Le 25/11/2014 08:16, Marcus Denker a Ã©crit : >>> Nobody did anything (the only thing I did is to remove *a lot* of duplicated methods >>> im the hierarchy). >> >> Ok >> Switch to DarkTheme, then to WaterTheme. Text color scheme get wrong. >> > > I think this is because of #installFullTheme > > if you add this to UITheme (the superclass of all) it should work: > > installFullTheme > "Installs full theme: > this theme > default forts > desktop background > completion list colors" > > self beCurrent. > SHPreferences setStyleTable: SHTextStylerST80 blueStyleTable. > PolymorphSystemSettings desktopColor: Color lightGray lighter lighter. > NECPreferences backgroundColor: UITheme current windowColor. > Paragraph insertionPointColor: UITheme current caretColor. > > > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 25, 2014

Re: [Pharo-dev] changing MC repository url display

by Sebastian Sastre

Itâs a good optimization helps > On Nov 24, 2014, at 11:09 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > So I have this problemâ¦ each time I open a MC browser I see something like this: > > <Screen Shot 2014-11-24 at 14.04.44.png> > > And as you can seeâ¦ most important part of the repositories (the NAME) is hidded because window is small. > Of course, I can enlarge the screen to see the names, but that made me think the way the information is presented is not good (because the place, sthub, ss, ss3 or whatever) is less important than the repository name. > So I would like to change that to something like: > > Pharo/Pharo40 (smalltalkhub.com <http://smalltalkhub.com/>) > Pharo/Pharo40Inbox (smalltalkhub.com <http://smalltalkhub.com/>) > Moose/Glamour (smalltalkhub.com <http://smalltalkhub.com/>) > ./mc (filetree) > VMMaker (source.squeak.org <http://source.squeak.org/>) > â¦ etcâ¦ > > since this is a small change that has a huge visual impact, I would like to discuss it before. > So, what do you think? > > Esteban >

Nov. 25, 2014

Re: [Pharo-dev] Dependencies Analyzer

by Christophe Demarey

Le 25 nov. 2014 Ã 15:03, phil(a)highoctane.be a Ã©crit : > I installed it in my 3.0 but it crashes with a DNU on TreeNodeModel>>position: > > I loaded it like this: > > Gofer it > smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis'; > configuration; > loadStable > > The article on > > http://www.baptistequide.fr/packagedependencies.php > > says that it loads on 3.0 but well, it doesn't say it works there. You're right. the latest version does not work on Pharo 30. It should not be a big deal to have it working. Most specific parts are related to Nautilus and spec changes. For example #updatePackageGroupAndClassList is bot implemented in PackageTreeNautilusUI in Pharo 30. Probably it was removed. I do not find a reference to #position: in the Package-Dependencies package, so it's difficult to guess the problem root. How to reproduce?

Nov. 25, 2014

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

by Marcus Denker

> On 25 Nov 2014, at 15:24, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 25/11/2014 08:16, Marcus Denker a Ã©crit : >> Nobody did anything (the only thing I did is to remove *a lot* of duplicated methods >> im the hierarchy). > > Ok > Switch to DarkTheme, then to WaterTheme. Text color scheme get wrong. > I think this is because of #installFullTheme if you add this to UITheme (the superclass of all) it should work: installFullTheme "Installs full theme: this theme default forts desktop background completion list colors" self beCurrent. SHPreferences setStyleTable: SHTextStylerST80 blueStyleTable. PolymorphSystemSettings desktopColor: Color lightGray lighter lighter. NECPreferences backgroundColor: UITheme current windowColor. Paragraph insertionPointColor: UITheme current caretColor.

Nov. 25, 2014

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

by Hilaire

Le 25/11/2014 08:16, Marcus Denker a Ã©crit : > Nobody did anything (the only thing I did is to remove *a lot* of duplicated methods > im the hierarchy). Ok Switch to DarkTheme, then to WaterTheme. Text color scheme get wrong. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 25, 2014

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

by Hilaire

Le 25/11/2014 08:16, Marcus Denker a Ã©crit : > I guess the fix you did was not actually ever integrated. > (I asked, you said âsure, itâs inâ, and closed the report). Indeed, as I replied to you, it was integrated because that part is not broken any more, in Pharo3 (I reported for it) and in Pharo4. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 25, 2014

Dependencies Analyzer

by phil＠highoctane.be

I installed it in my 3.0 but it crashes with a DNU on TreeNodeModel>>position: I loaded it like this: Gofer it smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis'; configuration; loadStable The article on http://www.baptistequide.fr/packagedependencies.php says that it loads on 3.0 but well, it doesn't say it works there. Looks like widgets have had a facelift. What was changed there? It is an interesting tool for my own work too, so I'd like to have it running. Any pointers before digging down the rabbit hole? Phil

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Hilaire

Le 25/11/2014 08:08, stepharo a Ã©crit : > > 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. Yes, I know it is difficult. > So if you are concerned about the size, give a try to help. I would love to, but given my little time slot I can dedicate to Smalltalk, by doing so I will have to stop Dr.Geo et al. I hope time will give oportunity to help in on way or another. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 25, 2014

Re: [Pharo-dev] NativeBoost

by Esteban Lorenzano

ah, and yes. this is a mess. quitte the oposite to out âideal situationâ Esteban > On 25 Nov 2014, at 14:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> 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