- Pharo-users - lists.pharo.org

Re: [Pharo-users] [SmalltalkCI] loading tonel dependencies?

by Gabriel Cotelli

Bernardo, I've proposed a pull request to fix this problem ( https://github.com/hpi-swa/smalltalkCI/pull/367) and tested it against a fork of your repo ( https://travis-ci.org/gcotelli/earley-parser/builds/366766621 ). On Thu, Apr 12, 2018 at 9:30 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > I've created a new issue in smalltalkCI issue tracker: > https://github.com/hpi-swa/smalltalkCI/issues/365 . > <https://github.com/hpi-swa/smalltalkCI/issues/365> > > > On Thu, Apr 12, 2018 at 6:12 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> peter, >>> are you sure that dependencies of a project in tonel format can be >>> loaded? >> >> >> I agree with Gabriel, this has to be a Metacello issue. >> >> The support that was added was having your repo in tonel. If tonel >> dependencies are problem, that's a different issue. I think this is best to >> report directly to SmalltalkCI issue tracker. >> >> But I think smalltalkCI disabled it for Pharo (see disableIcebergDuring: >>> ). I don't know why. >>> >> >> I know that some (long) time ago loading it with iceberg was causing some >> weird trouble, but recently some people mentioned that they use it without >> problems (I think this was from Jenkins CI), so enabling it in SmalltalkCI >> sounds like a good idea. >> >> Peter >> >> On Thu, Apr 12, 2018 at 3:40 AM, Bernardo Ezequiel Contreras < >> vonbecmann(a)gmail.com> wrote: >> >>> in a fresh 6.1 image , i did this >>> >>> Metacello new >>> baseline: 'EarleyParser'; >>> repository: 'github://vonbecmann/earley-parser/repository'; >>> load. >>> >>> expression in the playground and it works. >>> >>> so there's something bogus in smalltalkCI. >>> >>> >>> >>> On Wed, Apr 11, 2018 at 9:14 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> >>> wrote: >>> >>>> If Iceberg enableMetacelloIntegration is true the load seems to work. >>>> But I think smalltalkCI disabled it for Pharo (see disableIcebergDuring: ). >>>> I don't know why. >>>> >>>> On Wed, Apr 11, 2018 at 6:40 PM, Bernardo Ezequiel Contreras < >>>> vonbecmann(a)gmail.com> wrote: >>>> >>>>> 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. >>>>> >>>> >>>> >>> >>> >>> -- >>> Bernardo E.C. >>> >>> Sent from a cheap desktop computer in South America. >>> >> >> >

April 15, 2018

Going to give 4 days lectures at University of Skikda in Algeria

by Stephane Ducasse

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

April 15, 2018

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

by Stephane Ducasse

Ben can you open a bug entry. Now I can tell you that the launcher is one of the most complex application built in Pharo because it has to adapt to multiple OS, multiple version of OS, multiple versions of the images and the VM. For example we discover that we cannot open certain pharo 30 image with the pharo 30 vm but better with a pharo 40 vm. Stef On Sun, Apr 15, 2018 at 6:58 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 April 2018 at 17:49, Benoit St-Jean via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: >> >> >> >> ---------- Forwarded message ---------- >> From: Benoit St-Jean <bstjean(a)yahoo.com> >> To: Esteban Lorenzano <estebanlm(a)gmail.com> >> Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> Bcc: >> Date: Fri, 13 Apr 2018 09:49:15 +0000 (UTC) >> Subject: Re: [Pharo-users] Where do we go now ? >> For those interested. >> >> Created the issues 21686, 21693, 21695, 21696. >> >> And more to come... > > > Thanks for those. I don't much time right to devote, but managed to knock > one off. > And I learn't something new. I'd not known there was a setting for screen > background. > > The other ones seem related to a problem dealing with user home folders > containing non-ascii characters. > Currently this seems only to affect a small number of people, but is a show > stopper for them, > and the numbers will grow with our hoped for growing popularity. > > As a work around, in the PharoLauncher settings can you set the directories > like > C:\PharoLauncher\images > C:\PharoLaucnher\vms > and report if that helps. > > Note, I bumped into an issue changing that setting myself recently where it > tries to migrate > the existing images from the old to the new folder, causing a catch-22 when > your trying > to do that to work around other problems. To work around that, I had to > scroll > down the debug stack to find where the migration was iterating through the > image folders, > and short circuit that with "Return entered value" from the context menu. > Any value > will do when the return value is not used. good luck. > > @PharoLauncher maintainers, can the change in this setting be made to > succeed even if the migration fails. > (I need to run right now) > > cheers -ben >

