May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Personal Programming onPharo

by Norbert Hartl

> Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no>: > > Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. > Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed. > If we talk about C/C++ the runtime is the operating system. Everytime I update it the linked libraries are suspect to be invalid from then. If you have in the same system update a new version of the C compiler you are doomed. You cannot link your binary with the new libs. And the new C compiler quirks about your code. So what you have then? Staying on an old C language standard? Statically link everything. Ah no that wonât work because you would have to care about all your dependencies being compilable with the new compiler. But you donât update the compiler meaning you donât update the operating system. It is the same as staying on pharo 3. For Java the situation is slightly different because if you use new programming language features you can only do when switching the compiler to the new standard. There is a lot of effort that went into making the java vm recognize the language version and execute regarding that making version compatible. We are in sync here. I told you it is about manpower. Do you know how much manpower it needed and how long it took to add something like closures to the java language? Do you consider java closure to be en par with other languages? We are sorry not everything is to your liking. It is not even to our own liking because we have dreams far beyond. But we will never get there if we donât take the effort. And the point of open source (did I mention pharo is open source?? ) is that the ones that do it decide what to do. Nuff said! Norbert > On 07.05.2018 11:57, Norbert Hartl wrote: >> I understand what you are saying but it contains some misconceptions about the modern software world. >> >> âThe earth is not stopping to turn just because you want to stay on the sunny sideâ >> >> There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ â¦ there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster. >> >> Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you â¦ nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change. >> >> So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story: >> >> You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it >> >> How does this sound? >> >> Norbert >> >>> Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>: >>> >>> Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? >>> Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand." >>> I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand. >>> >>> pharo.org <http://pharo.org/> writes: "Pharo is a pure object-oriented programming language...". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language. >>> >>> A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again. >>> >>> Cheers >>> --Trygve >>> >>> >>> >>> On 06.05.2018 13:00, Norbert Hartl wrote: >>>> Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate. >>>> >>>> Norbert >>>> >>>> Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>: >>>> >>>>> I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? >>>>> --Thanks, Trygve >>>>> >>>>> On 05.05.2018 13:53, Stephan Eggermont wrote: >>>>>> Iâve taken a look at what would be needed to >>>>>> support magma on pharo a few years ago. Chris always told us he uses it >>>>>> professionally on squeak and has not enough capacity to keep up with >>>>>> changes in pharo without having a customer/maintainer for it. Twice a year >>>>>> or so someone asks about magma on pharo and takes a look. AFAIK there are >>>>>> no real obstacles to a port, but magma uses a lot of deep implementation >>>>>> specifics that will take an experienced smalltalker to deal with, and a lot >>>>>> of mailing list archeology as pharo changed a lot since magma worked on >>>>>> pharo last >>>>>> >>>>>> Stephan >>>>> >>>>> -- >>>>> The essence of object orientation is that objects collaborate to achieve a goal. >>>>> Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> >>>>> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> >>>>> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >>>>> Norway Tel: (+47) 22 49 57 27 >>> >>> -- >>> The essence of object orientation is that objects collaborate to achieve a goal. >>> Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> >>> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> >>> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >>> Norway Tel: (+47) 22 49 57 27 >> > > -- > The essence of object orientation is that objects collaborate to achieve a goal. > Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> > N-0378 Oslo http://fullOO.info <http://fulloo.info/> > Norway Tel: (+47) 22 49 57 27

May 7, 2018

Re: [Pharo-users] Package extension. Adding instance variables to classes

by Pavel Krivanek

