- Pharo-users - lists.pharo.org

Re: [Pharo-users] Where do we go now ?
by Esteban Lorenzano April 15, 2018

April 15, 2018

Hi, > On 13 Apr 2018, at 07:53, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Benoit St-Jean <bstjean(a)yahoo.com> > Subject: Where do we go now ? > Date: 13 April 2018 at 07:53:46 CEST > To: pharo-users(a)lists.pharo.org > Reply-To: Benoit St-Jean <bstjean(a)yahoo.com> > > > Hello guys, > > Just a quick word to get some things straight because, quite frankly, I really don't know where we're heading. > > When Pharo started, the goal was to depart from Squeak and do a *major clean up* of all the code, especially Morphic. The promise of a new, clean & lean Smalltalk attracted a lot of people. And then... > > I'm looking at the Pharo 7.0 image right now and I just don't get where we're heading. Every Pharo release gets bigger, and bigger, and bigger. I don't mind the environment getting bigger if it adds functionalities or new tools but that's not quite the case here. LOTS of stuff is just duplicated. > > Do we really need 2 code completion classes (NECController, NOCController) ? Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 compilers (OpalCompiler, Compiler) ? Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? Do we really need 2 inspectors (GTInspector, EyeInspector) ? Do we really need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera. I could go on, and on, and onâ¦ Pharo 7.0 is a development version. Before is releases most duplicated things you mention here will be gone: - Nautilus - Compiler - EyeInspector Workspace could be gone but we need a fallback in case the other more potent tools fail. Schedulers are still necessary. > > Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes. Can you see a trend? > > Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings. Can you see a trend? > > Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 alpha has a 47.97 MB image. Can you see a trend? Pharo 5.1 didnât have : - GTTools - Iceberg - Epicea - and many others. > > Add to that the fact that Pharo is a nightmare when you want to port code. Just with the 7.0 release, 61 classes will be deprecated (and lots more to come if you search for the string "deprecated" into the code, most of the time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess classes). If you do not want we to remove classes, how do you want we to go âsmaller" and cleaner? > You have code that deals with sockets, should you use the old Socket classes or convert everything to Zodiac? And why do we keep both "frameworks" in the image ? Pharo hasn't been backward compatible with "old socket classes" a looooooong time ago anyway! Zodiac relies on Sockets, there is not duplication there. > You have code that deals with dependencies, should you use the old dependents mechanism or convert everything to announcements? you got me here. but removing takes timeâ¦ you are free to contribute with fixes :) > > UI speaking, what framework should anyone use ? Athens? Something else? yes, I think Athens should not be part of the image but a loadable package. > > You have code that deals with streams, should you use the old stream classes or convert everything to Zinc ? And why do we keep both "frameworks" in the image ? Pharo hasn't been backward compatible with the old stream classes a looooooong time ago anyway! again, you are mixing pearls and apples here. (and btw, there was a HUGE refactor of streams on P7) > So what's the plan? For instance, should I keep using the Nautilus Browser or I should switch to the Calypso browser and get used to it because Nautilus will be deprecated? Or should I just don't care because a third system browser will be added in Pharo 8 just because "it's cool, let's add this one too!â ? The plan is continue improving slowly but steadyâ¦ things takes time. > Couldn't we just decide on what's "official" and what's a goodie or an external optional tool/package/framework the same way all other Smalltalks do? If you say Calypso is the official & supported browser, fine! Then just get Nautilus out of the image, create a nice loadable package for it and if someone prefers Nautilus, they'll just have to load it into the image, the same way VW has a gazillion optional tools/packages/frameworks you can load from a parcel! > > Whenever I get asked a simple question by a newbie like "Oh, which system browser should I use?", quite frankly, I don't know what to answer. Did we include Calypso to deprecate Nautilus later? Is Calypso just a proof of concept? Is it just an optional tool? What about all those delay schedulers? You should read this list with more attention. We told at least 10 times Nautilus is going to be removed. We told it in presentations. We told it in tech talks. I donât know how else we could tell it. Maybe a HUGE banner in our site? âHEY YOU, READER: NAUTILUS WILL BE REMOVED!" > "I loaded this code from SqueakSource and it just doesn't work". Should I help the guy to fix it or just tell him to convert all the code to the corresponding framework in Pharo? if there is a corresponding framework yes. Problem is that people tends to believe a package from squeaksource not loading in P7 is our fault and not the responsibility of the package maintainer (or the one wanting to use it). > > Perhaps a little bit of clarity and details about what's coming and what's the plan would be beneficial to a lot of us. Perhaps a little bit of reading? We told it, several times. You cannot take an alpha version and expect production quality. And you cannot expect that things happens magically: engineering takes a lot of time and efforts and we do our best with the resources we have as a community. This is an open source project. With perks and no so muchâ¦ but the way to change things is contributing. And just to be clear: The goal of Pharo was never to be SMALL. The goal is to do a Smalltalk that is at the same time: - Clean (That DOES NOT MEANS SMALL!) - Modern - Fitting for business Iâm sorry for counter-rant your rant, but while there are somethings were you are right, I find the tone of your commentary not very constructive. cheers! Esteban > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >

