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

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

by Alistair Grant

Hi Subbu, On Tue, Jun 27, 2017 at 09:19:20PM +0530, K K Subbu wrote: > On Monday 26 June 2017 01:42 PM, Alistair Grant wrote: > >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)" > > The meaning of 's3/..' is ambiguous when s3 is a symlink. Should 's3' be > resolved or not before #parent op is applied? Disambiguation depends on > context, so early canonicalization is a bug. > > My own preference is to not to canonicalize at all and 's3/..' should be > left as {s3, ..}. See > > http://man7.org/linux/man-pages/man7/path_resolution.7.html > > >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. > > Path class>>from:delimiter has a bug. It attempts to canonicalize elements > parsed from the String regardless of the context. If the code is changed to: > > pathClass withAll: (aDelimiterCharacter split: aString) > > your test will pass. This is basically what I do (it also removes empty segments). > I wonder why Path was subclassed from Object and not from > SequenceableCollection? > > >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" > > I am ok with this. > > >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" > > ok with this too. > > >3. Adds unit tests to cover the changed behaviour. > >... > >Before I submit the patch, does anyone have any strong objections to the > >changes as described above? > > None from my side. > > Regards .. Subbu Thanks! Alistair

June 27, 2017

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

by Alistair Grant

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 27, 2017

Re: [Pharo-dev] Windows 10 crash - LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

by Peter Uhnak

Hi, I'm experiencing this problem regularly (at least once a week), I've noticed that it sometimes happens after dualboot, and that restarting windows usually helps... but this is always on launch of the image, it never occured later udring runtime; so now the first thing I do on boot is to check if Pharo works and if not I restart... Peter On Tue, Jun 27, 2017 at 04:43:06PM +0200, Andrei Chis wrote: > Hi, > > On Windows 10 with the Pharo 6 release and the latest vm [1] I get the > following crash when attempting to save the image after doing some more > intensive computations: > > ------------------------------------------------------------------------------------------ > # Debug console > # To close: F2 -> 'debug options' -> 'show output console' > # To disable: F2 -> 'debug options' -> 'show console on errors' > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(c:\pharo6\SurfacePlugin) (998: Invalid access to memory > location. > > ) > LoadLibrary(c:\pharo6\SurfacePlugin.dll) (998: Invalid access to memory > location. > > ) > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(c:\pharo6\SurfacePlugin) (998: Invalid access to memory > location. > > ) > LoadLibrary(c:\pharo6\SurfacePlugin.dll) (998: Invalid access to memory > location. > > ) > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(c:\pharo6\SurfacePlugin) (998: Invalid access to memory > location. > > ) > LoadLibrary(c:\pharo6\SurfacePlugin.dll) (998: Invalid access to memory > location. > > ) > ------------------------------------------------------------------------------------------ > > The image take around 600MB before the crash but that is expected. > I've seen that this error was appearing before in the past. > Any suggestions of how to debug it? > > Cheers, > Andrei > > [1] > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201706211817-f544…

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Stephan Eggermont

On 27/06/17 14:56, Sven Van Caekenberghe wrote: > P3 is a modern, lean and mean PostgreSQL client for Pharo. Nice! Thank you Stephan

June 27, 2017

Re: [Pharo-dev] zero size pharo vm zips

by Esteban Lorenzano

yes, this is because we ran out of space. next build should fix that :) Esteban > On 27 Jun 2017, at 19:31, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > http://files.pharo.org/vm/pharo-spur32/win/ <http://files.pharo.org/vm/pharo-spur32/win/> > > All vm-zips from the last days have size 0

June 27, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Paul DeBruicker

Luke Gorrie wrote > Hi Paul, > > On 23 June 2017 at 22:11, Paul DeBruicker < > pdebruic@ > > wrote: > >> For those projects described with Metacello baselines or configurations >> you >> can issue a #fetch command to download all the Monticello packages needed >> to >> load the projects into your image.... >> > > Thanks for this idea! > > Could be that a "high-brow" approach based on Metacello metadata is an > interesting alternative to a "low-brow" approach based on simply scraping > the package-cache/ directory after installation. > > Here is what I would really like (restating from another mail): > > To make a dump of all available packages (restricting to ones with > Metacello configurations is probably fine) and, for each package, to make > a > list of: > > - The mcz files required for installation (and any other downloded > resources if there are some...?) > - The sha256 hash of each mcz file (assume I can get this easily if the > file is downloaded) > - The URL where the file was downloaded from / should be downloaded from > in > the future > > Do you think this can be determined in a straightforward way from > Metacello > metadata? Hi Luke, I think it is straight forward, if not already supported. I think you want data that is contained in the instance of the MetacelloVersionLoadDirective that is created by Metacello's record command (https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr…) But I'm not sure where to look to give you the URL from where its loading the package. So continuing with the Seaside example I posted replace the #fetch with a #record and inspect the output of the command. Hope this helps Paul. -- View this message in context: http://forum.world.st/Recursively-downloading-Pharo-packages-Building-image… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2017

zero size pharo vm zips

by Nicolai Hess

http://files.pharo.org/vm/pharo-spur32/win/ All vm-zips from the last days have size 0

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Sven Van Caekenberghe

> On 27 Jun 2017, at 17:37, Michael Forster <mike(a)forsterfamily.ca> wrote: > > On Tue, Jun 27, 2017 at 7:56 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> P3 is a modern, lean and mean PostgreSQL client for Pharo. >> >> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. >> >> With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. >> >> More info, usage examples and code at https://github.com/svenvc/P3 >> >> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. >> >> This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. >> >> Sven >> >> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! >> >> > > > Very nice, Sven. Common Lisp's loss was Pharo's gain ;-) Haha, my CL days are long, long gone (though I still maintain 1 CL web app in production, more than 10 years after it was written), but it was a lot of fun. Like Common Lisp, I feel that Pharo is really an amplifier, a power tool, that makes seemingly impossible things possible and easy/fun to do. If you look at all the code being written by others (Calypso, Iceberg, Epicea, GT Tools, Spotter, and so many, many others), you can see the same effect going on. What is important IMHO is that people stick with (keeping supporting/documenting/promoting) the open source code they publish (else it will decay very quickly). > Mike >

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Esteban A. Maringolo

Amazing work Sven!!! This is very good. Esteban A. Maringolo 2017-06-27 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. > > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! > >

June 27, 2017

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

by K K Subbu

On Tuesday 27 June 2017 05:01 PM, Sven Van Caekenberghe wrote: > 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. +1. Pharo's elegant design captures the essentials of naming file objects. > In your reasoning, your truth, your reference is always the Unix file > system and the way paths are handled > 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. Agreed that the first form is quite elegant. But I see no harm in graceful acceptance of the second. Such strings could be encountered in scripts and variables. It is also a convenient shorthand. > Windows is an important target for Pharo, they use $\ not $/. Windows cmd shell uses only $\ while its API accepts both. This is a eternal meme thread in Win32 mailing lists ;-). > 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 ? Path elements are platform-specific and their resolution to specific inode is context-specific. Canonicalization is only needed in low level code. > Should we support ~ ? Sometimes I would like that too, but maybe > > FileLocator home Elements like ~ or $HOME are expanded by shell before calling host API. GUI shells based on XDG also expand other variables (see ~/.config/user-dirs.dirs) It is upto Pharo to define its own variables and expand them just before calling APIs (say from {$PHARO_HOME, "pharo.conf"} Regards .. Subbu

June 27, 2017