- Pharo-users - lists.pharo.org

IDEA: I will record an Iceberg cast (an "Icecast" ; ) ) every tuesday

by Esteban Lorenzano

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

April 14, 2018

Re: [Pharo-users] QRCode - A thank you note

by Stephane Ducasse

Thanks Sven Yes QRCode is nice. Once I wanted to see if I could produce a pdf version for artefact and when I read the spec I stopped. And yes sometimes the atmosphere of this mailing-list is telling me to stay away from it. So thanks for your nice mail and energy. And thanks for your super cool libraries. Today we had a good laugh with Santiago because we will build a smart contracts corpus and use STON to save them (too easy ;P) Stef On Fri, Apr 13, 2018 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 > > > >

April 13, 2018

QRCode - A thank you note

by Sven Van Caekenberghe

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

April 13, 2018

[OT] Reminder about quoting/top-posting

by Esteban A. Maringolo

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

April 13, 2018

Re: [Pharo-users] Where do we go now ?

by Richard Sargent

On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Sometime Pharo frustrate me a lot, I felt it too in the message from > Benoit, in the other hand its community is very kind and always helpful. So > it is not about blaming people. > > In my opinion, there are too much things pushed at the same time in Pharo. > You can't push too much things into the box, then when people complain > about it to be overfull and bugged request them to fix it, I don't think it > can work that way, at this scale of changes. In the other, this is not > really what happen here, I very likely exaggerate this trait but you get > the idea. > > For example, I developed DrGeo for several years on P3. Why sticking to > P3? It gave me the opportunity to fine craft DrGeo to be stable and > predictable in the way it behaves to its end users, and a lot of releases > occurred. When I started to look at porting to newer image last June, I > realized DrGeo will become unstable and oversized, so can of turning from > A+ grade to a D- grade, just by the magic of porting it. My plan was to > port it during the summer to get it ready end of August to deploy in local > schools, it does not happen. And I can write it: it is s-u-p-e-r > f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I don't know, I am a > casual developer, but it makes developing well crafted and reliable Pharo > application a bit expensive to my taste. To such a scale that I started to > evaluate alternative to Pharo as the underneath system, idea I finally gave > up after several weeks of evaluations. All in all I still have this felling > Pharo is not developer friendly, I fell DrGeo is not secure there. See when > porting to newer image, I end up using P7-32bits alpha on Linux because it > was the most comfortable situation comparing to P5/P6/P6.1, is it not > strange? > > In the other hand this struggle occurs at image change. Ok, may be it is a > pattern specific to Smalltalk. Is it the case with commercial Smalltalk > vendors? Hi Hilaire, Thanks for articulating this. I've been mostly watching Pharo rather than using it, so I haven't been affected by the changes between versions. With respect to commercial products versus Pharo *at the present time*, I think we have different driving forces shaping things. In my opinion, VA Smalltalk has been the one most strongly driven by the importance of backward compatibility and ease of migration to a new version. VisualWorks has been pretty good about providing a path forward with minimal pain, although the more major version numbers difference, the harder it is to transition. Likewise, GemStone/S has a strong emphasis on keeping our customers' existing applications running with minimal changes. That being said, I have no doubt that the earliest versions of all these products had substantial incompatibilities between versions. I am also pretty sure there is a threshold beyond which the adoption of Pharo in business applications will compel Pharo development to facilitate migration to newer versions and to better maintain API compatibility. [And that may be simply because, as more businesses rely on Pharo, they will be financially supporting its development.] A second consideration is the size of the product teams (measured in full-time staffing). I think the commercial products had a much larger staffing in their early days than Pharo has even now. And I think the consequence of that is that the changes between v1 and v2 or between v2 and v3 of the commercial products *may* have been comparable to the differences between Pharo v(n) and v(n+3). Richard > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

April 13, 2018

Re: [Pharo-users] Where do we go now ?

by Stephane Ducasse

We know where we go (we have a roadmap) and this is always the same and we are getting there. Tell me one smalltalk that is bootstrapped. And only bad OOP programmers count number of classes!!!! Now I will not reply to provocation. So I just trashed this thread because it goes nowhere. Sorry constructivism criticisms from people that already commited and helped is something positive. But in this thread I only read in inverse and I will let you with it and keep my good energy for it . Stef On Fri, Apr 13, 2018 at 7:53 AM, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: pharo-users(a)lists.pharo.org > Cc: > Bcc: > Date: Fri, 13 Apr 2018 05:53:46 +0000 (UTC) > Subject: Where do we go now ? > 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) >

April 13, 2018

Re: [Pharo-users] Where do we go now ?

by Hilaire