3 9

[SmalltalkCI] loading tonel dependencies?
by Bernardo Ezequiel Contreras April 15, 2018

April 15, 2018

peter, are you sure that dependencies of a project in tonel format can be loaded? earley-parser -> linked-list see https://travis-ci.org/vonbecmann/earley-parser/builds/365332549 thanks in advance -- Bernardo E.C. Sent from a cheap desktop computer in South America.

3 6

Going to give 4 days lectures at University of Skikda in Algeria
by Stephane Ducasse April 15, 2018

April 15, 2018

Hi Just to let you know that I will be giving a Pharo lectures and advanced design at the University of Skikda in Algeria to Master and PhD students. Thanks Abdelghani Alidra for the organisation. Stef

1 0

QRCode - A thank you note
by Sven Van Caekenberghe April 15, 2018

April 15, 2018

Hi, Given that the mailing lists are often used to ask questions when we get in trouble, report bugs and other issues, conduct public discussion between strong headed individuals, we quickly forget what a fantastic platform Pharo is. Last month I implemented a rough MVP-style ticket sales platform that was successfully used to sell and validate at the entrance, about 1000 digital, online tickets for a relatively large 3000+ attendance event (a party). It took only a couple of days to build and deploy, and it was a lot of fun - it was even done in 'unstable' Pharo 7. Early on I decided to identify each individual ticket by a unique URL. For easier presentation and scanning purposes, I encoded that URL in a QR code. Although I am grateful for the whole Pharo ecosystem (including Seaside), we all build on top of other people's work, I was especially happy with Jochen Rick's QRCode package (http://smalltalkhub.com/#!/~JochenRick/QRCode/) This is such a great piece of work ! It worked right out of the box in Pharo 7 (even though it is from 2013/2014), was well designed, easy to figure out, was well documented, had unit tests. I can't say anything bad about it, it is as close to perfect as I have ever seen. So: thanks Jochen, you made my day ! Here is how a ticket generates its own QR code: T123Ticket>>#asQRCode ^ self url asString asQRCode formWithQuietZone magnifyBy: 5 Just beautiful. It is also easy (for a non-graphics, non-UI person like me) to combine the QR code with some text: T123Ticket >>#asQRCodeWithText | form font | form := Form extent: 535 @ 185 depth: 1. font := LogicalFont familyName: 'Bitmap DejaVu Sans' pointSize: 14. self asQRCode displayOn: form at: 0 @ 0. form getCanvas drawString: self url asString at: 180 @ 20 font: font color: Color black; drawString: self id36, ' - ', ticketId asString at: 180 @ 45 font: font color: Color black; drawString: (name ifNil: [ 'N.N' ]) at: 180 @ 90 font: font color: Color black; drawString: (email ifNil: [ '@' ]) at: 180 @ 115 font: font color: Color black; drawString: (phone ifNil: [ '+' ]) at: 180 @ 140 font: font color: Color black. ^ form Next we combine this with a nice template designed by a graphics artist: T123Ticket >>#asQRCodeWithTextInTemplate | templateFile form | templateFile := 'tickets123-template-{1}.jpg' format: { self event id }. form := PluginBasedJPEGReadWriter formFromFileNamed: templateFile. self asQRCodeWithText displayOn: form at: 20@540. ^ form And finally, the ticket form is encoded as a JPEG (to be mailed and so on): T123Ticket >>#asJPEGBytes ^ ByteArray streamContents: [ :out | PluginBasedJPEGReadWriter putForm: self asQRCodeWithTextInTemplate onStream: out ] I also found GT Inspector very handy (again) in doing back end work (managing payments and other administration), especially the ability to use Spotter on a collection open in an inspector. Anyway, I know many of you have similar happy experiences, I just wanted to share (one of) mine. Thanks Jochen, thanks everyone. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

5 4

[OT] Reminder about quoting/top-posting
by Esteban A. Maringolo April 14, 2018

April 14, 2018

Hi, Please apologize the digression, but these days there were a lot of interesting threads with LOTS of replies from different members. Can I ask for more trimming of the quoted text and/or emails replied to? The follow up of some replies was hard because they were nested deep into a chain of previous quotes, or in the case of top-posters, they keep the replied emails accumulating in the bottom, causing a scroll down to find nothing else was there. Thanks! -- Esteban A. Maringolo

2 1

IDEA: I will record an Iceberg cast (an "Icecast" ; ) ) every tuesday
by Esteban Lorenzano April 14, 2018

