[Pharo-dev] Object>>#pinInMemory performance

Hello I stumbled across a performance issue when pinning objects in memory. Below I have two scripts that pin and unpin a byte array (or any object) 20k times. The first script pins each time a new byte array: > [ 2 timesRepeat: [ > | array wasPinned | > array := ByteArray new. >

Re: [Pharo-dev] object pinning versus garbage collection

On Sun, Sep 25, 2016 at 7:14 AM, Eliot Miranda wrote: > Hi Ben, > >> On Sep 23, 2016, at 8:17 PM, Ben Coman wrote: >> >> How does object pinning interact with garbage collection? Does it >> block garbage collection until it is manually unpinned?

Re: [Pharo-dev] object pinning versus garbage collection

Hi Ben, > On Sep 23, 2016, at 8:17 PM, Ben Coman wrote: > > How does object pinning interact with garbage collection? Does it > block garbage collection until it is manually unpinned? Or does it > garbage collection proceed anyway? Intuitively I'd guess the former??

[Pharo-dev] object pinning versus garbage collection

How does object pinning interact with garbage collection? Does it block garbage collection until it is manually unpinned? Or does it garbage collection proceed anyway? Intuitively I'd guess the former?? cheers -ben

Re: [Pharo-dev] Object>>rollToArity:?

I’m not happy with the method name, but I think is well explained in method comments: ExternalAddress>>rollToArity: arity "This will 'roll' a pointer to a certain arity. What does this means? Let's say I have a method who will be called with a ** arity:

[Pharo-dev] Object>>rollToArity:?

Esteban, What Object>>rollToArity: is supposed to do? It belongs to UnifiedFFI Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Object graph stream/visitor implementation?

Hi, Indeed, DeepTraverser is the project to look at. I started it from the code of Mariano, and then Stefan Rechhart reimplemented it from scratch to make it very fast (e.g. traversing subclasses of a class is only 10% slower than the hard coded withAllSubclassesDo:) and to make it work like a

Re: [Pharo-dev] Object graph stream/visitor implementation?

I managed to get per object substitution callbacks working in Mushroom. Please take a look in http://www.squeaksource.com/Mushroom and load Mushr00m-Pharo on top of MushrOOm (after installing Cryptography and SecureSession from http://www.squeaksource.com/Cryptography). Then look at the

Re: [Pharo-dev] Object graph stream/visitor implementation?

I'm sorry, this is with Fuel loaded. These are extensions to Fuel serialization and materialization. b, robert On 12/22/2015 03:55 AM, Robert Withers wrote: I managed to get per object substitution callbacks working in Mushroom. Please take a look in http://www.squeaksource.com/Mushroom

Re: [Pharo-dev] Object graph stream/visitor implementation?

> On 22 Dec 2015, at 09:46, Denis Kudriashov wrote: > > Hello. > > Do we have way to traverse object graph? > > I want stream which iterate object graph through instance variables with > knowledge about path at every step. > > Maybe Fuel has classes for this ? > yes,

Re: [Pharo-dev] Object graph stream/visitor implementation?

I found this: http://smalltalkhub.com/#!/~Moose/DeepTraverser 2015-12-22 10:05 GMT+01:00 Marcus Denker : > > > On 22 Dec 2015, at 09:46, Denis Kudriashov wrote: > > > > Hello. > > > > Do we have way to traverse object graph? > > > > I want stream

[Pharo-dev] Object graph stream/visitor implementation?

Hello. Do we have way to traverse object graph? I want stream which iterate object graph through instance variables with knowledge about path at every step. Maybe Fuel has classes for this ? Best regards, Denis

Re: [Pharo-dev] Object graph stream/visitor implementation?

Denis, The DeepTraverser was a little easy hack I shared years ago to Tudor Girba which he then (improved it?) put it in Moose. While it works is still very limited. You can give it a try. And if not, please spend some time checking the graph traverser we have in Fuel. I suspect it could be

Re: [Pharo-dev] Object #is:

On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote: On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote: the isBlah is not optimal now it is just there and we cannot rewrite everything. I still think that is: is a nice way to kill some of the

Re: [Pharo-dev] Object #is:

On 25 June 2013 10:51, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 25, 2013, at 10:47 AM, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 10:28, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote: On

Re: [Pharo-dev] Object #is:

On Jun 25, 2013, at 10:54 AM, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 10:51, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 25, 2013, at 10:47 AM, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 10:28, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 24,

Re: [Pharo-dev] Object #is:

On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote: On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote: On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote: the isBlah is not

Re: [Pharo-dev] Object #is:

On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote: On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote: On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote: the isBlah is not optimal

Re: [Pharo-dev] Object #is:

On 25 June 2013 11:54, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote: On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote: On 2013-06-24, at 18:55, Stéphane

Re: [Pharo-dev] Object #is:

But in some cases, you will end up with an object that is more than one thing: - a Number - an Integer - a Fraction For example 0 shall answer yes to these 3. So ^foo == #specialName just does not work, or you end up with caseOf: 2013/6/25 Igor Stasenko siguc...@gmail.com On 25 June 2013

Re: [Pharo-dev] Object #is:

On 25 June 2013 12:47, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: But in some cases, you will end up with an object that is more than one thing: - a Number - an Integer - a Fraction For example 0 shall answer yes to these 3. So ^foo == #specialName just does not work, or you

Re: [Pharo-dev] Object #is:

On 25 June 2013 12:59, Camille Teruel camille.ter...@gmail.com wrote: On 25 juin 2013, at 11:45, Igor Stasenko wrote: On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote: On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: On Jun 24, 2013, at 6:59 PM, Camillo Bruni

Re: [Pharo-dev] Object #is:

I really cannot believe that you can consider is: #string better programing than isString no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol programing) is just bad, bad, bad. Is so bad that is axiomatic... I cannot even

Re: [Pharo-dev] Object #is:

On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote: I really cannot believe that you can consider is: #string better programing than isString no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol

Re: [Pharo-dev] Object #is:

On Jun 25, 2013, at 1:36 PM, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote: I really cannot believe that you can consider is: #string better programing than isString no matter the implementation, and no matter if you can

Re: [Pharo-dev] Object #is:

I agree with Esteban here, I think we just have to agree to disagree :) To me as well, is: #Number reads 100x worse than isNumber. On Jun 25, 2013, at 12:33 PM, Igor Stasenko wrote: In general, the more methods we put into Object, the higher probability of name clashing (two projects using

Re: [Pharo-dev] Object #is:

On 25 June 2013 14:21, Henrik Johansen henrik.s.johan...@veloxit.no wrote: I agree with Esteban here, I think we just have to agree to disagree :) To me as well, is: #Number reads 100x worse than isNumber. On Jun 25, 2013, at 12:33 PM, Igor Stasenko wrote: In general, the more methods we

