- Pharo-users - lists.pharo.org

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Richard O'Keefe

Here's what I think. copyFrom: start to: stop " ANSI Smalltalk section 5.7.8.7, reorganised a bit. Answer a new collection containing all of the elements of the receiver between the indices start and stop inclusive in their original order. The element at index start in the receiver is at index 1 in the result, the element at index start+1 is at index 2, etc. If stop < start, the new collection is emptyy. Otherwise, the size of the new collection is the maximum of (stop - start + 1) and 0. The parameters start and stop must be positive integers. Errors If stop >= start and (start < 1 or start > the receiver's size). If stop >= start and (stop < 1 or stop > the receiver's size). " ((start isKindOf: Integer) and: [start positive]) ifFalse: [start error: 'not a positive integer']. ((stop isKindOf: Integer) and: [stop positive]) ifFalse: [stop error: 'not a positive integer']. ^stop < start ifTrue: [self copyEmpty] ifFalse: [(start between: 1 and: self size) ifFalse: [start error: 'index out of range']. (stop between: 1 and: self size) ifFalse: [stop error: 'index out of range']. self from: start to: stop collect: [:each | each]] allButFirst ^self allButFirst: 1 allButFirst: count ^self copyFrom: count + 1 to: self size allButLast ^self allButLast: 1 allButLast: count ^self copyFrom: 1 to: self size - count first: count "(x first: n) , (x allButFirst: n) = x and: [(x first: n) size = n]" ^self copyFrom: 1 to: count last: count "(x allButLast: n) , (x last: n) = x and: [(x last: n) size = n]" ^self copyFrom: self size - count to: self size See the comments in #first: and #last: ? In order to program effectively, I need operations with *simple* specifications. "seq first: n returns the first n elements of seq or it's an error" "seq last: n returns the last n elements of seq or it's an error" This has the virtue of making these pretty redundant operations fully consistent with #copyFrom:to: On Fri, 30 Aug 2019 at 19:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() Â» > > The question is then, who is right? > > Should #allButFirst: with an argument greater than the collection size > raise an error > > Or > > Should #allButFirst: with an argument greater than the collection size > returns an empty collection ? > > I asked a few people about it @ ESUG and it appears that the expected > behaviour from #allButFirst: is not the same to all people. > > We need to decide so we improve consistence of collections. > > And then, we need to document that with a test :-). > > Cheers. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > >

Sept. 2, 2019

Re: [Pharo-users] Connection Timed Out

by horrido

This didn't fix the issue. It's not a matter of adjusting timeout values. However, I believe I've resolved the matter, more or less. You see, I think the problem is with Gmail... My Teapot application is using ZdcSecureSMTPClient>>sendUsingGmailAccount:password:to:message:. For whatever reason, Gmail is taking to long to respond. In the main thread, timeout causes the network to report a timeout error to the web browser. It seems that the Pharo application cannot capture this. But if I fork a process to do the sendUsingGmailAccount function, Pharo does capture this...a debug window opens with the timeout error message. The debug window tells me that it's timing out on waiting for data on the socket. Fortunately, the debug window does not prevent the Pharo application from continuing normally. So I can live with this. The alternative is to NOT use Gmail as a SMTP relay and *manually* send emails to my recipients. However, this would be extremely tedious and error-prone. I'll play it by ear. If the timeouts and debug windows prove to be problematic, I can fall back on manual emailing. Such is life in the world of networking. horrido wrote > I did a bit of research on the web and I discovered that nginx can be > unreliable due to default or inappropriate settings for certain timeout > values. Currently, I'm testing a possible fix: set /keepalive_timeout/ to > 90, rather than the default 65. So far, it seems to work, but I need > further > testing. > > > > Ben Coman wrote >> On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng < > >> horrido.hobbies@ > >> > >> wrote: >> >>> I have a Teapot application running under Linux and nginx. From time to >>> time, I get the following error: *ConnectionTimedOut: Data receive timed >>> out.* >>> >>> Otherwise, the Teapot application works fine, even with this error >>> message. >>> >>> Can anyone tell me what or where it's timing out, and how can I change >>> the >>> timeout value? >>> >> >> I'm not familiar with Teapot, but a screen snapshot might help. >> Hopefully someone else has some ideas. >> >> cheers -ben > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 1, 2019

Re: [Pharo-users] New Streams & Converters

by Sven Van Caekenberghe

Given a binary stream, you wrap it to decode it: (ZnCharacterReadStream on: binaryStream encoding: #iso88592) upToEnd. There is also #readStreamEncoded:do: directly on FileReference. > On 1 Sep 2019, at 06:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > How would I do the following with the new streams (was working in 6.1, now > "Instance of ZnCharacterReadStream did not understand #converter:"): > aFileRef readStreamDo: [ :str | > str > converter: ISO88592TextConverter new; > upToEnd ]. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 1, 2019

New Streams & Converters

by Sean P. DeNigris

How would I do the following with the new streams (was working in 6.1, now "Instance of ZnCharacterReadStream did not understand #converter:"): aFileRef readStreamDo: [ :str | str converter: ISO88592TextConverter new; upToEnd ]. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 1, 2019

Re: [Pharo-users] VW vs Pharo Performance

by Ben Coman

On Sat, 31 Aug 2019 at 20:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> > wrote: > > > > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > > > Is VisualWorks really faster than Pharo? Why??? > > The Pharo code is single threaded, single core, while the VW code uses > something called MatriX.VirtualMachines to create workers that run on > multiple cores. > > Presumably that makes a huge difference. > > Also, such parallelism is easy for benchmarks that can be split in > independent tasks, real world code is a completely different story. > > Basically, this is not the same code that is being compared. > Thanks Sven for this insight. It wold not have occurred to me. Looking at the results with new eyes, I notice its apparent in the sum activity of the four processors - averaging around 103% (including non-Pharo tasks) for Pharo testing and much more for VisualWorks. Normalizing CPU usage I get these comparative results (smaller is faster VW). 0.86 fasta 0.93 binary-trees 1.02 fannkuch-redux 1.02 reverse-complement 1.08 pidigits 1.09 spectral-norm 1.44 n-body 1.49 k-nucleotide So VW is 20% faster on some, 40% slower on others and most are pretty close. Although such a Matrix feature would be advantageous for some domains - just need someone to invent similar for Pharo. cheers -ben

Sept. 1, 2019

R: VW vs Pharo Performance

by Lorenzo Schiavina

Ciao Giorgio, vedo che sei sempre sulla braccia; perchÃ© non ci sentiamo per mettere insieme due vecchiaie? Lorenzo Da: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] Per conto di giorgio ferraris Inviato: sabato 31 agosto 2019 17:48 A: Any question about pharo is welcome Oggetto: Re: [Pharo-users] VW vs Pharo Performance hello, Test seems old, both virtual machines (VW and Pharo) have upgraded in the meantime. VW has always been faster that Pharo for what I know, up to recent time. Recently Pharo changed the vm technology so now it should be much faster, but I don'r know is faster that VW , so it would be nice to have a up to date comparison. Related to Matrix, this is a nice way to have many smalltalk images running in parallel, but it doesn't seems the case of this test. It requires a specific way of writing the code, it is not as automatic as defining a piece of code "parallel". The thread model of VW and Pharo are still the same, green thread and (almost) single core systems ciao giorgio On Sat, Aug 31, 2019 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > Is VisualWorks really faster than Pharo? Why??? The Pharo code is single threaded, single core, while the VW code uses something called MatriX.VirtualMachines to create workers that run on multiple cores. Presumably that makes a huge difference. Also, such parallelism is easy for benchmarks that can be split in independent tasks, real world code is a completely different story. Basically, this is not the same code that is being compared.

Aug. 31, 2019

Re: [Pharo-users] VW vs Pharo Performance

by giorgio ferraris

hello, Test seems old, both virtual machines (VW and Pharo) have upgraded in the meantime. VW has always been faster that Pharo for what I know, up to recent time. Recently Pharo changed the vm technology so now it should be much faster, but I don'r know is faster that VW , so it would be nice to have a up to date comparison. Related to Matrix, this is a nice way to have many smalltalk images running in parallel, but it doesn't seems the case of this test. It requires a specific way of writing the code, it is not as automatic as defining a piece of code "parallel". The thread model of VW and Pharo are still the same, green thread and (almost) single core systems ciao giorgio On Sat, Aug 31, 2019 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> > wrote: > > > > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > > > Is VisualWorks really faster than Pharo? Why??? > > The Pharo code is single threaded, single core, while the VW code uses > something called MatriX.VirtualMachines to create workers that run on > multiple cores. > > Presumably that makes a huge difference. > > Also, such parallelism is easy for benchmarks that can be split in > independent tasks, real world code is a completely different story. > > Basically, this is not the same code that is being compared. > > >

Aug. 31, 2019

Re: [Pharo-users] VW vs Pharo Performance

by Sven Van Caekenberghe

> On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > Is VisualWorks really faster than Pharo? Why??? The Pharo code is single threaded, single core, while the VW code uses something called MatriX.VirtualMachines to create workers that run on multiple cores. Presumably that makes a huge difference. Also, such parallelism is easy for benchmarks that can be split in independent tasks, real world code is a completely different story. Basically, this is not the same code that is being compared.

Aug. 31, 2019

VW vs Pharo Performance

by Richard Kenneth Eng

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… Is VisualWorks really faster than Pharo? Why???

Aug. 31, 2019

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Kasper Ãsterbye

I always like to find a way not to make the choice. #(1 2) allButFirst: 3 ifInsufficient: [â¦] allButFirst: N ^self allButFirst: N ifInsufficent: [ âfight about this"]. â Kasper On 30 August 2019 at 12.28.14, Cyril Ferlicot (cyril.ferlicot(a)gmail.com) wrote: On Fri 30 Aug 2019 at 09:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() Â» > > The question is then, who is right? > > Should #allButFirst: with an argument greater than the collection size > raise an error > > Or > > Should #allButFirst: with an argument greater than the collection size > returns an empty collection ? > > I asked a few people about it @ ESUG and it appears that the expected > behaviour from #allButFirst: is not the same to all people. > > We need to decide so we improve consistence of collections. > > And then, we need to document that with a test :-). > Hi, I was one of the person who discussed this with Julien at ESUG and IMO it should launch an error. While working on complexe models, errors in such cases are really really really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound help me a lot to find bugs and sometimes without this kind of methods it could have take me days to find the problem (and itâs only in the case I know there is a bug). > Cheers. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > Villeneuve > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > d'Ascq > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 30, 2019