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

Re: [Pharo-dev] Bloc and Gestures

by Stephane Ducasse

I really hope that we will be able to take advantage of the work done by merwan and jb on gestures but yes we need sdl20 working. Stef On Sat, Dec 2, 2017 at 1:02 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Sean, > > The main problem of gestures is that they can only theoretically work with > OS-Window (SDL2 or other windowing library). > With morphic I can not even find how to add support of horizontal scrolling > using touchpad... > > For this reason those gestures are hierarchy placeholder and are not used > anywhere. > As for ETA ... 3 months maybe :) I think we will work on gestures as soon as > bloc will officially supports SDL2 windows. > > Cheers, > Alex

Dec. 4, 2017

Re: [Pharo-dev] Bloc Feedback

by Stephane Ducasse

Hi Aliaksei Read again this sentence :) "BlPostAction" - a valuable that is guaranteed to be evaluated in the beginning of every frame before anything else. MAy be BlPostAction should be renamed BlEarlyAction On Sat, Dec 2, 2017 at 5:26 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > An object that is called now "Animation" in Bloc is not necessarily bound to > the visual element. > The correct name for the root class of "BlBaseAnimation" should be > "BlPostAction" - a valuable that is guaranteed to be evaluated in the > beginning of every frame before anything else. We have already a deferred > action but they are only evaluated when there is enough time between frames. > "BlBaseAnimation" should be renamed to something line "BlElementAnimation" > that is guaranteed to be bound to a visual element and stops itself if > element is no more in the scene graph by checking that explicitly before > doing every animation step. > > Cheers, > Alex > > On 2 December 2017 at 16:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Aliaksei Syrel wrote >> > ... >> > Also, what is the lifetime of an infinite animation? >> > ... >> > Do you have any particular use-case for animations? >> >> I hacked together a simplified stepping animation (may not be in the right >> place in the class hierarchy). Here's a pull request to discuss >> https://github.com/pharo-graphics/Bloc/pull/37 >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Dec. 4, 2017

Re: [Pharo-dev] Pharo Launcher endless loop opening debuggers in Pharo 6.1

by Bernhard Pieber

Hi Christoph, Thanks for looking into this. Here you go: Bernhard > Am 04.12.2017 um 10:54 schrieb Christophe Demarey <christophe.demarey(a)inria.fr>: > > Hi, > > I cannot reproduce this bug. > Do you have the log or the stack trace? > >> Le 2 dÃ©c. 2017 Ã 14:51, Bernhard Pieber <bernhard(a)pieber.com> a Ã©crit : >> >> I ran into an annoying problem using the latest Pharo 6.1 (stable) from Pharo Launcher. I am on macOS Sierra Version 10.12.6. >> >> Steps to reproduce: >> 1. Open Pharo Launcher >> 2. Create new Pharo 6.1 (stable) image from the official distributions, named Test >> 3. Launch the Test image >> 4. Open a File Browser >> 5. Right click on the selected Test directory in the left file tree pane. >> 6. Debuggers start opening on KeyNotFound: key #arg4 not found in Dictionary >> 7. Image hangs >> >> Interestingly the problem does not happen if I create the image using âcurl get.pharo.org | bashâ and start it with â./pharo-ui Pharo.imageâ although About Pharo shows the same information: >> Pharo 6.0 >> Latest update: #60523 >> >> Can someone please confirm the bug? >> >> Bernhard

Dec. 4, 2017

[Pharo 7.0-dev] Build #358: 20786-halt-messages-are-not-highlighted-in-red-as-the-other-flavours-of-halt-messages

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

There is a new Pharo build available! The status of the build #358 was: SUCCESS. The Pull Request #569 was integrated: "20786-halt-messages-are-not-highlighted-in-red-as-the-other-flavours-of-halt-messages" Pull request url: https://github.com/pharo-project/pharo/pull/569 Issue Url: https://pharo.fogbugz.com/f/cases/20786 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 4, 2017

Pharo newsletter archive

by Torsten Bergmann

Hi, the newsletter archive is now available on "newsletter.pharo.org" which is more easy to remember. Thanks Marcus for setting up the redirect! Bye T.

Dec. 4, 2017

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

by Eliot Miranda

Hi Ben, > On Dec 4, 2017, at 6:38 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> On 4 December 2017 at 15:47, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Here are some ideas/things to say on the tip of my head: >> - Changing an object to a forwarding object is non atomic (we need to maintain at least stack invariant) > > Thats because the whole multiword object has to be copied. > What about the reverse, flattening a forwarding-object back into the > real-object? > I presume only the one word of the object-pointer is updated. > btw, are we safe if competing threads write the *same* data to a slot, Alas a forwarding object has two fields that need to be set in separate words. The class index in the header must be the forwarder class index, and the first word of the object body must point to the forwarder. Reverting obviously requires two writes too. So atomic (un)forwarding is not possible. > > > Anyway my idea was the GC-thread would only *identify* objects to be > moved, and queue them > for the Main-thread to chip away at, so only one thread is converting > objects to forwarding objects. > > >> - To decrease the pauses in full GC I have 2 plans: >> -- incremental marking (split the mark pause in multiple small pauses): Not implemented right now. >> -- selective compaction (compacts only part of the heap instead of all the heap and sweeps the rest, similar to G1, but uses forwarders instead of lots of card marking metadata): I implemented SpurSweeper which only sweeps but works very well. >> - Currently the marking phase removes all forwarders and I would like incremental marking to maintain the same invariant (forwarders are always white). > > A concurrent-marking thread could essentially do the same. > i. From shared memory load forwarder F from object-slot > F <== object-slot > > ii. Follow forwarder to real-object, store into temporary R > R <== flattened/followed pointer > > iii. Atomic compare-and-swap R back into object-slot, > object-slot <== if F then R > > When (iii.) fails > * If I'm the Main-thread, then an other-thread already did what I wanted, > and since thats the *only* mutation other-threads can do to an object-slot. > I am certain... "object-slot == R", so since I'm handling a > failed forwarding-check, just continue with the normal retry. > * If I'm an other-thread, no hurry. Read the object-slot again and it > "should" be a real-object, otherwise just keep trying until I get one. > > So the question is... When using forwarders for compaction, > how often would fail forwarder-check fail... > * if there was one thread on its own; versus > * in the Main-thread if an other-thread had already flattened many of them > > >> - In general, Concurrent marking and sweeping have been implemented everywhere, but no concurrent compaction. For compaction you can make it selective (compact only part of the heap and the part which needs it the most) like I suggest and like in G1, which decreases considerably compaction pause time. Work on concurrent compaction is state of the art and not in production everywhere, see for example > > IIUC not many other languages use forwarding pointer like we do, and > these seem like a real advantage > to compact incrementally and concurrently. > > >> No more time right now. > > I recognise it wasn't a great format. > I really appreciate the time you could spare. > > cheers -ben >

Dec. 4, 2017

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

by Ben Coman

On 4 December 2017 at 15:47, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Here are some ideas/things to say on the tip of my head: > - Changing an object to a forwarding object is non atomic (we need to maintain at least stack invariant) Thats because the whole multiword object has to be copied. What about the reverse, flattening a forwarding-object back into the real-object? I presume only the one word of the object-pointer is updated. btw, are we safe if competing threads write the *same* data to a slot, Anyway my idea was the GC-thread would only *identify* objects to be moved, and queue them for the Main-thread to chip away at, so only one thread is converting objects to forwarding objects. > - To decrease the pauses in full GC I have 2 plans: > -- incremental marking (split the mark pause in multiple small pauses): Not implemented right now. > -- selective compaction (compacts only part of the heap instead of all the heap and sweeps the rest, similar to G1, but uses forwarders instead of lots of card marking metadata): I implemented SpurSweeper which only sweeps but works very well. > - Currently the marking phase removes all forwarders and I would like incremental marking to maintain the same invariant (forwarders are always white). A concurrent-marking thread could essentially do the same. i. From shared memory load forwarder F from object-slot F <== object-slot ii. Follow forwarder to real-object, store into temporary R R <== flattened/followed pointer iii. Atomic compare-and-swap R back into object-slot, object-slot <== if F then R When (iii.) fails * If I'm the Main-thread, then an other-thread already did what I wanted, and since thats the *only* mutation other-threads can do to an object-slot. I am certain... "object-slot == R", so since I'm handling a failed forwarding-check, just continue with the normal retry. * If I'm an other-thread, no hurry. Read the object-slot again and it "should" be a real-object, otherwise just keep trying until I get one. So the question is... When using forwarders for compaction, how often would fail forwarder-check fail... * if there was one thread on its own; versus * in the Main-thread if an other-thread had already flattened many of them > - In general, Concurrent marking and sweeping have been implemented everywhere, but no concurrent compaction. For compaction you can make it selective (compact only part of the heap and the part which needs it the most) like I suggest and like in G1, which decreases considerably compaction pause time. Work on concurrent compaction is state of the art and not in production everywhere, see for example IIUC not many other languages use forwarding pointer like we do, and these seem like a real advantage to compact incrementally and concurrently. > No more time right now. I recognise it wasn't a great format. I really appreciate the time you could spare. cheers -ben

Dec. 4, 2017

feenk log

by Tudor Girba

Hi, Here is an update of the work on Bloc and GT: Bloc: - Bezier curves (cubic and quadratic). https://twitter.com/feenkcom/status/934765444464021504 https://twitter.com/feenkcom/status/934856909001252865 - Dragging is now possible through a BlDragHandler that can be attached to any element. - Pixel accurate line heads and tails https://twitter.com/feenkcom/status/936704646290305025 - More flexible scalable element. https://twitter.com/feenkcom/status/934003681539907585 - Improved scalability of the rendering. For example, on Mac, we are on par with the speed of Firefox. https://twitter.com/feenkcom/status/931462535861108736 - Sparta is now able to load custom fonts. https://twitter.com/feenkcom/status/930919637214285824 - Text insertion works now much better. Deletion and Selection still require more work. - The rope data structure can now be better inspected. https://twitter.com/feenkcom/status/937298739584172032 - Sparta/Moz2D has a visual loader that also provides more specific details in case of errors. https://twitter.com/feenkcom/status/936501909581688832 - Moz2D is now installed by default on Linux 64b. GT: - The GT Visualizer sub-project now contains two tools: -- GT Mondrian is a graph visualization engine that is both performant and shows how Bloc works well for visualizations. More details in a follow up post. https://twitter.com/feenkcom/status/937682660704563202 -- GT Connector is a new tool for browsing connected examples. More details about it in a follow up post. https://twitter.com/feenkcom/status/936109463462965248 Enjoy, The feenk team -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

Dec. 4, 2017

Re: [Pharo-dev] Alternative bytecode sets demo request

by Eliot Miranda