2018-05-07 12:25 GMT+02:00 Alidra Abdelghani via Pharo-users < pharo-users(a)lists.pharo.org>: > > > ---------- PÅeposlanÃ¡ zprÃ¡va ---------- > From: Alidra Abdelghani <alidrandco(a)yahoo.fr> > To: pharo-users(a)lists.pharo.org > Cc: > Bcc: > Date: Mon, 7 May 2018 11:25:49 +0100 > Subject: Package extension. Adding instance variables to classes > Hi, > > I am working on a package named ClassNamesAnalyzer and I need to add code > to third party classes in other packages (for instance the FAMIX-Core > package). > âExtendingâ third party classes with methods is easy; I just need to > categorise my methods under the *ClassNamesAnalyzer protocole so that > loading my package will load them in the image. > However, if I want to add instance variables to theses classes, they are > not there when I load the package in a new image. > > *So my question is* : is there a way to include instance variables > addition to other packages in my package? > Currently not, you should use privateState > *Another question is* : is it good practice to add instance variables to > classes in third party packages and is there a way to avoid it (because I > am not very confortable with that idea)? > It is not, see FAMIXContainerEntity>>#definedAnnotationTypes how this issue is currently being solved using the privateState. Cheers, -- Pavel > > Thanks in advance, > Abdelghani > >

May 7, 2018

Re: [Pharo-users] Personal Programming onPharo

