Pharo-dev

By thread

pharo-dev@lists.pharo.org

3 participants
144616 messages

Re: [Pharo-dev] about expressions

by Stephane Ducasse

Ok. Then we can have an ordered expression :) A sequence without a declaration is a bit useless. On Fri, Jun 30, 2017 at 11:56 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Surprising that a sequence is not an expression. I'm pretty sure that (1+2. > 2+3) is an expression that returns 5 (after computing a useless addition). > What is currently not an expression is the variable declaration, indeed. But > if we make |d| an expression then that means we can declare variables in the > middle of a sequenceâ¦ so it would still have the same lifetime, but a > shorter scope ? > > On 30 June 2017 at 11:32, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> I do not get why (Yes I know it is because it is not in the syntax.... >> but it is conceptually not nice). >> >> | d | >> d := Dictionary new. >> d at: #top at: #below1 put: 1. >> d at: #top at: #below1 put: 2. >> d at: #top at: #below1. >> >> is not an expression in Pharo. >> >> It means that I can manipulate >> >> 1 + 3, >> x + 3 as an expression >> but not a sequence. >> >> So it forces me to use a block to convert artificially a sequence >> in an expression. >> >> [ >> | d | >> d := Dictionary new. >> d at: #top at: #below1 put: 1. >> d at: #top at: #below1 put: 2. >> d at: #top at: #below1. >> ] value >> >> So if I want to build a repl executing expression then this is not a >> Pharo repl but just a stupid expression. >> >> I would like to know what would be impact to have sequence and >> declaration as expression. >> >> Stef >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

June 30, 2017

Reflecting on data (literal) object syntax

by Stephane Ducasse

Hi 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). Now it occurred to me that when we program complex objects we do not need a compact literal syntax for our objects. But when we manipulate data objects it is super handy. I ended up doing a lot of self new addRow: 'Claudia Puig' withTaggedValues: {('Snakes on a Plane' -> 3.5). ('Just My Luck' -> 3.0). ('The Night Listener' -> 4.5). ('Superman Returns' -> 4.0). ('You, Me and Dupree' -> 2.5)}. And I was not in the mood to write a class for the taggedValues and writing a class would not have really help me. Now we also have STON but STON is not yet part of the language grammar. So we have to have an explicit conversion call. STON fromString: 'Point[10,20]' 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. 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] about expressions

by Damien Pollet

Surprising that a sequence is not an expression. I'm pretty sure that (1+2. 2+3) is an expression that returns 5 (after computing a useless addition). What is currently not an expression is the variable declaration, indeed. But if we make |d| an expression then that means we can declare variables in the middle of a sequenceâ¦ so it would still have the same lifetime, but a shorter scope ? On 30 June 2017 at 11:32, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not get why (Yes I know it is because it is not in the syntax.... > but it is conceptually not nice). > > | d | > d := Dictionary new. > d at: #top at: #below1 put: 1. > d at: #top at: #below1 put: 2. > d at: #top at: #below1. > > is not an expression in Pharo. > > It means that I can manipulate > > 1 + 3, > x + 3 as an expression > but not a sequence. > > So it forces me to use a block to convert artificially a sequence > in an expression. > > [ > | d | > d := Dictionary new. > d at: #top at: #below1 put: 1. > d at: #top at: #below1 put: 2. > d at: #top at: #below1. > ] value > > So if I want to build a repl executing expression then this is not a > Pharo repl but just a stupid expression. > > I would like to know what would be impact to have sequence and > declaration as expression. > > Stef > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

June 30, 2017

about expressions

by Stephane Ducasse

I do not get why (Yes I know it is because it is not in the syntax.... but it is conceptually not nice). | d | d := Dictionary new. d at: #top at: #below1 put: 1. d at: #top at: #below1 put: 2. d at: #top at: #below1. is not an expression in Pharo. It means that I can manipulate 1 + 3, x + 3 as an expression but not a sequence. So it forces me to use a block to convert artificially a sequence in an expression. [ | d | d := Dictionary new. d at: #top at: #below1 put: 1. d at: #top at: #below1 put: 2. d at: #top at: #below1. ] value So if I want to build a repl executing expression then this is not a Pharo repl but just a stupid expression. I would like to know what would be impact to have sequence and declaration as expression. Stef

June 30, 2017

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

by Stephane Ducasse