Hi Ben, > On Dec 4, 2017, at 4:17 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> On 4 December 2017 at 10:48, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Ben, >> >>> On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> I'm shooting in the dark here since its a bit hard to grasp... >>> a. The implications of support alternative bytecode sets >>> * Do the alternative bytecode sets run in parallel to normal Pharo >>> bytecodes? >> >> >> Yes. There's a single bit in the header of a compiled method that selects >> between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is >> unset then the normal bytecode set is used, and if the nit is set, the Sista >> bytecode set is used. > > That clarifies things a lot. So I guess the main advantage of this bit > is making it easier to: > a. incrementally develop and test new bytecodes? > b. transition the Image between bytecode sets? Exactly. >>> * Can the bytecode sets be loaded adhoc/dynamically into an Image? >>> or only compiled into the VM? >> >> >> Only compiled into the VM. >> >>> >>> b. How to implement/work with alternative bytecodes >> >> >> In Squeak there are class-side accessors in CompiledCode. See CompiledCode >> class>>installSecondaryBytecodeSet:. Note that the support isn't quite >> finished yet. I hope to have the Sista vytecde set ready for the next >> release of Squeak. ClÃ©ment is providing it in Pharo. >> >> In Squeak the BytecodeEncoder hierarchy implements the necessary support for >> multiple bytecode sets. Via CompiledCode >> class>>installSecondaryBytecodeSet: the system is informed as to which >> bytecode set to use. This must match the bytecode set(s) that are in the >> VM. Classes beneath BytecodeEncoder, in particular EncoderForV3PlusClosures >> and EncoderForSistaV1 (in package BytecodeSets at >> http://source.squeak.org/VMMaker) encode the current and the Sista sets >> respectively. > > Can more than two bytecode sets be compiled into the one VM? > i.e. Is a bytecode-set hard coded into position, > or is it more like a variable slot that can select between several > bytecode sets compiled into the VM. For example, if someone wanted > to experiment with implementing Ethereum bytecodes, would they first need > to rip out either EncoderForV3PlusClosures or EncoderForSistaV1? It's hard coded. There could be more sets. This is Claus Gittinger's idea and in his VM there are two bits, allowing 4 sets. The implementation is simple. A variable holds the bytecode index times 256, and this is added to the bytecode on each dispatch in either the interpreter or the JIT. So in Claus' VM the bytecodes range from 0 to 1023. The variable must be set on every send and return. Obviously in jitted code it is effectively free. We were short of header bits and only needed one extra set so we support only two. > > > Now I made the mistake once of thinking it was Sista introducing this > bytecode-bit, > (btw, how do you normally refer to it?) but IIUC Sista is just making use > of the feature. So I'm curious historically when the bytecode-bit was > introduced? I added it with Claus when we were working on a project together in 2012. It was first used for Newspeak in 2013 or 2014 when I defined a set that supported the full range of Newspeak sends and lifted the number of literals and branch displacement limits. > > cheers -ben > >> >>> To help (b.), would it be feasible to blog a mini-demo showing how to >>> install/use alternative bytecodes? maybe for something like this simple RPN >>> calculator substitute for "arith.c"... >>> * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith >>> * >>> https://github.com/philipaconrad/mini-vm/blob/master/examples/arith/arith.c >> >> >> That's not how this will work. Essentially it is transparent. Once the >> bytecode set support is installed in the compiler one simply compiles >> Smalltalk (or anything else that produces parse trees that can be output to >> compiled methods via the BytecodeEncoder hierarchy) and the method will be >> output in the currently selected bytecode set. So it's not something one >> plays around with, unless that is, one is developing the bytecode set in the >> Vm simulator. >

Dec. 4, 2017

[Pharo 7.0-dev] Build #357: 20781-update-to-iceberg-064

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

There is a new Pharo build available! The status of the build #357 was: SUCCESS. The Pull Request #560 was integrated: "20781-update-to-iceberg-064" Pull request url: https://github.com/pharo-project/pharo/pull/560 Issue Url: https://pharo.fogbugz.com/f/cases/20781 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 4, 2017

Re: [Pharo-dev] Alternative bytecode sets demo request

by Ben Coman

On 4 December 2017 at 10:48, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ben, > > On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> I'm shooting in the dark here since its a bit hard to grasp... >> a. The implications of support alternative bytecode sets >> * Do the alternative bytecode sets run in parallel to normal Pharo >> bytecodes? > > > Yes. There's a single bit in the header of a compiled method that selects > between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is > unset then the normal bytecode set is used, and if the nit is set, the Sista > bytecode set is used. That clarifies things a lot. So I guess the main advantage of this bit is making it easier to: a. incrementally develop and test new bytecodes? b. transition the Image between bytecode sets? >> * Can the bytecode sets be loaded adhoc/dynamically into an Image? >> or only compiled into the VM? > > > Only compiled into the VM. > >> >> b. How to implement/work with alternative bytecodes > > > In Squeak there are class-side accessors in CompiledCode. See CompiledCode > class>>installSecondaryBytecodeSet:. Note that the support isn't quite > finished yet. I hope to have the Sista vytecde set ready for the next > release of Squeak. ClÃ©ment is providing it in Pharo. > > In Squeak the BytecodeEncoder hierarchy implements the necessary support for > multiple bytecode sets. Via CompiledCode > class>>installSecondaryBytecodeSet: the system is informed as to which > bytecode set to use. This must match the bytecode set(s) that are in the > VM. Classes beneath BytecodeEncoder, in particular EncoderForV3PlusClosures > and EncoderForSistaV1 (in package BytecodeSets at > http://source.squeak.org/VMMaker) encode the current and the Sista sets > respectively. Can more than two bytecode sets be compiled into the one VM? i.e. Is a bytecode-set hard coded into position, or is it more like a variable slot that can select between several bytecode sets compiled into the VM. For example, if someone wanted to experiment with implementing Ethereum bytecodes, would they first need to rip out either EncoderForV3PlusClosures or EncoderForSistaV1? Now I made the mistake once of thinking it was Sista introducing this bytecode-bit, (btw, how do you normally refer to it?) but IIUC Sista is just making use of the feature. So I'm curious historically when the bytecode-bit was introduced? cheers -ben > >> To help (b.), would it be feasible to blog a mini-demo showing how to >> install/use alternative bytecodes? maybe for something like this simple RPN >> calculator substitute for "arith.c"... >> * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith >> * >> https://github.com/philipaconrad/mini-vm/blob/master/examples/arith/arith.c > > > That's not how this will work. Essentially it is transparent. Once the > bytecode set support is installed in the compiler one simply compiles > Smalltalk (or anything else that produces parse trees that can be output to > compiled methods via the BytecodeEncoder hierarchy) and the method will be > output in the currently selected bytecode set. So it's not something one > plays around with, unless that is, one is developing the bytecode set in the > Vm simulator.

Dec. 4, 2017

[Pharo 7.0-dev] Build #356: 20793-During-Bootstrap-if-a-baseline-installation-fails-it-should-cancel-the-process

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

There is a new Pharo build available! The status of the build #356 was: FAILURE. The Pull Request #567 was integrated: "20793-During-Bootstrap-if-a-baseline-installation-fails-it-should-cancel-the-process" Pull request url: https://github.com/pharo-project/pharo/pull/567 Issue Url: https://pharo.fogbugz.com/f/cases/20793 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 4, 2017

Re: [Pharo-dev] Design pattern for wrapper/proxy objects?

by Mariano Martinez Peck

Hi Luke, Not only for the details of a particular proxy implementation like Ghost, but also because of all the discussions around it, I think this journal paper [1] we wrote may be of help to you. Cheers, [1] https://hal.inria.fr/hal-01081236 On Mon, Dec 4, 2017 at 5:51 AM, Luke Gorrie <luke(a)snabb.co> wrote: > Thanks Ben & Henrik for the ideas! > > I will scratch my head a bit and then try to do something sensible. :-) > > > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2017

Re: [Pharo-dev] Pharo Launcher endless loop opening debuggers in Pharo 6.1

by Christophe Demarey

Hi, I cannot reproduce this bug. Do you have the log or the stack trace? > Le 2 dÃ©c. 2017 Ã 14:51, Bernhard Pieber <bernhard(a)pieber.com> a Ã©crit : > > I ran into an annoying problem using the latest Pharo 6.1 (stable) from Pharo Launcher. I am on macOS Sierra Version 10.12.6. > > Steps to reproduce: > 1. Open Pharo Launcher > 2. Create new Pharo 6.1 (stable) image from the official distributions, named Test > 3. Launch the Test image > 4. Open a File Browser > 5. Right click on the selected Test directory in the left file tree pane. > 6. Debuggers start opening on KeyNotFound: key #arg4 not found in Dictionary > 7. Image hangs > > Interestingly the problem does not happen if I create the image using âcurl get.pharo.org | bashâ and start it with â./pharo-ui Pharo.imageâ although About Pharo shows the same information: > Pharo 6.0 > Latest update: #60523 > > Can someone please confirm the bug? > > Bernhard

Dec. 4, 2017

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

by Benoit St-Jean

