April 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] How to prevent Mustache from replacing & with & etc.?

by Norbert Hartl

Hi, > Am 16.04.2019 um 09:02 schrieb jtuchel(a)objektfabrik.de: > > Hi Pharoers, > > > I may be a bit wrong on this list. I try anyways. > > I am using Mustache to fill text into a String which will then be handed over to LaTeX. The Data I fill in comes from the Database. > > Now the problem is this: if a String from the database contains an ampersand (like in 'Katz & Maus'), Mustache will replace special chars with HTML entities. That is fine in a web context, but LaTeX doesnt actually work well with HTML entities. I could, of course, remove the html entities after Mustache invested a lopt of work into creating them. But it seems more logical to keep Mustache from being so eager to help. It is not logical because mustache is defined that way. So redefining does not improve it. But just use triple {{{ }}} to have strings not being escaped. > > BTW: I already took the hurdle of Mustache excaping $& fir tabular environments (LaTeX uses the ampersand as a divider for table cells) by using \catcode in our .tex template files. But now the String comes from the database and so I am a bit lost... > > > So is there any best practice for this problem? > Yes, use it this way '{{{ value }}}' asMustacheTemplate value: { #value -> '&' } asDictionary Norbert

April 16, 2019

How to prevent Mustache from replacing & with & etc.?

by jtuchel＠objektfabrik.de

Hi Pharoers, I may be a bit wrong on this list. I try anyways. I am using Mustache to fill text into a String which will then be handed over to LaTeX. The Data I fill in comes from the Database. Now the problem is this: if a String from the database contains an ampersand (like in 'Katz & Maus'), Mustache will replace special chars with HTML entities. That is fine in a web context, but LaTeX doesnt actually work well with HTML entities. I could, of course, remove the html entities after Mustache invested a lopt of work into creating them. But it seems more logical to keep Mustache from being so eager to help. BTW: I already took the hurdle of Mustache excaping $& fir tabular environments (LaTeX uses the ampersand as a divider for table cells) by using \catcode in our .tex template files. But now the String comes from the database and so I am a bit lost... So is there any best practice for this problem? Joachim

April 16, 2019

"Instance of SampleForm did not understand #myInstanceVariable"

by Steve Quezadas

I am going through the "Spec UI framework" manual and creating a simple UI interface for a program I am writing. When I do a: foo := SampleForm new openWithSpec. I am getting the following error: "Instance of SampleForm did not understand #okButton" okButton is an "instance variable" of the [SampleForm] class and for some reason the class method is not seeing it. The exact line that brings up this error is here: SampleForm class >> defaultSpec ^ SpecLayout composed newRow: [ :row | row add: #okButton ] <----- error happens here origin: 0 @ 0 corner: 1 @ 0.7; yourself Am I missing something incredibly simple? Should I refer to a instance variable with a hash tag in front of it?

April 14, 2019

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.3

by Norbert Hartl

> Am 14.04.2019 um 07:49 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi Tim, > > Is not about subprojects, is about hot fixes :) > Pharo 7 will continue having some updates on critical bugs but it should not include regular changes (like an update on Calypso). > In that sense, fix #2781 sneaked in and it shouldnât, which means we still need to adjust the process :P > The last sentence made me very lucky.ð Norbert > Esteban > > >> On 13 Apr 2019, at 14:50, Tim Mackinnon <tim(a)testit.works> wrote: >> >> This is great - Iâm pleased we can get fixes like this (and keen to get passed that font issue which was driving me crazy). >> >> A small related question - how do ensure we get fixes from sub projects considered too? Iâd really like to see: https://github.com/pharo-ide/Calypso/pull/451 as itâs annoying not being able to move methods between classes. There are a few other Calypso gems in there too (and quite a few more to fix). >> >> I worry that having all these sub-projects makes it a bit complicated to get them included? >> >> Tim >> >> Sent from my iPhone >> >>> On 12 Apr 2019, at 16:26, "tesonep(a)gmail.com" <tesonep(a)gmail.com> wrote: >>> >>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font corruption font. >>> >>> <image.png> >>> >>> Changes Log >>> >>> #2781 Fix comment on OSWindow >> startTextInput >>> #3160 2975-Problem-when-you-read-an-mcz-pharo7 >>> #3130 Improving the performance of SourceFileArray >>> #3164 MailMessage can not send mails with attachment in Pharo7 >>> #3149 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat >>> #3178 Fix for corrupted fonts in Pharo7 >>> Detailed Diff: v7.0.2...pharo-project:v7.0.3 >>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3 >>> >>> All the images are available in ZeroConf and in the Pharo Launcher. >>> >>> Thanks to all the collaborators especially: >>> >>> - David >>> - Guille >>> - Pavel >>> - Christophe >>> - Theo >>> - Sabine >>> - Sven >>> >>> And to all the people that helped to make this release in a couple of minutes. >>> And thanks to the academy! >>> >>> Pablo >

April 14, 2019

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.3

by Esteban Lorenzano

Hi Tim, Is not about subprojects, is about hot fixes :) Pharo 7 will continue having some updates on critical bugs but it should not include regular changes (like an update on Calypso). In that sense, fix #2781 sneaked in and it shouldnât, which means we still need to adjust the process :P Esteban > On 13 Apr 2019, at 14:50, Tim Mackinnon <tim(a)testit.works> wrote: > > This is great - Iâm pleased we can get fixes like this (and keen to get passed that font issue which was driving me crazy). > > A small related question - how do ensure we get fixes from sub projects considered too? Iâd really like to see: https://github.com/pharo-ide/Calypso/pull/451 <https://github.com/pharo-ide/Calypso/pull/451> as itâs annoying not being able to move methods between classes. There are a few other Calypso gems in there too (and quite a few more to fix). > > I worry that having all these sub-projects makes it a bit complicated to get them included? > > Tim > > Sent from my iPhone > > On 12 Apr 2019, at 16:26, "tesonep(a)gmail.com <mailto:tesonep@gmail.com>" <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> wrote: > >> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font corruption font. >> >> <image.png> >> >> Changes Log >> >> #2781 <https://github.com/pharo-project/pharo/pull/2781> Fix comment on OSWindow >> startTextInput >> #3160 <https://github.com/pharo-project/pharo/pull/3160> 2975-Problem-when-you-read-an-mcz-pharo7 >> #3130 <https://github.com/pharo-project/pharo/pull/3130> Improving the performance of SourceFileArray >> #3164 <https://github.com/pharo-project/pharo/pull/3164> MailMessage can not send mails with attachment in Pharo7 >> #3149 <https://github.com/pharo-project/pharo/pull/3149> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat >> #3178 <https://github.com/pharo-project/pharo/pull/3178> Fix for corrupted fonts in Pharo7 >> Detailed Diff: v7.0.2...pharo-project:v7.0.3 <https://github.com/pharo-project/pharo/compare/v7.0.2...pharo-project:v7.0.3> >> https://github.com/pharo-project/pharo/releases/tag/v7.0.3 <https://github.com/pharo-project/pharo/releases/tag/v7.0.3> >> All the images are available in ZeroConf and in the Pharo Launcher. >> >> Thanks to all the collaborators especially: >> >> - David >> - Guille >> - Pavel >> - Christophe >> - Theo >> - Sabine >> - Sven >> >> And to all the people that helped to make this release in a couple of minutes. >> And thanks to the academy! >> >> Pablo

