February 2019 - Pharo-users

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