- Pharo-users - lists.pharo.org

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

by Cyril Ferlicot

On ven. 13 oct. 2017 at 12:05, Gour <gour(a)atmarama.com> wrote: > On Wed, 11 Oct 2017 17:18:54 +0000 > Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > Well there is a move towards Pillar for class and method commands so > > who knows maybe we will have that soon enough ;) > > Let me say that I'm very happy seeing that Pillar is moving forward (e.g. > addition of support for footnotes) as well as plan for the future (*.epub > support) since I'm considering whether it could serve as single-source > markup > for all of one's writings? > > After migrating from Python-powered static-site-generator (to Hugo) and rst > markup I was considering to use AsciiDoc(tor) markup for all my content, > but, > so far, due to using Emacsm settled to use org-mode instead. Haven't tried > with > slides (yet), but there is Pandoc support for it. > > Therefore, I'd rather see Pillar support in Pandoc which would buy us even > more > import/export capabilities for free instead of focusing on single formats > like > *.odt, *.epub etc. > > Pillar with 1st class support in Pandoc would, imho, improve status of > Pharo > itself making it along with Pillar exceelent tool for development as well > as > for all writing needs - articles, books, documentation, > slide-presentations. > > But it would be nice to make it more transparent where/how can one submit > feature request for Pillar? Hi, I don't have much time so, fast answer: https://github.com/pillar-markup/pillar/issues > > Fogbugs issue trakcer is certainly not the ideal place these days... > > > Sincerely, > Gour > > -- > Everyone is forced to act helplessly according to the qualities > he has acquired from the modes of material nature; therefore no > one can refrain from doing something, not even for a moment. > > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 13, 2017

Pillar (was Re: Behold Pharo: The Modern Smalltalk)

by Gour

On Wed, 11 Oct 2017 17:18:54 +0000 Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Well there is a move towards Pillar for class and method commands so > who knows maybe we will have that soon enough ;) Let me say that I'm very happy seeing that Pillar is moving forward (e.g. addition of support for footnotes) as well as plan for the future (*.epub support) since I'm considering whether it could serve as single-source markup for all of one's writings? After migrating from Python-powered static-site-generator (to Hugo) and rst markup I was considering to use AsciiDoc(tor) markup for all my content, but, so far, due to using Emacsm settled to use org-mode instead. Haven't tried with slides (yet), but there is Pandoc support for it. Therefore, I'd rather see Pillar support in Pandoc which would buy us even more import/export capabilities for free instead of focusing on single formats like *.odt, *.epub etc. Pillar with 1st class support in Pandoc would, imho, improve status of Pharo itself making it along with Pillar exceelent tool for development as well as for all writing needs - articles, books, documentation, slide-presentations. But it would be nice to make it more transparent where/how can one submit feature request for Pillar? Fogbugs issue trakcer is certainly not the ideal place these days... Sincerely, Gour -- Everyone is forced to act helplessly according to the qualities he has acquired from the modes of material nature; therefore no one can refrain from doing something, not even for a moment.

Oct. 13, 2017

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