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

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

by Alidra Abdelghani

Ok, got it. Thanks Guille Abdelghani > On 10 May 2018, at 21:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Just be careful, that privateState thing looks like a Moose only Famix feature. It't not available in plain Pharo objects :) > > On Wed, May 9, 2018 at 2:09 AM, Alidra Abdelghani via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > > > ---------- Forwarded message ---------- > From: Alidra Abdelghani <alidrandco(a)yahoo.fr <mailto:alidrandco@yahoo.fr>> > To: Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Bcc: > Date: Wed, 9 May 2018 01:09:06 +0100 > Subject: Re: Package extension. Adding instance variables to classes > Hi Pavel, > > Thank you for your answer. > I actually didnât know about this mechanism. > I think it is will do the job :) > I have probably to rewrite some parts pf my code to access my variables through privateState. no? > > > Thanks again > Abdelghani >> On 07 May 2018, at 13:15, pharo-users-request(a)lists.pharo.org <mailto:pharo-users-request@lists.pharo.org> wrote: >> >> >> Message: 1 >> Date: Mon, 7 May 2018 13:43:56 +0200 >> From: Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> >> Subject: Re: [Pharo-users] Package extension. Adding instance >> variables to classes >> Message-ID: >> <CAHN2FzeMiBL4Y8asJ0XCjS2AQdxycoN+pbc+Hsd=trMnmuiJqw(a)mail.gmail.com <mailto:CAHN2FzeMiBL4Y8asJ0XCjS2AQdxycoN+pbc+Hsd=trMnmuiJqw@mail.gmail.com>> >> Content-Type: text/plain; charset="utf-8" >> >> 2018-05-07 12:25 GMT+02:00 Alidra Abdelghani via Pharo-users < >> pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>>: >> >>> >>> >>> ---------- P?eposlan? zpr?va ---------- >>> From: Alidra Abdelghani <alidrandco(a)yahoo.fr <mailto:alidrandco@yahoo.fr>> >>> To: pharo-users(a)lists.pharo.org <mailto:pharo-users@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 > > > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13 Dr. Abdelghani Alidra Enseignant-chercheur UniversitÃ© 20 aoÃ»t 1955 SKIKDA-ALGÃRIE Mob:+ 213 550 453 391

May 12, 2018

Re: [Pharo-users] Spec on Moose 6.0 error: MessageNotUnderstood: ToolDockingBarMorph>>popUpOwner

by Arturo Zambrano

Hi Offray I have the same problem(Pharo 6.1), it only happens while opening submenus. did you find a solution? thanks On Sat, Nov 21, 2015 at 2:49 PM, Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Hi, > > I'm getting this error while trying to prototype some interface with Spec > on Moose 6.0: > > MessageNotUnderstood: ToolDockingBarMorph>>popUpOwner > > it happens anytime that I'm using displaying a MenuModel and I go to the > menu items. I imagine that the menu item is complaining about a lacking pop > up message. How can I solve this? > > Thanks, > > Offray > >

May 11, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

I have been reading and learning about your Zinc HTTP framework, on the client side for now. It looks fantastic with all the needed pieces. I guess the server part has all the needed part of the teacher share counter part. Thanks Hilaire Le 07/05/2018 Ã 20:05, Sven Van Caekenberghe a Ã©critÂ : > Uploading can be done using an HTTP POST or PUT, just like Playground does its Remote Publish, or Monticello its Save operation. -- Dr. Geo http://drgeo.eu

May 11, 2018

Re: [Pharo-users] Personal Programming onPharo

by Travis Ayres

