October 2017 - Pharo-users - lists.pharo.org

How to recover selections in a fastlist after an update

by Steven Costiou

Hi, I am using fastlists in a browser inspired from glmexamples, and when i use a stepping and that i update the browser (update method) all selections in lists are lost. Is there an automatic way to recover the selections or does it have to be handled in my code ? If so, i don't understand how to recover my selection, if i kept the fastlist in a var, doing list selection: myObject does not do anything. Steven.

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Dimitris Chloupis

to be more specific what I mean because apparently I may know nothing about namespaces , I was talking in terms of Python's module and package system even though python uses special syntax "import" to import a module, a source file, the real functionality is actually a method but of an object dealing with the handling of modules and packages , packages are basically file directories containing mutliple modules as soon as you do the import the syntax is the usual object syntax so Dog.bark() can be anything 1) A class method call, Dog being the class 2) A instance method call, Dog being the instance 3) or a function call, Dog being the function , which is also an object (methods in python are basically function object taking the reference to an instance as first argument, hence why the weird syntax of adding self as first argument when we define instance method) and Dog is the module imported. of course in case (3) you can collapse the module "name" so you can do only bark() if you import via "from Dog import *" which means from module Dog import every object. But from import is frown upon in the python world because obviously it makes it easier to have name collision which is what the module system try to avoid in the first place. So the equivelant of pharo would be MyModule MyInstance myMessage: or if you include packages as well MyPackage MyModule MyInstance myMessage: which follows pharo syntax and OO design. That's my general idea at least. Please enlighten me :) On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> fair enough you think namespaces are not the right solution, what you >>> think is the right solution then ? >>> >> >> I told you. Namespaces are a solution, but they come with issues. >> >> > > Then I misunderstood you but I am geniouly interested in what those > problems are and I think the infromation is something others will find > interesting as well. > > No. In the HPC world, a common held position is that Fortran code is 30% >> faster than C++. >> > > Cannot even rememeber the last time a 3d graphics developers mentioned > Fortran.I occasional frequent forums and mailing lists plus keeping in > contact with Blender developers. > > I have heard that Fortran can outperform C++ in numeric computation around > the percentage you mentioned but first time I heard that its generally > faster. > > Language Benchmark seems to strongly disagree > > http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc&lang2=gpp > > of its widely criticized but then what benchmark is not > > >> Remember that part of my job is to write compilers. >> >> > I knew that you write compilers (SmaCC) I did not realise you are a pro > and especially on ones that generate highly optimised machine code > > >> I'm also consider a guy to talk to when someone has deep issues with some >> of the new features of C++... even if I don't do C++, I can often reframe >> what the feature means in the overall scheme of programming languages. >> > > On other hand I have close to zero experience on compilers > . > > >> I find it very interesting. I consider that current compilers are very >> good optimising code that is written in a language that obscures the >> developper intent in the first place. >> > > I lost you there, you mean compilers for other languages than C++ ? > > As I told you, I work in a world where performance is paramount and C++ is >> strongly criticized for the fact its incidental complexity makes it very >> very hard to reach or maintain performance levels (compared to Fortran, >> say). >> >> Thierry >> >> > > And I "work" in a world that C++ is the undisputed king , that's 3d > graphics , though I must admit I try to stick with Python as much as I can. > > In any case my point was that if namespaces can be done in a badly design > language , should be possible in Pharo and easier. Not ease, just easier. > > Of course that's just a wild assumption but I hope this thread do not only > disaprove my assumption but said a light in the real challanges of > namespace implementation > >

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Dimitris Chloupis

On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> fair enough you think namespaces are not the right solution, what you >> think is the right solution then ? >> > > I told you. Namespaces are a solution, but they come with issues. > > Then I misunderstood you but I am geniouly interested in what those problems are and I think the infromation is something others will find interesting as well. No. In the HPC world, a common held position is that Fortran code is 30% > faster than C++. > Cannot even rememeber the last time a 3d graphics developers mentioned Fortran.I occasional frequent forums and mailing lists plus keeping in contact with Blender developers. I have heard that Fortran can outperform C++ in numeric computation around the percentage you mentioned but first time I heard that its generally faster. Language Benchmark seems to strongly disagree http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc&lang2=gpp of its widely criticized but then what benchmark is not > Remember that part of my job is to write compilers. > > I knew that you write compilers (SmaCC) I did not realise you are a pro and especially on ones that generate highly optimised machine code > I'm also consider a guy to talk to when someone has deep issues with some > of the new features of C++... even if I don't do C++, I can often reframe > what the feature means in the overall scheme of programming languages. > On other hand I have close to zero experience on compilers . > I find it very interesting. I consider that current compilers are very > good optimising code that is written in a language that obscures the > developper intent in the first place. > I lost you there, you mean compilers for other languages than C++ ? As I told you, I work in a world where performance is paramount and C++ is > strongly criticized for the fact its incidental complexity makes it very > very hard to reach or maintain performance levels (compared to Fortran, > say). > > Thierry > > And I "work" in a world that C++ is the undisputed king , that's 3d graphics , though I must admit I try to stick with Python as much as I can. In any case my point was that if namespaces can be done in a badly design language , should be possible in Pharo and easier. Not ease, just easier. Of course that's just a wild assumption but I hope this thread do not only disaprove my assumption but said a light in the real challanges of namespace implementation

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Dimitris Chloupis

