- Pharo-users - lists.pharo.org

Re: [Pharo-users] Showcasing Pharo, Roassal and Grafoscopio at re:publica 2018

by Offray Vladimir Luna CÃ¡rdenas

Hi Phil, On 06/05/18 07:30, phil(a)highoctane.be wrote: > Hi Offray, > > On Sun, May 6, 2018 at 1:47 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi Phil, > > > On 27/04/18 03:02, phil(a)highoctane.be <mailto:phil@highoctane.be> > wrote: >> >> On Thu, Apr 26, 2018 at 3:57 PM, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> >> Hi, >> >> I will be showcasing Pharo, Roassal and Grafoscopio at >> re:publica 2018, >> next week. As you may know, re:publica[2] is one of the most >> important >> and visible media & digital culture conventions in Europe and >> is a good >> scenario for the Pharo community.Â You can find details about my >> participation at [1] >> >> >> The "on how to use the GrafoscopioÂ /pocket infrastructure/Â for >> data activism and digital citizenshipÂ " soundbite just blew my mind. >> >> "Pocket Infrastructure" hits the nail on the head for sure.Â >> I positively love that angle.Â >> Compared to python, node, etc, there is much less fuss to get >> started and it allows to focus on the data narrative right away. >> >> I regularly make folders in my Dropbox where I throw a pharo vm >> and a pharo image I work on, saved >> usingÂ https://github.com/Pharophile/HOImageSaver >> <https://github.com/Pharophile/HOImageSaver> so that I can always >> go back in time easily (saved me more than once!). This very >> handy for working on machine A, and resuming work on machine B, >> or C etc. >> And is indeed "Pocket Infrastructure". >> > > I think that pocket infrastructures are a powerful concept for > inclusion and participation, specially in the times of fancy > exclusionary "Big Data" and "Artificial Intelligence" buzzwords > and discourses that don't take into account who becomes data of > who, who will have the access, storage and processing capability > in those forecast futures. In contrast Pocket Infrastructures are > inclusive by default, being self-contained, simple and working > well in on/off line contexts. > > > As I am busy in that space with Hadoop / TensorFlow / ..., yes there > is a tendency to have kind of "high priests of data" showing up. > This is isolating the common folk instead of empowering them. I am > fighting that tendency in the projects because the technology can be > approachable. > Well, now we are two of us. In general the Smalltalk tradition of fighting against incidental complexity and the needs of broader communities of being empowered by code+data will bring more people interested that is already active on those concerns. > > Pharo, in the live coding environment front and Fossil, in the > DVCS front, work pretty well for that working definition of Pocket > Infrastructures.Â Is impressive that just under 50 Mb anyone can > have a Jupyter+GitHub alike environment for data storytelling, > visualization and reproducible research that just run in their > pockets and low end machines (and of course, big server and > anything in between). We tried before with IPython notebook and > other more complex stuff and we were dealing with external > complexities instead of going right into story telling + coding + > data viz. Of course, Jupyter and GitHub are a lot more popular > that Grafoscopio + Fossil, but they're also traveling the most > traverse path, while I think that a lot of valuable innovation > comes, by definition, from the margins and that can give Pharo > ecosystem an advantage point over other more popular approaches, > as practice have demonstrated time and again. > > > As a Jupyter user, yes, I can relate. Jupyter is easy once you have it > installed (like installing Anaconda distribution and typing "jupyter > notebook" on the command line. But that is already a high bar for non > technical people. As a former regular user of IPython Notebook (before it morphed to Jupyter), my issues go beyond installation and are more related with moldability and the possibility to adapt the tool taking into account its users and contexts, hopefully by such users in such context. In the end, each Jupyter notebooks provides a RELP "linear metaphor" for documents and in that case you have two options, which I don't think are the best for exploratory computing, start to split your document into several notebooks (losing panoramic view) or ending with long scrolls, losing detail[1][2]. The best, for such exploratory documents, would be to combine the outliner metaphor of Leo/OrgMode with the interactivity of IPython[3], but in that endeavor you end fighting with a lot of incidental complexity that Pharo doesn't have[4], because of the way liveness, simplicity and adaptability are embedded into the tool and culture. In that way, Grafoscopio notebooks can contain simple notes or full books [4a][4b] [1] http://mutabit.com/repos.fossil/piamed/artifact/d8762d656bcbf480 [2] http://mutabit.com/repos.fossil/piamed/doc/tip/linea-base-aras-iecas.html [3] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexi… [4] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… [4a] http://mutabit.com/repos.fossil/grafoscopio/dir?ci=28ec1bf0c1ab3c71&name=Do… [4b] http://mutabit.com/repos.fossil/mapeda/ Even with JupyterLab and the phospore.js[5] that improves on extensibility, you still need to deal with a lot of friction in the development experience.Â I would say that Grafoscopio and JupyterLab are following inverse paths (and in that way one is the future of the other): Grafoscopio started from the Pharo Interactive Development Environment and is trying to bring interactive notebooks documentation capabilities to such environment, while Jupyter started with interactive notebooks and is trying to become a full IDE [7][7a]. Grafoscopio will learn a lot by increasing languages support, and JupyterLab is dealing with development needs and customized workflows. [5] https://github.com/jupyterlab/jupyterlab [6] https://medium.com/@brianray_7981/jupyterlab-first-impressions-e6d70d8a175d [7] https://youtu.be/Ejh0ftSjk6g?t=253 [7a] https://youtu.be/Ejh0ftSjk6g?t=329 > > I am very interested in Grafoscopio to work out proof of concepts in > Pharo, so that I can have a nice narrative structure. > Coupled with gtExample and specific inspector presentations, this is a > terrific thing. I usually start from a notebook. There I put notes, problem descriptions, future working playgrounds where I launch the debugger. Is a really good experience and with your your proposed bug fix for the annoying UI bug is even getting better. It was the kind of experience I would like to have with Jupyter+Leo+Python, but now empowered by Pharo :-). Let me know how it works for you. > > My current project involved a Glorp component and I'd like to showcase > transactions within a Grafoscopio notebook. > > I'll tell you how it goes :-) I'm really curious. Keep us informed. :-). > > Fossil is indeed a great vehicle for code and assets. Fossil and > SQLite, great stuff. > > Phil Yes, good combination, even for the released open data of the biggest leak in journalism history, the Panama Papers, SQLite+Fossil+Pharo[8] worked pretty well. I think that there is a lot of unseen potential in such simple but powerful systems in all these places where people is just using popular "big data" stuff and we need to think in the "last mile" infrastructure to connect people with data. There the Pocket Infrastructures have a lot to offer and we can pioneer the path. [8] http://mutabit.com/offray/blog/en/entry/panama-papers-1 Cheers, Offray

