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

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Dale Henrichs

On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: > >> On 6 Nov 2017, at 15:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations > How so ? > > What is the problem with Symbol>>#asString ? I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:) It's not just Metacello. It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose -- Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not... And I don't need to hear about how Pharo is not Smalltalk:) Dale

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Sven Van Caekenberghe

> On 6 Nov 2017, at 15:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations How so ? What is the problem with Symbol>>#asString ? #foo asString => 'foo' #'foo-bar' asString => 'foo-bar' Sven

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Dale Henrichs

...also note that I have seen a number of baselines where symbols are used in places where Strings are required ... of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations ... In Metacello the only "legal" place to use a Symbol is for a symbolic version ... Of course this is really only an issue for cross platform projects and the issue shows up as a problem real fast ... it's just painful for the uninitiated to debug ... Dale On 11/6/17 1:51 AM, stephan wrote: > On 05-11-17 22:05, Stephane Ducasse wrote: >> I was working in cleaning the users of asLayoutFrame and when I >> commit I see >> >> - #category : 'Morphic-Base-Layouts' >> + #category : #Morphic-Base-Layouts >> >> but #category : #Morphic-Base-Layouts >> is not a valid symbol. > > In Metacello we use the quoted symbol form exactly because different > smalltalks have different ideas of what a valid symbol is. > > Stephan > > >

Nov. 6, 2017

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Raffaello Giulietti

Hi Nicolas, seems that only the upload to the Pharo repo fails, not the building by itself. But the cog_win64x64_pharo.stack.spur_201711061254.zip is not even on the bintray repo. I would expect it at least there. Is that right? Just wondering... Of course, I'll try to grab the SqueakSSL.dll from the squeak 64 bit/win vm. On 2017-11-06 15:05, Nicolas Cellier wrote: > Unfortunately, the VM is corectly built, but the script fails at deploy > stage... > https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls… > > Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to > pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win> > Warning: Permanently added the RSA host key for IP address > '193.51.193.142' to the list of known hosts. > Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to > pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip> > scp: /appli/files.pharo.org/vm/pharo-spur64/win/latest.zip > <http://files.pharo.org/vm/pharo-spur64/win/latest.zip>: Permission denied > Command exited with code 1 > > At this stage, there's not much i can do. > You'll have to ask to Pharo team to correct this problem. > > In the interim, I suggest you download the Squeak VM for Win64 and pick > SqueakSSL.dll there... > > 2017-11-06 11:34 GMT+01:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>: > > Thanks Nicolas! > > > > On 2017-11-06 11:30, Nicolas Cellier wrote: > > Oh yes, you're right, > the SqueakSLL could have been built but was not built in pharo... > I just changed > https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p…> > this should trigger another automated build and if all goes well > you will have a new bintray artefact to test. > > 2017-11-06 10:21 GMT+01:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>>: > > > Â Â Hi Nicolas, > > Â Â I tried both the vm found at the location you mention (dated > Â Â 2017-10-22): > > https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…> > > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…>> > > Â Â and the "official" latest vm on the Pharo site (dated > 2017-11-01) > > http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…> > > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…>> > > > > Â Â Neither of them contains the SqueakSSL.dll and, in fact, in > both > Â Â cases I get an exception when using Gofer to download Roassal2, > Â Â using the latest 60519 image: > > Â Â Gofer it > Â Â Â Â Â smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > Â Â Â Â Â configurationOf: 'Roassal2'; > Â Â Â Â Â loadDevelopment > > Â Â This works on Pharo 32 bit/Win, where SquekSSL is present. > > > > > > > > > Â Â On 2017-11-04 23:31, Nicolas Cellier wrote: > > Â Â Â Â Note that win64 SSL works at least since > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…>> > Â Â Â Â and > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…>> > > Â Â Â Â Maybe it's a bit too recent to be found in official Pharo > Â Â Â Â distribution, but if you can live with bleeding edge, > pick a > Â Â Â Â more recent VM here: > https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files> > > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files>> > Â Â Â Â (or maybe you can find one from the Pharo site?) > > > Â Â Â Â 2017-11-04 22:21 GMT+01:00 henry <henry(a)callistohouse.club > Â Â Â Â <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club> > Â Â Â Â <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club>>>>: > > Â Â Â Â Â Â Â This is the advantage of in-image SSL solution, > found in the > Â Â Â Â Â Â Â Cryptography repository: > > http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>> > Â Â Â Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>>> > > Â Â Â Â Â Â Â Sent from ProtonMail Mobile > > > Â Â Â Â Â Â Â On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti > Â Â Â Â Â Â Â <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> > Â Â Â Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>>> wrote: > > Â Â Â Â Â Â Â Â Â Hi, the SqueakSSL dll is not included in the Pharo > Â Â Â Â Â Â 64bit/Win vm > Â Â Â Â Â Â Â Â Â distribution. I guess this has to do with > problems in > Â Â Â Â Â Â building it. > Â Â Â Â Â Â Â Â Â Anybody knows where the difficulties lie? > Greetings > Â Â Â Â Â Â Raffaello > > > > > > > > >

