- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] HTTPProgress Content-Length v.

by Sven Van Caekenberghe

Hi Ben, On 01 Oct 2013, at 19:48, Ben Coman <btc(a)openInWorld.com> wrote: > For PharoLauncher, I am trying to get a progress bar going for the downloading the Template lists, but the total transfer size is not being filled in for the HTTPProgress announcement. I've pulled out some code to Workspace script into [2] with the resulting Transcript result shown in [3]. I'm guessing this is due to the _"Transfer-Encoding: chunked"_ header clashing with the "Content-Length" header [1]. By putting a 'self halt' in ZnStatusLine>>readFrom: and executing several "Transcript crShow: (ZnLineReader on: stream) nextLine" the real headers were found as shown in [4], from which it seems the Content-Length is faked-up after the download finishes, and no use for a progress bar. Completely correct! I am happy you made it this far and were able to understand the specs and code. > So I only today discovered 'chunked' format, so I am curious... is there a particular advantage to use chunked for directory listing at "url=http://files.pharo.org/image/30/" ? > Could it be changed to instead set Content-Length instead? > btw, This is only for the directory listing (which however takes 10 seconds to get all). The zip files seem to set "Content-Length" when downloaded. The whole idea of chunked transfer encoding is to make it easier for the server: it does not have to buffer and compute a total size upfront. BTW, there are other cases in HTTP where Content-Length is not set as well. It is just how it is. And yes that means silly progress indications. Sven > cheers -ben > > > [1] http://stackoverflow.com/questions/2419281/content-length-header-versus-chu… > > "[2]start------------------Workspace-script----------" > workBlock := > [ ZnClient new > signalProgress: true ; > url: 'http://files.pharo.org/image/30/' ; > enforceHttpSuccess: true ; > beOneShot ; > accept: 'text/html;charset=utf-8' ; > enforceAcceptContentType: true ; > logToTranscript ; > get > ]. > > UIManager default informUserDuring: > [ :bar| > [ workBlock value] on: HTTPProgress do: > [ : progress | > Transcript crShow: '# ' , progress printString , > ' total=' , progress total asString , > ' amount=' , progress amount asString. > bar label: progress printString. progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume. > ]. > ]. > "[2]end------------------Workspace-script----------" > > > "[3]start--------------Transcript------" > # HTTPProgress: Connecting to files.pharo.org total=nil amount=nil > 2013-10-02 00:43:36 428852 I Wrote a ZnRequest(GET /image/30/) > 2013-10-02 00:43:36 428852 D Sent headers > Accept: text/html;charset=utf-8 > User-Agent: Zinc HTTP Components 1.0 > Connection: close > Host: files.pharo.org > # HTTPProgress: Writing request total=nil amount=nil > # HTTPProgress: Reading response total=nil amount=nil > ZnUtils>>signalProgress: 16384 total: nil > # HTTPProgress: Tranferred 16.38k bytes ... total=nil amount=nil > ZnUtils>>signalProgress: 32768 total: nil > # HTTPProgress: Tranferred 32.77k bytes ... total=nil amount=nil > ZnUtils>>signalProgress: 49152 total: nil > # HTTPProgress: Tranferred 49.15k bytes ... total=nil amount=nil > ZnUtils>>signalProgress: 65536 total: nil > # HTTPProgress: Tranferred 65.54k bytes ... total=nil amount=nil > ZnUtils>>signalProgress: 81920 total: nil > # HTTPProgress: Tranferred 81.92k bytes ... total=nil amount=nil > ZnUtils>>signalProgress: 85434 total: nil > # HTTPProgress: Tranferred 85.43k bytes ... total=nil amount=nil > 2013-10-02 00:43:38 428852 I Read a ZnResponse(200 OK text/html;h5ai=0.22.1;charset=UTF-8 85444B) > 2013-10-02 00:43:38 428852 D Received headers > Date: Tue, 01 Oct 2013 16:43:34 GMT > Transfer-Encoding: chunked > Content-Length: 85444 > Vary: Accept-Encoding > Server: Apache > Connection: close > Content-Type: text/html;h5ai=0.22.1;charset=UTF-8 > 2013-10-02 00:43:38 428852 T GET /image/30/ 200 85444B 1874ms > "[3]end--------------Transcript------" > > "[4]start----------ZnStatusLine>>readReal-Headers--------" > HTTP/1.1 200 OK > Date: Tue, 01 Oct 2013 17:23:55 GMT > Server: Apache > Vary: Accept-Encoding > Connection: close > Transfer-Encoding: chunked > Content-Type: text/html;h5ai=0.22.1;charset=UTF-8 > "[4]end-----------Real-Headers--------" > >

