September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ObjectVirus is renamed to ObjectMutation

by Norbert Hartl

Thanks for doing it. I think this is a good move! Norbert > Am 05.09.2016 um 15:26 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi. > > Finally I made this change: ObjectVirus project is renamed to ObjectMutation. And all virus related words are now around word "mutate". > > Probably this metaphor is not good for some people but at least it has no negative impact which was mentioned here. > > Mocketry is adopted for new names too. > > Best regards, > Denis

Sept. 5, 2016

Re: [Pharo-dev] [ANN] Sparta v1.0

by Aliaksei Syrel

> > How does this handles accelerated graphics? Nice question :) There are 3 ways to create a canvas: 1) canvas for offscreen rendering. In this case it must be rasterized in order to be displayed on the screen. (requres pixel copying) 2) canvas for existing pixel buffer. In this case every draw operation directly manipulates pixels. For example there is a way to get a pointer to pixel buffer of SDL Window and create sparta canvas that would wrap it (no pixel copying required, very fast). 3) canvas for GL context. For example we could create an SDL window with OpenGL support, get GLContext and create canvas that would operate on it. (fast but a bit complicated). First way can result in either software or hardware rendering. For example on Mac users can choose one of the following backends: CoreGraphics CPU or CoreGraphics GPU, Skia CPU or Skia GPU and even Cairo. Second way does not allow to use GPU Accelerated backends, since canvas is created for pixel buffer. On Mac it is CoreGraphics CPU, Skia CPU or Cairo. Third way actually allows to create GPU accelerated canvas. For example Skia GPU renders everything using OpenGL. It is supported on all platforms: windows, linux, mac, android, iOS. The most simple way to create a new canvas is: > canvas := MozCanvas extent: 500@400. Behind the scenes it chooses the best backend for current platform: D2D1 on Windows, CoreGraphics on Mac and Skia+X11 mixture on Linux. Important to mention that Sparta allows developers to manually select which backend to use. Cheers, Alex On 5 September 2016 at 14:51, philippe.back(a)highoctane.be < philippe.back(a)gmail.com> wrote: > Sweet. > > How does this handles accelerated graphics? > > Phil > > Le 5 sept. 2016 11:52, "Aliaksei Syrel" <alex.syrel(a)gmail.com> a Ã©crit : > >> Hi >> >> I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6. >> https://github.com/syrel/Sparta/tree/v1.0 >> For a moment only Linux and Mac are supported. >> >> It can be bootstrapped with the following script: >> >> Metacello new >> baseline: 'Sparta'; >> repository: 'github://syrel/sparta:v1.0/src'; >> load: #file:core >> >> >> (on linux install 32bit libgtk-2, lingtk-3 and libstdc++) >> (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH) >> >> Sparta is an almost stateless vector graphics API for Pharo that provides >> bindings to the Moz2D rendering backend. Moz2D is the extracted graphical >> engine from Mozilla Firefox compiled as standalone shared library together >> with the extern C bindings required to call the engine from Pharo. >> >> - developed with the help of Iceberg >> <https://github.com/npasserini/iceberg> (thanks!) on Github. >> - integrated into travis-ci <https://travis-ci.org/syrel/Sparta> using >> smalltalkCI <https://github.com/hpi-swa/smalltalkCI> (great job!). >> - documented using Pillar <https://github.com/pillar-markup/pillar> (so >> better!) syntax. >> >> Cheers, >> Alex >> >

Sept. 5, 2016

Re: [Pharo-dev] [Ann] New Seamless version 0.9.0

by philippe.back＠highoctane.be

What is TostSerializer ? Le 5 sept. 2016 15:19, "Denis Kudriashov" <dionisiydk(a)gmail.com> a Ã©crit : > Hi, > > I released new version of Seamless 0.9.0. > It is based on specialized TostSerializer instead of Fuel. > > This version is ~4 times faster than previous one and produce much compact > data packets. > For example Fuel based version takes 400 bytes to return small integer as > result of message send. Now it is just 21 bytes. > > Pharo 5 and 6 are supported. >

Sept. 5, 2016

Re: [Pharo-dev] [Ann] New Seamless version 0.9.0

by Denis Kudriashov

And here is working script to load it: Metacello new smalltalkhubUser: 'Pharo' project: âSeamless'; configuration: âSeamless'; version: #stable; load Loading by Gofer or directly by configuration is not working now (it is really strange) 2016-09-05 15:18 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi, > > I released new version of Seamless 0.9.0. > It is based on specialized TostSerializer instead of Fuel. > > This version is ~4 times faster than previous one and produce much compact > data packets. > For example Fuel based version takes 400 bytes to return small integer as > result of message send. Now it is just 21 bytes. > > Pharo 5 and 6 are supported. >

Sept. 5, 2016

ObjectVirus is renamed to ObjectMutation

by Denis Kudriashov

Hi. Finally I made this change: ObjectVirus project is renamed to ObjectMutation. And all virus related words are now around word "mutate". Probably this metaphor is not good for some people but at least it has no negative impact which was mentioned here. Mocketry is adopted for new names too. Best regards, Denis

Sept. 5, 2016

[Ann] New Seamless version 0.9.0

by Denis Kudriashov

