- Pharo-dev - lists.pharo.org

Big Pharo 6 Image (32 bit) crashes while garbage collecting
by Cyrille Delaunay June 14, 2017

June 14, 2017

Hello, I am running a Pharo 6 32 bit image (Pharo 6.0 Latest update: #60499). I saved this image after loading big data in memory (image is 995 MB). After saving, the image became "unstable", and always crashed after doing some random actions. I tries to open the image and perform: Smalltalk garbageCollect. The image systematically crashes. I Join the dump files I have been able to collect. -- Cyrille Delaunay

3 4

I want to get in contact with raphael luque from madrid :)
by Stephane Ducasse June 14, 2017

June 14, 2017

Hi guys. I tried to get in contact with raphael but my emails do not seem to go to destination. Do you have the email of raph/fael luque from madrid? Stef

2 1

Pharo6 deployment issues
by Holger Freyther June 14, 2017

June 14, 2017

Hi! today I started to look at of why my benchmark in the CI stalled/didn't complete and I see three separate issues and wonder how to address them properly? I have a truncated log attached Issues: * In my CI script I disable Deprecation warnings but this has no influence on Deprecation>>#transform. This means that it will try to write the changes?! To scale we start the same image multiple times. * Somehow writing the log fails (and the TCP connection fails the same time?!) with a primitive error. * Errors "recurse". So while we try to exit the image it seems to fail the same way and tries again.. which fails again.. which fails again..at some point no new context will be allocated. Solutions? * Prevent new errors in NonInteractiveUIManager>>#unhandledErrorDefaultAction:? * Check in >>#transform if transformation is disabled and then return early? * ??? No idea.. I will strace to see what happens to the Debug log.. but ideally I would like this file writing to be disabled. :) Should I create tickets? holger dispatch failed on "[ self doExpire. statsdClient flush ]". an OrderedCollection(MultiByteFileStream(Object)>>primitiveFailed: MultiByteFileStream(Object)>>primitiveFailed MultiByteFileStream(StandardFileStream)>>primFlush: MultiByteFileStream(StandardFileStream)>>flush MultiByteFileStream(WriteStream)>>nextChunkPut: SourceFileArray>>writeSource:preamble:onSuccess:onFail: CompiledMethod>>putSource:withPreamble: CompiledMethod>>putSource:class:category:withStamp:priorMethod: VODescriptionBuilder class(ClassDescription)>>logMethodSource:forMethod:inCategory:withStamp: VODescriptionBuilder class(ClassDescription)>>compile:classified:withStamp:notifying:logSource: VODescriptionBuilder class(ClassDescription)>>compile:classified:withStamp:notifying: VODescriptionBuilder class(ClassDescription)>>compile:classified:notifying: VODescriptionBuilder class(ClassDescription)>>compile:classified: [ aMethod origin compile: aMethod ast formattedCode classified: aMethod protocol ] in Deprecation>>transform BlockClosure>>ensure: Author>>useAuthor:during: Author class>>useAuthor:during: Deprecation>>transform Pragma(Object)>>deprecated:transformWith: Pragma>>selector) <snip log about lost TCP connection> PrimitiveFailed: primitive #primClose: in MultiByteFileStream failed MultiByteFileStream(Object)>>primitiveFailed: MultiByteFileStream(Object)>>primitiveFailed MultiByteFileStream(StandardFileStream)>>primClose: MultiByteFileStream(StandardFileStream)>>close SmalltalkImage>>closeLog: [ self closeLog: logStream ] in SmalltalkImage>>logDuring: in Block: [ self closeLog: logStream ] BlockClosure>>ensure: SmalltalkImage>>logDuring: NonInteractiveUIManager(CommandLineUIManager)>>inform: STCommandLineHandler(Object)>>inform: STCommandLineHandler>>handleError:reference: [ :e | self handleError: e reference: aReference ] in STCommandLineHandler>>handleErrorsDuring:reference: in Block: [ :e | self handleError: e reference: aReference ]...etc... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: PrimitiveFailed(Exception)>>signal PrimitiveFailed class(SelectorException class)>>signalFor: MultiByteFileStream(Object)>>primitiveFailed: MultiByteFileStream(Object)>>primitiveFailed MultiByteFileStream(StandardFileStream)>>primClose: MultiByteFileStream(StandardFileStream)>>close SmalltalkImage>>closeLog: FileWriteError: File /build/build/PharoDebug.log write failed MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: MultiByteFileStream(StandardFileStream)>>nextPut: MultiByteFileStream>>basicNextPut: UTF8TextConverter>>nextPut:toStream: [ :char | self nextPut: char toStream: aStream ] in UTF8TextConverter(TextConverter)>>nextPutAll:toStream: in Block: [ :char | self nextPut: char toStream: aStream ] ByteSymbol(SequenceableCollection)>>do: UTF8TextConverter(TextConverter)>>nextPutAll:toStream: MultiByteFileStream>>nextPutAll: Context>>printOn: MultiByteFileStream(Stream)>>print: Context>>errorReportOn: [ :logger | logger nextPutAll: 'THERE_BE_DRAGONS_HERE'; cr; nextPutAll: errMsg; cr. "just print the error message if no context is given" aContext ifNotNil: [ aContext errorReportOn: logger ]. " write some type of separator" logger nextPutAll: (String new: 79 withAll: $-); cr; cr ] in SmalltalkImage>>logError:inContext: in Block: [ :logger | ... [ logStream := self openLog. aMonadicBlock value: logStream ] in SmalltalkImage>>logDuring: in Block: [ logStream := self openLog.... BlockClosure>>ensure: SmalltalkImage>>logDuring: SmalltalkImage>>logError:inContext: [ Smalltalk logError: aString inContext: aContext. " Print stacks of all current processes " Smalltalk logDuring: [ :logger | logger nextPutAll: 'Processes and their stacks: '; cr. Process allInstances do: [ :each | | ctx | logger nextPutAll: 'Process: '; print: each; cr; nextPutAll: ' stack:'; cr; cr. ctx := each isActiveProcess ifTrue: [ thisContext sender ] ifFalse: [ each suspendedContext ]. ctx ifNotNil: [ (ctx stackOfSize: 20) do: [ :s | logger print: s; cr ] ]. logger nextPutAll: '------------------------------'; cr; cr ] ] ] in NonInteractiveUIManager(CommandLineUIManager)>>quitFrom:withMessage: in Block: [ Smalltalk logError: aString inContext: aContext....etc... BlockClosure>>ensure: NonInteractiveUIManager(CommandLineUIManager)>>quitFrom:withMessage: NonInteractiveUIManager(CommandLineUIManager)>>unhandledErrorDefaultAction: UnhandledError>>defaultAction UndefinedObject>>handleSignal: UnhandledError(Exception)>>signal UnhandledError class>>signalForException: PrimitiveFailed(Error)>>defaultAction UndefinedObject>>handleSignal: PrimitiveFailed(Exception)>>pass [ :ex | ActiveWorld := priorWorld. ActiveEvent := priorEvent. ActiveHand := priorHand. ex pass ] in WorldMorph(PasteUpMorph)>>becomeActiveDuring: in Block: [ :ex | ... BlockClosure>>cull: Context>>evaluateSignal: FileWriteError: File /build/build/PharoDebug.log write failed MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: MultiByteFileStream(StandardFileStream)>>next:putAll:startingAt: MultiByteFileStream>>basicNext:putAll:startingAt: UTF8TextConverter(TextConverter)>>next:putByteString:startingAt:toStream: UTF8TextConverter(TextConverter)>>next:putAll:startingAt:toStream: MultiByteFileStream>>next:putAll:startingAt: UTF8TextConverter(TextConverter)>>nextPutByteString:toStream: UTF8TextConverter(TextConverter)>>nextPutAll:toStream: MultiByteFileStream>>nextPutAll: Context>>printDetails: Context>>errorReportOn: [ :logger | logger nextPutAll: 'THERE_BE_DRAGONS_HERE'; cr; nextPutAll: errMsg; cr. "just print the error message if no context is given" aContext ifNotNil: [ aContext errorReportOn: logger ]. " write some type of separator" logger nextPutAll: (String new: 79 withAll: $-); cr; cr ] in SmalltalkImage>>logError:inContext: in Block: [ :logger | ... [ logStream := self openLog. aMonadicBlock value: logStream ] in SmalltalkImage>>logDuring: in Block: [ logStream := self openLog.... BlockClosure>>ensure: SmalltalkImage>>logDuring: SmalltalkImage>>logError:inContext: [ Smalltalk logError: aString inContext: aContext. " Print stacks of all current processes " Smalltalk logDuring: [ :logger | logger nextPutAll: 'Processes and their stacks: '; cr. Process allInstances do: [ :each | | ctx | logger nextPutAll: 'Process: '; print: each; cr; nextPutAll: ' stack:'; cr; cr. ctx := each isActiveProcess ifTrue: [ thisContext sender ] ifFalse: [ each suspendedContext ]. ctx ifNotNil: [ (ctx stackOfSize: 20) do: [ :s | logger print: s; cr ] ]. logger nextPutAll: '------------------------------'; cr; cr ] ] ] in NonInteractiveUIManager(CommandLineUIManager)>>quitFrom:withMessage: in Block: [ Smalltalk logError: aString inContext: aContext....etc... BlockClosure>>ensure: NonInteractiveUIManager(CommandLineUIManager)>>quitFrom:withMessage: NonInteractiveUIManager(CommandLineUIManager)>>unhandledErrorDefaultAction: UnhandledError>>defaultAction UndefinedObject>>handleSignal: UnhandledError(Exception)>>signal UnhandledError class>>signalForException: FileWriteError(Error)>>defaultAction UndefinedObject>>handleSignal: FileWriteError(Exception)>>signal FileWriteError(Exception)>>signal: MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: MultiByteFileStream(StandardFileStream)>>nextPut: FileWriteError: File /build/build/PharoDebug.log write failed MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: MultiByteFileStream(StandardFileStream)>>next:putAll:startingAt: MultiByteFileStream>>basicNext:putAll:startingAt: UTF8TextConverter(TextConverter)>>next:putByteString:startingAt:toStream: UTF8TextConverter(TextConverter)>>next:putAll:startingAt:toStream: MultiByteFileStream>>next:putAll:startingAt: UTF8TextConverter(TextConverter)>>nextPutByteString:toStream: UTF8TextConverter(TextConverter)>>nextPutAll:toStream: MultiByteFileStream>>nextPutAll: Context>>printOn: MultiByteFileStream(Stream)>>print: Context>>errorReportOn:

