March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Nicolai Hess

2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > Currently the image the monkey uses to validate issues is 9 days old - > which might be a problem if your bug fix today depends on or conflicts with > something integrated a week ago. > > I have somewhat isolated the problem to a Rubric/GTTools update, but > nothing looks obvious from the package level. Its time for bed, so I > haven't dug into code changes yet, but could someone from the Glamorous > Team familiar with the changes for Issue 15018 take a look? > > https://pharo.fogbugz.com/default.asp?15018 > > https://pharo.fogbugz.com/default.asp?15127 > > cheers -ben > possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting. startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Stephan Eggermont

On 17/03/15 21:35, Nicolas Cellier wrote: > But wait, the file was buffered (bytes are fetched from file by packets), > but the decoder was not! All decoding is performed char by char. In the optimized version there is still no reading of a 32/64-bit word at a time, checking all 8th bits at the same time, isn't there? I assume Bitmap asByteArray hack works for ByteStrings too? Stephan

March 17, 2015

Re: [Pharo-dev] Rubric mutability issue in RubTextComposer binary search

by Stephan Eggermont

Hi Alex, On 17/03/15 22:19, Aliaksei Syrel wrote: > seems like there is a rather rare bug in Rubric. I opened an issue with > explanation: > > https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextC… > > Would be nice to fix it until release. It was caught in Spotter - as it > heavily uses multithreading. Any suggestions are welcome if it is known :) Why is that an issue in Rubric? Sounds like you might need a monitor in Spotter? Stephan

March 17, 2015

Rubric mutability issue in RubTextComposer binary search

by Aliaksei Syrel

Hi, seems like there is a rather rare bug in Rubric. I opened an issue with explanation: https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextC… Would be nice to fix it until release. It was caught in Spotter - as it heavily uses multithreading. Any suggestions are welcome if it is known :) Cheers, Alex

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Nicolas Cellier

2015-03-17 21:10 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > We can already have relatively fast UTF8 reading when the file is > essentially composed of ascii. > I've demonstrated this a few years ago with SqueaXtreams ( > http://www.squeaksource.com/XTream/) > > For example, see > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141577… > > I don't want to sell SqueaXtreams, it was just an experiment, but the good > ideas should be extracted, we don't have to wait for a new VM. > > Nicolas Cellier (eh, I now have to disambiguate, maybe i will sign NiCe...) > > I've also found this - http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15338… - only the end counts, quoted below: But wait, the file was buffered (bytes are fetched from file by packets), but the decoder was not! All decoding is performed char by char. That's bad, because when only a few bytes require decoding and majority can be translated unchanged to String, there is potentially a major speed up by simple using a sub-array copy primitive. We know this since #squeakToUTF8, many thanks to Andreas. To profit by buffering for decoder too, just use a message to wrap it up: { [| tmp | tmp := (MultiByteFileStream readOnlyFileNamed: (SourceFiles at: 2) name) ascii; wantsLineEndConversion: false; converter: UTF8TextConverter new. 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. [| tmp | tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) name) readXtream binary buffered ~> UTF8Decoder) buffered. 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. } #(152 18) #(152 19) Bingo, now the speed up is there too! 7.5x is not a bad score afterall. That's not amazing, the change log is essentially made of ASCII and does rarely require any UTF8 translation at all. Of course, if you handle files full of chinese code points, don't expect a speed up at all! But for a decent proportion of latin character users, the potential speed-up is there, right under our Streams. > > 2015-03-17 19:58 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> >> Le 17 mars 2015 18:59, "Stephan Eggermont" <stephan(a)stack.nl> a Ã©crit : >> > >> > On 17/03/15 17:59, Stephan Eggermont wrote: >> > >> >> I tried the code with the latest pharo-spur image and vm: >> >> from 17 seconds down to 10.5 >> > >> > >> > And I tried it again with cogspurlinux 3268 and the >> > trunk46-spur. That needed switching to >> > >> > MultiByteFileStream readOnlyFileNamed: >> > >> > and ran in 8.8 sec (average of three runs). Interestingly, on Pharo >> > that is significantly slower, about 15 sec. >> > >> > replacing that by StandardFileStream (and no decoding) reduced it to >> > <120 ms. >> >> Maybe using FFI to read the file in the correct format would be a nice >> option to have available. >> >> The code in the MultibyteFileStream looks quite convoluted when reading. >> >> There is reason we need a 64 it VM to read a UTF8 file fast. (8secs >> really does not qualify) >> >> Opinions? >> >> Phil >> >> > >> > Stephan >> > >> > >> > [1 to: 10 do: [:j | |a length| >> > length := 0. >> > a := >> > (MultiByteFileStream readOnlyFileNamed: >> '/home/stephan/Downloads/jfreechart.mse') readStream contents]] >> timeToRunWithoutGC >> > >> > >> > >> > >> > >