Oct. 1, 2013

HTTPProgress Content-Length v.

by Ben Coman

For PharoLauncher, I am trying to get a progress bar going for the downloading the Template lists, but the total transfer size is not being filled in for the HTTPProgress announcement. I've pulled out some code to Workspace script into [2] with the resulting Transcript result shown in [3]. I'm guessing this is due to the _"Transfer-Encoding: chunked"_ header clashing with the "Content-Length" header [1]. By putting a 'self halt' in ZnStatusLine>>readFrom: and executing several "Transcript crShow: (ZnLineReader on: stream) nextLine" the real headers were found as shown in [4], from which it seems the Content-Length is faked-up after the download finishes, and no use for a progress bar. So I only today discovered 'chunked' format, so I am curious... is there a particular advantage to use chunked for directory listing at "url=http://files.pharo.org/image/30/" ? Could it be changed to instead set Content-Length instead? btw, This is only for the directory listing (which however takes 10 seconds to get all). The zip files seem to set "Content-Length" when downloaded. cheers -ben [1] http://stackoverflow.com/questions/2419281/content-length-header-versus-chu… "[2]start------------------Workspace-script----------" workBlock := [ ZnClient new signalProgress: true ; url: 'http://files.pharo.org/image/30/' ; enforceHttpSuccess: true ; beOneShot ; accept: 'text/html;charset=utf-8' ; enforceAcceptContentType: true ; logToTranscript ; get ]. UIManager default informUserDuring: [ :bar| [ workBlock value] on: HTTPProgress do: [ : progress | Transcript crShow: '# ' , progress printString , ' total=' , progress total asString , ' amount=' , progress amount asString. bar label: progress printString. progress isEmpty ifFalse: [ bar current: progress percentage ]. progress resume. ]. ]. "[2]end------------------Workspace-script----------" "[3]start--------------Transcript------" # HTTPProgress: Connecting to files.pharo.org total=nil amount=nil 2013-10-02 00:43:36 428852 I Wrote a ZnRequest(GET /image/30/) 2013-10-02 00:43:36 428852 D Sent headers Accept: text/html;charset=utf-8 User-Agent: Zinc HTTP Components 1.0 Connection: close Host: files.pharo.org # HTTPProgress: Writing request total=nil amount=nil # HTTPProgress: Reading response total=nil amount=nil ZnUtils>>signalProgress: 16384 total: nil # HTTPProgress: Tranferred 16.38k bytes ... total=nil amount=nil ZnUtils>>signalProgress: 32768 total: nil # HTTPProgress: Tranferred 32.77k bytes ... total=nil amount=nil ZnUtils>>signalProgress: 49152 total: nil # HTTPProgress: Tranferred 49.15k bytes ... total=nil amount=nil ZnUtils>>signalProgress: 65536 total: nil # HTTPProgress: Tranferred 65.54k bytes ... total=nil amount=nil ZnUtils>>signalProgress: 81920 total: nil # HTTPProgress: Tranferred 81.92k bytes ... total=nil amount=nil ZnUtils>>signalProgress: 85434 total: nil # HTTPProgress: Tranferred 85.43k bytes ... total=nil amount=nil 2013-10-02 00:43:38 428852 I Read a ZnResponse(200 OK text/html;h5ai=0.22.1;charset=UTF-8 85444B) 2013-10-02 00:43:38 428852 D Received headers Date: Tue, 01 Oct 2013 16:43:34 GMT Transfer-Encoding: chunked Content-Length: 85444 Vary: Accept-Encoding Server: Apache Connection: close Content-Type: text/html;h5ai=0.22.1;charset=UTF-8 2013-10-02 00:43:38 428852 T GET /image/30/ 200 85444B 1874ms "[3]end--------------Transcript------" "[4]start----------ZnStatusLine>>readReal-Headers--------" HTTP/1.1 200 OK Date: Tue, 01 Oct 2013 17:23:55 GMT Server: Apache Vary: Accept-Encoding Connection: close Transfer-Encoding: chunked Content-Type: text/html;h5ai=0.22.1;charset=UTF-8 "[4]end-----------Real-Headers--------"