There is no way to mark the language version, no #pragma stdc version iso99 Delphi: {$IF CompilerVersion >= 17.0} Freepascal: {$if FPC_VERSION > 2} No make files: the compiler handles that trash for you. Compatibility: Freepascal supports Delphi, Object Pascal, and has various switches for all kinds of things should you need it. Supports Windows, Linux, Mac, Android, Amiga (...seriously) and a multitude of other systems. On Wed, May 9, 2018, 6:54 AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > âI have a C++ program written in the late 80s by someone > else. It used to run fine under cfront 2.0 and early g++. > Ten years after it was written it was impossible to compile. > > *Since* that there have been changes to streams and strings, > amongst other things. > > The 1989 C standard changed the semantics of mixed signed/unsigned > integer arithmetic. It also inadvertently rendered illegal a > widely used technique. It is notoriously the case these days > that compilers taking the C standards literally have "broken" > quite a lot of code that worked with less ambitious compilers. > I have been watching this phenomenon with considerable > nervousness. See for example > http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf > > I have certainly had previously acceptable C89 code be rejected > by compilers as not being legal C11. It is true that compilers > tend to have command line/IDE switches to ask that old code be > compiled under old rules, but you cannot say that *in* the program. > There is no way to mark the language version, no > #pragma stdc version iso99 > > > > As for Java, I could rant about the floods of deprecation warnings > from old code. I shall content myself with one observation. > Read http://java-performance.info/changes-to-string-java-1-7-0_06/ > Before Java 1.7, the substring operation in Java took O(1) time > and space. From Java 1.7 on, it takes time and space linear in the > size of the result. The syntax and abstract semantics did not > change but the pragmatics did. Code that had adequate performance > could suddenly start crawling. > > Oracle do a tolerably thorough job of describing compatibility > issues between JDK releases. See for example > > http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366… > where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge > was gone, 32-bit Solaris support (and yes, I was still using 32-bit > code in SPARC Solaris and Intel Solaris) was gone, and the type > inference algorithm had changed in a way that could break things. > I am still somewhat peeved about some of the rewriting I've had to > do over the last several releases. > > Then there is the simple fact that porting code from one release of > an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. > OpenSolaris to Solaris 11 was not as painless. Solaris 11 to > OpenIndiana was not a happy time for me. OpenBSD changes forced > rework. I'd finally got my program to port smoothly between Solaris, > Darwin, and Linux. And then I had trouble porting to the next major > release of Linux. And with Ubuntu 17, I've got another problem I > still haven't tracked down. All of this in a C program that gets > regularly (sp)linted and checked all sorts of ways, written with > the intention of producing portable code. > > EVERYTHING BREAKS. > > > On 7 May 2018 at 22:42, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > >> 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>: >> >> 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>: >> >> 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 <%20trygver(a)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 collaborate to achieve a goal. * >> Trygve Reenskaug mailto: trygver(a)ifi.uio.no <%20trygver(a)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 collaborate to >> achieve a goal. * >> Trygve Reenskaug mailto: trygver(a)ifi.uio.no <%20trygver(a)ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> Norway Tel: (+47) 22 49 57 27 >> > >

May 11, 2018

Re: [Pharo-users] Personal Programming onPharo

by David T. Lewis