May 8, 2018

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

by Norbert Hartl

> 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 8, 2018

Re: [Pharo-users] Personal Programming onPharo

by Norbert Hartl

> Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no>: > > Norbert, > I stand corrected because I have not followed the mainstream languages as well as I probably should. Thank you for your candid answer, it clearly outlines what I can and cannot expect from Pharo and any other ST project. > Ok, I didnât want to sound too harsh but for me there is no benefit in telling something which is not true. And as a member of such community you get sometimes allergic to things that sound negative because that happens far too often. What I said about not upgrading is the thing we suffer from. While you find it that squeak has moved too fast we consider it that it didnât move enough. That is why a lot of the sub-systems need to be replaced and that causes instability. For me the stability is outstanding if I look what is changed all the time. But that is another perspective. For a user of the platform it is simply annoying. We know that but not moving is not option for us so thatâs why I say that frankly. And sadly the only thing that can compensate side-effects due to changes is to put a lot of man power onto it. The programming/software world has not much too say about how change should be done. > 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. > We are onto it. If you look at the way we can work, model inspect etc. it is still an wonderful tool. And it is getting better every day while breaking things here and there. I can only repeat what I said earlier. The part of your IDE that copes with language details might break the least because that is the most stable part of the pharo system. But all of the UI system will be replaced in a non-compatible way. Morphic is great but it has grown into a hugly monster. And in this century you might not survive having bitmap based graphics. It might still make perfect sense to you. Because there will be some effort put into the ability to load it into pharo at wish. But I would suspect it wonât change much from there. But it cannot stay because to old-fashioned and not changeable. Maybe it is missing in the Dynabook vision that is not likely that children born after 2000 still wonât too use a graphical interface designed in the 70s being unchanged. But Iâm not sure if the Dynabook vision was supposed to be realized some day or just a vehicle to complain about everything. > Again, thank you for your answers. They have given invaluable contributions to my thinking. I would have liked to say something more encouraging but â¦. Norbert > --Trygve. > > > On 07.05.2018 14:14, Norbert Hartl wrote: >> >>> Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no <mailto:trygver@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

May 8, 2018

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

by Esteban Lorenzano

