- Pharo-dev - lists.pharo.org

Re: [Pharo-project] P2P library in Smalltalk

by StÃ©phane Ducasse

> Hi guys >> >> is there a library for doing P2P in Smalltalk? >> > > Peer to Peer in which sense? > > Data transfer? Yes It would be fun to see if we could replicate all the mcz files we all have in our caches.

Oct. 13, 2011

Re: [Pharo-project] P2P library in Smalltalk

by Marcus Denker

On Oct 13, 2011, at 4:46 PM, StÃ©phane Ducasse wrote: > Hi guys > > is there a library for doing P2P in Smalltalk? > Peer to Peer in which sense? Data transfer? Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 13, 2011

[Pharo-project] P2P library in Smalltalk

by StÃ©phane Ducasse

Hi guys is there a library for doing P2P in Smalltalk? Stef

Oct. 13, 2011

Re: [Pharo-project] BUG on converting to Fraction

by StÃ©phane Ducasse

thanks you http://code.google.com/p/pharo/issues/detail?id=4909 Stef On Oct 13, 2011, at 2:39 PM, Norberto Manzanos wrote: > On both Squeak 3.9 (I supose others too) and Pharo: > Fraction readFromString: '1/2' ---> 1 > '1/2' asNumber ---> 1 > > fix > > Number #readFrom: stringOrStream > "Answer a number as described on aStream. The number may > include a leading radix specification, as in 16rFADE" > | value base aStream sign | > aStream _ (stringOrStream isString) > ifTrue: [ReadStream on: stringOrStream] > ifFalse: [stringOrStream]. > (aStream nextMatchAll: 'NaN') ifTrue: [^ Float nan]. > sign _ (aStream peekFor: $-) ifTrue: [-1] ifFalse: [1]. > (aStream nextMatchAll: 'Infinity') ifTrue: [^ Float infinity * sign]. > base _ 10. > value _ Integer readFrom: aStream base: base. > "this line " > (aStream peekFor: $/) ifTrue:[^Fraction numerator: value denominator: (aStream upTo: $\) asInteger]. > " added " > (aStream peekFor: $r) > > ifTrue: > ["<base>r<integer>" > (base _ value) < 2 ifTrue: [^self error: 'Invalid radix']. > (aStream peekFor: $-) ifTrue: [sign _ sign negated]. > value _ Integer readFrom: aStream base: base]. > ^ self readRemainderOf: value from: aStream base: base withSign: sign. > > -- > Norberto Manzanos > Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS) > FaHCE/UNLP - CONICET > Calle 48 e/ 6 y 7 s/NÂº - 8Âº piso - oficina 803 > Tel: +54-221-4230125 interno 262

Oct. 13, 2011

[Pharo-project] BUG on converting to Fraction

by Norberto Manzanos

On both Squeak 3.9 (I supose others too) and Pharo: Fraction readFromString: '1/2' ---> 1 '1/2' asNumber ---> 1 fix Number #readFrom: stringOrStream "Answer a number as described on aStream. The number may include a leading radix specification, as in 16rFADE" | value base aStream sign | aStream _ (stringOrStream isString) ifTrue: [ReadStream on: stringOrStream] ifFalse: [stringOrStream]. (aStream nextMatchAll: 'NaN') ifTrue: [^ Float nan]. sign _ (aStream peekFor: $-) ifTrue: [-1] ifFalse: [1]. (aStream nextMatchAll: 'Infinity') ifTrue: [^ Float infinity * sign]. base _ 10. value _ Integer readFrom: aStream base: base. "this line " (aStream peekFor: $/) ifTrue:[^Fraction numerator: value denominator: (aStream upTo: $\) asInteger]. " added " (aStream peekFor: $r) ifTrue: ["<base>r<integer>" (base _ value) < 2 ifTrue: [^self error: 'Invalid radix']. (aStream peekFor: $-) ifTrue: [sign _ sign negated]. value _ Integer readFrom: aStream base: base]. ^ self readRemainderOf: value from: aStream base: base withSign: sign. -- Norberto Manzanos Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS) FaHCE/UNLP - CONICET Calle 48 e/ 6 y 7 s/NÂº - 8Âº piso - oficina 803 Tel: +54-221-4230125 interno 262

Oct. 13, 2011

Re: [Pharo-project] Pharo Consortium News: let's make it real.

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > we will now set up a consortium for pharo. > Very cool. I'm in! Sean -- View this message in context: http://forum.world.st/Pharo-Consortium-News-let-s-make-it-real-tp3891453p39… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 13, 2011

Re: [Pharo-project] About ~= and ~~

