August 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] mentoring contined I hope

by 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.) Just as the advice I gave you some months ago was to be unambiguous and precise when naming things, be unambiguous and precise about your APIs (all your methods, really!). People who end up using your code will thank you. > I send this personal because I cannot send to the mailing list according > to some spam list >

Aug. 31, 2020

mentoring contined I hope

by Roelof Wobben

Aug. 31, 2020

Re: [Pharo-users] mentoring continued I hope

by Richard Sargent

On Sun, Aug 30, 2020 at 10:04 PM Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello, > > I have this challenge from exercism : > https://github.com/exercism/pharo-smalltalk/tree/master/exercises/clock > > and this function is given : > > hour: anInteger minute: anInteger2 > self shouldBeImplemented > > > Schould I make it on this class method work that the minutes will not > exceed the 59 minutes > So when for example when 70 min are given so hour:0 minute:70 it will > be converted to hour: 1 minutes: 10 > 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.) or can I better do this on the instance side. > > Regards, > > Roelof > > >

Aug. 31, 2020

Re: [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH)

by Torsten Bergmann

Hi Jonathan, Â nice, thanks for investing time and effort into this. Such utilities are needed for serious applications. Some thoughts and questions: Â 1.Â What is the mid-term or long-term plan regarding collaboration? Will you be able to step in as maintainer? Â 2. As it already seems to be authored by several people and contains functionality of general interest it should beÂ considered to move it toÂ Â Â Â a central community place likeÂ https://github.com/pharo-contributions[https://github.com/pharo-contributio… where several people from community have already Â Â Â access.Â It would then be in alignment withÂ https://github.com/pharo-contributions/Cryptography[https://github.com/phar… too and maintenance of contributions as well as releases could be done from different sides and more centrally. Â Â Â Â You and anyone can then regulary fork from the community repo to an own (customized) repo like https://github.com/objectguild/Crypto-Nacl Â Â Â I guess Esteban can add you as contributor to "pharo-contribution" organization if you follow that path. Â 3. I guess LICENSE file need to be updated to give additionall credit to the original authors or mention more general "Pharo community"Â Â Â Â (currently it mentionsÂ Object Guild solely) Â Â 4. Can it be changed to use "NaCl" instead of "Nacl" which is more suitable name for SodiumÂ (a similar name fixing was done in the Cuis port too) Â 5. Would it be possible to add some expressions/samples or docu in the README for end users on how to use it. This would give people a quick guide on how to do things. Â Â Â 6. Any plans for making it work on Windows too? Thanks Torsten Â Gesendet:Â Montag, 31. August 2020 um 09:52 Uhr Von:Â "Jonathan van Alteren" <jvalteren(a)objectguild.com> An:Â "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Betreff:Â [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH) Hi all, I wanted to let you know that I ported the Crypto-Nacl library from SmalltalkHub to GitHub here:Â https://github.com/objectguild/Crypto-Nacl[https://github.com/objectguild/C… The original author is Tony Garnock-Jones, with contributions from HernÃ¡n Morales Durand. See the README for more details. Libsodium has evolved a lot over time, which means that there is plenty of additional functionality that can be unlocked through this library. I don't have a need for it at the moment, but that might change in the near future. My interest is in using the cryptographic features to enhance security of business applications. Oh, and thanks to the Buenos Aires Smalltalk team (https://github.com/ba-st/[https://github.com/ba-st/]) for inspiration on using GitHub Actions with smalltalkCI :-) Â Cheers, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations jvalteren(a)objectguild.com

Aug. 31, 2020

Re: [Pharo-users] CV/OCR Library

by StÃ©phane Ducasse

I know that there is an openCV binding by https://twitter.com/DmitryMatveev You have a binding in GT too. > On 31 Aug 2020, at 14:40, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi, > > Does anybody know if there is an OCR or some CV library available for Pharo? > > I would like to make an experiment with recognizing the content of > some fixed size form, and of course I prefer to do it with Smalltalk > whenever possible. > > Regards! > > 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

Aug. 31, 2020

Re: [Pharo-users] CV/OCR Library

by Esteban Maringolo

Hi Eric, Thanks for the reference. I'll look into it! Regards! Esteban A. Maringolo On Mon, Aug 31, 2020 at 10:06 AM Eric Gade <eric.gade(a)gmail.com> wrote: > > Hi Esteban, > > I know that Sean D has wrapped the Tesseract OCR library: > https://github.com/seandenigris/Tesseract-St > > On Mon, Aug 31, 2020 at 8:42 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> Hi, >> >> Does anybody know if there is an OCR or some CV library available for Pharo? >> >> I would like to make an experiment with recognizing the content of >> some fixed size form, and of course I prefer to do it with Smalltalk >> whenever possible. >> >> Regards! >> >> Esteban A. Maringolo >> > > > -- > Eric

Aug. 31, 2020

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

by StÃ©phane Ducasse

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

Aug. 31, 2020

Re: [Pharo-users] CV/OCR Library

by Eric Gade

Hi Esteban, I know that Sean D has wrapped the Tesseract OCR library: https://github.com/seandenigris/Tesseract-St On Mon, Aug 31, 2020 at 8:42 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > Does anybody know if there is an OCR or some CV library available for > Pharo? > > I would like to make an experiment with recognizing the content of > some fixed size form, and of course I prefer to do it with Smalltalk > whenever possible. > > Regards! > > Esteban A. Maringolo > > -- Eric

Aug. 31, 2020

CV/OCR Library

by Esteban Maringolo

Hi, Does anybody know if there is an OCR or some CV library available for Pharo? I would like to make an experiment with recognizing the content of some fixed size form, and of course I prefer to do it with Smalltalk whenever possible. Regards! Esteban A. Maringolo

Aug. 31, 2020

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

by Esteban Maringolo

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 >

Aug. 31, 2020