by Trygve Reenskaug

Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed. On 07.05.2018 11:57, Norbert Hartl wrote: > I understand what you are saying but it contains some misconceptions > about the modern software world. > > âThe earth is not stopping to turn just because you want to stay on > the sunny sideâ > > There is two funny concepts going on in the modern software industry. > The one tells you that because you want to do a product everything > else around you should come to a full stop so can comfortably build > your software not disturbed by other things. The second one tells you > that you _have to upgrade_ â¦ there is this magical force preventing > you from staying where you are. Both notions are funny alone but they > come combined and then they turn out to be a non-sensical monster. > > Letâs take a different approach. Put in everything you say about > software, libraries, etc the word version. So you can build upon Pharo > version 3 your own product. You can stay at that version and it wonât > change. If the software you sell is not 80% pharo but your own you > should not have a problem just to stay on that version because you > develop your own stuff. But still the world did not stop turning and > there is pharo 4. You decide there are a few nice features but the > work to adjust is too big to take the risk. Then there is pharo 5 and > you â¦ nahhh not this timeâ¦.Then there is pharo6 and they not only > changed the image but also the way source code is managed. That > prevents you further from adjusting. But hey you can still be happy > with pharo3 and it does not change. > > So what is the real problem? Yes, money/time is not enough. I think > there are a lot of people risking their health to promote pharo and > now we have a consortium that can pay engineers to do work on pharo. > So let me tell you a future story: > > You see what pharo is doing and you think it is good. You can also see > that there are too less resources to proceed in the way you need it to > go. So you decide to show pharo to the world inspiring people with > some kind of a vision. The result is that more people pay into the > consortium and we hire more engineers. And then one day the consortium > has enough money to pay engineers that can care about a LTS (long term > support) version of pharo. So you can stay on pharo version 3 and > still get those annoying bugs fixed. And hey this team has also enough > time to provide you with tools that make a migration to pharo version > 4 more easy and less annoying for you. And then you have your own > product based on pharo version 4. And then for version 5, version 6,â¦. > Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on > how the people approach it > > How does this sound? > > Norbert > >> Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no >> <mailto:trygver@ifi.uio.no>>: >> >> Thanks for your quick answer.Â I have only a fleeting knowledge of >> Pharo but liked what I saw. The Squeak class library has seen organic >> growth since 1978 or earlier. Pharo gave it a thorough overhaul. At >> the Pharo kernel was a minimal image with a minimal class library. >> The rest of the functionality was partitioned into packages that >> could be added to the kernel image as required. Beautiful. But only >> my dream? >> >> /Matthew 7:24-27: And the rain fell, and the floods came, and the >> winds blew and beat on thatÂ house, but it did not fall, because >> it had been founded on the rock. AndÂ everyone who hears these >> words of mine and does not do them will be like a foolish man who >> built his house on the sand."/ >> >> I am developing an IDE for non-programmersÂ called BabyIDE, a >> non-intrusive extension of Squeak. Where the Class Browser in Squeak >> is used to work with one class at the time, the BabyIDE browser is >> used to work with structures of collaborating objects, ignoring their >> classes. I would like to develop a BabyIDE image that gets broad >> usage and long life. I'm looking for a rock to build on and hoped it >> could be what I thought was the Pharo kernel+ a few selected >> packages. In your answer, I read that if I build BabyIDE on Pharo, I >> will be building on sand. >> >> pharo.org <http://pharo.org/>writes: "/Pharo is a pure >> object-oriented programming language.../". The only language I can >> see is defined by the release image. A Pharo programmer builds >> application programs in this language. He or she can add new classes, >> change existing ones, subclass them, add or change methods, change >> the Smalltalk dictionary, etc. etc.Â An extremely flexible and >> powerful language. >> >> A tale from the future when Pharo is a mainstream language:Business >> customers benefit from end users using applications that are written >> by Pharo programmers who built on the Pharo language and environment >> that had been developed by the Pharo community. One day there is a >> happy announcement: A new version of Pharo will be launched tomorrow. >> It is truly cool and includes any number of improvements, some of >> them documented. And, by the way, applications written in the current >> Pharo will no longer work. So please inform your customers that you >> will not be able to serve them for a while. We are confident that all >> your application programmers will be happy to drop whatever they are >> doing in order to adapt their applications to the new Pharo so that >> you can start serving your customers again. >> >> Cheers >> --Trygve >> >> >> >> On 06.05.2018 13:00, Norbert Hartl wrote: >>> Can you elaborate on what you consider as a kernel? There are always >>> things moving in the pharo world. The last years the virtual machine >>> got some iterations and it is still not fully stable. For pharo it >>> is hard to have it stable because we feel the need that a lot of the >>> existing parts need to be replaced to be useful in these times. >>> Furthermore pharo is also prototyping platform for programming >>> language features. All of these are counter-stability measures. So >>> if you need a stable kernel from native ground up to UI pharo wonât >>> be that thing you are looking for the coming years (if at all). You >>> always need to adopt to change so you need to define your required >>> scope better in order to get an estimate. >>> >>> Norbert >>> >>> Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no >>> <mailto:trygver@ifi.uio.no>>: >>> >>>> I'm working on a programing paradigm and IDE for the personal >>>> programmer who wants to control his or her IoT. The size of the >>>> target audience I have in mind is >100 million. I gave up Squeak >>>> long ago as a platform because they obsolete my code faster than I >>>> can write it.Â I have now frozen Squeak 3.10.2 and hope its runtime >>>> will survive until I find a better foundation. My hope is that >>>> Pharo has a stable kernel that I can build on. According to >>>> Stephan, this is not so. Is there any plan for creating a stable >>>> Pharo kernel that people can use for building software of lasting >>>> value for millions of non-expert users? >>>> --Thanks, Trygve >>>> >>>> On 05.05.2018 13:53, Stephan Eggermont wrote: >>>>> Iâve taken a look at what would be needed to >>>>> support magma on pharo a few years ago. Chris always told us he uses it >>>>> professionally on squeak and/*has not enough capacity to keep up with changes in pharo without >>>>> having a customer/maintainer for it.*/ Twice a year >>>>> or so someone asks about magma on pharo and takes a look. AFAIK there are >>>>> no real obstacles to a port, but magma uses a lot of deep implementation >>>>> specifics that will take an experienced smalltalker to deal with, and a lot >>>>> of mailing list archeology as pharo changed a lot since magma worked on >>>>> pharo last >>>>> >>>>> Stephan >>>> >>>> -- >>>> /The essence of object orientation is that >>>> objectscollaboratetoachieve a goal./ >>>> TrygveReenskaug mailto: trygver(a)ifi.uio.no >>>> <mailto:%20trygver@ifi.uio.no> >>>> Morgedalsvn. 5A http://folk.uio.no/trygver/ >>>> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >>>> NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 22 49 57 27 >> >> -- >> /The essence of object orientation is that >> objectscollaboratetoachieve a goal./ >> TrygveReenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >> NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 22 49 57 27 > -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 22 49 57 27

May 7, 2018

Package extension. Adding instance variables to classes

by Alidra Abdelghani

