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

Re: [Pharo-users] How to LAN feature

by Sven Van Caekenberghe

Uploading can be done using an HTTP POST or PUT, just like Playground does its Remote Publish, or Monticello its Save operation. > On 7 May 2018, at 19:15, Hilaire <hilaire(a)drgeo.eu> wrote: > > As described previously, students may also upload their work at the end of a teaching session. > > Hilaire > > > Le 07/05/2018 Ã 18:57, Norbert Hartl a Ã©crit : >> For what do you need an FTP server? For browsing and downloading usually a HTTP server is as good as. You implement a handler that returns a directory list for directories and the file content for files. Can be used with every web browser and zinc you have already in the image, >> >> Norbert > > -- > Dr. Geo > http://drgeo.eu > > >

May 7, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

As described previously, students may also upload their work at the end of a teaching session. Hilaire Le 07/05/2018 Ã 18:57, Norbert Hartl a Ã©critÂ : > For what do you need an FTP server? For browsing and downloading usually a HTTP server is as good as. You implement a handler that returns a directory list for directories and the file content for files. Can be used with every web browser and zinc you have already in the image, > > Norbert -- Dr. Geo http://drgeo.eu

May 7, 2018

Re: [Pharo-users] #ast vs. #parseTree

by webwarrior

If you guys are to get rid of acronyms in method names, cosider the following: #onDNU:do: #gcd: #lcm: #rem: #quo: #ulp #ln #theta #r #g #b and others. Then if you get bored again there are a lot of contractions, too, especially in Number and subclasses. Like #abs, #sqrt, #sin, #cos, ... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 7, 2018

Re: [Pharo-users] How to LAN feature

by Norbert Hartl

> Am 07.05.2018 um 18:08 schrieb Hilaire <hilaire(a)drgeo.eu>: > >> Le 06/05/2018 Ã 13:31, Norbert Hartl a Ã©crit : >> If it is on a single network this should be doable by using UDP broadcast announcements. The share server can announce some information and its IP in a UDP packet being broadcasted. Every client receives that and then knows the address of the server to connect to >> >> Hope this helps, Norbert > > Yep, then I can I set up a FTP server to run on the Pharo teacher instance. I already wrote a facade for user friendly FTP client. > Does any one know about FTP server on Pharo, for example this one[1]? > For what do you need an FTP server? For browsing and downloading usually a HTTP server is as good as. You implement a handler that returns a directory list for directories and the file content for files. Can be used with every web browser and zinc you have already in the image, Norbert > Thanks > > Hilaire > > [1] http://map.squeak.org/package/f84afa9e-c2ea-4d4c-bc65-aea93701753d > > -- > Dr. Geo > http://drgeo.eu > > >

May 7, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

Le 06/05/2018 Ã 13:31, Norbert Hartl a Ã©critÂ : > If it is on a single network this should be doable by using UDP broadcast announcements. The share server can announce some information and its IP in a UDP packet being broadcasted. Every client receives that and then knows the address of the server to connect to > > Hope this helps, Norbert Yep, then I can I set up a FTP server to run on the Pharo teacher instance. I already wrote a facade for user friendly FTP client. Does any one know about FTP server on Pharo, for example this one[1]? Thanks Hilaire [1] http://map.squeak.org/package/f84afa9e-c2ea-4d4c-bc65-aea93701753d -- Dr. Geo http://drgeo.eu

May 7, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Ramon Leon

On 05/05/2018 03:08 AM, Sean P. DeNigris wrote: > and may buy us little at the cost of a good amount of extra typing. Auto-completion killed that argument long ago. Method names are for reading, not writing; the computer will do most of the writing for you. If you're optimizing key strokes when deciding a method name, you're doing it wrong. -- Ramon Leon

May 7, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Richard Sargent