by Eliot Miranda

2011/10/12 Levente Uzonyi <leves(a)elte.hu> > On Thu, 13 Oct 2011, Igor Stasenko wrote: > > On 12 October 2011 23:22, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Wed, 12 Oct 2011, Mariano Martinez Peck wrote: >>> >>> On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>> On Wed, 12 Oct 2011, Clara Allende wrote: >>>>> >>>>> Hi guys, >>>>> >>>>>> >>>>>> I'm wondering, why? >>>>>> >>>>>> ProtoObject>> ~~ anObject >>>>>> "Answer whether the receiver and the argument are not the same object >>>>>> (do not have the same object pointer)." >>>>>> >>>>>> self == anObject >>>>>> ifTrue: [^ false] >>>>>> ifFalse: [^ true] >>>>>> >>>>>> >>>>>> Hi Carla. I can think about two things. The first one, is the one >>>> Levente >>>> said, performance. >>>> If you analyze the bycode of this method, you will see that it is >>>> extremely >>>> fast because: >>>> >>>> 1) #== has an special associated bytecode, that is, them VM maps such >>>> bytecode to an specific primitive and it is directly executed. It means >>>> that >>>> the method #== is really never sent. >>>> 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, >>>> it >>>> method is never executed and instead the compiler replace a message send >>>> bytecode with jump ones. >>>> >>>> Another possible reason (it may not be the case, but in another places >>>> it >>>> is), is to prevent VM interruption for check other processes. In >>>> summary, >>>> the VM checks whether it should execute another process of the queue >>>> after >>>> a >>>> method execution. As you know, some parts of the scheduling process is >>>> done >>>> at the image side. And from there we lack a way to say to the VM, >>>> "please >>>> execute this method without checking others processes". Hence, in a few >>>> yet >>>> very specific places of PRocess, Scheduler, Semaphore, etc, #== is used >>>> as >>>> a >>>> mean of executing something WITHOUT being interrupted. I can imagine >>>> that >>>> it >>>> may happen the same with #~~. So if you implement such method with a >>>> #not, >>>> you will indeed send a message, proving a possibilty to be interrupted. >>>> >>> >>> I don't see how this would be a reason. When you send #~~, then you >>> explicitly allow a suspension point, so not using #not won't avoid >>> suspension points. >>> >>> >> To my thinking, in a first place, i would ask: >> why instead of fixing the code which may be affected by having or not >> suspension points, >> we introducing new workarounds ?? >> > > Which code needs to be fixed? > > > >> I think it is bad excuse for introduction of new primitive. >> If we miss some atomicity for semaphores, lets add a primitive(s) >> which fixing the semaphore issue(s). >> > > Are there any issues with semaphores? > > > But introducing new primitive to avoid suspension?!?! i cannot follow >> this line of thinking. >> > > I guess you're not replying to my mail, but Eliot's. Btw there's no such > "line of thinking". He didn't add the primitive for #~~ to avoid a > suspension point, but to improve it's performance. > +1. The primitive is nearly twice as fast as the old method in my measurements, which are these: | null | null := Time millisecondsToRun: [1 to: 1000000000 do: [:i| i - i]]. "- is an inlined" (Time millisecondsToRun: [1 to: 1000000000 do: [:i| i ~~ i]]) - null I got about 1200 ms before the primitive, about 660 afterwards, but there's noise to contend with. Anyway, significantly faster. > > Levente > > > >> >>>> Another reasons, similar to the previous one, is that sometimes #== is >>>> also >>>> used as a way to avoid executing method. So..there are some methods (I >>>> don't >>>> remember if #allInstancesDo: or #allObjectsDo:) will loop forever >>>> because >>>> >>> >>> #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: >>> uses a >>> custom marker object, so creating new objects won't cause infinite loop >>> (because gc doesn't change the order of any two objects). >>> >>> the loop condition would be creating objects (remember that method >>>> execution >>>> creates objects such as MethodContext). >>>> >>> >>> Contexts object are not created until requested and these loops don't >>> need >>> contexts. Some old methods interating through all/some objects use 0 as >>> the >>> marker object. These may have problems with objects created during their >>> loops. >>> >>> >>> Levente >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> -- best, Eliot

Oct. 13, 2011

Re: [Pharo-project] About ~= and ~~

by Levente Uzonyi

