- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] VM error in Arch Linux

by phil＠highoctane.be

I guess that that image is a Spur one, requiring a Spur VM. Phil On Tue, Dec 22, 2015 at 11:14 AM, nacho <0800nacho(a)gmail.com> wrote: > Hi Folks, > I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo > site. > Everything works fine for Pharo 4. > But when I try to load a Pharo 5 image I get the following error: > This interpreter (vers. 6502) cannot read file image (vers. 6521) > > and when I do pharo --version: > 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15024 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 > UTC > 2012 i686 i686 i386 GNU/Linux > plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] > > > Any clues? > > Thanks in advance > Nacho > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Denis Kudriashov

Hi My vote: > 1. Do you agree to changing #sum and #sum: in the suggested way? > yes but I prefer #sum: return zero too for empty collections > 2. Do you agree to the removal of #detectSum:? > yes > > 3. Do you agree to the removal of #sumNumbers? > yes > > 4. Do you agree that the #max and #min selectors also need to be adapted? > yes

Dec. 22, 2015

VM error in Arch Linux

by nacho

Hi Folks, I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo site. Everything works fine for Pharo 4. But when I try to load a Pharo 5 image I get the following error: This interpreter (vers. 6502) cannot read file image (vers. 6521) and when I do pharo --version: 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 https://github.com/pharo-project/pharo-vm.git Commit: bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15024 Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] Any clues? Thanks in advance Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolas Cellier