On Sat, May 5, 2018 at 3:08 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Richard Sargent wrote > > No. Please, really no. > > As much as I appreciate (and share) the passion for Smalltalk, you did not > AFAICT address my reasoning for not applying the no-acronym *guideline* in > this case, namely: > > >> Since the argument IIUC is that "a > >> general user won't know the domain well enough to understand the > >> acronym", > >> would they understand "abstractSyntaxTree"?! That, to me, is as opaque > as > >> the acronym for one not acquainted with the domain, and may buy us > little > >> at the cost of a good amount of extra typing. > I care a lot less about typing than reading. Some years ago, a colleague of mine conducted a brief and informal survey of the developers working in our team. "What fraction of time do you spend reading code versus writing code?" Some people answered 50:50. In effect, saying that for every method they read, they wrote a new one! The truth is that we all spend substantially more time reading than writing. Consequently, we need to emphasize how we communicate to readers. Alan Knight said it best: (paraphrasing) Trust the implementation does what it says it does. (In other words, message names should do what they say they do without creating the need to look inside the method to understand it.) > > > Richard Sargent wrote > > a disambiguation page with a lengthy list > > IMHO this is irrelevant. My proposal included a method comment, which would > provide the google-able term, as well as potentially a good enough summary > that one wouldn't have to leave the image. The fact that the method belongs > to CompiledMethod is the disambiguation. The internet is meaningless and > flat compared to the context and structure of a ST image. > > > Richard Sargent wrote > > Do not use comments embedded *inside* methods to cover for naming the > > method badlyâ¦ Also, if one Googles an acronym > > How is a harder-to-type thing that the user doesn't understand but is > easier > to google better than a comment that gives the necessary context right in > the image? My ideal image would avoid the need to Google as much as > possible, suggesting a comment either way, so nothing lost. There's nothing > inherently "bad" about an acronym. For example, no one's been banging down > the door to rename "JPEGReadWriter" to > "JointPhotographicExpertsGroupReadWriter". In that case, it's because the > acronym is so well-known, but what I'm asking whether #ast is a similar > candidate for exception because it is so unknown (i.e. compiler > domain-specific) that a user is likely to know either the term and the > acronym or neither. > The thing is that a well named concept doesn't need Googling in order to have at least some understanding of its meaning. I would be willing to bet that, even if you had never heard of the topic before, you would have *some* idea what the phrase abstract syntax tree meant. Conversely, the first time one might encounter the concept presented as "ast", you might suspect it was a kind of snake. I'm being a bit extreme here, of course. > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 7, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Richard Sargent

> > I know it. But my stupid question is why it's still called abstract while > it is implemented for concrete language? > I finally got around to running an image and extracting a screen print. Hopefully, it will attach and be visible to you. The classes of objects in the inspector show the abstract syntax: a method node comprised of a sequence node, etc. Each abstract syntax node is bound with the actual source code that it represents. Abstract is not about the language something is implemented in, but rather the syntactic structure of the code. On Fri, May 4, 2018 at 12:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2018-05-04 21:10 GMT+03:00 Richard Sargent <richard.sargent@ > gemtalksystems.com>: > >> On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>> >>>> Ramon Leon-5 wrote >>>> > And my point made; I don't even know what that means. >>>> >>>> Ha ha, I googled it and even after seeing the definition still didn't >>>> understand - we must be getting old ;-) >>>> >>>> Regarding the use of acronyms - while I agree with you as a general >>>> principle, I wonder about this case. Since the argument IIUC is that "a >>>> general user won't know the domain well enough to understand the >>>> acronym", >>>> would they understand "abstractSyntaxTree"?! >>> >>> >>> Now I am wonder: is it really correct to call syntax tree as abstract >>> when it is really implemented? >>> AST is very known term but now when I read it word by word I have such >>> questions :). >>> >> >> In computer science, an *abstract syntax tree* (AST), or just *syntax >> tree*, is a *tree* representation of the *abstract syntactic *structure >> of source code written in a programming language. >> [Wikipedia] >> > > I know it. But my stupid question is why it's still called abstract while > it is implemented for concrete language? > > >> >> >>> >>> >>>> That, to me, is as opaque as >>>> the acronym for one not acquainted with the domain, and may buy us >>>> little at >>>> the cost of a good amount of extra typing. Maybe keep the acronym and >>>> add a >>>> good method commentâ¦ >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>> >>>> >>> >> >