"Let's start with the misconception that namespaces are about modularisation Stephan " Well I can only for speak for Python because is where I used namespaces the most and the language I am most experienced with. Namespaces in python are merely objects that come with a collection of method speciallised in the handling of source code files , individuals and in collection with all the objects contained in them , cause everything in python apart from the core synstax are object. Last time I checked, objects even in Pharo are abour modularistation so it stands to reason that at least in Python namespaces are too. Maybe your refer to something else ?

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Norbert Hartl

> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: > > On 13-10-17 09:55, Thierry Goubier wrote: >> Because namespaces, by essence, come with serious issues. I won't take >> someone seriously on namespaces until he can cite those faithfully. > > Let's start with the misconception that namespaces are about modularisation > +1 Norbert

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Thierry Goubier

2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > fair enough you think namespaces are not the right solution, what you > think is the right solution then ? > I told you. Namespaces are a solution, but they come with issues. > > As much I hate C++ , no I will have to disagree with your there, bad > language design sure, but many of the "bad design" choices they make are > based on the fact that this is a pure performance orientated language. Oh > and we still wait for the real C++ alternative. Rust people claim they are > close, D people claim they are close, everyone claims its very close, but > still no alternative. Well I dont count C becaue its not OO, even if you > claim C++ an abomination of OOP. I can guarantee that the dude that will > come up with a language as fast as C++ and much better design he is going > to make a fortune. In the mean time , those that have to use C++ will > continue to use C++ and wait for the extemely remote competition to catch > up. In the mean time C++ is the undisputed king in its speciality. > No. In the HPC world, a common held position is that Fortran code is 30% faster than C++. Remember that part of my job is to write compilers. I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages. > > Unfortunately coming up with a top performance language is a lot more than > language design, live coding and OOP. Took ages for C and C++ to get to the > level of optimisation they are nowdays. That's no easy feat even if you or > I dont find interesting. > I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place. > > So yes the modules that C++ will come up with, will be as ugly as hell, > templates that suppose to be there as an alternative to dynamic typing etc > are ugly as hell, but I dont see much protest in getting them removed. And > there cases you cannot even use these "improvements" because ... well > performance issues. While other languages worry how many times slower they > are compared to C++, C++ worries about how much percentage of performance > it loses with each added feature. C++ exits in a diffirent universe than > the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one. > As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say). Thierry > > On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi Kilon, >> >> disclaimer: I've used Parcplace Smalltlk without namespaces, then >> VisualWorks with namespaces. >> >> 2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> Personally I dont get it, we find the path to bootstrap the pharo image >>> clear and we cannot see the path to namespaces ? >>> >> >> Because namespaces, by essence, come with serious issues. I won't take >> someone seriously on namespaces until he can cite those faithfully. >> >> >>> >>> it makes zero sense to me >>> >>> Plus what you say, countless and countless of implementation of >>> namespaces out there. And again what you say about perfection. >>> >>> If C++ can improve, If C++ can dream of namespaces planning the >>> introduction of modules(in future version) in replacement (not removal) of >>> his awful header file format.... I think we got the excuse to be confident >>> we can come up with something decent. >>> >> >> C++ is about adding incidental complexity to the development process, >> i.e. how to make something complex where it could be done in a simpler way. >> >> So I'd be very wary of any innovation coming from that direction. >> >> >>> >>> We develop a freaking IDE for crying out loud. >>> >>> No it wont be a walk in the park, no it wont get done in one or next >>> version, and no it cannot be an individual our outside effort. But we have >>> the community super qualified to do it. >>> >> >> And qualified enough maybe to also see it doesn't make that much of sense. >> >> Please remember that the design of a programming language consists not >> just in a laundry list of features, but also in making judicious choices of >> what to *omit* and, more importantly, in establishing design principles >> that are easy to understand [Steele, 2003] >> >> Thierry >> >> >>> On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris < >>>> sean(a)clipperadams.com> wrote: >>>> >>>>> horrido wrote >>>>> > Having separate namespaces would be really good. >>>>> > VisualWorks has them. Why not Pharo? >>>>> >>>>> I can't remember ever hearing disagreement on this subject. It seems >>>>> the >>>>> only questions have been: 1) how to do them *right*, >>>> >>>> >>>> The default position would be leveraging someone else's experience, so >>>> this begs the question, what is wrong in namespace implementations in VW, >>>> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, >>>> SmalltalkX, other languages) >>>> Are there been any research papers around comparing these? >>>> >>>> I found the "Pharo on Gemstone VM" talk impressive. The "develop on >>>> Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's >>>> commercial future. So a naive approach would be to do namespaces just like >>>> Gemstone. Maybe its not the best, but would it be "good enough" -- >>>> perfection being the enemy of done and all that jazz. >>>> >>>> cheers -ben >>>> >>>> >>>>> and 2) where they fall on the endless prioritized todo list >>>>> >>>>

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by stephan