Trygve, Thank you for pressing the SEND button with a shaking hand. I am inspired by your words. But I am only 22 years younger than you, and I hope that others are reading and appreciating what you have to say. Dave On Thu, May 10, 2018 at 12:02:44PM +0200, Trygve Reenskaug wrote: > At 87, I'm an old man. I'm told that I don't understand modern software, > which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ... > From time to time, I am told that a new version of the program that > fixes bugs and improves security is available. Press the button to > install it.?? So I wonder: Is modern software out of control? Does > /anybody /understand it, or is it so complicated that it is beyond human > comprehension? Why didn't they get it right the first time? Most of us > have the GOF book on Design Patterns on our bookshelf.?? In the > introduction, they write: > > /An object-oriented program's runtime structure often bears little > resemblance to its code structure. The code structure is frozen at > compile-time; it consists of classes in fixed inheritance > relationships. The runtime structure consists of rapidly changing > networks of communicating objects.[GOF-95] p. 22./ > > ??and > > /???, it's clear that code won't reveal everything about how a system > will work. [ibid.p.23]/ > > Modern programmers are thus reduced to relying on testing the code. In > the words of Edsger Dijstra: > > /"Program testing can be used to show the presence of bugs, but > never to show their absence!"[REF] / > > Modern programmers know all this but accept it as an unavoidable part of > progress. Some may have seen it as a challenge, but they are up against > the enormous inertia of a community who haven't changed their > fundamental model of programming since the advent of the von Neumann > stored program computer in 1948. > > I can't resist another quote; this time from Tony Hoare's TuringAward > lecture: > > /???There are two ways of constructing a software design: One way is > to make it so simple that there are obviously no deficiencies and > the other is to make it so complicated that there are no obvious > deficiencies. The first method is far more difficult. ???[Hoare-81]/ > > In the lecture, Hoare was bemoaning his unsuccessful fight for > simplicity. Developers, particularly committees?? of developers, seem to > love complexity for its own sake. I have never accepted that bugs are an > unavoidable part of software.(See "2.???? ??Get it Right the First Time"?? > in the draft article). Bugs are parts of the facts of life but they are > not an acceptable part of it. Ideally, my software should be /so simple > that there are obviously no deficiencies. /One of my attempts at coming > to grips with the problem is the DCI programming paradigm. Here, /the > runtime structure of rapidly changing networks of communicating objects/ > is specified in explicit code that says (almost) everything about what > happens at runtime. Wouldn't it be wonderful if Pharo were to become > first to overcome the GOF limitation? I challenge you to play with > BabyIDE on Squeak?? and become convinced that it is a step in the right > direction. > > I won't reread this message before I?? send it. I suppose it's > controversial and should probably delete some or all of it to avoid > angry answers. Another reason why I probably shouldn't send it is that I > do not have time to engage in a discussion. I /must /give priority to > finishing my article on DCI and PP. (A ~50 page draft is on my home > page; it will be updated from time to time) > > I press the SEND button with a shaking hand > --Trygve > > > > On 09.05.2018 15:53, Richard O'Keefe wrote: > >???I have a C++ program written in the late 80s by someone > >else.?? It used to run fine under cfront 2.0 and early g++. > >Ten years after it was written it was impossible to compile. > > > >*Since* that there have been changes to streams and strings, > >amongst other things. > > > >The 1989 C standard changed the semantics of mixed signed/unsigned > >integer arithmetic.?? It also inadvertently rendered illegal a > >widely used technique.?? It is notoriously the case these days > >that compilers taking the C standards literally have "broken" > >quite a lot of code that worked with less ambitious compilers. > >I have been watching this phenomenon with considerable > >nervousness.?? See for example > >http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf > ><http://www.eng.utah.edu/%7Ecs5785/slides-f10/Dangerous+Optimizations.pdf> > > > >I have certainly had previously acceptable C89 code be rejected > >by compilers as not being legal C11.?? It is true that compilers > >tend to have command line/IDE switches to ask that old code be > >compiled under old rules, but you cannot say that *in* the program. > >There is no way to mark the language version, no > >?????? #pragma stdc version iso99 > > > > > > > >As for Java, I could rant about the floods of deprecation warnings > >from old code.?? I shall content myself with one observation. > >Read http://java-performance.info/changes-to-string-java-1-7-0_06/ > >Before Java 1.7, the substring operation in Java took O(1) time > >and space.?? From Java 1.7 on, it takes time and space linear in the > >size of the result.?? The syntax and abstract semantics did not > >change but the pragmatics did.?? Code that had adequate performance > >could suddenly start crawling. > > > >Oracle do a tolerably thorough job of describing compatibility > >issues between JDK releases.?? See for example > >http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366… > >where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge > >was gone, 32-bit Solaris support (and yes, I was still using 32-bit > >code in SPARC Solaris and Intel Solaris) was gone, and the type > >inference algorithm had changed in a way that could break things. > >I am still somewhat peeved about some of the rewriting I've had to > >do over the last several releases. > > > >Then there is the simple fact that porting code from one release of > >an OS to another can be a pain.?? Solaris 10 to OpenSolaris was easy. > >OpenSolaris to Solaris 11 was not as painless.?? Solaris 11 to > >OpenIndiana was not a happy time for me.?? OpenBSD changes forced > >rework.?? I'd finally got my program to port smoothly between Solaris, > >Darwin, and Linux.?? And then I had trouble porting to the next major > >release of Linux.?? And with Ubuntu 17, I've got another problem I > >still haven't tracked down.?? All of this in a C program that gets > >regularly (sp)linted and checked all sorts of ways, written with > >the intention of producing portable code. > > > >EVERYTHING BREAKS. > > > > > >On 7 May 2018 at 22:42, Trygve Reenskaug <trygver(a)ifi.uio.no > ><mailto:trygver@ifi.uio.no>> wrote: > > > > 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/ > >>>>> <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/ > >>> <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/ > > <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 11, 2018