April 14, 2019

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.3

by Tim Mackinnon

This is great - Iâm pleased we can get fixes like this (and keen to get passed that font issue which was driving me crazy). A small related question - how do ensure we get fixes from sub projects considered too? Iâd really like to see: https://github.com/pharo-ide/Calypso/pull/451 as itâs annoying not being able to move methods between classes. There are a few other Calypso gems in there too (and quite a few more to fix). I worry that having all these sub-projects makes it a bit complicated to get them included? Tim Sent from my iPhone > On 12 Apr 2019, at 16:26, "tesonep(a)gmail.com" <tesonep(a)gmail.com> wrote: > > Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font corruption font. > > <image.png> > > Changes Log > > #2781 Fix comment on OSWindow >> startTextInput > #3160 2975-Problem-when-you-read-an-mcz-pharo7 > #3130 Improving the performance of SourceFileArray > #3164 MailMessage can not send mails with attachment in Pharo7 > #3149 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat > #3178 Fix for corrupted fonts in Pharo7 > Detailed Diff: v7.0.2...pharo-project:v7.0.3 > https://github.com/pharo-project/pharo/releases/tag/v7.0.3 > > All the images are available in ZeroConf and in the Pharo Launcher. > > Thanks to all the collaborators especially: > > - David > - Guille > - Pavel > - Christophe > - Theo > - Sabine > - Sven > > And to all the people that helped to make this release in a couple of minutes. > And thanks to the academy! > > Pablo

April 13, 2019

Re: [Pharo-users] is this a valid Smalltalk way

by Roelof Wobben

April 13, 2019

Re: [Pharo-users] is this a valid Smalltalk way

by Richard O'Keefe

