- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Mailing list Archive - Bandwidth Limit Exceeded

by Marcus Denker

I will check with support. > On 21 Sep 2018, at 09:49, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Marcus, > > I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching > his/her bandwidth limit. Please try again later." message on http://lists.pharo.org > > If I remember correctly we already had this one or two years ago. > > Thanks > T.

Sept. 21, 2018

Mailing list Archive - Bandwidth Limit Exceeded

by Torsten Bergmann

Hi Marcus, I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later." message on http://lists.pharo.org If I remember correctly we already had this one or two years ago. Thanks T.

Sept. 21, 2018

Deprecation guide for methods, classes and packages

by Torsten Bergmann

Hi, >From Bug #20900/ PR 1818 it looked like it is not really clear on how to "deprecate" correctly. Therefore I summarized and wrote a short guide following what we contributors used as best practice so far. Also read [1], [2] and [3] and check some of the deprecation settings in the Pharo settings browser. Just open SettingsBrowser and search for "Depre". I write this mail to "pharo-dev" with CC: "pharo-users" list - because of common interest. But comments and replies should please go to "pharo-dev" so we do not disrupt the thread too much. Thanks! Please review what I wrote and ideally we can put the text or a link to it as "Deprecation guide" into the documentation / wiki / ... on GitHub afterwards. Hope this helps a little bit. Thanks T. [1] https://en.wikipedia.org/wiki/Deprecation [2] https://www.peteruhnak.com/blog/2015/08/06/transforming-deprecated-code-wit… [3] https://pharoweekly.wordpress.com/2016/06/17/automatic-deprecation-refactor… ------------------------------------------------------------------------------------------------------------------------------ In any Pharo version we have a special package hosting deprecated methods and classes. This allows smooth migration for Pharo users as code should still load and runs to some extent - but deprecation warnings and possibly a helping hand (in form of automatic code transformations) could be given to support migration. As we currently work on Pharo7 there is a "Deprecated70" package in the image hosting deprecated methods and classes intended to be removed for Pharo 8. When Pharo 7 is released the users can easily spot the deprecations - also because they are striked through (more on this below). When Pharo 8 iteration starts the "Deprecated70" will be replaced with an empty "Deprecated80" package. DEPRECATING METHODS =================== If you deprecate a METHOD use #deprecated: message and switch it to be an extension method in *Deprecated70*. If the method could be replaced by calling another method then dispatch the call to the new method and ideally provide a transformation so next time the old method is called the sender method is automagically rewritten and could be adopted/migrated: oldMethod "An old method we do not use anymore. But luckily there is a replacement." self deprecated: 'Please use #newMethod instead' transformWith: '`@receiver oldMethod' -> '`@receiver newMethod'. ^ self newMethod So if there is a method like foo self oldMethod sending the old deprecated method it will be migrated to foo self newMethod as soon as foo, the oldMethod and the transformation is called. If the automatically migrated method is under version control (Monticello or git) you will easily see that #foo was modified. In case there is no replacement for a method you would like to deprecate then it is best to throw an error when it is used: veryOldMethod "A very old method hopefully nobody uses. So we do no provide a replacement." self deprecated: 'The method #veryOldMethod is deprecated without any replacement'. ^ self error: 'Do not use #veryOldMethod anymore' Note that the method is striked through in the Pharo system browser in both cases to show that it should not be used anymore. In the standard image calling a deprecated method is logged on the Transcript and flagged with a warning dialog. This should help users and maintainers of external packages to easily spot when they still use deprecated code. You can change these settings in Pharo Settings Browser under Tools -> Debugging -> Deprecation Handling. DEPRECATING CLASSES =================== If you deprecate a CLASS implement #isDeprecated on class side to return true and move it to package "Deprecated70" Ideally write in the class comment why it is deprecated and if there is a replacement class what to use instead Object subclass: #OldClass instanceVariableNames: '' classVariableNames: '' package: 'Deprecated70-OldTag' and comment to explain the reasons: OldClass comment: 'Use NewClass instead'. and implement in class side method category 'testing' isDeprecated "We do not need this class anymore" ^true Note that the class is striked through in the system browser. DEPRECATING PACKAGES ==================== If you deprecate a PACKAGE then rename it with "Deprecated" in the name. Let the class side of the package manifest (typically a subclass of PackageManifest within the package) als return #isDeprecated with true. In the class comment of the package manifest (which also serves as package comment) explain why the package is deprecated and if there is a replacement or not. Example: your package name is "OldPackage-Core", so the new name is "OldPackage-Deprecated-Core". Create a manifest or use the existing one. A Manifest should be a subclass of PackageManifest and should be categorized within a 'Manifest' tag. PackageManifest subclass: #ManifestOldPackageCore instanceVariableNames: '' classVariableNames: '' package: 'OldPackage-Deprecated-Core-Manifest' and comment to explain the reasons: ManifestOldPackageCore comment: 'This package is not useful anymore. Check NewPackage for replacement'. and implement in class side method category 'testing' isDeprecated "We do not need this package anymore" ^true Note that the manifest class and the package is striked through in the system browser. Be aware that a deprecated package might be removed completely already in the next Pharo major version iteration.