Hi, I released new version of Seamless 0.9.0. It is based on specialized TostSerializer instead of Fuel. This version is ~4 times faster than previous one and produce much compact data packets. For example Fuel based version takes 400 bytes to return small integer as result of message send. Now it is just 21 bytes. Pharo 5 and 6 are supported.

Sept. 5, 2016

strange FFI behaviour? (or lack of understanding?)

by Ben Coman

Is it a **requirement** that FFI calls have a method all to themselves like a primitive call? I have this definition... FFIExternalStructure subclass: #CXString CXString class>>fieldsDesc ^ #( void *data; uint private_flags; ) The instance returned by this... Xxxx>>getClangVersion ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang has private_flags=1 indicating the library allocated external memory for *data and to release this I need to call clang_disposeString( CXString string). However this doesn't guard against being called twice and double-free()'ing CXString crashing the VM, so I defined the following... CXString>>dispose self inform: 'debug_dispose1'. self private_flags = 1 ifTrue: [ self inform: 'debug_dispose2'. self private_flags: 0. self ffiCall: #( void clang_disposeString ( CXString self ) ) module: Libclang ] ifFalse: [ self inform: 'debug_dispose3'. Error signal: 'Cannot dispose twice' ]. However something strange, dispose will only execute once. For example for... s := Libclang getClangVersion. s dispose. "==>debug_dispose1, debug_dispose2" s dispose. "==>nothing at all" I would expect the second call to dispose to result it "==>debug_dispose1, debug_dispose3" but it does nothing at all. Debugging into "S dispose" displays the source of dispose and then returns without executing anything. The image seems fine and displays the updated zero in private_flags -- at least for a few minutes, then it might crash indicating the clang_disposeString() has been called twice. However it works if I separate out the FFI call to a separate method... CXString>>unsafeDispose self ffiCall: #( void clang_disposeString ( CXString self ) ) module: Libclang CXString>>dispose self inform: 'dispose1'. self private_flags = 1 ifTrue: [ self inform: 'dispose2'. self private_flags: 0. self unsafeDispose. ] ifFalse: [ self inform: 'dispose3'. Error signal: 'Cannot dispose twice' ]. s := Libclang getClangVersion. s dispose. "==>debug_dispose1, debug_dispose2" s dispose. "==>debug_dispose1, debug_dispose3" s dispose. "==>debug_dispose1, debug_dispose3" s dispose. "==>debug_dispose1, debug_dispose3" Can someone hazard a guess what is behind this behaviour? I would prefer not to require the unguarded #unsafeDispose. cheers -ben

Sept. 5, 2016

Re: [Pharo-dev] [ANN] Sparta v1.0

by philippe.back＠highoctane.be

Sweet. How does this handles accelerated graphics? Phil Le 5 sept. 2016 11:52, "Aliaksei Syrel" <alex.syrel(a)gmail.com> a Ã©crit : > Hi > > I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6. > https://github.com/syrel/Sparta/tree/v1.0 > For a moment only Linux and Mac are supported. > > It can be bootstrapped with the following script: > > Metacello new > baseline: 'Sparta'; > repository: 'github://syrel/sparta:v1.0/src'; > load: #file:core > > > (on linux install 32bit libgtk-2, lingtk-3 and libstdc++) > (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH) > > Sparta is an almost stateless vector graphics API for Pharo that provides > bindings to the Moz2D rendering backend. Moz2D is the extracted graphical > engine from Mozilla Firefox compiled as standalone shared library together > with the extern C bindings required to call the engine from Pharo. > > - developed with the help of Iceberg > <https://github.com/npasserini/iceberg> (thanks!) on Github. > - integrated into travis-ci <https://travis-ci.org/syrel/Sparta> using > smalltalkCI <https://github.com/hpi-swa/smalltalkCI> (great job!). > - documented using Pillar <https://github.com/pillar-markup/pillar> (so > better!) syntax. > > Cheers, > Alex >

Sept. 5, 2016

[ANN] Sparta v1.0

by Aliaksei Syrel

Hi I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6. https://github.com/syrel/Sparta/tree/v1.0 For a moment only Linux and Mac are supported. It can be bootstrapped with the following script: Metacello new baseline: 'Sparta'; repository: 'github://syrel/sparta:v1.0/src'; load: #file:core (on linux install 32bit libgtk-2, lingtk-3 and libstdc++) (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH) Sparta is an almost stateless vector graphics API for Pharo that provides bindings to the Moz2D rendering backend. Moz2D is the extracted graphical engine from Mozilla Firefox compiled as standalone shared library together with the extern C bindings required to call the engine from Pharo. - developed with the help of Iceberg <https://github.com/npasserini/iceberg> (thanks!) on Github. - integrated into travis-ci <https://travis-ci.org/syrel/Sparta> using smalltalkCI <https://github.com/hpi-swa/smalltalkCI> (great job!). - documented using Pillar <https://github.com/pillar-markup/pillar> (so better!) syntax. Cheers, Alex

Sept. 5, 2016

Re: [Pharo-dev] Message browser strange new behavior

by Denis Kudriashov

2016-09-05 11:42 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: > I agree, it is sometimes difficult to find a class in the message browser > because of the inheritance organization. > I think that most often I do not want that, but also it might be useful in > other circunstances, so maybe the best would be to have both possibilities > and make is easy to change from one to the other. > Now there is filter field in message browser. And maybe it will be not an issue anymore

Sept. 5, 2016