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

Ideas wanted: "Patterns to sustain feedback loops"
by Marcus Denker July 8, 2017

July 8, 2017

Hi, I want to do a third talk at ESUG as the âpart 3â of the feedback loop series.. The first parts where: 1. Nomads do not build Cathedrals: https://www.slideshare.net/MarcusDenker/2014-esugcathedral 2. Perfection and Feedback Loops: Why worse is better. https://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-wo… The idea for part 3 is to do something along the lines of âpatterns to enable feedback loopsâ, a more practical view on what one should be doing (or not be doing) to enable and sustain a project as a feedback loop. - both things we do and those we should - things that we do wrong / anti patterns - technical as well as social (communityâ¦) - examples you have seen in the real world The idea is not to follow a formal patterns language, it will be informalâ¦ so if you have any ideas, please send a private mail to me. Marcus

3 4

Debugging the VM under gdb on cygwin
by Eliot Miranda July 7, 2017

July 7, 2017

Hi All, I'm finding it very difficult to debug the 32-bit VM on 64-bit Windows using cygwin. The default gdb for 64-bit cygwin simply doesn't work properly, finding set facts in programs that work out side of the debugger. I've tried to build a 32-bit gdb from the 7.11 sources, configuring with ./configure --target=i686-w64-mingw32, but the resulting gdb doesn't find the 32-bit dlls in C:\Windows\SysWOW64', and complains "Don't know how to run.". Does anyone else have a working gdb for 32-bit programs on 64-bit Windows? How did you build it? Does anyone else have a working gdb for 32-bit programs on 32-bit Windows? How did you build it? Do I need to create a 32-bit cygwin installation on 32-bit windows for this to work? Does anyone have the cygwin gdb 7.8 sources or a pointer to them? One poster claimed that 32-bit gdb on cygwin only works if compiled from the 7.8 sources. Any other ideas? AdvThanksance _,,,^..^,,,_ best, Eliot

1 0

[ANN] Iceberg 0.5.1 with Pull Request review tool
by Esteban Lorenzano July 7, 2017

July 7, 2017

Hi, I just released Iceberg version 0.5.1 with a Pull Request tool Guille and I worked on since yesterday. It allows you to list open Pull Requests (by right click on a repo, GitHub/Review pull requestsâ¦ option): And then if you doubleclick on one (or select it with right button), you will see this: it allows you to see changes and - merge changes into your image (in case you want to see more in details the code, run tests, etc.) - accept a pull request - reject a pull request no, it does not shows (at least *yet*) comments, and it does not allows you to add comments, reviews, etc. this could be done, but not time to implement it now, so for now this has to be enough. Again, this can be loaded in a 6.0 image by executing this script: #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGit') do: [ :each | each asPackage removeFromSystem ]. Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:v0.5.1'; load. (and you still need to have the vm that is meant for Pharo7) This tools are open for you to use on your projectsâ¦ and to improve them, I accept pull requests on pharo-vcs/iceberg. cheers! Esteban

5 8

Epicea and #name in #behaviorAffectedName
by Torsten Bergmann July 6, 2017

July 6, 2017

Hi, in latest Pharo 6 image 60494 I run into some trouble today where the deprecation warning dialog popped up and repeated itself unstoppable due to Epicea. It is hard to reproduce but what I found out was that I had a class modification (represented by EpClassModification) which run into a state where "newClass" was nil and therefore in EpClassModification>>#behaviorAffectedName the message #name was sent to nil. So #name was found in Object and as we all know we deprecated it now which lead to the deprecation dialog, leading to the deprecation dialog, leading to the deprecation dialog, ... Nearly all implementors of Epiceas #behaviorAffectedName send #name which is ok if there is a valid object it is sent to. I do not know if we should protect them somehow in case something goes wrong (like having nil in newClass) or if we should keep this untouched. At least I wanted to inform because I do not know if this later gets others into trouble too and losing their changes because Epicea does not record. Thanks T.

2 1

[pharo-project/pharo-core]
by GitHub July 6, 2017

July 6, 2017

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

1 0

[pharo-project/pharo-core] 9b87bb: 60507
by GitHub July 6, 2017

July 6, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9b87bb71fd929f5f2af417887b3598f79784ae60 https://github.com/pharo-project/pharo-core/commit/9b87bb71fd929f5f2af41788… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-07-06 (Thu, 06 Jul 2017) Changed paths: M Jobs.package/Job.class/class/examples/exampleCurrentValue.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/script60506.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60507.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60506.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60507.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Core.package/Text.class/class/initialization/initialize.st M Traits.package/TBehaviorCategorization.class/instance/organization/category.st M UnifiedFFI.package/FFISizeT.class/class/converting/asExternalTypeOn_.st Log Message: ----------- 60507 20218 Master branch (Pharo 6) needs to be safely merged into development branch (Pharo 7). https://pharo.fogbugz.com/f/cases/20218 http://files.pharo.org/image/60/60507.zip

1 0

OSPlatform currentVersion
by Norbert Hartl July 6, 2017

July 6, 2017

Does anyone know when the output for OSPlatform currentVersion changed? In Pharo 4 I get '1095' and in pharo6 I get '10.12.5'. The determination if it is a OSX system or older is done by currentVersion asNumber >= 1000 which changes behaviour because the currentVersion string has been changed. Is the output the one supposed to be? Norbert

2 3

Simply Happy
by Stephane Ducasse July 6, 2017

July 6, 2017

Hi pharoing people Just a little word to tell you that I'm super happy about the future of Pharo. The consortium is growing and will probably be able to pay esteban and clement. The roadmap for Pharo 70 is really exciting. The bootstrap, git and the new project in the pipe will boost us. So I wanted to thanks you all for all this super great energy. We (you and us) are building a super cool future. Stef

7 6

tar sec files for windows Pharo VM build
by Eliot Miranda July 6, 2017

July 6, 2017

Hi All, if I'm reading the build.winMNxOP/third-party/Makefile.libXXX files correctly there should be a libXXX.spec.win file for each library in build.winMNxOP/third-party. There are no such files in the Cog or master branches. Can anybody point me to these files? _,,,^..^,,,_ best, Eliot

1 1

Recommended production VM on latest macOS Sierra?
by Bernhard Pieber July 5, 2017

July 5, 2017

Hi, What VM would you recommend for a production app on macOS Sierra? - Pharo 6, right? - I assume 32-bit because 64-bit is still experimental, right? - The one I get with âcurl get.pharo.org | bashâ has a reproducible crash when typing (https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141) So it canât be the recommended one, right? I must admit I am quite confused. Cheers, Bernhard

4 5