June 2017 - Pharo-dev - lists.pharo.org

Pharo 7 provisional HOWTO
by Pavel Krivanek Aug. 24, 2017

Aug. 24, 2017

Hi, this mail describes how to start to send pull requests to Pharo 7 Github repository from Pharo 7. Preparations ===================== - you need to have a Github account and set SSH keys. See https://help.github.com/articles/connecting-to-github-with-ssh/ - create own pharo-project/pharo repository fork. Go to https://github.com/pharo-project/pharo, click on "Fork" button and follow the instructions Get Pharo 7 image ===================== The CI jobs for the Pharo 7 defelopment are currently not fully set and we still do not publish Pharo 7 image to files.pharo.org so you cannot get it using zero-conf scripts. But we have a provisional CI job that bootstraps the Pharo 7 image. https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ There download a file named like Pharo7.0-32bit-hash.zip and decompress it. Unlike Pharo 6 images, the archive contains three files. Image, changes and sources. In Pharo 7 you have the sources file for every bootstrapped version. It has a commit hash in the name and it cannot be shared between different Pharo 7 imges, however it can be shared between images that were created as snapshots with the same bootstrapped image as ancestor. Create local clone ===================== You need a local clone of the Pharo repository. Because it contains a lot of small files, it is not a good idea to have own clone for every image. You can have only one and share them between images. But because of some current Monticello constraints you need to have the clone placed in the image directory in a folder with name 'pharo-core'. In this step we will clone the Pharo repository from pharo-project/pharo Github repository and add your fork as default pull target. We will update your fork repository to contain all latest commits from the Pharo repository in the branch named 'development'. For latest stable version (Pharo 6) we use the master branch. In the end we will checkout the repository to a particular commit from which the downloaded Pharo 7 image was bootstrapped. Imagine that you have a Pharo 7 image that is several days old and the development branch has already some commits that change code. If you would take this older image, checkout to the development branch and then do your commit, your would revert all changes done in not-loaded commits. The other option is to update your image to correspond to the repository latest commit which requires packages reloading. If you checkout to a particular commit, you are in detached HEAD state. In this state you cannot do commits directly. You need to firstly create new a new branch which we will do anyway. Evaluate the following code. This functionality will be later direct part of Iceberg UI. Do not forget to change the user name. username := 'YOUR-USER-NAME'. repository := IceRepositoryCreator new url: 'git@github.com:pharo-project/pharo.git'; location: ('pharo-core' asFileReference ensureCreateDirectory); subdirectory:'src'; createRepository. repository checkoutBranch: 'development'. repository register. fork := (IceRemote name: 'myFork' url: ('git@github.com:{1}/pharo.git' format: {username})). repository addRemote: fork. repository pushRemote: fork. repository pullRemote: repository origin. "update fork" repository backend pullFrom: repository origin. "use this low-level form to prevent packages reloading" repository push. "checkout to the commit from which the image was bootstrapped" repository checkoutBranch: (SystemVersion current commitHash). Use already created clone ===================== This is alternative to the previous step. Let's suppose that you already have your local clone. You take some Pharo 7 image and you want to create commits. Then you need to create a symlink or move/copy the repository into your image directory. Remember, it must be named pharo-core (we do not use the name 'pharo' to avoid collision with VM executable). In this step we will register an existing Pharo repository clone, set your fork as the push target, update your fork and then switch to the particular commit. repository := IceRepositoryCreator new location: ('pharo-core' asFileReference); subdirectory:'src'; createRepository. repository register. fork := repository remotes detect: [ :remote | remote remoteName = #myFork ]. repository pushRemote: fork. repository pullRemote: repository origin. repository checkoutBranch: 'development'. repository backend pullFrom: repository origin. repository push. repository checkoutBranch: (SystemVersion current commitHash). Issue processing ===================== - create new case on FogBugz to get the issue number - open Iceberg and from the context menu on the 'pharo' repository do: Pharo - Create new branch from FogBugz issue, enter the issue ID and it will fill the full branch name for you - create your changes (you can do it before the creation of the branch too) - commit and push your changes in Iceberg, this way you will commit your branch to your fork repository. Remember that the Iceberg commit window has two buttons, one for local commit, the second for commit with immediate push. They can be very long because they contain the full branch (issue) name - in Iceberg in the 'pharo' repository context menu do: Pharo - Create pull request, fill your - fill your Github credentials - leave the PR title, comment is not required, check the pull request head and base. The base MUST be pharo-project/pharo development. Create the pull requests - go to https://github.com/pharo-project/pharo/pulls, check your pull requests and put URL of it into the issue record on FogBugz (as a comment). Resolve the issue as Fix review needed Cheers, -- Pavel

