February 2019 - Pharo-users

Re: [Pharo-users] im using pharo 7 with linux env. but cannot input korean.

by Pierce Ng

On Tue, Feb 19, 2019 at 09:42:18AM +0100, Hilaire wrote: > Hi Pierce, > Yes, this option worked to key in Chinese. > > By the way, do you know if any option is needed on Windows? I checked > for the options but I did not see anything relevant: Hi Hilaire, My self-built VM on Windows 7 doesn't have the option either. But, multilingual input into Pharo works. Outside of Pharo, configure Windows multilingual input. Within Pharo, choose a font like Arial Unicode MS. Then just switch Windows input system using hot-key or mouse click, and type. See screenshot. Pierce

Feb. 22, 2019

Re: [Pharo-users] Pharo Object Serialization

by john pfersich

Thereâs also STON. See https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… /*âââââââââââââââââ-*/ Sent from my iPhone https://boincstats.com/signature/-1/user/51616339056/sig.png See https://objectnets.net and https://objectnets.org > On Feb 21, 2019, at 19:05, BrunoBB <smalltalk(a)adinet.com.uy> wrote: > > Hi, > > Which are the options for serialize objects in Pharo ? > > I know there is Fuel (https://rmod.inria.fr/web/software/Fuel) > > OmniBase is not supported any more. OmniBase was pretty cool even > transactional !!! > > What are you using ? (of course there is GemStone/S but i was not able to > convince my client yet :) > > regards, > bruno > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Feb. 22, 2019

Pharo Object Serialization

by BrunoBB

Hi, Which are the options for serialize objects in Pharo ? I know there is Fuel (https://rmod.inria.fr/web/software/Fuel) OmniBase is not supported any more. OmniBase was pretty cool even transactional !!! What are you using ? (of course there is GemStone/S but i was not able to convince my client yet :) regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 22, 2019

Re: [Pharo-users] Iceberg Custom SSH Keys

by BrunoBB

Hi, We are still looking into this issue but we have everything configurated: <http://forum.world.st/file/t111409/iceberg-conf.png> If i can fix it i will post it here. regards bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 22, 2019

Embedding object properties in NeoJSON mappings

by Esteban Maringolo

Hi all (again), As part of writing the port (and adaptation to use Zinc and NeoJSON), a CouchDB JSON-REST API, now I find something I don't know how to solve using NeoJSON mappings. All objects you store in CouchDB at a particular URI are saved as "Documents", so if you save a dictionary with keys "name", "height", "c" to "/people/1234" , when you query "people/1234" you get the keys of the saved dictionary PLUS to extra keys called _id and _rev. Then when you query (GET) back the document you get a JSON like this: {"_id": ..., "_rev": ..., "name": ..., "height":...,} My Idea is that I can wrap any object serializable as JSON within aDocument, but then if I define CouchDocument class>>#neoJsonMapping: mapper as: mapper for: self do: [ :mapping | mapping mapAccessor: #id to: '_id'. mapping mapAccessor: #revision to: '_rev'. mapping mapAccessor: #class to: '_class' ]. I have no way to "flatten"/"merge" anObject within aDocument. I would expect something like mapper for: self do: [ :mapping | mapping mapAccessor: #id to: '_id'. mapping mapAccessor: #revision to: '_rev'. mapping mapAccessor: #class to: '_class' mapping embed: [:object | object whatToEmbed] ]. Of course this is awkward, because if I need to read it back, the "extraction" of the embeded properties needs to know which belongs to which and more importantly , what to instantiate! Of course I can do it manually without using NeoJSON (It's already being done [1]) , but I like when different libraries things fit naturally together :) Am I stretching it too much? :) Regards, [1] Currently the writing is done manually and the refresh (which is also a GET) does the following: CouchDocument>>#refresh " Update this Document to the latest revision " | response | response := self information. "response is a Dictionary" revision := response at: '_rev'. object := response couchToObject. ^response And here happens the magic, it searchs for a "_class" key which if present will use to instantiate the object "wrapped" by the document. Dictionary>>couchToObject | class object | self removeKey: '_id' ifAbsent: []. self removeKey: '_rev' ifAbsent: []. self keysAndValuesDo: [:key :value | self at: key put: value couchToObject]. class := (self at: '_class' ifAbsent: [^self]) asSymbol asClass. object := class basicNew. object jsonInstanceVariableNames keysAndValuesDo: [:index :key | self at: key ifPresent: [:value | object instVarAt: index put: value]]. ^object #jsonInstanceVariableNames is another level of "mapping" here, that defined what to map from the Document response. Esteban A. Maringolo

Feb. 22, 2019

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

by Tim Mackinnon