Hi, I am working on a package named ClassNamesAnalyzer and I need to add code to third party classes in other packages (for instance the FAMIX-Core package). âExtendingâ third party classes with methods is easy; I just need to categorise my methods under the *ClassNamesAnalyzer protocole so that loading my package will load them in the image. However, if I want to add instance variables to theses classes, they are not there when I load the package in a new image. So my question is : is there a way to include instance variables addition to other packages in my package? Another question is : is it good practice to add instance variables to classes in third party packages and is there a way to avoid it (because I am not very confortable with that idea)? Thanks in advance, Abdelghani

May 7, 2018

Re: [Pharo-users] Personal Programming onPharo

by Norbert Hartl

I understand what you are saying but it contains some misconceptions about the modern software world. âThe earth is not stopping to turn just because you want to stay on the sunny sideâ There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ â¦ there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster. Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you â¦ nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change. So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story: You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it How does this sound? Norbert > Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no>: > > Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? > Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand." > I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand. > > pharo.org <http://pharo.org/> writes: "Pharo is a pure object-oriented programming language...". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language. > > A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again. > > Cheers > --Trygve > > > > On 06.05.2018 13:00, Norbert Hartl wrote: >> Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate. >> >> Norbert >> >> Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>: >> >>> I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? >>> --Thanks, Trygve >>> >>> On 05.05.2018 13:53, Stephan Eggermont wrote: >>>> Iâve taken a look at what would be needed to >>>> support magma on pharo a few years ago. Chris always told us he uses it >>>> professionally on squeak and has not enough capacity to keep up with >>>> changes in pharo without having a customer/maintainer for it. Twice a year >>>> or so someone asks about magma on pharo and takes a look. AFAIK there are >>>> no real obstacles to a port, but magma uses a lot of deep implementation >>>> specifics that will take an experienced smalltalker to deal with, and a lot >>>> of mailing list archeology as pharo changed a lot since magma worked on >>>> pharo last >>>> >>>> Stephan >>> >>> -- >>> The essence of object orientation is that objects collaborate to achieve a goal. >>> Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> >>> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> >>> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >>> Norway Tel: (+47) 22 49 57 27 > > -- > The essence of object orientation is that objects collaborate to achieve a goal. > Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> > N-0378 Oslo http://fullOO.info <http://fulloo.info/> > Norway Tel: (+47) 22 49 57 27

May 7, 2018

Re: [Pharo-users] Personal Programming onPharo

by Trygve Reenskaug

Thanks for your quick answer.Â I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? /Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. AndÂ everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/ I am developing an IDE for non-programmersÂ called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand. pharo.org writes: "/Pharo is a pure object-oriented programming language.../".Â The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc.Â An extremely flexible and powerful language. A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again. Cheers --Trygve On 06.05.2018 13:00, Norbert Hartl wrote: > Can you elaborate on what you consider as a kernel? There are always > things moving in the pharo world. The last years the virtual machine > got some iterations and it is still not fully stable. For pharo it is > hard to have it stable because we feel the need that a lot of the > existing parts need to be replaced to be useful in these times. > Furthermore pharo is also prototyping platform for programming > language features. All of these are counter-stability measures. So if > you need a stable kernel from native ground up to UI pharo wonât be > that thing you are looking for the coming years (if at all). You > always need to adopt to change so you need to define your required > scope better in order to get an estimate. > > Norbert > > Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no > <mailto:trygver@ifi.uio.no>>: > >> I'm working on a programing paradigm and IDE for the personal >> programmer who wants to control his or her IoT. The size of the >> target audience I have in mind is >100 million. I gave up Squeak long >> ago as a platform because they obsolete my code faster than I can >> write it.Â I have now frozen Squeak 3.10.2 and hope its runtime will >> survive until I find a better foundation. My hope is that Pharo has a >> stable kernel that I can build on.Â According to Stephan, this is not >> so. Is there any plan for creating a stable Pharo kernel that people >> can use for building software of lasting value for millions of >> non-expert users? >> --Thanks, Trygve >> >> On 05.05.2018 13:53, Stephan Eggermont wrote: >>> Iâve taken a look at what would be needed to >>> support magma on pharo a few years ago. Chris always told us he uses it >>> professionally on squeak and/*has not enough capacity to keep up with changes in pharo without >>> having a customer/maintainer for it.*/ Twice a year >>> or so someone asks about magma on pharo and takes a look. AFAIK there are >>> no real obstacles to a port, but magma uses a lot of deep implementation >>> specifics that will take an experienced smalltalker to deal with, and a lot >>> of mailing list archeology as pharo changed a lot since magma worked on >>> pharo last >>> >>> Stephan >> >> -- >> >> /The essence of object orientation is that objects collaborateto >> achieve a goal. / >> Trygve Reenskaug mailto: trygver(a)ifi.uio.no >> <mailto:%20trygver@ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 22 49 57 27 >> -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 22 49 57 27