Re: [Pharo-dev] Object #is:

On 2013-06-25, at 14:35, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 14:00, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 25, 2013, at 1:36 PM, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote: I really cannot

Re: [Pharo-dev] Object #is:

On 25 juin 2013, at 13:22, Igor Stasenko wrote: On 25 June 2013 12:59, Camille Teruel camille.ter...@gmail.com wrote: On 25 juin 2013, at 11:45, Igor Stasenko wrote: On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote: On 25 juin 2013, at 10:28, Esteban Lorenzano

Re: [Pharo-dev] Object #is:

On 25 June 2013 14:54, Camillo Bruni camillobr...@gmail.com wrote: On 2013-06-25, at 14:35, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013 14:00, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 25, 2013, at 1:36 PM, Igor Stasenko siguc...@gmail.com wrote: On 25 June 2013

Re: [Pharo-dev] Object #is:

Except that arithmetic on Fraction isExact, or should I say is: #exact, while on Float is not, so definitely a Float is not a Fraction, even if its internal representation is a Fraction. 2013/6/25 Igor Stasenko siguc...@gmail.com On 25 June 2013 13:34, Nicolas Cellier

Re: [Pharo-dev] Object #is:

On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote: Just remove it :) Doru Alternatively, start using it, and remove the rest of the is* methods on Object, which was the initial intent :P Of course, there's a tradeoff between locality of implementation and discoverability with (default)

Re: [Pharo-dev] Object #is:

I never liked it, so I vote for removal :) On Jun 24, 2013, at 11:27 AM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote: Just remove it :) Doru Alternatively, start using it, and remove the rest of the is* methods on Object,

Re: [Pharo-dev] Object #is:

But I hate more isPlague in Object. Stef On Jun 24, 2013, at 12:55 PM, Esteban Lorenzano esteba...@gmail.com wrote: I never liked it, so I vote for removal :) On Jun 24, 2013, at 11:27 AM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Jun 23, 2013, at 10:08 PM, Tudor Girba

Re: [Pharo-dev] Object #is:

On 2013-06-24, at 18:41, Stéphane Ducasse stephane.duca...@inria.fr wrote: But I hate more isPlague in Object. I think that plage mostly arises when people do not like to use Visitors / DoubleDispatch. Conceptually the #is: message IS exactly the same, instead of doing a dynamic dispatch

Re: [Pharo-dev] Object #is:

