- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 6620fb: 60504

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6620fb9590b2f111b274832b86ab30e560c95f05 https://github.com/pharo-project/pharo-core/commit/6620fb9590b2f111b274832b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-29 (Thu, 29 Jun 2017) Changed paths: M CodeExport.package/extension/TClassDescription/instance/fileOutLocalMethodsInCategory_on_.st M Files.package/StdioStream.class/instance/accessing/next_.st M Kernel.package/Context.class/class/simulation/runSimulated_.st M Monticello.package/MCMcdReader.class/instance/loading/loadPatch.st M Monticello.package/MCMczReader.class/instance/loading/loadDefinitions.st M Monticello.package/MCPatch.class/instance/intializing/initializeWithBase_target_.st M Monticello.package/MCVersion.class/instance/enumerating/withAllDependenciesDo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60503.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60504.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60503.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60504.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60504 20185 Request pipe after block argments https://pharo.fogbugz.com/f/cases/20185 20183 TraitDescription>>fileOutLocalMethodsInCategory:on: method temp var name overlap https://pharo.fogbugz.com/f/cases/20183 20184 Request space between argument and selector in StdioStream>>next: https://pharo.fogbugz.com/f/cases/20184 http://files.pharo.org/image/60/60504.zip

June 29, 2017

Early Pull Request Validation Process

by Guillermo Polito

Hi all, As some/a lot of you have been asking how to contribute, I'm here to answer some questions :). First of all, integrating fixes in Pharo has been "slowed down" because we missed the Monkey for Pull Request (PR) integration. Some of you have seen a travis job going around and checking. That was our initial solution, but it has a main issue for us: it only works for unix because our build process is long, uses lots of small files due to file tree and osx travis support is REALLY SLOW with I/O access. This is why we chose to use good old Jenkins. https://ci.inria.fr/pharo-ci-jenkins2/ # Why it took so much time Just some explanation of why it took so much time (you can skip this if you're not interested). I started working on integrating Jenkins with Pull Requests several weeks ago (note that I'm part time on this, also working in other projects and the deadlines of the past weeks like IWST were killing my time). We have now a new and working Jenkins server for Pharo7. This jenkins server is hosted in Inria, its url being - We chose to use Jenkins 2 because I managed to make the PR integration plugin work only in Jenkins 2. - This required the creation of a new jenkins server + slaves. The pharo and pharo-contribution servers run with Jenkins 1.6 and I did not want to migrate existing servers to not break existing jobs. - At the same moment, the inria CI infrastructure was having some (lots?) of hiccups because of storage limitations. I spent several weeks to create the running slaves for each platform and connect jenkins to them because of that. - Finally, I spent some time to test the new Jenkins MultiJobs. These kind of jobs allow to split a single job in sequential phases. And each phase can have multiple jobs that run concurrently. This allows us to bootstrap once (on unix) and test in all platforms. An example of the new multijob can be found here: https://ci.inria.fr/pharo-ci-jenkins2/job/Pharo-PullRequest-Pipeline/ # Current Design Right at this moment, we are validating PRs using Jenkins. The process is as follows: 1) Github notifies about changes in PRs to Jenkins using webhooks. So far, we have configured it to notify about PR changes (including comments) and normal pushes (to capture merges into the #development branch). 2) Upon the reception of a GH notification, Jenkins will launch two jobs/validations. The basic structure of both validations is the same so far. Bootstrap once (unix) and test in many platforms. There are the following two test configurations however. 2.1) Full Validation: tests 32 and 64 bits, for linux, osx and windows. This configuration is not fully working right now because we found a VM bug in 64 bits that prevents us from creating a full pharo image. Bootstrap is Ok, but there is a segfault when loading a big Metacello configuration. 2.2) Basic Validation: tests only 32 bits, for now in linux and osx (I'm planning to do windows today). This validation is to give us nevertheless a feedback of the build even if the full is failing so far. 2.3) Others? We could easily add new validations to run some faster tests i.e., just loading a patch on the previous image. 3) Jenkins takes control and notifies Github So far, Full validation is failing, and I plan to keep it running until it gets green. I don't care if it's red right now, the idea is that we should fix it, and we should remember it is broken :). On the other hand, the Basic Validation is working and running tests. Once the tests runs are finished, Github PR state will be either a success (if all tests went green) or a failure (if it failed or some tests failed). You will see actually a message saying: Validation Failure. Please check test results. 7782 tests run, 0 skipped, 6 failed. + a link to jenkins if you want to inspect results. You can see an example of it in action in here: https://github.com/pharo-project/pharo/pull/119 # Next points Right now we are missing: - Fogbugz integration - Publish new images in the file server when a push/merge happens in the #development branch (I should sit today with Esteban to do some ssh key configuration in a server I have no access to) - fixing the failing tests => TO HAVE A GREEN BUILD> :D - Enhance tests? - your enhancement idea :) The current validation already gives us an idea of what works and what does not work, what breaks the bootstrap, and if we have failing tests or not. I'd like however that before integrating a fix, there is at least 2 people that look at it and put a +1. Because Monkey validation and the ability to merge does not mean much actually :). If you have some questions, enhancements, there is this thread, there is the #bootstrap channel in discord also. Guille (in behalf of everybody that helped me with this) -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 29, 2017

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

