September 2019 - Pharo-users

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

by John Pfersich

+100. Smalltalk for me is a hobby which comes after the music (guitar and keyboards) and gun habits. I used to code in Smalltalk professionally, but havenât had a paid job in 26 years. I used to produce code for Squeak back in the early 2000âs, but stopped because my code never made it into the image that I know of. I just code for myself now. /ââââââââââââââââââââ/ For encrypted mail use jgpfersich(a)protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org > On Sep 3, 2019, at 04:39, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Ad 1. > To cut a long story short, > the ANSI Smalltalk standard is the nearest thing we have to a clear specification > of the nearest thing we have to a consensus. > One of the reasons that Smalltalk gets less use than many of us would like > is that it can be extremely unpleasant trying to port from one dialect of > Smalltalk to another, so you have to commit to a dialect. > And dialects of Smalltalk have an unpleasant habit of disappearing. > I really liked Ambrai. What was I to do with my Ambrai code when > Ambrai disappeared? > I have never met a better-looking Smalltalk than Dolphin. > ObjectArts stopped selling Dolphin a year or two ago, and open sourced it. > Today the ObjectArts website has an expired certificate, > pages have the date 2016 on them, > and the GitHub link points to a GitHub site containing an Amber fork > but no Dolphin. > Imagine my relief at discovering that Dolphin *is* still being maintained, > it's just not where ObjectArts said it was. But I am worried about > whether I should bother with it any more. > Then there's ST/X. > ... > > Code written for C99 is still useful. > I have four different C compilers and I don't have to care which one I use. > > Code written for Fortran95 is still useful (and yes I know about Fortran 2018). > I have two different Fortran compilers; the one that does the best job handles > Fortran 2003 but not 2008 or 2018, and as long as I stick to 2003 I don't have > to care which I use. > > The Common Lisp standard came out in 1994 and the HyperSpec is still useful > to me for writing Lisp today. > My copy of Common Lisp the Language, 2nd edition, is still useful to me. > > Ad 2. > In the Pharo 7.0 sources there are on the order of 600 senders of #signal[:] > -- exceptions and semaphores both use #signal so this is approximate -- > and on the order of 1000 senders of #error:, which really should be > exceptions. (It is surprisingly hard to make this change.) The newer > components use exceptions a lot more than the old ones. > Of course some exceptions (like subscript out of bounds) are raised > inside primitives, which Ctrl-N doesn't show you. > > One quite strange thing about the ANSI Smalltalk standard is that it > introduced an elaborate exception-handling system into the language > -- much more complicated than C++ or Java or Ada -- but introduced > almost no standard exceptions that a portable program could catch. > Let's take one consequence of this. > What does > (OrderedCollection withAll: #[3 1 4 1 5 9]) copyFrom: 2.5 to: 4.2 > do? > My Smalltalk: currently reports 'bad start' coming from the call to > #copyFrom:to: with culprit 2.5. > This is going to be an IndexError some day; cleaning > up the code to use well-chosen exceptions is a mammoth task. > > Squeak: 'Array called #basicNew: with invalid argument 2.7' > Of course there is no 2.7 in our code... > > Pharo: 'PrimitiveFailed: primitive #basicNew: in Array class failed' > > VW: 'Unhandled exception: This message needs a positive integer argument' > appearing to come from OrderedCollection>>new: > > VisualAge Smalltalk: drops you into a debugger with no actual explanation; > the only number in sight is 2.7, which is not one of the numbers we provided. > > GNU Smalltalk: 'Object: 1 error: The program attempted to divide a number by zero'. > I kid you not. > > Exceptions could be useful IF you knew what to catch. > > Just for grins, sending #copyFrom:to: to an OrderedCollection with a start > or stop value out of range raises an ExCLDTIndexOutOfRange exception but > sending it to an Array with the same contents does not. > > Ad 3. > allButFirst: n ^self copyFrom: n+1 to: self size > and then ask what #copyFrom:to: should do. > > This is actually one tiny symptom of a pervasive issue in Smalltalk. > When commercial Smalltalks are riddled with not-quite-working and/or > not-self-consistent stuff in basic classes, what can we expect from > an open source project, unless someone is prepared to donate serious > money for a cleanup? > > >> On Tue, 3 Sep 2019 at 04:01, Kasper Ãsterbye <kasper.osterbye(a)gmail.com> wrote: >> This is actually an intersting discussion. There are several levels to it. >> >> 1. Should Pharo be compatible with a standard from 1998? >> 2. What is the general view on using exceptions in Pharo? >> 3. What should allButFirst: do? >> >> Ad 1) I am relatively new to Pharo, If backwards compatibility is important, it should adhere to the standard and the spirit of the standard. If we want a different semantics in some areas, it seems like new methods are needed, with names which is not confused with existing standard. >> >> Ad 2) I am so new to Pharo I do not even know how efficient (or expensive) exceptions are in Pharo. In most programming languages they are expensive, and should not be used as an alternative to an if statement. My views on exceptions are very influenced by Bertrand Meyer, which lead me to the view that a) Asking for the all but the first three elements of a two element array is most likely a broken pre-condition. Hence an error. b) As it is the clients responsibility to ensure precondition, we might as well help the client of the collection by offering an other method with a different pre-condition. >> >> Ad 3. Should follow from the first two :-) >> >> Best, >> >> Kasper

