October 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [squeak-dev] Using libraries in FFI

by Annick Fron

Thank you ! I will try that. Annick Le 23 oct. 2014 Ã 17:49, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > On Thu, Oct 23, 2014 at 8:46 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Annick, > > On Wed, Oct 22, 2014 at 5:45 AM, Annick Fron <list(a)afceurope.com> wrote: > Hi Eliot, > > My problem is not with the VM, my problem is with my own library that I connect to through FFI. > I know where the libraries are ! > > I have tried to add them in /etc/ld.so.conf.d , that does not work. > I have tried export LD_LIBRARY_PATH, but somehow it erases some libraries needed by pharo. > > But if you use the script I include with my VMs it won't erase. It extends LD_LIBRARY_PATH. Find an example attached. > > Here's the operative line (the last one). PLUGINS is the directory containing VM plugins, SVMLLP is "Smalltalk VM LD_LIBRARY_PATH" and specifies the directories containing the C libraries the VM depends on (C library, libuuid, etc). > > LD_LIBRARY_PATH=$PLUGINS:$SVMLLP:${LD_LIBRARY_PATH} exec "$BIN/squeak" "$@" > > > > I have done sudo ldconfig ... > > In fact I have one library that depends from another one. > In FFI I call one method which calls another method in the other library. > I have tried to create symbolics links in the directory â¦ > I have checked that nm gives the right symbol with the right type .. > > So I have no idea what to try now ! > > Annick > > Le 22 oct. 2014 Ã 12:46, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > Hi Annick, > > > > LD_LIBRARY_PATH should be set to point to the relevant directories, but this can be tricky as there is a lot if variation across Linux distros as to where libraries are kept. The squeak script that comes with the Cog VMs extends LD_LIBRARY_PATH, so if you know where your libraries are you can use the script to find the other libraries the VM needs (c library and plugins). > > > > Eliot (phone) > > > > On Oct 22, 2014, at 2:55 AM, Annick Fron <list(a)afceurope.com> wrote: > > > >> Hi, > >> > >> I am using a module in FFI which depends on a large library letâs say 10 dynamic .so files in a directory. > >> How is it possible to use this library without making all symbolic links ? > >> > >> Annick > > > > > > > > -- > best, > Eliot > > > > -- > best, > Eliot

Oct. 24, 2014

Re: [Pharo-users] Pharo program examples

by Hilaire

Le 23/10/2014 22:48, Peter UhnÃ¡k a Ã©crit : > But if you want introductory-level then there is "A first application" > chapter in Pharo by Example book (http://pharobyexample.org/) This book is a good resource to learn. To test the examples be sure to download the matching "Pharo by Example" image because some examples may not work out of the box with a more rencent Pharo. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 24, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by Luc Fabresse

Hi Sven and Phil, Thanks for your answers. So I already use the zeroconf handlers ;-) The problem is that I do not benefit from the cache well enough because our command line tool (pharo-based and installed by this script http://car.mines-douai.fr/scripts/PhaROS) is dedicated to create custom images at specific path and currently I rebuild everything to have an up-to-date version at creation time (vm,pharo, code). I should probably create all images in the directory and then move them. Thanks, #Luc 2014-10-24 8:12 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > On Fri, Oct 24, 2014 at 12:50 AM, Luc Fabresse <luc.fabresse(a)gmail.com> > wrote: > >> Hi, >> >> >>> 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. >>> >> >> what are zeroconf "handlers"? >> > > the things you get in the list when you do ./pharo someimage.image --list > > So "save" is one. > > There is one in here if you like a sample. > https://github.com/philippeback/Bubble > > >> because I use zeroconf to rebuild images and it is slow because it >> downloads the vm, the image, the mcz then installing, ... >> did I missed something? >> > > No, but as my full build takes half an hour on a powerful box, this is not > practical to do like that. > So: > > CI JOB 1 (half an hour, every once in a while) > ----------- > - get pharo > - get image > - build "baseworker" image with standard packages etc > > CI JOB2 (whenever a commit is done in git, lasts a minute max) > ---------- > - take baseworker > - pull from repo > - build user code upon the base worker > > HTH > Phil > >> >> thx, Sven and Esteban, I like reading development and deployment >> processes from experienced people! >> >> #Luc >> >> >>> >>> > 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> >>> >>> >>> >> >

Oct. 24, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by phil＠highoctane.be

On Fri, Oct 24, 2014 at 12:50 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi, > > >> 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. >> > > what are zeroconf "handlers"? > the things you get in the list when you do ./pharo someimage.image --list So "save" is one. There is one in here if you like a sample. https://github.com/philippeback/Bubble > because I use zeroconf to rebuild images and it is slow because it > downloads the vm, the image, the mcz then installing, ... > did I missed something? > No, but as my full build takes half an hour on a powerful box, this is not practical to do like that. So: CI JOB 1 (half an hour, every once in a while) ----------- - get pharo - get image - build "baseworker" image with standard packages etc CI JOB2 (whenever a commit is done in git, lasts a minute max) ---------- - take baseworker - pull from repo - build user code upon the base worker HTH Phil > > thx, Sven and Esteban, I like reading development and deployment processes > from experienced people! > > #Luc > > >> >> > 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> >> >> >> >

Oct. 24, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by phil＠highoctane.be

On Thu, Oct 23, 2014 at 11:11 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > 2014-10-23 17:04 GMT-03:00 Sven Van Caekenberghe <sven(a)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. :) > > > 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. > > 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. > I have been using Jenkins for a while, due to Sebastian kicking my ass to do so. I am very glad I did. It brings a lot of confidence in rebuilding it all quickly. > 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. > Now investigating Ansible (and the hello-pharo project on GH as a start). Takes a moment to sink in but it is very useful. I see that you use supervisord. I am looking into monit for keeping things alive. Maybe can we compare notes on these. Phil > Regards, > > Esteban A. Maringolo >

