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

Re: [Pharo-dev] FloatArray

by Nicolas Cellier

Hi, I recommand inquiring about Smallapack, the Smalltalk interface to LAPACK, on squeaksource.com or github. You'll get the speed of numpy. There is a Metacello configuration. I have not checked the port on current Pharo, but I can reactivate if there is some interest. Le mer. 24 avr. 2019 Ã 05:55, Jimmie Houchin <jlhouchin(a)gmail.com> a Ã©crit : > I just recently discovered FloatArray by accident. > > I was close to having to use Python/Numpy due to considerable > performance differences. Performance is very important. > > In one of my test using a 212000 item array of floats and doing a sum on > each iteration through the array Pharo was taking 17 minutes verses > Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40 > seconds. That is acceptable. > > However when looking at the FloatArray comment it says it uses 32bit > floats. I need 64bit. I don't even know where to look to create 64bit > FloatArrays. I am surprised that they didn't get converted when moving > to 64bit Pharo. > > Would I need to change VM source? Compile a new VM and create image side > classes? I have not messed with VM in years. I do not know where the > FloatArray plugin would be. > > Any pointers would be a great help. If this needs to be on the vm-dev > list I can move it there. > > Thanks. > > Jimmie > > >

April 24, 2019

FloatArray

by Jimmie Houchin

I just recently discovered FloatArray by accident. I was close to having to use Python/Numpy due to considerable performance differences. Performance is very important. In one of my test using a 212000 item array of floats and doing a sum on each iteration through the array Pharo was taking 17 minutes verses Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40 seconds. That is acceptable. However when looking at the FloatArray comment it says it uses 32bit floats. I need 64bit. I don't even know where to look to create 64bit FloatArrays. I am surprised that they didn't get converted when moving to 64bit Pharo. Would I need to change VM source? Compile a new VM and create image side classes? I have not messed with VM in years. I do not know where the FloatArray plugin would be. Any pointers would be a great help. If this needs to be on the vm-dev list I can move it there. Thanks. Jimmie

April 24, 2019

Lectures at Montreal

by StÃ©phane Ducasse

Hello Just a little mail to mention that I will visit montreal and give some lectures 23 and 24 of May. If Montreal Smalltalkers want to discuss let me know. Stef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas 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

April 23, 2019

Re: [Pharo-dev] how implement isAbstract?

by Tudor Girba