You wrote: "a frame is always two times a throw" but the specification says "A frame is composed of one or two ball throws" and later we learn that the 10th frame may have three throws. There is an issue with your Smalltalk. aCollection withIndexDo: [:index :item | "You have the arguments in the wrong order. It is :item then :index" ... index := index + 2 "this is not legal"]. The assignment is not legal because you are not allowed to assign to method parameters or block parameters. You're going to have something like this: game := BowlingGame new. ... game roll: nPins. score := game score. Since the score of a strike or a spare depends on the scores of the *next* two throws, it might be easier to process the throws backwards. On Sat, 13 Apr 2019 at 04:32, Roelof Wobben <r.wobben(a)home.nl> wrote: > > Hello, > > Im thinking how to solve this one : > https://github.com/exercism/problem-specifications/blob/master/exercises/bo… > > so I thought because you throw two times for a frame to solve it like > this : > > > aCollection withIndexDo: [:index :item | > (if spare) ifTrue: take 3 items out of the score collection and sum > them up > (if strike) ifTrue: take 4 items out of the score collection and sum > them up. > (if not a spare and not a strike) : ifTrue: take 2 items out of the > score collection and sum them up. > index := index + 2 // because a frame is always two times a throw > > > Now I wonder if this is a valid smalltalk to do this > > Roelof > >

April 13, 2019

Re: [Pharo-users] [Pharo-dev] [OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)

by john pfersich

Well, I run a consulting firm and if I could make money from developing software on Pharo, Iâd be willing to join the Consortium as a Gold member. Iâd love to develop using Smalltalk. I do proof of concepts in Smalltalk frequently and deploy in other languages. I would think that a company using Smalltalk would be willing to pay thousands or ten thousands for long term support, depending on the application. I mean one seat of Jetbrainsâ development tools is $600-700 a year, and enterprise development isnât cheap. A reasonable sized MongoDB Atlas database cluster is, according to the website, somewhere in the area of $2500-3000 a month. The average job I do saves the company I work for hundreds of thousands of dollars. I was doing jobs 30 years ago that weâre doing that. Maybe itâs more like millions. /*âââââââââââââââââ-*/ Sent from my iPhone https://boincstats.com/signature/-1/user/51616339056/sig.png See https://objectnets.net and https://objectnets.org > On Apr 12, 2019, at 01:25, Norbert Hartl <norbert(a)hartl.name> wrote: > > So you earn money with pharo? Isnât that a bit risky if you donât have someone to ask if you have a critical problem? That is what you get when you pay into the consortium. Is it that you demand that from the mailing list and the people that work in their free time? > > Norbert > >> Am 12.04.2019 um 03:06 schrieb john pfersich <jpfersich(a)gmail.com>: >> >> +1 on the long term support idea. Changing an application every year to support a new version of Pharo is a nonstarter for most of my clients. >> >> /*âââââââââââââââââ-*/ >> Sent from my iPhone >> https://boincstats.com/signature/-1/user/51616339056/sig.png >> See https://objectnets.net and https://objectnets.org >> >>> On Apr 11, 2019, at 06:33, "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> wrote: >>> >>> +1 on the long term support and stability topic. >> > >

April 13, 2019

Re: [Pharo-users] [Pharo-dev] [OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)

by Esteban Lorenzano

In the pharo board we have discussed several times the LTS thingy. As others said, problem with this is it costs time, and time is money (that we do not have for the moment). It is certainly something in our horizon, but for now is just not possible. I donât know which kind of applications are in play here, but I find hard to believe the effort of migrating from Pharo 6 to Pharo 7 (to put an example) is so big since I migrated all my projects in no-time. Of course migrating from Pharo 2 to Pharo 7 will take more effort than just catch up the last version. But to improve migration recently we introduce auto rewrite tools. This works fine up to a point. Stability in other termsâ¦ what does it means? Stability in the API? Stability in the execution? While the 2nd is a must, the 1st is complicated because you have to have a compromise with the need of evolution. Nevertheless, I would say that the core of Pharo is very stable and what is not so much is the tooling. This is because we are still looking for the right tooling (and because needs change, 10 years ago IoT was not a thing nor we should be prepared to it, and now is âthe new kid in the blockâ and we need to answer to it. Lot of other things accumulate what this days is called âtechnical debtâ and we need to answer to that. That breaks âstabilityâ, but breaks it in a positive way. Soâ¦ I have my doubts about what stability means. If it means no change. It is a no go (but users can always stick with older versions, is not that we are hiding them). If it means eternal backward compatibility. It is too expensive (and also an eventual stagnation) So we choose to be âstable in our goalsâ : to provide each version an improved version of Pharo that users can enjoy (that the origin of this thread that has been suddenly highjacked for just one of the topics), while trying to be as effortless as possible to catch up (but of course, âas effortless as possibleâ does not means zero effort). Esteban > On 12 Apr 2019, at 03:06, john pfersich <jpfersich(a)gmail.com> wrote: > > +1 on the long term support idea. Changing an application every year to support a new version of Pharo is a nonstarter for most of my clients. > > /*âââââââââââââââââ-*/ > Sent from my iPhone > https://boincstats.com/signature/-1/user/51616339056/sig.png > See https://objectnets.net and https://objectnets.org > >> On Apr 11, 2019, at 06:33, "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> wrote: >> >> +1 on the long term support and stability topic. >

April 12, 2019