September 2019 - Pharo-users

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