Sept. 4, 2019

Re: [Pharo-users] Connection Timed Out

by horrido

Since JRMPC opens for registration in three days, I can't afford to screw around with the web server at this late date. Had I known about this issue earlier in the year (say, May or June), I could've dealt with it then. All I'm looking for is a workaround, a duct tape solution. Sven Van Caekenberghe-2 wrote >> On 1 Sep 2019, at 23:06, horrido < > horrido.hobbies@ > > wrote: >> >> 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. > > Of course you can deal with it, if you want to. > > An HTTP server handling a request should do so fairly quickly, else > clients will become unhappy. The client might automatically give up and > close the connection. > > Doing a (possibly) long running operation while handling a request is, > like you noticed yourself, dangerous. > > A Zn HTTP Server (like the one used by Teapot) can operate in 2 modes: in > debug mode and in production mode. In debug mode an unexpected error while > handling a request will result in a debugger. In production mode, that > same exception will result in an HTTP 500 Server error with the exception > printString. Production mode is the default. > >> 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 >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 3, 2019

Re: [Pharo-users] Connection Timed Out

by Sven Van Caekenberghe

> On 1 Sep 2019, at 23:06, horrido <horrido.hobbies(a)gmail.com> wrote: > > 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. Of course you can deal with it, if you want to. An HTTP server handling a request should do so fairly quickly, else clients will become unhappy. The client might automatically give up and close the connection. Doing a (possibly) long running operation while handling a request is, like you noticed yourself, dangerous. A Zn HTTP Server (like the one used by Teapot) can operate in 2 modes: in debug mode and in production mode. In debug mode an unexpected error while handling a request will result in a debugger. In production mode, that same exception will result in an HTTP 500 Server error with the exception printString. Production mode is the default. > 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. 3, 2019

Re: [Pharo-users] Connection Timed Out

by Sven Van Caekenberghe

> On 3 Sep 2019, at 00:54, Jeff Gray <jeff(a)rogerthedog.com> wrote: > > Have you tried manually opening up the gmail account you are sending from in > the browser and looking for anything funny? I have had similar issues where > the gmail was needing a security prompt/response. > I wrote a service to send mails asynchronously (in case the gmail connection > was down and generally to give a speedy UI response) using the > ZdcSecureSMTPClient, which is working like a charm. If possible, it would be interesting for the community to learn about this. Especially dealing with success/failure is important once you operate asynchronously.

Sept. 3, 2019

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

by Richard O'Keefe

