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

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Esteban A. Maringolo

2017-06-30 8:28 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> Am 30.06.2017 um 12:03 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> recently I started to read a book on machine learning and they >> manipulate dictionary of dictionary. (So I started my own >> implementation and I will switch to DataFrame). >> > having an abstract notation for a structure (or dictionary of dictionary) is something really useful. I work a lot with JSON and the creation in pharo is done the same way but you have to call asDictionary all the time which is annoying. This can be rethought and would make things less ugly if we had a good way. If it is close to S-expressions the better. I don't what black magic requires, but having a syntax compatible with JSON would be a HUGE boost. Maybe because of where the keys are located on my keyboard layout, but the #-> selector, although I understand its semantics, it's cumbersome to type. I'd love a more compact representation. If the compiler could be modified to accept $: as a message selector, then we could map it to return an Association as #-> currently does. I can't foresee the implications of such change. > What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. One of the stregths of the JSON format is it doesn't matter in which order the data arrives, otherwise you'd use a Array, because you already know the indices of the data you're looking for. Regards! -- Esteban.

June 30, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Stephane Ducasse

> But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. >> >> STON fromString: 'Point[10,20]' >> > Same goes for JSON. > >> We were brainstorming with marcus and we could have a first nice extension: >> >> { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>>>> 10@20 >> >> Now in addition I think that there is a value in having an object >> literal syntax. >> >> I pasted the old mail of igor on object literals because I like the >> idea since it does not add any change in the parser. >> Do you remember what were the problem raised by this solution (beside >> the fact that it had too many # and the order was like in ston not >> explicit). >> >> I would love to have another pass on the idea of Igor. > > What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. >As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. > > my 2 cents, > > Norbert > >> >> Stef >> >> >> >> >> ---------- Forwarded message ---------- >> From: Igor Stasenko <siguctua(a)gmail.com> >> Date: Fri, Oct 19, 2012 at 1:09 PM >> Subject: [Pharo-project] Yet another Notation format: Object literals >> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >> >> >> Hi, >> as i promised before, here the simple smalltalk-based literal format. >> It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to >> have separate parser (a normal smalltalk parser used for that). >> >> The idea is quite simple: >> you can tell any object to represent itself as an 'object literal' , >> for example: >> >> (1@3) asObjectLiteral >> --> #(#Point 1 3) >> >> { 1@2. 3@4. true. false . nil } asObjectLiteral >> >> -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) >> >> (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral >> -> >> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') >> >> Next thing, you can 'pretty-print' it (kinda): >> >> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral >> >> '#(#Dictionary >> 1 >> (#Array 1 2 3) >> ''foo'' ''bar'')' >> >> >> and sure thing, you can do reverse conversion: >> >> '#(#Dictionary >> 1 >> (#Array 1 2 3) >> ''foo'' ''bar'')' parseAsObjectLiteral >> >> a Dictionary('foo'->'bar' 1->#(1 2 3) ) >> >> Initially, i thought that it could be generic (by implementing default >> Object>>#asObjectLiteral), >> but then after discussing it with others, we decided to leave >> >> Object>>#asObjectLiteral to be a subclass responsibility. >> So, potentially the format allows to represent any object(s) as >> literals, except from circular referencing objects, of course. >> >> The implementation is fairly simple, as you may guess and contains no >> new classes, but just extension methods here and there. >> >> Take it with grain and salt, since it is just a small proof of >> concept. (And if doing it for real it may need some changes etc). >> Since i am far from areas right now, where it can be used, i don't >> want to pursue it further or advocate if this is the right way to do >> things. >> Neither i having a public repository for this project.. >> >> So, if there anyone who willing to pick it up and pursue the idea >> further, please feel free to do so and make a public repository for >> project. >

June 30, 2017

Re: [Pharo-dev] Reviewing of the pull requests

by Pavel Krivanek

2017-06-30 17:58 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Fri, Jun 30, 2017 at 4:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, >> >> the reviewing of the pull requests is currently not as easy as we would >> like to have. For simple changes it should be enough to go to the pull >> requests list (https://github.com/pharo-project/pharo/pulls) and review >> the changes from the GitHub web interface. In case that the PR passes tests >> and bootstrapping, it should be fine. >> >> However if you want to play with an image that contains the PR code, your >> options are more complicated. The basic and the most clean one is to >> bootstrap from the repository with the PR applied on it. But it takes A LOT >> of time (over 20 mins). You can use this script that you will run inside >> the clone. >> >> set -e >> >> export PR=122 >> export BRANCH=development >> >> export PHARO_VERSION=60 >> export BOOTSTRAP_ARCH=32 >> >> git fetch origin $BRANCH >> git fetch origin refs/pull/$PR/head >> git checkout -b pullrequest FETCH_HEAD >> git merge --no-edit origin/$BRANCH >> #git diff origin/$BRANCH..pullrequest > pullrequest.diff >> >> wget -O - get.pharo.org/${PHARO_VERSION}+vm >> <http://get.pharo.org/$%7BPHARO_VERSION%7D+vm> | bash >> >> ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ >> prepare_image.st --save --quit >> ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ >> bootstrap.st --ARCH=${BOOTSTRAP_ARCH} --quit >> bash ./bootstrap/scripts/build.sh >> >> The other option is to take existing Pharo 7 image, have >> pharo-project/pharo clone next to it in a folder named 'pharo-core' and >> then create a new branch with the merged pull request. Currently it cannot >> be done from Iceberg directly so you need to use Git. You can use this >> script: >> >> set -e >> >> PR=119 >> COMMIT=2225314a7404c9e00fe71e70d41fc59d4ba78e2d >> > > where does this commit hash come from? > > as described, SystemVersion current commitHash > >> cd pharo-core >> >> git fetch origin refs/pull/$PR/head >> git checkout -b pr$PR-local FETCH_HEAD >> git checkout $COMMIT >> git checkout -b pr$PR-merged >> git merge --no-edit pr$PR-local >> #git diff $COMMIT...pr$PR-merged > pr$PR.diff >> > > Sorry I haven't the time to test this, but maybe it would do the same...?? > git fetch origin refs/pull/$PR/merge:pr$PR-merged > #git diff $COMMIT...pr$merged > > https://coderwall.com/p/z5rkga/github-checkout-a-pull-request-as-a-branch > > cheers -ben > ok, I'll try. thanks -- Pavel > > >> Set the pull request name to the variable PR and the image commmit hash >> to the variable named COMMIT. It can be obtained by "SystemVersion current >> commitHash". As the result you are in a merged branch created for this pull >> requests (e.g. pr122-merged) and you need to reload all packages. It can be >> done from Iceberg where you will need to confirm several dialogs, or by >> this script: >> >> repo := MCFileTreeRepository new >> directory: './pharo-core/src' asFileReference; >> yourself. >> >> versions := OrderedCollection new. >> repo allFileNames do: [ :packageName | >> | wc | >> wc := MCWorkingCopy allManagers detect: [ :each | each packageName = >> (packageName withoutSuffix: '.package') ] ifNone: [nil]. >> wc ifNotNil: [ >> [(repo loadVersionFromFileNamed: packageName) load] on: >> MCMergeOrLoadWarning do: [:w | w resume ] ]] displayingProgress: [:e | e ]. >> >> The other option is to let display the classical Monticello merging >> window. For that you can use this script: >> >> repo := MCFileTreeRepository new >> directory: './pharo-core/src' asFileReference; >> yourself. >> >> versions := OrderedCollection new. >> repo allFileNames do: [ :packageName | >> | wc | >> wc := MCWorkingCopy allManagers detect: [ :each | each packageName = >> (packageName withoutSuffix: '.package') ] ifNone: [nil]. >> wc ifNotNil: [ >> versions add: (repo loadVersionFromFileNamed: packageName) ]] >> displayingProgress: [:e | e ]. >> >> merger := MCVersionMerger new. >> versions do: [:each | merger addVersion: each ]. >> merger mergeWithNameLike: 'merged'. >> >> merger gatherChanges. >> >> (merger instVarNamed: #records) do: [ :each | each mergePatch operations >> do: [:operation | operation chooseRemote.]]. >> >> (merger instVarNamed: #merger) operations do: #chooseRemote. >> >> merger resolveConflicts. >> >> However I have seen cases where for example the PR deleted some class and >> the MC merging tool was not able to see this change. So be careful with >> this approach. We need to look at that. >> >> Do not look on this mail as something final. It's only a hint for brave >> sprinters. To find a good workflow how properly review our PR should be one >> of our priorities. >> >> Cheers, >> -- Pavel >> > >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Stephane Ducasse

Thanks! This is cool I'm learning how to PR too :). Stef On Fri, Jun 30, 2017 at 4:55 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The PR is updated > > -- Pavel > > 2017-06-30 16:44 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> Attached is the changeset as discussed in my last email. >> >> Just to be clear, this is just for reference, I'm happy to redo the PR >> if it will save you and/or Pavel some time. >> >> Cheers, >> Alistair >> >> >> On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > Hi Stef, >> > >> > Good pickup. >> > >> > I also can't load >> > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. >> > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I >> > have no idea what that is (I don't remember ever creating it, and I >> > don't have a copy on my machine anywhere, or in any of my backups). >> > >> > Fortunately I do have a changeset of the patch. I'll send it through >> > as an attachment after I've sent this email in case it causes the >> > response to be blocked. >> > >> > Do you or Pavel have a preference on how to get the PR fixed? I'm >> > happy to generate a new PR if you or Pavel can close the existing one >> > (#126). >> > >> > Thanks, >> > Alistair >> > >> > >> > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> >> Hi alistair >> >> >> >> I'm starting to review code that is in the PR pipeline. >> >> https://github.com/pharo-project/pharo/pull/126 >> >> >> >> I noticed that you wrote in the slice >> >> >> >> Changes since last slice: >> >> >> >> - Change Path>>fullName to just print the path >> >> - Fix absolute path strings >> >> - Bug fix Path class>>from:delimiter: >> >> - Add unit tests >> >> >> >> But I only see in the PR three methods. >> >> Can you check because I have the impression that we are losing code >> >> somewhere? >> >> >> >> BTW I could not see the contents of the AlistairGrant.1 package >> >> I tried on several images 70 and 60 latest >> >> >> >> Stef >> >> > >

June 30, 2017

Re: [Pharo-dev] The new implementation of current working directory

by Ben Coman

On Fri, Jun 30, 2017 at 4:12 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > > On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> Rajula, thanks for your write-up. >> >> As the person who pushed Rajula to send his email I feel I should >> respond. >> >> While I'm in favour of Rajula's proposed changes, scripting in >> particular will be much easier, I think we need to make the change >> generally known as it will not always be obvious, e.g. at the moment I >> can rely on: >> >> '../init/mystartup.st' asFileReference fileIn >> >> to always work with the current definition since my init directory is >> always next to the image directory. After Rajula's changes I >> will need to do something like: >> >> (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn >> > > That's not true. It depends from where the image is launched. If you're > running from the command line, > > $ pharo Pharo.image eval " 'someFile' asFileReference fullName " > > will be a file relative to the path of the image, if you open the image > from where it is located (ie, working directory = image directory). > > This is yes different when you're > 1) deploying the image in one directory, but you're using it from another > one > $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' > asFileReference fullName " > > But then, why working directory should be image directory and not VM > directory? > I feel the analogy is that the VM is like WinWord.exe and the Image is like a document. The working directory would never be where WinWord.exe is located. Its where the document was opened from. cheers -ben > Just historical reasons? > That's a buggy convention. And people who know what a working > directory is will perceive it as even buggier. > > 2) starting the process from a graphical environment (ie, double click > in an executable app) > In that case, the OS usually sets as working directory the current > user home directory, or the user "desktop" directory. > > In any case, > - we should have a good default, I think that following the principle of > least surprise we should use as working directory what the OS means by > working directory. > > - Applications in general should be explicit with their file management. > Each OS has different locations to store different things (data, settings, > libraries, executables)... FileLocator helps by reducing the noise between > different OSs, but we should use it! > > >> Cheers, >> Alistair >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

June 30, 2017

Re: [Pharo-dev] Reviewing of the pull requests

by Ben Coman

On Fri, Jun 30, 2017 at 4:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > the reviewing of the pull requests is currently not as easy as we would > like to have. For simple changes it should be enough to go to the pull > requests list (https://github.com/pharo-project/pharo/pulls) and review > the changes from the GitHub web interface. In case that the PR passes tests > and bootstrapping, it should be fine. > > However if you want to play with an image that contains the PR code, your > options are more complicated. The basic and the most clean one is to > bootstrap from the repository with the PR applied on it. But it takes A LOT > of time (over 20 mins). You can use this script that you will run inside > the clone. > > set -e > > export PR=122 > export BRANCH=development > > export PHARO_VERSION=60 > export BOOTSTRAP_ARCH=32 > > git fetch origin $BRANCH > git fetch origin refs/pull/$PR/head > git checkout -b pullrequest FETCH_HEAD > git merge --no-edit origin/$BRANCH > #git diff origin/$BRANCH..pullrequest > pullrequest.diff > > wget -O - get.pharo.org/${PHARO_VERSION}+vm > <http://get.pharo.org/$%7BPHARO_VERSION%7D+vm> | bash > > ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/prepare_ > image.st --save --quit > ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ > bootstrap.st --ARCH=${BOOTSTRAP_ARCH} --quit > bash ./bootstrap/scripts/build.sh > > The other option is to take existing Pharo 7 image, have > pharo-project/pharo clone next to it in a folder named 'pharo-core' and > then create a new branch with the merged pull request. Currently it cannot > be done from Iceberg directly so you need to use Git. You can use this > script: > > set -e > > PR=119 > COMMIT=2225314a7404c9e00fe71e70d41fc59d4ba78e2d > where does this commit hash come from? > > cd pharo-core > > git fetch origin refs/pull/$PR/head > git checkout -b pr$PR-local FETCH_HEAD > git checkout $COMMIT > git checkout -b pr$PR-merged > git merge --no-edit pr$PR-local > #git diff $COMMIT...pr$PR-merged > pr$PR.diff > Sorry I haven't the time to test this, but maybe it would do the same...?? git fetch origin refs/pull/$PR/merge:pr$PR-merged #git diff $COMMIT...pr$merged https://coderwall.com/p/z5rkga/github-checkout-a-pull-request-as-a-branch cheers -ben > Set the pull request name to the variable PR and the image commmit hash to > the variable named COMMIT. It can be obtained by "SystemVersion current > commitHash". As the result you are in a merged branch created for this pull > requests (e.g. pr122-merged) and you need to reload all packages. It can be > done from Iceberg where you will need to confirm several dialogs, or by > this script: > > repo := MCFileTreeRepository new > directory: './pharo-core/src' asFileReference; > yourself. > > versions := OrderedCollection new. > repo allFileNames do: [ :packageName | > | wc | > wc := MCWorkingCopy allManagers detect: [ :each | each packageName = > (packageName withoutSuffix: '.package') ] ifNone: [nil]. > wc ifNotNil: [ > [(repo loadVersionFromFileNamed: packageName) load] on: > MCMergeOrLoadWarning do: [:w | w resume ] ]] displayingProgress: [:e | e ]. > > The other option is to let display the classical Monticello merging > window. For that you can use this script: > > repo := MCFileTreeRepository new > directory: './pharo-core/src' asFileReference; > yourself. > > versions := OrderedCollection new. > repo allFileNames do: [ :packageName | > | wc | > wc := MCWorkingCopy allManagers detect: [ :each | each packageName = > (packageName withoutSuffix: '.package') ] ifNone: [nil]. > wc ifNotNil: [ > versions add: (repo loadVersionFromFileNamed: packageName) ]] > displayingProgress: [:e | e ]. > > merger := MCVersionMerger new. > versions do: [:each | merger addVersion: each ]. > merger mergeWithNameLike: 'merged'. > > merger gatherChanges. > > (merger instVarNamed: #records) do: [ :each | each mergePatch operations > do: [:operation | operation chooseRemote.]]. > > (merger instVarNamed: #merger) operations do: #chooseRemote. > > merger resolveConflicts. > > However I have seen cases where for example the PR deleted some class and > the MC merging tool was not able to see this change. So be careful with > this approach. We need to look at that. > > Do not look on this mail as something final. It's only a hint for brave > sprinters. To find a good workflow how properly review our PR should be one > of our priorities. > > Cheers, > -- Pavel >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Alistair Grant

On Fri, Jun 30, 2017 at 04:55:29PM +0200, Pavel Krivanek wrote: > The PR is updated > > -- Pavel Thanks, Pavel! > 2017-06-30 16:44 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Attached is the changeset as discussed in my last email. > > Just to be clear, this is just for reference, I'm happy to redo the PR > if it will save you and/or Pavel some time. > > Cheers, > Alistair > > > On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > Good pickup. > > > > I also can't load > > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. > > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I > > have no idea what that is (I don't remember ever creating it, and I > > don't have a copy on my machine anywhere, or in any of my backups). > > > > Fortunately I do have a changeset of the patch. I'll send it through > > as an attachment after I've sent this email in case it causes the > > response to be blocked. > > > > Do you or Pavel have a preference on how to get the PR fixed? I'm > > happy to generate a new PR if you or Pavel can close the existing one > > (#126). > > > > Thanks, > > Alistair > > > > > > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi alistair > >> > >> I'm starting to review code that is in the PR pipeline. > >> https://github.com/pharo-project/pharo/pull/126 > >> > >> I noticed that you wrote in the slice > >> > >> Changes since last slice: > >> > >> - Change Path>>fullName to just print the path > >> - Fix absolute path strings > >> - Bug fix Path class>>from:delimiter: > >> - Add unit tests > >> > >> But I only see in the PR three methods. > >> Can you check because I have the impression that we are losing code > somewhere? > >> > >> BTW I could not see the contents of the AlistairGrant.1 package > >> I tried on several images 70 and 60 latest > >> > >> Stef > >> > >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Pavel Krivanek

The PR is updated -- Pavel 2017-06-30 16:44 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Attached is the changeset as discussed in my last email. > > Just to be clear, this is just for reference, I'm happy to redo the PR > if it will save you and/or Pavel some time. > > Cheers, > Alistair > > > On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > Good pickup. > > > > I also can't load > > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. > > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I > > have no idea what that is (I don't remember ever creating it, and I > > don't have a copy on my machine anywhere, or in any of my backups). > > > > Fortunately I do have a changeset of the patch. I'll send it through > > as an attachment after I've sent this email in case it causes the > > response to be blocked. > > > > Do you or Pavel have a preference on how to get the PR fixed? I'm > > happy to generate a new PR if you or Pavel can close the existing one > > (#126). > > > > Thanks, > > Alistair > > > > > > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi alistair > >> > >> I'm starting to review code that is in the PR pipeline. > >> https://github.com/pharo-project/pharo/pull/126 > >> > >> I noticed that you wrote in the slice > >> > >> Changes since last slice: > >> > >> - Change Path>>fullName to just print the path > >> - Fix absolute path strings > >> - Bug fix Path class>>from:delimiter: > >> - Add unit tests > >> > >> But I only see in the PR three methods. > >> Can you check because I have the impression that we are losing code > somewhere? > >> > >> BTW I could not see the contents of the AlistairGrant.1 package > >> I tried on several images 70 and 60 latest > >> > >> Stef > >> >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Alistair Grant

Attached is the changeset as discussed in my last email. Just to be clear, this is just for reference, I'm happy to redo the PR if it will save you and/or Pavel some time. Cheers, Alistair On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > Good pickup. > > I also can't load > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I > have no idea what that is (I don't remember ever creating it, and I > don't have a copy on my machine anywhere, or in any of my backups). > > Fortunately I do have a changeset of the patch. I'll send it through > as an attachment after I've sent this email in case it causes the > response to be blocked. > > Do you or Pavel have a preference on how to get the PR fixed? I'm > happy to generate a new PR if you or Pavel can close the existing one > (#126). > > Thanks, > Alistair > > > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi alistair >> >> I'm starting to review code that is in the PR pipeline. >> https://github.com/pharo-project/pharo/pull/126 >> >> I noticed that you wrote in the slice >> >> Changes since last slice: >> >> - Change Path>>fullName to just print the path >> - Fix absolute path strings >> - Bug fix Path class>>from:delimiter: >> - Add unit tests >> >> But I only see in the PR three methods. >> Can you check because I have the impression that we are losing code somewhere? >> >> BTW I could not see the contents of the AlistairGrant.1 package >> I tried on several images 70 and 60 latest >> >> Stef >>

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Alistair Grant

Hi Stef, Good pickup. I also can't load SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I have no idea what that is (I don't remember ever creating it, and I don't have a copy on my machine anywhere, or in any of my backups). Fortunately I do have a changeset of the patch. I'll send it through as an attachment after I've sent this email in case it causes the response to be blocked. Do you or Pavel have a preference on how to get the PR fixed? I'm happy to generate a new PR if you or Pavel can close the existing one (#126). Thanks, Alistair On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi alistair > > I'm starting to review code that is in the PR pipeline. > https://github.com/pharo-project/pharo/pull/126 > > I noticed that you wrote in the slice > > Changes since last slice: > > - Change Path>>fullName to just print the path > - Fix absolute path strings > - Bug fix Path class>>from:delimiter: > - Add unit tests > > But I only see in the PR three methods. > Can you check because I have the impression that we are losing code somewhere? > > BTW I could not see the contents of the AlistairGrant.1 package > I tried on several images 70 and 60 latest > > Stef >

June 30, 2017