Oct. 1, 2013

Re: [Pharo-dev] XMLParser & PharoExtras, XMLWriter, XPath: status?

by HernÃ¡n Morales Durand

Hi Stef, I added you as contributor to the repo. I will update my Configurations during the week with catalog info. The catalog looks really nice. HernÃ¡n 2013/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi hernan > > this is great it shows up in the catalog list. > > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ > ? > Now could you add the catalog metadata information to the configuration. > > I will improve the catalog generator to generate the missing method > template. > if you give me access to the repo I can also do it for you. > > Stef > > > On Oct 1, 2013, at 8:23 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > El 29/09/2013 11:01, StÃ©phane Ducasse escribiÃ³: > >> cool is it standalone? > > > > Yes > > > >> Could you add the catalog metadata and publish it in metarepository > like that it will be documented on the catalog. > >> You can take as example Soup or OSC on PharoExtras > >> > > > > Done. I have added usage example. Let me know if anything is missing. > > > > Cheers, > > > > HernÃ¡n > > > >> Stef > >> On Sep 29, 2013, at 12:42 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> > >>> Already migrated > >>> > >>> http://www.smalltalkhub.com/#!/~hernan/XMLPullParser > >>> > >>> I use it a lot to parse really big XMLs > >>> > >>> El 29/09/2013 7:05, StÃ©phane Ducasse escribiÃ³: > >>>> It would be good to migrate this one > >>>> XMLPullParser > >>>> < > http://pharo.gemtalksystems.com/book/LanguageAndLibraries/XML/XML-support-i…> > : > >>>> Supports StAX. http://www.squeaksource.com/XMLPullParser.html to > >>>> smalltalkhub. > >>>> Does anybody use it? > >>>> > >>>> On Sep 28, 2013, at 11:42 PM, HernÃ¡n Morales Durand > >>>> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > >>>> > >>>>> El 28/09/2013 14:38, phil(a)highoctane.be <mailto:phil@highoctane.be> > >>>>> escribiÃ³: > >>>>>> In the Pharo 20 image, I see that we do have XMLParser, > XMLPullParser, > >>>>>> XMLWriter and XPath listed in the configuration (new install with > >>>>>> ZeroConf). > >>>>>> > >>>>>> I am also using Soup. > >>>>>> > >>>>>> That's because I am working on some OpenData and screen scraping > work > >>>>>> and wondered what was okay to use. > >>>>>> > >>>>>> Is Soup depending on these? (I have XMLReader and Writer in my > image but > >>>>>> don't know from where at the moment - but there are no tests, so > only > >>>>>> something like #Core was loaded. > >>>>>> > >>>>>> Also what is different between XMLParser and XMLPullParser? > >>>>>> > >>>>> > >>>>> > http://pharo.gemtalksystems.com/pier/book/LanguageAndLibraries/XML/XML-supp… > >>>>> > >>>>>> TIA > >>>>>> Phil > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > >> > > > > > > >

Oct. 1, 2013

Pharo Project Catalog List

by Alexis Parseghian

