Re: [Pharo-users] Partition/Sync ready databases for Pharo?

[Pierce Ng]

On Tue, Feb 19, 2019 at 01:02:51PM +, Tim Mackinnon wrote:
> When you say Fossil - are you referring to
> "https://fossil-scm.org/index.html/doc/trunk/www/index.wiki” ?
> I’ve seen it come up a few times - is it good? 

Yes I mean the Fossil SCM. I use it as a personal wiki and file repo. It
comes with built-in ticketing system and forum, all wrapped into one
executable file. Fossil also imports/exports Git repos.

I'd use Fossil for small development teams too. Except for game
development and other cases involving multi-GB repos with lots of binary
blobs.

> can you hook into it to save application runtime artefacts such that a
> distributed application can read them back 

Fossil was designed as a standalone executable. It is difficult to
"library-ify" and the developers have no plan to do so. But it is just a
single executable, supports JSON output for some of its functions, and
can be invoked via OSSubprocess and the like, conceptually similar to
how Iceberg uses libgit2 to do Git stuff.

Pierce

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

[Pierce Ng]

On Tue, Feb 19, 2019 at 10:36:18AM -0300, Esteban Maringolo wrote:
> No problem, I was going to ask about Fossil as well, I know it is a
> self contained SCM, with issue tracker, and whatnot. People that uses
> it don't want to use git except if forced to.
> So I also ask how this would work. :)

Fossil's built-in sync mechanism is described at
https://fossil-scm.org/index.html/doc/trunk/www/sync.wiki.

Fossil's traffic works through tunneling - this is how I 'fossil push'
new blog posts from my laptop to my server through an SSH tunnel. I had
also tested Fossil behind Internet-reachable Caddy HTTPS reverse proxy,
which works too.

For your use case, I might approach it like this: Write data locally and
commit to Fossil as blobs. To sync, run Fossil under OSSubprocess to
sync with the central server, either directly (if Fossil on central
server is directly reachable) or thru a tunnel created by your
application if your application runs on both ends.

> I saw SQLite-sync before, but it is a commercial product, and its
> platform support/setup seems convoluted.
>
> dqlite might be a viable alternative, from more than reliable
> provider, it's is not clear whether I have to use a different library
> to access SQLite (it seems so) or a special wire protocol/api calls.

I was actually thinking of https://github.com/rqlite/rqlite/ but did not
remember the name when I replied originally.

But it seems that, however you choose to sync, your application still
needs to handle any data conflict that arises.

Pierce

Re: [Pharo-users] Running pharo in daemon mode

[Pierce Ng]

On Tue, Feb 19, 2019 at 05:17:34AM -0800, sergio ruiz wrote:
> My daemontools run file looks like:
> but for some reason, it just sits and grinds and restarts.. never remaining
> started for more than a second..

PharoDebug.log or "ps ax | egrep readproctitle" should contain some
clues. 

> VM="/home/bandtracker/pharoImages/pharo"
> IMAGE="/home/bandtracker/pharoImages/Pharo.image"

Looks like you put the VM and image/changes files in the same directory.
Depending on how you set up, Pharo may need write-access to the image's
containing directory, /home/bandtracker/pharoImages in your case. 

I suggest to put the VM files somewhere else, and owned by root:root.
This greatly reduces the risk of bug or exploited vulnerability in your
code or Pharo running as your uid overwriting the VM files.

Pierce

Re: [Pharo-users] Pharo Object Serialization

[john pfersich]

There’s also STON. See 
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/STON/STON.html

/*—-*/
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  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
> 

[Pharo-users] Pharo Object Serialization

[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

Re: [Pharo-users] Iceberg Custom SSH Keys

[BrunoBB]

Hi,

We are still looking into this issue but we have everything configurated:
 

If i can fix it i will post it here.

regards
bruno



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

[Pharo-users] Embedding object properties in NeoJSON mappings

[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

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

[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 
>  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
> 

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

[Sven Van Caekenberghe]

Hi Esteban,

> On 21 Feb 2019, at 23:36, Esteban Maringolo  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

Re: [Pharo-users] Zinc Error Hierarchy

[Esteban Maringolo]

El jue., 21 feb. 2019 a las 19:11, Sven Van Caekenberghe
() escribió:
> > On 21 Feb 2019, at 22:37, Esteban Maringolo  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

[Pharo-users] Using ZnClient>>#contentWriter

[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

Re: [Pharo-users] Zinc Error Hierarchy

[Sven Van Caekenberghe]

> On 21 Feb 2019, at 22:37, Esteban Maringolo  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

[Pharo-users] Zinc Error Hierarchy

[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

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

[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.henri...@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

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

[Gabriel Cotelli]

Now that Pharo 7 is finally released, we took some time to update the whole
web stack hosted at ba-st .

As a general update all the projects now follow the brand new community
guidelines  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
.

Regards,
Gabriel

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

[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

[Pharo-users] [ANN] Pharo Consortium New Academic Member: Tecnológico de Monterrey in Guadalajara

[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

[Pharo-users] [ANN] Buoy v5.0.0 released!

[Gabriel Cotelli]

Buoy , the project aiming to complement Pharo
 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.


Regards,

Gabriel

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

[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  wrote:
> 
> 
> 
> On Thu, 21 Feb 2019 at 20:36, Tim Mackinnon  > 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

[Pharo-users] Iceberg Custom SSH Keys

[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

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

[BrunoBB]

Excellent !!!



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

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

[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  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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[Ben Coman]

On Thu, 21 Feb 2019 at 20:36, Tim Mackinnon  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

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

[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

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

[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

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

[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  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
>
>
>