Re: [Pharo-users] Metacello load in code vs. Iceberg menu install? Can you automate remote loading?

by Tim Mackinnon

This was indeed the answer - use the gitlab protocol and specify a branch e.g. Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'PagerDuty'; repository: âgitlab:// <mailto:git@gitlab.com>macta/WillowPagerDuty:master/src'; load. Thanks Gaby Tim > On 10 May 2018, at 01:26, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I think you can use: > Metacello new > baseline: 'PagerDuty'; > repository: 'gitlab://macta/WillowPagerDuty:master/source'; > load. > > or something like that > > On Wed, May 9, 2018 at 8:44 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi - Iâm trying to automate the deployment of a seaside image to Digital Ocean. I was following the Enterprise Pharo booklet - and its a bit out of date, but I wanted to do the bit about taking a clean image and then loading in my project which Iâve stored in Git using Iceberg. > > So on the command line I am trying to eval â > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'PagerDuty'; > repository: 'git(a)gitlab.com <mailto:git@gitlab.com>:macta/WillowPagerDuty.git'; > load.â > > But I get retry errors and a walkback, so Iâve tried to do the same in the playground in a fresh image and its true - I get an error because ZnClient is trying to connect to a url like "http://:80/git@gitlab.com:macta/WillowPagerDuty.git/?C=M;O%3DD <http://:80/git@gitlab.com:macta/WillowPagerDuty.git/?C=M;O=D>â (so it interprets that git@ specification strangely). > > But what is weird, is that if I use Iceberg - connected to the same repo (and specified the same way) - and then use the Metacello - Install baseline menu (right click on the BaselineOfXXX package) it then works perfectly. > > So whatâs the difference? It looks like the latter is mapping down to a "repository: 'gitlocal://' <>, packageDir;â whereas the above is trying to read it over the wire? > > I then tried using an access token for gitlab, so its an https variant - but that gave me an error as well? Does this mean to automate I have to bring down the initial BaseLine - but then if that baseline refers to others - that seems to work, so Iâm a bit confused about what is going on? > > Tim

May 10, 2018

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

by Guillermo Polito

Just be careful, that privateState thing looks like a Moose only Famix feature. It't not available in plain Pharo objects :) On Wed, May 9, 2018 at 2:09 AM, Alidra Abdelghani via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Alidra Abdelghani <alidrandco(a)yahoo.fr> > To: Pavel Krivanek <pavel.krivanek(a)gmail.com> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Bcc: > Date: Wed, 9 May 2018 01:09:06 +0100 > Subject: Re: Package extension. Adding instance variables to classes > Hi Pavel, > > Thank you for your answer. > I actually didnât know about this mechanism. > I think it is will do the job :) > I have probably to rewrite some parts pf my code to access my variables > through privateState. no? > > > Thanks again > Abdelghani > > On 07 May 2018, at 13:15, pharo-users-request(a)lists.pharo.org wrote: > > > Message: 1 > Date: Mon, 7 May 2018 13:43:56 +0200 > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Package extension. Adding instance > variables to classes > Message-ID: > <CAHN2FzeMiBL4Y8asJ0XCjS2AQdxycoN+pbc+Hsd=trMnmuiJqw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 10, 2018