Hi, I think that it is good that isAbstract does not mean isInstantiatable. However, I also think that isAbstract is too generic and that it would be better to have the tools implement their meaning rather than relying on a generic term. Cheers, Doru > On Apr 23, 2019, at 5:58 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > I ended up being surprised today that classes that have abstract > methods (send #subclassResponsibility) were returning false to > `isAbstract` and true to `hasAbstractMethods`. > I see that the behavior for isAbstract changed over the years: when it > was added [1] it was checking for abstract methods. Then it was > changed to always return false and allow overrides [2]. > > Is there an explicit need to have/keep `isAbstract` at the class > level? Users can still instantiate those classes, send message to them > and get SubclassResponsibility errors. Tools could implement specific > solutions for handling this. > > Cheers, > Andrei > > [1] https://github.com/pharo-project/pharo/pull/541/files > [2] https://github.com/pharo-project/pharo/pull/1090/files > > On Mon, Apr 1, 2019 at 3:02 PM Tim Mackinnon <tim(a)testit.works> wrote: >> >> 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) >> > -- www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

April 23, 2019

Re: [Pharo-dev] how implement isAbstract?

by Andrei Chis

I ended up being surprised today that classes that have abstract methods (send #subclassResponsibility) were returning false to `isAbstract` and true to `hasAbstractMethods`. I see that the behavior for isAbstract changed over the years: when it was added [1] it was checking for abstract methods. Then it was changed to always return false and allow overrides [2]. Is there an explicit need to have/keep `isAbstract` at the class level? Users can still instantiate those classes, send message to them and get SubclassResponsibility errors. Tools could implement specific solutions for handling this. Cheers, Andrei [1] https://github.com/pharo-project/pharo/pull/541/files [2] https://github.com/pharo-project/pharo/pull/1090/files On Mon, Apr 1, 2019 at 3:02 PM Tim Mackinnon <tim(a)testit.works> wrote: > > 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 23, 2019

[Pharo 8.0] Build #232: 3196-ObjectLayout: remove var compactClassIndex

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

There is a new Pharo build available! The status of the build #232 was: SUCCESS. The Pull Request #3208 was integrated: "3196-ObjectLayout: remove var compactClassIndex" Pull request url: https://github.com/pharo-project/pharo/pull/3208 Issue Url: https://github.com/pharo-project/pharo/issues/MarcusDenker Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 20, 2019

[Pharo 8.0] Build #231: 3206-NautilusRefactoring-contains-dead-code

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

There is a new Pharo build available! The status of the build #231 was: FAILURE. The Pull Request #3207 was integrated: "3206-NautilusRefactoring-contains-dead-code" Pull request url: https://github.com/pharo-project/pharo/pull/3207 Issue Url: https://github.com/pharo-project/pharo/issues/3206 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 20, 2019

Re: [Pharo-dev] [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by StÃ©phane Ducasse

> > > Hi Esteban, > > This is fantastic! We are eager to investigate how Roassal3 can run in an external window. this will possible even without GTK3 :) Stef > > Alexandre > >> On Apr 18, 2019, at 6:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: >> >> We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! >> >> Why we want a Spec 2.0 with different backends? >> >> There are reasons that converged to decide us to make it: >> >> â¢ First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). >> â¢ Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: >> â¢ Because there is still an important place for desktop applications market and most medium-size to big business still require them. >> â¢ Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). >> >> For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. >> >> Why Gtk3? >> >> There are some other important players in the "native widgets scene", so why we choose Gtk3? >> >> Again, several reasons were taken into account: >> >> â¢ Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. >> â¢ It is very mature and popular. >> â¢ It is made in plain C. >> >> Next step: tool migration >> >> The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: >> >> â¢ Old GT tools will be replaced by new Spec tools (while preserving its power). >> â¢ Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). >> â¢ Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. >> >> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) >> >> >> A small screenshot of the new Inspector (WIP): >> >> <Screenshot 2019-04-18 at 12.07.16.png> >> >> Esteban > > > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas 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

April 20, 2019

Re: [Pharo-dev] [squeak-dev] Any experts on using path in app bundles willing to help me?

by Esteban Lorenzano

> On 19 Apr 2019, at 20:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Fri, Apr 19, 2019 at 12:51 AM Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > yep. > The Pharo distribution uses install_name_tool to deal with it, if you want an example already in osvm code: > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64…> > > It's perhaps a case of "if it ain't broke, don't fixit", but I wonder if it would be better for Pharo to use Frameworks to hold dlls and Resources to hold plugin dlls/bindles. Contents/MacOS/Plugins is, I *think*, unique to Pharo. Yes, this is an inherited situation and I ignore the rationale behind it. I agree this way of distributing is not appropriate but I just didnât have the time to fix it (because after all, it is working so I always have something more urgent to do). Esteban > > > Esteban > >> On 18 Apr 2019, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> >> >> On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> Hi All, >> >> I have a plugin dependent on several support libraries that ma y be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do? >> >> Never mind. I think I've found what I need: >> https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4… <https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4…> >> https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath <https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath> >> >> _,,,^..^,,,_ >> best, Eliot > > > > > -- > _,,,^..^,,,_ > best, Eliot

April 20, 2019

Small Pharo developer contract

by ducasse

Hi guys This may interest some of you. Stef

April 20, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Alexandre Bergel

Hi Esteban, This is fantastic! We are eager to investigate how Roassal3 can run in an external window. Alexandre > On Apr 18, 2019, at 6:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: > > We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! > > Why we want a Spec 2.0 with different backends? > > There are reasons that converged to decide us to make it: > > â¢ First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). > â¢ Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: > â¢ Because there is still an important place for desktop applications market and most medium-size to big business still require them. > â¢ Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). > > For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. > > Why Gtk3? > > There are some other important players in the "native widgets scene", so why we choose Gtk3? > > Again, several reasons were taken into account: > > â¢ Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. > â¢ It is very mature and popular. > â¢ It is made in plain C. > > Next step: tool migration > > The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: > > â¢ Old GT tools will be replaced by new Spec tools (while preserving its power). > â¢ Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). > â¢ Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. > > And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) > > > A small screenshot of the new Inspector (WIP): > > <Screenshot 2019-04-18 at 12.07.16.png> > > Esteban