10 27

Catalog statistics (Who know this projects?)
by Esteban Lorenzano Aug. 22, 2017

Aug. 22, 2017

Soâ¦ I took a couple of minutes to do a small list of project description status: >From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. Which means 264 are mysterious projects nobody can guess what are they about. I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) Even very important projects like Seaside or Garage and Glorp are not documented. So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. Here the list of non-documented projects: http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main --- 'A4BP' 'Aconcagua' 'BootstrapMagritte' 'Chalten' 'CommandShell' 'Cormas' 'DependencyAnalyser' 'FamixJS' 'FontAwesome' 'Garage' 'GarageConnectionPool' 'GarageGlorp' 'Glorp' 'Grease' 'IniModules' 'Kendrick' 'Magritte3' 'MagritteMagic' 'MetaBoardBoard' 'MyFirstWebApp' 'NBOpenGL' 'NeoJSON' 'OSProcess' 'PetitParser' 'Phexample' 'Pier3' 'Pier3AddOns' 'ProcessWrapper' 'RewriteTool' 'Seaside3' 'SimplePersistence' 'Ston' 'Telescope' 'Woden' âXtreams' http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main --- 'AconcaguaDeluxe' 'AthensSVG' 'Autotest' 'CPanel' 'CreativeCommonsLive' 'DevFlow' 'EventRecorder' 'ExtendedNumberParser' 'ExternalWebBrowser2' 'FixedDecimal' 'Ghost' 'GraphViz' 'Gravatar' 'Hubcap' 'Infinity' 'Mandrill' 'Mathex' 'MemoryMonitor' 'MinimalConnectors' 'Mocketry' 'MongoTalk' 'NBSQLite3' 'NumericalMethods' 'ODBC' 'OSOSX' 'OSWindows' 'PackageDependenciesAnalysis' 'PharoLauncher' 'PlagueDoctor' 'Pomodoro' 'RemoteAnnouncement' 'SandstoneDb' 'Scheduler' 'ScriptManager' 'Shapes' 'SmallUML' 'Spreadsheet' 'Spy' 'StateSpecs' 'SuffixConditionals' 'Teachable' 'TestMock' 'Trees' 'Twilio' 'Vidi' 'VistaCursors' 'Viva' 'WiringPi' 'WorkingSet' 'XBase' 'sQuick' âsQuick_new' http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main --- 'Actalk' 'Arduino' 'BabyMock2' 'CTranslator' 'DBPedia' 'DigitalOcean' 'Forum' 'Fuel' 'GTDebugger' 'GTInspector' 'GTInspectorCore' 'GTPlayground' 'GTPlaygroundCore' 'GTSpotter' 'GToolkit' 'GlamourCore' 'GlorpDBX' 'GraphET' 'InstanceEncoder' 'Marina' 'Mechanize' 'Memcached' 'Moose' 'Pastell' 'PharoOnlineHelp' 'ProfStef' 'PythonParser' 'RFB' 'Roassal3d' 'SQLite3' 'Smallapack' 'SmalltalkHub' 'Snapshotcello' 'SortFunctions' 'Spotlight' 'Stamp' 'Tide' 'VersionBrowser' âVersionner' http://www.squeaksource.com/MetacelloRepository --- 'AXAnnouncements' 'Adore' 'Aida' 'Ajp' 'Algernon' 'Alien' 'Amers' 'Announcements' 'AutomaticMethodCategorizer' 'BetaNineIPAddress' 'CAnalyzer' 'CairoGraphics' 'CampSmalltalkLondon' 'Cecinestpasunepomme' 'CharacterMap' 'Chronos' 'CloudforkAWS' 'Cog' 'Connectors' 'ContextS' 'Control' 'Country' 'Countryside' 'DBXBrowser' 'DBXTools' 'DependencyBrowser' 'DependencyView' 'EnhancedOmniBrowser' 'ExternalIconFamily' 'ExternalWebBrowser' 'FileMan' 'FileTree' 'Filesystem' 'GemTools' 'Gitocello' 'Glamour' 'Gofer' 'GoferProjectLoader' 'GoogleAnalytics' 'HPDF' 'HealthReportProducer' 'HelpSystem' 'ICal' 'InstancesBrowser' 'JQueryWidgetBox' 'JavaScriptAnalyzer' 'Jejak' 'Keymapping' 'Kozen' 'KyotoTycoonClient' 'MaBase' 'MaClientServer' 'Magma' 'Magmafy' 'Magritte' 'Magritte2' 'Magritte3AddOns' 'MagritteAddOns2' 'Metacello' 'MetacelloBrowser' 'MetacelloPreview' 'MockGemStone' 'Mondrian' 'Money' 'MonticelloRedirect' 'Murmansk' 'Nagare' 'NativeBoost' 'Neo4reSt' 'NewECompletion' 'NewInspector' 'NewOCompletion' 'Nile' 'NotificationsArea' 'O2' 'OCompletion' 'OPAX' 'ObjectMetaTools' 'OmniBrowser' 'OmniBrowserLukas' 'Orca' 'PagedReader' 'Pharo' 'PharoMorphicExtras' 'PharoNonCore' 'Phriak' 'Pier' 'Pier2' 'PierAddOns' 'PierAddOns2' 'PostMark' 'ProcessModel' 'Quaternion' 'REPL' 'Raphael' 'RatPack' 'RefactoringBrowser' 'RefactoringTools' 'RoelTyper' 'SIXX' 'SPort2' 'SandcastleThemes' 'Scamper' 'Scribo' 'Seafox' 'Seaside' 'Seaside28' 'Seaside28Examples' 'Seaside30' 'SeasideJSON' 'SeasideRest' 'SeasideTesting' 'SharedWorkspace' 'Shout' 'SimpleApplescript' 'SoapOpera' 'SpellingServices' 'SpyForO2' 'Sqnappy' 'SqueakCheck' 'SqueakDBX' 'SqueakFS' 'SqueakSource' 'StOMP' 'Stripe' 'SunnysidePlanning2' 'SwaLint' 'Swazoo2' 'TODO' 'TimerDaemon' 'Tuio' 'VMMaker' 'Waterfall' 'WebClient' 'WebTester' 'XMLRPC' 'XMLSupport' 'Zodiac'

