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

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

by Christophe Demarey

Hi Sean, There was a similar issue on Linux: https://github.com/pharo-project/pharo-launcher/issues/307 It works with 1.7.2 on my laptop but Iâm able to reproduce the error if I put PharoLauncher in a location containing non ASCII characters, I get the same error. To fix this, in PL image, edit VirtualMachine>>#fullPath with: ^(self getSystemAttribute: 0) asByteArray utf8Decoded It is a problem with the Pharo image. Encoding is not managed everywhere. Tell me if it fixes your problem. Christophe > Le 13 fÃ©vr. 2019 Ã 03:42, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > Just dl-ed launcher from Pharo.org. Attempting to open Iceberg gives: > "NotFound: Could not find repository from '/'". Seems to be coming from > libgit. Anyone else seeing this? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 13, 2019

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

by Max Leske

Nope. I downloaded launcher just 20 minutes ago on Mojave and am using it without problems. Where did you extract it to? Did you extract it as a different user? Did you try to run it from within the .dmg directly? Max On 13 Feb 2019, at 3:42, Sean P. DeNigris wrote: > Just dl-ed launcher from Pharo.org. Attempting to open Iceberg gives: > "NotFound: Could not find repository from '/'". Seems to be coming > from > libgit. Anyone else seeing this? > > > > ----- > Cheers, > Sean > -- > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 13, 2019

Re: [Pharo-dev] External Module not found

by Pierce Ng

On Wed, Feb 13, 2019 at 12:12:39AM +0000, Moussa Saker via Pharo-dev wrote: > am using a Pharo 7 image and an elementary os 64bits distribution > (based on Ubuntu 18.04), i was working on my project and when trying > to execute it i encountered this problem. Click on the debug button, look around and it'll tell you _which_ external module cannot be found. From context it looks like Cairo, so try installing Cairo runtime libraries, but before that confirm by clicking on the debug button.

Feb. 13, 2019

Re: [Pharo-dev] File problems in Pharo 8

by Alistair Grant

Hi Cyril, On Tue, 12 Feb 2019 at 19:41, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 12/02/2019 Ã 18:56, Alistair Grant a Ã©crit : > > Hi Cyril, > > > > ... > > > > However any application that iterates over a large number of files could > > well be slower because the Guide / Visitor system retrieves entries. > > > > Thank you for the detailed explanation! > > > Do you know how many files are being deleted when the system feels > > slower? > > I was committing in Iceberg that is a Filetree repository. My change > impacted multiple package thus I would say it should be around 2500 > files and 500 folders. I wrote a class to measure the time taken by the Visitor / Guide - it's basically the same as the DeleteVisitor but just counts the number of files visited. Running this on a directory that contains 82331 files including 10169 directories. My 6 year old Dell XPS 13 (i7, SSD, 8G RAM) gives the following average times: Pharo 7: 3.7 seconds Pharo 8: 2.6 seconds I've attached the class below. > > It would be straightforward to modify the directory iteration primitives > > to only answer the file name instead of all attributes. I'll have a > > look and see how easy it would be to modify the Guide / Visitor objects > > to retrieve only file names instead of entire entries. > > > > So if possible it would make file copy/deletion even faster than before > IIUC? That would be really great! The Guide / Visitor framework uses file attributes to navigate the tree, so retrieving only file names wouldn't be useful. But I did notice that the entries weren't being initialised properly, so after fixing that bug the average run time for Pharo 8 drops: Pharo 8: 1.7 seconds I'll submit a PR with this fix. I also realised I inadvertently changed the behaviour of DeleteVisitor slightly. In Pharo 7 the Visitor will descend in to a symbolic link that points to a directory, in Pharo 8 it doesn't. This prevents the system from entering an infinite loop if the symbolic link points to the directory containing the link, but means that the set of files visited may be different. Pharo 7 may visit additional files that are currently skipped by Pharo 8, or it may visit some multiple times. I'll raise this as a separate discussion as I'm not sure that simply reverting to the old behaviour is a good idea. Cheers, Alistair

Feb. 13, 2019

Can't Install Launcher on Mac Mojave

by Sean P. DeNigris

Just dl-ed launcher from Pharo.org. Attempting to open Iceberg gives: "NotFound: Could not find repository from '/'". Seems to be coming from libgit. Anyone else seeing this? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 13, 2019

External Module not found