April 14, 2018

hi, The idea is to show a small example of something and to answer questions. First âIcecast" will be next Tuesday. You can send your questions in the iceberg channel or in list. cheers, Esteban ps: Is âevery tuesdayâ until I run out of things to show or time ;)

4 3

[TechTalk] April 12: GIT with Iceberg
by Marcus Denker April 13, 2018

April 13, 2018

Hi, There next TechTalk will be April 12: GIT with Iceberg https://association.pharo.org/event-2797068 A regular chat about Pharo. Happens on Discord. The Tech talks are open to both members and non-members! Topic: GIT with Iceberg. Demo of improved UI We will send an information to all subscribers some hours before the talk starts.

6 7

Re: [Pharo-users] Where do we go now ?
by Ben Coman April 13, 2018

April 13, 2018

On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Just a quick word to get some things straight because, quite frankly, I > really don't know where we're heading. > > Do we really need 8 delay schedulers (DelayMicrosecondScheduler, > DelayMillisecondScheduler, DelayNullScheduler, > DelayExperimentalSpinScheduler, DelaySpinScheduler, > DelayTicklessScheduler, DelayExperimentalCourageousScheduler, > DelayExperimentalSemaphoreScheduler) ? > This should have been cleaned up a while ago. Thanks for the bump. I'll get to it. However note, that half of those have not more than two methods, so are not contributing much to the size of the Image. > Perhaps a little bit of clarity and details about what's coming and what's > the plan would be beneficial to a lot of us. > I guess you are looking for... https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… cheers -ben

5 5

Re: [Pharo-users] Where do we go now ?
by phil＠highoctane.be April 13, 2018

April 13, 2018

