- Pharo-dev - lists.pharo.org

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

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

by Nicolas Passerini

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. On Sun, Sep 4, 2016 at 10:10 AM, stepharo <stepharo(a)free.fr> wrote: > Hi denis > > I looked at senders of iconNamed: > > and when I see a Smalltalk ui icons iconNamed: I change it into self > iconNamed: when I can. > > May be I was also changing the superclass to be Model and this would be > the problem. > > It would be nice to have the possibility to get the list displayed not > following inheritance but > > just based on alphabetic name of classes. > > > Stef > > Le 4/9/16 Ã 10:05, Denis Kudriashov a Ã©crit : > > I can't reproduce (or I not see it) > Could you explain more? > > 2016-09-03 22:11 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi >> >> >> Often I look at senders and I modify them directly in the message browser >> and I do not one by one. >> >> Now when I recompile a method I get a new one and I lose the next one. >> >> Am I the only one to have this behavior. It is highly disrputing. >> >> Stef >> >> >> > >

Sept. 5, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] c0db47: 60199

by Marcus Denker

> > Log Message: > ----------- > 10025 MethodDictionary at:put: and #flushCache > https://pharo.fogbugz.com/f/cases/10025 > For this one we need to carefully check if there are bad side effects. it should work as now at:put: is the fall-back case and flushes by selector. (instead of clients having to do it explicitly) Marcus

Sept. 5, 2016

Re: [Pharo-dev] Iceberg Question

by Nicolas Passerini

Yes, it can be cryptic. It would be nice that we discuss which is the best vocabulary to use so that it is clear both for people with or without a strong git background. Iceberg does not have a "pull" operation, as it is intended from the git command line. Instead you have fetch and merge separately (remember: git pull = git fetch + git merge). In this way, you first download all new versions from the remote repository, you can browse them, and then you can decide to: a. Merge the remote changes into your local branch b. Load any version, without merging (which in git is called "detached head"). I thought this way (more similar to current Pharo tools than to the git command line) is better for our needs, but I could be wrong. Or we could have both. Also, one tricky thing here is that "incomming changes" could be two different things: - changes in the remote repository but not merged into your current branch. - changes in your current branch but not loaded into the image I am not sure how should be the best way to show that information. On Sun, Sep 4, 2016 at 8:56 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I have a question regarding the window: > > > Why if I want to retrieve the new versions, I need to press the button > âFetch new versionsâ. I think I should do a pull ? But instead, i can do a > load or a merge. A bit crypticâ¦ > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Sept. 5, 2016

Re: [Pharo-dev] Can Sound depend on Jobs?

by Guille Polito

The questions we should ask ourselves always: - Would it make sense to use Sound without Jobs? - Would it make sense to use Jobs without Sound? First, I just want to say I do not have the answer to that question because I do not know those packages very well. Butttt.... it's smelly to me. My reflex is to put that as a third package. Second and more meta, I think we should ask ourselves those questions more often (just like Sean did, thanks Sean! :D). -------- Original Message -------- > > 2016-09-05 9:55 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>>: > > Do you mean that job depends on sound? > > > I guess Sean wants put #beepAtEnd to Sound packageas Job extension. Is > such dependency valid?

Sept. 5, 2016