Perhaps the solution resides in settings you can tweak from within Smalltalk?Â Something like MemoryPolicy you have in VisualWorks for memory & garbage collection management. I don't think fixing the behavior of memory management & garbage collection (marking, sweeping, etc) in the VM is the way to go.Â There's an awful lot of different needs for different applications out there ! Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: ClÃ©ment Bera <bera.clement(a)gmail.com> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Cc: Pharo Development List <pharo-dev(a)lists.pharo.org> Sent: Monday, December 4, 2017 2:49 AM Subject: Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap) hum... The mail is very long so I did not read all of it. Here are some ideas/things to say on the tip of my head:- Changing an object to a forwarding object is non atomic (we need to maintain at least stack invariant)- To decrease the pauses in full GC I have 2 plans:-- incremental marking (split the mark pause in multiple small pauses): Not implemented right now.-- selective compaction (compacts only part of the heap instead of all the heap and sweeps the rest, similar to G1, but uses forwarders instead of lots of card marking metadata): I implemented SpurSweeper which only sweeps but works very well.- Currently the marking phase removes all forwarders and I would like incremental marking to maintain the same invariant (forwarders are always white). - In general, Concurrent marking and sweeping have been implemented everywhere, but no concurrent compaction. For compaction you can make it selective (compact only part of the heap and the part which needs it the most) like I suggest and like in G1, which decreases considerably compaction pause time. Work on concurrent compaction is state of the art and not in production everywhere, see for exampleÂ Shenandoah Garbage Collector A. Shipilev Pause-Less GC for Improving Java ResponsivenessÂ C. Gracie And I will watch at talk on this topic tomorrow for the Android GC.- Some runtime, especially now with small servers being rent, are running on single core machines. So we need the low-pause GC to work incrementally aside from concurrently. So step 1 incremental GC. Step 2 concurrent marking and sweeping with low-pause for scavenge/compaction. No more time right now.Â On Sun, Dec 3, 2017 at 6:33 AM, Ben Coman <btc(a)openinworld.com> wrote: Hi Eliot, Clement, On 7 July 2017 at 00:41, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > - Better support for large heaps (GC tuning API, incremental GC). > > Pharo 64 bit is now able to manage large heap. However better > > performance can be proposed by offering better settings for the > > different GC zone. > > The most important thing here is the incremental GC.Â Spur has a generation > scavenger that collects garbage in newly created objects (new space), > and a mark-compact collector that collects and compacts garbage in old space. > > Right now on my 2.3GHz MacMini doing normal development, the generation > scavenger causes pauses of 1ms or less, and the mark-compact collector > than causes pauses of around 200ms.Â Both account for about 0.75% of > entire execution time (1.5% total), so the scavenger is invoked frequently > and the pauses that it creates are not noticeable.Â But the occasional > pauses created by the mark-compact collector /are/ noticeable, > especially in games and music. > > The idea for the incremental collector is to implement a mark-sweep or > mark-sweep-compact collector for old space that works incrementally, > doing a little bit of work on each invocation, probably immediately after a scavenge. > It is intended to avoid the long pauses caused by the non-incremental > mark-compact collector and make the system more suitable for games, music, etc. Reading http://www.mirandabanda.org/ cogblog/2013/09/13/lazy- become-and-a-partial-read- barrier/ Â "An alternative implementation, oft-used in Lisp systems, is to add a Â read barrier to all object access, and mark objects as forwarders. Â This can be used to implement a >>>lazy copying garbage collection<<<< Â where objects are copied from one semi-space to another in parallel to the Â main program (the âmutatorâ).Â To become, or move an object one replaces the Â objectâs header or first field with a forwarding pointer to the desired target Â or copy in a new location, marking the âcorpseâ as forwarded.Â The program Â checks the forwarded flag on each access.Â If there is hardware support, Â as in a Lisp machine, this can work well.Â But without hardware support, Â and like the object table representation, it has costs, slowing down Â program execution due to the scattering of forwarding checks and Â forwarding pointer follows throughout program execution." I'm curious... Given we now have forwarders with Spur, are we already sufficiently paying the cost of forwarding checks that a lazy copying garbage collector might be a feasible form of incremental garbage collection? I presume "parallel to the main program" means garbage collection occuring in a separate thread to the main vm thread, potentially resulting in very low main program pause times for garbage collection. I found this a useful summary of the terminology... * https://www.dynatrace.com/ resources/ebooks/javabook/ reduce-garbage-collection- pause-time/ and I'm curious how our planned Incremental CG fits those categories. That article got me contemplating our performance constraint of the VM only operating in only in a single native thread. Even though GC is a only a few percent of performance, I wondered what a concurrent GC might look like for us. I found this video describing concurrent GC in Go (ignore first 11:20 and the second half was not so interesting) * https://pusher.com/sessions/ meetup/the-realtime-guild/ golangs-realtime-garbage- collector where they present some interesting charts of their concern with latency pauses. (btw they reference a multi-language GC latency benchmark Â https://github.com/WillSewell/ gc-latency-experiment) And for balance of that I found... https://blog.plan99.net/ modern-garbage-collection- 911ef4f8bd8e And then my mind wandered around implementation details of concurrent garbage collection. To organise and quiet my thoughts I needed to put pen to paper, so I thought sharing that might stir thoughts for others.Â Probably naive and please excuse the brain dump format... Considering two threads... * Main program thread "MP" * Garbage collection thread "GC" with object-space shared between them, consisting of objects split in object-header & object-body... 1. Only "MP" mutates the object-body, updating slots creating new edges Â Â in the object-graph, and relocating objects in memory using forwarders. Â Â This rule avoids potential race conditions without needing to add Â Â synchronisation code affecting performance of "MP". 2. Concurrently "GC" performs a Marking Phase by following the object-graph Â Â tricolour tagging objects gray & black. it needs to mutate the object-header, Â Â in a synchronised way something like... Â Â Â a. Load object-header from shared object-space into local variable Â Â Â Â Â H <== object-header Â Â Â b. Modify header into another local variable Â Â Â Â Â H' <== H + updated GC color bits Â Â Â c. Atomic compare-and-swap H' back into object-space Â Â Â Â Â object-header <== if H then H' Â Â Â "MP" gets priority. Conflicts presumed rare. Then considering object mutation by "MP" concurrent/overlapped with "GC" marking... 3. TLDR; see 4. Â Â In old-space if 'mutated' object is linked to a 'target' object Â Â Â a. if 'mutated' isBlack, "MP" marks 'target' gray (to be later processed by "GC"). Â Â Â b. if 'mutated' isGray, overlapped 'mutated' gray->black by "GC" while 'target' Â Â Â Â remains white would break tricolor invariant (is it a credible case?), options... Â Â Â Â Â i. mark 'target' gray, the state anyway in case 'mutated' gray -> black Â Â Â Â Â ii. re-mark 'mutated' gray, i.e. normally gray->gray, and rarely black->gray Â Â Â Â Â iii. optimisticly just check after mutation if color changed (cached reads Â Â Â Â Â Â Â Â cheaper than writes and conflicts presumed rare) then set color to gray. Â Â Â c. if 'mutated' isWhite, options... Â Â Â Â Â i. do nothing and let "GC" reach 'target' normally, as long as overlapped white->black cannot occur Â Â Â Â Â ii. if white->black possible, do same as (3.b) "MP" marks 'target' gray, to be later processed by "GC". 4. Overall simplification of (3.) might be... Â Â Â "MP" checks for any color change during mutation, and only then marks 'mutated' object gray. Â Â Â How expensive would such a check be?Â Presumed marking is infrequent and Â Â Â can be done safely like (2.) 5. Eden/survivor space is ignored by "GC" thread. No point in adding work to the gray set Â Â until survivors filtered. Stop the world scavenging done as normal by "MP", Â Â only marking objects gray when they are moved to old-space. Â Â Post scavenging options... Â Â Â Â a. Resume the world and leave it for "GC" to process these recently grayed objects. Â Â Â Â b. Keep world stopped for "MP" to complete marking, emptying gray set to Â Â Â Â Â Â transition to Sweep Phase, at which point "MP" resumes the world. Â Â Â Â Â Â It doesn't matter if subsequently objects are added to the gray set, Â Â Â Â Â Â since existing white objects can never again be referenced by "MP". 6. Sweeping can be safely done by "GC" since white-objects are unreachable from "MP". Â Â "GC" can also take time to determine an optimum page P to compact and Â Â then (per 1.) passes to "MP" via a relocation-queue the objects to be Â Â relocated using forwarding pointers. "GC" could even spend extra time Â Â to determine the optimum relocation-destination without impacting the Â Â performance of "MP".Â When "MP" empties the relocation-queue, "GC" starts Â Â on the next Marking Phase. 7. Now a question remains about multi-threaded flattening of forwarding pointers. Â Â If two threads simultaneously perform an identical transform from... Â Â Â Â someObject-slot --> forwarder-b --> finalObject-c Â Â to... Â Â Â Â someObject-slot --> finalObject-c Â Â does it matter that these operation may be done twice overlapping? Â Â Options... Â Â Â a. One mitigation could be for "GC" to identify forwarders to be flattened Â Â Â Â and queue them for "MP" to process (reuse the compaction-queue).Â This Â Â Â Â is work that "MP" would need to do anyway, but brings it forward to be Â Â Â Â dealt with at a convenient time. Â Â Â b. I guess "MP" and "GC" could play nice together if when encountering Â Â Â Â a slot containing with a forwarding pointer they both do something similar to (2.) like... Â Â Â Â Â i. Load object-slot from shared object-space into local variable S <== slot Â Â Â Â Â ii. Set local variable S' <== flattened/followed pointer Â Â Â Â iii. Atomic compare-and-swap S' back into object-space, (object-slot <== if S then S') Â Â Â Â Â Â Â - "MP" gets priority but presume conflicts rare anyway. Â Â Â Â Â Â Â - While this violates rule (1.) the presumed frequency of Â Â Â Â Â Â Â Â encountering forwarding pointers is low for "MP", so performance Â Â Â Â Â Â Â Â should not be affected. Indeed by "GC" pre-emptively flattening forwarders Â Â Â Â Â Â Â Â the frequency "MP" sees reduces. 8. The release of the compacted page back to the OS is held up by forwarding pointers. Â Â Forwarders are part of the graph followed in the Marking Phase they get Â Â marked gray/black just like objects if they are referenced.Â After forwarders are Â Â fully flattened they are skipped by Marking and end up marked white and released Â Â just like any other object. Once all forwarders are released, the page is released Â Â to the OS.Â Â If "GC" can effectively flatten pointers concurrently with "MP" during its Â Â normal Marking Phase, then pages would be released back to the OS in a timely manner. Now one thing I am curious about how the GC tri-color marking is implemented. At https://clementbera.wordpress. com/2014/01/16/spurs-new- object-format it describes how Spur's object header has three bits for GC. * isGray * isRemembered * isMarkedÂ (I presume this means marked "black") Do the bits imply the gray set is not stored in a separate data structure on the heap, but rather distributed in-place, which I guess would require multiple passes through memory to grow the gray set? So this is not an area I'm set up to seriously work on, but I remain curious and hopefully its a useful seed discussion for others. cheers -ben P.S. At https://clementbera.wordpress. com/2017/09/19/vm-learning- memory-management/ nice to hear that you have Sophie (I presume) continuing with the VM. -- ClÃ©ment BÃ©raPharo consortium engineerhttps://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650Â Villeneuve d'Ascq

Dec. 4, 2017

Re: [Pharo-dev] Design pattern for wrapper/proxy objects?

by Luke Gorrie

Thanks Ben & Henrik for the ideas! I will scratch my head a bit and then try to do something sensible. :-)

Dec. 4, 2017

Re: [Pharo-dev] Design pattern for wrapper/proxy objects?

by Henrik Sperre Johansen

For proxies/wrappers, you might want to look into how the Ghost framework interrupts sends. (I don't know the exact details, but I'd guess step 1 is subclassing ProtoObject, rather than Object) For your specific case, isn't there already a *Struct class in the image you can subclass, create a class method containing the fields definition, and then have accessors autogenerated, rather than using doesNotUnderstand:? Usually, that would make the code easier to browse/debug later on, doesn't confuse the syntax highlighter/code critic in uses of an otherwise undefined field, etc. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 4, 2017

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

by ClÃ©ment Bera