Nov. 6, 2017

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Nicolas Cellier

Unfortunately, the VM is corectly built, but the script fails at deploy stage... https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls… Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win Warning: Permanently added the RSA host key for IP address '193.51.193.142' to the list of known hosts. Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip scp: /appli/files.pharo.org/vm/pharo-spur64/win/latest.zip: Permission denied Command exited with code 1 At this stage, there's not much i can do. You'll have to ask to Pharo team to correct this problem. In the interim, I suggest you download the Squeak VM for Win64 and pick SqueakSSL.dll there... 2017-11-06 11:34 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > Thanks Nicolas! > > > > On 2017-11-06 11:30, Nicolas Cellier wrote: > >> Oh yes, you're right, >> the SqueakSLL could have been built but was not built in pharo... >> I just changed https://github.com/OpenSmallta >> lk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext >> this should trigger another automated build and if all goes well you will >> have a new bintray artefact to test. >> >> 2017-11-06 10:21 GMT+01:00 Raffaello Giulietti < >> raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch >> >>: >> >> >> Hi Nicolas, >> >> I tried both the vm found at the location you mention (dated >> 2017-10-22): >> >> https://bintray.com/opensmalltalk/vm/download_file?file_ >> path=cog_win64x64_pharo.cog.spur_201710221351.zip >> <https://bintray.com/opensmalltalk/vm/download_file?file_ >> path=cog_win64x64_pharo.cog.spur_201710221351.zip> >> >> and the "official" latest vm on the Pharo site (dated 2017-11-01) >> >> http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64- >> 201711010928-e14fbab.zip >> <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_ >> 64-201711010928-e14fbab.zip> >> >> >> >> Neither of them contains the SqueakSSL.dll and, in fact, in both >> cases I get an exception when using Gofer to download Roassal2, >> using the latest 60519 image: >> >> Gofer it >> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >> configurationOf: 'Roassal2'; >> loadDevelopment >> >> This works on Pharo 32 bit/Win, where SquekSSL is present. >> >> >> >> >> >> >> >> >> On 2017-11-04 23:31, Nicolas Cellier wrote: >> >> Note that win64 SSL works at least since >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa >> 70862014d3bb510f2edf7465e857c645be0e4 >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ba >> a70862014d3bb510f2edf7465e857c645be0e4> >> and >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa >> 8241de11b99ecaea5236b3d3e3c0d303c6eb4 >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca >> a8241de11b99ecaea5236b3d3e3c0d303c6eb4> >> >> Maybe it's a bit too recent to be found in official Pharo >> distribution, but if you can live with bleeding edge, pick a >> more recent VM here: >> https://bintray.com/opensmalltalk/vm/cog/201710221351#files >> <https://bintray.com/opensmalltalk/vm/cog/201710221351#files> >> (or maybe you can find one from the Pharo site?) >> >> >> 2017-11-04 22:21 GMT+01:00 henry <henry(a)callistohouse.club >> <mailto:henry@callistohouse.club >> <mailto:henry@callistohouse.club>>>: >> >> This is the advantage of in-image SSL solution, found in the >> Cryptography repository: >> >> http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html> >> <http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html>> >> >> Sent from ProtonMail Mobile >> >> >> On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch> >> <mailto:raffaello.giulietti@lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>>> wrote: >> >> Hi, the SqueakSSL dll is not included in the Pharo >> 64bit/Win vm >> distribution. I guess this has to do with problems in >> building it. >> Anybody knows where the difficulties lie? Greetings >> Raffaello >> >> >> >> >> >> >> > >

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-06 10:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 6 Nov 2017, at 10:37, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > Because it's a cross dialect library and because contributing in Squeak > is so much easier for me. > > > > I like the social power provided by github and i know how to use git, at > least as an expert beginner. > > But it took me two hours to pick a pharo image, fork and clone the pharo > repository, pick a pharo VM (I ended up building my own), > > retrieve my ssh pass phrase to avoid using github thru https, > > search documentation of where should I put the image wrt to my cloned > git repository, > > search how to use iceberg, > > and finally realized that the author/date would not even be preserved if > we want to port this cross dialect library. > > You are absolutely right, but it is improving and will get better. > > Nope, i don't buy the argument... The information has simply been erased and won't reappear by operation of wishfull thinking Even if we later add the blame API, the information of original authors is definitely lost. That was already the case at each Pharo release, the mc ancestry was reset and it was very difficult to trace back. 7.0 is in continuity, just with a more radical eradication. For Pharo, such compatibility is a drag, for me it's usefull, it's just that we have different trade offs It's not for complaining, but trade offs are to be made explicit and assumed. > The dark theme upsets me, especially the green on blue, I could have > searched how to change it, but there I stopped. > > Then switch to the light/white theme, just one setting. > > > While doing all these things, I did not spent a minute focusing on the > SortFunction subject. > > I can see that as an investment, maybe I should have done it before, but > it was too much for a Sunday evening. > > I think what Denis means is, it would have been helpful to apply the > change in Pharo. How you communicate that is less relevant, just saving the > MC version and mailing it would already have been very helpful. > > IMHO. > Right, I can understand that cross dialect is becoming inconvenient... That's why I gave the .diff URL just for giving a chance to glimpse at refactoring POC. Pharo still has Monticello, so it could have worked (not sure how well without common ancestor) The extra difficulty here is that package delimitation does not match, SortFunction has been integrated into Collection in Squeak. Is extracting sources From .mcz and filtering in change list still possible? (Epicea?) I will try and import in Pharo. But it was not humanely possible yesterday night. > > 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > It is difficult to compare to current Pharo version. > > Why you not produce Pharo pull request? > > > > 2017-11-06 0:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > > I've put some of the proposed composition features into > > > > http://source.squeak.org/inbox/Collections-nice.766.mcz > > http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz > > > > http://source.squeak.org/inbox/Collections-nice.766.diff > > http://source.squeak.org/inbox/CollectionsTests-nice.283.diff > > > > SInce it's Squeak based, it uses <=>, but never mind, that's the same > functions. > > > > > > Stephane: the original comments were from Travis Griggs. > > It's more a tutorial for using the SortFunction than a detailed > explanation of implementation. > > > > The original idea is that oSortFunction are composable. > > For example, it's possible to chain sorting on a first criterion, then > resort on a second criterion if objects have same rank with first. > > > > For this, we need a to distinguish when objects have same rank (=) and > cannot use a binary result (Boolean) like legacy sortBlock, > > So we rather need a ternary comparison (<=>). > > > > This thread is about extending composition, and generalizing > implementation by composition (like Xtreams) > > - for sorting nil first (or last) > > - for reversing the order > > - for sorting properties with any collation order, and not just default > <=> > > > > 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi guys > > > > Do you have some nice comments somewhere? because I do not understand > > anything about this thread. > > I check the code and the comments are well... unclear and confusing. > > > > Stef > > > > On Sun, Nov 5, 2017 at 4:15 PM, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > > > > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > >> > > >> > > >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier > > >> <nicolas.cellier.aka.nice(a)gmail.com>: > > >>> > > >>> > > >>> Ah, I messed up, UndefinedSorter must not be chained, it must be a > > >>> wrapper! > > >>> Otherwise comparing to nil will resort to sorting by properties and > > >>> fail... > > >>> > > >>> SortFunction>>undefinedFirst > > >>> ^UndefinedSorter descending wrap: self > > >>> > > >>> UndefinedSorter>> collate: value1 with: value2 > > >>> "sort all nil according to the direction (first if -1, last if > > >>> +1), then" > > >>> value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. > > >>> value2 ifNil: [^direction negated]. > > >>> ^sorterForNonNil collate: value1 with: value2 > > >>> > > >>> It's important to have the UndefinedSorter : > > >>> - decoupled from property sort, because it can be generally > usefull > > >>> - collating 2 nil as 0, so that another property can be chained > > >> > > >> > > >> I like your idea. > > >> It also forced me to think that direction itself should be > implemented as > > >> wrapper. I would name it InvertedSortFunction: > > >> > > >> InvertedSortFunction>>collate: value1 with: value2 > > >> ^(actualSortFunction collate: value1 with: value2) * -1 > > >> > > >> > > >> If we will do it then direction will be not part of SortFunction. And > all > > >> current functions will be in fact ascending. > > >> And to explicitly reflect this fact I would introduce > > >> AscendingSortFunction as their superclass. > > >> InvertedSortFunction and ChainedSortFunction will stay subclasses of > > >> SortFunction. > > >> > > >> So what you think? > > > > > > > > > Yes, I was thinking the same. > > > On another hand, direction makes thing symmetric and has its elegance > too. > > > What I don't like with it is that it forces the library to have two > > > different messages for the same thing: > > > - collate:with: in base class accounting for direction > > > - threeWayCompare:with: in every subclass > > > > > > The fact to hardcode the direction in base class could be seen as an > > > optimization too. > > > I'm not sure what Sista optimization could bring in this case, because > the > > > selectors may get megamorphic... > > > > > > > > >> > > >>> > > >>> > > >>> In > > >>> > > >>> people sortBy: #name ascending undefinedFirst , #age descending > > >>> > > >>> we could then have people with name nil still sorted by age, what is > not > > >>> possible with current implementation > > >>> > > >> > > > > > > > > > > > > > >