On Thu, 13 Oct 2011, Igor Stasenko wrote: > On 12 October 2011 23:22, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Wed, 12 Oct 2011, Mariano Martinez Peck wrote: >> >>> On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>>> On Wed, 12 Oct 2011, Clara Allende wrote: >>>> >>>> Â Hi guys, >>>>> >>>>> I'm wondering, why? >>>>> >>>>> ProtoObject>> ~~ anObject >>>>> Â "Answer whether the receiver and the argument are not the same object >>>>> Â (do not have the same object pointer)." >>>>> >>>>> Â self == anObject >>>>> Â Â Â ifTrue: [^ false] >>>>> Â Â Â ifFalse: [^ true] >>>>> >>>>> >>> Hi Carla. I can think about two things. The first one, is the one Levente >>> said, performance. >>> If you analyze the bycode of this method, you will see that it is >>> extremely >>> fast because: >>> >>> 1) #== has an special associated bytecode, that is, them VM maps such >>> bytecode to an specific primitive and it is directly executed. It means >>> that >>> the method #== is really never sent. >>> 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, it >>> method is never executed and instead the compiler replace a message send >>> bytecode with jump ones. >>> >>> Another possible reason (it may not be the case, but in another places it >>> is), is to prevent VM interruption for check other processes. In summary, >>> the VM checks whether it should execute another process of the queue after >>> a >>> method execution. As you know, some parts of the scheduling process is >>> done >>> at the image side. And from there we lack a way to say to the VM, "please >>> execute this method without checking others processes". Hence, in a few >>> yet >>> very specific places of PRocess, Scheduler, Semaphore, etc, #== is used as >>> a >>> mean of executing something WITHOUT being interrupted. I can imagine that >>> it >>> may happen the same with #~~. So if you implement such method with a #not, >>> you will indeed send a message, proving a possibilty to be interrupted. >> >> I don't see how this would be a reason. When you send #~~, then you >> explicitly allow a suspension point, so not using #not won't avoid >> suspension points. >> > > To my thinking, in a first place, i would ask: > why instead of fixing the code which may be affected by having or not > suspension points, > we introducing new workarounds ?? Which code needs to be fixed? > > I think it is bad excuse for introduction of new primitive. > If we miss some atomicity for semaphores, lets add a primitive(s) > which fixing the semaphore issue(s). Are there any issues with semaphores? > But introducing new primitive to avoid suspension?!?! i cannot follow > this line of thinking. I guess you're not replying to my mail, but Eliot's. Btw there's no such "line of thinking". He didn't add the primitive for #~~ to avoid a suspension point, but to improve it's performance. Levente > >>> >>> Another reasons, similar to the previous one, is that sometimes #== is >>> also >>> used as a way to avoid executing method. So..there are some methods (I >>> don't >>> remember if #allInstancesDo: or #allObjectsDo:) will loop forever because >> >> #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: uses a >> custom marker object, so creating new objects won't cause infinite loop >> (because gc doesn't change the order of any two objects). >> >>> the loop condition would be creating objects (remember that method >>> execution >>> creates objects such as MethodContext). >> >> Contexts object are not created until requested and these loops don't need >> contexts. Some old methods interating through all/some objects use 0 as the >> marker object. These may have problems with objects created during their >> loops. >> >> >> Levente >> > > > > -- > Best regards, > Igor Stasenko. > >

Oct. 13, 2011

Re: [Pharo-project] About ~= and ~~

by Igor Stasenko

On 12 October 2011 23:22, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 12 Oct 2011, Mariano Martinez Peck wrote: > >> On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Wed, 12 Oct 2011, Clara Allende wrote: >>> >>> Â Hi guys, >>>> >>>> I'm wondering, why? >>>> >>>> ProtoObject>> ~~ anObject >>>> Â "Answer whether the receiver and the argument are not the same object >>>> Â (do not have the same object pointer)." >>>> >>>> Â self == anObject >>>> Â Â Â ifTrue: [^ false] >>>> Â Â Â ifFalse: [^ true] >>>> >>>> >> Hi Carla. I can think about two things. The first one, is the one Levente >> said, performance. >> If you analyze the bycode of this method, you will see that it is >> extremely >> fast because: >> >> 1) #== has an special associated bytecode, that is, them VM maps such >> bytecode to an specific primitive and it is directly executed. It means >> that >> the method #== is really never sent. >> 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, it >> method is never executed and instead the compiler replace a message send >> bytecode with jump ones. >> >> Another possible reason (it may not be the case, but in another places it >> is), is to prevent VM interruption for check other processes. In summary, >> the VM checks whether it should execute another process of the queue after >> a >> method execution. As you know, some parts of the scheduling process is >> done >> at the image side. And from there we lack a way to say to the VM, "please >> execute this method without checking others processes". Hence, in a few >> yet >> very specific places of PRocess, Scheduler, Semaphore, etc, #== is used as >> a >> mean of executing something WITHOUT being interrupted. I can imagine that >> it >> may happen the same with #~~. So if you implement such method with a #not, >> you will indeed send a message, proving a possibilty to be interrupted. > > I don't see how this would be a reason. When you send #~~, then you > explicitly allow a suspension point, so not using #not won't avoid > suspension points. > To my thinking, in a first place, i would ask: why instead of fixing the code which may be affected by having or not suspension points, we introducing new workarounds ?? I think it is bad excuse for introduction of new primitive. If we miss some atomicity for semaphores, lets add a primitive(s) which fixing the semaphore issue(s). But introducing new primitive to avoid suspension?!?! i cannot follow this line of thinking. >> >> Another reasons, similar to the previous one, is that sometimes #== is >> also >> used as a way to avoid executing method. So..there are some methods (I >> don't >> remember if #allInstancesDo: or #allObjectsDo:) will loop forever because > > #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: uses a > custom marker object, so creating new objects won't cause infinite loop > (because gc doesn't change the order of any two objects). > >> the loop condition would be creating objects (remember that method >> execution >> creates objects such as MethodContext). > > Contexts object are not created until requested and these loops don't need > contexts. Some old methods interating through all/some objects use 0 as the > marker object. These may have problems with objects created during their > loops. > > > Levente > -- Best regards, Igor Stasenko.