hum... The mail is very long so I did not read all of it. Here are some ideas/things to say on the tip of my head: - Changing an object to a forwarding object is non atomic (we need to maintain at least stack invariant) - To decrease the pauses in full GC I have 2 plans: -- incremental marking (split the mark pause in multiple small pauses): Not implemented right now. -- selective compaction (compacts only part of the heap instead of all the heap and sweeps the rest, similar to G1, but uses forwarders instead of lots of card marking metadata): I implemented SpurSweeper which only sweeps but works very well. - Currently the marking phase removes all forwarders and I would like incremental marking to maintain the same invariant (forwarders are always white). - In general, Concurrent marking and sweeping have been implemented everywhere, but no concurrent compaction. For compaction you can make it selective (compact only part of the heap and the part which needs it the most) like I suggest and like in G1, which decreases considerably compaction pause time. Work on concurrent compaction is state of the art and not in production everywhere, see for example Shenandoah Garbage Collector <https://shipilev.net/talks/vmm-Sep2017-shenandoah.pdf> *A. Shipilev* Pause-Less GC for Improving Java Responsiveness <https://speakerdeck.com/vmm/pause-less-gc-for-improving-java-responsiveness> *C. Gracie* And I will watch at talk on this topic tomorrow for the Android GC. - Some runtime, especially now with small servers being rent, are running on single core machines. So we need the low-pause GC to work incrementally aside from concurrently. So step 1 incremental GC. Step 2 concurrent marking and sweeping with low-pause for scavenge/compaction. No more time right now. On Sun, Dec 3, 2017 at 6:33 AM, Ben Coman <btc(a)openinworld.com> wrote: > > Hi Eliot, Clement, > > On 7 July 2017 at 00:41, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > - Better support for large heaps (GC tuning API, incremental GC). > > > Pharo 64 bit is now able to manage large heap. However better > > > performance can be proposed by offering better settings for the > > > different GC zone. > > > > The most important thing here is the incremental GC. Spur has a > generation > > scavenger that collects garbage in newly created objects (new space), > > and a mark-compact collector that collects and compacts garbage in old > space. > > > > Right now on my 2.3GHz MacMini doing normal development, the generation > > scavenger causes pauses of 1ms or less, and the mark-compact collector > > than causes pauses of around 200ms. Both account for about 0.75% of > > entire execution time (1.5% total), so the scavenger is invoked > frequently > > and the pauses that it creates are not noticeable. But the occasional > > pauses created by the mark-compact collector /are/ noticeable, > > especially in games and music. > > > > The idea for the incremental collector is to implement a mark-sweep or > > mark-sweep-compact collector for old space that works incrementally, > > doing a little bit of work on each invocation, probably immediately > after a scavenge. > > It is intended to avoid the long pauses caused by the non-incremental > > mark-compact collector and make the system more suitable for games, > music, etc. > > Reading http://www.mirandabanda.org/cogblog/2013/09/13/lazy- > become-and-a-partial-read-barrier/ > "An alternative implementation, oft-used in Lisp systems, is to add a > read barrier to all object access, and mark objects as forwarders. > This can be used to implement a >>>lazy copying garbage collection<<<< > where objects are copied from one semi-space to another in parallel to > the > main program (the âmutatorâ). To become, or move an object one replaces > the > objectâs header or first field with a forwarding pointer to the desired > target > or copy in a new location, marking the âcorpseâ as forwarded. The > program > checks the forwarded flag on each access. If there is hardware support, > as in a Lisp machine, this can work well. But without hardware support, > and like the object table representation, it has costs, slowing down > program execution due to the scattering of forwarding checks and > forwarding pointer follows throughout program execution." > > I'm curious... Given we now have forwarders with Spur, are we > already sufficiently paying the cost of forwarding checks that a lazy > copying > garbage collector might be a feasible form of incremental garbage > collection? > > I presume "parallel to the main program" means garbage collection occuring > in a separate thread to the main vm thread, potentially resulting in > very low main program pause times for garbage collection. > > I found this a useful summary of the terminology... > * https://www.dynatrace.com/resources/ebooks/javabook/ > reduce-garbage-collection-pause-time/ > and I'm curious how our planned Incremental CG fits those categories. > > That article got me contemplating our performance constraint of the VM only > operating in only in a single native thread. Even though GC is a only > a few percent of performance, I wondered what a concurrent GC might > look like for us. > > I found this video describing concurrent GC in Go (ignore first 11:20 > and the second half was not so interesting) > * https://pusher.com/sessions/meetup/the-realtime-guild/ > golangs-realtime-garbage-collector > where they present some interesting charts of their concern with latency > pauses. > (btw they reference a multi-language GC latency benchmark > https://github.com/WillSewell/gc-latency-experiment) > > And for balance of that I found... > https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e > > > And then my mind wandered around implementation details of concurrent > garbage collection. > To organise and quiet my thoughts I needed to put pen to paper, so I > thought sharing that > might stir thoughts for others. Probably naive and please excuse the > brain dump format... > > > Considering two threads... > * Main program thread "MP" > * Garbage collection thread "GC" > with object-space shared between them, consisting of objects split in > object-header & object-body... > > 1. Only "MP" mutates the object-body, updating slots creating new edges > in the object-graph, and relocating objects in memory using forwarders. > This rule avoids potential race conditions without needing to add > synchronisation code affecting performance of "MP". > > > 2. Concurrently "GC" performs a Marking Phase by following the object-graph > tricolour tagging objects gray & black. it needs to mutate the > object-header, > in a synchronised way something like... > a. Load object-header from shared object-space into local variable > H <== object-header > b. Modify header into another local variable > H' <== H + updated GC color bits > c. Atomic compare-and-swap H' back into object-space > object-header <== if H then H' > "MP" gets priority. Conflicts presumed rare. > > > Then considering object mutation by "MP" concurrent/overlapped with > "GC" marking... > > 3. TLDR; see 4. > In old-space if 'mutated' object is linked to a 'target' object > a. if 'mutated' isBlack, "MP" marks 'target' gray (to be later > processed by "GC"). > > b. if 'mutated' isGray, overlapped 'mutated' gray->black by "GC" > while 'target' > remains white would break tricolor invariant (is it a credible > case?), options... > i. mark 'target' gray, the state anyway in case 'mutated' > gray -> black > ii. re-mark 'mutated' gray, i.e. normally gray->gray, and > rarely black->gray > iii. optimisticly just check after mutation if color changed > (cached reads > cheaper than writes and conflicts presumed rare) then > set color to gray. > > c. if 'mutated' isWhite, options... > i. do nothing and let "GC" reach 'target' normally, as long > as overlapped white->black cannot occur > ii. if white->black possible, do same as (3.b) "MP" marks > 'target' gray, to be later processed by "GC". > > > 4. Overall simplification of (3.) might be... > "MP" checks for any color change during mutation, and only then > marks 'mutated' object gray. > How expensive would such a check be? Presumed marking is infrequent > and > can be done safely like (2.) > > > 5. Eden/survivor space is ignored by "GC" thread. No point in adding > work to the gray set > until survivors filtered. Stop the world scavenging done as normal by > "MP", > only marking objects gray when they are moved to old-space. > > Post scavenging options... > a. Resume the world and leave it for "GC" to process these > recently grayed objects. > > b. Keep world stopped for "MP" to complete marking, emptying gray > set to > transition to Sweep Phase, at which point "MP" resumes the > world. > It doesn't matter if subsequently objects are added to the gray > set, > since existing white objects can never again be referenced by > "MP". > > > 6. Sweeping can be safely done by "GC" since white-objects are > unreachable from "MP". > "GC" can also take time to determine an optimum page P to compact and > then (per 1.) passes to "MP" via a relocation-queue the objects to be > relocated using forwarding pointers. "GC" could even spend extra time > to determine the optimum relocation-destination without impacting the > performance of "MP". When "MP" empties the relocation-queue, "GC" > starts > on the next Marking Phase. > > > 7. Now a question remains about multi-threaded flattening of > forwarding pointers. > If two threads simultaneously perform an identical transform from... > someObject-slot --> forwarder-b --> finalObject-c > to... > someObject-slot --> finalObject-c > does it matter that these operation may be done twice overlapping? > > Options... > > a. One mitigation could be for "GC" to identify forwarders to be > flattened > and queue them for "MP" to process (reuse the compaction-queue). > This > is work that "MP" would need to do anyway, but brings it forward > to be > dealt with at a convenient time. > > b. I guess "MP" and "GC" could play nice together if when encountering > a slot containing with a forwarding pointer they both do > something similar to (2.) like... > i. Load object-slot from shared object-space into local > variable S <== slot > ii. Set local variable S' <== flattened/followed pointer > iii. Atomic compare-and-swap S' back into object-space, > (object-slot <== if S then S') > - "MP" gets priority but presume conflicts rare anyway. > - While this violates rule (1.) the presumed frequency of > encountering forwarding pointers is low for "MP", so > performance > should not be affected. Indeed by "GC" pre-emptively > flattening forwarders > the frequency "MP" sees reduces. > > > 8. The release of the compacted page back to the OS is held up by > forwarding pointers. > Forwarders are part of the graph followed in the Marking Phase they get > marked gray/black just like objects if they are referenced. After > forwarders are > fully flattened they are skipped by Marking and end up marked white > and released > just like any other object. Once all forwarders are released, the > page is released > to the OS. If "GC" can effectively flatten pointers concurrently > with "MP" during its > normal Marking Phase, then pages would be released back to the OS > in a timely manner. > > > > Now one thing I am curious about how the GC tri-color marking is > implemented. > At https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format > it describes how Spur's object header has three bits for GC. > * isGray > * isRemembered > * isMarked (I presume this means marked "black") > Do the bits imply the gray set is not stored in a separate data > structure on the heap, but rather distributed in-place, which I guess > would require multiple passes through memory to grow the gray set? > > > So this is not an area I'm set up to seriously work on, but I remain > curious > and hopefully its a useful seed discussion for others. > cheers -ben > > > P.S. At https://clementbera.wordpress.com/2017/09/19/vm-learning- > memory-management/ > nice to hear that you have Sophie (I presume) continuing with the VM. > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Dec. 4, 2017

Re: [Pharo-dev] Alternative bytecode sets demo request

by ClÃ©ment Bera

To use the alternate bytecode set in Pharo 7 use: CompilationContext bytecodeBackend: EncoderForSistaV1. OpalCompiler recompileAll. based on: https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/ Currently in Pharo SqueakV3PlusClosure and SistaV1 are installed in CompiledCode. You need to install another set if you want to use it using #installSecondaryBytecodeSet: or similar methods. CompiledMethod installSecondaryBytecodeSet: EncoderForMyBytecodeSet. Then you can just use the first code snippet to use it: CompilationContext bytecodeBackend: EncoderForMyBytecodeSet. OpalCompiler recompileAll. On Mon, Dec 4, 2017 at 3:48 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ben, > > On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> I'm shooting in the dark here since its a bit hard to grasp... >> a. The implications of support alternative bytecode sets >> * Do the alternative bytecode sets run in parallel to normal Pharo >> bytecodes? >> > > Yes. There's a single bit in the header of a compiled method that selects > between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is > unset then the normal bytecode set is used, and if the nit is set, the > Sista bytecode set is used. > > * Can the bytecode sets be loaded adhoc/dynamically into an Image? >> or only compiled into the VM? >> > > Only compiled into the VM. > > >> b. How to implement/work with alternative bytecodes >> > > In Squeak there are class-side accessors in CompiledCode. See > CompiledCode class>>installSecondaryBytecodeSet:. Note that the support > isn't quite finished yet. I hope to have the Sista vytecde set ready for > the next release of Squeak. ClÃ©ment is providing it in Pharo. > > In Squeak the BytecodeEncoder hierarchy implements the necessary support > for multiple bytecode sets. Via CompiledCode class>>installSecondaryBytecodeSet: > the system is informed as to which bytecode set to use. This must match > the bytecode set(s) that are in the VM. Classes beneath BytecodeEncoder, > in particular EncoderForV3PlusClosures and EncoderForSistaV1 (in package > BytecodeSets at http://source.squeak.org/VMMaker) encode the current and > the Sista sets respectively. > > For (a.) I guess an exciting opportunity is facilitating an Ethereum >> virtual machine >> running as a Process inside a Pharo image, managed by tools written in >> Pharo. >> Other languages are already getting in a party which would be good for >> Pharo to join. >> In such a revolutionary domain I expect people are more willing to >> experiment >> with alternative systems like Pharo, and I bet Pharo could excel in that >> domain. >> * https://github.com/ethereum/go-ethereum/blob/master/core/vm/opcodes.go >> * https://medium.com/@jeff.ethereum/optimising-the-ethereum- >> virtual-machine-58457e61ca15 >> * https://github.com/pirapira/awesome-ethereum-virtual-machi >> ne#evm-implementations >> >> >> To help (b.), would it be feasible to blog a mini-demo showing how to >> install/use alternative bytecodes? maybe for something like this simple RPN >> calculator substitute for "arith.c"... >> * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith >> * https://github.com/philipaconrad/mini-vm/blob/master/ >> examples/arith/arith.c >> > > That's not how this will work. Essentially it is transparent. Once the > bytecode set support is installed in the compiler one simply compiles > Smalltalk (or anything else that produces parse trees that can be output to > compiled methods via the BytecodeEncoder hierarchy) and the method will be > output in the currently selected bytecode set. So it's not something one > plays around with, unless that is, one is developing the bytecode set in > the Vm sim,letter. > > >> >> (a calculator demo could be an interesting adjunct to Sven's calculator >> tutorial...) >> https://medium.com/concerning-pharo/rediscovering-the-ux-of- >> the-legendary-hp-35-scientific-pocket-calculator-d1d497ece999 >> >> >> cheers -ben >> > > > > -- > _,,,^..^,,,_ > best, Eliot > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Dec. 4, 2017

Esteban's ChangeLog week of 27 November 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 27 November 2017 to 3 December 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=27/11/2017&to=3/12/2017 ChangeLog ========= 28 November 2017: ----------------- * I just released [Iceberg 0.6.4](https://github.com/pharo-vcs/iceberg/releases/tag/v0.6.4). This is a bugfix release :) cheers! Esteban

Dec. 4, 2017

Re: [Pharo-dev] Alternative bytecode sets demo request

by Eliot Miranda

Hi Ben, On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <btc(a)openinworld.com> wrote: > I'm shooting in the dark here since its a bit hard to grasp... > a. The implications of support alternative bytecode sets > * Do the alternative bytecode sets run in parallel to normal Pharo > bytecodes? > Yes. There's a single bit in the header of a compiled method that selects between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is unset then the normal bytecode set is used, and if the nit is set, the Sista bytecode set is used. * Can the bytecode sets be loaded adhoc/dynamically into an Image? > or only compiled into the VM? > Only compiled into the VM. > b. How to implement/work with alternative bytecodes > In Squeak there are class-side accessors in CompiledCode. See CompiledCode class>>installSecondaryBytecodeSet:. Note that the support isn't quite finished yet. I hope to have the Sista vytecde set ready for the next release of Squeak. ClÃ©ment is providing it in Pharo. In Squeak the BytecodeEncoder hierarchy implements the necessary support for multiple bytecode sets. Via CompiledCode class>>installSecondaryBytecodeSet: the system is informed as to which bytecode set to use. This must match the bytecode set(s) that are in the VM. Classes beneath BytecodeEncoder, in particular EncoderForV3PlusClosures and EncoderForSistaV1 (in package BytecodeSets at http://source.squeak.org/VMMaker) encode the current and the Sista sets respectively. For (a.) I guess an exciting opportunity is facilitating an Ethereum > virtual machine > running as a Process inside a Pharo image, managed by tools written in > Pharo. > Other languages are already getting in a party which would be good for > Pharo to join. > In such a revolutionary domain I expect people are more willing to > experiment > with alternative systems like Pharo, and I bet Pharo could excel in that > domain. > * https://github.com/ethereum/go-ethereum/blob/master/core/vm/opcodes.go > * https://medium.com/@jeff.ethereum/optimising-the- > ethereum-virtual-machine-58457e61ca15 > * https://github.com/pirapira/awesome-ethereum-virtual- > machine#evm-implementations > > > To help (b.), would it be feasible to blog a mini-demo showing how to > install/use alternative bytecodes? maybe for something like this simple RPN > calculator substitute for "arith.c"... > * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith > * https://github.com/philipaconrad/mini-vm/blob/ > master/examples/arith/arith.c > That's not how this will work. Essentially it is transparent. Once the bytecode set support is installed in the compiler one simply compiles Smalltalk (or anything else that produces parse trees that can be output to compiled methods via the BytecodeEncoder hierarchy) and the method will be output in the currently selected bytecode set. So it's not something one plays around with, unless that is, one is developing the bytecode set in the Vm sim,letter. > > (a calculator demo could be an interesting adjunct to Sven's calculator > tutorial...) > https://medium.com/concerning-pharo/rediscovering-the-ux-of- > the-legendary-hp-35-scientific-pocket-calculator-d1d497ece999 > > > cheers -ben > -- _,,,^..^,,,_ best, Eliot

