- Pharo-users - lists.pharo.org

Re: mentoring contined I hope

by Roelof Wobben

Sept. 1, 2020

Re: [Pharo-users] mentoring contined I hope

by Richard Sargent

What is the value of *self* when the error occurred? The debugger should show you this. Another way to determine this is to look at the code and think about where the sending method is implemented and where the invoked method is implemented (assuming that there really is one). On Tue, Sep 1, 2020 at 10:11 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > oke, then I would work with hour and minutes as the challenge wanted, > > So still on the class side make code that convert any given hour and >> minute to a valid one ? >> > > Yes. Such code would also be used when doing arithmetic with Times. e.g. > if you were to implement an instance method named #addMinutes:, its > implementation would be as simple as ^Time hours: self hours minutes: self > minutes + anInteger (assuming the argument has that name). The instance > creation method would normalize the new requested time, just like Time > hours: 0 minutes: 70 would do. > >> >> Roelof >> >> > > On some way I think or I do something wrong or I did misunderstood you. > > I did this in Pharo > > Object subclass: #Clock > instanceVariableNames: 'hour minute' > classVariableNames: '' > package: 'Exercise@Clock' > > I made a asscesors on the instance side. > > then I did this on the class side : > > hour: anInteger minute: anInteger2 > self hour: anInteger2 % 60 + anInteger; > self minute: anInteger2 / 60; > yourself. > > but I see a message that hour and minutes are not known. > > Roelof > >

Sept. 1, 2020

Re: mentoring contined I hope

by Roelof Wobben

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by StÃ©phane Ducasse

Hi john you can propose for inclusion in pharo. - Add a nice comment (with executablecomments would be a plus). - Possibly some tests - Send a PR. > On 1 Sep 2020, at 09:32, John Aspinall <john.aspinall(a)gmail.com> wrote: > > Dolphin shows the same behaviour. I added the following method to ScaledDecimal to help: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: scale) / scaleFactor > > > Translating slightly for Pharo: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: scale) / scaleFactor > > > You can then do: > > (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 9.5s1 "true" > > > HTH. > > John > > > > > > > >> On 1 Sep 2020, at 05:17, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> As a follow up to this, adding a roundTo: before converting into a >> ScaledDecimal does not work. >> >> (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) >> asScaledDecimal: 1) = 17.9s1 >> >> So how do you compare two ScaledDecimals that _should_ be the same? >> >> Regards! >> >> Esteban A. Maringolo >> >> On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I was doing some basic calculations based on a formula, and I wanted >>> to convert the result to a scaled decimal in order to avoid having >>> these "loose" decimals in 10th position or something similar. >>> >>> So I did the following: >>> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 >>> >>> But When I do this in a test: >>> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 >>> >>> It fails because the comparison returns false. >>> >>> I guess this is the proper behavior, but I'd expected that the >>> conversion from a Float to a scaled decimal would have eliminated the >>> extra precision from the formula. >>> >>> I can do a roundTo: 0.1 before converting, but I'd like to know what >>> would be the proper way of dealing with this. >>> >>> Thanks! >>> >>> Esteban A. Maringolo >> > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by Esteban Maringolo

