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

Re: [Pharo-dev] [Moose-dev] Code functionality assessment

by StÃ©phane Ducasse

+1 ! Stef On Sep 23, 2013, at 7:36 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Very nice work, Natalia! > > Doru > > > On Mon, Sep 23, 2013 at 6:12 PM, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> wrote: > Hello, > I wrote another blog post concerning my project on Google Summer of Code, and there's how I assessed the results using Graph-ET. > http://nataliatymchuk.blogspot.com/2013/09/code-functionality-assessment.ht… > > Best regard, > Natalia > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Sept. 23, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by StÃ©phane Ducasse

+1 Now I understand the point of max with the name sort/sorted because this is not explicit to me too :) I laways have to think. On Sep 23, 2013, at 6:28 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 100% agree. > Do it right > do it fast. > We must not turn usage of the library into something fragile for the sake of speed. > We already make the code itself fragile more often than not in term of complexity (harder to understand/test/change). > > Especially, introduction of shared mutable states (global, class vars, singleton or any other form) should ring an alarm in reviewers head > (This is some very old Squeak code in this case, so Squeakers are to blame, but we're all in same bath). > > > > 2013/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Sep 23, 2013, at 3:33 , Max Leske <maxleske(a)gmail.com> wrote: > > >> > >> If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. > > > > Agreed. BUT: the Random object used by these methods is the same one that is used by #atRandom for instance, hence the race condition. There is no way anyone can safely use these methods without the mutex, single threaded or not. Calls to methods using that same Random object can be all over the place and also in the base system. > > > It seems to me an existing Random instance is used in this case mostly* for performance. > One could argue that since the Random in this case is used for a bulk operation, for which the object creation cost is largely amortized for collection sizes > 20, it's acceptable to instead use Random new by default, which wouldn't suffer from the same race conditions. > While still slower than a mutex-protected version for single-threaded code, it would also scale correctly if the users (and vm) are actually multi-threaded. > > [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffle] bench '208,000 per second.' '222,000 per second.' '223,000 per second.' > [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleWithMutex] bench '188,000 per second.' '186,000 per second.''184,000 per second.' > [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleNewRandom] bench '167,000 per second.' '166,000 per second.' '167,000 per second.' > > Cheers, > Henry > > * Low seed entropy is another issue, but if purely random shuffling is a critical requirement, one shouldn't use the default Random generator anyways... > > >

Sept. 23, 2013

Re: [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

by Igor Stasenko

On 23 September 2013 21:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 23 September 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Hi Jan, >> >> I think I will add the ByteArray accessor to NBExternalAddress today >> or tomorrow since I need it as well for another project. >> >> hmm, reading from memory into bytearray can be done with memory copy: > > inputs: address , offset , size to read > > newAddress := NBExternalAddress value: address value + offset. > buffer := ByteArray new: size. > NativeBoost memCopy: newAddress to: buffer size: size. > > same way, writing, just swap the source and destination: > > newAddress := NBExternalAddress value: address value + offset. > buffer "is given from somewhere". > NativeBoost memCopy: buffer to: newAddress size: size. > > but as Jan noted, you cannot tell to write starting at specified offset > from/to bytearray, e.g.: > > copy from: address to: buffer + someOffset > neither: > copy from: buffer + someOffset to: someAddress > > this where we need to introduce special 'field address' type, so you can > construct it like this: > > offsetAddress := buffer nbAddressAt: offset. > > so then you can use it to pass to any function, which expects address, > like memory copy > or any foreign function. > > Since objects are moving in memory, we cannot calculate address of field > before hand: > > address := NBExternalAddress value: someObject address + offset. > > because if GC will happen, after computing such address and its actual use, > you will read/write to wrong location. > ** after computing and *before* actual use ** > Thus we should keep oop + offset up to the point of passing it to external > function, under > controllable conditions, that guarantee there's no GC is possible. > > > Things would be much simpler if we could have pinning, isnt? :) > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Sept. 23, 2013

Re: [Pharo-dev] SHA1 changed ??

by Max Leske

Hi Sorry, I was on holidays and didn't see this. On 23.09.2013, at 20:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-Byt… > > with slice > > On 13 Sep 2013, at 15:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Bump. >> >> Max ? >> >> On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> I'm not aware of such a change... >>>>> this is probably an error/side effect of something else. >>>>> >>>> This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦ Yes that's true. Those two classes were nearly identical. I resolved differences by using the latest method versions of differing methods. Therefore it might well be that I changed that method to the way it is today because the current version is the one with the younger timestamp (I think the changes all came from Stef). Cheers, Max >>>> >>>> https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations >>> >>> I want to wait for Max to respond/explain. >>> >>> But according to http://en.wikipedia.org/wiki/Sha1 >>> >>> "SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long." >>> >>> The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash. >>> >>>>> Esteban >>>>> >>>>> On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> Why was the contract of SHA1>>hashStream: changed ? >>>>>> >>>>>> It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. >>>>>> >>>>>> MD5 hashMessage: 'foo'. >>>>>> >>>>>> #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] >>>>>> >>>>>> SHA1 hashMessage: 'foo'. >>>>>> >>>>>> 68123873083688143418383284816464454849230703155 >>>>>> >>>>>> It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. >>>>>> >>>>>> Can you please explain ? >>>>>> >>>>>> Sven >>>>> >>>>> >>>> >>> >> > >

Sept. 23, 2013

Re: [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

by Igor Stasenko

On 23 September 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Hi Jan, > > I think I will add the ByteArray accessor to NBExternalAddress today > or tomorrow since I need it as well for another project. > > hmm, reading from memory into bytearray can be done with memory copy: inputs: address , offset , size to read newAddress := NBExternalAddress value: address value + offset. buffer := ByteArray new: size. NativeBoost memCopy: newAddress to: buffer size: size. same way, writing, just swap the source and destination: newAddress := NBExternalAddress value: address value + offset. buffer "is given from somewhere". NativeBoost memCopy: buffer to: newAddress size: size. but as Jan noted, you cannot tell to write starting at specified offset from/to bytearray, e.g.: copy from: address to: buffer + someOffset neither: copy from: buffer + someOffset to: someAddress this where we need to introduce special 'field address' type, so you can construct it like this: offsetAddress := buffer nbAddressAt: offset. so then you can use it to pass to any function, which expects address, like memory copy or any foreign function. Since objects are moving in memory, we cannot calculate address of field before hand: address := NBExternalAddress value: someObject address + offset. because if GC will happen, after computing such address and its actual use, you will read/write to wrong location. Thus we should keep oop + offset up to the point of passing it to external function, under controllable conditions, that guarantee there's no GC is possible. > Concerning the Streams, I think it is the easiest solution to wrap around > a ByteArray. Otherwise you could subclass one of the main stream classes > and implement your own primitive methods with FFI to read and write bytes. > In the worst case you will have to implement all primitive methods with FFI > that you find in the StandardFileStream. > > > On 2013-09-22, at 10:12, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hello, > > > > I'm trying to implement a binary ReadStream that gets its data not from a > > Smalltalk collection but from some external memory address. I got this > > address from a library call using NativeBoost. > > > > The NBExternalAddress has methods to access bytes, int's and longs but > > there is no method to get a ByteArray starting at a specified offset and > > with a specified length. I need a method like this to implement the > > ReadStream>>next: method efficiently. > > > > Is it possible ti implement such a method or are there other ways to > > implement a ReadStream efficiently? > > > > In [1] I read that there was already an idea to implement a nbAddressAt: > > method. This would also be using in combination with NativeBoost > > class>>#memCopy:to:size > > > > Regrads, > > Jan. > > > > [1] > > > http://forum.world.st/Pharo-dev-NB-Review-amp-fixes-amp-ideas-td4698514.html > > -- Best regards, Igor Stasenko.

Sept. 23, 2013

Re: [Pharo-dev] SHA1 changed ??

by Sven Van Caekenberghe

https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-Byt… with slice On 13 Sep 2013, at 15:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Bump. > > Max ? > > On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> I'm not aware of such a change... >>>> this is probably an error/side effect of something else. >>>> >>> This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦ >>> >>> https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations >> >> I want to wait for Max to respond/explain. >> >> But according to http://en.wikipedia.org/wiki/Sha1 >> >> "SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long." >> >> The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash. >> >>>> Esteban >>>> >>>> On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> Max, >>>>> >>>>> Why was the contract of SHA1>>hashStream: changed ? >>>>> >>>>> It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. >>>>> >>>>> MD5 hashMessage: 'foo'. >>>>> >>>>> #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] >>>>> >>>>> SHA1 hashMessage: 'foo'. >>>>> >>>>> 68123873083688143418383284816464454849230703155 >>>>> >>>>> It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. >>>>> >>>>> Can you please explain ? >>>>> >>>>> Sven >>>> >>>> >>> >> >

Sept. 23, 2013

Re: [Pharo-dev] Use pharo users mailing list

by H. Hirzel

P.S. I found your Pharo questions http://stackoverflow.com/search?q=user%3A35306+[pharo] 28 of them. Maybe this is a case http://stackoverflow.com/questions/13788585/smalltalk-binding/13789481#1378… "Smalltalk binding" Your answer has 0 points, the accepted anwer given by Hernan has 5 points. On 9/23/13, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello Stephan > > On 9/23/13, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Hannes wrote: >>> In reply to this post by Stephan Eggermont >>> On 9/23/13, Stephan Eggermont <[hidden email]> wrote: >>> > Kilon wrote >>> >>Here is a radical suggestion you probably don't want to hear. >>> >>Close down Pharo users mailing list, redirect everyone to >>> >> stackoverflow. >>> >> >>> > >>> > Definitely not. Stackoverflow is nearly dead, and seriously unsuitable >>> > for >>> > small languages. >>> >>> There are obstacles but one cannot say that it is "seriously >>> unsuitable". >> >> I feel fully qualified to make that statement. > > http://stackoverflow.com/search?q=Stephan+Eggermont > 5 questions, all three years ago? No Pharo question. > > Or do you use a nick name these days? > > And where are the closed Pharo stackoverflow questions? > >> Getting voted on by >> majority views is not exactly what we need. Especially not in >> a cargo-cult driven profession. > > And what is Pharo? A closed sect with people who think everybody else > is clueless and does not want to operate _the_ open space about > programming questions? There are other small communities on > stackoverflow. For example XSL-FO, a technology which has been around > for a long time, good concepts, has mature tools, is useful but still > is not popular. > > The main thing is not about voting but about the person who asks > accepting the answer. And that is often the answer which later on gets > votes. > > The accepted answer is likely the answer which solves the programming > problem asked. > And the questions are well organized. The existing pool of 283 Pharo > questions is a useful resource. More useful that searching through the > mailing list archive. > > http://stackoverflow.com/questions/tagged/pharo > >>> >Good questions will get closed by clueless people. >>> Mostly if the form does not fit. >> >> Nope. there has been a strong change in what is deemed to be an >> acceptable question on SO in the past years. And not in the right >> direction. >> I know several posters here who have been bitten by that. > > Could you give some examples, please? > >>> And if there are Pharo people (maybe earned in another area) with >>> enough reputation points this may be prevented >> >> That would be nice, but isn't the case. Stackoverflow doesn't work like >> that. > > > > >>> > Good answers will get downvoted because they go against majority >>> > views. > > It depends on which tag set you operate in. > I doubt that this applies to a question tagged 'Pharo'. Proper tagging > is important to frame the question properly. > >>> Why? >> >> Because stackoverflow is an opinion site, dominated by popularity. > > Yes, popular languages and thus the questions about them get a lot of > reputation points. > But that is not all that important. The important thing is that you > can organize programming questions in a good way and solve them > nicely. And the content is under a creative common license, thus may > he "harvested" for a FAQ list. > >> Nobody says an answer has to be right. Like I said, take a look at >> questions on OODBs. > > We are not talking about OODBs where it is natural that divergent > opinions come in but about Smalltalk programming which is a well > established mature programming technology, has acceptance of being > "useful" (but only for 'specialists' as the general opinion goes) and > thus has a narrow focus. So the subcommunity can operate quite > unhampered in stackoverflow.... :-) > >>> >The ranking system is heavily skewed towards popular languages. > > Sure, but is this a problem? There are 1000 million speakers of > Chinese and I still did not learn Chinese yet. > >>> It is based on the number of hits which is naturally less in less >>> popular languages. >>> However subcommunities may function well in stackoverflow. >> >> No, not really. It means that members of subcommunities have less >> rights and power. There is no value in subdividing our community >> further. > > You mean by having questions on stackoverflow and the mailing list? > > Let me summarize: Nobody forces you to operate on stackoverflow, but I > consider both, the mailing list and stackoverflow, as useful. And some > cross-referencing might be useful. > > --Hannes > > > P.S. It is easy to monitor what is happening on stackoverflow > regarding 'Pharo' even if you do not want to participate. > > Just visit > http://stackoverflow.com/questions/tagged/pharo > from time to time. >

Sept. 23, 2013

Re: [Pharo-dev] [Moose-dev] Code functionality assessment

by Natalia Tymchuk

Thanks, Doru. Best, Natalia 23.09.13 20:43, Tudor Girba ???????(??): > I blogged it:) > http://www.moosetechnology.org/news/assessing-ode-with-graphet > > Cheers, > Doru > > > > On Mon, Sep 23, 2013 at 7:36 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Very nice work, Natalia! > > Doru > > > On Mon, Sep 23, 2013 at 6:12 PM, Natalia Tymchuk > <natalia.tymchuk(a)unikernel.net > <mailto:natalia.tymchuk@unikernel.net>> wrote: > > Hello, > I wrote another blog post concerning my project on Google > Summer of Code, and there's how I assessed the results using > Graph-ET. > http://nataliatymchuk.blogspot.com/2013/09/code-functionality-assessment.ht… > > Best regard, > Natalia > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Sept. 23, 2013

Re: [Pharo-dev] [Moose-dev] Code functionality assessment

by Tudor Girba

I blogged it:) http://www.moosetechnology.org/news/assessing-ode-with-graphet Cheers, Doru On Mon, Sep 23, 2013 at 7:36 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Very nice work, Natalia! > > Doru > > > On Mon, Sep 23, 2013 at 6:12 PM, Natalia Tymchuk < > natalia.tymchuk(a)unikernel.net> wrote: > >> Hello, >> I wrote another blog post concerning my project on Google Summer of >> Code, and there's how I assessed the results using Graph-ET. >> >> http://nataliatymchuk.blogspot.com/2013/09/code-functionality-assessment.ht… >> >> Best regard, >> Natalia >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 23, 2013

Re: [Pharo-dev] Use pharo users mailing list

by H. Hirzel

On 9/23/13, blake <dsblakewatson(a)gmail.com> wrote: > If StackOverflow is dead, what is replacing it? Are people reverting to > discussion groups/mail lists? Or different Q&A sites, like the > aforementioned InfoQ? > > (Alan Kay is right: programming really IS pop culture.) And what does this imply? [snip]

Sept. 23, 2013