Dec. 4, 2017

Alternative bytecode sets demo request

by Ben Coman

I'm shooting in the dark here since its a bit hard to grasp... a. The implications of support alternative bytecode sets * Do the alternative bytecode sets run in parallel to normal Pharo bytecodes? * Can the bytecode sets be loaded adhoc/dynamically into an Image? or only compiled into the VM? b. How to implement/work with alternative bytecodes For (a.) I guess an exciting opportunity is facilitating an Ethereum virtual machine running as a Process inside a Pharo image, managed by tools written in Pharo. Other languages are already getting in a party which would be good for Pharo to join. In such a revolutionary domain I expect people are more willing to experiment with alternative systems like Pharo, and I bet Pharo could excel in that domain. * https://github.com/ethereum/go-ethereum/blob/master/core/vm/opcodes.go * https://medium.com/@jeff.ethereum/optimising-the-ethereum-virtual-machine-5… * https://github.com/pirapira/awesome-ethereum-virtual-machine#evm-implementa… To help (b.), would it be feasible to blog a mini-demo showing how to install/use alternative bytecodes? maybe for something like this simple RPN calculator substitute for "arith.c"... * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith * https://github.com/philipaconrad/mini-vm/blob/master/examples/arith/arith.c (a calculator demo could be an interesting adjunct to Sven's calculator tutorial...) https://medium.com/concerning-pharo/rediscovering-the-ux-of-the-legendary-h… cheers -ben

Dec. 4, 2017

Re: [Pharo-dev] Design pattern for wrapper/proxy objects?

by Ben Coman