15 22

Pharo behind ALLSTOCKER marketplace
by Masashi UMEZAWA Aug. 17, 2017

Aug. 17, 2017

Hi all, >From Torsten, I've received a request to post about some technical details of ALLSTOCKER (http://pharo.org/success/AllStocker) . I hope these notes will be interesting to Pharo web developers. - Seaside / Teapot We are using Seaside as a main framework for ALLSTOCKER marketplace. Seaside's component architecture is great for extending application in an organized way. ALLSTOCKER prototype was originally composed of only 3 class categories. Now these were gradually grown to 70 categories. But we still feel that they are manageable. We also use Teapot for building Web-based API in a quick way. Recently we've built webhook handlers for integration with other services. - Templating with Mustaside We need a lot of responsive-design web pages for supporting various mobile devices. (It is important especially for Southeast Asian countries, where tablets are popular than PCs). We would like to adopt existing Twitter Bootstrap templates for saving time. So, Mustaside was our choice. http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside Before Mustaside, there were a lot of noisy #div: sends in our code. Now they are gone. - Localization Our business target is world-wide. So localization is very important topic. Currently ALLSTOCKER supports 4 languages and we will add Chinese languages soon. Translation strings are not only in Smalltalk code, but also in Mustache templates. So we selected Soup for extracting translatable strings in those templates. http://smalltalkhub.com/#!/~PharoExtras/Soup For managing translations, we use Gettext package. http://smalltalkhub.com/#!/~PharoExtras/Gettext - Databases For transactional data, we chose Glorp. Although there are mapping costs, we prefer RDB (Postgres). It is reliable for handling precious order-related data. However, for supporting complex search of machines, we use Neo4j - a graph database. It supports very powerful query language called Cypher. We can avoid complex table joins and get aggregated results faster. http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt - Keyword search ALLSTOCKER supports free keyword search. We selected Elasticsearch for search-engine. Elasticsearch has elaborated searching facilities and those are easily accessible via REST API. We have extended the existing Elasticsearch client for Pharo 5. https://github.com/newapplesho/elasticsearch-smalltalk - Deployment We are using AWS Elastic Load Balancer and running Nginx as a front-end web server. Two back-end Pharo images are running and load-balanced with sticky sessions. It was sort of difficult to find the appropriate simultaneous number of database connections and Pharo processes. We feel ALLSTOCKER is pretty stable for now, but we need to adjust more for expanding our services. Best regards, -- [:masashi | ^umezawa]