the isBlah is not optimal now it is just there and we cannot rewrite everything. I still think that is: is a nice way to kill some of the isPlague in Object. Stef But I hate more isPlague in Object. I think that plage mostly arises when people do not like to use Visitors /

[Pharo-dev] Object #is:

can we remove that, or is this still in use?

Re: [Pharo-dev] Object #is:

On 23 Jun 2013, at 18:14, Camillo Bruni camillobr...@gmail.com wrote: can we remove that, or is this still in use? Hmm, no senders, no implementors, but the idea is not bad: it could replace a lot of methods. And it bears the signature of some illustrious hackers… Sven

Re: [Pharo-dev] Object #is:

Except that if an object both is: this and is: that, from two different packages, this will lead to an override. 2013/6/23 Sven Van Caekenberghe s...@stfx.eu On 23 Jun 2013, at 18:14, Camillo Bruni camillobr...@gmail.com wrote: can we remove that, or is this still in use? Hmm, no

Re: [Pharo-dev] Object #is:

On 2013-06-23, at 19:19, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Except that if an object both is: this and is: that, from two different packages, this will lead to an override. from which package? #is: doesn't seem to be used in general 2013/6/23 Sven Van Caekenberghe

Re: [Pharo-dev] Object #is:

Actually, a better implementation would be: Objectis: aClassOrSymbol ^ aClassOrSymbol asString = self class name asString Like this you can even pass the class instead of its name (I presume that printOn: will not change any time soon so we can rely on the fact that we can polymorphically

Re: [Pharo-dev] Object#if:then:else:

Le 18/06/2013 18:53, Camille Teruel a écrit : #someRandomObject if: then: else: thinking of doing a C style condition and not using at all the receiver. Come on, people are not that stupid ! And if they really are, no matter what you do, they will write bad code eventually. It is not a

[Pharo-dev] Object#if:then:else:

Hello everyone. I see a lot of code that follows the following pattern: a long expression aComplexTest ifTrue: [ a long expression something ] ifFalse: [ a long expression something else ]. The classic refactoring is to store a long expression in a temp to avoid repetition: | temp |

Re: [Pharo-dev] Object#if:then:else:

is it not slower? and I would remove as much as method as possible from Object. why | temp | temp := a long expression. temp aComplexTest ifTrue: [ temp something ] ifFalse: [ temp something else ]. is not good enough? And finally we should kill as much as possible of these if….

Re: [Pharo-dev] Object#if:then:else:

Hi Camille, It's not bad as things goes, because it does look a bit like non-smalltalk code (i.e. the if then else structure) except that the precise meaning is very much Smalltalk : if: has a receiver, and there is a not so intuitive relationship between the bloc parameters and the

Re: [Pharo-dev] Object#if:then:else:

On 18 juin 2013, at 11:20, Goubier Thierry wrote: Hi Camille, It's not bad as things goes, because it does look a bit like non-smalltalk code (i.e. the if then else structure) except that the precise meaning is very much Smalltalk : Ok the name may be confusing. So if you rename it to

Re: [Pharo-dev] Object#if:then:else:

Le 18/06/2013 12:27, Camille Teruel a écrit : On 18 juin 2013, at 11:20, Goubier Thierry wrote: Hi Camille, It's not bad as things goes, because it does look a bit like non-smalltalk code (i.e. the if then else structure) except that the precise meaning is very much Smalltalk : Ok the

Re: [Pharo-dev] Object#if:then:else:

It feels to me as if this code wants to be on the temp. So perhaps, | temp | temp := a long expression. temp aComplexTest ifTrue: [ temp something ] ifFalse: [ temp something else ]. can become a long expression doSomething and on Temp: doSomething self aComplexTest

Re: [Pharo-dev] Object#if:then:else:

ifEvaluatesToTrueUsing sounds like an overkill to me and unnecessary , its common convention in all popular languages than an if always needs to evaluate to true to execute and if it evaluates to false then else handles it. -- View this message in context: http://forum.world.st/Pharo-dev

Re: [Pharo-dev] Object#if:then:else:

Very few things are truly necessary in life, programming languages are not amongst them. As I said , for me how already things work in pharo is fine concerning ifTrue: and friends . -- View this message in context: http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693952.html

Re: [Pharo-dev] Object#if:then:else:

Very few things are truly necessary in life, programming languages are not amongst them. As I said , for me how already things work in pharo is fine concerning ifTrue: and friends . -- View this message in context: http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693952.html

Re: [Pharo-dev] Object#if:then:else:

...@yahoo.co.uk Very few things are truly necessary in life, programming languages are not amongst them. As I said , for me how already things work in pharo is fine concerning ifTrue: and friends . -- View this message in context: http://forum.world.st/Pharo-dev-Object-if-then-else