On 4 December 2017 at 00:10, Luke Gorrie <luke(a)snabb.co> wrote: > Howdy, > > I have some Smalltalk objects that represent external data and I am looking > for a neat way to access them. > > The data that I am dealing with is C binary objects described by DWARF > schemas. So I will load a type declaration like this: > > struct outer { > struct inner { > int a, b; > }; > }; > > and then I will want to be able to write convenient expressions like: > > aStruct outer inner a + aStruct outer inner b > > I have implemented this already but I am not sure that I took the right > approach. Seems like a reasonable approach, except difficulties with the broadness of your DSL domain (as you've found.) > I have implemented these accessors like #outer #inner #a #b via a > messageNotUnderstood: method that looks into the object, so that 'aStruct > outer' is equivalent to 'aStruct field: #outer'. My concern is that the > names of the C struct fields can collide with existing Smalltalk methods and > then I will get totally unexpected results. > > Is there a canonical solution to this problem? > > The first idea I have is to add a bit of syntatic sugar, like to write > 'aStruct _outer _inner _a' where the leading underscore avoids method name > collisions and is then stripped off in messageNotUnderstood. That doesn't > seem especially elegant though. > > I can't quite bring myself to write verbose things like > > ((aStruct child: #outer) child: #inner) child: #a > > An easy improvement might be to subclass your DwarfStruct from ProtoObject rather than Object to significantly reduce the surface area of name clashes. * https://github.com/pharo-project/pharo/blob/development/src/Kernel/ProtoObj… But I've not worked much with ProtoObject so I'm not sure what difficulties that might bring. In particular, can anyone comment on extra requirements to support object display in GT Inspector? A naming clash with the remaining ProtoObject methods seems extremely unlikely, and the easiest path would be to just guard against loading such structs. DwarfStruct>>loadStructure ... nameClashes := ProtoObject methodNames. self fieldnames do: [ :f | (nameClashes includes: f) ifTrue: [ self error: 'Seriously!? Your trying awful hard to break me' ] ] Just for the fun of it(!?) you might even try reducing that surface area by renaming that just in your personal Images by renaming ProtoObject methods. (Actually thats any interesting experiment I'll have to try later when I've got Pharo in front of me.) The only other thing I can think of is, presuming you've got a single class (e.g. DwarfStruct) holding the structure as data. for each loaded structure, generate "DwarfStruct subclass: CStruct1" and CStruct1>>fieldname so that method lookup stops at the first class and doesn't run all the way up the class hierarchy. But that would still be susceptible to breaking the system by overloading messages critical to system operation. cheers -ben

Dec. 3, 2017

Design pattern for wrapper/proxy objects?

by Luke Gorrie

Howdy, I have some Smalltalk objects that represent external data and I am looking for a neat way to access them. The data that I am dealing with is C binary objects described by DWARF schemas. So I will load a type declaration like this: struct outer { struct inner { int a, b; }; }; and then I will want to be able to write convenient expressions like: aStruct outer inner a + aStruct outer inner b I have implemented this already but I am not sure that I took the right approach. I have implemented these accessors like #outer #inner #a #b via a messageNotUnderstood: method that looks into the object, so that 'aStruct outer' is equivalent to 'aStruct field: #outer'. My concern is that the names of the C struct fields can collide with existing Smalltalk methods and then I will get totally unexpected results. Is there a canonical solution to this problem? The first idea I have is to add a bit of syntatic sugar, like to write 'aStruct _outer _inner _a' where the leading underscore avoids method name collisions and is then stripped off in messageNotUnderstood. That doesn't seem especially elegant though. I can't quite bring myself to write verbose things like ((aStruct child: #outer) child: #inner) child: #a

Dec. 3, 2017

Re: [Pharo-dev] [Vm-dev] FFI Struct Argument Pass By Value Fails on Mac 64 bit

by Ben Coman

On 27 November 2017 at 00:24, Todd Blanchard <tblanchard(a)mac.com> wrote: > > i'm getting the idea that we should probably write a test suite/library > for FFI > I noticed these... * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/ platforms/unix/plugins/SqueakFFIPrims/ffi-test-main.c * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/ Cog/platforms/Cross/plugins/SqueakFFIPrims/sqFFITestFuncs.c * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/ Cog/platforms/Cross/plugins/IA32ABI/AlienSUnitTestProcedures.c These look like c-code test frames for FFI. Could these be built by the OpenSmalltalk CI to be normally shipped with the VM so that Image-side CI can test against them? And also some general info... * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/ Cog/platforms/unix/plugins/SqueakFFIPrims/00README > > On Nov 24, 2017, at 12:54 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 24 November 2017 at 13:16, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On 22 November 2017 at 21:59, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On 22 November 2017 at 13:38, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> >>>> >>>> I've been trying to track this down for a couple weeks now. >>>> >>> >>>> I have concluded that structs passed by value to functions on the 64 >>>> bit VM are not properly populated. The struct's memory is all zero'd. >>>> >>>> I found this while trying to work with LibClang and found that >>>> functions that fetched code locations from code ranges always returned >>>> invalid zero'd locations. After spending some time with lldb I have traced >>>> the problem into the native code and found that the argument is not correct. >>>> >>>> I've carved out the wee bit of clang to reproduce this in a tiny >>>> library. >>>> >>>> The gist of it is below and the entire file is included. Basically the >>>> struct passed to the function clang_getRangeStart is zero'd memory >>>> regardless of the data I send from the image side. >>>> >>> My last analysis discovered something interesting about strings defined inside shared libraries being handled differently, but only later realised I had chased the wrong rabbit down the hole. I've now investigated the premise you actually poses, and I agree, that structs being zero is some cases. The attached zipfile containing libstruct.c a few comparison cases - three "good" layouts that work fine and one "bad" that mostly gets zeros but sometimes other weird numbers. There is a Makefile with three main targets: 1. make layout - statically compiles libstruct.c and runs produced a.out to display structure layouts 2. make run - downloads Pharo, starts it loading LibStruct.st , then you manually run LibStruct>>>LibStructTest>>#testStructs and observe structure values on console 3. make debug - starts LLDB to run Pharo with breakpoints pre-configured for when you run #testStructs. Note Pharo will freeze and you need to move to LLDB. Try these commands... frame variable call print_struct(&GoodStruct1_fmt, &aStruct) continue That works on Ubuntu 16.04 64 bit. You will need to tune it for OSX. clang and lldb are required. ================================ The offsets configured in the class variables of all ExternalStructs correctly matches that reported by the C code test frame results here... $ make layout clang -g libstruct.c ./a.out GoodStruct1: uint32_t:int1: 01 4 uint32_t:int2: 05 4 GoodStruct2: uint32_t:int1: 01 4 uint32_t:int2: 05 4 void*:ptr_data: 09 8 GoodStruct3: void*:ptr_data: 01 8 uint32_t:int1: 09 4 uint32_t:int2: 13 4 BadStruct: void*:ptr_data1: 01 8 void*:ptr_data2: 09 8 uint32_t:int1: 17 4 uint32_t:int2: 21 4 ================================ $ make run clang -g -o libstruct.so -shared -fPIC libstruct.c getpharo/pharo-vm/lib/pharo/5.0-201707201942/pharo getpharo/Pharo.image ../LibStruct.st Now manually browse to and run LibStruct>>>LibStructTest>>#testStructs LibStructTest>>testStructs |good1Struct good2Struct good3Struct badStruct | good1Struct := GoodStruct1 new int1: 2; int2: 3. good2Struct := GoodStruct2 new int1: 2; int2: 3; ptr_force_int: 4. good3Struct := GoodStruct3 new int1: 2; int2: 3; ptr_force_int: 4. badStruct := BadStruct new int1: 2; int2: 3; ptr_force_int1: 4; ptr_force_int1: 5. self assert: (LibStruct tryGood1: good1Struct) equals: 6. self assert: (LibStruct tryGood2: good2Struct) equals: 6. self assert: (LibStruct tryGood3: good3Struct) equals: 6. "Problem exposed in next line" self assert: (LibStruct tryBad: badStruct) equals: 6. which on console produces... GoodStruct1: uint32_t:int1: 01 4 = 02 00 00 00 uint32_t:int2: 05 4 = 03 00 00 00 GoodStruct2: uint32_t:int1: 01 4 = 02 00 00 00 uint32_t:int2: 05 4 = 03 00 00 00 void*:ptr_data: 09 8 = 04 00 00 00 00 00 00 00 GoodStruct3: void*:ptr_data: 01 8 = 04 00 00 00 00 00 00 00 uint32_t:int1: 09 4 = 02 00 00 00 uint32_t:int2: 13 4 = 03 00 00 00 BadStruct: void*:ptr_data1: 01 8 = 00 00 00 00 00 00 00 00 void*:ptr_data2: 09 8 = 00 00 00 00 00 00 00 00 uint32_t:int1: 17 4 = 29 03 03 00 uint32_t:int2: 21 4 = 00 00 00 00 Comparing GoodStruct3 and BadStruct, it seems one pointer is handled fine, but not two. The first time this is run after Image boots seems like BadStruct gets some random data. ================================ In same image, subsequent runs of LibStruct>>>LibStructTest>>testStructs give only all zeros for BadStruct, as Todd observed. GoodStruct1: uint32_t:int1: 01 4 = 02 00 00 00 uint32_t:int2: 05 4 = 03 00 00 00 GoodStruct2: uint32_t:int1: 01 4 = 02 00 00 00 uint32_t:int2: 05 4 = 03 00 00 00 void*:ptr_data: 09 8 = 00 00 00 00 00 00 00 00 GoodStruct3: void*:ptr_data: 01 8 = 00 00 00 00 00 00 00 00 uint32_t:int1: 09 4 = 02 00 00 00 uint32_t:int2: 13 4 = 03 00 00 00 BadStruct: void*:ptr_data1: 01 8 = 00 00 00 00 00 00 00 00 void*:ptr_data2: 09 8 = 00 00 00 00 00 00 00 00 uint32_t:int1: 17 4 = 00 00 00 00 uint32_t:int2: 21 4 = 00 00 00 00 cheers -ben

Dec. 3, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by Nicolas Cellier

It seems that the .travis_tests.sh all stalled for recent squeak versions of linux32x86 The build are then marked as failed and nothing uploaded on bintray. https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/309909223 For pharo-vm it seems to be a different problem when compiling libgit2 https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/309909228 opensmalltalk / linux32x86 deserves some more care... Too many failures for too much time! 2017-12-03 11:29 GMT+01:00 stephan <stephan(a)stack.nl>: > On 02-12-17 11:18, Thierry Goubier wrote: > >> Le 02/12/2017 Ã 11:00, stephan a Ã©crit : >> >>> On 01-12-17 21:21, Thierry Goubier wrote: >>> >>>> To avoid segfaults, I'm using one from November. >>>> >>> >>> Where does that come from? Or do you compile it yourself? >>> >> >> It comes from the bintray opensmalltalk folder. For example, >> >> https://bintray.com/opensmalltalk/vm/cog/201711061254#files >> >> I've never had much success compiling it myself. >> > > Ha. I found the latest in > https://bintray.com/opensmalltalk/vm/cog/201712010755#files > > But there is no 32 bit linux x86 pharo build there, only the 64 bit. > > Stephan > > >

Dec. 3, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by Thierry Goubier

Le 03/12/2017 Ã 11:29, stephan a Ã©critÂ : > On 02-12-17 11:18, Thierry Goubier wrote: >> Le 02/12/2017 Ã 11:00, stephan a Ã©critÂ : >>> On 01-12-17 21:21, Thierry Goubier wrote: >>>> To avoid segfaults, I'm using one from November. >>> >>> Where does that come from? Or do you compile it yourself? >> >> It comes from the bintray opensmalltalk folder. For example, >> >> https://bintray.com/opensmalltalk/vm/cog/201711061254#files >> >> I've never had much success compiling it myself. > > Ha. I found the latest in > https://bintray.com/opensmalltalk/vm/cog/201712010755#files > > But there is no 32 bit linux x86 pharo build there, only the 64 bit. Interesting: one only find the newspeak build there in linux x86 32bits (no pharo, no squeak builds). And it seems to have been the case for a little while. Thierry > Stephan > > >

Dec. 3, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by stephan

On 02-12-17 11:18, Thierry Goubier wrote: > Le 02/12/2017 Ã 11:00, stephan a Ã©critÂ : >> On 01-12-17 21:21, Thierry Goubier wrote: >>> To avoid segfaults, I'm using one from November. >> >> Where does that come from? Or do you compile it yourself? > > It comes from the bintray opensmalltalk folder. For example, > > https://bintray.com/opensmalltalk/vm/cog/201711061254#files > > I've never had much success compiling it myself. Ha. I found the latest in https://bintray.com/opensmalltalk/vm/cog/201712010755#files But there is no 32 bit linux x86 pharo build there, only the 64 bit. Stephan

Dec. 3, 2017

Garbage Collection (was Re: Discussing the roadmap)

by Ben Coman

Hi Eliot, Clement, On 7 July 2017 at 00:41, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > - Better support for large heaps (GC tuning API, incremental GC). > > Pharo 64 bit is now able to manage large heap. However better > > performance can be proposed by offering better settings for the > > different GC zone. > > The most important thing here is the incremental GC. Spur has a generation > scavenger that collects garbage in newly created objects (new space), > and a mark-compact collector that collects and compacts garbage in old space. > > Right now on my 2.3GHz MacMini doing normal development, the generation > scavenger causes pauses of 1ms or less, and the mark-compact collector > than causes pauses of around 200ms. Both account for about 0.75% of > entire execution time (1.5% total), so the scavenger is invoked frequently > and the pauses that it creates are not noticeable. But the occasional > pauses created by the mark-compact collector /are/ noticeable, > especially in games and music. > > The idea for the incremental collector is to implement a mark-sweep or > mark-sweep-compact collector for old space that works incrementally, > doing a little bit of work on each invocation, probably immediately after a scavenge. > It is intended to avoid the long pauses caused by the non-incremental > mark-compact collector and make the system more suitable for games, music, etc. Reading http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-re… "An alternative implementation, oft-used in Lisp systems, is to add a read barrier to all object access, and mark objects as forwarders. This can be used to implement a >>>lazy copying garbage collection<<<< where objects are copied from one semi-space to another in parallel to the main program (the âmutatorâ). To become, or move an object one replaces the objectâs header or first field with a forwarding pointer to the desired target or copy in a new location, marking the âcorpseâ as forwarded. The program checks the forwarded flag on each access. If there is hardware support, as in a Lisp machine, this can work well. But without hardware support, and like the object table representation, it has costs, slowing down program execution due to the scattering of forwarding checks and forwarding pointer follows throughout program execution." I'm curious... Given we now have forwarders with Spur, are we already sufficiently paying the cost of forwarding checks that a lazy copying garbage collector might be a feasible form of incremental garbage collection? I presume "parallel to the main program" means garbage collection occuring in a separate thread to the main vm thread, potentially resulting in very low main program pause times for garbage collection. I found this a useful summary of the terminology... * https://www.dynatrace.com/resources/ebooks/javabook/reduce-garbage-collecti… and I'm curious how our planned Incremental CG fits those categories. That article got me contemplating our performance constraint of the VM only operating in only in a single native thread. Even though GC is a only a few percent of performance, I wondered what a concurrent GC might look like for us. I found this video describing concurrent GC in Go (ignore first 11:20 and the second half was not so interesting) * https://pusher.com/sessions/meetup/the-realtime-guild/golangs-realtime-garb… where they present some interesting charts of their concern with latency pauses. (btw they reference a multi-language GC latency benchmark https://github.com/WillSewell/gc-latency-experiment) And for balance of that I found... https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e And then my mind wandered around implementation details of concurrent garbage collection. To organise and quiet my thoughts I needed to put pen to paper, so I thought sharing that might stir thoughts for others. Probably naive and please excuse the brain dump format... Considering two threads... * Main program thread "MP" * Garbage collection thread "GC" with object-space shared between them, consisting of objects split in object-header & object-body... 1. Only "MP" mutates the object-body, updating slots creating new edges in the object-graph, and relocating objects in memory using forwarders. This rule avoids potential race conditions without needing to add synchronisation code affecting performance of "MP". 2. Concurrently "GC" performs a Marking Phase by following the object-graph tricolour tagging objects gray & black. it needs to mutate the object-header, in a synchronised way something like... a. Load object-header from shared object-space into local variable H <== object-header b. Modify header into another local variable H' <== H + updated GC color bits c. Atomic compare-and-swap H' back into object-space object-header <== if H then H' "MP" gets priority. Conflicts presumed rare. Then considering object mutation by "MP" concurrent/overlapped with "GC" marking... 3. TLDR; see 4. In old-space if 'mutated' object is linked to a 'target' object a. if 'mutated' isBlack, "MP" marks 'target' gray (to be later processed by "GC"). b. if 'mutated' isGray, overlapped 'mutated' gray->black by "GC" while 'target' remains white would break tricolor invariant (is it a credible case?), options... i. mark 'target' gray, the state anyway in case 'mutated' gray -> black ii. re-mark 'mutated' gray, i.e. normally gray->gray, and rarely black->gray iii. optimisticly just check after mutation if color changed (cached reads cheaper than writes and conflicts presumed rare) then set color to gray. c. if 'mutated' isWhite, options... i. do nothing and let "GC" reach 'target' normally, as long as overlapped white->black cannot occur ii. if white->black possible, do same as (3.b) "MP" marks 'target' gray, to be later processed by "GC". 4. Overall simplification of (3.) might be... "MP" checks for any color change during mutation, and only then marks 'mutated' object gray. How expensive would such a check be? Presumed marking is infrequent and can be done safely like (2.) 5. Eden/survivor space is ignored by "GC" thread. No point in adding work to the gray set until survivors filtered. Stop the world scavenging done as normal by "MP", only marking objects gray when they are moved to old-space. Post scavenging options... a. Resume the world and leave it for "GC" to process these recently grayed objects. b. Keep world stopped for "MP" to complete marking, emptying gray set to transition to Sweep Phase, at which point "MP" resumes the world. It doesn't matter if subsequently objects are added to the gray set, since existing white objects can never again be referenced by "MP". 6. Sweeping can be safely done by "GC" since white-objects are unreachable from "MP". "GC" can also take time to determine an optimum page P to compact and then (per 1.) passes to "MP" via a relocation-queue the objects to be relocated using forwarding pointers. "GC" could even spend extra time to determine the optimum relocation-destination without impacting the performance of "MP". When "MP" empties the relocation-queue, "GC" starts on the next Marking Phase. 7. Now a question remains about multi-threaded flattening of forwarding pointers. If two threads simultaneously perform an identical transform from... someObject-slot --> forwarder-b --> finalObject-c to... someObject-slot --> finalObject-c does it matter that these operation may be done twice overlapping? Options... a. One mitigation could be for "GC" to identify forwarders to be flattened and queue them for "MP" to process (reuse the compaction-queue). This is work that "MP" would need to do anyway, but brings it forward to be dealt with at a convenient time. b. I guess "MP" and "GC" could play nice together if when encountering a slot containing with a forwarding pointer they both do something similar to (2.) like... i. Load object-slot from shared object-space into local variable S <== slot ii. Set local variable S' <== flattened/followed pointer iii. Atomic compare-and-swap S' back into object-space, (object-slot <== if S then S') - "MP" gets priority but presume conflicts rare anyway. - While this violates rule (1.) the presumed frequency of encountering forwarding pointers is low for "MP", so performance should not be affected. Indeed by "GC" pre-emptively flattening forwarders the frequency "MP" sees reduces. 8. The release of the compacted page back to the OS is held up by forwarding pointers. Forwarders are part of the graph followed in the Marking Phase they get marked gray/black just like objects if they are referenced. After forwarders are fully flattened they are skipped by Marking and end up marked white and released just like any other object. Once all forwarders are released, the page is released to the OS. If "GC" can effectively flatten pointers concurrently with "MP" during its normal Marking Phase, then pages would be released back to the OS in a timely manner. Now one thing I am curious about how the GC tri-color marking is implemented. At https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format it describes how Spur's object header has three bits for GC. * isGray * isRemembered * isMarked (I presume this means marked "black") Do the bits imply the gray set is not stored in a separate data structure on the heap, but rather distributed in-place, which I guess would require multiple passes through memory to grow the gray set? So this is not an area I'm set up to seriously work on, but I remain curious and hopefully its a useful seed discussion for others. cheers -ben P.S. At https://clementbera.wordpress.com/2017/09/19/vm-learning-memory-management/ nice to hear that you have Sophie (I presume) continuing with the VM.

Dec. 3, 2017

Re: [Pharo-dev] MCRepositoryError on System > Software update

by Alistair Grant

On 2 December 2017 at 17:26, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > As far as I know it doesn't work and hasn't worked for a long time. (Which > makes me wonder why it is still there.) > > Peter I think it was just no one took the time to remove it. Anyway, I can't find it in Pharo 7. Cheers, Alistair > On Sat, Dec 2, 2017 at 5:25 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> I assume that System > Software update can be used to update an Image from >> Pharo 6.0 to Pharo 6.1, correct? >> >> When I tried to update a Pharo 6.0 image (Latest update: #60499) using >> System > Software update I ran into the following error: >> Could not load BaselineOfFileTree-ThierryGoubier.32.mcz: >> ZnHttpUnsuccessful: 404 Not Found >> >> I tried it twice to make sure it was not some intermittent network error. >> >> Any help would be appreciated. >> >> Bernhard > >

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > should be "BlPostAction" - a valuable that is guaranteed to be evaluated > in the > beginning of every frame before anything else. That name and definition do not seem to fit to me. "Post" in what sense? Why is "action" more accurate than "animation"? Aliaksei Syrel wrote > and stops itself if element is no more in the scene graph *by checking > that explicitly before > doing every animation step*. I'd be interested in the performance cost of this approach, especially for an example like Squeak's infection modelling morphâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Aliaksei Syrel

I forgot to mention that "BlPostAction" is a one time action - it disappears once done :) Cheers, Alex On 2 December 2017 at 17:26, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > An object that is called now "Animation" in Bloc is not necessarily bound > to the visual element. > The correct name for the root class of "BlBaseAnimation" should be > "BlPostAction" - a valuable that is guaranteed to be evaluated in the > beginning of every frame before anything else. We have already a deferred > action but they are only evaluated when there is enough time between frames. > "BlBaseAnimation" should be renamed to something line "BlElementAnimation" > that is guaranteed to be bound to a visual element and stops itself if > element is no more in the scene graph *by checking that explicitly before > doing every animation step*. > > Cheers, > Alex > > On 2 December 2017 at 16:35, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Aliaksei Syrel wrote >> > ... >> > Also, what is the lifetime of an infinite animation? >> > ... >> > Do you have any particular use-case for animations? >> >> I hacked together a simplified stepping animation (may not be in the right >> place in the class hierarchy). Here's a pull request to discuss >> https://github.com/pharo-graphics/Bloc/pull/37 >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> >