Ad 1. To cut a long story short, the ANSI Smalltalk standard is the nearest thing we have to a clear specification of the nearest thing we have to a consensus. One of the reasons that Smalltalk gets less use than many of us would like is that it can be extremely unpleasant trying to port from one dialect of Smalltalk to another, so you have to commit to a dialect. And dialects of Smalltalk have an unpleasant habit of disappearing. I really liked Ambrai. What was I to do with my Ambrai code when Ambrai disappeared? I have never met a better-looking Smalltalk than Dolphin. ObjectArts stopped selling Dolphin a year or two ago, and open sourced it. Today the ObjectArts website has an expired certificate, pages have the date 2016 on them, and the GitHub link points to a GitHub site containing an Amber fork but no Dolphin. Imagine my relief at discovering that Dolphin *is* still being maintained, it's just not where ObjectArts said it was. But I am worried about whether I should bother with it any more. Then there's ST/X. ... Code written for C99 is still useful. I have four different C compilers and I don't have to care which one I use. Code written for Fortran95 is still useful (and yes I know about Fortran 2018). I have two different Fortran compilers; the one that does the best job handles Fortran 2003 but not 2008 or 2018, and as long as I stick to 2003 I don't have to care which I use. The Common Lisp standard came out in 1994 and the HyperSpec is still useful to me for writing Lisp today. My copy of Common Lisp the Language, 2nd edition, is still useful to me. Ad 2. In the Pharo 7.0 sources there are on the order of 600 senders of #signal[:] -- exceptions and semaphores both use #signal so this is approximate -- and on the order of 1000 senders of #error:, which really should be exceptions. (It is surprisingly hard to make this change.) The newer components use exceptions a lot more than the old ones. Of course some exceptions (like subscript out of bounds) are raised inside primitives, which Ctrl-N doesn't show you. One quite strange thing about the ANSI Smalltalk standard is that it introduced an elaborate exception-handling system into the language -- much more complicated than C++ or Java or Ada -- but introduced almost no standard exceptions that a portable program could catch. Let's take one consequence of this. What does (OrderedCollection withAll: #[3 1 4 1 5 9]) copyFrom: 2.5 to: 4.2 do? My Smalltalk: currently reports 'bad start' coming from the call to #copyFrom:to: with culprit 2.5. This is going to be an IndexError some day; cleaning up the code to use well-chosen exceptions is a mammoth task. Squeak: 'Array called #basicNew: with invalid argument 2.7' Of course there is no 2.7 in our code... Pharo: 'PrimitiveFailed: primitive #basicNew: in Array class failed' VW: 'Unhandled exception: This message needs a positive integer argument' appearing to come from OrderedCollection>>new: VisualAge Smalltalk: drops you into a debugger with no actual explanation; the only number in sight is 2.7, which is not one of the numbers we provided. GNU Smalltalk: 'Object: 1 error: The program attempted to divide a number by zero'. I kid you not. Exceptions could be useful IF you knew what to catch. Just for grins, sending #copyFrom:to: to an OrderedCollection with a start or stop value out of range raises an ExCLDTIndexOutOfRange exception but sending it to an Array with the same contents does not. Ad 3. allButFirst: n ^self copyFrom: n+1 to: self size and then ask what #copyFrom:to: should do. This is actually one tiny symptom of a pervasive issue in Smalltalk. When commercial Smalltalks are riddled with not-quite-working and/or not-self-consistent stuff in basic classes, what can we expect from an open source project, unless someone is prepared to donate serious money for a cleanup? On Tue, 3 Sep 2019 at 04:01, Kasper Ãsterbye <kasper.osterbye(a)gmail.com> wrote: > This is actually an intersting discussion. There are several levels to it. > > 1. Should Pharo be compatible with a standard from 1998? > 2. What is the general view on using exceptions in Pharo? > 3. What should allButFirst: do? > > Ad 1) I am relatively new to Pharo, If backwards compatibility is > important, it should adhere to the standard and the spirit of the standard. > If we want a different semantics in some areas, it seems like new methods > are needed, with names which is not confused with existing standard. > > Ad 2) I am so new to Pharo I do not even know how efficient (or expensive) > exceptions are in Pharo. In most programming languages they are expensive, > and should not be used as an alternative to an if statement. My views on > exceptions are very influenced by Bertrand Meyer, which lead me to the view > that a) Asking for the all but the first three elements of a two element > array is most likely a broken pre-condition. Hence an error. b) As it is > the clients responsibility to ensure precondition, we might as well help > the client of the collection by offering an other method with a different > pre-condition. > > Ad 3. Should follow from the first two :-) > > Best, > > Kasper >

