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

IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

by Torsten Bergmann

Hi, Windows users of Pharo have been hit by an Iceberg error "IceGenericError: failed to stat file ... The filename or extension is too long" as seen in attached screenshot (for instance when loading Seaside from the original SeasideSt/Seaside master branch). Initially the long filename (who make trouble on Windows according to the message) were blamed - and it was suggested to have Seaside (or other projects) in Tonel format. Johan wanted to try this - but initially it was not possible as Esteban had to provide a fix for the Tonel converter first. This is now available. Following this fix today Johan provided a "tonel" branch of Seaside to check. Roelof Wobben and Mike Davis tried with me on Discord a few combinations and it seems there is a different cause. It seems to be more related to having the image or image path including spaces AND dots. So for instance Pharo Launcher suggests the download of Pharo 7 from the official distribution to be named "Pharo 7.0 - 32bit (stable)". When you just accept the name the Pharo Launcher suggests then you may hit the problem. When you start such an image and try to load the FileTree (master) or Tonel version (tonel branch) of Seaside using Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load or Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:tonel/repository'; load you will get the error. If you use "Foo" as the name for image it seems to work. Requires some more testing but I guess it is related to the naming in Pharo Launcher with "dots" AND "spaces" instead of the long filenames. "pharo 7.0 (stable)" fails "seaside.test" works "seaside test" works also "seaside. test" works also "seaside-test" works also "seaside(test)" works also Maybe more people can try other combinations on their Windows machines too. If our finding is true it would be good if Laucher on Windows could nuke the dot/space combinations for instance by using underlines. Thanks T. (aka astares)

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Tim Mackinnon

On 1 Apr 2019, at 09:54, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Or, if the class has subclasses, one could get a suggestion/action to > implement the missing method as > missingMethod > ^self subclassResponsibility > > Which also has the benefit of working nicely with the "expected (or was that > "missing"?) protocol" functionality. > Unless you meant something else? I donât know if we are all talking about the same thing. In my image, I have a class where I havenât got the isAbstract defined, and so Calypso shows a red message - as it thinks Iâm supposed to implement #execute (if it knows my intent that my class is abstract, then it doesnât show the red warning). I think this is Denisâ question? Sure, if I choose to use the abstract class, then its my choice, but as a lint checker -having useful warnings is helpful. But it is a nuisance defining isAbstract - and Iâd almost prefer it assumes its abstract in this case (the normal expectations?) unless I tag it as concrete and signal to users that they might consider using my class (its probably a design smell these days though)

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Henrik Sperre Johansen

I guess I could have added additional constraints "and the missing method is called from a method on the "abstract class", and the missing method is defined on subclasses", but I thought that implicit from the context :) To me, an abstract class is one you either can't instatiate (through overriding new), or one containing methods which delegate to methods implemented by subclasses, so it makes no sense to use instances of the class itself. The use case is addressed at the method level, yes, but it *is* for the typical meaning associated with a class being abstract, at least to me. Cheers, Henry Tudor Girba-2 wrote > This is a use case that is addressed at the level of the method, not of a > class. > > I see the issue similarly to Stef: as I can utilize a class, it has little > meaning to call it abstract. A missing method has a different meaning from > the typical meaning associated with a class being abstract. > > Cheers, > Doru > > >> On Apr 1, 2019, at 10:54 AM, Henrik Sperre Johansen < > henrik.s.johansen@ > > wrote: >> >> Tim Mackinnon wrote >>> Calypso warns you about missing methods if it doesnât understand a class >>> is abstract, so itâs useful to avoid those warnings otherwise you become >>> desensitised to them. >>> >>> Tim >> >> Or, if the class has subclasses, one could get a suggestion/action to >> implement the missing method as >> missingMethod >> ^self subclassResponsibility >> >> Which also has the benefit of working nicely with the "expected (or was >> that >> "missing"?) protocol" functionality. >> Unless you meant something else? >> >> Cheers, >> Henry >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > -- > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Tudor Girba

This is a use case that is addressed at the level of the method, not of a class. I see the issue similarly to Stef: as I can utilize a class, it has little meaning to call it abstract. A missing method has a different meaning from the typical meaning associated with a class being abstract. Cheers, Doru > On Apr 1, 2019, at 10:54 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Tim Mackinnon wrote >> Calypso warns you about missing methods if it doesnât understand a class >> is abstract, so itâs useful to avoid those warnings otherwise you become >> desensitised to them. >> >> Tim > > Or, if the class has subclasses, one could get a suggestion/action to > implement the missing method as > missingMethod > ^self subclassResponsibility > > Which also has the benefit of working nicely with the "expected (or was that > "missing"?) protocol" functionality. > Unless you meant something else? > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

April 1, 2019

[Pharo 8.0] Build #206: Revert "Integrating UndefinedClass, ClassDefinition and modified classBuilderâ¦"

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #206 was: SUCCESS. The Pull Request #3117 was integrated: "Revert "Integrating UndefinedClass, ClassDefinition and modified classBuilderâ¦"" Pull request url: https://github.com/pharo-project/pharo/pull/3117 Issue Url: https://github.com/pharo-project/pharo/issues/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Henrik Sperre Johansen

Tim Mackinnon wrote > Calypso warns you about missing methods if it doesnât understand a class > is abstract, so itâs useful to avoid those warnings otherwise you become > desensitised to them. > > Tim Or, if the class has subclasses, one could get a suggestion/action to implement the missing method as missingMethod ^self subclassResponsibility Which also has the benefit of working nicely with the "expected (or was that "missing"?) protocol" functionality. Unless you meant something else? Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 1, 2019