April 19, 2019

Re: [Pharo-dev] [squeak-dev] Any experts on using path in app bundles willing to help me?

by Eliot Miranda

Hi Esteban, On Fri, Apr 19, 2019 at 12:51 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yep. > The Pharo distribution uses install_name_tool to deal with it, if you want > an example already in osvm code: > > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64… > It's perhaps a case of "if it ain't broke, don't fixit", but I wonder if it would be better for Pharo to use Frameworks to hold dlls and Resources to hold plugin dlls/bindles. Contents/MacOS/Plugins is, I *think*, unique to Pharo. > Esteban > > On 18 Apr 2019, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi All, >> >> I have a plugin dependent on several support libraries that may be >> shared with other plugins. So I want the support libraries in a common >> place (TheVm.app/Contents/Frameworks) while the plugins themselves are >> bundles in TheVM.app/Contents/Resources. In allowing one to install plugin >> support libraries in TheVM.app/Contents/Frameworks I have to use the >> linker's -rpath feature to specify where dlopen may find the search >> libraries. The question i don't see an answer to in Apple's documentation >> is whether one uses -rpath when linking the plugin, or when linking the VM >> into which the plugin will be loaded, or both. Anybody ever done this and >> know definitively what to do? >> > > Never mind. I think I've found what I need: > > https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4… > https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath > > _,,,^..^,,,_ > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot

April 19, 2019

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

by ducasse

Our plan is to use Pango directly or indirectly (I do not remember exactly but via SDL2). But as everything it takes time. First the VM should get headless and more. Now if we would have some other sources of fundings Pharo would not be like it is now. Stef > On 19 Apr 2019, at 12:48, phil(a)highoctane.be wrote: > > Question: Can't we use some platform facility for renderering text on a surface instead of using FreeType? > > e.g. Windows https://docs.microsoft.com/en-us/windows/desktop/direct2d/direct2d-and-dire… <https://docs.microsoft.com/en-us/windows/desktop/direct2d/direct2d-and-dire…> > > Phil > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Garanti sans virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <x-msg://72/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > On Fri, Apr 19, 2019 at 12:12 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> On 17 Apr 2019, at 23:43, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Somebody should just decide that new version needs to be to back ported. > > Who is the somebody that would decide? If we have to live with Pharo 7.x for the next year (possibly a bit less) - some of the UI fixes would be much appreciated, particularly if its easy to do. > > Perhaps if we do a 7.0.4 we might do that? > > Tim > > p.s. 7.0.3 definitely doesnât fix the font glitch (sadly), and Guilleâs fix cause my image to deadlock for 3-5 minutes when I see it (which might actually be helpful - is it could conform a specific type of problem)

April 19, 2019

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

by ducasse

We will certainly back port the font glitches in P7.0 because it is important. Stef > On 18 Apr 2019, at 14:54, Tim Mackinnon <tim(a)testit.works> wrote: > > >> On 17 Apr 2019, at 23:43, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Somebody should just decide that new version needs to be to back ported. > > Who is the somebody that would decide? If we have to live with Pharo 7.x for the next year (possibly a bit less) - some of the UI fixes would be much appreciated, particularly if its easy to do. > > Perhaps if we do a 7.0.4 we might do that? > > Tim > > p.s. 7.0.3 definitely doesnât fix the font glitch (sadly), and Guilleâs fix cause my image to deadlock for 3-5 minutes when I see it (which might actually be helpful - is it could conform a specific type of problem)

April 19, 2019

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

by phil＠highoctane.be