2015-12-22 10:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 22 Dec 2015, at 10:22, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > > > 2015-12-22 3:46 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > > I am saying that if you want sum: to be generic, it cannot assume a > *specific* Zero object. > > > And sum: should be generic because of its name. > > > > This seems the crux of the disparate viewpoints, which is why I > > suggested return a *generic* Zero object as follows... > > > > > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > > do something like... > > > > > > Collection>>sum > > > | sum sample | > > > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > > > sample := self anyOne. > > > sum := self inject: sample into: [ :accum :each | accum + each ]. > > > ^ sum - sample > > > > > > Nice, but generic zero can't work: you sometimes need to decide if it is > the zero of vector space, or of associated field. > > The generic zero can't behave as both say a matrix and a scalar... > > Indeed, that is what I said the first time Ben proposed this. > > But I am curious, Nicolas, what you think of this, with your math > background/interest ? > > This is what I had in old app (in the 90s): SequenceableCollection>>sum: aBlock "answer the sum of all elements after applying a Block" | sum | self isEmpty ifTrue: [^0]. sum := aBlock value: (self at: 1). 2 to: self size do: [:i | sum := sum + (aBlock value: (self at: i))]. ^sum Collection>>sum: aBlock "answer the sum of all elements after applying a Block" | sum | sum := 0. self do: [:e | sum := sum + (aBlock value: e)]. ^sum I find sum: much more expressive than inject:into: If we really find that it adds semantic value to inject:into: we may also implement optionnal: Collection>>sum: aBlock to: initialValue "answer the sum of all elements after applying a Block" | sum | sum := initialValue. self do: [:e | sum := sum + (aBlock value: e)]. ^sum Collection>>sum: aBlock ^self sum: aBlock to: 0 This way, no (#anyOne,#-) trick required, that's why I prefer sum:to: to sum:ifEmpty:... For example, I had symbolic algebra, and the #- trick would have required further simplification of the sum. So I don't have any mathematical solution, just pragmatic ones: - I agree on this: no need for many selectors, one or maximum two should be enough - I wouldn't care too much and would just answer 0 for empty collection because we have inject:into: or optionnally sum:to: for exotic cases

Dec. 22, 2015

Re: [Pharo-dev] Any thread-safe collection for Pharo?

by Denis Kudriashov

2015-12-22 10:28 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > There is SharedQueue that I know of. > > LRUCache and TTLCache can #beThreadSafe. > > In general it is easy enough to put something in front of your collection > access. > I want something more simple which not force me to remember what is semaphore, monitor, mutex or whatever. Something like this: threadSafeCollection := AnyCollectionClass threadSafe. or threadSafeCollection := AnyCollectionInstance threadSafe. or more general threadSafeObject := AnyObjectInstance threadSafe Thread safe wrappers should allow concurrent reads which blocked on writes and writes which blocked on anything. For example collection #add: method should wait until current #do: or #add: completes. And #do: should wait until current #add: completes.

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Sven Van Caekenberghe

> On 22 Dec 2015, at 10:22, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2015-12-22 3:46 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I am saying that if you want sum: to be generic, it cannot assume a *specific* Zero object. > > And sum: should be generic because of its name. > > This seems the crux of the disparate viewpoints, which is why I > suggested return a *generic* Zero object as follows... > > > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > do something like... > > > > Collection>>sum > > | sum sample | > > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > > sample := self anyOne. > > sum := self inject: sample into: [ :accum :each | accum + each ]. > > ^ sum - sample > > > Nice, but generic zero can't work: you sometimes need to decide if it is the zero of vector space, or of associated field. > The generic zero can't behave as both say a matrix and a scalar... Indeed, that is what I said the first time Ben proposed this. But I am curious, Nicolas, what you think of this, with your math background/interest ? > On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxleske(a)gmail.com> wrote: > > While I think you might be on to something, I think we should take small > > steps. Iâd be happy already if we can just get rid of one superfluous method > > and provide a better API without starting to think about the deeper > > semantics. > > Sure, small steps are better, except when this hits a sticking point > that the bigger step may overcome. I think returning a generic zero > allowing the program to proceed is better than throwing an generic > error that the programmer needs to explicitly deal with. The concept > of zero is well defined for the common arithmetic functions. Just for > a thought experiment, what arithmetic functions would need to be dealt > with. > > > ArithmeticZero class >> + anObject > > ^anObject > > AritmeticZero class >> * anObject > ^ anObject zero > > AritmeticZero class >> - anObject > ^ anObject zero - anObject > > > > Also, I think thereâs a reason why Aconcagua is an external package: > > developers usually are happy to work with numbers (which are already objects > > in Smalltalk anyway) and theyâre fast. > > Sure its an external package, but when you have a collection of weight > readings for example, you want to use the internal convenient #sum > method... > { 4 kg . 5 kg . 6 kg } sum --> 16kg > { } sum + 1 kg --> 1kg > { } sum * 1 kg --> 0 kg^2 "hmmm, zero with units and > multiplication starts getting more complicated - maybe should be left > out of this discussion" > > > While #sumNumbers may *technically* be the best name (which > > we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: > > form a triple that naturally fits into the naming protocol applied > > elsewhere. > > So maybe alternative naming of the generic zero... > #sum (empty --> EmptyAggregateZero) > #sum: (empty --> EmptyAggregateZero) > #sum: ifEmpty: (empty --> whatever) > > > > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > > wrote: > > Doru, > > > > For me this whole discussion started because you (the standpoint that you > > take) hijacked the best selector (#sum) for a use case that is much less > > common than adding a collection of numbers which should give 0 when empty > > (you hijack it by not wanting to return 0, which I totally understand, but > > doing so you redefine the meaning/semantics). > > > > Max's point is to make everything more consistent and remove some API. I > > support that too. > > > > Now, I like Max's proposal. > > > > But, you know, my conclusion when the thread ended was that it might be > > better to throw all these selectors away, since #inject:into: covers most > > use cases at least as well and at least as clear. > > #sum is very convenient and that lowers the barrier of entry for > newcomers over the relatively exotic #inject:into: We should keep > trying to work through the sticky points, but maybe you guys getting > together IRL is better than continuing on the mail list. > > cheers -ben

Dec. 22, 2015

Re: [Pharo-dev] Any thread-safe collection for Pharo?

by Sven Van Caekenberghe

There is SharedQueue that I know of. LRUCache and TTLCache can #beThreadSafe. In general it is easy enough to put something in front of your collection access. If you want concurrent and interleaved access to the same collection by multiple threads while modifying the collection, that is something else ;-) > On 22 Dec 2015, at 09:41, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > Anybody know thread-safe collections project?

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolas Cellier

2015-12-22 3:46 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I am saying that if you want sum: to be generic, it cannot assume a > *specific* Zero object. > > And sum: should be generic because of its name. > > This seems the crux of the disparate viewpoints, which is why I > suggested return a *generic* Zero object as follows... > > > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > do something like... > > > > Collection>>sum > > | sum sample | > > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > > sample := self anyOne. > > sum := self inject: sample into: [ :accum :each | accum + each ]. > > ^ sum - sample > > Nice, but generic zero can't work: you sometimes need to decide if it is the zero of vector space, or of associated field. The generic zero can't behave as both say a matrix and a scalar... > On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxleske(a)gmail.com> wrote: > > While I think you might be on to something, I think we should take small > > steps. Iâd be happy already if we can just get rid of one superfluous > method > > and provide a better API without starting to think about the deeper > > semantics. > > Sure, small steps are better, except when this hits a sticking point > that the bigger step may overcome. I think returning a generic zero > allowing the program to proceed is better than throwing an generic > error that the programmer needs to explicitly deal with. The concept > of zero is well defined for the common arithmetic functions. Just for > a thought experiment, what arithmetic functions would need to be dealt > with. > > > ArithmeticZero class >> + anObject > > ^anObject > > AritmeticZero class >> * anObject > ^ anObject zero > > AritmeticZero class >> - anObject > ^ anObject zero - anObject > > > > Also, I think thereâs a reason why Aconcagua is an external package: > > developers usually are happy to work with numbers (which are already > objects > > in Smalltalk anyway) and theyâre fast. > > Sure its an external package, but when you have a collection of weight > readings for example, you want to use the internal convenient #sum > method... > { 4 kg . 5 kg . 6 kg } sum --> 16kg > { } sum + 1 kg --> 1kg > { } sum * 1 kg --> 0 kg^2 "hmmm, zero with units and > multiplication starts getting more complicated - maybe should be left > out of this discussion" > > > While #sumNumbers may *technically* be the best name (which > > we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: > > form a triple that naturally fits into the naming protocol applied > > elsewhere. > > So maybe alternative naming of the generic zero... > #sum (empty --> EmptyAggregateZero) > #sum: (empty --> EmptyAggregateZero) > #sum: ifEmpty: (empty --> whatever) > > > > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > > wrote: > > Doru, > > > > For me this whole discussion started because you (the standpoint that you > > take) hijacked the best selector (#sum) for a use case that is much less > > common than adding a collection of numbers which should give 0 when empty > > (you hijack it by not wanting to return 0, which I totally understand, > but > > doing so you redefine the meaning/semantics). > > > > Max's point is to make everything more consistent and remove some API. I > > support that too. > > > > Now, I like Max's proposal. > > > > But, you know, my conclusion when the thread ended was that it might be > > better to throw all these selectors away, since #inject:into: covers most > > use cases at least as well and at least as clear. > > #sum is very convenient and that lowers the barrier of entry for > newcomers over the relatively exotic #inject:into: We should keep > trying to work through the sticky points, but maybe you guys getting > together IRL is better than continuing on the mail list. > > cheers -ben > >

Dec. 22, 2015

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

by Denis Kudriashov

I found this: http://smalltalkhub.com/#!/~Moose/DeepTraverser 2015-12-22 10:05 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 22 Dec 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com> 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, I think so.. there is #fuelAccept:, but I am not sure how general it > is. > > I remember that Doru did some object graph iteration experiments, too? > (I canât find it). > > But I think we should actually add a general âobject graph iteratorâ to > the reflective > features of the language. It seems very useful to have, and for sure Fuel > could just > use it. > > Marcus > > > > >

Dec. 22, 2015

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

by Robert Withers

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 > and load Mushr00m-Pharo on top of MushrOOm (after installing > Cryptography and SecureSession from > http://www.squeaksource.com/Cryptography) > > Then look at the classes in the Utility category. > > HTH, > > Robert > > > > On 12/22/2015 03:46 AM, 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 ? >> >> Best regards, >> Denis > -- . .. ... ^,^ robert Go Panthers!

Dec. 22, 2015