by Stephane Ducasse

Thanks for all your positive energy. Your return of experience on the new tools is great too. I experienced some glitches but this is getting really better and open a lot of possibilities. On Wed, Jun 28, 2017 at 4:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 27 Jun 2017, at 14:56, 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. > > I made the code easier to load. > > The default group loads P3Client and its basic dependencies NeoJSON and ZTimestamp > > Metacello new > baseline: 'P3'; > repository: 'github://svenvc/P3'; > load. > > The glorp group loads P3DatabaseDriver and the whole of Glorp (warning: large download) > > Metacello new > baseline: 'P3'; > repository: 'github://svenvc/P3'; > load: 'glorp'. > >> 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 29, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Ben Coman

On Thu, Jun 29, 2017 at 1:10 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > I just realised that on OSX it is enough to put .sources in the same > folder with Pharo.app which is extremely cool because there is no need to > carry them around with images. > IIUC this won't work with Pharo 7, since a new sources file will be delivered with each new build. cheers -ben > > However, in case of Window it is different. I tried to put .source in the > same folder with Pharo.exe but got a notification that sources in the > *image* folder were not found. > > It would be great to unify this behaviour among platforms :) > I prefer OSX .sources location strategy. > > Cheers, > Alex >

June 29, 2017

Re: [Pharo-dev] A better way to serialise methods?

by Eliot Miranda

Hi Alex, > On Jun 28, 2017, at 10:38 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi, > > Smalltalk is famous for tiny methods with just a few parameters. However, sometimes libraries written in C have methods that accept many arguments. In my case I have a method that requires to pass exactly 15 arguments, luckily 15 is maximum possible amount of arguments in Pharo, so my day was saved. Until I tried to load the same code in Window. Here is my ffi call method: > > primMeasure: aTextRun start: aStart length: aMaxLength breakBefore: aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap: aCanWordWrap breakPriority: aBreakPriorityPointer > > ^ self ffiCall: #(uint32 text_run_break_and_measure ( > TextRun aTextRun, > uint32 aStart, > uint32 aMaxLength, > bool aLineBreakBefore, > double aWidth, > TextPropertyProvider aProvider, > TextSuppressBreak aSuppressBreak, > ExternalAddress aTrimWhitespace, > NativeTextMetrics aMetrics, > TextBoundingBoxType aBoundingBoxType, > Canvas aCanvas, > ExternalAddress aUsedHyphenation, > ExternalAddress aLastBreak, > bool aCanWordWrap, > ExternalAddress aBreakPriorityPointer)) > > If I try to commit it using filetree/gitfiletree/Iceberg I get an .st method source file with the following name (138 characters): >> primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st > > And of course trying to clone the repo using git fails on Window because filename is too long. > So here comes the question: Is it really necessary to name method source file according to the method's #sender? Would it make sense to trim the filename and append a short hash to avoid collisions? IMO file per class with methods ordered by selector makes even more sense. Provided methods are ordered by selector then incidental changes such as protocol or version stamp won't cause false differences to be shown. > > Cheers, > Alex