3 4

[pharo-project/pharo-core] 89d297: 60501
by GitHub June 14, 2017

June 14, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 89d297dce3beea42497ef1b7aea3d7460bc75a4b https://github.com/pharo-project/pharo-core/commit/89d297dce3beea42497ef1b7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-14 (Wed, 14 Jun 2017) Changed paths: M Kernel.package/Deprecation.class/class/class initialization/initialize.st M Kernel.package/Deprecation.class/class/logging/deprecationsWhile_.st M Kernel.package/Deprecation.class/class/settings/raiseWarning.st M Kernel.package/Deprecation.class/class/settings/showWarning.st M Kernel.package/Deprecation.class/instance/handling/transform.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60500.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60501.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60500.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60501.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/VersionBrowser.class/instance/accessing/displayStringsFor_.st Log Message: ----------- 60501 20093 Missing source stamp makes changes hard to view https://pharo.fogbugz.com/f/cases/20093 20148 transforming deprecations should take #showWarning into account https://pharo.fogbugz.com/f/cases/20148 http://files.pharo.org/image/60/60501.zip

1 0

[pharo-project/pharo-core]
by GitHub June 14, 2017

June 14, 2017

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

1 0

Re: [Pharo-dev] [Vm-dev] BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)
by Eliot Miranda June 14, 2017

