> On 23 Oct 2014, at 23:11, Esteban A. Maringolo <emaring...@gmail.com> wrote: > > 2014-10-23 17:04 GMT-03:00 Sven Van Caekenberghe <s...@stfx.eu>: > >>> Why do you use the pharo shell script instead of pharo-vm with >>> --no-display? Is there any benefit other than having the pwd set to >>> the image location? And hence, the argument script should be relative >>> to the image. >> >> No particular reason, mostly because I hate adding the --no-display >> But yes, I usually bypass the script and use the executable directly. > > I don't know how Pharo resolves the file names by default. > > Pharo's FileLocator seems to provide something similar to the > Dolphin's FileLocator I'm used to work with (see attached image) to > avoid the "resolution guessing" of relative paths when defined in the > context of a script or app code (e.g. to specify template files). > I should use it more. :)
Here are some things you can try: $ ./pharo Pharo.image eval "'' asFileReference pathString" '/' $ ./pharo Pharo.image eval "'foo.txt' asFileReference pathString" '/Users/sven/Tmp/pharo4/foo.txt' It seems to be image relative, unless its empty, then it becomes root, which is weird. Using absolute, resolved paths is one way to take all doubt away. There are quite a number of known locations: $ ./pharo Pharo.image eval '(FileLocator supportedOrigins collect: [ :each | each -> (FileLocator perform: each) pathString ]) asDictionary' a Dictionary(#cache->'/Users/sven/Library/Caches' #changes->'/Users/sven/Tmp/pharo4/Pharo.changes' #desktop->'/Users/sven/Desktop' #documents->'/Users/sven/Documents' #home->'/Users/sven' #image->'/Users/sven/Tmp/pharo4/Pharo.image' #imageDirectory->'/Users/sven/Tmp/pharo4' #preferences->'/Users/sven/Library/Preferences' #systemApplicationSupport->'/Library/Application Support' #systemLibrary->'/Library' #temp->'/tmp' #userApplicationSupport->'/Users/sven/Library/Application Support' #userLibrary->'/Users/sven/Library' #vmBinary->'/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo' #vmDirectory->'/Users/sven/tmp/pharo4/pharo-vm' #workingDirectory->'/Users/sven/Tmp/pharo4' ) >> All this sharing, talking & discussing, even over small issues and style is >> important, we can all learn a lot from each other and save time and money. > > Absolutely. > > I'd like to know the development process of others, from SCM to > building, deploying and server provisioning. I would say the standard approach is: - use Monticello with any repo type - split your code in some big modules, some private, some from public source - have a single overarching Metacello configuration - use zeroconf to build images - optionally use a CI Note that zeroconf handlers allow you to build images incrementally (the image is saved after each build), which is way faster than always starting from scratch. > After a year o Pharo development I think I'm ready to embrace a CI > server (I already use scripts to build images), but I think I will > move all my repositories to git before. These are orthogonal decisions, most CI jobs on the Pharo contribution server run against StHub. > However, my remote server provisioning is still manual, and too > rudimentary even for my own taste. If I could speed up this, I would > deliver features faster to my customers. Now everything runs inside a > two week sprint window. I am not into provisioning myself, but more automation is always good, though sometimes setting up and maintaining all these things takes a lot of time as well. > Regards, > > Esteban A. Maringolo > <filelocator.png>