It is true that there are many things in there. New tools have to be finished before the old ones can be removed (there was a time where refactorings were not in Calypso). But for a real project, one is settling for a version and a toolset. I am not really keen to migrate Pharo projects from one version to another and some deprecations seems rather gratuitous sometimes. The world also moves forward and it shows in the image. I think that Iceberg has swallowed a lot of bandwidth and as a result other elements are in need of more love. Pharo7 is unreleased yet. Some say something is great by version 10. 3 versions to go. I consider Pharo 7 as a great piece of kit but unusable for my current work. There are many new things to learn in there. When is too much too much? Also, simplifications are breaking things in unexpected ways (like the #atEnd thing). I am glad 6.1 gets backports and new releases for sure. Phil On Fri, Apr 13, 2018, 07:53 Benoit St-Jean via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello guys, > > Just a quick word to get some things straight because, quite frankly, I > really don't know where we're heading. > > When Pharo started, the goal was to depart from Squeak and do a *major > clean up* of all the code, especially Morphic. The promise of a new, clean > & lean Smalltalk attracted a lot of people. And then... > > I'm looking at the Pharo 7.0 image right now and I just don't get where > we're heading. Every Pharo release gets bigger, and bigger, and bigger. I > don't mind the environment getting bigger if it adds functionalities or new > tools but that's not quite the case here. LOTS of stuff is just duplicated. > > Do we really need 2 code completion classes (NECController, NOCController) > ? Do we really need 2 system browsers (Nautilus, Calypso)? Do we really > need 2 compilers (OpalCompiler, Compiler) ? Do we really need 8 delay > schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, > DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, > DelayTicklessScheduler, DelayExperimentalCourageousScheduler, > DelayExperimentalSemaphoreScheduler) ? Do we really need 2 inspectors > (GTInspector, EyeInspector) ? Do we really need 2 workspaces > (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera. I could go > on, and on, and on... > > Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha > has 7612 classes. Can you see a trend? > > Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference > settings. Pharo 7.0 alpha has 662 preference settings. Can you see a trend? > > Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 > alpha has a 47.97 MB image. Can you see a trend? > > Add to that the fact that Pharo is a nightmare when you want to port > code. Just with the 7.0 release, 61 classes will be deprecated (and lots > more to come if you search for the string "deprecated" into the code, most > of the time hidden in the comments of the > soon-to-be-deprecated-in-Pharo-8-I-guess classes). > > You have code that deals with sockets, should you use the old Socket > classes or convert everything to Zodiac? And why do we keep both > "frameworks" in the image ? Pharo hasn't been backward compatible with > "old socket classes" a looooooong time ago anyway! > > You have code that deals with dependencies, should you use the old > dependents mechanism or convert everything to announcements? > > UI speaking, what framework should anyone use ? Athens? Something else? > > You have code that deals with streams, should you use the old stream > classes or convert everything to Zinc ? And why do we keep both > "frameworks" in the image ? Pharo hasn't been backward compatible with the > old stream classes a looooooong time ago anyway! > > So what's the plan? For instance, should I keep using the Nautilus > Browser or I should switch to the Calypso browser and get used to it > because Nautilus will be deprecated? Or should I just don't care because a > third system browser will be added in Pharo 8 just because "it's cool, > let's add this one too!" ? > > Couldn't we just decide on what's "official" and what's a goodie or an > external optional tool/package/framework the same way all other Smalltalks > do? If you say Calypso is the official & supported browser, fine! Then > just get Nautilus out of the image, create a nice loadable package for it > and if someone prefers Nautilus, they'll just have to load it into the > image, the same way VW has a gazillion optional tools/packages/frameworks > you can load from a parcel! > > Whenever I get asked a simple question by a newbie like "Oh, which system > browser should I use?", quite frankly, I don't know what to answer. Did we > include Calypso to deprecate Nautilus later? Is Calypso just a proof of > concept? Is it just an optional tool? What about all those delay > schedulers? > > "I loaded this code from SqueakSource and it just doesn't work". Should I > help the guy to fix it or just tell him to convert all the code to the > corresponding framework in Pharo? > > Perhaps a little bit of clarity and details about what's coming and what's > the plan would be beneficial to a lot of us. > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >

3 3

Re: [Pharo-users] Where do we go now ?
by Marcus Denker April 13, 2018

April 13, 2018

> On 13 Apr 2018, at 11:26, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Benoit St-Jean <bstjean(a)yahoo.com> > Subject: Re: [Pharo-users] Where do we go now ? > Date: 13 April 2018 at 11:26:09 CEST > To: Esteban Lorenzano <estebanlm(a)gmail.com> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Reply-To: Benoit St-Jean <bstjean(a)yahoo.com> > > > BTW, why put an .exe installer for Windows available when it crashes right from the start? It just doesn't work at all. Period. For everyone. > > And I thought looking for senders of a method was something we mastered a long time ago, like starting with Smalltalk-76. Am I supposed to assume that everything, even basic functionalities, are all broken because it's labeled "alphaâ ? We have already a issue tracker entry with a description of a fix: https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-wrong-behaviour-t… <https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-wrong-behaviour-t…> TODO: turn that description into code and make a Pull Request. Marcus

2 1