Hi John, I was doing a similar rounding in the test assertion, I think your method is better and broadly usable (and maybe convenient for an #equals: implementation). Thanks! Esteban A. Maringolo On Tue, Sep 1, 2020 at 4:33 AM John Aspinall <john.aspinall(a)gmail.com> wrote: > > Dolphin shows the same behaviour. I added the following method to ScaledDecimal to help: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: scale) / scaleFactor > > > Translating slightly for Pharo: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: scale) / scaleFactor > > > You can then do: > > (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 9.5s1 "true" > > > HTH. > > John > > > > > > > > > On 1 Sep 2020, at 05:17, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > As a follow up to this, adding a roundTo: before converting into a > > ScaledDecimal does not work. > > > > (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) > > asScaledDecimal: 1) = 17.9s1 > > > > So how do you compare two ScaledDecimals that _should_ be the same? > > > > Regards! > > > > Esteban A. Maringolo > > > > On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > >> > >> Hi, > >> > >> I was doing some basic calculations based on a formula, and I wanted > >> to convert the result to a scaled decimal in order to avoid having > >> these "loose" decimals in 10th position or something similar. > >> > >> So I did the following: > >> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 > >> > >> But When I do this in a test: > >> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 > >> > >> It fails because the comparison returns false. > >> > >> I guess this is the proper behavior, but I'd expected that the > >> conversion from a Float to a scaled decimal would have eliminated the > >> extra precision from the formula. > >> > >> I can do a roundTo: 0.1 before converting, but I'd like to know what > >> would be the proper way of dealing with this. > >> > >> Thanks! > >> > >> Esteban A. Maringolo > > > >

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by Esteban Maringolo

It evaluates to false in VW too. I guess it is a matter of internal representation, since ScaledDecimals/FixedPoints are a Fraction after all. What is weird, and I'd say wrong (at least from the UX perspective) is that in Pharo (and Dolphin): ((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) -> 17.900000000000002 While in VW and VAST they round the float properly: ((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) -> 17.9 Regards! Esteban A. Maringolo On Tue, Sep 1, 2020 at 1:24 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > > Interesting. Your expression evaluates to true in VA Smalltalk. > > > Am 01.09.20 um 06:17 schrieb Esteban Maringolo: > > As a follow up to this, adding a roundTo: before converting into a > > ScaledDecimal does not work. > > > > (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) > > asScaledDecimal: 1) = 17.9s1 > > > > So how do you compare two ScaledDecimals that _should_ be the same? > > > > Regards! > > > > Esteban A. Maringolo > > > > On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > >> Hi, > >> > >> I was doing some basic calculations based on a formula, and I wanted > >> to convert the result to a scaled decimal in order to avoid having > >> these "loose" decimals in 10th position or something similar. > >> > >> So I did the following: > >> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 > >> > >> But When I do this in a test: > >> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 > >> > >> It fails because the comparison returns false. > >> > >> I guess this is the proper behavior, but I'd expected that the > >> conversion from a Float to a scaled decimal would have eliminated the > >> extra precision from the formula. > >> > >> I can do a roundTo: 0.1 before converting, but I'd like to know what > >> would be the proper way of dealing with this. > >> > >> Thanks! > >> > >> Esteban A. Maringolo > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Sept. 1, 2020

Re: [Pharo-users] mentoring contined I hope

by Richard Sargent

I recommend against modifying time instances once created. Likewise for dates and timestamps.You don't know if the time instance has been shared with another object. It's best to treat them as immutable once created. Do not make the mistake of trying to avoid creating new objects. It will lead to contorted code and all sorts of complications. (Of course, be careful not to create a bazillion objects unnecessarily!) The same advice applies to creating classes. Some languages have a high cost to define a new class, usually psychological. This leaves their programmers "allergic" (or acting as if they were) to creating a new class that would make a solution better. In Smalltalk, a class is just an object. In terms of how to model time, you *could* have the time object just store the count of intervals since the start of the day. But, if you want Times with microsecond resolution or nanosecond resolution, you would always be working with a LargeInteger internally. VA Smalltalk Time has ('hours' 'minutes' 'seconds' 'milliseconds' 'millisecondsFromMidnight') VisualWorks Time has ('hours' 'minutes' 'seconds' 'milliseconds' 'partialNanosecond') Pharo (5.0) Time has ('seconds' 'nanos') It can be useful to trade space efficiency for comprehensibility. Often, focussing on space efficiency results in convoluted code for little other benefit. It's a good idea to start by modelling the concepts that we discuss when describing something. My cookoo clock has an hour hand and a minute hand. It has no concept of seconds, per se. It has a time tick, but whether that is exactly one second, I don't know. Probably not. The pendulum doesn't move that fast. So, if modelling a cookoo clock, modelling the hours and minutes it shows is a reasonable design. In some respects, modelling your Time as a number of minutes into the day would simplify normalizing the arguments to the instance creation methods. Just compute the requested number of minutes, perform the modulus to limit the size of a day, and you are done. In the absence of a constraint imposed by the author of the problem, you are free to implement a solution that presents the expected results. On Mon, Aug 31, 2020 at 10:12 PM Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 1-9-2020 om 00:22 schreef Richard Sargent: > > On Mon, Aug 31, 2020 at 3:10 PM Roelof Wobben <r.wobben(a)home.nl> wrote: > >> Op 31-8-2020 om 23:45 schreef Richard Sargent: >> >> On Mon, Aug 31, 2020 at 1:57 PM Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> >>> I would argue against that approach. Make it a requirement that a given >>> API must be used with correct values. >>> e.g. #hours:minutes: requires hours between 00 and 23 and minutes >>> between 00 and 59. >>> >>> If you want to convert equivalent time values, use a specific API. For >>> example, many time implementations publicly define a seconds-based API, >>> such as Time class>>#fromSeconds:. You can do the same with your >>> implementation with a class-side #fromMinutes: method. (The corresponding >>> instance methods would be #asSeconds and #asMinutes or something similar.) >>> >>> >>> >>> Moment, I do not know if I understand you right. >>> >>> so I would use the given method and use on the instance another function >>> that takes care of the converting to or a valid time object or for example >>> convert it to minutes and on display take care that a valid time is shown. >>> >>> Do I understand you right ? >>> >> >> I don't think you do, but it's a little difficult to determine. >> >> *Time hours: 0 minutes: 70* should throw an out of range exception on >> the second argument. >> Time fromMinutes: 70 "should" answer an instance equivalent to 01:00. (I >> say should in quotes, because Time is a point in time. Duration is >> something that makes more sense to have *Duration minutes: 70* be >> acceptable.) >> >> This discussion assumes *your* model of time uses just hours and >> minutes. Normally, Time includes seconds, and often fractions of seconds. >> But, you are working on an exercise, so a reduced scope Time may be >> appropriate. >> >> Rather than talking about Time class>>#fromMinutes:, let's go a little >> more extreme and discuss a hypothetical Time class>>#fromHours: method. We >> understand and agree that Time can represent hours from 0 through 23. There >> is no 24 o'clock. So, if you wrote *Time fromHours: 25*, what would you >> expect to get for a result? What would someone who comes along later and >> uses your code expect to get? It's not well defined. So extrapolate from >> that case to the other cases. 70 minutes is not a time. "I'll meet you >> *at* 70 minutes" said no one ever. :-) ["*in* 70 minutes" is a duration >> from the present moment, implying a time 70 minutes in the future.] >> >> I have come across a lot of code in my life. The hardest code to work >> with and to enhance is code that says it will try to accept whatever it's >> given. If it wants a number, it will accept a string of digits and "figure >> out" what number was meant. Life is so much easier when the author says >> "That's rubbish. Give me a proper number." or "That's too big. Give me a >> proper number of hours.", etc. >> >> In general, make your APIs precise and predictable. Range check the >> passed values and complain when they aren't proper. If the clock you are >> modelling has a precision of minutes, your API is #hours:minutes: and maybe >> just #hours: for convenience. (In general, I wouldn't do so.) And it's >> reasonable to have methods to answer the number of increments from the >> start of the day of your clock's precision and to create a new instance >> from that number. So, with a precision of minutes, you can have an instance >> method named e.g. #asMinutes or perhaps #totalMinutes or even >> #minutesSinceMidnight, and to have a corresponding *class* method >> #fromMinutes: or #minutesFromMidnight: which answers the corresponding >> instance of Time. If your clock has a precision of seconds, which is more >> normal for us, those "minutes" methods would actually be similarly named >> "seconds" methods instead. (If your clock has a precision finer than >> seconds, I would expect to see corresponding methods for the finer >> gradations of time that would be common, *in addition to* the various >> "seconds" methods. e.g. milliseconds or microseconds since midnight. And >> likely both if the clock resolution was microseconds, just because we do >> tend to think of milliseconds or microseconds when we talk of more precise >> times.) >> >> >> >> >> I understad but here im stuck at what the person who made this challenge >> has said. >> And unfortunalty he/she has deciced that what I said earlier the code >> schould convert invalid time objects to valid time objects. >> If I have made this myself I would make it as you said so when a time in >> invalid thrown a error. >> > > I understand. You have constraints. In that case, where you would do > validation in #hours:minutes: (class side), do normalization instead. If > either argument is out of range (starting with the minutes), keep the > remainder and add the excess to the next value. If hours go out of range, > discard the excess. You may need to tolerate negative values. The > arithmetic is still straight forward. If not, you still need to validate > for them. > > >> Roelof >> >> > Sorry to be throwing ideas but it is not better to keep everything in for > examples minutes . So when I add minutes or substract minutes there does > not have to make a new clock all the time. > I could then make the converting from minutes to hours and minitues when I > want to display it. > So I have more flexiblility when for example the output format needs to be > changed. > > >

Sept. 1, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by Esteban Maringolo

Hi Stef, That was the first thing I tried, but PharoADO (it is, PharoCOM) needs the source in order to do some of its stuff. But even so, I'd still like to have a VM that is used only for running the image headless, without any GUI (nor IDE). Regards! Esteban A. Maringolo On Mon, Aug 31, 2020 at 10:20 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > If this is for obsfucation why not simply providing an empty source/changes file? > And you can remove the decompiler (but then after you will never debug anymore your application). > > S > > Hi Stef, > > Thanks for the support. > > I don't know if there is a way to do that for FFI except if you > somehow modify the methods during execution to include the arguments > in the method itself instead of relying on the source code for > reflection. > > What would help in the meantime is to have a VM that is headless all > the time (something like a forced --headless parameter), otherwise it > is really easy for somebody to remove the --headless parameter and > fire your image and navigate your code with all the power a Smalltalk > IDE provides. > > > Is there a way to compile a VM with such an option? (basically a > HeadlessPharoConsole.exe). > > Regards! > > Esteban A. Maringolo > > On Sat, Aug 29, 2020 at 2:46 AM StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > > Hi > > Iâm really interested in this. > Because we should be able to ship without the sources. > FFI needs the source at some point but I guess that this is the first time > and that the information could be stored in the compiledMethod. > But I do not remember. > > Now may be esteban or pablo can give you some hints > but frankly we are super super super busy > but if you have a way and that Pharo should be changed to support this scenario let > us know we will support you. > > S > > On 29 Aug 2020, at 04:49, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi, > > Is there a way to get rid the .sources file in a deployment scenario? > > I followed this guide [1], but I cannot get rid of the .sources files, > because I'm using PharoADO (which uses PharoCOM) and it uses some > reflection for FFI and for some reason that implies using the .sources > file. I installed the FFICompilerPlugin as per the instructions, but I > don't have a way to tell whether I did in the right place/moment, nor > how to assess its proper installation. > > If such [2] .sources file cannot be removed, what is the criteria for > the lookup, can it be renamed or modified via some parameter/config? > > Thanks! > > [1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… > [2] Pharo8.0-32bit-0932da8.sources in my case > > > Esteban A. Maringolo > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by John Aspinall

Dolphin shows the same behaviour. I added the following method to ScaledDecimal to help: roundedByScale | scaleFactor | scaleFactor := 10 ** scale. ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: scale) / scaleFactor Translating slightly for Pharo: roundedByScale | scaleFactor | scaleFactor := 10 ** scale. ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: scale) / scaleFactor You can then do: (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 9.5s1 "true" HTH. John > On 1 Sep 2020, at 05:17, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > As a follow up to this, adding a roundTo: before converting into a > ScaledDecimal does not work. > > (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) > asScaledDecimal: 1) = 17.9s1 > > So how do you compare two ScaledDecimals that _should_ be the same? > > Regards! > > Esteban A. Maringolo > > On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> Hi, >> >> I was doing some basic calculations based on a formula, and I wanted >> to convert the result to a scaled decimal in order to avoid having >> these "loose" decimals in 10th position or something similar. >> >> So I did the following: >> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 >> >> But When I do this in a test: >> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 >> >> It fails because the comparison returns false. >> >> I guess this is the proper behavior, but I'd expected that the >> conversion from a Float to a scaled decimal would have eliminated the >> extra precision from the formula. >> >> I can do a roundTo: 0.1 before converting, but I'd like to know what >> would be the proper way of dealing with this. >> >> Thanks! >> >> Esteban A. Maringolo >

Sept. 1, 2020

Re: mentoring contined I hope

by Roelof Wobben

Sept. 1, 2020