Oct. 24, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by Sven Van Caekenberghe

> On 24 Oct 2014, at 00:50, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi, > > 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. > > what are zeroconf "handlers"? > because I use zeroconf to rebuild images and it is slow because it downloads the vm, the image, the mcz then installing, ... > did I missed something? 1. Setup a build directory/image $ mkdir build $ cd build $ curl get.pharo.org/30+vm | bash $ ./bin/pharo -vm-display-null Pharo.image save build 2. Load/update your stuff $ ./bin/pharo -vm-display-null build.image config http://mc.stfx.eu/XYZ XYZ --install=bleedingEdge --username=sven(a)beta9.be --password=secret $ ./bin/pharo -vm-display-null build.image save t3 You do step 1 only once, you can repeat step 2 many times. It uses the build.image and the local package-cache as a cache, incrementally adding only those things that changed. Try it, it is way faster. You can always reset and start over if you think that is necessary but it rarely is. > thx, Sven and Esteban, I like reading development and deployment processes from experienced people! > > #Luc > > > > 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> > > >

Oct. 24, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by Luc Fabresse

Hi, > 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. > what are zeroconf "handlers"? because I use zeroconf to rebuild images and it is slow because it downloads the vm, the image, the mcz then installing, ... did I missed something? thx, Sven and Esteban, I like reading development and deployment processes from experienced people! #Luc > > > 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> > > >

Oct. 23, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by Sven Van Caekenberghe

> On 23 Oct 2014, at 23:11, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2014-10-23 17:04 GMT-03:00 Sven Van Caekenberghe <sven(a)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>

Oct. 23, 2014

Re: [Pharo-users] Starting a pool of worker images using command line parameters

by Esteban A. Maringolo

2014-10-23 17:04 GMT-03:00 Sven Van Caekenberghe <sven(a)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. :) > 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. 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. 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. Regards, Esteban A. Maringolo

Oct. 23, 2014

Re: [Pharo-users] Pharo program examples

by Peter UhnÃ¡k

Hi, > a simple calculation program for any purposes This reminded me of a calculator and this https://medium.com/@svenvc/rediscovering-the-ux-of-the-legendary-hp-35-scie… > A file archieve perhaps or so ? What about the Compression package? But if you want introductory-level then there is "A first application" chapter in Pharo by Example book (http://pharobyexample.org/) There's also a list of nice tools http://pharo.gemtalksystems.com/book/PharoTools/ and more links here http://pharo.org/documentation I'm sure others can give you more and better examples. Peter On Thu, Oct 23, 2014 at 10:09 PM, Hans Schueren <werbung(a)hans-schueren.de> wrote: > Hello again , > > > let me ask a strange question for a beginner of pharo. > > Let the system be the system. hahaha > > > " Are there examples of complete , simple programs for Pharo smalltalk 80 > ? " > > Very simple ones for beginners ? > > A file archieve perhaps or so ? > > > For example : a simple personal database > a simple calculation program for any purposes > s simple statistic program or so > > > > This could help for learning. > > > > Hans > > >

Oct. 23, 2014