May 7, 2018

Re: [Pharo-users] reading from a named pipe in Pharo

by Siemen Baader

Wow, thanks for your help, Alistair! I'll try it out. cheers, Siemen On Sun, May 6, 2018 at 7:47 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Siemen & Mariano, > > On 5 May 2018 at 16:26, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi Siemen, > > > > You may want to check the pipe support code in OSSubprocess [1]. Note > that > > the pipes should work outside of OSSubprocess. You can read the > > documentation as well as the unit tests for the pipes. > > > > Cheers, > > > > [1] https://github.com/marianopeck/OSSubprocess > > OSSPipe seems to assume that is controlling both ends of the pipe, > while it may be that Siemen just wants to read from the pipe. Anyway, > Mariano mentioned that pipes should work outside of OSSubprocess, and > I've made some modifications to FilePlugin which should facilitate > that, so thought I'd have a go. This still doesn't completely meet > Siemen's requirements as it polls the stream, but... I've attached a > little demo class, tested only on Ubuntu 16.04. Be warned, I've never > used Unix pipes before, so feel free to critique the code: > > > NamedPipeEcho provides sample code showing how to read from a Unix > named pipe and echo the contents to stdout. > > Interesting attributes of the sample code include: > > - It is just a sample, it isn't intended to be production ready. > - It marks the pipe non-blocking so that multiple pipes can be > processed without the image blocking when reading. > - It's polling, rather than event driven. > - It doesn't have any external dependencies outside the core Pharo > image and standard Pharo VM. > - It defines a method that directly calls a primitive - I consider > this bad practice and would like to make the primitive generally > available through FilePlugin. > > > The simplest way to run this is in one terminal (bash shell): > > $ mkfifo /dev/shm/pharopipe > $ pharo --headless Pharo.image eval "(NamedPipeEcho on: > '/dev/shm/pharopipe') run" > > and in a second terminal (bash shell): > > $ pharo --headless Pharo.image eval "NamedPipeEcho sampleWriteTo: > '/dev/shm/pharopipe'" > > You should see: > > Hello World > Line 2 > > in the first terminal, with a 15 second delay between the lines and exit. > > > There's also AsyncFile, which should make it event driven instead of > polled, but I haven't had a chance to look at that yet. > > This is tested with: > > > Pharo7.0alpha > Build information: > Pharo-7.0+alpha.build.839.sha.675decd24230e0ef7d1579af07c2112c104c6d7b > (64 Bit) > > > 5.0-201804122226 Thu Apr 12 22:34:48 UTC 2018 gcc 4.8 [Production > Spur 64-bit VM] > CoInterpreter VMMaker.oscog-eem.2361 uuid: > 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: > 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018 > VM: 201804122226 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Apr 12 15:26:17 2018 -0700 $ CommitHash: 07c6dc3 $ > Plugins: 201804122226 https://github.com/OpenSmalltalk/opensmalltalk- > vm.git $ > Linux travis-job-b95e67e4-9fb2-4d69-a59f-1fbf859b912c > 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > plugin path: /home/alistair/pharo7/Issue21692/vm/pharo-vm/lib/ > pharo/5.0-201804122226 > [default: /home/alistair/pharo7/Issue21692/vm/pharo-vm/lib/ > pharo/5.0-201804122226/] > > > Earlier VMs probably won't work as #atEnd will always return true or > false (I forget which). > > Cheers, > Alistair >