Sept. 3, 2019

Re: [Pharo-users] Exercism - creating fresh image with previously submitted exercises

by Tim Mackinnon

Iâve replied to David in discord - but in case anyone else comes looking - the upgrade path for the first versions of exercism is documented in the instruction for Pharo in the exercism track. This should resolve most problems listed below. The move to a package per exercise was driven by discussion with the board here about Pharo direction and concepts - and we were guided to move to using more packages in order to cleanly support extension methods in exercises (something that comes up in a number of exercises, and was a common feature request). It also allows us to more easily supply lint rules per exercise and a number of other smaller features. Unfortunately it does make it more painful to load old exercises into a fresh image (they are always visible online in your account). A feature request to gather old submissions and load them is a good one - itâs not so hard, and maybe someone can offer to do that for us (progress has been limited due to new job constraints at the moment). We are always on the lookout for more mentors to help us feedback on user submissions, and there are also more exercises to convert (weâve done about half so far) Tim Sent from my iPhone > On 30 Aug 2019, at 10:09, DavidBajger <bajger(a)gmail.com> wrote: > > Hi Tim & Pharo Exercism contributors! I had a chance to come back to my exercism challenges and tried to create new image for continuing on solutions. I've tried to load manually previously submitted/completed exercises into fresh image (with Exercism loaded) and found few issues. Here is my list: > Batch loading > 1) It would be great to have menu item to "Batch load already submitted exercises", so I should create issue on Github for this enhancement, right? > > Renamed exercises > 2) I faced few challenges when loading my already posted exercises and one of them was renamed package and class. My old solution was in different package and class was named differently too, so I had to rename class with solution to new name, so the tests would be green again. I had to move class to new package as well. Examples are: ResistorColorDuo(new class name) <-> ResistorColors (old) MatchingBrackets(new class name) <-> BracketPush(old) Is there a way, to have some migration mechanism as part of loading the exercise into image, which would rename class (and package) automatically and resubmit solution again? > > Loading subclasses with missing references to superclass > 3) Some of my solutions are using more classes and sub-classes, for some reason loading such exercise failed, because it tried to load subclass first without having superclass loaded. So workaround for this was to create superclass as stub manually and load exercise again. I had to move classes to correct package, but somehow I struggle to understand what is really right package name (screenshots below). > > Exercises in independent packages > 4) Old way of organizing Exercism exercises was using package extension of package Exercism, which I found a bit more well-arranged than using package for each exercise. Is there a reason for having each exercise in standalone package? I guess there is a good reason for that. > > > Thanks for your insights! > David > David Bajger > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 3, 2019

Re: [Pharo-users] Connection Timed Out

by Jeff Gray

Have you tried manually opening up the gmail account you are sending from in the browser and looking for anything funny? I have had similar issues where the gmail was needing a security prompt/response. I wrote a service to send mails asynchronously (in case the gmail connection was down and generally to give a speedy UI response) using the ZdcSecureSMTPClient, which is working like a charm. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 2, 2019

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

by Kasper Ãsterbye

This is actually an intersting discussion. There are several levels to it. 1. Should Pharo be compatible with a standard from 1998? 2. What is the general view on using exceptions in Pharo? 3. What should allButFirst: do? Ad 1) I am relatively new to Pharo, If backwards compatibility is important, it should adhere to the standard and the spirit of the standard. If we want a different semantics in some areas, it seems like new methods are needed, with names which is not confused with existing standard. Ad 2) I am so new to Pharo I do not even know how efficient (or expensive) exceptions are in Pharo. In most programming languages they are expensive, and should not be used as an alternative to an if statement. My views on exceptions are very influenced by Bertrand Meyer, which lead me to the view that a) Asking for the all but the first three elements of a two element array is most likely a broken pre-condition. Hence an error. b) As it is the clients responsibility to ensure precondition, we might as well help the client of the collection by offering an other method with a different pre-condition. Ad 3. Should follow from the first two :-) Best, Kasper