Some interesting thoughts below - but my understanding is these images are being created by Pharo Launcher , so they should be isolated from one another? I also donât understand why you can load with 32bit (multiple images) but only once with 64bit. Do we load radically different git code with longer paths on 64bit? (Strange isnât it?) Possibly worth caveating this is with 2-3 users so far, and only noticed this pattern with the last one. Also - has anyone created an issue for these path problems - Iâm curious if my results match anything else. Tim Sent from my iPhone > On 21 Feb 2019, at 16:01, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Tim Mackinnon wrote >> 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â¦ > > The Iceberg cache path is relative to the image folder, so it's at least > possible to have success in one image, located in C:\Pharo\testImage\, while > another image, reciding in something like > C:\Users\sam\Documents\Pharo\images\exercism-test-run-7.0-32\ , fails to > load the exact same filetree package... > > > Tim Mackinnon wrote >> 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? > > Yeaaah, that sounds fishy. > But at least the first method sounds like a test, which may be part of the > packages in the git repo that gets cloned without being loaded by Metacello, > if the Metacello dependency specifies a *Core group which does not include > tests. > > > Tim Mackinnon wrote >> 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 > > To be pendantic, (and not of much actual help, sorry :/ ) the problem isn't > really with Windows, which provides API's for getting file info that handle > long paths just fine, but with libgit, which is probably compiled against > some POSIX stat implementation provided by Cygwin/mingw, which does not. > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Feb. 22, 2019

Re: [Pharo-users] Using ZnClient>>#contentWriter

by Sven Van Caekenberghe

Hi Esteban, > On 21 Feb 2019, at 23:36, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi all, > > I'm doing this and it works > ZnClient new > method: #PUT; > url: 'http://127.0.0.1:5984/baseball/2'; > contents: (NeoJSONWriter toString: { 'foo' -> 'baz'} asDictionary); > contentType: ZnMimeType applicationJson; > execute. > > > But if try to use a contentWriter it fails because it can't determine > the contentType of the entity. > > ZnClient new > method: #PUT; > url: 'http://127.0.0.1:5984/baseball/2'; > "contentType: ZnMimeType applicationJson;" > contentWriter: [ :entity | NeoJSONWriter toString: entity ]; > contents: { 'foo' -> 'baz'} asDictionary; > execute. > > If I uncomment the "contentType:" message send it complains about > setting the content type before setting the entity, which makes sense > but baffles me. > > My Idea is to directly pass the object as contents, and let the > content writer deal with how it's going to be serialized on the > request (a JSON string, for the most part). > > Although the first expression works, I know it can be done better, but > I can't manage to get it working :) Yes, it can be done more elegantly. Please check ZnClient>>#forJsonREST that does set a reader and writer (latest Zn). > Thanks, > > ps: I also wonder by there aren't #bePut, #bePost, #beDelete, etc. > convenience methods instead of passing the HTTP method as a symbol :) Because ZnClient already has way too many methods ;-) What I typically do is configure and re-use a client (for talking to the same service), where only the URL changes (merging with the same endpoint, same username/password, etc ) myClient get: '/user/1'. myClient post: '/users' with: { #name->'foo' } asDictionary. myClient get: '/user?name=foo' (in my case, my client wraps a ZnClient instance, adds a cache, does processing of errors). > Esteban A. Maringolo Sven

Feb. 21, 2019

Re: [Pharo-users] Zinc Error Hierarchy

by Esteban Maringolo

El jue., 21 feb. 2019 a las 19:11, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > On 21 Feb 2019, at 22:37, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > I don't know, but note that the exceptions in Zinc-HTTP-Exceptions are not the only ones used, there are also those in Resource-Meta and Character-Encoding, and all system Networking errors (those are quite common, ConnectionTimedOut, ConnectionClosed). > > Zinc is certainly not 'closed' under its own exception set, it is too complex for that. I understand. > I also typically allow code to throw exceptions freely, instead of trying to handle them. I do try to make each exception as meaningful as possible (not just self error: 'xyz'), but I tend to reuse existing exception classes in many cases, if that makes sense. > And if you are a REST client, you also have to handle all HTTP exception classes intelligently (you know, not found is not the same as unauthorised or wrong request, often errors have a useful payload). I understand, and for the most part I have the same strategy. > In my own REST client, I turn REST exceptions into something more meaningful, and let the others bubble up. So, some high level code will basically do [ ] on: Error do: [ ] but often with some logging. I'm taking a similar approach, so I let code fail as early as possible and let exceptions bubble up. So in this case I'm handling Exceptions and also API errors and signalling them with a particular error class. Although this API (CouchDB) doesn't have error codes or something meaningful to use as a key to throw different exceptions. > This is not such an easy subject, but an interesting one. It certainly is. Thank you. Esteban A. Maringolo

Feb. 21, 2019

Using ZnClient>>#contentWriter

by Esteban Maringolo