April 15, 2018

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

by Tudor Girba

Hi Sven, Thanks a lot for the positive message! Indeed, it is a much needed perspective, and I am sure there are many other similar examples. Btw, nice work, too :). Cheers, Doru > On 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 ] > > <Screen Shot 2018-04-13 at 20.40.54.png> > > 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 > > > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

April 15, 2018

Re: [Pharo-users] Recover question at startup

by Ben Coman

> > On Sat, Apr 14, 2018 at 5:56 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> Replying to myself for the record, these two lines seem to inactivate >> Epicea >> >> "Inactivate Epicea" >> EpSettings monitorEnabled: false. >> EpSettings lostEventsDetectorEnabled: false. >> >> >> Now, there is still likely an issue I don't understand > > On 15 April 2018 at 00:32, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi, > I have been checking this problem and the message is shown because is > trying to find the ombu file for the current session. > Usually what it does is comparing the file with the recorded size and > timestamp in the image to check that the file has no new changes. > If the file is newer or larger than the previous info of the image, the > recover message appears. > > I think there is a bug here, although I am not sure, I think that MartÃn > has to help to understand it. > Because in the current implementation if the file does not exists it > produces the recovery message. > Even though it can show that there are changes, if there is no file with > them I think is quite difficult to recover them. > > This behaviour is not happening in the machine where the image is built, > because the file exists in the disk. They are stored in the pharo-local > directory. > > Cheers, > Pablo > I didn't have a chance to check for repeat-ability, but yesterday I saved-quit and Image-A, then in PharoLauncher did a Copy of Image-A to image-B, then opening Image-B got a question about Recovery that I didn't expect or want. cheers -ben

April 15, 2018

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

by Ben Coman

On 13 April 2018 at 17:49, Benoit St-Jean via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Esteban Lorenzano <estebanlm(a)gmail.com> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Bcc: > Date: Fri, 13 Apr 2018 09:49:15 +0000 (UTC) > Subject: Re: [Pharo-users] Where do we go now ? > For those interested. > > Created the issues 21686, 21693, 21695, 21696. > > And more to come... > Thanks for those. I don't much time right to devote, but managed to knock one off. And I learn't something new. I'd not known there was a setting for screen background. The other ones seem related to a problem dealing with user home folders containing non-ascii characters. Currently this seems only to affect a small number of people, but is a show stopper for them, and the numbers will grow with our hoped for growing popularity. As a work around, in the PharoLauncher settings can you set the directories like C:\PharoLauncher\images C:\PharoLaucnher\vms and report if that helps. Note, I bumped into an issue changing that setting myself recently where it tries to migrate the existing images from the old to the new folder, causing a catch-22 when your trying to do that to work around other problems. To work around that, I had to scroll down the debug stack to find where the migration was iterating through the image folders, and short circuit that with "Return entered value" from the context menu. Any value will do when the return value is not used. good luck. @PharoLauncher maintainers, can the change in this setting be made to succeed even if the migration fails. (I need to run right now) cheers -ben

April 15, 2018

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

by Ben Coman

