- Pharo-dev - lists.pharo.org

GSoC 2017 - Week 7 Update - Enhancing Pharo Command Line Interface

by Rajula Vineet

Hi all, Sorry I couldn`t post updates for a few weeks. Recently, I started working on implementing clap-st as a command line handler in Pharo. During the last few weeks I have worked on the new working directory implementation. For the last week blog post, I wrote a post on SessionManagers <https://vineetreddy.wordpress.com/2017/06/28/session-manager-in-pharo/> . It would be helpful if you can give your feedback on this. Thanks in advance. Rajula -- View this message in context: http://forum.world.st/GSoC-2017-Week-7-Update-Enhancing-Pharo-Command-Line-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 28, 2017

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

by Eliot Miranda

Sven, On Tue, Jun 27, 2017 at 5: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. > Cool! Congratulations! 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 ! > _,,,^..^,,,_ best, Eliot

June 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Ben Coman

On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > >> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >> > >> > >> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com >> >: >> >> >> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >> >> <pavel.krivanek(a)gmail.com> wrote: >> >> > Hi, >> >> > >> >> > this mail describes how to start to send pull requests to Pharo 7 >> Github >> >> > repository from Pharo 7. >> >> >> >> Thank you for the great explanation Pavel. >> >> >> >> > Preparations >> >> > ===================== >> >> > >> >> > - you need to have a Github account and set SSH keys. See >> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >> >> > - create own pharo-project/pharo repository fork. Go to >> >> > https://github.com/pharo-project/pharo, click on "Fork" button and >> >> > follow >> >> > the instructions >> >> >> >> [ ... ] >> >> >> >> > Issue processing >> >> > ===================== >> >> > >> >> > - create new case on FogBugz to get the issue number >> >> > - open Iceberg and from the context menu on the 'pharo' repository >> do: >> >> > Pharo >> >> > - Create new branch from FogBugz issue, enter the issue ID and it >> will >> >> > fill >> >> > the full branch name for you >> >> > - create your changes (you can do it before the creation of the >> branch >> >> > too) >> >> > - commit and push your changes in Iceberg, this way you will commit >> your >> >> > branch to your fork repository. Remember that the Iceberg commit >> window >> >> > has >> >> > two buttons, one for local commit, the second for commit with >> immediate >> >> > push. They can be very long because they contain the full branch >> (issue) >> >> > name >> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >> Create >> >> > pull >> >> > request, fill your >> >> > - fill your Github credentials >> >> > - leave the PR title, comment is not required, check the pull request >> >> > head >> >> > and base. The base MUST be pharo-project/pharo development. Create >> the >> >> > pull >> >> > requests >> >> > - go to https://github.com/pharo-project/pharo/pulls, check your >> pull >> >> > requests and put URL of it into the issue record on FogBugz (as a >> >> > comment). >> >> > Resolve the issue as Fix review needed >> >> >> >> It means, there is no PR without a corresponding FogBugz issue ? >> > >> > >> > Yes, at least for code changes we would like to keep this relation. If >> it is >> > a really trivial change in readme or something like that, we can accept >> no >> > related issue record. >> > Please prefer to comment the issues instead of PRs directly to have all >> > information at one place. >> >> Thank you Pavel for the explanation. >> >> Maybe in the future, it will make sense to put everything in the PR >> and use github issues. >> You will use CI travis builds for all PR ? >> > > For now we will use FogBugz because it has a lot of nice features and good > API. Maybe we will switch it in future but now we should not change too > many things at once :-) > For several reasons we now prefer to use own infrastructure for checking > of PRs (mainly because of MacOS issues on Travis). But again, it can be > changed in future. > > It would be interesting to see how this might fit in with our workflow... https://blog.fogcreek.com/fogbugz-github-integration/ cheers -ben

June 28, 2017

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