Why to stop there? We could also change our class prefixes. Why to put HTTPSomething when we could put HyperTextTransferProtocolSomething ? :) cheers! Esteban > On 8 May 2018, at 05:15, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > #onDNU:do: > > That one's not so good. Not so much because of the acronym, but because it's unclear about what the argument is. A better name would be > #onUndefinedSelector:do: > > #gcd: > #lcm: > > > These come from elementary (primary school in my day) mathematics. They are the standard names. > > #rem: > #quo: > > These are not acronyms. They are more intelligible than // and \\. But yes, > {floor,ceiling,rounded,truncated}{Quotient,Remainder}: > would be clearer. #quo: and #rem: are sufficiently rare > that it wouldn't hurt if they were longer. > BUT they are in the Blue Book and in the standard. > > #ulp > > This is indeed an acronym, and it's probably obscure > to many programmers. But practically every paper I have read about floating-point issues uses this; it is > a technical term of art. Spelling it out as #unitOfLeastPrecision as VisualWorks does, and as > both Squeak and Pharo do in their comments, is the > reverse of helpful, because that is not what 'ulp' > stands for. It's Unit in the Last Place. Now there IS > a case for giving #ulp a long name, but that's not it. > There are some subtleties in the definition. > http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf <http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf> > lists, by my count, five definitions. The first is obsolete, > The fifth is a hybrid of some of the others. It turns out > that I knew less about ULPs than I thought I did. > > #ln > > #NaperianLogarithm won't help anyone who doesn't > know who Napier was or what a logarithm is. I > suppose #logarithmToBaseE might work. > > #theta > > That is not an acronym. It is spelled out in full. > Using Greek letters for arbitrary angles goes back > roughly two thousand years. To the Greeks, in fact. > Blame them, not Pharo. > > #r > #g > #b > > I can think of at least two meanings for each of these, so granted. > > > > Click here to Reply or Forward > 0.2 GB (1%) of 15 > > > On 8 May 2018 at 04:57, webwarrior <reg(a)webwarrior.ws <mailto:reg@webwarrior.ws>> wrote: > 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 <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > >

May 8, 2018

Re: [Pharo-users] How to LAN feature

by CÃ©drick BÃ©ler

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. > Le 8 mai 2018 Ã 08:28, Henrik Sperre Johansen <henrik.s.johansen(a)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 > > No, but it does involve setting certain options on the socket, etc. > You could check if http://smalltalkhub.com/#!/~henriksp/SSDP is > appropriate/works for you. > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

May 8, 2018

Re: [Pharo-users] Personal Programming onPharo

by Trygve Reenskaug

Norbert, I stand corrected because I have not followed the mainstream languages as well as I probably should. Thank you for your candid answer, it clearly outlines what I can and cannot expect from Pharo and any other ST project. 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. Again, thank you for your answers. They have given invaluable contributions to my thinking. --Trygve. On 07.05.2018 14:14, Norbert Hartl wrote: > >> Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug <trygver(a)ifi.uio.no >> <mailto:trygver@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 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 8, 2018

Re: [Pharo-users] How to LAN feature

by Henrik Sperre Johansen

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 No, but it does involve setting certain options on the socket, etc. You could check if http://smalltalkhub.com/#!/~henriksp/SSDP is appropriate/works for you. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 8, 2018

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

by Richard O'Keefe

#onDNU:do: That one's not so good. Not so much because of the acronym, but because it's unclear about what the argument is. A better name would be #onUndefinedSelector:do: #gcd: #lcm: These come from elementary (primary school in my day) mathematics. They are the standard names. #rem: #quo: These are not acronyms. They are more intelligible than // and \\. But yes, {floor,ceiling,rounded,truncated}{Quotient,Remainder}: would be clearer. #quo: and #rem: are sufficiently rare that it wouldn't hurt if they were longer. BUT they are in the Blue Book and in the standard. #ulp This is indeed an acronym, and it's probably obscure to many programmers. But practically every paper I have read about floating-point issues uses this; it is a technical term of art. Spelling it out as #unitOfLeastPrecision as VisualWorks does, and as both Squeak and Pharo do in their comments, is the reverse of helpful, because that is not what 'ulp' stands for. It's Unit in the Last Place. Now there IS a case for giving #ulp a long name, but that's not it. There are some subtleties in the definition. http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf lists, by my count, five definitions. The first is obsolete, The fifth is a hybrid of some of the others. It turns out that I knew less about ULPs than I thought I did. #ln #NaperianLogarithm won't help anyone who doesn't know who Napier was or what a logarithm is. I suppose #logarithmToBaseE might work. #theta That is not an acronym. It is spelled out in full. Using Greek letters for arbitrary angles goes back roughly two thousand years. To the Greeks, in fact. Blame them, not Pharo. #r #g #b I can think of at least two meanings for each of these, so granted. Click here to Reply or Forward 0.2 GB (1%) of 15 On 8 May 2018 at 04:57, webwarrior <reg(a)webwarrior.ws> wrote: > 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 8, 2018

How to pretty print a dynamic array

by Davide Varvello

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? Davide -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 7, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

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

May 7, 2018