February 2019 - Pharo-users

Re: [Pharo-users] pathSegments of workingDirectory?

by David Richards

Perfect. Many thanks. On Thu, 14 Feb 2019 at 05:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 14 Feb 2019, at 13:55, David Richards <david.i.richards.iii(a)gmail.com> > wrote: > > > > Hi Sven, > > > > Your second example expression fails for 'workingDirectory': > > > > FileLocator workingDirectory resolve pathSegments > > ==> #() > > > > It works fine for FileLocator home but not for FileLocator > workingDirectory . > > > > Your first expression will produce the desired result, if ensourcelled > with syntactimancy: > > > > FileLocator workingDirectory pathString asFileReference pathSegments > > > > This smells a lot like an edge case to me. But perhaps it is the Way of > Smalltalk. > > Like Alistair said, it should be > > FileLocator workingDirectory asAbsolute pathSegments. > > because it is a relative path. > > > Thanks > > David > > > > > > > > On Wed, 13 Feb 2019 at 22:46, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > David, > > > > > On 14 Feb 2019, at 03:56, David Richards < > david.i.richards.iii(a)gmail.com> wrote: > > > > > > Hi community, > > > > > > Consider: > > > > > > | file | > > > file := FileLocator workingDirectory . > > > file fullName . > > > "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit > stable)'" > > > file pathSegments . > > > "==> #()" > > > > > > How do we obtain path segments for the working directory? > > > > > > Is this an edge case where pathSegments does not return a semantically > consistent value? > > > > > > Thanks > > > David > > > > A FileLocator is a bit special, it is usable, but not yet fully > realised, more abstract. > > > > You can use resolve. Consider: > > > > FileLocator home pathString. > > "'/Users/sven'" > > > > FileLocator home resolve pathSegments. > > "#('Users' 'sven')" > > > > HTH, > > > > Sven > > > > > > >

Feb. 14, 2019

Re: [Pharo-users] Status of XML Support's move to GitHub

by Sven Van Caekenberghe

Hi again, > On 10 Jan 2019, at 16:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > What is the status of XML Support's move to GitHub ? > Many people were pro, has anything been done ? > It would be very nice. > > Sven I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. This is just the bare minimum, a proof of concept, with new, much simplified baselines. It was the last project that I depend on and I wanted it in GitHub for my own purposes. The default load of XMLParser includes XMLWriter, the tests and the GT extensions. All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to load reasonably fast. I want to stress that this is not a fork, nor the end of this conversion. I have a lot of respect for this high quality, solid code base and want this important piece of code to move forward. I hope others will help. Sven

Feb. 14, 2019

Re: [Pharo-users] How do I find the RPackageTag of a class?

by Tim Mackinnon