8 7

Re: [Pharo-dev] Pharo 7 provisional HOWTO
by Nicolai Hess Aug. 9, 2017

Aug. 9, 2017

And if I only want to contribute by reviewing a fix. Do I have to go the git-path ? Or is there a way to just start up an image and load and review the change? Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" <pavel.krivanek(a)gmail.com >: 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi all, > > Just to be clear, in Pharo 7, if I want to get some code integrated: > - I *have to* use the pull request process described by Pavel > OR > - I *can* use the pull request process, but I can also use the old slice > monticello process > ? > > What is the answer to the first question now, and what will be the answer > of this question in 6 months from now ? > You should use the pull request process. It is possible to create a standard slice BUT it must be done from Pharo 6 and then sent into Pharo60Inbox. And then you need to wait until somebody converts this slice to pull request. That means that it will be harder and harder to contribute this way because the code-base is moving. No slice will be integrated into Pharo 7 with the old process directly. Cheers, -- Pavel > > Thanks > > > On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> >> wrote: >> >>> >>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: >>> >>> >>> >>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com >>>> >: >>>> >>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>> > >>>>> > >>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>> serge.stinckwich(a)gmail.com>: >>>>> >> >>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>> >> > Hi, >>>>> >> > >>>>> >> > this mail describes how to start to send pull requests to Pharo 7 >>>>> Github >>>>> >> > repository from Pharo 7. >>>>> >> >>>>> >> Thank you for the great explanation Pavel. >>>>> >> >>>>> >> > Preparations >>>>> >> > ===================== >>>>> >> > >>>>> >> > - you need to have a Github account and set SSH keys. See >>>>> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" button >>>>> and >>>>> >> > follow >>>>> >> > the instructions >>>>> >> >>>>> >> [ ... ] >>>>> >> >>>>> >> > Issue processing >>>>> >> > ===================== >>>>> >> > >>>>> >> > - create new case on FogBugz to get the issue number >>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>> repository do: >>>>> >> > Pharo >>>>> >> > - Create new branch from FogBugz issue, enter the issue ID and it >>>>> will >>>>> >> > fill >>>>> >> > the full branch name for you >>>>> >> > - create your changes (you can do it before the creation of the >>>>> branch >>>>> >> > too) >>>>> >> > - commit and push your changes in Iceberg, this way you will >>>>> commit your >>>>> >> > branch to your fork repository. Remember that the Iceberg commit >>>>> window >>>>> >> > has >>>>> >> > two buttons, one for local commit, the second for commit with >>>>> immediate >>>>> >> > push. They can be very long because they contain the full branch >>>>> (issue) >>>>> >> > name >>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >>>>> Create >>>>> >> > pull >>>>> >> > request, fill your >>>>> >> > - fill your Github credentials >>>>> >> > - leave the PR title, comment is not required, check the pull >>>>> request >>>>> >> > head >>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>> Create the >>>>> >> > pull >>>>> >> > requests >>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check your >>>>> pull >>>>> >> > requests and put URL of it into the issue record on FogBugz (as a >>>>> >> > comment). >>>>> >> > Resolve the issue as Fix review needed >>>>> >> >>>>> >> It means, there is no PR without a corresponding FogBugz issue ? >>>>> > >>>>> > >>>>> > Yes, at least for code changes we would like to keep this relation. >>>>> If it is >>>>> > a really trivial change in readme or something like that, we can >>>>> accept no >>>>> > related issue record. >>>>> > Please prefer to comment the issues instead of PRs directly to have >>>>> all >>>>> > information at one place. >>>>> >>>>> Thank you Pavel for the explanation. >>>>> >>>>> Maybe in the future, it will make sense to put everything in the PR >>>>> and use github issues. >>>>> You will use CI travis builds for all PR ? >>>>> >>>> >>>> For now we will use FogBugz because it has a lot of nice features and >>>> good API. Maybe we will switch it in future but now we should not change >>>> too many things at once :-) >>>> For several reasons we now prefer to use own infrastructure for >>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>> can be changed in future. >>>> >>>> >>> It would be interesting to see how this might fit in with our workflow... >>> https://blog.fogcreek.com/fogbugz-github-integration/ >>> >>> >>> >>> What is the benefit of the integration? I do not understand it from the >>> given link. >>> >>> >> When you submit a PR on github, Fogbugz is automatically updated with a >> link to the PR. >> Presumably this makes it easier for people reviewing cases in Fogbugz to >> identify the slice to test. >> This is a better link... >> https://blog.fogcreek.com/improved-github-integration-automa >> tically-create-bug-events-with-commits/ >> >> cheers -ben >> > >