Sept. 2, 2019

SLE 2019: Call for Endorsements - Most Influential Paper (MIP) Award

by Andrei Chis

------------------------------------------------------------------------ Call for Endorsements: ACM SIGPLAN International Conference on Software Language Engineering (SLE) - Most Influential Paper Award SLE MIP Awards: http://www.sleconf.org/mip Follow us on twitter: https://twitter.com/sleconf SLE 2019: https://conf.researchr.org/home/sle-2019 ------------------------------------------------------------------------ Starting in 2019, the ACM SIGPLAN International Conference on Software Language Engineering (SLE) delivers annually an award to the Most Influential Paper (MIP) presented at the SLE conference held 10 years prior to the award year. The SLE MIP Award distinguishes the authors of the paper having the greatest impact (either scientific, societal or industrial). The papers are judged by their influence over the past decade. The SLE MIP Award is delivered by the current members of the Steering Committee (SC) of the conference, considering: i) endorsements from the community, and ii) the synthesis of some facts and metrics collected in advance by selected SC members. The vote is by majority of the SC members, after a discussion during the online meetings. Authors are informed at once, and awarded at the coming conference. In 2019 we offer two awards: one for the authors of the MIP from the 2009 program (http://www.sleconf.org/2009/Program.html) and another one for the authors of the MIP from the 2008 program (http://www.sleconf.org/2008/program.html) back to the first edition of the conference. SLE MIP Award 2019: - Program SLE 2009: http://www.sleconf.org/2009/Program.html; - Endorsement: http://tiny.cc/slemip2019 (deadline: Sep. 20th, 2019) SLE MIP Award 2018: - Program SLE 2008: http://www.sleconf.org/2008/program.html; - Endorsement: http://tiny.cc/slemip2018 (deadline: Sep. 20th, 2019)

Sept. 2, 2019

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

by Richard O'Keefe

I didn't join all the dots. My point is that [all] but {first,last} have simple definitions in terms of #copyFrom:to: and that if you want to make them accept oversize counts, you either have to change the definition of #copyFrom:to: (bad idea) or cut these methods loose from #copyFrom:to: and define them in terms of something else. I should also explain that there are at least four plausible definitions: (1) 'the first n elements of x' is exactly n elements long (current Squeak and Pharo 8) (2) 'the first n elements of x' is (x size min: n) elements long (3) 'the first n elements of x' is exactly |n| elements long; it's the first n if n >= 0 or the last |n| if n <= 0. (34 'the first n elements of x' is exactly n elements long and if x size < n the last n - x size elements are the default value for n (nil for objects, zero for numbers, blank for characters). Number (3) is the original APL\360 definition found in the 1968 manual from IBM. While the sign dependence wrecks the lovely v = (n .take v) , (n .drop v) property, APL wants to let you pick *any* corner of an array with *any* number of subscripts in a single operator. Number (4) is the definition found in the APL standard (the 1993 draft, anyway). My resolution was to say that #first: (#last:) and #take: are DIFFERENT operations, where take: n ^n positive ifTrue: [self first: (self size min: n)] ifFalse: [self last: (self size min: n negated)] drop: n ^n positive ifTrue: [self allButFirst: (self size min: n)] ifFalse: [self allButLast: (self size min: n negated)] They are different because they have different preconditions and postconditions. Why did I not follow APL more closely? Because I tried hard to define a #defaultElement for sequences and failed to come up with anything coherent. Also, APL is just as happy with floating point counts as with integer ones, provided they are close enough to integral. I should also point out that Pharo 8 does not respect the ANSI semantics of #copyFrom:to:. Example: 'abc' copyFrom: 6 to: 0 should, according to the common specification, answer ''. The result is instead a primitive failure in #basicNew:, of all things. On Mon, 2 Sep 2019 at 20:37, Richard O'Keefe <raoknz(a)gmail.com> wrote: > 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