Actually - Iâve realised that Calypso can give me the tag name from its context - (aToolContext lastSelectedClassGroup). However it does highlight a very strange package/tag design. Are you not supposed to be easily able to derive RPacakgeTags? Tim > On 14 Feb 2019, at 13:19, Tim Mackinnon <tim(a)testit.works> wrote: > > Iâm trying to understand how RPackage and RPackageTag work in Pharo7? It seems different than Pharo6 at least with Nautilus (vs Calypso) - as previously the Nautilus UI gave me the RPacakgeTag, and I could just work with that. Calypso doesnât seem to give me the tag object, but if I have a known class and I want to know its RPackageTag I canât see how you do it? It all seems rather messyâ¦. > > I can ask a class for its category - which just gives me a symbol of the form âmypackage-tagnameâ, and if I ask a class for its package, it will give me an RPackage(myPackage) - but that RPackage has a set of RPackageTags which just use the tagname (so not prefixed with "mypackage-â)? So am I really supposed to split the category name on â-â myself, and then select the correct RPackageTag? > > If I look at the RPackageTag tests - they all seem to use hard coded values and so donât really show you how you deal with the question above? > > It really seems quite messy? > > I naively thought that if I wanted a browser extension to deal with a selected package tag - and file out some classes in that tag (for exercism) - I could easily get the RPackageTag from any class and then use it? > > Tim

Feb. 14, 2019

How do I find the RPackageTag of a class?

by Tim Mackinnon

Iâm trying to understand how RPackage and RPackageTag work in Pharo7? It seems different than Pharo6 at least with Nautilus (vs Calypso) - as previously the Nautilus UI gave me the RPacakgeTag, and I could just work with that. Calypso doesnât seem to give me the tag object, but if I have a known class and I want to know its RPackageTag I canât see how you do it? It all seems rather messyâ¦. I can ask a class for its category - which just gives me a symbol of the form âmypackage-tagnameâ, and if I ask a class for its package, it will give me an RPackage(myPackage) - but that RPackage has a set of RPackageTags which just use the tagname (so not prefixed with "mypackage-â)? So am I really supposed to split the category name on â-â myself, and then select the correct RPackageTag? If I look at the RPackageTag tests - they all seem to use hard coded values and so donât really show you how you deal with the question above? It really seems quite messy? I naively thought that if I wanted a browser extension to deal with a selected package tag - and file out some classes in that tag (for exercism) - I could easily get the RPackageTag from any class and then use it? Tim

Feb. 14, 2019

Re: [Pharo-users] pathSegments of workingDirectory?

by Sven Van Caekenberghe

> On 14 Feb 2019, at 13:55, David Richards <david.i.richards.iii(a)gmail.com> wrote: > > Hi Sven, > > Your second example expression fails for 'workingDirectory': > > FileLocator workingDirectory resolve pathSegments > ==> #() > > It works fine for FileLocator home but not for FileLocator workingDirectory . > > Your first expression will produce the desired result, if ensourcelled with syntactimancy: > > FileLocator workingDirectory pathString asFileReference pathSegments > > This smells a lot like an edge case to me. But perhaps it is the Way of Smalltalk. Like Alistair said, it should be FileLocator workingDirectory asAbsolute pathSegments. because it is a relative path. > Thanks > David > > > > On Wed, 13 Feb 2019 at 22:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > David, > > > On 14 Feb 2019, at 03:56, David Richards <david.i.richards.iii(a)gmail.com> wrote: > > > > Hi community, > > > > Consider: > > > > | file | > > file := FileLocator workingDirectory . > > file fullName . > > "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'" > > file pathSegments . > > "==> #()" > > > > How do we obtain path segments for the working directory? > > > > Is this an edge case where pathSegments does not return a semantically consistent value? > > > > Thanks > > David > > A FileLocator is a bit special, it is usable, but not yet fully realised, more abstract. > > You can use resolve. Consider: > > FileLocator home pathString. > "'/Users/sven'" > > FileLocator home resolve pathSegments. > "#('Users' 'sven')" > > HTH, > > Sven > >

Feb. 14, 2019

Re: [Pharo-users] pathSegments of workingDirectory?

by David Richards

Hi Sven, Your second example expression fails for 'workingDirectory': FileLocator workingDirectory resolve pathSegments ==> #() It works fine for FileLocator home but not for FileLocator workingDirectory . Your first expression will produce the desired result, if en*source*lled with syntactimancy: FileLocator workingDirectory pathString asFileReference pathSegments This smells a lot like an edge case to me. But perhaps it is the Way of Smalltalk. Thanks David On Wed, 13 Feb 2019 at 22:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > David, > > > On 14 Feb 2019, at 03:56, David Richards <david.i.richards.iii(a)gmail.com> > wrote: > > > > Hi community, > > > > Consider: > > > > | file | > > file := FileLocator workingDirectory . > > file fullName . > > "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'" > > file pathSegments . > > "==> #()" > > > > How do we obtain path segments for the working directory? > > > > Is this an edge case where pathSegments does not return a semantically > consistent value? > > > > Thanks > > David > > A FileLocator is a bit special, it is usable, but not yet fully realised, > more abstract. > > You can use resolve. Consider: > > FileLocator home pathString. > "'/Users/sven'" > > FileLocator home resolve pathSegments. > "#('Users' 'sven')" > > HTH, > > Sven > > >

Feb. 14, 2019

Quality assistant

by Hilaire

Hi How to turn off the quality assitant in the calypso browser? I don't find anymore the option in the settings browser. Hilaire -- Dr. Geo http://drgeo.eu

Feb. 14, 2019

Re: [Pharo-users] Working VM for OS X for Pharo 7

by Hilaire

I know what you are describing, for example cairo can be impacted. My self questioning was: Does the VM rely on the host git library or is the one shipped with the vm sufficient? Best, Hilaire Le 14/02/2019 Ã 10:33, Alistair Grant a Ã©critÂ : > On Linux it is almost always: > > - A library isn't found because the search path is wrong, i.e. > LD_LIBRARY_PATH needs to be set, and/or > - there's a missing dependency. > > The ldd command helps track these down by showing which dependencies > are missing. > > On Linux you need to be careful because the pharo script sets > upÂ LD_LIBRARY_PATH, so ldd may show something as missing which will be > found when pharo is actually run, e.g libssh. > > Cheers, > Alistair > (on phone) -- Dr. Geo http://drgeo.eu

Feb. 14, 2019

Re: [Pharo-users] Working VM for OS X for Pharo 7

by Alistair Grant

On Thu., 14 Feb. 2019, 10:07 Hilaire, <hilaire(a)drgeo.eu> wrote: > Hopefully I may have access to a mac tomorrow to test your request, or > it will be in 10 days. > > On the other hand, is not libgit integrated in the VM, so I don't > understand how it can be related to system update? Or is libgit a > binding to a system git or something like that? > On Linux it is almost always: - A library isn't found because the search path is wrong, i.e. LD_LIBRARY_PATH needs to be set, and/or - there's a missing dependency. The ldd command helps track these down by showing which dependencies are missing. On Linux you need to be careful because the pharo script sets up LD_LIBRARY_PATH, so ldd may show something as missing which will be found when pharo is actually run, e.g libssh. Cheers, Alistair (on phone) > >

Feb. 14, 2019

Re: [Pharo-users] pathSegments of workingDirectory?

by Sven Van Caekenberghe

Haha, I didn't pay enough attention to see the difference between #workingDirectory and #home. Thanks for the clarification ! BTW, what I also wanted to add is that independent of the precise type you can always use the instances to do your job (open it, move it, etc ...). > On 14 Feb 2019, at 08:18, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi David & Sven, > > On Thu, 14 Feb 2019 at 07:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> David, >> >>> On 14 Feb 2019, at 03:56, David Richards <david.i.richards.iii(a)gmail.com> wrote: >>> >>> Hi community, >>> >>> Consider: >>> >>> | file | >>> file := FileLocator workingDirectory . >>> file fullName . >>> "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'" >>> file pathSegments . >>> "==> #()" >>> >>> How do we obtain path segments for the working directory? >>> >>> Is this an edge case where pathSegments does not return a semantically consistent value? >>> >>> Thanks >>> David >> >> A FileLocator is a bit special, it is usable, but not yet fully realised, more abstract. >> >> You can use resolve. Consider: >> >> FileLocator home pathString. >> "'/Users/sven'" >> >> FileLocator home resolve pathSegments. >> "#('Users' 'sven')" > > What Sven wrote is, of course, correct. But this is also an edge case: > > FileLocator workingDirectory resolve pathSegments. > "#()" > > The reason in this case is because the directory is stored as a > RelativePath. A RelativePath is resolved against the working > directory, which in this case is the same thing, so no movement is > required, and an empty path is used. > > You can also try: > > FileLocator workingDirectory asAbsolute pathSegments. > " #('home' 'alistair' 'pharo8' 'pharo64.04')" > > Just for added confusion, FileLocator class>>workingDirectory is also > a special case. Most of the methods in the origins protocol return an > instance of FileLocator. But FileLocator class>>workingDirectory > returns an instance of FileReference. > > HTH, > Alistair

Feb. 14, 2019