Dec. 2, 2017

Re: [Pharo-dev] MCRepositoryError on System > Software update

by Peter UhnÃ¡k

As far as I know it doesn't work and hasn't worked for a long time. (Which makes me wonder why it is still there.) Peter On Sat, Dec 2, 2017 at 5:25 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > I assume that System > Software update can be used to update an Image from > Pharo 6.0 to Pharo 6.1, correct? > > When I tried to update a Pharo 6.0 image (Latest update: #60499) using > System > Software update I ran into the following error: > Could not load BaselineOfFileTree-ThierryGoubier.32.mcz: > ZnHttpUnsuccessful: 404 Not Found > > I tried it twice to make sure it was not some intermittent network error. > > Any help would be appreciated. > > Bernhard >

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Aliaksei Syrel

Hi, An object that is called now "Animation" in Bloc is not necessarily bound to the visual element. The correct name for the root class of "BlBaseAnimation" should be "BlPostAction" - a valuable that is guaranteed to be evaluated in the beginning of every frame before anything else. We have already a deferred action but they are only evaluated when there is enough time between frames. "BlBaseAnimation" should be renamed to something line "BlElementAnimation" that is guaranteed to be bound to a visual element and stops itself if element is no more in the scene graph *by checking that explicitly before doing every animation step*. Cheers, Alex On 2 December 2017 at 16:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Aliaksei Syrel wrote > > ... > > Also, what is the lifetime of an infinite animation? > > ... > > Do you have any particular use-case for animations? > > I hacked together a simplified stepping animation (may not be in the right > place in the class hierarchy). Here's a pull request to discuss > https://github.com/pharo-graphics/Bloc/pull/37 > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Dec. 2, 2017

MCRepositoryError on System > Software update

by Bernhard Pieber

I assume that System > Software update can be used to update an Image from Pharo 6.0 to Pharo 6.1, correct? When I tried to update a Pharo 6.0 image (Latest update: #60499) using System > Software update I ran into the following error: Could not load BaselineOfFileTree-ThierryGoubier.32.mcz: ZnHttpUnsuccessful: 404 Not Found I tried it twice to make sure it was not some intermittent network error. Any help would be appreciated. Bernhard

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > ... > Also, what is the lifetime of an infinite animation? > ... > Do you have any particular use-case for animations? I hacked together a simplified stepping animation (may not be in the right place in the class hierarchy). Here's a pull request to discuss https://github.com/pharo-graphics/Bloc/pull/37 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Tudor Girba

Hi Sean, The way I understand it is that the animation has to be stopped for the animation to be removed. If you make it to never stop, it will never be removed. Cheers, Doru > On Dec 2, 2017, at 3:37 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Aliaksei Syrel wrote >> Yes, after animation is stopped it is removed from the animation manager >> and if referenced weakly should be garbage collected. >> Otherwise it is a bug :) > > I changed the clock example code from `loop: 1` to `beInfinite` and opened a > bunch of clocks. > > Now, in a fresh playground: > <http://forum.world.st/file/t128965/Screenshot_2017-12-02_09.jpeg> > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > Yes, after animation is stopped it is removed from the animation manager > and if referenced weakly should be garbage collected. > Otherwise it is a bug :) I changed the clock example code from `loop: 1` to `beInfinite` and opened a bunch of clocks. Now, in a fresh playground: <http://forum.world.st/file/t128965/Screenshot_2017-12-02_09.jpeg> ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 2, 2017

Pharo Launcher endless loop opening debuggers in Pharo 6.1

by Bernhard Pieber

I ran into an annoying problem using the latest Pharo 6.1 (stable) from Pharo Launcher. I am on macOS Sierra Version 10.12.6. Steps to reproduce: 1. Open Pharo Launcher 2. Create new Pharo 6.1 (stable) image from the official distributions, named Test 3. Launch the Test image 4. Open a File Browser 5. Right click on the selected Test directory in the left file tree pane. 6. Debuggers start opening on KeyNotFound: key #arg4 not found in Dictionary 7. Image hangs Interestingly the problem does not happen if I create the image using âcurl get.pharo.org | bashâ and start it with â./pharo-ui Pharo.imageâ although About Pharo shows the same information: Pharo 6.0 Latest update: #60523 Can someone please confirm the bug? Bernhard

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Aliaksei Syrel

Hi Sean, Yes, after animation is stopped it is removed from the animation manager and if referenced weakly should be garbage collected. Otherwise it is a bug :) Cheers, Alex On 2 December 2017 at 04:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Aliaksei Syrel wrote > >> So one would change the `loop: 1` in your example to `beInfinite`? > > ... > > Also, what is the lifetime of an infinite animation? > > > > > > It can only be stopped by sending #stop to it. > > Is holding it weakly from the element and sending #stop enough for the > animation to be garbage collected? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Dec. 2, 2017

Re: [Pharo-dev] Bloc and Gestures

by Aliaksei Syrel

Hi Sean, The main problem of gestures is that they can only theoretically work with OS-Window (SDL2 or other windowing library). With morphic âI can not even find how to add support of horizontal scrolling using touchpad... For this reason those gestures are hierarchy placeholder and are not used anywhere. As for ETA ... 3 months maybe :) I think we will work on gestures as soon as bloc will officially supports SDL2 windows. Cheers, Alex

Dec. 2, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by Thierry Goubier

Le 02/12/2017 Ã 11:00, stephan a Ã©critÂ : > On 01-12-17 21:21, Thierry Goubier wrote: >> To avoid segfaults, I'm using one from November. > > Where does that come from? Or do you compile it yourself? It comes from the bintray opensmalltalk folder. For example, https://bintray.com/opensmalltalk/vm/cog/201711061254#files I've never had much success compiling it myself. Thierry > > Stephan > > > >

Dec. 2, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by stephan

On 01-12-17 21:21, Thierry Goubier wrote: > To avoid segfaults, I'm using one from November. Where does that come from? Or do you compile it yourself? Stephan

Dec. 2, 2017

Bloc and Gestures

by Sean P. DeNigris

I see a tantalizing hierarchy of BlGestureEvent and subclasses like BlGestureZoomEvent, but I can't seem to trap any. Are these working? If not, any ETA? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 2, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote >> So one would change the `loop: 1` in your example to `beInfinite`? > ... > Also, what is the lifetime of an infinite animation? > > > It can only be stopped by sending #stop to it. Is holding it weakly from the element and sending #stop enough for the animation to be garbage collected? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 2, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by Eliot Miranda

Hi Stephan, On Fri, Dec 1, 2017 at 10:52 AM, stephan <stephan(a)stack.nl> wrote: > On 01-12-17 18:56, Alistair Grant wrote: > >> On 01-12-17 11:16, stephan wrote: >>> >>>> Is the latest really from august? >>>> >>> I have: Date: Sun Aug 27 21:55:26 2017 +0200 >> > > So what happened in the past two months? Not sure if this is the kind of info you're looking for but... Not work has been done on the VM in the past few months. ClÃ©ment and Sophie have done some good work on JIT support for the replaceFrom:to:with:startingAt: that should be in the latest VMs. I have had some family issues that have taken me away from the VM but I am back now. I had broken the VM recently in adding a logging framework to monitor scavenges and Nicolas beat me to the fix. Holger has done some work on Openssl. _,,,^..^,,,_ best, Eliot

Dec. 1, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by Thierry Goubier

Le 01/12/2017 Ã 19:52, stephan a Ã©critÂ : > On 01-12-17 18:56, Alistair Grant wrote: >>> On 01-12-17 11:16, stephan wrote: >>>> Is the latest really from august? >> I have: Date: Sun Aug 27 21:55:26 2017 +0200 > > So what happened in the past two months? I don't know. To avoid segfaults, I'm using one from November. Thierry > > Stephan > > >

Dec. 1, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by stephan

On 01-12-17 18:56, Alistair Grant wrote: >> On 01-12-17 11:16, stephan wrote: >>> Is the latest really from august? > I have: Date: Sun Aug 27 21:55:26 2017 +0200 So what happened in the past two months? Stephan

Dec. 1, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by Alistair Grant

On 1 December 2017 at 18:49, stephan <stephan(a)stack.nl> wrote: > On 01-12-17 11:16, stephan wrote: >> >> Is the latest really from august? > > > Ping I have: Date: Sun Aug 27 21:55:26 2017 +0200 Cheers, Alistair

Dec. 1, 2017

Re: [Pharo-dev] Where is the latest linux vm?

by stephan

On 01-12-17 11:16, stephan wrote: > Is the latest really from august? Ping

Dec. 1, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by Martin Dias

Julien, I dodn't know it but anyway my issue was just in the step smalltalkhub -> filtree using the migration tool. Peter, yes it's public. This is the code I used: ---------------------------------------- migration := GitMigration on: 'MartinDias/Epicea'. migration cacheAllVersions. migration authors: { 'md' -> #('Martin Dias' '<tinchodias(a)gmail.com>'). 'MD' -> #('Martin Dias' '<tinchodias(a)gmail.com>'). 'MartinDias' -> #('Martin Dias' '<tinchodias(a)gmail.com>'). 'PabloTesone' -> #('Pablo Tesone' '<tesonep(a)gmail.com>'). 'PavelKrivanek' -> #('Pavel Krivanek' '<pavel.krivanek(a)gmail.com>'). 'DamienCassou' -> #('Damien Cassou' '<DamienCassou(a)gmail.com>'). 'DenisKudryashov' -> #('Denis Kudryashov' '<dionisiydk(a)gmail.com>'). 'GustavoSantos' -> #('Gustavo Santos' '<gugajansen(a)gmail.com>'). 'ThomasHeniart' -> #('Thomas Heniart' '<heniart.thomas(a)gmail.com>'). 'LucasGodoy' -> #('Lucas Godoy' '<godoy.lucas(a)gmail.com>'). 'StephaneDucasse' -> #('Stephane Ducasse' '<stephane.ducasse(a)inria.fr>'). 'VincentBlondeau' -> #('Vincent Blondeau' '<vincent.blondeau(a)inria.fr>'). 'AlbertoBacchelli' -> #('Alberto Bacchelli' '<sbackg(a)gmail.com>'). 'SkipLentz' -> #('Skip Lentz' '<skippetie(a)gmail.com>'). 'TheIntegrator' -> #('The Integrator' '<integrator(a)fake.com>'). }.l migration fastImportCodeToDirectory: 'src' initialCommit: '18a30d8d' to: './epicea-fast-import.txt' ---------------------- MartÃn On Thu, Nov 30, 2017 at 2:14 PM, Julien <julien.delplanque(a)inria.fr> wrote: > If you use Traits and want to have Epicea loadable from GitHub on Pharo > 6.1, it will not work. > > There is an issue when you try to load a Trait in Tonel format in the > image. > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille 1 > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq&entry=gmail&source=g> > Villeneuve > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq&entry=gmail&source=g> > d'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq&entry=gmail&source=g> > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > Le 6 nov. 2017 Ã 01:42, Martin Dias <tinchodias(a)gmail.com> a Ã©crit : > > Hi all, I'm considering to move Epicea (+Ombu+Hiedra) to github. I read > that tonel is the new format and there is Peter's git-migration, which > could be the tool to do it. > > Is it good idea to move now? > Is it the right tool? > > Bests, > MartÃn > > >

Dec. 1, 2017

[Pharo 7.0-dev] Build #355: 20800-do-not-open-welcome-window-for-now

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

There is a new Pharo build available! The status of the build #355 was: FAILURE. The Pull Request #568 was integrated: "20800-do-not-open-welcome-window-for-now" Pull request url: https://github.com/pharo-project/pharo/pull/568 Issue Url: https://pharo.fogbugz.com/f/cases/20800 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 1, 2017

[ANN] New Academic Partner: USI Software Institute

by Marcus Denker

The Pharo Consortium is very happy to announce that the Software Institute of the UniversitÃ della Svizzera italiana has joined as a Academic Partner. About - USI Software Institute: https://www.si.usi.ch <https://www.si.usi.ch/> - Pharo Consortium: http://consortium.pharo.org <http://consortium.pharo.org/> The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org <http://association.pharo.org/>

Dec. 1, 2017

Re: [Pharo-dev] Polymorphism between Strings and FileReference

by Cyril Ferlicot

On Fri, Dec 1, 2017 at 12:17 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Cyril, > > > Sorry, I misunderstood. > No problem :) > This looks like a good addition. Although is there any reason it > shouldn't be added to SequenceableCollection, where #readStream and > #writeStream are defined? > I agree. I talked about string because it is my use case but it's true it should be with #readStream/#writeStream. > Cheers, > Alistair > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 1, 2017