by Moussa Saker

Hello everyone Â Â am using a Pharo 7 image and an elementary os 64bits distribution (based on Ubuntu 18.04), i was working on my project and when trying to execute it i encountered this problem. do you have any solution or suggestion to made ? Moussa.

Feb. 13, 2019

[Pharo 8.0] Build #68: 2467-cleanup-temp-var-reading

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

There is a new Pharo build available! The status of the build #68 was: SUCCESS. The Pull Request #2496 was integrated: "2467-cleanup-temp-var-reading" Pull request url: https://github.com/pharo-project/pharo/pull/2496 Issue Url: https://pharo.fogbugz.com/f/cases/2467 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2019

[Pharo 8.0] Build #67: 2502-Unused-temporary-variable-in-FTTableContainerMorph

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

There is a new Pharo build available! The status of the build #67 was: FAILURE. The Pull Request #2503 was integrated: "2502-Unused-temporary-variable-in-FTTableContainerMorph" Pull request url: https://github.com/pharo-project/pharo/pull/2503 Issue Url: https://pharo.fogbugz.com/f/cases/2502 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2019

Re: [Pharo-dev] File problems in Pharo 8

by Cyril Ferlicot D.

Le 12/02/2019 Ã 18:56, Alistair Grant a Ã©critÂ : > Hi Cyril, > > I'm glad you're able to commit now. :-) > > A few comments on the performance: > > I haven't done a performance comparison for a while, and there have been > a few changes in the plugin, so I'll keep it qualitative for now and try > and run some more tests soon. > > FileReference>>exists should be significantly faster than before. It > used to retrieve all the file attributes (an array of values, mostly > integers and booleans). Now it just returns a boolean. > > Retrieving individual file attributes should also be faster. E.g. > FileReference>>modificationTime also retrieved all file attributes and > threw away everything except the desired attribute. Now it answers just > the requested attribute. > > Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit > slower because more information is being retrieved than previously. > > FileReference>>exists gets called a lot. So do requests for individual > file attributes. So my perception was that overall the system would > probably be a bit faster than previously. > > However any application that iterates over a large number of files could > well be slower because the Guide / Visitor system retrieves entries. > Thank you for the detailed explanation! > Do you know how many files are being deleted when the system feels > slower? I was committing in Iceberg that is a Filetree repository. My change impacted multiple package thus I would say it should be around 2500 files and 500 folders. > > It would be straightforward to modify the directory iteration primitives > to only answer the file name instead of all attributes. I'll have a > look and see how easy it would be to modify the Guide / Visitor objects > to retrieve only file names instead of entire entries. > So if possible it would make file copy/deletion even faster than before IIUC? That would be really great! > Cheers, > Alistair > -- Cyril Ferlicot https://ferlicot.fr

Feb. 12, 2019

Re: [Pharo-dev] File problems in Pharo 8

by Alistair Grant

Hi Cyril, On Tue, 12 Feb 2019 at 11:57, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Cyril, > > > > In not at my PC at the moment, sorry. > > > > Can you try with vmLatest80? > > > > curl get.pharo.org/64/vmLatest80 | bash > > > > This looks like an issue I resolved recently. > > > > I can commit with this vm. Thank you. I'm glad you're able to commit now. :-) > I have the impression that the commit takes longer now but I don't > have any bench. (maybe it's just my imagination). A few comments on the performance: I haven't done a performance comparison for a while, and there have been a few changes in the plugin, so I'll keep it qualitative for now and try and run some more tests soon. FileReference>>exists should be significantly faster than before. It used to retrieve all the file attributes (an array of values, mostly integers and booleans). Now it just returns a boolean. Retrieving individual file attributes should also be faster. E.g. FileReference>>modificationTime also retrieved all file attributes and threw away everything except the desired attribute. Now it answers just the requested attribute. Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit slower because more information is being retrieved than previously. FileReference>>exists gets called a lot. So do requests for individual file attributes. So my perception was that overall the system would probably be a bit faster than previously. However any application that iterates over a large number of files could well be slower because the Guide / Visitor system retrieves entries. Do you know how many files are being deleted when the system feels slower? It would be straightforward to modify the directory iteration primitives to only answer the file name instead of all attributes. I'll have a look and see how easy it would be to modify the Guide / Visitor objects to retrieve only file names instead of entire entries. Cheers, Alistair

Feb. 12, 2019