June 14, 2017

Hi Esteban, Hi Igor, Hi All, On Fri, Mar 10, 2017 at 7:35 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Iâm tumbling into an error in Pharo, because we use callbacks intensively, > in Athens(cairo)-to-World conversion in particular, and people is sending > always their crash reportsâ¦ we made the whole conversion a lot more robust > since problems started to arise, but now I hit a wall I cannot solve: I > think problem is in something in callbacks. > > And problem is showing very easy on 64bits (while in 32bits it takes time > and is more random). > I responded in the "image not opening" thread, but it's the same problem. I really want to hear what y'all think because I'll happily implement a fix, but I want to know which one y'all think is a good idea. Here's my reply (edits between [ & ] to add information): On Mon, Mar 13, 2017 at 9:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: I'm pretty confident [I know] this is to do with bugs in the Athens surface code which assumes that callbacks can be made in the existing copyBits and warpBits primitive. They can't do this safely because a GC (scavenge) can happen during a callback, which then causes chaos when the copyBits primitive tries to access objects that have been moved under its feet. I've done work to fix callbacks so that when there is a failure it is the copyBits primitive that fails, instead of apparently the callback return primitive. One of the apparent effects of this fix is to stop the screen opening up too small; another is getting the background colour right, and yet another is eliminating bogus pixels in the VGTigerDemo demo. But more work is required to fix the copyBits and warpBits primitives. There are a few approaches one might take: a) fixing the primitive so that it saves and restores oops around the callbacks using the external oop table [InterpreterProxy>>addGCRoot: & removeGCRoot:]. That's a pain but possible. [It's a pain because all the derived pointers (the start of the destForm, sourceForm, halftoneForm and colorMapTable) must be recomputed also, and of course most of the time the objects don't move; we only scavenge about once every 2 seconds in normal running] b) fixing the primitive so that it pins the objects it needs before ever invoking a callback [this is a pain because pinning an object causes it to be tenured to old space if it is in new space; objects can't be pinned in new space, so instead the pin operation forwards the new space object to an old space copy if required and answers its location in old space, so a putative withPinnedObjectsDo: operation for the copyBits primitive looks like withPinnedFormsDo: aBlock <inline: #always> self cppIf: SPURVM & false ifTrue: [| bitBltOopWasPinned destWasPinned sourceWasPinned halftoneWasPinned | (bitBltOopWasPinned := interpreterProxy isPinned: bitBltOop) ifFalse: [bitBltOop := interpreterProxy pinObject: bitBltOop]. (destWasPinned := interpreterProxy isPinned: destForm) ifFalse: [destForm := interpreterProxy pinObject: destForm]. (sourceWasPinned := interpreterProxy isPinned: sourceForm) ifFalse: [sourceForm := interpreterProxy pinObject: sourceForm]. (halftoneWasPinned := interpreterProxy isPinned: halftoneForm) ifFalse: [halftoneForm := interpreterProxy pinObject: halftoneForm]. aBlock value. bitBltOopWasPinned ifFalse: [interpreterProxy unpinObject: bitBltOop]. destWasPinned ifFalse: [interpreterProxy unpinObject: destForm]. sourceWasPinned ifFalse: [interpreterProxy unpinObject: sourceForm]. halftoneWasPinned ifFalse: [interpreterProxy unpinObject: halftoneForm]] ifFalse: [aBlock value] and tenuring objects to old space is not ideal because they are only collected by a full GC, so doing this would at least tenure the bitBltOop which is very likely to be in new space] c) fixing the primitive so that it uses the scavenge and fullGC counters in the VM to detect if a GC occurred during one of the callbacks and would fail the primitive [if it detected that a GC had occurred in any of the surface functions]. The primitive would then simply be retried. d) ? I like c) as it's very lightweight, but it has issues. It is fine to use for callbacks *before* cop[yBits and warpBits move any bits (the lockSurface and querySurface functions). But it's potentially erroneous after the unlockSurface primitive. For example, a primitive which does an xor with the screen can't simply be retried as the first, falling pass, would have updated the destination bits but not displayed them via unlockSurface. But I think it could be arranged that no objects are accessed after unlockSurface, which should naturally be the last call in the primitive (or do I mean showSurface?). So the approach would be to check for GCs occurring during querySurface and lockSurface, failing if so, and then caching any and all state needed by unlockSurface and showSurface in local variables. This way no object state is accessed to make the unlockSurface and showSurface calls, and no bits are moved before the queryDurface and lockSurface calls. If we used a failure code such as #'object may move' then the primitives could answer this when a GC during callbacks is detected and then the primitive could be retried only when required. [Come on folks, please comment. I want to know which idea you like best. We could fix this quickly. But right now it feels like I'm talking to myself.] > Here is the easiest way to reproduce it (in mac): > > wget files.pharo.org/get-files/60/pharo64-mac-latest.zip > wget files.pharo.org/get-files/60/pharo64.zip > wget files.pharo.org/get-files/60/sources.zip > unzip pharo64-mac-latest.zip > unzip pharo64.zip > unzip sources.zip > ./Pharo.app/Contents/MacOS/Pharo ./Pharo64-60438.image eval "VGTigerDemo > runDemo" > > eventually (like 5-6 seconds after, if not immediately), you will have a > stack like this: > > SmallInteger(Object)>>primitiveFailed: > SmallInteger(Object)>>primitiveFailed > SmallInteger(VMCallbackContext64)>>primSignal:andReturnAs:fromContext: > GrafPort>>copyBits > GrafPort>>image:at:sourceRect:rule: > FormCanvas>>image:at:sourceRect:rule: > FormCanvas(Canvas)>>drawImage:at:sourceRect: > FormCanvas(Canvas)>>drawImage:at: > VGTigerDemo>>runDemo > VGTigerDemo class>>runDemo > UndefinedObject>>DoIt > OpalCompiler>>evaluate > OpalCompiler(AbstractCompiler)>>evaluate: > [ result := Smalltalk compiler evaluate: aStream. > self hasSessionChanged > ifFalse: [ self stdout > print: result; > lf ] ] in EvaluateCommandLineHandler>>evaluate: > in Block: [ result := Smalltalk compiler evaluate: aStream.... > BlockClosure>>on:do: > EvaluateCommandLineHandler>>evaluate: > EvaluateCommandLineHandler>>evaluateArguments > EvaluateCommandLineHandler>>activate > EvaluateCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ aCommandLinehandler activateWith: commandLine ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in > Block: [ aCommandLinehandler activateWith: commandLine ] > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: > [ self > handleArgument: > (self arguments > ifEmpty: [ '' ] > ifNotEmpty: [ :arguments | arguments first ]) ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ > self... > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activate > PharoCommandLineHandler>>activate > PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ super activateWith: aCommandLine ] in PharoCommandLineHandler > class>>activateWith: in Block: [ super activateWith: aCommandLine ] > > Any idea? > > thanks! > Esteban -- _,,,^..^,,,_ best, Eliot