Question: Can't we use some platform facility for renderering text on a surface instead of using FreeType? e.g. Windows https://docs.microsoft.com/en-us/windows/desktop/direct2d/direct2d-and-dire… Phil <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Garanti sans virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Apr 19, 2019 at 12:12 PM Tim Mackinnon <tim(a)testit.works> wrote: > > On 17 Apr 2019, at 23:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Somebody should just decide that new version needs to be to back ported. > > > Who is the somebody that would decide? If we have to live with Pharo 7.x > for the next year (possibly a bit less) - some of the UI fixes would be > much appreciated, particularly if its easy to do. > > Perhaps if we do a 7.0.4 we might do that? > > Tim > > p.s. 7.0.3 definitely doesnât fix the font glitch (sadly), and Guilleâs > fix cause my image to deadlock for 3-5 minutes when I see it (which might > actually be helpful - is it could conform a specific type of problem) >

April 19, 2019

Re: [Pharo-dev] Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"

by Serge Stinckwich

done : https://github.com/pillar-markup/pillar/issues/368 On Thu, Apr 18, 2019 at 4:15 PM ducasse <stepharo(a)netcourrier.com> wrote: > Hi serge > > I cannot check now but Pillar should be running in P7 64 bits without > problem. > I see many warnings too. > Can you open a bug entry? > Stef > > > On 18 Apr 2019, at 15:48, Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > > Any news on this ? This is only a 32 bits VM problem ? > Why when I install Pillar on MacOS, the 32bits VM is used and not 64bits > VM ? > > > On Fri, May 11, 2018 at 11:37 AM <serge.stinckwich(a)gmail.com> wrote: > >> Yes this is just a little bit annoying when you use Pillar because you >> have a lot of noise ;-) >> >> EnvoyÃ© de mon iPhone >> >> > Le 11 mai 2018 Ã 17:17, Esteban Lorenzano <estebanlm(a)gmail.com> a >> Ã©crit : >> > >> > This is a problem since more than one year. >> > Apple changed something on their apis and nobody knows how to fix it. >> > >> > but it is just a warning and you can work normally anyway :) >> > >> > cheers, >> > Esteban >> > >> >> On 11 May 2018, at 00:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> Yeah, I saw that for a while too, but my 64bit P7 VMs from the last >> couple of days don't do this anymore. >> >> I don't know why. >> >> >> >>> On 10 May 2018, at 23:53, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> >> >>> I noticed that recent Pharo 6.1 zero conf downloads show lots of >> these errors when you run the image in the terminal. Previous versions >> didnât do this - is this something to do with the latest vm upgrade? >> >>> >> >>> ./pharo-ui PagerDuty.image >> >>> >> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: >> Error: unsupported compressor 8 >> >>> >> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: >> Error: Unknown compression scheme encountered for file >> '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' >> >>> >> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: >> Error: unsupported compressor 8 >> >>> >> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: >> Error: Unknown compression scheme encountered for file >> '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' >> >>> >> >>> >> >>> Tim >> >> >> >> >> > >> > >> > > > -- > Serge Stinckwic > h > > Int. Research Unit > on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University > (SU) > French National Research Institute for Sustainable Development (IRD) > U > niversity of YaoundÃ© I, Cameroun > "Programs must be written for people to read, and only incidentally for > machines to execute." > https://twitter.com/SergeStinckwich > > > -- Serge Stinckwic âhâ Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) âSorbonne University (SU) French National Research Institute for Sustainable Development (IRD)â U âniversity of YaoundÃ© Iâ, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich â

April 19, 2019

Re: [Pharo-dev] Handling of deprecation packages

by Stephan Eggermont

Torsten Bergmann <astares(a)gmx.de> wrote: > The problem with the new vs. old streams seems to be that migration is > unfinished even for the base image. > Development already switched quickly to newer construction sites instead > of finishing these old ones. There are indeed several open issues with the new streams usage. I posted one on the handling of filing in fileouts by drag and drop. The issue I see with existing code is mostly that an object is used as a stream but is actually an information holder which understands much more than the stream protocol. Rewriting that code to use a streamHolder can be non-trivial. The fallback behavior of a readWriteStream opened on a read-only file is also not easy to get right. Stephan

April 19, 2019

Re: [Pharo-dev] Any experts on using path in app bundles willing to help me?