May 7, 2018

<Programming> 2019: Call for Papers & Call for Workshop Proposals

by Fabio Niephaus

<Programming> 2019 : The Art, Science, and Engineering of Programming April 1-4, 2019, Genova, Italy http://2019.programming-conference.org The International Conference on the Art, Science, and Engineering of Programming is a new conference focused on programming topics including the experience of programming. We have named it <Programming> for short. <Programming> seeks for papers that advance knowledge of programming on any relevant topic, including programming practice and experience. Paper submissions and publications are handled by the the Art, Science, and Engineering of Programming journal (http://programming-journal.org) Accepted papers must be presented at the conference. ******************************************************** CALL FOR PAPERS ******************************************************** <Programming> 2019 accepts scholarly papers that advance knowledge of programming. Almost anything about programming is in scope, but in each case there should be a clear relevance to the act and experience of programming. PAPER SUBMISSIONS: June 1, 2018 URL FOR SUBMISSIONS: http://programming-journal.org/submission/ Submissions covering several areas of expertise are accepted, including but not limited to: â¢ General-purpose programming â¢ Distributed systems programming â¢ Parallel and multi-core programming â¢ Graphics and GPU programming â¢ Security programming â¢ User interface programming â¢ Database programming â¢ Visual and live programming â¢ Data mining and machine learning programming â¢ Interpreters, virtual machines and compilers â¢ Modularity and separation of concerns â¢ Model-based development â¢ Metaprogramming and reflection â¢ Testing and debugging â¢ Program verification â¢ Programming education â¢ Programming environments â¢ Social coding ******************************************************** CALL FOR WORKSHOP PROPOSALS ******************************************************** To build a community and to foster an environment where participants can exchange ideas and experiences related to practical software development, <Programming> will host a number of workshops, during the days before the main conference. The workshops will provide a collaborative forum to exchange recent and/or preliminary results, to conduct intensive discussions on a particular topic, or to coordinate efforts between representatives of a technical community. They are intended as a forum for lively discussion of innovative ideas, recent progress, or practical experience on programming and applied software development in general for specific aspects, specific problems, or domain-specific needs. We also encourage practical, hands-on workshops in which participants actually experience one or several aspects of practical software development. WORKSHOP PROPOSAL SUBMISSIONS: First Deadline: July 1st, 2018 Second Deadline: September 1st, 2018 The duration of workshops is in general one day, but we encourage the submission of half-day workshop proposals on focused topics as well. In exceptional situations, e.g., for workshops that involve actual practice of programming-related activities, workshop organizers can request a 2 day workshop slot. If desired, the workshop proceedings can be published in the ACM Digital Library. ******************************************************** IMPORTANT DATES ******************************************************** Research paper submissions: June 1, 2019 Research paper first notifications: August 1, 2018 Research paper final notifications: September 7, 2018 Workshop proposals: July 1st, 2018 (first deadline) Workshop proposals: September 1st, 2018 (second deadline) ******************************************************** ORGANIZATION ******************************************************** General Chair: Davide Ancona, University of Genova Local Organizing Chair: Elena Zucca, University of Genova Program Chair: Matthew Flatt, University of Utah Organizing Committee: Walter Cazzola (Workshops Co-Chair), UniversitÃ degli Studi di Milano Stefan Marr (Workshops Co-Chair), University of Kent Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University of Potsdam Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of Potsdam Program Committee: Mehdi Bagherzadeh, Oakland University Walter Cazzola, UniversitÃ degli Studi di Milano Ravi Chugh, University of Chicago Joeri De Koster, Vrije Universiteit Brussel Christos Dimoulas, Northwestern University Susan Eisenbach, Imperial College London Richard P. Gabriel, Dream Songs, Inc. & HPI Jeremy Gibbons, University of Oxford Michael Greenberg, Pomona College Philipp Haller, KTH Royal Institute of Technology Robert Hirschfeld, HPI, University of Potsdam Eunsuk Kang, Carnegie Mellon University Stephen Kell, University of Cambridge Stefan Marr, University of Kent Tamara Rezk, Inria Joshua Sunshine, Carnegie Mellon University Steffen Zschaler, King's College London ******************************************************** <Programming> 2019 is kindly supported by AOSA ******************************************************** For more information, visit http://2019.programming-conference.org