On 13-10-17 09:55, Thierry Goubier wrote: > Because namespaces, by essence, come with serious issues. I won't take > someone seriously on namespaces until he can cite those faithfully. Let's start with the misconception that namespaces are about modularisation Stephan

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Dimitris Chloupis

fair enough you think namespaces are not the right solution, what you think is the right solution then ? As much I hate C++ , no I will have to disagree with your there, bad language design sure, but many of the "bad design" choices they make are based on the fact that this is a pure performance orientated language. Oh and we still wait for the real C++ alternative. Rust people claim they are close, D people claim they are close, everyone claims its very close, but still no alternative. Well I dont count C becaue its not OO, even if you claim C++ an abomination of OOP. I can guarantee that the dude that will come up with a language as fast as C++ and much better design he is going to make a fortune. In the mean time , those that have to use C++ will continue to use C++ and wait for the extemely remote competition to catch up. In the mean time C++ is the undisputed king in its speciality. Unfortunately coming up with a top performance language is a lot more than language design, live coding and OOP. Took ages for C and C++ to get to the level of optimisation they are nowdays. That's no easy feat even if you or I dont find interesting. So yes the modules that C++ will come up with, will be as ugly as hell, templates that suppose to be there as an alternative to dynamic typing etc are ugly as hell, but I dont see much protest in getting them removed. And there cases you cannot even use these "improvements" because ... well performance issues. While other languages worry how many times slower they are compared to C++, C++ worries about how much percentage of performance it loses with each added feature. C++ exits in a diffirent universe than the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one. On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Kilon, > > disclaimer: I've used Parcplace Smalltlk without namespaces, then > VisualWorks with namespaces. > > 2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> Personally I dont get it, we find the path to bootstrap the pharo image >> clear and we cannot see the path to namespaces ? >> > > Because namespaces, by essence, come with serious issues. I won't take > someone seriously on namespaces until he can cite those faithfully. > > >> >> it makes zero sense to me >> >> Plus what you say, countless and countless of implementation of >> namespaces out there. And again what you say about perfection. >> >> If C++ can improve, If C++ can dream of namespaces planning the >> introduction of modules(in future version) in replacement (not removal) of >> his awful header file format.... I think we got the excuse to be confident >> we can come up with something decent. >> > > C++ is about adding incidental complexity to the development process, i.e. > how to make something complex where it could be done in a simpler way. > > So I'd be very wary of any innovation coming from that direction. > > >> >> We develop a freaking IDE for crying out loud. >> >> No it wont be a walk in the park, no it wont get done in one or next >> version, and no it cannot be an individual our outside effort. But we have >> the community super qualified to do it. >> > > And qualified enough maybe to also see it doesn't make that much of sense. > > Please remember that the design of a programming language consists not > just in a laundry list of features, but also in making judicious choices of > what to *omit* and, more importantly, in establishing design principles > that are easy to understand [Steele, 2003] > > Thierry > > >> On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <btc(a)openinworld.com> wrote: >> >>> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <sean(a)clipperadams.com >>> > wrote: >>> >>>> horrido wrote >>>> > Having separate namespaces would be really good. >>>> > VisualWorks has them. Why not Pharo? >>>> >>>> I can't remember ever hearing disagreement on this subject. It seems the >>>> only questions have been: 1) how to do them *right*, >>> >>> >>> The default position would be leveraging someone else's experience, so >>> this begs the question, what is wrong in namespace implementations in VW, >>> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, >>> SmalltalkX, other languages) >>> Are there been any research papers around comparing these? >>> >>> I found the "Pharo on Gemstone VM" talk impressive. The "develop on >>> Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's >>> commercial future. So a naive approach would be to do namespaces just like >>> Gemstone. Maybe its not the best, but would it be "good enough" -- >>> perfection being the enemy of done and all that jazz. >>> >>> cheers -ben >>> >>> >>>> and 2) where they fall on the endless prioritized todo list >>>> >>>