May 7, 2018

Re: [Pharo-users] Personal Programming onPharo

by Sean P. DeNigris

Trygve Reenskaug wrote > I am developing an IDE for non-programmersÂ called BabyIDE I remember seeing this in a screencast - it was very cool! Trygve Reenskaug wrote > In your answer, I read that if I build BabyIDE on Pharo, I will be > building on sand. Sorry I took so long to reply to your OP. It does indeed *sound* like that but AFAICT (myself included with dozens of projects), porting to new versions has been relatively painless. That said, a project like you described may have additional hurdles because it hooks so deeply into the inner guts of the IDE. Also, there are continually new techniques to ease these transitions. For example, there is now a deprecation message which auto-rewrites sender on first send; this is even more powerful if one has tests with good coverage because running the tests magically updates your project. Trygve Reenskaug wrote > A tale from the futureâ¦ drop whatever they are doing in > order to adapt their applications to the new Pharo so that you can start > serving your customers again. It's a hard problem because we have a big vision, which means a natural tension with backward compatibility. In fact, IMHO that was one of the major reasons for the fork from Squeak, so I guess it's unfortunate that now Squeak seems to be a moving target as well. Again, just to reiterate, AFAICT, most of the changes are generally deep in the system and will not affect the average customer facing project. Even then, there's no need to be on the latest, greatest version if the cost doesn't seem worth it. There are plenty of production systems happily running on Pharo 1.x. Suggestions are very welcome about how to move toward a bright future with minimum impact on existing users/projects!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 7, 2018

Re: [Pharo-users] Personal Programming onPharo

by Stephan Eggermont

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. > Oracle lists 24 behavioral incompatibilities between Java SE 7 and SE 6. Stephan

May 7, 2018

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

Re: [Pharo-users] Saving a Smalltalk Project

by Marten Feldtmann

>From my current experiences ... the people do not choose OODBs, because in the mainstream languages the stuff is simply not visible (market share). The knowledge is not there and the biggest problem - a programming interfaces are not available. People use RDBMS oder NoSQl systems, because these systems offer a programming model to developers - even if they are simply bad. And they offer language independent access to the data. Some people are moving from RDBMS to NoSQL-system, because they hope to get more OO-programming in the database. Thats also a problem with Gemstone/S. Its a wonderful database, but it offers no default programming model to external developers - so it will never be attractive to non-Smalltalk developers. Am 06.05.2018 um 23:08 schrieb Todd Blanchard: > It sounds great...until something goes wrong. I wouldnât choose it for important data. I might use it as a local cache. Especially when it has a single maintainer I could go to for help. > > > Sent from the road > >> On May 6, 2018, at 11:44, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Todd Blanchard <tblanchard(a)mac.com> wrote: >>> Just out of curiosity, why do you want an OODB? >> >> http://wiki.squeak.org/squeak/5602 >> >> >> >> >

May 6, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Todd Blanchard

It sounds great...until something goes wrong. I wouldnât choose it for important data. I might use it as a local cache. Especially when it has a single maintainer I could go to for help. Sent from the road > On May 6, 2018, at 11:44, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Todd Blanchard <tblanchard(a)mac.com> wrote: >> Just out of curiosity, why do you want an OODB? > > http://wiki.squeak.org/squeak/5602 > > > >

May 6, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Todd Blanchard