Hi all, I'm doing this and it works ZnClient new method: #PUT; url: 'http://127.0.0.1:5984/baseball/2'; contents: (NeoJSONWriter toString: { 'foo' -> 'baz'} asDictionary); contentType: ZnMimeType applicationJson; execute. But if try to use a contentWriter it fails because it can't determine the contentType of the entity. ZnClient new method: #PUT; url: 'http://127.0.0.1:5984/baseball/2'; "contentType: ZnMimeType applicationJson;" contentWriter: [ :entity | NeoJSONWriter toString: entity ]; contents: { 'foo' -> 'baz'} asDictionary; execute. If I uncomment the "contentType:" message send it complains about setting the content type before setting the entity, which makes sense but baffles me. My Idea is to directly pass the object as contents, and let the content writer deal with how it's going to be serialized on the request (a JSON string, for the most part). Although the first expression works, I know it can be done better, but I can't manage to get it working :) Thanks, ps: I also wonder by there aren't #bePut, #bePost, #beDelete, etc. convenience methods instead of passing the HTTP method as a symbol :) Esteban A. Maringolo

Feb. 21, 2019

Re: [Pharo-users] Zinc Error Hierarchy

by Sven Van Caekenberghe

> On 21 Feb 2019, at 22:37, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi all, Sven, :-) > > I'm writing some client REST API code and need to handle errors in the > call, and found that all Errors are direct descendants of the Error > class, why aren't Zinc Errors descendants of a common ZnError class? > > Regards, > > Esteban A. Maringolo I don't know, but note that the exceptions in Zinc-HTTP-Exceptions are not the only ones used, there are also those in Resource-Meta and Character-Encoding, and all system Networking errors (those are quite common, ConnectionTimedOut, ConnectionClosed). Zinc is certainly not 'closed' under its own exception set, it is too complex for that. I also typically allow code to throw exceptions freely, instead of trying to handle them. I do try to make each exception as meaningful as possible (not just self error: 'xyz'), but I tend to reuse existing exception classes in many cases, if that makes sense. And if you are a REST client, you also have to handle all HTTP exception classes intelligently (you know, not found is not the same as unauthorised or wrong request, often errors have a useful payload). In my own REST client, I turn REST exceptions into something more meaningful, and let the others bubble up. So, some high level code will basically do [ ] on: Error do: [ ] but often with some logging. This is not such an easy subject, but an interesting one. HTH, Sven

Feb. 21, 2019

Zinc Error Hierarchy

by Esteban Maringolo

Hi all, Sven, :-) I'm writing some client REST API code and need to handle errors in the call, and found that all Errors are direct descendants of the Error class, why aren't Zinc Errors descendants of a common ZnError class? Regards, Esteban A. Maringolo

Feb. 21, 2019

Re: [Pharo-users] Trying to understand Developing with Pharo, Deploying with Gemstone/s

by sergio ruiz

Okay. let me wrap my head around all of this.. thanks! On February 20, 2019 at 5:17:27 PM, Dale Henrichs ( dale.henrichs(a)gemtalksystems.com) wrote: Hello Sergio, Sorry for the delay in replying .. too many balls in the air:) I'll comment in-line .. ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Feb. 21, 2019

[ANN] ba-st Web stack updated (RenoirSt, Willow and HighchartsSt)

by Gabriel Cotelli

Now that Pharo 7 is finally released, we took some time to update the whole web stack hosted at ba-st <https://github.com/ba-st>. As a general update all the projects now follow the brand new community guidelines <https://github.com/ba-st/Community> and support Pharo 6.1â32 bits and Pharo 7â32 & 64 bits. The build matrix now includes Pharo 8 as a preview. This includes new versions of RenoirSt, HighchartsSt, Boardwalk, Willow and it's related projects. You can see the detailed announcement here <https://medium.com/ba-st/web-stack-summer-release-1d141b2660ee>. 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 Henrik Sperre Johansen

Tim Mackinnon wrote > 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â¦ The Iceberg cache path is relative to the image folder, so it's at least possible to have success in one image, located in C:\Pharo\testImage\, while another image, reciding in something like C:\Users\sam\Documents\Pharo\images\exercism-test-run-7.0-32\ , fails to load the exact same filetree package... Tim Mackinnon wrote > 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? Yeaaah, that sounds fishy. But at least the first method sounds like a test, which may be part of the packages in the git repo that gets cloned without being loaded by Metacello, if the Metacello dependency specifies a *Core group which does not include tests. Tim Mackinnon wrote > 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 To be pendantic, (and not of much actual help, sorry :/ ) the problem isn't really with Windows, which provides API's for getting file info that handle long paths just fine, but with libgit, which is probably compiled against some POSIX stat implementation provided by Cygwin/mingw, which does not. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 21, 2019

[ANN] Pharo Consortium New Academic Member: TecnolÃ³gico de Monterrey in Guadalajara

by Marcus Denker

The Pharo Consortium is very happy to announce that TecnolÃ³gico de Monterrey in Guadalajara has joined the Consortium as an Academic Member. About - TecnolÃ³gico de Monterrey in Guadalajara: http://www.gda.itesm.mx - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Feb. 21, 2019

[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