6 11

[pharo-project/pharo-core]
by GitHub June 14, 2017

June 14, 2017

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

1 0

[pharo-project/pharo-core] e59a47: 60500
by GitHub June 14, 2017

June 14, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e59a4769ea6b401295c17ddf67cfb58757f8909d https://github.com/pharo-project/pharo-core/commit/e59a4769ea6b401295c17ddf… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-14 (Wed, 14 Jun 2017) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60499.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60500.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60499.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60500.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Zinc-Zodiac.package/ZnHTTPSTests.class/instance/testing/testGetPharoVersion.st Log Message: ----------- 60500 20146 ZnHTTPSTests>>#testGetPharoVersion started to fail https://pharo.fogbugz.com/f/cases/20146 http://files.pharo.org/image/60/60500.zip

1 0

[ANN] Pharo 6.0 released!
by Esteban Lorenzano June 13, 2017

June 13, 2017

Dear World, The time has come for Pharo 6.0! Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. This is our most significant release yet. Here are some highlights: - Pharo is now provided in 64-bit version in Linux and OSX and brings even better performance and stability (beware, 64bits version is a new technology and a small amount of tests is still failing) - A new code changes management system named Epicea for easier reviewing and recovering of your code easily - Integrated support for Git through an easy-to-use tool for repositories and commits management named Iceberg (as a preview for Pharo 6, it will be the default in Pharo 7) - The unified foreign function interface (UnifiedFFI) for interfacing with the outside world is significantly improved - The PharoVM is now part of OpenSmalltalk initiative - Introduction of object immutability, alternative bytecode sets and block closures independent of outer context - Pharo can now be bootstrapped from source code managed by Git - Pharo modularity is improved - Pharo is faster - The Dark Theme was improved and set as default color theme of Pharo These are just the more prominent highlights, but the details are just as important. We have closed 1474 issues in Pharo 6.0 (a more complete changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60Change…) While the technical improvements are significant (starting the transition to 64bits is a remarkable achievement), still the most impressive fact is that the new code that got in the main Pharo 6.0 image was contributed by more than 80 people. Pharo is more than code. It is an exciting project involving energetic people. We thank all the contributors of this release: Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas Godoy, Marcus Denker, Mariano Martinez Peck, Marion Noirbent, Martin Dias, Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo Tesone, Paul De Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger Stebler, Ronie Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie Kaleba, Stefan Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van Caekenberghe, Thibault Arloing, Thibault Arloing, Thibault Raffaillac, Thierry Goubier, Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor Girba, Udo Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner Kassens, Yuriy Tymchuk (If you contributed with Pharo 6.0 development in any way and we missed your name, please send us a mail and we will add you). Enjoy! The Pharo Team Try Pharo: http://pharo.org/download Learn Pharo: http://pharo.org/documentation

12 13

Github package management beta
by Eliot Miranda June 13, 2017

June 13, 2017

Hi All, I've been invited to participate in github's Bera test of their new package management support. I don't know much, if anything, about the software except that it supports RubyGems (Ruby), Maven (Java) and npm (JavaScript) formats. My contact at github has asked me to supply a list of email addresses of those who would like to test the software. My contact will provide documentation. If you would like to participate please reply to me using this same subject line and including in the body of the message the email you'd like used. Please do top post. Maybe we could get github to directly support Monticello. Maybe this could achieve some simplifications and ease some tensions. I don't know. But I'm intrigued. Cheers! _,,,^..^,,,_ (phone)

5 4