I did not take any blame in wht you say. I just wanted to explain that yes comments can be wrong :) I'm super happy to get some brains looking at improving FS. I'm fighting to see how we can start to integrate faster changes in P70. On Fri, Jun 30, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Fri, Jun 30, 2017 at 09:46:44AM +0200, Stephane Ducasse wrote: >> Hi alistair >> >> I do not know if this is me that wrote a wrong path class comment. >> You should consider that theere were nearly no comment at all and I >> started to try to give more love to this great library. >> >> Stef > > No problem, I wasn't trying to blame anyone. The comments appear to > align with the design goals of the class. And I really do agree with > the goals, it is just that given the confusion it creates, in this > particular case it is more practical to parse the strings. > > Actually issue 18042[1] offers an alternative approach, which is to enforce > not allowing the directory delimiter. I would extend the error message > to suggest using #resolve: instead. I think that following the > programmer's rule of being strict in what you write and forgiving in > what you read, parsing the string is more practical, but I'm keen to see > what everyone else thinks. > > [1] https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but… > >> I'm not expert of file system. Now I like your idea to have explicit >> messages such as canonalize or expand. > > :-) > > Cheers, > Alistair > > > >> On Tue, Jun 27, 2017 at 8:56 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > Hi Sven, >> > >> > On Tue, Jun 27, 2017 at 01:31:42PM +0200, Sven Van Caekenberghe wrote: >> >> Hi Alistair, >> >> >> >> I think it is great that you are working on FileSystem and are trying >> >> to contribute. I appreciate your effort to find consensus. >> > >> > :-) >> > >> > >> >> But, and please take this as positive criticism, I feel a bit uneasy >> >> when I read your reasoning, but maybe I am wrong. >> > >> > Thanks for taking the trouble to reply. Hopefully I can address some of >> > your unease below. >> > >> > >> >> You see, the way I understand FileSystem (what I think was the >> >> original design idea), it is a cross platform abstraction over >> >> concrete file systems and paths. >> > >> > It does appear to be the case that effort was put in to avoid specifying >> > a separator, but it makes an assumption that is incorrect. The class >> > comments of path state that the seperator can be part of a file name, >> > and this is incorrect for every disk file system Pharo supports (as far >> > as I know). >> > >> > >> > >> >> A FileReference holds a FileSystem and a Path. A Path is just a >> >> collection of elements that leads to a location, the leaf possibly >> >> being interpreted as a file with an extension (although that last >> >> point is just a convention). It seems great effort was put into >> >> avoiding the use of separators. >> > >> >> Pharo is an object oriented system with appropriate abstractions, >> >> FileSystem gives us one approach to this difficult problem. >> >> >> >> In your reasoning, your truth, your reference is always the Unix file >> >> system and the way paths are handled there. You expect a number of >> >> things based on that, but maybe that was/is not the design goal. >> > >> > I do have a bias towards the Unix filesystem, and you're correct that >> > all the examples I provided use the Unix file system, but I've tried to >> > make sure that the changes I've made apply equally to Windows file >> > systems (more below). >> > >> > >> >> I said this before, but I am not sure we should interpret the argument of #/. >> > >> > I'll come back to this later :-) >> > >> > >> >> I think that >> >> >> >> FileLocator root / 'foo' / 'bar' / 'readme.txt'. >> >> >> >> is more abstract (fitting to the original goal) then >> >> >> >> '/foo' asFileReference / 'bar/readme.txt'. >> >> >> >> because it totally avoids a reference to the platform dependent path separator. >> > >> > I wasn't trying to suggest that code would normally be written this way. >> > It is more likely that '/foo' asFileReference is created early in the >> > code, and much later an input is supplied which is 'bar/readme.txt'. At >> > that point, the natural thing to do is send #/ as above. >> > >> > The problem with only supporting the first case above is that it puts >> > the onus of parsing the string on the user. We could add a another >> > method that parses the supplied string, but that will just make the >> > interface more confusing, and we already have a steady stream of >> > messages to the list from people getting confused by this. >> > >> > >> >> The same goes for '..' as >> >> >> >> (FileLocator root / 'foo' / 'bar' / 'down') parent / 'readme.txt'. >> >> >> >> is a more object oriented way to write '/foo/bar/down/../readme.txt', IMO. >> > >> > Agreed, but as mentioned above, we also have to deal with input strings >> > from external sources. >> > >> > >> >> Windows is an important target for Pharo, they use $\ not $/. >> > >> > The patch handles that, so on windows I can do: >> > >> > ('C:\cygwin' asFileReference / 'usr\local\bin') parent " File @ C:\cygwin\usr\local" >> > >> > (just to be clear, this is an example of how the strings are handled, >> > I'm not expecting anyone to write code like the above). >> > >> > >> >> Do you see my point ? >> > >> > I think so, but... :-) >> > >> > >> >> BTW, I consider the fact that current, >> >> >> >> '/foo' asFileReference / 'bar/readme.txt' >> >> >> >> works with #exists even though 'bar/readme.txt' was not fully >> >> parsed/resolved a bug, or a happy coincidence at best. >> > >> > I agree that it is a happy coincedence, but it is also intuitive. >> > >> > >> >> Another point is the distinction between internal/external and/or >> >> concrete/abstract paths. Should something like '..' remain part of a >> >> path. Never, always, only when it can be resolved ? What about special >> >> characters ? >> > >> > I'm arguing that '..' should be left in the path unless explicitly told >> > to be removed, so that things like symbolic links are handled properly >> > (by the file system itself). (Thanks to Denis for reminding me about >> > this in an earlier email thread) >> > >> > While it's nice to be completely general, is there a supported file >> > system that doesn't interpret ".." as the parent directory? >> > >> > As an aside, another patch I'll be submitting fixes symbolic link >> > handling so we could conveivably write a #canonicalizeOnFileSystem that >> > would properly handle 'symboliclink/..', but it would be slow. >> > >> > >> >> Should we support ~ ? Sometimes I would like that too, but maybe >> >> >> >> FileLocator home >> >> >> >> is enough. >> > >> > As Subbu points out in a later message, things like '~' are handled by >> > the shell. We could consider adding something like #expand to handle >> > '~' and shell variables, e.g. $HOME, but I'd make that a separate patch. >> > >> > It would also need to be done carefully as $ and ~ are valid characters >> > within file names (only / and the null character are not allowed in >> > Posix file systems, Windows has more characters that are not allowed). >> > >> > >> > >> >> All this being said, I think FileSystem can and should be improved, >> >> but carefully. >> >> >> >> It would be good if more people joined this discussion. >> >> >> >> Sven >> > >> > I think I understand the original goals, and I don't disagree with them, >> > however: >> > >> > 1. they are based on an arguably incorrect assumption (the >> > separator character can be part of a file name), >> > >> > 2. they've caused quite a bit of confusion due to unexpected behaviour, >> > >> > 3. if support for a file system that allows the separator in file names >> > is ever added, we will still have to be able to parse a full path >> > correctly (which the current code wouldn't do) >> > >> > 4. I don't think these changes conflict with the original goals, all the >> > examples you provided above still function exactly the same. >> > >> > Does that help reduce your uneasiness? >> > >> > Thanks again, >> > Alistair >> > >> > >> > >> > >> >> > On 26 Jun 2017, at 10:12, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> > >> >> > Pharo's FileSystem behaviour is currently somewhat inconsistent in its >> >> > treatment of path strings. >> >> > >> >> > To be able to demonstrate the limitations and fixes, I'm assuming that >> >> > the following files and directories have been created (/dev/shm is a >> >> > memory based file system in Ubuntu): >> >> > >> >> > cd /dev/shm >> >> > mkdir -p d1/d2/d3/d4 >> >> > touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt >> >> > pushd d1 && ln -s d2/d3 ./s3 && popd >> >> > >> >> > >> >> > >> >> > 1. Path's are canonicalised during initial creation, but are not when >> >> > extending the path, i.e. sending #/ >> >> > >> >> > E.g. >> >> > >> >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" >> >> > >> >> > '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" >> >> > >> >> > Automatic canonicalisation is problematic as the code doesn't handle >> >> > symbolic links in the path name: >> >> > >> >> > ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" >> >> > >> >> > '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" >> >> > >> >> > >> >> > 2. In an attempt to be completely general, the argument to #/ is assumed >> >> > to be a single directory / file. This is incorrect as the path >> >> > delimiter is not allowed to be part of the file name. The result is >> >> > that path comparisons and operations such as #parent give unexpected >> >> > results. >> >> > >> >> > E.g. >> >> > >> >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" >> >> > >> >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" >> >> > >> >> > >> >> > My PR modified FileSystem so that: >> >> > >> >> > 1. Canonicalisation is separated out as an operation that has to be >> >> > manually requested: >> >> > >> >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" >> >> > >> >> > '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" >> >> > >> >> > >> >> > 2. The argument to #/ can be either a single file / directory name or a >> >> > path. >> >> > >> >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" >> >> > >> >> > >> >> > >> >> > 3. Adds unit tests to cover the changed behaviour. >> >> > >> >> > >> >> > While I believe that these changes improve Pharo overall, making it more >> >> > intuitive and consistent, modifying the path creation to remove >> >> > canonicalisation is not backward compatible and requires a change to >> >> > PathTest>>testRelativeFromStringNormalization and >> >> > PathTest>>testRelativeFromStringNormalizationParent to manually >> >> > canonicalise the paths. >> >> > >> >> > Before I submit the patch, does anyone have any strong objections to the >> >> > changes as described above? >> >> > >> >> > Thanks, >> >> > Alistair >> > >> >