Oct. 13, 2011

Re: [Pharo-project] About ~= and ~~

by Levente Uzonyi

On Wed, 12 Oct 2011, Mariano Martinez Peck wrote: > On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Wed, 12 Oct 2011, Clara Allende wrote: >> >> Hi guys, >>> >>> I'm wondering, why? >>> >>> ProtoObject>> ~~ anObject >>> "Answer whether the receiver and the argument are not the same object >>> (do not have the same object pointer)." >>> >>> self == anObject >>> ifTrue: [^ false] >>> ifFalse: [^ true] >>> >>> > Hi Carla. I can think about two things. The first one, is the one Levente > said, performance. > If you analyze the bycode of this method, you will see that it is extremely > fast because: > > 1) #== has an special associated bytecode, that is, them VM maps such > bytecode to an specific primitive and it is directly executed. It means that > the method #== is really never sent. > 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, it > method is never executed and instead the compiler replace a message send > bytecode with jump ones. > > Another possible reason (it may not be the case, but in another places it > is), is to prevent VM interruption for check other processes. In summary, > the VM checks whether it should execute another process of the queue after a > method execution. As you know, some parts of the scheduling process is done > at the image side. And from there we lack a way to say to the VM, "please > execute this method without checking others processes". Hence, in a few yet > very specific places of PRocess, Scheduler, Semaphore, etc, #== is used as a > mean of executing something WITHOUT being interrupted. I can imagine that it > may happen the same with #~~. So if you implement such method with a #not, > you will indeed send a message, proving a possibilty to be interrupted. I don't see how this would be a reason. When you send #~~, then you explicitly allow a suspension point, so not using #not won't avoid suspension points. > > Another reasons, similar to the previous one, is that sometimes #== is also > used as a way to avoid executing method. So..there are some methods (I don't > remember if #allInstancesDo: or #allObjectsDo:) will loop forever because #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: uses a custom marker object, so creating new objects won't cause infinite loop (because gc doesn't change the order of any two objects). > the loop condition would be creating objects (remember that method execution > creates objects such as MethodContext). Contexts object are not created until requested and these loops don't need contexts. Some old methods interating through all/some objects use 0 as the marker object. These may have problems with objects created during their loops. Levente > So...again, I think it may happen the same with #~~. > > That being said, I agree that the method deserve a GOOD comment explaining > the reasons of such optimization. > > Cheers > > > >> Instead of: >>> ProtoObject>> ~~ anObject >>> "Answer whether the receiver and the argument are not the same object >>> (do not have the same object pointer)." >>> >>> ^(self == anObject) not >>> >>> And why? >>> Object >> ~= anObject >>> "Answer whether the receiver and the argument do not represent the >>> same object." >>> >>> ^self = anObject == false >>> >>> Instead of >>> Object>> ~= anObject >>> "Answer whether the receiver and the argument do not represent the >>> same object." >>> >>> ^(self = anObject) not. >>> >>> Is there any particular reason for this that I'm missing? >>> >> >> Performance. >> >> >> Levente >> >> Thanks in advance! >>> -- >>> >>> "*Most good programmers do programming not because they expect to get paid >>> or get adulation by the public, but because it is fun to program.*" >>> >>> Linus Torvalds >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 12, 2011