Sept. 21, 2018

Re: [Pharo-dev] Debugger should step silently over #halt

by Ben Coman

On Fri, 21 Sep 2018 at 01:51, Tim Mackinnon <tim(a)testit.works> wrote: > I never knew it did that - but it makes sense. Presumably pressing resume > then activated them again right? > yes. Though IIUC its not so much that they were deactivated, but more like the system goes... I hit a halt, hey I'm already halted, so no-op. cheers -ben > > Tim > > Sent from my iPhone > > On 20 Sep 2018, at 08:42, Ben Coman <btc(a)openinworld.com> wrote: > > I'll often put several breakpoints in code like this... > ``` > debug := true. > "Somewhere else in application code..." > debug ifTrue: [ self halt ]. > 1 + 1. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 2 + 2. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 3 + 3. "Representing some longer bit of application code" > ``` > While stepping <Over> code after hitting the first halt, > I am used to subsequent halts being silently stepped over. > I just confirmed this with > http://files.pharo.org/platform/Pharo6.0-win.zip > and also build 60541 started from PharoLauncher. > > However build 71231 and build 60542 do not silently step over a #halt. > Each produces slightly different results (pics attached). > <P01-Double-Halt-Pharo7.png> > <P02-Double-Halt-Pharo60542.png> > > I've logged an issue... > > https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… > > cheers -ben > >

Sept. 20, 2018

Re: [Pharo-dev] Debugger should step silently over #halt

by Tim Mackinnon

I never knew it did that - but it makes sense. Presumably pressing resume then activated them again right? Tim Sent from my iPhone > On 20 Sep 2018, at 08:42, Ben Coman <btc(a)openinworld.com> wrote: > > I'll often put several breakpoints in code like this... > ``` > debug := true. > "Somewhere else in application code..." > debug ifTrue: [ self halt ]. > 1 + 1. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 2 + 2. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 3 + 3. "Representing some longer bit of application code" > ``` > While stepping <Over> code after hitting the first halt, > I am used to subsequent halts being silently stepped over. > I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip > and also build 60541 started from PharoLauncher. > > However build 71231 and build 60542 do not silently step over a #halt. > Each produces slightly different results (pics attached). > <P01-Double-Halt-Pharo7.png> > <P02-Double-Halt-Pharo60542.png> > > I've logged an issue... > https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… > > cheers -ben

Sept. 20, 2018

Debugger should step silently over #halt

by Ben Coman

I'll often put several breakpoints in code like this... ``` debug := true. "Somewhere else in application code..." debug ifTrue: [ self halt ]. 1 + 1. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 2 + 2. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 3 + 3. "Representing some longer bit of application code" ``` While stepping <Over> code after hitting the first halt, I am used to subsequent halts being silently stepped over. I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip and also build 60541 started from PharoLauncher. However build 71231 and build 60542 do not silently step over a #halt. Each produces slightly different results (pics attached). [image: P01-Double-Halt-Pharo7.png] [image: P02-Double-Halt-Pharo60542.png] I've logged an issue... https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… cheers -ben

Sept. 20, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban A. Maringolo

On 20/09/2018 02:11, ponyatov wrote: > Just add Torrent as download variant Torrent for a 50mb/file is overkill today. And adds a new requirement to get started. A Torrent based Pharo launcher is a different story :) Regards, -- Esteban A. Maringolo

Sept. 20, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by ponyatov

Just add Torrent as download variant -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 20, 2018

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

by Julien