8 25

Epicea feedback
by Jan BlizniÄenko July 23, 2017

July 23, 2017

Hello I'd like to thank you for creating the Epicea. It is way more user-friendly and dependable than previous change-handling tool. Browsing, applying and reverting changes is way easier. Just one note: It is not exactly clear from first look how to properly reapply changes after an image has been closed without saving. If I select all changes I want to apply without using any filter, those changes are reapplied in wrong order (if I changed a method two times, first the new version is applied and then the old one). As far as I understood, I have to use filter to show only latest changes, but I think it could be clearer in the UI that I need to do so (or something completely different?) for applying changes. Thank you Jan -- View this message in context: http://forum.world.st/Epicea-feedback-tp4952661.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

3 4

PharoSpur32Vm
by Nicolai Hess July 23, 2017

July 23, 2017

Where are the latest Pharo-spur-vms (32bit) are built? I don't see them on the build server, only the buildresults at http://files.pharo.org/vm/pharo-spur32/linux/ The latest builds on the buildserver are from the last year only. nicolai

9 27

Recursively downloading Pharo packages / Building images with Nix
by Luke Gorrie July 18, 2017

July 18, 2017

Howdy! I want to build Pharo images using Nix <https://nixos.org/nix/>. On the one hand this should look basically like the Jenkins scripts, but on the other hand the build must run inside a sandbox that is isolated from the network. So I need to download all of the code that I need ahead of time because I am not able to contact Github, SmalltalkHub, etc, once the build is running. I am not sure how to approach this problem yet but I have a preliminary question. Is there an easy way that I could "recursively" download all the Smalltalk code (etc) required for an application onto the local filesystem, and then load this into a Pharo image that does not have network access? Concrete example - How could I write a Pharo script that downloads all the software required to install Moose in a standard Pharo 6.0 image? Then how could I load that into an image off the local filesystem? I feel like there should be a solution here, since Monticello seems to be able to cache packages locally on the filesystem, but I don't how enough experience to quite know how to approach it. If this is possible then the "utopian" vision could be to recursively download every Pharo package that exists, in every relevant version, and make them available in the Nix universe. This is what Nix does with Python, R, Emacs, etc packages. Or if this turns out to be difficult for some reason then I could perhaps build the Pharo image externally - e.g. on the Inria Jenkins - and then import that into Nix as an opaque binary. This is probably the simplest solution but it is not very appealing from my Nix-centric viewpoint because I won't have visibility into what has changed between one image build and the next. Feedback would be much appreciated! -Luke P.S. Screenshot from the Pharo part of my application that is starting to come together, visualizing Lua JIT compiler IR code to make it more understandable than disassembly listings: https://github.com/raptorjit/raptorjit/pull/63#issuecomment-310138536.