June 30, 2017

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

by Alistair Grant

Hi Stef, On Fri, Jun 30, 2017 at 09:46:44AM +0200, Stephane Ducasse wrote: > Hi alistair > > I do not know if this is me that wrote a wrong path class comment. > You should consider that theere were nearly no comment at all and I > started to try to give more love to this great library. > > Stef No problem, I wasn't trying to blame anyone. The comments appear to align with the design goals of the class. And I really do agree with the goals, it is just that given the confusion it creates, in this particular case it is more practical to parse the strings. Actually issue 18042[1] offers an alternative approach, which is to enforce not allowing the directory delimiter. I would extend the error message to suggest using #resolve: instead. I think that following the programmer's rule of being strict in what you write and forgiving in what you read, parsing the string is more practical, but I'm keen to see what everyone else thinks. [1] https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but… > I'm not expert of file system. Now I like your idea to have explicit > messages such as canonalize or expand. :-) Cheers, Alistair > On Tue, Jun 27, 2017 at 8:56 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > > > On Tue, Jun 27, 2017 at 01:31:42PM +0200, Sven Van Caekenberghe wrote: > >> Hi Alistair, > >> > >> I think it is great that you are working on FileSystem and are trying > >> to contribute. I appreciate your effort to find consensus. > > > > :-) > > > > > >> But, and please take this as positive criticism, I feel a bit uneasy > >> when I read your reasoning, but maybe I am wrong. > > > > Thanks for taking the trouble to reply. Hopefully I can address some of > > your unease below. > > > > > >> You see, the way I understand FileSystem (what I think was the > >> original design idea), it is a cross platform abstraction over > >> concrete file systems and paths. > > > > It does appear to be the case that effort was put in to avoid specifying > > a separator, but it makes an assumption that is incorrect. The class > > comments of path state that the seperator can be part of a file name, > > and this is incorrect for every disk file system Pharo supports (as far > > as I know). > > > > > > > >> A FileReference holds a FileSystem and a Path. A Path is just a > >> collection of elements that leads to a location, the leaf possibly > >> being interpreted as a file with an extension (although that last > >> point is just a convention). It seems great effort was put into > >> avoiding the use of separators. > > > >> Pharo is an object oriented system with appropriate abstractions, > >> FileSystem gives us one approach to this difficult problem. > >> > >> In your reasoning, your truth, your reference is always the Unix file > >> system and the way paths are handled there. You expect a number of > >> things based on that, but maybe that was/is not the design goal. > > > > I do have a bias towards the Unix filesystem, and you're correct that > > all the examples I provided use the Unix file system, but I've tried to > > make sure that the changes I've made apply equally to Windows file > > systems (more below). > > > > > >> I said this before, but I am not sure we should interpret the argument of #/. > > > > I'll come back to this later :-) > > > > > >> I think that > >> > >> FileLocator root / 'foo' / 'bar' / 'readme.txt'. > >> > >> is more abstract (fitting to the original goal) then > >> > >> '/foo' asFileReference / 'bar/readme.txt'. > >> > >> because it totally avoids a reference to the platform dependent path separator. > > > > I wasn't trying to suggest that code would normally be written this way. > > It is more likely that '/foo' asFileReference is created early in the > > code, and much later an input is supplied which is 'bar/readme.txt'. At > > that point, the natural thing to do is send #/ as above. > > > > The problem with only supporting the first case above is that it puts > > the onus of parsing the string on the user. We could add a another > > method that parses the supplied string, but that will just make the > > interface more confusing, and we already have a steady stream of > > messages to the list from people getting confused by this. > > > > > >> The same goes for '..' as > >> > >> (FileLocator root / 'foo' / 'bar' / 'down') parent / 'readme.txt'. > >> > >> is a more object oriented way to write '/foo/bar/down/../readme.txt', IMO. > > > > Agreed, but as mentioned above, we also have to deal with input strings > > from external sources. > > > > > >> Windows is an important target for Pharo, they use $\ not $/. > > > > The patch handles that, so on windows I can do: > > > > ('C:\cygwin' asFileReference / 'usr\local\bin') parent " File @ C:\cygwin\usr\local" > > > > (just to be clear, this is an example of how the strings are handled, > > I'm not expecting anyone to write code like the above). > > > > > >> Do you see my point ? > > > > I think so, but... :-) > > > > > >> BTW, I consider the fact that current, > >> > >> '/foo' asFileReference / 'bar/readme.txt' > >> > >> works with #exists even though 'bar/readme.txt' was not fully > >> parsed/resolved a bug, or a happy coincidence at best. > > > > I agree that it is a happy coincedence, but it is also intuitive. > > > > > >> Another point is the distinction between internal/external and/or > >> concrete/abstract paths. Should something like '..' remain part of a > >> path. Never, always, only when it can be resolved ? What about special > >> characters ? > > > > I'm arguing that '..' should be left in the path unless explicitly told > > to be removed, so that things like symbolic links are handled properly > > (by the file system itself). (Thanks to Denis for reminding me about > > this in an earlier email thread) > > > > While it's nice to be completely general, is there a supported file > > system that doesn't interpret ".." as the parent directory? > > > > As an aside, another patch I'll be submitting fixes symbolic link > > handling so we could conveivably write a #canonicalizeOnFileSystem that > > would properly handle 'symboliclink/..', but it would be slow. > > > > > >> Should we support ~ ? Sometimes I would like that too, but maybe > >> > >> FileLocator home > >> > >> is enough. > > > > As Subbu points out in a later message, things like '~' are handled by > > the shell. We could consider adding something like #expand to handle > > '~' and shell variables, e.g. $HOME, but I'd make that a separate patch. > > > > It would also need to be done carefully as $ and ~ are valid characters > > within file names (only / and the null character are not allowed in > > Posix file systems, Windows has more characters that are not allowed). > > > > > > > >> All this being said, I think FileSystem can and should be improved, > >> but carefully. > >> > >> It would be good if more people joined this discussion. > >> > >> Sven > > > > I think I understand the original goals, and I don't disagree with them, > > however: > > > > 1. they are based on an arguably incorrect assumption (the > > separator character can be part of a file name), > > > > 2. they've caused quite a bit of confusion due to unexpected behaviour, > > > > 3. if support for a file system that allows the separator in file names > > is ever added, we will still have to be able to parse a full path > > correctly (which the current code wouldn't do) > > > > 4. I don't think these changes conflict with the original goals, all the > > examples you provided above still function exactly the same. > > > > Does that help reduce your uneasiness? > > > > Thanks again, > > Alistair > > > > > > > > > >> > On 26 Jun 2017, at 10:12, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> > > >> > Pharo's FileSystem behaviour is currently somewhat inconsistent in its > >> > treatment of path strings. > >> > > >> > To be able to demonstrate the limitations and fixes, I'm assuming that > >> > the following files and directories have been created (/dev/shm is a > >> > memory based file system in Ubuntu): > >> > > >> > cd /dev/shm > >> > mkdir -p d1/d2/d3/d4 > >> > touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt > >> > pushd d1 && ln -s d2/d3 ./s3 && popd > >> > > >> > > >> > > >> > 1. Path's are canonicalised during initial creation, but are not when > >> > extending the path, i.e. sending #/ > >> > > >> > E.g. > >> > > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" > >> > > >> > '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" > >> > > >> > Automatic canonicalisation is problematic as the code doesn't handle > >> > symbolic links in the path name: > >> > > >> > ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" > >> > > >> > '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" > >> > > >> > > >> > 2. In an attempt to be completely general, the argument to #/ is assumed > >> > to be a single directory / file. This is incorrect as the path > >> > delimiter is not allowed to be part of the file name. The result is > >> > that path comparisons and operations such as #parent give unexpected > >> > results. > >> > > >> > E.g. > >> > > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" > >> > > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" > >> > > >> > > >> > My PR modified FileSystem so that: > >> > > >> > 1. Canonicalisation is separated out as an operation that has to be > >> > manually requested: > >> > > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" > >> > > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" > >> > > >> > > >> > 2. The argument to #/ can be either a single file / directory name or a > >> > path. > >> > > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" > >> > > >> > > >> > > >> > 3. Adds unit tests to cover the changed behaviour. > >> > > >> > > >> > While I believe that these changes improve Pharo overall, making it more > >> > intuitive and consistent, modifying the path creation to remove > >> > canonicalisation is not backward compatible and requires a change to > >> > PathTest>>testRelativeFromStringNormalization and > >> > PathTest>>testRelativeFromStringNormalizationParent to manually > >> > canonicalise the paths. > >> > > >> > Before I submit the patch, does anyone have any strong objections to the > >> > changes as described above? > >> > > >> > Thanks, > >> > Alistair > > >

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