May 7, 2018

Re: [Pharo-users] Commit request on PBKDF2

by Udo Schneider

Hi MartÃn, sure - go ahead and change/fix it. JFYI - one of the last things on my todo list was to move PBKDF2 to github. If somebody volunteers I'm happy to pass on any maintainer related "things". :-) I won't have the time to do anything serious in Smalltalk for the foreseeable future anyways :-( CU, Udo On 06.05.18 01:46, Martin Dias wrote: > Hello Udo and PBKDF2 users, > > Thanks for the PBKDF2 [1] project; it's been useful in the mongotalk > project [2]. Now, I write you with a small change proposal due to some > problems I have because of name conflicts with classes at Cryptography > package [3] (which ConfigurationOfPBKDF2 declares as a dependency). > > I analyzed what are the concrete dependencies in PBKDF2 to Cryptography: > > - Core uses SHA1, which is in Pharo at least since Pharo 4.0 > - Tests use the ByteArray>>fromHexString: method extension, which > could be copied. > > (BTW also thanks to Christophe Demarey and collaborators for the > Dependencies Analyzer, it's very useful!) > > Then (unless I'm missing something), PBKDF2 doesn't really need > Cryptography as dependency. I can commit the changes if you agree (I > see the repository is public). It works locally. > > Regards, > MartÃn > > [1] http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2 > [2] https://github.com/pharo-nosql/mongotalk > [3] http://smalltalkhub.com/#!/~Cryptography/Cryptography/ > >

May 7, 2018

Re: [Pharo-users] Histogram for files dates and sizes

by Alexandre Bergel

Hi Offray, You can add ticks as follows: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= c := (1 to: 100) collect: [ :i | 50 atRandom @ 50 atRandom ]. g := RTGrapher new. d := RTData new. d points: c. d x: #x. d y: #y. g add: d. g axisX noTick. g axisY noTick. g addDecorator: (RTVerticalValuesDecorator new addAll: #(10 25)). g addDecorator: (RTHorizontalValuesDecorator new addAll: #(10 25)). g -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= For the legend, there is actually no such a support. However, it should be easy to add a new rule, as a subclass of RTLegendItem Cheers, Alexandre > On May 6, 2018, at 9:13 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > Here is the improved version: > > <iiboahmkfajnlmam.png> > > As you can see, now I coded colored years functionality (I thought that colored histograms, following a criteria, would be supported by default, but I was unable to find any documentation or example about it). Two questions remain: > > â¢ How can I add ticks in the X axis, so they correspond to a particular criteria? For example, a change in the year? > â¢ There is any way to make the RTLegend puts the color labels in a "matrix alike" fashion? So, for example, I would like to say that instead of having the default 1xn column of color labels, as now, I want them organized over a nxm matrix, so they suit better different graphical objects and layouts. > Thanks, > > Offray > > On 26/04/18 14:31, Offray Vladimir Luna CÃ¡rdenas wrote: >> Hi, >> >> I'm making a histogram of files that have the naming convention YYYY_MM.js, for year and month info. The image below shows what I get until now: >> >> <pgoajgjcjaoiebgb.png> >> >> By the way, you can run this example by loading and updating the Dataviz package [2] from [3] >> >> [2] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Packages/Dataviz/readme… >> [3] http://ws.stfx.eu/OUEYE943HV3Q >> I would like to have bars for every year of a file name in a different color (I imagine that using #distinctColorUsing: ) and ticks on each year. I'm seeing some examples in the image and in http://agilevisualization.com/AgileVisualization/Roassal/0104-Roassal.html, but I wonder if there is a more mature and already existing RTObject for this kind of work. Also I would like to show Y axis scale using size of files in a human friendly format (160 Kb instead of 160000.0 and so on). >> >> Any help or pointers on this is greatly appreciated. >> >> Cheers, >> >> Offray >> >

May 6, 2018