5 15

macOS Sierra support
by Sven Van Caekenberghe July 15, 2017

July 15, 2017

Hi, Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? In particular it seems old VM's just stop working and recent VM's that do work either have issues or cannot run older (3.0, 4.0) images. Thanks, Sven PS: I have not yet upgraded, but one of my colleagues did and he got stuck: even after we found a VM that worked, it could only run 5.0 images, not his production 4.0 images. Needless to say, this is not good. PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor.

12 27

Pharo Launcher
by Stephane Ducasse July 14, 2017

July 14, 2017

Hi where can I find the pharo launcher for the latest version of Pharo? Stef

5 5

The new implementation of current working directory
by Rajula Vineet July 10, 2017

July 10, 2017

Hi all, As I have already been posting about my GSoC work and updates on my blog <https://vineetreddy.wordpress.com> and on the mailing list <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> . In this post, I would like to go in depth of my work on 'the working directory' so that I can get valuable feedback and suggestions from everyone. This discussion was started on an github PR <https://github.com/pharo-project/pharo/pull/96> which was conflicting my PR. Firstly, I would like to go through the current implementation of the working directory. With this implementation, when you use the defaultWorkingDirectory method, the directory in which the running image is present in, is returned. This is not a completely good working because when you run the image from a different directory like './pharo ../Pharo.image' the working directory is the one in which your image resides. But that isn`t your actual working directory. Due to this, 1. Pharo cannot be installed as a normal application in a read-only environment. 2. Pharo wrongly reads and writes files relative to the 'working directory'. 3. It also makes scripting difficult. In the FogBugz issue here <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there is an example which explains the problem. Let say the Pharo VM and Image are in the directory "~/Pharo", and I wrote a script in "~/Documents/Pharo-scripts" called "perfect-numbers.st" I have 2 possibilities: cd ~/Pharo && pharo Pharo.image st ~/Documents/Pharo-scripts/perfect-numbers.st // works or cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st perfect-numbers.st // doesn't work... It doesn't work because when pharo wants to load the file, it tries to locate it with: FileSystem disk workingDirectory !!! which is NOT the current working directory." I hope you get the problem. So for the new implementation <https://github.com/rajula96reddy/pharo-cli> with the help of Guille I researched about $PWD and getcwd() for a while and wrote a new implementation. This is how it goes 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI 2. And a new method currentWorkingDirectoryPath and currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the above method and gets the working directory. 3. To integrate this, I have patched the DiskStore method 'defaultWorkingDirectory' to use the new methods in OSPlatform. I have checked all the sendors of the 'defaultWorkingDirectory' for any issue. And I also wrote some unit tests. So, the new implementation is working fine. With this, now I am able to get the right working directory. The example mentioned above works perfectly. But, there may be a few cases where it can break interoperability between Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' directory and its methods should also be patched subsequently. In fact, these problems can be tackled by running image from its own directory itself (which is obvious ;) ) or by using the method imageDirectory in FileLocator class explicitly when necessary. But overall a good thing is this is will ensure the system will behave as in other languages. I have completed this implementation and submitted a PR <https://github.com/pharo-project/pharo/pull/92> to github. But because of some dependency issue, it has not yet been merged. With the help of my mentor, I am working on the problem. Thanks for reading all this. Please give your feedback and comments on this new implementation. Your suggestions help me in learning more about the project and also about the organization. Thanks, Rajula -- View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

7 15