On 14 April 2018 at 22:15, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > Thanks Jochen, thanks everyone. > > Great report! Thanks, Sven :) I was thinking in the same direction - that > my > posts always seem to focus on our work moving forward, and I rarely take > the > time to do a nice writeup of successful applications like these, of which > I've had many. > > I was also thinking that many of the recent animated discussions are signs > of health in our community I recently came across an interesting hypothesis... "There are two types of programming languages. Those that people complain about, and those that people don't use." Is it masochistic to hope we are moving towards the former? > because: a) They seem to often involve people that are not regular posters to the > list, signaling a potential widening of buy-in > While there is likely a growing need to guard against trolls, consider that newcomers may commit limited time to posting, be hurting and lash out, and with fresh eyes, may be poking us where it hurts. For us, don't take it personally. If we focus our response on the technical aspects, we lead the discussion where we want it to go. The easiest thing for a Pharo newcomer to do when experiencing problems is to just drop it and move on to something else. That they put in the effort to articulate their issues is a good thing, and are the seeds of a contributor concerned with making Pharo better. For newcomers, remember that many people have invested a lot of volunteer effort into Pharo and is something dear to our hearts. We love specific *constructive* feedback that helps us make Pharo better, but broad complaints only detract with little benefit. cheers -ben P.S. Years ago, this article was influential to me... http://www.catb.org/esr/faqs/smart-questions.html > b) While our community values constructive feedback (even if it's very > direct), it also fiercely protects people who have given us a lot (as > evidenced by the overwhelming response to a recent trolling on another ML) > c) Maybe most important: they are often about code and infrastructure that > didn't even *exist* a few years ago. For example, now we complain about > breaking builds; I'm sure we all remember not long ago when there was *no* > CI at all to complain about! It seems amazing that the system is as stable > as it is considering everything we overhauled/invented, including: streams, > http, file system, browser (2x), git support, FFI, changes, catalog, the > compiler, GTâ¦ > > For myself, I am clear that any instability is a small price to pay for the > power and hope that Pharo offers. Every time I drop out of our live, > direct, > turetles-all-the-way down into a Ruby script, command line, or > configuration > file, this is proven again. > > All we have to do is hang on! It is a well known principle that it often > seem most difficult just before success and the difference is who quits and > who doesn't :) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 15, 2018

Re: [Pharo-users] Recover question at startup

by Hilaire

Le 14/04/2018 Ã 18:32, tesonep(a)gmail.com a Ã©critÂ : > > This behaviour is not happening in the machine where the image is > built, because the file exists in the disk. They are stored in the > pharo-local directory. And it tries to access itÂ and at some point the path to the file get absolute, right? Then saved in the built image? May be this should not happen. Thanks for the clarifications. Hilaire -- Dr. Geo http://drgeo.eu

April 14, 2018

Re: [Pharo-users] Recover question at startup

by tesonep＠gmail.com

Hi, I have been checking this problem and the message is shown because is trying to find the ombu file for the current session. Usually what it does is comparing the file with the recorded size and timestamp in the image to check that the file has no new changes. If the file is newer or larger than the previous info of the image, the recover message appears. I think there is a bug here, although I am not sure, I think that MartÃn has to help to understand it. Because in the current implementation if the file does not exists it produces the recovery message. Even though it can show that there are changes, if there is no file with them I think is quite difficult to recover them. This behaviour is not happening in the machine where the image is built, because the file exists in the disk. They are stored in the pharo-local directory. Cheers, Pablo On Sat, Apr 14, 2018 at 5:56 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Replying to myself for the record, these two lines seem to inactivate > Epicea > > "Inactivate Epicea" > EpSettings monitorEnabled: false. > EpSettings lostEventsDetectorEnabled: false. > > > Now, there is still likely an issue I don't understand > > > > -- > Dr. Geo > http://drgeo.eu > > > > -- Pablo Tesone. tesonep(a)gmail.com

April 14, 2018

Re: [Pharo-users] Recover question at startup

by Hilaire

Replying to myself for the record, these two lines seem to inactivate Epicea Â Â Â "Inactivate Epicea" Â Â Â EpSettings monitorEnabled: false. Â Â Â EpSettings lostEventsDetectorEnabled: false. Now, there is still likely an issue I don't understand -- Dr. Geo http://drgeo.eu

April 14, 2018