Re: [Pharo-users] Serializing Excpetion with Fuel on the production and opening debugger on the dev machine - hot to? [Pharo 5]

by Petr Fischer

Thanks to all! Works perfectly! pf > Hereâs the snippet to open a debugger (used in Pharo 6 tho) > > materializedContext := (FLMaterializer newDefault > materializeFrom: gzip) root. > > sessionName := 'debug saved Fuel context: {1}' format: {aName}. > > GTGenericStackDebugger openOn: > ((Process > forContext: materializedContext > priority: Processor userInterruptPriority) > newDebugSessionNamed: sessionName startedAt: materializedContext). > > Tim > > Sent from my iPhone > > > On 10 May 2018, at 12:41, Tim Mackinnon <tim(a)testit.works> wrote: > > > > PharoLambda does this - Iâm not near a computer to extract the code, but if you need it quickly you should find it easily - there is a class method on Lambda - something like debugSavedS3 which shows how to read in a file (from S3) and then launch a debugger. > > > > Tim > > > > Sent from my iPhone > > > >> On 10 May 2018, at 10:58, Petr Fischer <petr.fischer(a)me.com> wrote: > >> > >> Hello, what is the current procedure for achieving %subj%? I am on latest Pharo 5. > >> > >> I am serializing server side exception with: > >> > >> FLSerializer serialize: anException toFileNamed: 'something'. > >> > >> But how to open a debugger after materialization on the "dev machine side"? > >> > >> I found (Google, Mailing list) some examples, but it's obsolete (the debugger class no longer exists in Pharo 5 etc etc). > >> > >> Thanks! Petr Fischer > >> > > > >

May 10, 2018

Re: [Pharo-users] Serializing Excpetion with Fuel on the production and opening debugger on the dev machine - hot to? [Pharo 5]

by Tim Mackinnon

Hereâs the snippet to open a debugger (used in Pharo 6 tho) materializedContext := (FLMaterializer newDefault materializeFrom: gzip) root. sessionName := 'debug saved Fuel context: {1}' format: {aName}. GTGenericStackDebugger openOn: ((Process forContext: materializedContext priority: Processor userInterruptPriority) newDebugSessionNamed: sessionName startedAt: materializedContext). Tim Sent from my iPhone > On 10 May 2018, at 12:41, Tim Mackinnon <tim(a)testit.works> wrote: > > PharoLambda does this - Iâm not near a computer to extract the code, but if you need it quickly you should find it easily - there is a class method on Lambda - something like debugSavedS3 which shows how to read in a file (from S3) and then launch a debugger. > > Tim > > Sent from my iPhone > >> On 10 May 2018, at 10:58, Petr Fischer <petr.fischer(a)me.com> wrote: >> >> Hello, what is the current procedure for achieving %subj%? I am on latest Pharo 5. >> >> I am serializing server side exception with: >> >> FLSerializer serialize: anException toFileNamed: 'something'. >> >> But how to open a debugger after materialization on the "dev machine side"? >> >> I found (Google, Mailing list) some examples, but it's obsolete (the debugger class no longer exists in Pharo 5 etc etc). >> >> Thanks! Petr Fischer >> > >

May 10, 2018

Re: [Pharo-users] Serializing Excpetion with Fuel on the production and opening debugger on the dev machine - hot to? [Pharo 5]

by Norbert Hartl

> Am 10.05.2018 um 11:58 schrieb Petr Fischer <petr.fischer(a)me.com>: > > Hello, what is the current procedure for achieving %subj%? I am on latest Pharo 5. > > I am serializing server side exception with: > > FLSerializer serialize: anException toFileNamed: 'something'. > > But how to open a debugger after materialization on the "dev machine side"? > > I found (Google, Mailing list) some examples, but it's obsolete (the debugger class no longer exists in Pharo 5 etc etc). > > Thanks! Petr Fischer > Have a look at FuelOutStackDebugAction>>#serializeTestFailureContext:toFileNamed: Hope this helps! Norbert

May 10, 2018