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

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

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