Re: [Pharo-dev] Polymorphism between Strings and FileReference

by Alistair Grant

Hi Cyril, On 1 December 2017 at 12:04, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Fri, Dec 1, 2017 at 11:55 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Cyril, >> >> The normal way to handle this is #asFileReference, so you can just have: >> >> aStringOrReference asFileReference readStreamDo: ... >> > > In that case, if it is a String like 'test', we will get a readStream > on the file './test' and not on the string 'test'. This is not what I > want. > > What I want is this for example: > > > > MyClass>>addComaAtTheEndOf: aStringOrFileReference > "If the argument is a String, add a coma at the end. If the > parameter is a file, add a coma at the end of its contents" > > aStringOrFileReference writeStreamDo: [ :s | s atEnd; nextPut: $, ] > > > > If I use your code, it will not add a coma at the end of the string > parameter, but at the end of the file represented by the string if it > exists. Sorry, I misunderstood. This looks like a good addition. Although is there any reason it shouldn't be added to SequenceableCollection, where #readStream and #writeStream are defined? Cheers, Alistair

Dec. 1, 2017

Re: [Pharo-dev] Polymorphism between Strings and FileReference

by Cyril Ferlicot

On Fri, Dec 1, 2017 at 11:55 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Cyril, > > The normal way to handle this is #asFileReference, so you can just have: > > aStringOrReference asFileReference readStreamDo: ... > In that case, if it is a String like 'test', we will get a readStream on the file './test' and not on the string 'test'. This is not what I want. What I want is this for example: MyClass>>addComaAtTheEndOf: aStringOrFileReference "If the argument is a String, add a coma at the end. If the parameter is a file, add a coma at the end of its contents" aStringOrFileReference writeStreamDo: [ :s | s atEnd; nextPut: $, ] If I use your code, it will not add a coma at the end of the string parameter, but at the end of the file represented by the string if it exists. > Cheers, > Alistair > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 1, 2017

[TechTalk] Topics Wanted for 2018!

by Marcus Denker

Hi, As you know, we are trying to have one Pharo tech-talk per month. The idea is to use this for -> mini âLecturesâ -> Demos of interesting Projects -> Just some interesting topic to discuss with audio chat on Discord You can see the past topics here: http://pharo.org/TechTalk <http://pharo.org/TechTalk> We will soon define the dates for the first half of 2018. If you want to do a techtalk yourself (give a presentation / Demo or moderate a discussion), feel free to contact me! You are able to pick a date that works best for you. Marcus

Dec. 1, 2017

Re: [Pharo-dev] Polymorphism between Strings and FileReference

by Alistair Grant

Hi Cyril, On 1 December 2017 at 11:50, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Hi, > > I am often in the case where I have a method taking a file or a string > as parameter and I often want to use #readStreamDo:/#writeStreamDo: in > the method because with I do not have to care if I need to close the > file stream or not with those. But since String do not understand > #readStreamDo:/#writeStreamDo: I cannot do that. > > Maybe it's worth to implement them on String? > > https://pharo.fogbugz.com/f/cases/20796/String-should-understand-readStream… > > Since it add methods to String I prefer talk about it on the mailing > list to have everyone's advice. The normal way to handle this is #asFileReference, so you can just have: aStringOrReference asFileReference readStreamDo: ... Cheers, Alistair

Dec. 1, 2017

Polymorphism between Strings and FileReference

by Cyril Ferlicot

Hi, I am often in the case where I have a method taking a file or a string as parameter and I often want to use #readStreamDo:/#writeStreamDo: in the method because with I do not have to care if I need to close the file stream or not with those. But since String do not understand #readStreamDo:/#writeStreamDo: I cannot do that. Maybe it's worth to implement them on String? https://pharo.fogbugz.com/f/cases/20796/String-should-understand-readStream… Since it add methods to String I prefer talk about it on the mailing list to have everyone's advice. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 1, 2017

Where is the latest linux vm?

by stephan

Is the latest really from august? Stephan

Dec. 1, 2017

[Pharo 7.0-dev] Build #354: 20786-halt-messages-are-not-highlighted-in-red-as-the-other-flavours-of-halt-messages

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

There is a new Pharo build available! The status of the build #354 was: SUCCESS. The Pull Request #564 was integrated: "20786-halt-messages-are-not-highlighted-in-red-as-the-other-flavours-of-halt-messages" Pull request url: https://github.com/pharo-project/pharo/pull/564 Issue Url: https://pharo.fogbugz.com/f/cases/20786 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 1, 2017

Re: [Pharo-dev] [ANN] files.pharo.org server move tomorrow, Nov 30

by Marcus Denker

I will check with Esteban when he is back! > On 29 Nov 2017, at 18:20, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Maybe a good occasion to fix opensmalltalk-vm :) > > i.e. https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/h8la5cg9fi2… <https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/h8la5cg9fi2…> > > /cygdrive/c/projects/vm/deploy/pharo > %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER/deploy/pharo; exec 0</dev/null; exec ./filter-exec.sh deploy-key.sh" > %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER; exec 0</dev/null; exec ./deploy/pharo/filter-exec.sh deploy-files.pharo.org.sh <http://deploy-files.pharo.org.sh/>" > Uploading ./pharo-win-x86_64-201711262336-8879e2e.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-201711262336-8879e2e.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 > > 2017-11-29 16:28 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > Hi, > > We will do the switch to the new server tomorrow, Nov 30. > > -> for people downloading, there should be no service intererruption > -> For *uploaders* (mostly CI jobs), you need new SSH credentials. > This means some upload jobs might break, but they will be easy > to fix > -> Uploading humans (people that scp to files.pharo.org <http://files.pharo.org/>): Talk to Christoph or me. > > Marcus >

Dec. 1, 2017

Re: [Pharo-dev] iceberg metacello integration not working?

by Tudor Girba

Hi, Thanks! This worked fine: Iceberg enableMetacelloIntegration: true. IceMetacelloPharoPlatform select. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. Cheers, Doru > On Dec 1, 2017, at 7:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > a regression, see: https://pharo.fogbugz.com/f/cases/20784/update-Metacello-since-last-update-… > in the meantime you can fix it by executing: > > IceMetacelloPharoPlatform select. > > Esteban > >> On 1 Dec 2017, at 07:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> In >> - a 60523 image, >> - with the latest stable VM (Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)) >> >> I am doing: >> Iceberg enableMetacelloIntegration: true. >> Metacello new >> baseline: 'GToolkit'; >> repository: 'github://feenkcom/gtoolkit/src'; >> load. >> >> The Iceberg window is empty (no repositories), and on the file system I have the github-cache folder filled with the downloaded code. >> >> Am I doing something wrong, or is this a regression? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> > -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."

Dec. 1, 2017

Re: [Pharo-dev] Newsletter content / editors wanted

by Julien

For the next one you could talk about the solutions created by the community for the Advent Of Code. They will be available there: https://github.com/juliendelplanque/AdventOfCode2017WithPharo <https://github.com/juliendelplanque/AdventOfCode2017WithPharo> --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 1 dÃ©c. 2017 Ã 09:15, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > Hi, > > You might know that we are sending out a monthly pharo newsletter, it contains larger > âmini articlesâ (e.g. announcements) and small one-line notes for blog posts, new libraries, > things like that. > > Here is the archive: > > https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=0486… <https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=0486…> > > Target audience are especially those who no follow the mailing list, but I think it is interesting > even for us as it is easy to not see all the interesting news. > > If you have content: please send it to me, I collect things over a month and then we put the > newletter together from that. > > This can be: > > - small (half page) articles abut *your* project! > - an interesting library you found > - a blog post you have written (or read) > > People can even take over for a complete month and do e.g. a themed newsletter focusing > on one aspect or project. > > Marcus

Dec. 1, 2017

[ANN] Pharo TechTalk Dec 19: Contributing to Pharo7

by Marcus Denker

Pharo TechTalk December 17: - 19 Dec 2017 5:00 PM - 7:00 PM (UTC+01:00) - Where? Discord / Youtube live Topic: Contributing. How to report bugs, submit code change. This will be a hands-on session where we show how to â¢ report bugs â¢ create pull requests â¢ help reviewing issues and pull requests https://association.pharo.org/event-2642666

Dec. 1, 2017

Newsletter content / editors wanted

by Marcus Denker

Hi, You might know that we are sending out a monthly pharo newsletter, it contains larger âmini articlesâ (e.g. announcements) and small one-line notes for blog posts, new libraries, things like that. Here is the archive: https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=0486… <https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=0486…> Target audience are especially those who no follow the mailing list, but I think it is interesting even for us as it is easy to not see all the interesting news. If you have content: please send it to me, I collect things over a month and then we put the newletter together from that. This can be: - small (half page) articles abut *your* project! - an interesting library you found - a blog post you have written (or read) People can even take over for a complete month and do e.g. a themed newsletter focusing on one aspect or project. Marcus

Dec. 1, 2017

Re: [Pharo-dev] [ANN] files.pharo.org server move tomorrow, Nov 30

by Marcus Denker

SSL certificate are now created and setup: https://files.pharo.org https://mooc.pharo.org https://lectures.pharo.org https://books.pharo.org https://get.pharo.org Marcus

Dec. 1, 2017

Re: [Pharo-dev] iceberg metacello integration not working?

by Esteban Lorenzano

a regression, see: https://pharo.fogbugz.com/f/cases/20784/update-Metacello-since-last-update-… <https://pharo.fogbugz.com/f/cases/20784/update-Metacello-since-last-update-…> in the meantime you can fix it by executing: IceMetacelloPharoPlatform select. Esteban > On 1 Dec 2017, at 07:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > In > - a 60523 image, > - with the latest stable VM (Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)) > > I am doing: > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > The Iceberg window is empty (no repositories), and on the file system I have the github-cache folder filled with the downloaded code. > > Am I doing something wrong, or is this a regression? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > >

Dec. 1, 2017

iceberg metacello integration not working?

by Tudor Girba

Hi, In - a 60523 image, - with the latest stable VM (Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)) I am doing: Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. The Iceberg window is empty (no repositories), and on the file system I have the github-cache folder filled with the downloaded code. Am I doing something wrong, or is this a regression? Cheers, Doru -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Dec. 1, 2017