June 28, 2017

Re: [Pharo-dev] debug vm windows?

by Andrei Chis

On Mon, Jun 19, 2017 at 1:20 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > the instructions are not merged yet and I am not sure whether something > has changed since I wrote it (April 8), but I wrote down instructions and > created scripts for building the VM on Windows (7+) > > https://github.com/pharo-project/pharo-vm/pull/128 > https://github.com/peteruhnak/pharo-vm/blob/windows-build/README-Win32.md > https://github.com/peteruhnak/pharo-vm/tree/windows-build/scripts/windows > By the way, thanks for publishing these scripts. I found them a while back and they were quite useful in figuring out how to configure cygwin. Cheers, Andrei in particular the Manual Compilation at the end; iirc `mvm -a` creates > asserting VM, `mvm -d` debug, `mvm -f` regular, and `mvm -A` all of them. > > Peter > > > On Tue, Jun 13, 2017 at 10:57:45PM +0200, phil(a)highoctane.be wrote: > > Not at the moment. > > > > On Tue, Jun 13, 2017 at 10:08 PM, Andrei Chis < > chisvasileandrei(a)gmail.com> > > wrote: > > > > > Thanks! Any chance you can redo the build to get also a debug vm for > > > the latest version? > > > > > > Cheers, > > > Andrei > > > > > > On Tue, Jun 13, 2017 at 8:02 PM, phil(a)highoctane.be < > phil(a)highoctane.be> > > > wrote: > > > > I have an older build here. > > > > > > > > https://ci.appveyor.com/project/philippeback/pharo-vm > > > > > > > > https://bintray.com/pharophile/pharo-vm/build/ > > > view/files?sort=name&order=asc#files/ > > > > > > > > There is an normal, assert and debug vm in there. > > > > > > > > Phil > > > > > > > > On Tue, Jun 13, 2017 at 7:14 PM, Andrei Chis < > chisvasileandrei(a)gmail.com > > > > > > > > wrote: > > > >> > > > >> Hi, > > > >> > > > >> Is there a Pharo debug vm for windows already build and available > > > >> somewhere? > > > >> > > > >> Cheers, > > > >> Andrei > > > >> > > > > > > > > > > > >

June 28, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Aliaksei Syrel

Aha! I found the problem... very strange. So, there is a difference: If I run Pharo.exe from Coherence mode in Parallels then VM directory is given relative to \Mac and sources can not be found: [image: Inline images 1] If I run Pharo.exe from "Virtual machine" mode in Parallels then VM directory is correct and source work from VM folder: [image: Inline images 2] I think it is an interesting discovery :) Cheers, Alex On 28 June 2017 at 20:20, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Henrik, > > Here is what `OSPlatform current potentialLocationsOfSourcesFile` gives > me: > > [image: Inline images 2] > > Are you sure you have the correct version of .sources? > > Yes, I use v60 sources with 60503 Pharo and stable VM. If I put sources > in the image folder it works... Very strange. > > Cheers, > Alex > > > On 28 June 2017 at 19:59, Henrik Nergaard <draagren(a)outlook.com> wrote: > > > > Are you sure you have the correct version of .sources?. > > > > It has allways been possible to have the .sources at the .exe (I have > allways done it that way), (are you sure that the right vm is started, > clicking on an image might launch a different vm if you have multiple). > > > > > > What is the output of `OSPlatform current potentialLocationsOfSourcesFile` > ? > > > > > > To debug: > > > > Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and > the do `SourceFiles ensureOpen` > > > > > > Best regards, > > > > Henrik > > > > > > > > ________________________________ > > Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Aliaksei > Syrel <alex.syrel(a)gmail.com> > > Sendt: 28. juni 2017 19:10:19 > > Til: Pharo Development List > > Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX > > > > Hi, > > > > I just realised that on OSX it is enough to put .sources in the same > folder with Pharo.app which is extremely cool because there is no need to > carry them around with images. > > > > However, in case of Window it is different. I tried to put .source in > the same folder with Pharo.exe but got a notification that sources in the > *image* folder were not found. > > > > It would be great to unify this behaviour among platforms :) > > I prefer OSX .sources location strategy. > > > > Cheers, > > Alex >