Postgres is indeed awesome - but pretty heavy for a resource constrained IoT client. Itâs great on the server though. Sent from the road > On May 6, 2018, at 10:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > PostgreSQL is a totally valid alternative as well. It is a real RDBMS, cross platform, open source, with wide support. We have two network level drivers in Pharo (PostgresV2 and recently P3) and it works well under GLORP. > >> On 6 May 2018, at 19:10, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> Just out of curiosity, why do you want an OODB? >> >> SQLite has a plethora of tools, powerful query capabilities, can be migrated with very little pain, and can act a bit like an OODB using GLORP. >> >> I have lost too many data sets to proprietary OODBs to ever trust one again. >> >>> On May 6, 2018, at 10:00 AM, horrido <horrido.hobbies(a)gmail.com> wrote: >>> >>> Just out of curiosity, which object database is recommended for Pharo? >>> Something that is reliably up-to-date as Pharo changes. >>> >>> >>> Stephan Eggermont-3 wrote >>>> Sean P. DeNigris < >>> >>>> sean@ >>> >>>> > wrote: >>>>> OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but >>>>> the >>>>> first reaction of people from less "productive" languages/systems is to >>>>> rewrite a working Smalltalk app in their language of comfortâ¦ >>>> >>>> Indeed. And rewriting something that also uses an OODB is going to kill >>>> productivity even more. 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 >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

May 6, 2018

Re: [Pharo-users] Personal Programming onPharo

by Norbert Hartl

As you are not biased to understand what I was saying can you please define what âstabilityâ means to you? After all those years Iâm fed up with people using terms like âstabilityâ or âscabilityâ as if the were self-explaining. The same goes for âenterprise needsâ. They are not, they are defined within the scope if their requirements. I have more than 100 pharo images running and these are pretty stable. Why? Because pharo is stable enough and I am capable of doing the rest to make it right for my needs. On the other hand if I were into writing UI based tools I know there will be a lot of changes in the coming years. So nothing to expect regarding stability. If you work in an enterprise your definition of stability can be defined as static/non-moving stability. It just means you donât have to cope with everyday changes but the gap of your software to actual software gets bigger every day. And with every day it is more unlikely someone is brave enough to decide to move on and to catch up with the rest. etc. etc. Norbert > Am 06.05.2018 um 21:16 schrieb Todd Blanchard <tblanchard(a)mac.com>: > > OK, I have to push back at this. > > When Pharo forked I was excited because Squeak was such a fast moving lab experiment that you couldn't build anything and expect it to work in a year. > > Pharo was supposed to be the "business ready" fork leaving Squeak to be the crazy lab experiment. > > From https://pharo.org/about > > It says: > > Pharo's goal is to deliver a clean, innovative, free and open-source immersive environment. > > By providing a stable and small core system, excellent developing tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical applications. > > But you are telling me that Pharo is also a fast moving lab experiment that is too unstable for real work? > > I understand this is hard but is there a definitive roadmap and plan to reach to stability? > >> On May 6, 2018, at 4:00 AM, Norbert Hartl <norbert(a)hartl.name> 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 >>> Morgedalsvn. 5A http://folk.uio.no/trygver/ >>> N-0378 Oslo http://fullOO.info >>> Norway Tel: (+47) 22 49 57 27 >

May 6, 2018

Re: [Pharo-users] Personal Programming onPharo

by horrido

I was thinking the same thing. Enterprises need to rely on a stable distribution over a long period of time. That's why many Linux distros have LTS versions. That's why VisualWorks is the enterprise standard. tblanchard wrote > OK, I have to push back at this. > > When Pharo forked I was excited because Squeak was such a fast moving lab > experiment that you couldn't build anything and expect it to work in a > year. > > Pharo was supposed to be the "business ready" fork leaving Squeak to be > the crazy lab experiment. > > From https://pharo.org/about > > It says: > > Pharo's goal is to deliver a clean, innovative, free and open-source > immersive environment. > > By providing a stable and small core system, excellent developing tools, > and maintained releases, Pharo is an attractive platform to build and > deploy mission critical applications. > > But you are telling me that Pharo is also a fast moving lab experiment > that is too unstable for real work? > > I understand this is hard but is there a definitive roadmap and plan to > reach to stability? > >> On May 6, 2018, at 4:00 AM, Norbert Hartl < > norbert@ > > 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@.uio > <mailto: > trygver@.uio > >>: >> >>> 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@.uio > <mailto:% > 20trygver@.uio > > >>> 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 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 6, 2018