Oct. 13, 2017

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

by Christophe Demarey

Hi Ben, > Le 13 oct. 2017 Ã 06:20, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > On Thu, Oct 12, 2017 at 3:43 PM, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > Hi Vitor, > >> Le 11 oct. 2017 Ã 13:44, Vitor Medina Cruz <vitormcruz(a)gmail.com <mailto:vitormcruz@gmail.com>> a Ã©crit : >> >> Hi Christophe, >> >> Yes, but: >> 1- I canât execute it if I donât have administrative rights >> > > ok. That the point I missed. > I think I will add a zip file with PharoLauncher for windows for user like you not having admin rights. > > Might this be a "portable" app, where downloaded images and VMs are stored next to the PharoLancher application, configured by a startup-setting file? > > > Alternatively... > searching around I found this... > https://stackoverflow.com/questions/18990418/nsis-require-admin-permission <https://stackoverflow.com/questions/18990418/nsis-require-admin-permission> > https://github.com/NSIS-Dev/Documentation/blob/master/Reference/RequestExec… <https://github.com/NSIS-Dev/Documentation/blob/master/Reference/RequestExec…> Good catch. probably by using RequestExecutionLevel = highest should solve the problem. > Also, when PharoLauncher is installed by an administrator and later used by a standard user, I guess there may be problems with Pharo needing to write changes to a restricted location?? Maybe that can be dealt with by... when a new user runs PharoLauncher from the start menu, copy it to their user folder $LocalAppdata\Programs\PharoLauncher > and run PharoLauncher from there where they have privilege to write? > https://stackoverflow.com/questions/31641818/install-application-files-to-s… <https://stackoverflow.com/questions/31641818/install-application-files-to-s…> Yes, you could have problems but I do not think that adding more complexity to the installer is the way to go. I would rather prefer, in preference order: 1/ Pharo Launcher do not need to write data, 2/ if files need to be written, they should go to a Pharo data folder (e.g. $LocalAppdata\Programs\PharoLauncher) or to the user apps setting folder. What I would like is that a Pharo image writes data where it should > > btw, where are the NSIS source files accessible? https://github.com/pharo-project/pharo-build-scripts/tree/master/windows-in… > Can they be dropped in the PharoLauncher git repo? No because they are shared and used with other Pharo build scripts. Thanks for the information. Cheers, Christophe

Oct. 13, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Thierry Goubier

Hi Kilon, disclaimer: I've used Parcplace Smalltlk without namespaces, then VisualWorks with namespaces. 2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > Personally I dont get it, we find the path to bootstrap the pharo image > clear and we cannot see the path to namespaces ? > Because namespaces, by essence, come with serious issues. I won't take someone seriously on namespaces until he can cite those faithfully. > > it makes zero sense to me > > Plus what you say, countless and countless of implementation of namespaces > out there. And again what you say about perfection. > > If C++ can improve, If C++ can dream of namespaces planning the > introduction of modules(in future version) in replacement (not removal) of > his awful header file format.... I think we got the excuse to be confident > we can come up with something decent. > C++ is about adding incidental complexity to the development process, i.e. how to make something complex where it could be done in a simpler way. So I'd be very wary of any innovation coming from that direction. > > We develop a freaking IDE for crying out loud. > > No it wont be a walk in the park, no it wont get done in one or next > version, and no it cannot be an individual our outside effort. But we have > the community super qualified to do it. > And qualified enough maybe to also see it doesn't make that much of sense. Please remember that the design of a programming language consists not just in a laundry list of features, but also in making judicious choices of what to *omit* and, more importantly, in establishing design principles that are easy to understand [Steele, 2003] Thierry > On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <btc(a)openinworld.com> wrote: > >> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> >>> horrido wrote >>> > Having separate namespaces would be really good. >>> > VisualWorks has them. Why not Pharo? >>> >>> I can't remember ever hearing disagreement on this subject. It seems the >>> only questions have been: 1) how to do them *right*, >> >> >> The default position would be leveraging someone else's experience, so >> this begs the question, what is wrong in namespace implementations in VW, >> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, >> SmalltalkX, other languages) >> Are there been any research papers around comparing these? >> >> I found the "Pharo on Gemstone VM" talk impressive. The "develop on >> Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's >> commercial future. So a naive approach would be to do namespaces just like >> Gemstone. Maybe its not the best, but would it be "good enough" -- >> perfection being the enemy of done and all that jazz. >> >> cheers -ben >> >> >>> and 2) where they fall on the endless prioritized todo list >>> >>

Oct. 13, 2017