> this is great it shows up in the catalog list. > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ Having such a centralized list of Pharo(-related) project is a reat resource. Hadn't realized previously that it was available. A lot of those projects have a non-obvious name, it might be interesting to have a few descriptive words directly in the list above (when available), rather than just the project name ? Minor bug : when you look up any particular project in a separate browser window/tab, the page title is always Â« truc Â» :)

Oct. 1, 2013

Re: [Pharo-dev] SlotVirus

by StÃ©phane Ducasse

marcus I love what you did for the codeHolder removal (please do the same for these items). Yes I want to remove the duplicates. Stef On Oct 1, 2013, at 9:31 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 1, 2013, at 9:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Oct 1, 2013, at 9:07 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> And we should not forget to do these cleanups: we now have nearly everything double in the system: >>> -> Compiler >>> -> Inspector >>> -> Debugger >>> -> ClassBuilder >>> -> ClassOrganizer >>> -> Browserâ¦. >> >> -> Rpackage vs PackaInfo vs. SystemCategory >> -> Ring vs. PseudeClass&co vs. RBClass >> -> AST vs RB AST > > -> Url vs. ZnUrl > -> ZnMimeType vs MimeType > -> NewList vs whichever-of-the 30 classes with "List" in its name > -> FreeType vs. Bitmap fonts > -> TreeInspector vs. ObjectExplorer > > We should really clean up. > > Marcus > >

Oct. 1, 2013

Re: [Pharo-dev] XMLParser & PharoExtras, XMLWriter, XPath: status?

by StÃ©phane Ducasse

Hi hernan this is great it shows up in the catalog list. https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? Now could you add the catalog metadata information to the configuration. I will improve the catalog generator to generate the missing method template. if you give me access to the repo I can also do it for you. Stef On Oct 1, 2013, at 8:23 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > El 29/09/2013 11:01, StÃ©phane Ducasse escribiÃ³: >> cool is it standalone? > > Yes > >> Could you add the catalog metadata and publish it in metarepository like that it will be documented on the catalog. >> You can take as example Soup or OSC on PharoExtras >> > > Done. I have added usage example. Let me know if anything is missing. > > Cheers, > > HernÃ¡n > >> Stef >> On Sep 29, 2013, at 12:42 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >>> Already migrated >>> >>> http://www.smalltalkhub.com/#!/~hernan/XMLPullParser >>> >>> I use it a lot to parse really big XMLs >>> >>> El 29/09/2013 7:05, StÃ©phane Ducasse escribiÃ³: >>>> It would be good to migrate this one >>>> XMLPullParser >>>> <http://pharo.gemtalksystems.com/book/LanguageAndLibraries/XML/XML-support-i…> : >>>> Supports StAX. http://www.squeaksource.com/XMLPullParser.html to >>>> smalltalkhub. >>>> Does anybody use it? >>>> >>>> On Sep 28, 2013, at 11:42 PM, HernÃ¡n Morales Durand >>>> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>>> >>>>> El 28/09/2013 14:38, phil(a)highoctane.be <mailto:phil@highoctane.be> >>>>> escribiÃ³: >>>>>> In the Pharo 20 image, I see that we do have XMLParser, XMLPullParser, >>>>>> XMLWriter and XPath listed in the configuration (new install with >>>>>> ZeroConf). >>>>>> >>>>>> I am also using Soup. >>>>>> >>>>>> That's because I am working on some OpenData and screen scraping work >>>>>> and wondered what was okay to use. >>>>>> >>>>>> Is Soup depending on these? (I have XMLReader and Writer in my image but >>>>>> don't know from where at the moment - but there are no tests, so only >>>>>> something like #Core was loaded. >>>>>> >>>>>> Also what is different between XMLParser and XMLPullParser? >>>>>> >>>>> >>>>> http://pharo.gemtalksystems.com/pier/book/LanguageAndLibraries/XML/XML-supp… >>>>> >>>>>> TIA >>>>>> Phil >>>>> >>>>> >>>> >>> >>> >> >> >> > >