Sometime Pharo frustrate me a lot, I felt it too in the message from Benoit, in the other hand its community is very kind and always helpful. So it is not about blaming people. In my opinion, there are too much things pushed at the same time in Pharo. You can't push too much things into the box, then when people complain about it to be overfull and bugged request them to fix it, I don't think it can work that way, at this scale of changes. In the other, this is not really what happen here, I very likely exaggerate this trait but you get the idea. For example, I developed DrGeo for several years on P3. Why sticking to P3? It gave me the opportunity to fine craft DrGeo to be stable and predictable in the way it behaves to its end users, and a lot of releases occurred. When I started to look at porting to newer image last June, I realizedÂ DrGeo will become unstable and oversized, so can of turning from A+ grade to a D- grade, just by the magic of porting it. My plan was to port it during the summer to get it ready end of August to deploy in local schools, it does not happen. And I can write it: it is s-u-p-e-rÂ f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I don't know, I am a casual developer, but it makes developing well crafted and reliable Pharo application a bit expensive to my taste. To such a scale that I started to evaluate alternative to Pharo as the underneath system, idea I finally gave up after several weeks of evaluations. All in all I still have this felling Pharo is not developer friendly, I fell DrGeo is not secure there. See when porting to newer image, I end up using P7-32bits alpha on Linux because it was the most comfortable situation comparing to P5/P6/P6.1, is it not strange? In the other hand this struggle occurs at image change. Ok, may be it is a pattern specific to Smalltalk. Is it the case with commercial Smalltalk vendors? Hilaire -- Dr. Geo http://drgeo.eu

April 13, 2018

Re: [Pharo-users] [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

by Guillermo Polito

On Fri, Apr 13, 2018 at 4:26 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 April 2018 at 21:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> On 13 Apr 2018, at 15:04, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> >> Can you make the video available online? >> >> >> https://youtu.be/A9H8jsSnBKM >> > > I like the new "New Repo", particularly additional of GitHub alternative > (not that I use them, but options is good) > Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo" > entry or similar > which presets *everything* required to clone the Pharo repo. > The thing is that the best way to do it is to clone your own fork... And each one has her/his one. > > Later, here you might even go as far as letting uses entry an Issue and > pre-create the branch > that a fix will be submitted on. But for now... one step at a time. > That's already there > > cheers -ben > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 13, 2018

Re: [Pharo-users] Where do we go now ?

by Herbert VojÄÃk

Herbert VojÄÃk wrote: > Just a bit of a bikeshedding here: > >> But I prefer these names: >> * Calypso System Browser > > Calypso Browser Display > >> * Calypso Debugger > > Calypso Debugger Display > Calypso Debugger Gear > >> * Iceberg Source Control Management\ > > Iceberg SCM Display > Iceberg SCM Gear > >> * Zinc HTTP Client > > Zinc Web Client Gear > >> * Zinc HTTP Server > > Zinc Web Server Gear > >> * Fuel Serialization > > Fuel Serialization Gear > >> * Glamorous Spotter [*] > > Spotter Search Display > Spotter Search Gear > >> * etc. >> >> [*] I particularly dislike "Glamorous" adjective. >> >> In the case of wrapper for libraries I'm hesitant to decide whether to >> indicate pharo name in it or not. >> I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of >> calling "Salty". > > NaCl Adapter Maybe "Salty NaCl Adapter" here, to be consistent with the previous ones of "Fancy Merit Type".

April 13, 2018

Re: [Pharo-users] Where do we go now ?

by Herbert VojÄÃk

Esteban A. Maringolo wrote: > On 13/04/2018 10:41, phil(a)highoctane.be wrote: >> A somewhat unique name makes it easier to google for it (like Roassal >> Pharo, or DeepTraverser Pharo, or Zinc Pharo). >> These will give us hits that are relevant. >> >> Try System Browser, Inspector... Just a bit of a bikeshedding here: > But I prefer these names: > * Calypso System Browser Calypso Browser Display > * Calypso Debugger Calypso Debugger Display Calypso Debugger Gear > * Iceberg Source Control Management\ Iceberg SCM Display Iceberg SCM Gear > * Zinc HTTP Client Zinc Web Client Gear > * Zinc HTTP Server Zinc Web Server Gear > * Fuel Serialization Fuel Serialization Gear > * Glamorous Spotter [*] Spotter Search Display Spotter Search Gear > * etc. > > [*] I particularly dislike "Glamorous" adjective. > > In the case of wrapper for libraries I'm hesitant to decide whether to > indicate pharo name in it or not. > I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of > calling "Salty". NaCl Adapter Ending with "... Display", "... Gear" and "... Adapter" high-level categorization. Question, is separation of UI and underlying machinery always possible. >> Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too >> bland), or SystemBrowserGear (why not), SystemBrowserRig (this one >> sounds cool actually)). > > Fortunately in the past the lack of namespaces caused the use of > prefixes instead of suffixes. > > With time prefixes become invisible. > > A suffix, instead, will get into all your names, bothering with other > existing suffixes like `Component`, `Model`, `Collection`, and so on.

April 13, 2018