Hello, Ok, I read all the mails. I see your point about not cancelling the possibility to use #to:by: on any Number. However, the remark from David Grandi seems really relevant to me. You can NOT write anything else than a *rational number* when writing a literal using the XXX.XXX pattern. I think it would be legit to generate scaled decimal by default from float literals and to be able to get Float only by either explicitly specify it (#asFloat, etcâ¦) or because of computation that lead to a Float (e.g. the need to approach an irrational number ?). I would be curious to see the impact of such change in the compiler on the system. Maybe a first step is indeed to implement a rule in Renraku to encourage people to use ScaledDecimals. Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 19 sept. 2018 Ã 09:22, Davide Grandi <grndvd63m06f704u(a)gmail.com> a Ã©crit : > > > 0.0 to: 1.0 by: 0.1 > Receiver and arguments, lexically (the dot), are float BUT > are written as decimal number (zero, one, one tenth). > > I think that in a text you can ONLY write "decimal" numbers or (in bases other than 10 [or with factors other than 2^x and 5 ?]), at worst, repeating decimals > (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions. > > So, may be, if the receiver or an argument is a float the compiler may issue a warning and compile to non-float, > if receiver or arguments are computed ... there should be a default behaviour. > > Best regards, > > Davide Grandi > (PS : I work mainly in an ERP that has only integers ... and doubles) > > On 18/09/2018 11:52, Guillaume Larcheveque wrote: >> Maybe #to:by: should convert its parameters in Fraction to avoid Floats problems (not sure, just an idea) >> >> 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >>> On 18 Sep 2018, at 11:13, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> >>> >>> On Tue, Sep 18, 2018 at 11:06 AM Julien <julien.delplanque(a)inria.fr <mailto:julien.delplanque@inria.fr>> wrote: >>> Hello, >>> >>> I realised that it is possible to create an interval of floats. >>> >>> I think this is bad because, since intervals are computed by successively adding a number, it might result in precision errors. >>> >>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9 1.0) >>> >>> The correct (precise) way to do it would be to use ScaledDecimal: >>> >>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) >>> >>> I opened an issue about it: https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by… <https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by…> >>> >>> And Iâd like to discuss this with you. >>> >>> What do you think? >>> >>> Well, I think it's a matter of balance :) >>> >>> #to:by: is defined in Number. So we could, for example, cancel it in Float. >>> However, people would still be able to do >>> >>> 1 to: 1.0 by: 0.1 >>> >>> Which would still show problems. >> >> Nevertheless, I have seen this a lot of times. >> >> 0.0 to: 1.0 by: 0.1 >> >> Is a common use case. >> >>> >>> And moreover, we could try to do >>> >>> 1 to: 7 by: (Margin fromNumber: 1) >>> >>> And even worse >>> >>> 1 to: Object new by: (Margin fromNumber: 1) >>> >>> I think adding type-validations all over the place is not a good solution, and is kind of opposite to our philosophy... >>> >>> So we should >>> - document the good usages >>> - document the bad ones >>> - and live with the fact that we have a relaxed type system that will fail at runtime :) >> >> yup. >> But not cancel. >> >> Esteban >> >>> >>> Guille >> >> >> >> >> -- >> Guillaume Larcheveque >>

Sept. 19, 2018

Re: [Pharo-dev] Platform file encoding for FFI

by Eliot Miranda

Hi Henry, On Tue, Sep 18, 2018 at 1:43 AM Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Guillermo Polito wrote > > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > > > akgrant0710@ > > > > > > wrote: > > > >> Hi Esteban, Guille and Everyone, > >> > >> I haven't looked at using FFI much, however it is easy to imagine that > >> different file encoding rules on different platforms will make writing > >> FFI calls more difficult, > > > > > > Well not really (from my point of view :)) > > From the point of view of the FFI call an encoded string is just a bunch > > of > > bytes. FFI does not do any interpretation of them. > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > self > ffiCall: #(bool saveContentsToFile(String fileName, String contents)) > options: #(+stringEncodings( fileName return , platformAPI contents) > > (And yes, I've probably badly mangled the options syntax) > Why not go for some generic escape sequence that can inject Smalltalk code into the marshaling? Right now e.g. primExport: aName value: aValue ^ self ffiCall: #(void moz_preferences_set_bool (short* aName, bool aValue)) is compiled as primExport: arg1 value: arg2 | tmp1 tmp2 | '<an unprintable nonliteral value>' invokeWithArguments: {(tmp2 := arg1 packToArity: 1). arg2} where '<an unprintable nonliteral value>' is the ExternalFunction object (it could usefully print itself ass a literal and then decompilation would be meaningful; there is already code in the Squeak FFI repository). Let's say one added {}'s as characters that can't ever appear in C parameter lists (of course and alas []'s can because of arrays)â¥ Then you could perhaps write primExport: aName value: aValue ^ self ffiCall: #(void moz_preferences_set_bool ( { short* aName } asUTF8String, bool aValue)) and have that generate a send of asUTF8String to arg1 or tmp2. One could surround the whole thing to apply a coercion to the return value, but there's no need because one can write e.g. primExport: aName value: aValue ^(self ffiCall: #(void moz_preferences_set_bool ( { short* aName } asUTF8String, bool aValue))) fromUTF8String So then there would be a generic mechanism for in jetting Smalltalk code into the marshaling and one could develop the string encoding support independently from the FFI. The options syntax however requires parsing support, more documentation, and constant extension to support new facilities, etc. Is much less verbose than having to manually convert Strings to the proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one > has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently used > API's that are broken if you try to use non-ascii. > > Cheers, > Henry > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- _,,,^..^,,,_ best, Eliot

Sept. 19, 2018