March 17, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Nicolas Cellier

2015-03-17 19:07 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Yes indeed, first external, then internal. > Behaviour is way more important than structure. > > Both are important. Don't forget that we shall be able to understand the smallest part of the system :) > > On 17 Mar 2015, at 18:23, stepharo <stepharo(a)free.fr> wrote: > > > > Did you check it? > > It is nice now. > > > > Not a stupid template with just something that goes against any book on > OOP: violation of encapsulation. > > Let us not talk about instance variables. > > > > Stef > > > > > > Le 17/3/15 15:59, Sven Van Caekenberghe a Ã©crit : > >> All class comments seem to have been modified ? > >> Was that intentional ? > >> > >>> On 17 Mar 2015, at 15:48, GitHub <noreply(a)github.com> wrote: > >>> > >>> 15147 change class comment template > >>> https://pharo.fogbugz.com/f/cases/15147 > >> > >> > > > > > > >

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Nicolas Cellier

We can already have relatively fast UTF8 reading when the file is essentially composed of ascii. I've demonstrated this a few years ago with SqueaXtreams ( http://www.squeaksource.com/XTream/) For example, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141577… I don't want to sell SqueaXtreams, it was just an experiment, but the good ideas should be extracted, we don't have to wait for a new VM. Nicolas Cellier (eh, I now have to disambiguate, maybe i will sign NiCe...) 2015-03-17 19:58 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > Le 17 mars 2015 18:59, "Stephan Eggermont" <stephan(a)stack.nl> a Ã©crit : > > > > On 17/03/15 17:59, Stephan Eggermont wrote: > > > >> I tried the code with the latest pharo-spur image and vm: > >> from 17 seconds down to 10.5 > > > > > > And I tried it again with cogspurlinux 3268 and the > > trunk46-spur. That needed switching to > > > > MultiByteFileStream readOnlyFileNamed: > > > > and ran in 8.8 sec (average of three runs). Interestingly, on Pharo > > that is significantly slower, about 15 sec. > > > > replacing that by StandardFileStream (and no decoding) reduced it to > > <120 ms. > > Maybe using FFI to read the file in the correct format would be a nice > option to have available. > > The code in the MultibyteFileStream looks quite convoluted when reading. > > There is reason we need a 64 it VM to read a UTF8 file fast. (8secs really > does not qualify) > > Opinions? > > Phil > > > > > Stephan > > > > > > [1 to: 10 do: [:j | |a length| > > length := 0. > > a := > > (MultiByteFileStream readOnlyFileNamed: > '/home/stephan/Downloads/jfreechart.mse') readStream contents]] > timeToRunWithoutGC > > > > > > > > >

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Stephan Eggermont

On 17/03/15 19:58, phil(a)highoctane.be wrote: > Maybe using FFI to read the file in the correct format would be a nice > option to have available. File reading seems fast enough: faster than my SSD can deliver data (>1GB/s) > The code in the MultibyteFileStream looks quite convoluted when reading. Yes. > There is reason we need a 64 it VM to read a UTF8 file fast. (8secs > really does not qualify) 40MB/s (on a 4GHz i7 4790K). As far as I understand it the inner loop of this is exactly what Sista can improve. Stephan

March 17, 2015

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

by stepharo

We can add a configurationOfSpec but somebody should find the old and resurrect it. I remember that I started to remove bad dependencies Le 17/3/15 18:04, Peter UhnÃ¡k a Ã©crit : > I am assuming requiring SpecTableLayout after it is incorporated into > Spec? > There is currently no configuration for spec since it is inside the > image, so the only way would be to specify version of Pharo (i.e. it's > incorporated in version X, so the user needs at least Pharo X) or > testing whether the class already exists. > > As for overriding behavior - loading a package would rewrite existing > code. > > There may be some issues if you were to concurrently update both Spec > and your package, and then the latest would win; but there may be > better solution. > > Peter > > On Tue, Mar 17, 2015 at 5:24 PM, webwarrior <reg(a)webwarrior.ws > <mailto:reg@webwarrior.ws>> wrote: > > Created issue in fogbugz. > > Also, if I decide to distribute a library that requires > SpecTableLayout, how > to do it properly? Basically most of changes are new classes (so > may be > shipped in any package), but there is also a modification to > existing method > in SpecInterpreter. > > > > -- > View this message in context: > http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428p4812633.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 17, 2015

Need more success stories

by stepharo

Hi guys we need more success stories: You should get one in 15 min. One paragraph: Context/solution One screenshot One comment on the techno This is important. But if you do not do it I cannot do it for you and we all lose. Stef

March 17, 2015