February 2019 - Pharo-users

[ANN] Buoy v5.0.0 released!

by Gabriel Cotelli

Buoy <https://github.com/ba-st/Buoy>, the project aiming to complement Pharo <https://www.pharo.org> adding useful extensions reached itâs 5.0.0 version. The supported Pharo versions are 6.1 â 32 bits and 7.0 â 32 & 64 bits. The breaking changes are just in the package organization, so you may have to adapt your baseline dependencies but the rest of the code is backwards compatible with version 4. You can see the detailed release notes here. <https://medium.com/ba-st/buoy-v5-0-0-released-9a26da396ceb> Regards, Gabriel

Feb. 21, 2019

Re: [Pharo-users] Windows 64bit, long filename issue but after a second load, how to categorise and report this?

by Tim Mackinnon

Hi Ben - while I understand the description below - why would it work the first time (no errors) and then fail the second time in a fresh image? Are we really sure its just down to non-determinism of the load process (possibly - but it seems very suspicious to me). There is something more fishy about windows going on I suspectâ¦ I will track down the Exercism dependencies to see if any of them are FileTree - having said that, on OSX (where it loads cleanly - I would expect to be able to find one of those methods in my image - but again I canât? They look like valid methods - but why arenât they in my image? Its like the load process is downloading other stuff on its own and then not loading that into the image? Iâm just worried that we keep blaming windows (and yes its dumb having a file length restriction I this day and age) - but maybe we are missing another problem too? Tim > On 21 Feb 2019, at 13:20, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Thu, 21 Feb 2019 at 20:36, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > We noticed a weird problem when testing the pharo exercism project. > > When loading on Windows10 in a fresh 64bit image with the following evaluate in the playground: > > Metacello new > baseline: 'Exercism'; > repository: 'github://exercism/pharo-smalltalk:master/dev/src'; > load. > > The project seemed to load correctly (but we seemed to hit an issue with an http submit giving a 404 error - which weirdly works in 32bit and OSX 64/32). Anyway - the real question here is that when trying to reproduce this in a second fresh 64bit image 2 users now have reported getting the long filename error: > > LGit_GIT_EEXISTS: Failed to stat file 'C:/Users/sam/Documents/Pharo/images/exercism-test-run-7.0-32...stance/testRaiseUnexpectedMessageWhenTooMuchMessages.st': The filename or extension is too long. > > And the second user got the same but with a different filename: ruleRBUtlitiesMethodsRuleV1FalsePositve.st > > These files are both method names which indicates FileTree format rather than Tonel (and these "failed to stat file" errors on Windows is one of the reasons for the move to Tonel). It may be from one of the dependencies that are pulled in. To identify which, search for that file under `pharo-local/iceberg` directory. I believe the repo may have been cloned successfully, its just the libgit binary can't `stat` long filenames. If that turns out the be untrue, use commandline git to complete the clone and you will likely see it. > > > I know there is a long standing problem with Windows and file path lengths - but why would it work the first time and then subsequently fail in fresh installs? Is something being cached on windows that isnât on other platforms? (Writing this - Iâm wondering if there is that shared pharo Iceberg setting for Share repos that might be implicated?) > > Also - given Exercism is in Tonel format and those files arenât in exercism, and in fact Iâm struggling to find where they are defined > > as above. > > > (my images donât have them) - there is something very weird going on. > > I wonder if we have another error that is masking all of this? > > Ultimately my question is - where is the Pharo issue that is tracking this problem? Iâve seen it mentioned lots of times here, but canât see anything in the issues that I can tack the above onto? > > Filetree on Windows is constrained by long filename issues with libgit. > > cheers -ben

Feb. 21, 2019

Re: [Pharo-users] Iceberg Custom SSH Keys

by Guillermo Polito

Hi Bruno, Check the settings and filter by "iceberg". You'll find what you seek I think: [image: image.png] On Thu, Feb 21, 2019 at 3:15 PM BrunoBB <smalltalk(a)adinet.com.uy> wrote: > Hi, > > Does Iceberg support a pair of key generated with PuTTY as RSA ? > > I can Push local changes with TortoiseGit client. > > But inside Pharo i get "Iceberg Authentication Error" when doing a Push. > > "Use custom SSH keys" is set but we use RSA keys generated with PuTTY. > > Maybe i'm missing something. > > regards, > bruno > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 21, 2019

Iceberg Custom SSH Keys

by BrunoBB

Hi, Does Iceberg support a pair of key generated with PuTTY as RSA ? I can Push local changes with TortoiseGit client. But inside Pharo i get "Iceberg Authentication Error" when doing a Push. "Use custom SSH keys" is set but we use RSA keys generated with PuTTY. Maybe i'm missing something. regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 21, 2019

Re: [Pharo-users] What does mean "Detached Working Copy" in Iceberg ?

by BrunoBB

Excellent !!! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 21, 2019

Re: [Pharo-users] What does mean "Detached Working Copy" in Iceberg ?

by Guillermo Polito

Hi Bruno, Take a look at the glossary here: https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary Any feedback (I'm sure many improvements can be done!) is super welcome! Guille On Thu, Feb 21, 2019 at 2:18 PM BrunoBB <smalltalk(a)adinet.com.uy> wrote: > Hi, > > We have in our server Gitolite instance running. > > From Pharo System browser we commit changes to local path and with > TortoiseGit we upload to the remote. > > So far so good but on Iceberg Repository Status i see "Detached Working > Copy". > > What is the meaning of the message ? > > The the remote is no been "handle" by Pharo ? > Or that the remove is not configured in Pharo ? > > regards, > bruno > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 21, 2019

Re: [Pharo-users] Windows 64bit, long filename issue but after a second load, how to categorise and report this?

by Ben Coman

On Thu, 21 Feb 2019 at 20:36, Tim Mackinnon <tim(a)testit.works> wrote: > We noticed a weird problem when testing the pharo exercism project. > > When loading on Windows10 in a fresh 64bit image with the following > evaluate in the playground: > > Metacello new > baseline: 'Exercism'; > repository: 'github://exercism/pharo-smalltalk:master/dev/src'; > load. > > The project seemed to load correctly (but we seemed to hit an issue with > an http submit giving a 404 error - which weirdly works in 32bit and OSX > 64/32). Anyway - the real question here is that when trying to reproduce > this in a second fresh 64bit image 2 users now have reported getting the > long filename error: > > LGit_GIT_EEXISTS: Failed to stat file > 'C:/Users/sam/Documents/Pharo/images/exercism-test-run-7.0-32...stance/testRaiseUnexpectedMessageWhenTooMuchMessages.st': > The filename or extension is too long. > > And the second user got the same but with a different filename: > ruleRBUtlitiesMethodsRuleV1FalsePositve.st These files are both method names which indicates FileTree format rather than Tonel (and these "failed to stat file" errors on Windows is one of the reasons for the move to Tonel). It may be from one of the dependencies that are pulled in. To identify which, search for that file under `pharo-local/iceberg` directory. I believe the repo may have been cloned successfully, its just the libgit binary can't `stat` long filenames. If that turns out the be untrue, use commandline git to complete the clone and you will likely see it. > > I know there is a long standing problem with Windows and file path lengths > - but why would it work the first time and then subsequently fail in fresh > installs? Is something being cached on windows that isnât on other > platforms? (Writing this - Iâm wondering if there is that shared pharo > Iceberg setting for Share repos that might be implicated?) > > Also - given Exercism is in Tonel format and those files arenât in > exercism, and in fact Iâm struggling to find where they are defined as above. > (my images donât have them) - there is something very weird going on. > > I wonder if we have another error that is masking all of this? > > Ultimately my question is - where is the Pharo issue that is tracking this > problem? Iâve seen it mentioned lots of times here, but canât see anything > in the issues that I can tack the above onto? > Filetree on Windows is constrained by long filename issues with libgit. cheers -ben

Feb. 21, 2019

What does mean "Detached Working Copy" in Iceberg ?

by BrunoBB

Hi, We have in our server Gitolite instance running. >From Pharo System browser we commit changes to local path and with TortoiseGit we upload to the remote. So far so good but on Iceberg Repository Status i see "Detached Working Copy". What is the meaning of the message ? The the remote is no been "handle" by Pharo ? Or that the remove is not configured in Pharo ? regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 21, 2019

Windows 64bit, long filename issue but after a second load, how to categorise and report this?

by Tim Mackinnon

We noticed a weird problem when testing the pharo exercism project. When loading on Windows10 in a fresh 64bit image with the following evaluate in the playground: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk:master/dev/src'; load. The project seemed to load correctly (but we seemed to hit an issue with an http submit giving a 404 error - which weirdly works in 32bit and OSX 64/32). Anyway - the real question here is that when trying to reproduce this in a second fresh 64bit image 2 users now have reported getting the long filename error: LGit_GIT_EEXISTS: Failed to stat file 'C:/Users/sam/Documents/Pharo/images/exercism-test-run-7.0-32...stance/testRaiseUnexpectedMessageWhenTooMuchMessages.st': The filename or extension is too long. And the second user got the same but with a different filename: ruleRBUtlitiesMethodsRuleV1FalsePositve.st I know there is a long standing problem with Windows and file path lengths - but why would it work the first time and then subsequently fail in fresh installs? Is something being cached on windows that isnât on other platforms? (Writing this - Iâm wondering if there is that shared pharo Iceberg setting for Share repos that might be implicated?) Also - given Exercism is in Tonel format and those files arenât in exercism, and in fact Iâm struggling to find where they are defined (my images donât have them) - there is something very weird going on. I wonder if we have another error that is masking all of this? Ultimately my question is - where is the Pharo issue that is tracking this problem? Iâve seen it mentioned lots of times here, but canât see anything in the issues that I can tack the above onto? For reference - our exercism issue is: https://github.com/exercism/pharo-smalltalk/issues/140 Tim

Feb. 21, 2019

Re: [Pharo-users] Pluralising messages or choosing word alternatives

by Richard O'Keefe

These days we are supposed to think about internationalisation and localisation. The rather elderly and inadequate '<1P> foobar<2?:s>' expandMacrosWith: n with: n = 1 works fine for English, but when you switch to '<1P> foobar<2?:s>' translated expandMacrosWith: n with: n = 1 you run into the problem that there are languages, such as Hebrew and Modern Standard Arabic, with a dual number, so that you need to distinguish 1, 2, >2 cases. Then there are the oddball languages with a "paucal" number. Generally it is better to rephrase the text, 'Number of foobars = <1P>' expandMacrosWith: n. On Thu, 21 Feb 2019 at 10:08, Tim Mackinnon <tim(a)testit.works> wrote: > I was browsing some of the Pharo issues (always worth doing) - and noticed > an interesting one about Test results reporting and pluralisation > (https://github.com/pharo-project/pharo/issues/2578) > > In it, I hadn't noticed String>>asPluralBasedOn: before (and judging from > many messages in the image, many others hadn't either). > > I'm fixing something similar for a refactoring bug and can use this > technique there (although from memory, it comes with a health warning as if > ever we want to internalise the messages in Pharo, this will need a > different approach). However we are probably a distance from doing that - > so cleaning up what we have is a good start. > > Anyway I was curious if there is something to help with messages like: > > âThere is 1 occurrence of {1}â vs âThere are many occurrences of {1}â, > which Iâd like to write something like: > > âThere â, (âis 1 â, âare many â) pick: result size, âoccurrenceâ > asPluralBasedOn: result size, â â, result printString. > > > Tim > > >

Feb. 21, 2019