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