by Esteban Lorenzano

yep. The Pharo distribution uses install_name_tool to deal with it, if you want an example already in osvm code: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64…> Esteban > On 18 Apr 2019, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > Hi All, > > I have a plugin dependent on several support libraries that may be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do? > > Never mind. I think I've found what I need: > https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4… <https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4…> > https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath <https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath> > > _,,,^..^,,,_ > best, Eliot

April 19, 2019

Re: [Pharo-dev] Handling of deprecation packages

by Christopher Fuhrman

Hello all, Apologies if I am on the wrong page.... On Thu, Apr 18, 2019, 09:26 Torsten Bergmann <astares(a)gmx.de> wrote: > That's why also "Deprecated70" could not easily get removed. And there is > no guide in how to migrate to the new stream. > At least I do not know of something that could quickly explain on how to > convert. > The following guide was useful to me: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/Migratio…

April 19, 2019

Re: [Pharo-dev] [squeak-dev] Any experts on using path in app bundles willing to help me?

by Ben Coman

On Fri, 19 Apr 2019 at 01:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi All, >> >> I have a plugin dependent on several support libraries that may be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do? > > > Never mind. I think I've found what I need: > https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4… > https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath Interesting reading. thx for the links. cheers -ben

April 19, 2019

Re: [Pharo-dev] MQTT Data Broker & Client in Smalltalk

by John M McIntosh

Tim wrote a few tests, some of that support is in this code. No SUnits tho. What I did instead was rely on tests other people did to check for compliance to the specification for both the Client and Server in various language, Perl or Python. As we are providing a client or a server component it is 'easy' to drive other people's spec tests to the unix socket. .... John M. McIntosh. Corporate Smalltalk Consulting LtdÂ https://www.linkedin.com/in/smalltalk âââââââ Original Message âââââââ On Tuesday, April 16, 2019 12:28 AM, ducasse <stepharo(a)netcourrier.com> wrote: > I like to see tests there :) > Iâm trying to write tests for the sound package and this is an kind of strange exercise. > > Stef > > > On 16 Apr 2019, at 09:23, Sven Van Caekenberghe sven(a)stfx.eu wrote: > > > > > On 16 Apr 2019, at 08:10, ducasse stepharo(a)netcourrier.com wrote: > > > Thanks John > > > Great news. > > > Do you know how different it is from https://github.com/svenvc/mqtt. > > > I saw that Sven have some tests. I did not see if he has the server part. > > > > Yes, that is correct: what I once did was a new MQTT client, an MQTT broker is a server that manages the distribution of messages. > > > > > Stef > > > > > > > On 16 Apr 2019, at 04:00, John M McIntosh johnmci(a)smalltalkconsulting.com wrote: > > > > Today we are pushing out a MQTT V311 client and data broker we've written in pure smalltalk. It is based on Tim Rowledge's earlier work, but as far as I know the only data broker in smalltalk. > > > > https://github.com/LabWare/MQTT-broker > > > > .... > > > > John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk

April 18, 2019

Re: [Pharo-dev] Any experts on using path in app bundles willing to help me?

by Eliot Miranda

On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > I have a plugin dependent on several support libraries that may be > shared with other plugins. So I want the support libraries in a common > place (TheVm.app/Contents/Frameworks) while the plugins themselves are > bundles in TheVM.app/Contents/Resources. In allowing one to install plugin > support libraries in TheVM.app/Contents/Frameworks I have to use the > linker's -rpath feature to specify where dlopen may find the search > libraries. The question i don't see an answer to in Apple's documentation > is whether one uses -rpath when linking the plugin, or when linking the VM > into which the plugin will be loaded, or both. Anybody ever done this and > know definitively what to do? > Never mind. I think I've found what I need: https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4… https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath _,,,^..^,,,_ best, Eliot

April 18, 2019

Any experts on using path in app bundles willing to help me?

by Eliot Miranda

Hi All, I have a plugin dependent on several support libraries that may be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do? _,,,^..^,,,_ best, Eliot

April 18, 2019

Re: [Pharo-dev] Roassal Animations

by Alexandre Bergel