I did a simlink total 124088 -rw-rw-r-- 1 ducasse admin 381 Jun 30 10:18 Pharo7.0-32bit-70f3b57.changes -rw-rw-r-- 1 ducasse admin 29740016 Jun 29 13:38 Pharo7.0-32bit-70f3b57.image -rw-rw-r-- 1 ducasse admin 33711804 Jun 29 13:37 Pharo7.0-32bit-70f3b57.sources -rw-r--r--@ 1 ducasse admin 65620 Jun 30 10:05 PharoDebug.log lrwxr-xr-x 1 ducasse admin 33 Jun 30 10:45 pharo-core@ -> ../../../PharoCodeBase/pharo-core drwxr-xr-x 4 ducasse admin 136 Jun 30 09:59 pharo-local/ But now I get DNU url :( repository := IceRepositoryCreator new location: ('pharo-core' asFileReference); subdirectory:'src'; createRepository. repository register. fork := repository remotes detect: [ :remote | remote remoteName = 'pharo' ]. repository pushRemote: fork. repository pullRemote: repository origin. repository checkoutBranch: 'development'. repository backend pullFrom: repository origin. repository push. repository checkoutBranch: (SystemVersion current commitHash). So I will wait that the system arrives to a state I can work with. Stef On Fri, Jun 30, 2017 at 10:48 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not get why > > repository := IceRepositoryCreator new > location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' > asFileReference); > > is not working and > > repository := IceRepositoryCreator new > location: ('pharo-core' asFileReference); > > + simlink would be working. > > > > On Fri, Jun 30, 2017 at 10:46 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Ok I try to understand. >> I already cloned the github repo and I do not want to be forced to >> download all these small files all the time. >> I want one place with all the forked code one and only one. >> >> I will try to create a simlink and try again. >> Tx >> >> Stef >> >> On Fri, Jun 30, 2017 at 10:26 AM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >>> Unfortunately you cannot share the repository the way you try because it >>> always needs to be in the image working directory in a folder named >>> 'pharo-core'. Without it the Monticello will not be able to see changes int >>> the packages. >>> >>> On one location place Pharo 7 image and execute the first script that clones >>> the repository and sets the remote fork. >>> Then into some other repository take a fresh Pharo 7 image, create symlink >>> to the 'pharo-core' folder in the original directory and then execute the >>> second script that only registers this repository into Iceberg and sets >>> proper pull and push targets on it. >>> >>> Cheers, >>> -- Pavel >>> >>> 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> So I do not understand >>>> >>>> Now if I do >>>> >>>> repository := IceRepositoryCreator new >>>> location: >>>> ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' >>>> asFileReference); >>>> subdirectory:'src'; >>>> createRepository. >>>> repository register. >>>> >>>> >>>> it works but doing it twice breaks. How can I get access to the repo? >>>> Because >>>> fork := repository remotes detect: [ :remote | remote remoteName = #pharo >>>> ]. >>>> >>>> Does not work :( >>>> And my github fork is name pharo I tried with 'pharo' but it failed too. >>>> >>>> >>>> "origin (git@github.com:Ducasse/pharo.git)" >>>> >>>> >>>> "upstream (git@github.com:pharo-project/pharo.git)" >>>> >>>> ;( >>>> >>>> >>>> >>>> >>>> On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>> > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip >>>> > >>>> > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek >>>> > <pavel.krivanek(a)gmail.com> wrote: >>>> >> The script in section "Use already created clone" is supposed to be >>>> >> used by >>>> >> a fresh Pharo 7 image. Maybe you are trying it on an image that already >>>> >> has >>>> >> the repository set? Even if I tried to use the name 'pharo' instead of >>>> >> 'myFork', the scripts work. >>>> >> >>>> >> Cheers, >>>> >> -- Pavel >>>> >> >>>> >> >>>> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>> >>>> >>> Hi pavel >>>> >>> >>>> >>> Since I want to reuse my clone. I tried the following. But I have no >>>> >>> idea about the name of my fork so I put the one of my fork = pharo and >>>> >>> it seems that this is what should be done. >>>> >>> >>>> >>> Now when I execute this script I get >>>> >>> >>>> >>> 'You already have an Iceberg repository >>>> >>> >>>> >>> So hat should I do? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Use already created clone >>>> >>> ===================== >>>> >>> >>>> >>> >>>> >>> repository := IceRepositoryCreator new >>>> >>> location: ('pharo-core' asFileReference); >>>> >>> subdirectory:'src'; >>>> >>> createRepository. >>>> >>> repository register. >>>> >>> >>>> >>> fork := repository remotes detect: [ :remote | remote remoteName = >>>> >>> #pharo >>>> >>> ]. >>>> >>> repository pushRemote: fork. >>>> >>> repository pullRemote: repository origin. >>>> >>> >>>> >>> repository checkoutBranch: 'development'. >>>> >>> repository backend pullFrom: repository origin. >>>> >>> repository push. >>>> >>> >>>> >>> repository checkoutBranch: (SystemVersion current commitHash). >>>> >>> >>>> >>> On Mon, Jun 26, 2017 at 1: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. >>>> >>> > >>>> >>> > 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 >>>> >>> > >>>> >>> >>>> >> >>>> >>>

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

I do not get why repository := IceRepositoryCreator new location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' asFileReference); is not working and repository := IceRepositoryCreator new location: ('pharo-core' asFileReference); + simlink would be working. On Fri, Jun 30, 2017 at 10:46 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Ok I try to understand. > I already cloned the github repo and I do not want to be forced to > download all these small files all the time. > I want one place with all the forked code one and only one. > > I will try to create a simlink and try again. > Tx > > Stef > > On Fri, Jun 30, 2017 at 10:26 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Unfortunately you cannot share the repository the way you try because it >> always needs to be in the image working directory in a folder named >> 'pharo-core'. Without it the Monticello will not be able to see changes int >> the packages. >> >> On one location place Pharo 7 image and execute the first script that clones >> the repository and sets the remote fork. >> Then into some other repository take a fresh Pharo 7 image, create symlink >> to the 'pharo-core' folder in the original directory and then execute the >> second script that only registers this repository into Iceberg and sets >> proper pull and push targets on it. >> >> Cheers, >> -- Pavel >> >> 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> So I do not understand >>> >>> Now if I do >>> >>> repository := IceRepositoryCreator new >>> location: >>> ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' >>> asFileReference); >>> subdirectory:'src'; >>> createRepository. >>> repository register. >>> >>> >>> it works but doing it twice breaks. How can I get access to the repo? >>> Because >>> fork := repository remotes detect: [ :remote | remote remoteName = #pharo >>> ]. >>> >>> Does not work :( >>> And my github fork is name pharo I tried with 'pharo' but it failed too. >>> >>> >>> "origin (git@github.com:Ducasse/pharo.git)" >>> >>> >>> "upstream (git@github.com:pharo-project/pharo.git)" >>> >>> ;( >>> >>> >>> >>> >>> On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>> > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip >>> > >>> > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek >>> > <pavel.krivanek(a)gmail.com> wrote: >>> >> The script in section "Use already created clone" is supposed to be >>> >> used by >>> >> a fresh Pharo 7 image. Maybe you are trying it on an image that already >>> >> has >>> >> the repository set? Even if I tried to use the name 'pharo' instead of >>> >> 'myFork', the scripts work. >>> >> >>> >> Cheers, >>> >> -- Pavel >>> >> >>> >> >>> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> >>> >>> Hi pavel >>> >>> >>> >>> Since I want to reuse my clone. I tried the following. But I have no >>> >>> idea about the name of my fork so I put the one of my fork = pharo and >>> >>> it seems that this is what should be done. >>> >>> >>> >>> Now when I execute this script I get >>> >>> >>> >>> 'You already have an Iceberg repository >>> >>> >>> >>> So hat should I do? >>> >>> >>> >>> >>> >>> >>> >>> Use already created clone >>> >>> ===================== >>> >>> >>> >>> >>> >>> repository := IceRepositoryCreator new >>> >>> location: ('pharo-core' asFileReference); >>> >>> subdirectory:'src'; >>> >>> createRepository. >>> >>> repository register. >>> >>> >>> >>> fork := repository remotes detect: [ :remote | remote remoteName = >>> >>> #pharo >>> >>> ]. >>> >>> repository pushRemote: fork. >>> >>> repository pullRemote: repository origin. >>> >>> >>> >>> repository checkoutBranch: 'development'. >>> >>> repository backend pullFrom: repository origin. >>> >>> repository push. >>> >>> >>> >>> repository checkoutBranch: (SystemVersion current commitHash). >>> >>> >>> >>> On Mon, Jun 26, 2017 at 1: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. >>> >>> > >>> >>> > 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 >>> >>> > >>> >>> >>> >> >>> >>

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

Ok I try to understand. I already cloned the github repo and I do not want to be forced to download all these small files all the time. I want one place with all the forked code one and only one. I will try to create a simlink and try again. Tx Stef On Fri, Jun 30, 2017 at 10:26 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Unfortunately you cannot share the repository the way you try because it > always needs to be in the image working directory in a folder named > 'pharo-core'. Without it the Monticello will not be able to see changes int > the packages. > > On one location place Pharo 7 image and execute the first script that clones > the repository and sets the remote fork. > Then into some other repository take a fresh Pharo 7 image, create symlink > to the 'pharo-core' folder in the original directory and then execute the > second script that only registers this repository into Iceberg and sets > proper pull and push targets on it. > > Cheers, > -- Pavel > > 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> So I do not understand >> >> Now if I do >> >> repository := IceRepositoryCreator new >> location: >> ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' >> asFileReference); >> subdirectory:'src'; >> createRepository. >> repository register. >> >> >> it works but doing it twice breaks. How can I get access to the repo? >> Because >> fork := repository remotes detect: [ :remote | remote remoteName = #pharo >> ]. >> >> Does not work :( >> And my github fork is name pharo I tried with 'pharo' but it failed too. >> >> >> "origin (git@github.com:Ducasse/pharo.git)" >> >> >> "upstream (git@github.com:pharo-project/pharo.git)" >> >> ;( >> >> >> >> >> On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip >> > >> > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek >> > <pavel.krivanek(a)gmail.com> wrote: >> >> The script in section "Use already created clone" is supposed to be >> >> used by >> >> a fresh Pharo 7 image. Maybe you are trying it on an image that already >> >> has >> >> the repository set? Even if I tried to use the name 'pharo' instead of >> >> 'myFork', the scripts work. >> >> >> >> Cheers, >> >> -- Pavel >> >> >> >> >> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> >> >>> Hi pavel >> >>> >> >>> Since I want to reuse my clone. I tried the following. But I have no >> >>> idea about the name of my fork so I put the one of my fork = pharo and >> >>> it seems that this is what should be done. >> >>> >> >>> Now when I execute this script I get >> >>> >> >>> 'You already have an Iceberg repository >> >>> >> >>> So hat should I do? >> >>> >> >>> >> >>> >> >>> Use already created clone >> >>> ===================== >> >>> >> >>> >> >>> repository := IceRepositoryCreator new >> >>> location: ('pharo-core' asFileReference); >> >>> subdirectory:'src'; >> >>> createRepository. >> >>> repository register. >> >>> >> >>> fork := repository remotes detect: [ :remote | remote remoteName = >> >>> #pharo >> >>> ]. >> >>> repository pushRemote: fork. >> >>> repository pullRemote: repository origin. >> >>> >> >>> repository checkoutBranch: 'development'. >> >>> repository backend pullFrom: repository origin. >> >>> repository push. >> >>> >> >>> repository checkoutBranch: (SystemVersion current commitHash). >> >>> >> >>> On Mon, Jun 26, 2017 at 1: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. >> >>> > >> >>> > 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 >> >>> > >> >>> >> >> >> >

June 30, 2017

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

by Alistair Grant

Hi Guillermo, On Fri, Jun 30, 2017 at 10:12:32AM +0200, Guillermo Polito 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). Feel free to ignore this section, it isn't important to the conclusion... But that's my point - it depends on where the image is launched. If I want to be sure that the file will be found, I need to resolve from the image directory, not the process current working directory. Using the current definition of defaultWorkingDirectory I don't need to worry about this. > 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? 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. This is the important bit on which we all seem to agree. :-) > - 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

June 30, 2017

Jump to page: