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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50131 Home: https://github.com/pharo-project/pharo-core

June 24, 2015

[pharo-project/pharo-core] 6036cd: 50131

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6036cd9c3c1f4657627bf4ad92e94e2d00674010 https://github.com/pharo-project/pharo-core/commit/6036cd9c3c1f4657627bf4ad… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-24 (Wed, 24 Jun 2015) Changed paths: M NECompletion.package/NECController.class/instance/private/setEditor_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/display/requestImplementorToInline_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50130.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50131.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50130.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50131.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Sources.package/SourceFileArray.class/instance/accessing/fileAt_.st A System-Sources.package/SourceFileArray.class/instance/accessing/fileAt_ifAbsent_.st M System-Sources.package/SourceFileArray.class/instance/source code management/changeRecordsFrom_className_isMeta_do_.st M System-Sources.package/SourceFileArray.class/instance/source code management/localProcessReadStreamAtFileIndex_atPosition_ifPresent_ifAbsent_.st M System-Sources.package/SourceFileArray.class/instance/source code management/readStreamAtFileIndex_atPosition_ifPresent_ifAbsent_.st R System-Sources.package/SourceFileArray.class/instance/to remove/at_.st R System-Sources.package/SourceFileArray.class/instance/to remove/at_ifAbsent_.st R System-Sources.package/SourceFileArray.class/instance/to remove/at_put_.st R System-Sources.package/SourceFileArray.class/instance/to remove/do_.st R System-Sources.package/SourceFileArray.class/instance/to remove/size.st Log Message: ----------- 50131 12728 requestImplementorToInline: is missing in NautilusRefactoring https://pharo.fogbugz.com/f/cases/12728 15828 NECController must check that its editor morph is not nil before unsubscribing from it https://pharo.fogbugz.com/f/cases/15828 15826 Clean up discouraged uses of SourceFiles and friends (10) https://pharo.fogbugz.com/f/cases/15826 http://files.pharo.org/image/50/50131.zip

June 24, 2015

Re: [Pharo-dev] Pharo versioning

by Daniel Milde

Thanks, that is exactly what I needed. I will combine the package from VM and image archives. Thanks Daniel Dne 23.6.2015 v 12:59 Peter UhnÃ¡k napsal(a): > Well as far as image goes, you can download whatever version you want > here http://files.pharo.org/image/40/ > So each "release" does have a different version number, only it is not > usually advertised. > > If you are interested in the reason of the change, usually searching the > version in issue tracker will give an issue > https://pharo.fogbugz.com/f/cases/15797/Backport-4-0-New-PackageManifests-s… > > Peter > > On Tue, Jun 23, 2015 at 12:26 PM, Daniel Milde <daniel(a)milde.cz > <mailto:daniel@milde.cz>> wrote: > > Hi everybody, > I am a maintainer of Pharo package in Arch Linux distribution and would > like to ask you if there is some way how to get Pharo release in some > specific (non-changing) version. > > I am now using link to official stable release [1], but the archive is > changing quite often without giving any notice (version number change), > which breaks the package building due to hash sums changes. > > Thanks > > Best regards > Daniel > > [1] http://files.pharo.org/platform/Pharo4.0-linux.zip > >

June 24, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50130 Home: https://github.com/pharo-project/pharo-core

June 23, 2015

[pharo-project/pharo-core] 8c7aca: 50130

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8c7aca8e6b816e717b07c12fa85ea311be9a725c https://github.com/pharo-project/pharo-core/commit/8c7aca8e6b816e717b07c12f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-23 (Tue, 23 Jun 2015) Changed paths: M FuelTests.package/FLBasicSerializationTest.class/instance/tests-strings/testRemoteString.st M Kernel.package/ClassOrganization.class/instance/accessing/comment_.st A OpalCompiler-Core.package/OCASTTranslator.class/instance/initialization/classForEffect.st A OpalCompiler-Core.package/OCASTTranslator.class/instance/initialization/classForValue.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/initialization/initialize.st R OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitCleanBlockNode_.st A Reflectivity.package/RFASTTranslator.class/README.md A Reflectivity.package/RFASTTranslator.class/definition.st A Reflectivity.package/RFASTTranslator.class/instance/initialization/classForEffect.st A Reflectivity.package/RFASTTranslator.class/instance/initialization/classForValue.st A Reflectivity.package/RFASTTranslatorForEffect.class/README.md A Reflectivity.package/RFASTTranslatorForEffect.class/definition.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/inline messages/emitAnd_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/inline messages/emitIfFalse_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/inline messages/emitIfNotNil_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/inline messages/emitIfTrue_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/inline messages/emitOr_.st A Reflectivity.package/RFASTTranslatorForValue.class/README.md A Reflectivity.package/RFASTTranslatorForValue.class/definition.st A Reflectivity.package/RFASTTranslatorForValue.class/instance/inline messages/emitIfFalse_.st A Reflectivity.package/RFASTTranslatorForValue.class/instance/inline messages/emitIfNotNil_.st A Reflectivity.package/RFASTTranslatorForValue.class/instance/inline messages/emitIfTrue_.st A Reflectivity.package/RFASTTranslatorForValue.class/instance/inline messages/emitWhileFalse_.st A Reflectivity.package/RFASTTranslatorForValue.class/instance/inline messages/emitWhileTrue_.st A Reflectivity.package/RFASTTranslatorForValue.class/instance/visitor-double dispatching/visitSequenceNode_.st A Reflectivity.package/extension/RBProgramNode/instance/hasMetalinkAfter.st A Reflectivity.package/extension/RBProgramNode/instance/hasMetalinkBefore.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50129.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50130.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50129.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50130.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Sources.package/PharoChangesCondenser.class/instance/private - 1 writing/writeRemoteString_for_.st A System-Sources.package/RemoteString.class/instance/testing/isRemoteString.st A System-Sources.package/SourceFileArray.class/instance/source code management/remoteStringAt_.st A System-Sources.package/SourceFileArray.class/instance/writing/remoteStringForNewString_.st A System-Sources.package/extension/Object/instance/isRemoteString.st M Tests.package/SourceFileArrayTest.class/instance/running/ensureChangesFileOpenedInProcess.st M Tests.package/SourceFileArrayTest.class/instance/testing/testForkedRead.st M Tests.package/SourceFileArrayTest.class/instance/testing/testForkedWrite.st M Traits.package/TClassDescription.class/instance/filein%2Fout/classComment_stamp_.st Log Message: ----------- 50130 15825 Move Reflectivity changes from Opal into a Opal translator subclass (part1) https://pharo.fogbugz.com/f/cases/15825 15824 Clean up discouraged uses of SourceFiles and friends (9) https://pharo.fogbugz.com/f/cases/15824 http://files.pharo.org/image/50/50130.zip

June 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: Searching for a Roassal2 version

by Yuriy Tymchuk

IMHO projectâs version should be orthogonal to pharo versions as much as possible. Uko > On 23 Jun 2015, at 15:49, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 23-06-15 15:13, Esteban Lorenzano wrote: > >> depending on #stable is #wrong! > > The one situation where depending on #stable is ok is > where we talk about a Pharo 4 version where > new development is only on Pharo 5. Stable is then > only a moving target on Pharo 5, not on 4. > > Stephan > > >

June 23, 2015

Job Offer | 1 year Post-Doc/Research & Teaching Assistant

by Noury Bouraqadi

Hi, We have a 12 months position for a post-doc/Research & teaching assistant at Ecole des Mines de Douai (France). Applicants should have a PhD degree. You can find out more about our activity (Pharo + Robotics) at: http://car.mines-douai.fr Best, Noury â Prof. Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury

June 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: Searching for a Roassal2 version

by Stephan Eggermont

On 23-06-15 15:13, Esteban Lorenzano wrote: > depending on #stable is #wrong! The one situation where depending on #stable is ok is where we talk about a Pharo 4 version where new development is only on Pharo 5. Stable is then only a moving target on Pharo 5, not on 4. Stephan

June 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: Re: Searching for a Roassal2 version

by Yuriy Tymchuk

Maybe itâs not a good approach, but I really enjoy Bundler specs, http://bundler.io/gemfile.html <http://bundler.io/gemfile.html>. They have this notation ~> which allows you to specify, that you want to auto advance parches or minor versions, but not minor or major versions respectively. If X.X. works like this, I really like that. Also if thingâs work like that we donât need this release symbolics, because 3.1. should work as #release3.1, right? Also is anybody using semantic versioning. Because if you subclass ConfigurationOf, you are forced to use it, and thatâs very nice. Uko > On 23 Jun 2015, at 15:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 23 Jun 2015, at 15:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> I donât get this. I do a project and I have version 4.3. Then I make a major changes i.e. change API without backwards compatibility and create version 5.0. Now 5.0 is stable, but if someone depends on my packageâs stable version, he has to rewrite his code, otherwise his package is insta-broken. > > this is why I do not recommend the use of #stable in dependency declarations (I already discussed this in pharo-dev). > according to Dale, the better way to handle this would be: > > - you can use, for example 3.? as dependency, then it will take latest 3 (I never tried this and Iâm not sure if it actually works) > - you are highly recommended to adopt Seaside convention: they have symbolic versions for #release3, #release3.1, etc. probably a bit more of work, but it works fine. > - and of course, you can use a fixed version number (for example: 3.1.1) > > depending on #stable is #wrong! > > Esteban > > >> >> I think this has to be also discussed with Pharo developers, who missed the main conversation, here it is: http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html <http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html> >> >> In short: we are arguing on depending on numbered versions vs symbolic. >> >> Uko >> >>> On 23 Jun 2015, at 14:40, stephan <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >>> >>> >>> >>> On 23-06-15 14:27, Yuriy Tymchuk wrote: >>>> Thatâs the point, Iâm fine using Pharo 4 in 2 years as long as the projects works. Because 1) I can use it for my reasons 2) I can migrate it if I need to. But if everyone depends on symbolic, in 2 years I open a project, it doesnât work because too much changed, I have no idea what changed, I throw it to trash. Uko >>> >>> If everyone would correctly use symbolic, the only thing you'd need >>> to do is change your own packages to make it work in the latest version of Pharo 4. >>> That is what we have with Seaside and it works. To make it work with your code, >>> Roassal, Glamour and GT need to switch to symbolic versions too. >>> >>> Stephan >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>

June 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: Searching for a Roassal2 version

by Esteban Lorenzano

> On 23 Jun 2015, at 15:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I donât get this. I do a project and I have version 4.3. Then I make a major changes i.e. change API without backwards compatibility and create version 5.0. Now 5.0 is stable, but if someone depends on my packageâs stable version, he has to rewrite his code, otherwise his package is insta-broken. this is why I do not recommend the use of #stable in dependency declarations (I already discussed this in pharo-dev). according to Dale, the better way to handle this would be: - you can use, for example 3.? as dependency, then it will take latest 3 (I never tried this and Iâm not sure if it actually works) - you are highly recommended to adopt Seaside convention: they have symbolic versions for #release3, #release3.1, etc. probably a bit more of work, but it works fine. - and of course, you can use a fixed version number (for example: 3.1.1) depending on #stable is #wrong! Esteban > > I think this has to be also discussed with Pharo developers, who missed the main conversation, here it is: http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html <http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html> > > In short: we are arguing on depending on numbered versions vs symbolic. > > Uko > >> On 23 Jun 2015, at 14:40, stephan <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >> >> >> >> On 23-06-15 14:27, Yuriy Tymchuk wrote: >>> Thatâs the point, Iâm fine using Pharo 4 in 2 years as long as the projects works. Because 1) I can use it for my reasons 2) I can migrate it if I need to. But if everyone depends on symbolic, in 2 years I open a project, it doesnât work because too much changed, I have no idea what changed, I throw it to trash. Uko >> >> If everyone would correctly use symbolic, the only thing you'd need >> to do is change your own packages to make it work in the latest version of Pharo 4. >> That is what we have with Seaside and it works. To make it work with your code, >> Roassal, Glamour and GT need to switch to symbolic versions too. >> >> Stephan >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

June 23, 2015