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

Metacello load in code vs. Iceberg menu install? Can you automate remote loading?

by Tim Mackinnon

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@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 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by Bernardo Ezequiel Contreras

Tim, i've used the following script https://github.com/pharo-vcs/tonel/blob/master/MigrateFromFileTree.md in my pet projects. hope this helps. On Wed, May 9, 2018 at 8:22 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hmmm - I donât think Iâve fully understood the instructions. If I already > have a project in filetree git format - does creating the .properties file > work? What do I do to convert it to tonel format? I think Iâve noticed a > few announcements where people have said theyâve moved to the new tonel > format - so how did they do it? > > I tried using git on the command line to add .properties file there - but > not sure it did anything? > > Tim > > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

May 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by Tim Mackinnon

Hmmm - I donât think Iâve fully understood the instructions. If I already have a project in filetree git format - does creating the .properties file work? What do I do to convert it to tonel format? I think Iâve noticed a few announcements where people have said theyâve moved to the new tonel format - so how did they do it? I tried using git on the command line to add .properties file there - but not sure it did anything? Tim > On 9 May 2018, at 15:21, Tim Mackinnon <tim(a)testit.works> wrote: > > Ah - I missed that piece of information - could that be put on the iceberg readme.md? In fact - Iâll submit a pr so you can keep motoring on getting it all to work (I really want a stable git environment - we are getting sooo close). > > Tim > >> On 9 May 2018, at 11:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> the problem is that tonel relies in a .properties file to know a repository format. >> and for backward compatibility, if this .properties file is not present, iceberg assumes the repository is a plain old âfiletreeâ repository. >> >> so, until we figure out how to provide both things (a nice tonel switch and backwar compatibility), the workaround is to commit a .properties file into you root repository, with this form: >> >> { >> #format : #tonel >> } >> >> and of course, thatâs before doing anything image-side. >> >> cheers, >> Esteban >> >> >>> On 9 May 2018, at 12:21, herby(a)mailbox.sk wrote: >>> >>> Yes, it is insanely hard to write project in tonel format. Needs lot of hacking here and there, setting the setting itself is not helpful. I managed to, somehow, but I forgot the algorithm already. I am dreadful as to when I will need to do it again. Takes lots of time and nerves. >>> >>> Herby >>> >>> On May 9, 2018 11:54:56 AM GMT+02:00, Tim Mackinnon <tim(a)testit.works> wrote: >>>> Hi guys - With all the talk about iceberg changes, Iâve stayed away >>>> from it for a bit (6 months) - but downloaded a new 6.1 image a few >>>> weeks ago and went to version some stuff yesterday into a new project. >>>> >>>> Iceberg seems a bit more stable - but it still seems to write out >>>> individual methods as files which I thought had been changed? Am I >>>> doing something wrong - or do i need to set something? >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>> >> >> > >

May 9, 2018

Re: How to pretty print a dynamic array

by Davide Varvello

Yep, Peter, that's an other option. Thanks Peter UhnÃ¡k wrote >> {self meth1. self meth2. self meth3} > > This is not possible in a reasonably general way. Usually I end up writing > it like `Array with: self meth1 with: self meth2 with: self meth3` > > On Tue, May 8, 2018 at 3:31 PM, Davide Varvello via Pharo-users < > pharo-users@.pharo >> wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Davide Varvello < > varvello@ > > >> To: > pharo-users@.pharo >> Cc: >> Bcc: >> Date: Tue, 8 May 2018 06:31:46 -0700 (MST) >> Subject: Re: How to pretty print a dynamic array >> Thanks Ben, I'm gonna try >> Cheers >> Davide >> >> >> Ben Coman wrote >> > On 8 May 2018 at 04:22, Davide Varvello via Pharo-users < >> >> > pharo-users@.pharo >> >> >> wrote: >> > >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: Davide Varvello < >> >> > varvello@ >> >> > > >> >> To: >> >> > pharo-users@.pharo >> >> >> Cc: >> >> Bcc: >> >> Date: Mon, 7 May 2018 13:22:58 -0700 (MST) >> >> Subject: How to pretty print a dynamic array >> >> Hi guys, >> >> I have a dynamic array that the formatter put on a column like this: >> >> {self meth1. >> >> self meth2. >> >> self meth3} >> >> >> >> instead I want it in a single row, like this: >> >> {self meth1. self meth2. self meth3} >> >> >> >> But I can't find any settings to pretty print in the last way. >> >> Can you help me, please? >> >> >> > >> > Hi Davide, >> > >> > I'm not sure I can be much help since I never use the pretty printer >> and >> > I'm not familiar with the system. >> > There may be a setting for that, but if not and I wanted to find out >> about >> > how to do it >> > I'd take the shotgun approach.... >> > >> > In System > Settings, search for "pretty" and the with some setting >> > related >> > to newLines, >> > some line "New line After Cascade" >> > then "Browse" it, then in the body of the method find that text again >> > and look for senders attached selector. >> > >> > That brought me to " BIConfigurableFormatter >> visitCascadeNode: " >> > and browsing that method in the System Browser shows a bundle of other >> > "visitXXX" methods. >> > Drop a "self haltOnce" in an interesting one and try to trigger when >> you >> > pretty print. >> > Trace through a few times to learn how it does its stuff, and see if >> you >> > can change it to do what you want. >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 9, 2018

Re: [Pharo-users] How to LAN feature

by Dimitris Chloupis

On Sun, May 6, 2018 at 1:48 PM Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I am looking for advices on a feature I want to develop for Dr. Geo. > > The need takes place in a LAN, for example in a School computer lab. > I think that even in the case of a LAN you can still do it via internet using something like github or dropbox. Many of those online tools work on an account basis and Pharo already offers some support for Github. If it has to be a LAN and the internet is a no go then another choice would be to have the "server" which probably will be the teacher access to the truter and retriever the IPs directly, even if the ip changes the connection can be identified by name and of course the router will provide the ips and names of all connections to it. I have not tried from Pharo but I am assuming it should be doable because the router can be access via an internet browser for their setup and settings. Format wise you could use something like STON , or if you rely of raster graphics (JPEG, PNG) , fuel could be a better choice for binary formats and eliminate any loss of performance while loading scetches remotely. Nowdays it has become the norm to identify people through popular accounts like Google (gmail), Facebook, iCloud, Microsoft Account, Twitter etc. In the case of dropbox you get also synchronisation for free which will give students immediate access not only to sceteches by teachers but all other students too because dropbox supports shared folders and you wont have to actively share each individual folder because those folder do this automagically for you. Dropbox also stores the version of the files for up to 30 days and of course its free, unless the scetches demand much more than 2 GBs which if they are anything like SVG they should not.

May 9, 2018

Re: [Pharo-users] Personal Programming onPharo

by Dimitris Chloupis

Cross platform support has always been a can of worms in any language. As soon as one tries to do something that is not so popular it usually results into several issues that may be there for years if not decades. Especially in the case of third party libraries. This is also one of the big reasons why many large project today are made in multiple programming languages. In my case, I battle with lack of good documentation about OpenGL which I find very surprising, considering how popular as a library it is. In theory, I should not experience such an issue but practice tends to always have a different opinion. Indeed, everything breaks and everything has its own issues which become apparent as soon as you make heavy usage of the thing. Then of course you have the case where the language or the library as you already mentioned break compatibility intentionally. So instabilities are part of coding, you learn to live with them and evade them to a reasonable degree. On Wed, May 9, 2018 at 4:54 PM 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 >> <+47%2022%2049%2057%2027> >> >> >> >> -- >> >> *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 >> <+47%2022%2049%2057%2027> >> > >

May 9, 2018

Re: [Pharo-users] How to LAN feature

by N. Bouraqadi

Hi, Just want to point that I did some work late 2017 on UDP sockets including multicast and broadcast. The package named 'NetworkExtras' is part of the ReusableBricks repo of my team. http://smalltalkhub.com/#!/~CAR/ReusableBricks It has some dependencies on other packages. I tested it in Pharo 6, but not 7. Noury PS. Since I can't keep up with the mailing-list traffic, don't forget to keep me in CC so I can react > On 08 May 2018, at 15:36, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 08.05.2018 um 15:05 schrieb Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: >> >>> Le 8 mai 2018 Ã 08:28, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> a Ã©crit : >>> >>> HilaireFernandes wrote >>>> Computer should be on a same network, however not sure about swtich in >>>> between. >>>> >>>> Does UDP broadcast required particular privilege on the host? >>>> >>>> Thanks >>>> >>>> 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 >>>> >>>> -- >>>> Dr. Geo >>>> http://drgeo.eu <http://drgeo.eu/> >>> >>> No, but it does involve setting certain options on the socket, etc. >>> You could check if http://smalltalkhub.com/#!/~henriksp/SSDP <http://smalltalkhub.com/#!/~henriksp/SSDP> is >>> appropriate/works for you. >>> >>> Cheers, >>> Henry >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >>> >> >> >> On 8 May 2018 at 15:32, CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> wrote: >> Hi, FYI, Noury did this package (Network-Extra). I will test for my lecture. It has UDP Multicast/broadcast and may help for the discovery phase (Iâm interested in that either). >> >> He said that about it: >> >> - UDP support : mutlicast + broadcast >> - fragment a (large) data et assemble it over UDP >> -la possibilitÃ© de fragmenter une donnÃ©e trop grande et la reconstruire au-dessus d'UDP >> >> Gofer it >> smalltalkhubUser: 'CAR' project: 'ReusableBricks'; >> configurationOf: 'ReusableBricks'; >> loadBleedingEdge >> >> Hope this help, >> >> See you, >> >> CÃ©drick >> >> Ps: tell me if you use it. >> >> >> If we've got multicast support for Pharo, perhaps its not a long jump to implementing mDNS. >> Then the teacher could share out their machine as "teacher.local" >> to let student machines connect to it. >> > If they all have Macs that would work. For the rest I doubt it will be that easy. > > Norbert > >> https://www.trustwave.com/Resources/SpiderLabs-Blog/mDNS---Telling-the-worl… <https://www.trustwave.com/Resources/SpiderLabs-Blog/mDNS---Telling-the-worl…> >> >> https://tools.ietf.org/html/rfc6762 <https://tools.ietf.org/html/rfc6762> >> The most basic kind of Multicast DNS client may simply send standard >> DNS queries blindly to 224.0.0.251:5353 <http://224.0.0.251:5353/>, without necessarily even >> being aware of what a multicast address is. This change can >> typically be implemented with just a few lines of code in an existing >> DNS resolver library. >> >> >> @Udo, did you ever find that mDNS package you lost? >> http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4827245.html <http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4827245.html> >> >> >> mDNS would be an interesting facility to include in the main Pharo release image, >> perhaps making it very easy for our "live" systems to locate each other on a local network without external infrastructure. >> >> >> cheers -ben

May 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by Tim Mackinnon

Ah - I missed that piece of information - could that be put on the iceberg readme.md? In fact - Iâll submit a pr so you can keep motoring on getting it all to work (I really want a stable git environment - we are getting sooo close). Tim > On 9 May 2018, at 11:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > the problem is that tonel relies in a .properties file to know a repository format. > and for backward compatibility, if this .properties file is not present, iceberg assumes the repository is a plain old âfiletreeâ repository. > > so, until we figure out how to provide both things (a nice tonel switch and backwar compatibility), the workaround is to commit a .properties file into you root repository, with this form: > > { > #format : #tonel > } > > and of course, thatâs before doing anything image-side. > > cheers, > Esteban > > >> On 9 May 2018, at 12:21, herby(a)mailbox.sk wrote: >> >> Yes, it is insanely hard to write project in tonel format. Needs lot of hacking here and there, setting the setting itself is not helpful. I managed to, somehow, but I forgot the algorithm already. I am dreadful as to when I will need to do it again. Takes lots of time and nerves. >> >> Herby >> >> On May 9, 2018 11:54:56 AM GMT+02:00, Tim Mackinnon <tim(a)testit.works> wrote: >>> Hi guys - With all the talk about iceberg changes, Iâve stayed away >>> from it for a bit (6 months) - but downloaded a new 6.1 image a few >>> weeks ago and went to version some stuff yesterday into a new project. >>> >>> Iceberg seems a bit more stable - but it still seems to write out >>> individual methods as files which I thought had been changed? Am I >>> doing something wrong - or do i need to set something? >>> >>> Tim >>> >>> Sent from my iPhone >> > >

May 9, 2018

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

by Richard O'Keefe

I'm personally OK with 'ast'. Did I write anything that made you think I wasn't? Of course things are contextual. In VMS one took "AST" to mean "Asynchronous System Trap". But even in VMS it was not confusing in a parsing context. As for "obviously sarcastic", I'm afraid there's this thing called "Poe's Law". On 9 May 2018 at 23:57, webwarrior <reg(a)webwarrior.ws> wrote: > Richard O'Keefe wrote > > First, my message was *defending* most of the short names > > that someone else was attacking. For the record, I am > > *far* more worried about the fragility of typical Smalltalk > > code than I am about method names, which are generally > > pretty good. > > > > ... > > If by "someone else" you mean me, I was obviously sarcastic. If you are OK > with GCD, LCM, ULP and other abbreviations, why get rid of AST? It's > well-known and unambigous term in respective area, that is also usually > used > as identifier in other programming languages and libraries (e.g. ast module > in Python, Microsoft.FSharp.Compiler.Ast module in F#). > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 9, 2018

Re: [Pharo-users] Personal Programming onPharo

by Richard O'Keefe

â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 9, 2018

Re: [Pharo-users] Personal Programming onPharo

by H. Hirzel

On 5/9/18, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > Of course not. But one of my goals is that future dynabooks will be > backwards compatible. Recent discussions have shown me that this goal is > a research project. > --Trygve Indeed [1]. And a very interesting one! Found and read your overview http://folk.uio.no/trygver/themes/Personal/PP-NIK.pdf And also the more elaborate draft of a description (50 pages) [2] http://folk.uio.no/trygver/themes/Personal/pp-index.html links to http://folk.uio.no/trygver/themes/Personal/PersonalProgramming.233.zip For my personal programming needs in Squeak so far I realized that the 'data' part is the easiest one to tackle in terms of backward compatibility. And some success in converting data to code forth and back to ease compatibility. It would be nicer of course to have a homoiconic notation [3] but still very doable. In particular as the new VMs have lifted the size constraint for the source code of in methods. --Hannes [1] An example is about the work involved to get a 17 year old 'Dynamic essay' from Squeak 3.2 to read in properly into a Squeak 6.0a trunk image http://forum.world.st/Dynamic-essay-project-MorphLayoutArticle-on-Bob-s-Sup… Quite some effort and not a full result yet... Though Squeak has some mechanisms to update classes and objects. In that thread Edgar de Cleene outlined the idea of a recursive DNU mechanism to check out earlier messages from the web http://forum.world.st/Dynamic-essay-project-MorphLayoutArticle-on-Bob-s-Sup… Needs much more elaboration ... ------------------- [2] Abstract Computer programming celebrates its platinum jubilee on the 21st of June, 2018. Exactly 70 years ago, the world's first programmer wrote the world's first program and then stored and executed it in the world's first stored program computer; affectionately known as Baby. The solitary Baby has morphed into billions of computers that are loosely connected into a single, global machine. Baby's control panel has morphed into graphical user interfaces (GUI) that empower everybody to augment their intellect. The consequences are deeply radical for individuals and society alike. A significant side effect of the GUI is that the computer has faded into the background and the user focuses on the immediate needs. We present DCI, a new programming paradigm that targets structures of communicating computers. Its goal is readable code that is so intuitive that everybody can grok it and so comprehensive that expert programmers will enjoy using it. DCI programming has been tested on real-life problems. A set of controlled experiments showed that DCI code is more readable than Java code. A new programming environment, BabyIDE, targets the single, global machine. Different GUIs support programmers having different mental models depending on their interests and proficiency. An MVC system architecture makes the program fade into the background and lets the user concentrate on satisfying his or her immediate needs. My approach is experimental. Smalltalk's universe of objects imitates the single, global machine and is my proving ground.We give two examples: one for experts and another for novices. A video1 illustrates the novice IDE. Our approach is experimental. The universe of objects found in Smalltalk's image imitates a computer network and is our proving ground. Squeak 3.10.2 is our laboratory where we experiment with various versions of BabyIDE. A great deal of work remains to make BabyIDE generally available and we are searching for a trailblazer who will take charge of it and take it out into the world. Keywords: Personal Programming, Novice Programming, Single Global Machine, IOT, Smart Home, MVC, DCI, BabyIDE, Smalltalk, Object Orientation [3] http://goran.krampe.se/2016/07/19/spry-is-a-smalltalk/ > On 09.05.2018 12:19, Marcus Denker wrote: >>> >>> >>>> I go back to Alan Kay's vision of a Dynabook: A/personal/computer >>>> for children of all ages. It should contain all its owner's >>>> /personal/data, including his or her/personal/programs, as they >>>> evolve through the years. Continuity is a must; the owner shall >>>> never loose data. >>>> >>> >> >> Do you really expect that the dynabook will be 100% backward >> compatible to Smalltalk-80? >> >> Marcus > > -- > > /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 9, 2018

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

by webwarrior

Richard O'Keefe wrote > First, my message was *defending* most of the short names > that someone else was attacking. For the record, I am > *far* more worried about the fragility of typical Smalltalk > code than I am about method names, which are generally > pretty good. > > ... If by "someone else" you mean me, I was obviously sarcastic. If you are OK with GCD, LCM, ULP and other abbreviations, why get rid of AST? It's well-known and unambigous term in respective area, that is also usually used as identifier in other programming languages and libraries (e.g. ast module in Python, Microsoft.FSharp.Compiler.Ast module in F#). -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by Herbert VojÄÃk

Esteban Lorenzano wrote: > the problem is that tonel relies in a .properties file to know a repository format. > and for backward compatibility, if this .properties file is not present, iceberg assumes the repository is a plain old âfiletreeâ repository. > > so, until we figure out how to provide both things (a nice tonel switch and backwar compatibility), the workaround is to commit a .properties file into you root repository, with this form: > > { > #format : #tonel > } > > and of course, thatâs before doing anything image-side. Yeah, that was maybe what I actually did, somehow. I faintly remember only doing something with .properties first... maybe I achieved it by getting to the newly created repo instance by some allInstances filtering and setting it to tonel format by some message send then committing it empty so .properties got there... anyway thanks for clarifying it for the next time. > cheers, > Esteban > > >> On 9 May 2018, at 12:21, herby(a)mailbox.sk wrote: >> >> Yes, it is insanely hard to write project in tonel format. Needs lot of hacking here and there, setting the setting itself is not helpful. I managed to, somehow, but I forgot the algorithm already. I am dreadful as to when I will need to do it again. Takes lots of time and nerves. >> >> Herby >> >> On May 9, 2018 11:54:56 AM GMT+02:00, Tim Mackinnon <tim(a)testit.works> wrote: >>> Hi guys - With all the talk about iceberg changes, Iâve stayed away >>> from it for a bit (6 months) - but downloaded a new 6.1 image a few >>> weeks ago and went to version some stuff yesterday into a new project. >>> >>> Iceberg seems a bit more stable - but it still seems to write out >>> individual methods as files which I thought had been changed? Am I >>> doing something wrong - or do i need to set something? >>> >>> Tim >>> >>> Sent from my iPhone >> > >

May 9, 2018

Re: [Pharo-users] Personal Programming onPharo

by Trygve Reenskaug

Of course not. But one of my goals is that future dynabooks will be backwards compatible. Recent discussions have shown me that this goal is a research project. --Trygve On 09.05.2018 12:19, Marcus Denker wrote: >> >> >>> I go back to Alan Kay's vision of a Dynabook: A/personal/computer >>> for children of all ages. It should contain all its owner's >>> /personal/data, includingÂ his or her/personal/programs, as they >>> evolve through the years.Â Continuity is a must; the owner shall >>> never loose data. >>> >> > > Do you really expect that the dynabook will be 100% backward > compatible to Smalltalk-80? > > Marcus -- /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 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by Esteban Lorenzano

the problem is that tonel relies in a .properties file to know a repository format. and for backward compatibility, if this .properties file is not present, iceberg assumes the repository is a plain old âfiletreeâ repository. so, until we figure out how to provide both things (a nice tonel switch and backwar compatibility), the workaround is to commit a .properties file into you root repository, with this form: { #format : #tonel } and of course, thatâs before doing anything image-side. cheers, Esteban > On 9 May 2018, at 12:21, herby(a)mailbox.sk wrote: > > Yes, it is insanely hard to write project in tonel format. Needs lot of hacking here and there, setting the setting itself is not helpful. I managed to, somehow, but I forgot the algorithm already. I am dreadful as to when I will need to do it again. Takes lots of time and nerves. > > Herby > > On May 9, 2018 11:54:56 AM GMT+02:00, Tim Mackinnon <tim(a)testit.works> wrote: >> Hi guys - With all the talk about iceberg changes, Iâve stayed away >> from it for a bit (6 months) - but downloaded a new 6.1 image a few >> weeks ago and went to version some stuff yesterday into a new project. >> >> Iceberg seems a bit more stable - but it still seems to write out >> individual methods as files which I thought had been changed? Am I >> doing something wrong - or do i need to set something? >> >> Tim >> >> Sent from my iPhone >

May 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by herby＠mailbox.sk

Yes, it is insanely hard to write project in tonel format. Needs lot of hacking here and there, setting the setting itself is not helpful. I managed to, somehow, but I forgot the algorithm already. I am dreadful as to when I will need to do it again. Takes lots of time and nerves. Herby On May 9, 2018 11:54:56 AM GMT+02:00, Tim Mackinnon <tim(a)testit.works> wrote: >Hi guys - With all the talk about iceberg changes, Iâve stayed away >from it for a bit (6 months) - but downloaded a new 6.1 image a few >weeks ago and went to version some stuff yesterday into a new project. > >Iceberg seems a bit more stable - but it still seems to write out >individual methods as files which I thought had been changed? Am I >doing something wrong - or do i need to set something? > >Tim > >Sent from my iPhone

May 9, 2018

Re: [Pharo-users] Personal Programming onPharo

by Marcus Denker

> > >> I go back to Alan Kay's vision of a Dynabook: A personal computer for children of all ages. It should contain all its owner's personaldata, including his or her personal programs, as they evolve through the years. Continuity is a must; the owner shall never loose data. >> > Do you really expect that the dynabook will be 100% backward compatible to Smalltalk-80? Marcus

May 9, 2018

Re: [Pharo-users] Tonel, Pharo 6.1 and file per class?

by Sven Van Caekenberghe

Can't really speak for 6.1 but on 7 things are definitively Tonel based (unless you use existing/older repos). Tracking Iceberg is best done in 7 (if you can live with an actively developed system). > On 9 May 2018, at 11:54, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi guys - With all the talk about iceberg changes, Iâve stayed away from it for a bit (6 months) - but downloaded a new 6.1 image a few weeks ago and went to version some stuff yesterday into a new project. > > Iceberg seems a bit more stable - but it still seems to write out individual methods as files which I thought had been changed? Am I doing something wrong - or do i need to set something? > > Tim > > Sent from my iPhone >

May 9, 2018

Tonel, Pharo 6.1 and file per class?

by Tim Mackinnon

Hi guys - With all the talk about iceberg changes, Iâve stayed away from it for a bit (6 months) - but downloaded a new 6.1 image a few weeks ago and went to version some stuff yesterday into a new project. Iceberg seems a bit more stable - but it still seems to write out individual methods as files which I thought had been changed? Am I doing something wrong - or do i need to set something? Tim Sent from my iPhone

May 9, 2018

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

by Esteban Lorenzano

to talk seriously, I agree #onDNU:do: would be better called with its long name. now, well known acronyms have their place in pharo as complete, self explaining method names too. is about matter of common sense to opt for one or the other (for example, âln" is more known in maths that its âlong name" neperian logarithm). Rules and conventions are not written in stone and smart people can have an agreement on when to break them. Acronyms is this case: while *in general* using them is bad, well known acronyms as HTTP, AST, etc. are fine and even sometimes better. cheers! Esteban > On 9 May 2018, at 02:03, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > First, my message was *defending* most of the short names > that someone else was attacking. For the record, I am > *far* more worried about the fragility of typical Smalltalk > code than I am about method names, which are generally > pretty good. > > Second, the criterion was implicit but fairly clear: > if an abbreviation of any kind is sufficiently common > that someone who wants the semantics will recognise the > identifier, use it. "ulp" is MORE familiar to people > who need it than "unitOfLeastPrecision" (spit), so it is > a better name. In the same way, HTTP is a *better* name > than HyperTextWhatever (amongst other things because the > word is Hypertext, so HyperText violates a Smalltalk style > rule that says internal capitals at *word* boundaries) > because it is familiar and takes less effort to recognise > than the fully spelled out thing. > > Third, the rule as always is "intention-revealing names". > (Another Smalltalk style rule that I did not invent.) > #onDNU:do: is a confusing name because when I saw it I > expected the first argument to be a signalled exception, > not a selector. There is nothing wrong with the DNU bit; > if you know you want to catch a DNU you are probably > familiar with "DNU" (and don't want to fuss with whether > it means Does Not Understand or Did Not Understand). > As a particular example from the list, #log or > #logarithm are both ambiguous, while #ln is NOT > ambiguous (in the context of numbers), making it a > better name, > > Finally, the significant point was not where I live > (about 1/1600 of the world's population live here) > but when I went to primary school, which was somewhat > more than 50 years ago. Twenty years before that, > children learned how to calculate square roots by hand. > (Cue Four Yorkshiremen. :-)) > > > > On 8 May 2018 at 20:00, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <raoknz(a)gmail.com>: >> >> #gcd: >> #lcm: >> >> These come from elementary (primary school in my day) mathematics. They are the standard names. > > You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again? > > Norbert > >

May 9, 2018

Re: [Pharo-users] How to LAN feature

by Norbert Hartl

That is mDNS being used. Bonjour is the MacOS service and Avahi the linux one. Norbert > Am 09.05.2018 um 02:25 schrieb JuliÃ¡n Maestri <serpi90(a)gmail.com>: > > You could also publish on a zeroconf service (Bonjour/Avahi) https://en.wikipedia.org/wiki/Zero-configuration_networking > >> On 8 May 2018 at 11:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> Ben Coman wrote >> > mDNS would be an interesting facility to include in the main Pharo release >> > image, >> > perhaps making it very easy for our "live" systems to locate each other on >> > a local network without external infrastructure. >> > >> > >> > cheers -ben >> >> mDNS and SSDP are pretty much interchangeable, implementation wise ;) >> >> The main problem; most computers these days come with multiple networking >> interfaces, and are usually connected to separate subnets. >> So when you connect a socket to the broadcast address, you have no idea >> which interface it will actually send the request over, and whether you can >> communicate with other entities is sort if hit or miss. >> >> Pharos netresolver is blissfully unaware/unable to tell you which interfaces >> are available, >> most of the work in the SSDP implementation went into trying to detect all >> the different ones (impossible without the added networking prims, and still >> unreliable whether it will find the correct ones with...), and bind:'ing a >> socket to each specifically. >> >> IIRC, the default server/client instantiation exemplified in class comments >> now simply binds to 0:0:0:0 and hopes the default interface is what you >> wanted, SSDPServer>>onAllInterfacesOfferServiceType:atLocation: runs >> through the more extensive setup. >> >> Cheers, >> Henry >> >> P.S. In second place; a listener loop capable of error handling a spotty >> wifi connection/machine sleep cycles... >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >

May 9, 2018

Re: [Pharo-users] How to LAN feature

by JuliÃ¡n Maestri

You could also publish on a zeroconf service (Bonjour/Avahi) https://en.wikipedia.org/wiki/Zero-configuration_networking On 8 May 2018 at 11:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no > wrote: > Ben Coman wrote > > mDNS would be an interesting facility to include in the main Pharo > release > > image, > > perhaps making it very easy for our "live" systems to locate each other > on > > a local network without external infrastructure. > > > > > > cheers -ben > > mDNS and SSDP are pretty much interchangeable, implementation wise ;) > > The main problem; most computers these days come with multiple networking > interfaces, and are usually connected to separate subnets. > So when you connect a socket to the broadcast address, you have no idea > which interface it will actually send the request over, and whether you can > communicate with other entities is sort if hit or miss. > > Pharos netresolver is blissfully unaware/unable to tell you which > interfaces > are available, > most of the work in the SSDP implementation went into trying to detect all > the different ones (impossible without the added networking prims, and > still > unreliable whether it will find the correct ones with...), and bind:'ing a > socket to each specifically. > > IIRC, the default server/client instantiation exemplified in class comments > now simply binds to 0:0:0:0 and hopes the default interface is what you > wanted, SSDPServer>>onAllInterfacesOfferServiceType:atLocation: runs > through the more extensive setup. > > Cheers, > Henry > > P.S. In second place; a listener loop capable of error handling a spotty > wifi connection/machine sleep cycles... > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 9, 2018

Re: Package extension. Adding instance variables to classes

by Alidra Abdelghani

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 <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

May 9, 2018

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

by Richard O'Keefe

First, my message was *defending* most of the short names that someone else was attacking. For the record, I am *far* more worried about the fragility of typical Smalltalk code than I am about method names, which are generally pretty good. Second, the criterion was implicit but fairly clear: if an abbreviation of any kind is sufficiently common that someone who wants the semantics will recognise the identifier, use it. "ulp" is MORE familiar to people who need it than "unitOfLeastPrecision" (spit), so it is a better name. In the same way, HTTP is a *better* name than HyperTextWhatever (amongst other things because the word is Hypertext, so HyperText violates a Smalltalk style rule that says internal capitals at *word* boundaries) because it is familiar and takes less effort to recognise than the fully spelled out thing. Third, the rule as always is "intention-revealing names". (Another Smalltalk style rule that I did not invent.) #onDNU:do: is a confusing name because when I saw it I expected the first argument to be a signalled exception, not a selector. There is nothing wrong with the DNU bit; if you know you want to catch a DNU you are probably familiar with "DNU" (and don't want to fuss with whether it means Does Not Understand or Did Not Understand). As a particular example from the list, #log or #logarithm are both ambiguous, while #ln is NOT ambiguous (in the context of numbers), making it a better name, Finally, the significant point was not where I live (about 1/1600 of the world's population live here) but when I went to primary school, which was somewhat more than 50 years ago. Twenty years before that, children learned how to calculate square roots by hand. (Cue Four Yorkshiremen. :-)) On 8 May 2018 at 20:00, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > #gcd: > #lcm: > > These come from elementary (primary school in my day) mathematics. They > are the standard names. > > > You mean where you live? That excludes 90% and more of the world. So when > is a abbreviation ok again? > > Norbert > >

May 9, 2018

Re: [Pharo-users] Personal Programming onPharo

by H. Hirzel

On 5/6/18, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > 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. Hello Tryge Good to see that you reconsider to use Smalltalk in 2018, this time Pharo. Am I assuming correctly that you want to continue to work on your IDE which the supports the DCI (Data-Context-Interaction) programming style [1]? The IDE was called "BabyIDE" [2]. In 2015 you wrote to the Squeak mailing list that you are abandoning Squeak (Squeak 3.8, 4.5 or 4.6 at that time and Smalltalk as a whole) in favour of JavaScript, a mainstream language. That you now at least reconsider to use Smalltalk (Pharo) is an interesting result as it reinforces the idea that doing things the Smalltalk way is more promising than going for JavaScript directly [6]. As for loading the BabyIDE into Squeak: It is noteworthy that after 10 years (done around Squeak version 3.8) of maintaining a fork the Squeakland (Etoys) image has been merged back into Squeak 6.0a trunk. [5] I could actually load some of your tools last year into Squeak 6.0a with very modest fixes last year. [2]. It seems that splitting your IDE enhancements into different parts which can be treated independently will probably help. And in addition helpful would be IMHO to write HOW you construct these tools and WHY you do it. These will help people to maintain your code even if the underlying system changes. It seems worthwhile to try out how it goes with the most recent Squeak version, Squeak 6.0a trunk [8]. Another option is to wait a few months and look for the bootstrap version of Pharo 7. All the code is in readable format on github and various types of image files may be built build from it [7]. And the third option is to check out if Cuis (the third Smalltalk which runs on the OpenSmalltalk [3] VM) suits your needs. [4] Kind regards Hannes Hirzel ------------------- [1] Data-Context-Interaction http://wiki.squeak.org/squeak/6048 [2] BabySRE http://wiki.squeak.org/squeak/2550 [3] http://www.opensmalltalk.org/ [4] Cuis Smalltalk https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev ; there is a Cuis mailing list. [5] Etoys in 2017 http://wiki.squeak.org/squeak/6531 [6] Of course these days JavaScript cannot be avoided. But it is preferable to generate it with a Smalltalk tool. [7] The file format used in Pharo 7 is called Tonel (no exclamation marks!) [8] Squeak 6.0a trunk download http://files.squeak.org/6.0alpha/

May 8, 2018