Nov. 6, 2017

Re: [Pharo-dev] Iceberg Clone Location

by Gabriel Cotelli

Maybe create a symlink by now? On Mon, Nov 6, 2017 at 7:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 5 Nov 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > I have a problem I'm not sure how to solve. In many of my baselines for > > personal private projects, I have dependencies with filetree URL > > repositories. IIUC, that was the best practice when I asked on the MetaC > > mailing list. The file URLS are all of the form > > {sharedRepoFolder}/{projectName}. Now Iceberg seems to expect clones to > be > > in {sharedRepoFolder}/{gitHubUser}/{projectName}. It doesn't find them > > there, and then clones everything anew. I have a few concerns about this, > > not the least of which is the thought of having to redo all my baselines. > > That said, I realize that maybe this is inevitable, so I wanted to put > this > > out there to see if I'm missing something and the best way to proceed. > > I do not have a real solution for this. > So far the url needs to have a kind of format and there is no way to > change it. Yes we can make the search of projects a bit more intelligent > but right now it is not there. > > The *trick* you can use (and Iâm not sure is a trick at all or even > something good, but at least it works ;) ) is that iceberg does not clones > a project that is already in the image. So if you installed project > dependency {projectName}, it will find it on his list and it will use it. > > This has collateral not desired outputs (like if you ask for a tag or > branch and it founds the project already there, it does not moves it to the > place you asked for)â¦ I will fix that eventually :) > > Now, this forces you to install previously the dependences which can be > not desired either :( > > Esteban > > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > >

Nov. 6, 2017

[Pharo 7.0-dev] Build #262: 20520 Package "OpalTools" should be "OpalCompiler-Tools"

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #262 was: SUCCESS. The Pull Request #436 was integrated: "20520 Package "OpalTools" should be "OpalCompiler-Tools"" Pull request url: https://github.com/pharo-project/pharo/pull/436 Issue Url: https://pharo.fogbugz.com/f/cases/20520 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 6, 2017

[Pharo 7.0-dev] Build #261: Stupid use of asLayoutFrame should be eliminated first pass.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #261 was: SUCCESS. The Pull Request #434 was integrated: "Stupid use of asLayoutFrame should be eliminated first pass." Pull request url: https://github.com/pharo-project/pharo/pull/434 Issue Url: https://pharo.fogbugz.com/f/cases/20639 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 6, 2017

[Pharo 7.0-dev] Build #260: 20640 Categorize uncategorized methods in classes starting with "P"

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #260 was: SUCCESS. The Pull Request #433 was integrated: "20640 Categorize uncategorized methods in classes starting with "P"" Pull request url: https://github.com/pharo-project/pharo/pull/433 Issue Url: https://pharo.fogbugz.com/f/cases/20640 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 6, 2017