Yes, that is the idea Alexandre > On Apr 18, 2019, at 1:42 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Great! Will this be part of the minimal roassal? That could improve documentation quite a bit. > > Norbert > > Am 18.04.2019 um 01:05 schrieb Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > >> Hi! >> >> Just as a follow up, we have a UML diagram builder for Roassal3. >> >> You can load Roassal3 using: >> Metacello new >> baseline: 'Roassal3'; >> repository: 'github://ObjectProfile/Roassal3/src <github://ObjectProfile/Roassal3/src>'; >> load. >> >> As indicated on https://github.com/ObjectProfile/Roassal3 <https://github.com/ObjectProfile/Roassal3> >> >> An UML class diagram can be open using: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> | builder pharoClassesToBeVisualized | >> >> "Zooming and position of the view can be controled using the keys: >> I O Space >> Arrows >> " >> >> pharoClassesToBeVisualized := >> TSAbstractLine >> withAllSubclasses. >> >> builder := >> RSUMLClassBuilder >> new. >> builder classes: pharoClassesToBeVisualized. >> >> builder classDescriptor >> methods: [ :cls | | methods | >> methods := cls methods sorted: [ :a :b | >> a selector < b selector ] ]. >> >> builder build. >> builder view when: >> TSExtentChangedEvent >> do: [ builder view zoomToFit ]. >> builder open >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> We now do have a support for UML class diagrams and we can easily add new features, if wanted. >> >> >> >> Cheers, >> Alexandre & Milton >> >> >>> On Mar 27, 2019, at 3:37 PM, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >>> >>> >>> >>>> On 27 Mar 2019, at 18:27, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>>> >>>> >>>> From: Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> >>>> Subject: Re: [Pharo-dev] Roassal Animations >>>> Date: 27 March 2019 at 18:27:28 CET >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >>>> >>>> >>>> Thanks to all of you for your nice words. >>>> These posts are a teaser of what is coming. Code of each animation is part of Roassal3. Note that we have made no official announcement, simply because Roassal3 is still well behind Roassal2 in terms of offered features. Actually, you cannot do much with Roassal3, beside having cool visualization. >>>> >>>> We will tell you more soon, once we have a UML renderer and code dependency visualizer :-) >>>> >>>> We are currently working on a nice distribution that can be shipped within Pharo 8. >>> >>> :) >>> >>> >>

April 18, 2019

Re: [Pharo-dev] Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"

by ducasse

Hi serge I cannot check now but Pillar should be running in P7 64 bits without problem. I see many warnings too. Can you open a bug entry? Stef > On 18 Apr 2019, at 15:48, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Any news on this ? This is only a 32 bits VM problem ? > Why when I install Pillar on MacOS, the 32bits VM is used and not 64bits VM ? > > > On Fri, May 11, 2018 at 11:37 AM <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: > Yes this is just a little bit annoying when you use Pillar because you have a lot of noise ;-) > > EnvoyÃ© de mon iPhone > > > Le 11 mai 2018 Ã 17:17, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : > > > > This is a problem since more than one year. > > Apple changed something on their apis and nobody knows how to fix it. > > > > but it is just a warning and you can work normally anyway :) > > > > cheers, > > Esteban > > > >> On 11 May 2018, at 00:14, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> > >> Yeah, I saw that for a while too, but my 64bit P7 VMs from the last couple of days don't do this anymore. > >> I don't know why. > >> > >>> On 10 May 2018, at 23:53, Tim Mackinnon <tim(a)testit.works> wrote: > >>> > >>> I noticed that recent Pharo 6.1 zero conf downloads show lots of these errors when you run the image in the terminal. Previous versions didnât do this - is this something to do with the latest vm upgrade? > >>> > >>> ./pharo-ui PagerDuty.image > >>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 > >>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' > >>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 > >>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' > >>> > >>> > >>> Tim > >> > >> > > > > > > > -- > Serge Stinckwich > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University (SU) > French National Research Institute for Sustainable Development (IRD) > University of YaoundÃ© I, Cameroun > "Programs must be written for people to read, and only incidentally for machines to execute." > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich>

April 18, 2019