June 28, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Aliaksei Syrel

Hi Henrik, Here is what `OSPlatform current potentialLocationsOfSourcesFile` gives me: [image: Inline images 2] Are you sure you have the correct version of .sources? Yes, I use v60 sources with 60503 Pharo and stable VM. If I put sources in the image folder it works... Very strange. Cheers, Alex On 28 June 2017 at 19:59, Henrik Nergaard <draagren(a)outlook.com> wrote: > > Are you sure you have the correct version of .sources?. > > It has allways been possible to have the .sources at the .exe (I have allways done it that way), (are you sure that the right vm is started, clicking on an image might launch a different vm if you have multiple). > > > What is the output of `OSPlatform current potentialLocationsOfSourcesFile` ? > > > To debug: > > Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and the do `SourceFiles ensureOpen` > > > Best regards, > > Henrik > > > > ________________________________ > Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Aliaksei Syrel <alex.syrel(a)gmail.com> > Sendt: 28. juni 2017 19:10:19 > Til: Pharo Development List > Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX > > Hi, > > I just realised that on OSX it is enough to put .sources in the same folder with Pharo.app which is extremely cool because there is no need to carry them around with images. > > However, in case of Window it is different. I tried to put .source in the same folder with Pharo.exe but got a notification that sources in the *image* folder were not found. > > It would be great to unify this behaviour among platforms :) > I prefer OSX .sources location strategy. > > Cheers, > Alex

June 28, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Henrik Nergaard

Are you sure you have the correct version of .sources?. It has allways been possible to have the .sources at the .exe (I have allways done it that way), (are you sure that the right vm is started, clicking on an image might launch a different vm if you have multiple). What is the output of `OSPlatform current potentialLocationsOfSourcesFile` ? To debug: Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and the do `SourceFiles ensureOpen` Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Aliaksei Syrel <alex.syrel(a)gmail.com> Sendt: 28. juni 2017 19:10:19 Til: Pharo Development List Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX Hi, I just realised that on OSX it is enough to put .sources in the same folder with Pharo.app which is extremely cool because there is no need to carry them around with images. However, in case of Window it is different. I tried to put .source in the same folder with Pharo.exe but got a notification that sources in the *image* folder were not found. It would be great to unify this behaviour among platforms :) I prefer OSX .sources location strategy. Cheers, Alex

June 28, 2017

A better way to serialise methods?

by Aliaksei Syrel

Hi, Smalltalk is famous for tiny methods with just a few parameters. However, sometimes libraries written in C have methods that accept many arguments. In my case I have a method that requires to pass exactly 15 arguments, luckily 15 is maximum possible amount of arguments in Pharo, so my day was saved. Until I tried to load the same code in Window. Here is my ffi call method: primMeasure: aTextRun start: aStart length: aMaxLength breakBefore: aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap: aCanWordWrap breakPriority: aBreakPriorityPointer ^ self ffiCall: #(uint32 text_run_break_and_measure ( TextRun aTextRun, uint32 aStart, uint32 aMaxLength, bool aLineBreakBefore, double aWidth, TextPropertyProvider aProvider, TextSuppressBreak aSuppressBreak, ExternalAddress aTrimWhitespace, NativeTextMetrics aMetrics, TextBoundingBoxType aBoundingBoxType, Canvas aCanvas, ExternalAddress aUsedHyphenation, ExternalAddress aLastBreak, bool aCanWordWrap, ExternalAddress aBreakPriorityPointer)) If I try to commit it using filetree/gitfiletree/Iceberg I get an .st method source file with the following name (138 characters): > > primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st And of course trying to clone the repo using git fails on Window because filename is too long. So here comes the question: *Is it really necessary to name method source file according to the method's #sender? Would it make sense to trim the filename and append a short hash to avoid collisions?* Cheers, Alex

June 28, 2017