Oct. 1, 2013

Re: [Pharo-dev] SlotVirus

by Pavel Krivanek

2013/10/1 Marcus Denker <marcus.denker(a)inria.fr>: > > On Oct 1, 2013, at 9:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Oct 1, 2013, at 9:07 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> And we should not forget to do these cleanups: we now have nearly everything double in the system: >>> -> Compiler >>> -> Inspector >>> -> Debugger >>> -> ClassBuilder >>> -> ClassOrganizer >>> -> Browserâ¦. >> >> -> Rpackage vs PackaInfo vs. SystemCategory >> -> Ring vs. PseudeClass&co vs. RBClass >> -> AST vs RB AST > > -> Url vs. ZnUrl > -> ZnMimeType vs MimeType > -> NewList vs whichever-of-the 30 classes with "List" in its name > -> FreeType vs. Bitmap fonts > -> TreeInspector vs. ObjectExplorer > > We should really clean up. > Do you remember the picture with a lighthouse starting as a rocket? I's normal for space vehicles to have doubled systems ;-) -- Pavel

Oct. 1, 2013

Re: [Pharo-dev] "as yet unclassified" protocol remains when empty

by Goubier Thierry

Hi Ben, I think it has already been noticed as a bug, so it will be corrected. Not sure there is already an issue about it, however. Regards, Thierry Le 01/10/2013 15:43, btc(a)openinworld.com a Ã©crit : > I wanted to check this was not a feature before reporting an issue. > Previously in Pharo 2.0, when the protocol "as yet unclassified" became > empty, it disappeared. > In Pharo 30434, it does not disappear when empty. > Really a small thing, but I prefer the previous behaviour. > > cheers -ben > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 1, 2013

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

by Henrik Johansen

On Sep 28, 2013, at 10:59 , Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the feedback guys. > > Based on the discussion I propose a different set of changes: > > 1. > shuffle > ^ self shuffleBy: Random new > > 2. > shuffled > ^ self copy shuffle > > 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) > > > I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). > > Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. > > Cheers, > Max +1 from me on all three suggestions, as you might guess. :) As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation. At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess. Cheers, Henry

Oct. 1, 2013

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

by Max Leske

bump... > Thanks for the feedback guys. > > Based on the discussion I propose a different set of changes: > > 1. > shuffle > ^ self shuffleBy: Random new > > 2. > shuffled > ^ self copy shuffle > > 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) > > > I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). > > Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. > > Cheers, > Max > > > On 24.09.2013, at 02:33, btc(a)openInWorld.com wrote: > >> Nicolas Cellier wrote: >>> >>> The reason why I don't like the explicit "copy", is because this is the >>> default behaviour. >>> In place mutation is an (evil) exception. >>> I'm personnally fine with current conventions: >>> - sort, shuffle, reverse, replace: are imperative, thus you are telling >>> collection, sort yourself ! >>> - sorted clearly sounds as a sorted copy for me. >>> If ever a change was to be made, I would much prefer this to happen on >>> opposite naming, sort -> inPlaceSort, or sortYourself :) >>> It's like telling the programmer, hey - a stateful mutation is really what >>> you want, is it? >>> >> >> Conventions should encourage good programming practice. Although it makes perfect sense on hearing it, I was explicitly not aware of the convention between 'sort' and 'sorted'. For me, the small difference in letters used between the two doesn't provide a wide enough distinction. Also, regarding not mutating state, I guess I knew that in the back of my head, but it has not generally been an explicit concern of mine while programming. Convention should encourage good programming. So I like the suggestion of inPlaceSort & sortYourself. As well as being more intention revealing, the less desirable methods are made less attractive by using a longer name. Perhaps another naming convention could be mutatedSort, or mutSort as a hint that the programmer should consider using these in conjunction with mutexes, or at own risk. >> >> cheers -ben >> >> >> >>> 2013/9/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>> >>>> +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... >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >

Oct. 1, 2013