March 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Issues with recent Pharos reading files

by Andrew P. Black

> On 21 Mar 2018, at 10:07 , Alistair Grant <akgrant0710(a)gmail.com> wrote: > > But to help track down your issue, maybe temporarily replace the code with: > > <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' error: > errorCode > > errorCode ifNotNil: [self halt: errorCode asString]. > ^ #badDirectoryPath > > > That should allow you to track down the issue a bit more. > > P.S. If the primitive really is missing, errorCode will be #'not found'. I still got #badDirectoryPath, so I assumed that the primitive was there, and was just returning the wrong answer. The question then became: why? After some hours spent investigating, I figured out what is going on. Here is the story. The new file streams have behaviour that differs in several respects from the old ones. Here are three things that affected my application: 1. sending #readstream to an old file stream answered self; with the new ones, I get a MNU. 2. closing a stream that that already been closed used to be a no-op; now it causes a primitive failure walkback. 3. Repositioning a filestream stream doesnât work. Unfortunately, sending #position: doesnât fail immediately, but the effect in my app (a compiler) is that the file Iâm reading appears to be empty. Now for the interesting bit. Because the file appeared empty, my tests opened the default prelude file. This also appeared to be empty, so it opened the default prelude file again, while it was still open the first time. This continued indefinitely â presumably, until some resource in the plugin was exhausted. Once that happened, the plugin was permanently broken. Probably the unwind machinery should have released the resource, but it didnât, probably because the resource is in the plugin, not in Pharo. You can argue that (1) is the desired behaviour, but it is atypical. Sending #asString to a String, #asNumber to a Number, or #asSet to a Set all return self. I think that sending #readStream to a ReadStream should likewise answer self. It used to. You can argue that (2) ought to fail, and Iâll probably agree with you. However, the failure should be a clean one (âattempt to close a stream that has already been closedâ), not a primitive failure. And then /all/ streams should behave that way, and there should be a #closeIfNecessary operation that does what #close used to do. Incidentally, the predicate that tests whether a stream is closed is named #closed; it should be named #isClosed. (3), as already been discussed here, is just wrong. If a stream has a #position: method, it should work. If we need another wrapper to implement it, so be it. If #position: canât be implemented for a particular kind of stream (e.g., an interactive input stream), then the method either should not be present at all, or should unconditionally raise an exception. I have not investigated exactly how #position: fails, but Iâm pretty sure that this is the culprit. If I replace the `fileStream` by `fileStream contents readStream`, everything works fine again. As for the primitive failing permanently because it runs out of resources â Iâll leave that to smarter people than me to figure out. At very least, it should produce an intelligible ResourceExhausted exception. Andrew

March 21, 2018

Re: [Pharo-users] Unable to execute example code from "The Spec UI Framework" Book

by dragoncity

You've defined this as an instance method, not a class method Thanks for that observation! On closer read indeed I had missed the 'class' word in the defaultSpec text on page 6, it took a little fiddling to get a Class method defined. Its 'almost' working :-) When I run the |ui | ... etc.... from a Playground, I don't get a working UI Form, but I get a correctly defined static image layout of the form under 'Morph' IN the Playground. I expected the CustomerSatisfaction UI form to appear as a independent item on the Pharo 'world'. Now what am I doing wrong ? :-) On 21/03/18 19:02, Alistair Grant wrote: > On 21 March 2018 at 08:37, dragoncity <dragoncitybrett(a)gmail.com> wrote: >> I had already defined & accepted defaultSpec , as per page 6. >> >> Attached is my CustomerSatisfaction.st file : I assume Pharo will suck it >> back in ! > You've defined this as an instance method, not a class method. > > If what I've said doesn't make sense, let us know and we can point you > to a description (which I don't have handy). One tip: Assuming you're > using Pharo 6, in the System Browser, roughly in the middle is a > "Class" button. Pressing that will show you the class methods. > > HTH, > Alistair > > > >> On 21/03/18 17:55, Alistair Grant wrote: >>> On 21 March 2018 at 03:12, dragoncity <dragoncitybrett(a)gmail.com> wrote: >>>> Hello, I'm just getting into Pharo, and am trying to >>>> do the example 'tutorial' UI programs in chapter 2 of The Spec UI >>>> Framework >>>> book. I have a special interest in end user GUI interfaces for programs. >>>> I >>>> enter the first example code as written and the methods are all accepted >>>> without errors. And yes, I did generate the accessors. >>>> >>>> However , on attempting to execute the code at the bottom of page 6 from >>>> the >>>> latest Spec UI Framework book, >>>> >>>> >>>> | ui | >>>> >>>> ui := CustomerSatisfaction newopenWithSpec. >>>> >>>> ui close. >>>> >>>> >>>> >>>> this error message appears, no UI image appears of course. >>>> >>>> "SubclassResponsibility:CustomerSatisfaction class had the subclass >>>> responsibility to implement #defaultSpec" >>>> >>>> ====== >>>> >>>> Not only don't I understand the message, but it implies I have to write >>>> something called #defaultSpec !, which is not mentioned in the tutorial. >>> CustomerSatisfaction is a subclass of ComposableModel >>> (ComposablePresenter in Pharo 7). If you have a look at the >>> implementation of #defaultSpec in ComposableModel or >>> ComposablePresenter (depending on which version of Pharo you are >>> using) it says that it is up to subclasses to implement the method >>> (#subclassResponsibility). Since you haven't defined it (yet), the >>> call to #defaultSpec uses the inherited definition from >>> ComposableModel, which raises the error you are seeing. >>> >>> CustomerSatisfaction class>>defaultSpec is on page 6 of my version of >>> the booklet, dated Feb 6, 2107. >>> >>> >>> Cheers, >>> Alistair >>> >>> >> -- >> Cheers, >> Brett >> > -- Cheers, Brett

March 21, 2018

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

by Guillermo Polito

Hi all, Don't forget also that this are the low level bricks used in Pharo. Utterly required by the bootstrap and the minimal image, thus keeping dependencies small and controlled is a big +. Magic and automatic stuff can be added on top. Nothing prevents to add a little layer on top as a separate library (I even encourage people to do so!) adding a builder, or a DSL to ease the construction of streams in the most performant way possible. Pharo has extension methods, and even this could be done with some extra objects managing the creation of the stream without being too complex. Guille On Tue, Mar 20, 2018 at 3:12 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 20 Mar 2018, at 14:51, Andrew P. Black <apblack(a)pdx.edu> wrote: > > > > I like the structure of streams wrapping streams from the point of view > of modularity of implementation and flexibility of reuse (as in applying > buffering and encoding to in-memory or network streams). > > > > But I donât like exposing al the machinery to the user. For example, > instead of > > > > bufferedReadStream := ZnBufferedReadStream on: aReadStream. > > bufferedWriteStream := ZnBufferedWriteStream on: aWriteStream. > > > > why not > > > > bufferedReadStream := ZnBuffer on: aReadStream. > > bufferedWriteStream := ZnBuffer on: aWriteStream > > > > where the class that implements the buffering looks at the stream and > decides whether to do read or write buffering (or both, for a read-write > stream). > > Hmm, then I would prefer real object messages, like #buffered not class > facades. > > > The meaning of #position: on an encoded Unicode stream is perfectly > well-defined. Itâs just not the same as the meaning of position on the > underlying byteStream â one counts in codePoints, the other in bytes. > > Yes, agreed. > > > The old file streams got this wrong; Iâm hoping that the new ones get it > right. However, the comment that > > > > "As a side note: using #size and #position[:] on variable encoded > streams > > like UTF8 is *very* dangerous and should be avoided.â > > > > makes me worry that they do not. Please, either implement #size and > #position[:] correctly on the encoded stream, or donât implement them at > all! Do *not* implement them incorrectly, and then tell me to avoid them > because they are dangerous! > > Well, I will repeat my opinion: #size #position #position: #reset have no > place in streams. > > I have an experimental implementation of a ZnPositionableReadStream that > adds 'excursion behaviour' as an add-on on top of more primitive streams > that do not. It allows for code like > > stream savingPositionDo: [ "read ahead" ]. > "continue reading as if noting happened" > > Here is the class comment. > > I am ZnPositionableReadStream. > I am polymorphic with (the most used/important methods of) ReadStream and > PositionableStream. > > I wrap another read stream and store the elements that I read in a sliding > circular buffer so that I am able to go back to any position inside that > buffer. > > Essentially, I implement #position and #position: to be used to back out > of reading ahead. > > Note that the size of my buffer limits how far I can go backwards. A > SubscriptOutOfBounds exception will be signalled when an attempt is made to > go too far backwards. > > The index returned by #position should be considered abstract, without > concrete meaning, but it is currently implemented as the count of elements > read by #next on the wrapped stream. On a simple stream over an in memory > collection, that will be equivalent to an integer index into that > collection. But on network streams or streams that were already further > along, this will no longer be the case. > > The most elementary example of my capabilities can be seen in my > implementation of #peek. See also the unit tests #testPlainExcursion and > #testSearch > > Of course, backing out of an excursion is only possible within the window > of the buffer size. > > Implementation > > - stream <ReadStream> the read stream that I wrap and add positioning to > - buffer <String|ByteArray> sliding, circular buffer > - index <PositiveInteger> zero based index into buffer, where next will be > stored > - count <PositiveInteger> number of next operations done on wrapped stream > - delta <PositiveInteger> number of positions that I was moved backwards > > The real core methods are #next, #atEnd, #position and #position: and are > used to implement the rest. > > Part of Zinc HTTP Components > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 21, 2018

Re: [Pharo-users] Issues with recent Pharos reading files

by Guillermo Polito

On Wed, Mar 21, 2018 at 9:51 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > I'll fix smalltalk CI code for Pharo 7 to use the new class. That will > solve the problems in travis builds. > Aaand, fix in here, awaiting for integration: https://github.com/hpi-swa/smalltalkCI/pull/361 > > @Andrew, about the directories issue, can you provide me a full stack > trace and even better a way to reproduce it? > > @CÃ©drik, kind of the same, if you provide a proper issue (or even a test > case?) that would be a real time saver. > > Issues that are arising now are because there are parts of the system that > were badly tested or not tested at all, so ... > > Tx all, > Guille > > On Tue, Mar 20, 2018 at 10:07 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> Hi Andrew, >> >> On 20 March 2018 at 21:42, Andrew P. Black <apblack(a)pdx.edu> wrote: >> > >> >> On 21 Mar 2018, at 03:15 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> >> >> >> >>> On 20 Mar 2018, at 14:36, Andrew P. Black <apblack(a)pdx.edu> wrote: >> >>> >> >>> Iâm having trouble reading files with the most recent âstableâ >> versions of Pharo. >> >> >> >> OK, this is no answer to your issue, but Pharo 7 latest is far from >> stable, it is intentionally the development head. >> >> >> >> It is very good that you test it and help out, more eyes and all that, >> but using it is at your own risk, there are no promises about stability. >> > >> > I understand this. The point of my post was to try and diagnose the >> issue and help make Pharo 7 more stable. >> > >> > Does my diagnosis of a missing or outdated primitive look reasonable? >> >> Not really :-) >> >> >> >> > If so, how do I check? >> >> If you can successfully open World Menu -> Tools -> File Browser then >> the primitive is working. >> >> >> > That is, where are is this primitive >> > >> > <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' >> error: errorCode > >> > >> > supposed to come from? Iâm guessing that there should be a file with >> âFilePluginâ somewhere in its name somewhere in one of my VMs. There isnât >> â although some older Cog vms from back in the day (Iâm talking Pharo 1.4) >> have something called >> > âlibAsynchFilePlugin.dylibâ >> >> Plugins can either be built-in or external. FilePlugin is built-in. >> >> >> > If this plugin is now essential to run Pharo, shouldnât downloading the >> launcher and using the launcher to grab a fresh image and launch it (after >> checking for the appropriate VM) be all that is required to ensure that it >> is installed? If not, what other steps should I take? >> >> The error handling in #lookupEntryIn:index: is less than ideal. I'm >> working on a replacement, so I don't think it is worthwhile spending a >> lot of time on it. >> >> This primitive returns a directory entry by index number. Just taking >> a couple of wild guesses: One possibility is that the directory was >> modified while you were iterating over the directory. I'm also not >> sure how it handles entries that you don't have permission to read. >> >> But to help track down your issue, maybe temporarily replace the code >> with: >> >> <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' error: >> errorCode > >> errorCode ifNotNil: [self halt: errorCode asString]. >> ^ #badDirectoryPath >> >> >> That should allow you to track down the issue a bit more. >> >> P.S. If the primitive really is missing, errorCode will be #'not found'. >> >> >> > Iâm getting on a l-o-n-g flight in a few hours, and would really like >> to be able to run Pharo ... >> > >> > Andrew >> >> HTH, >> Alistair >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 21, 2018

Re: [Pharo-users] Issues with recent Pharos reading files

by Guillermo Polito

I'll fix smalltalk CI code for Pharo 7 to use the new class. That will solve the problems in travis builds. @Andrew, about the directories issue, can you provide me a full stack trace and even better a way to reproduce it? @CÃ©drik, kind of the same, if you provide a proper issue (or even a test case?) that would be a real time saver. Issues that are arising now are because there are parts of the system that were badly tested or not tested at all, so ... Tx all, Guille On Tue, Mar 20, 2018 at 10:07 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Andrew, > > On 20 March 2018 at 21:42, Andrew P. Black <apblack(a)pdx.edu> wrote: > > > >> On 21 Mar 2018, at 03:15 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >> > >>> On 20 Mar 2018, at 14:36, Andrew P. Black <apblack(a)pdx.edu> wrote: > >>> > >>> Iâm having trouble reading files with the most recent âstableâ > versions of Pharo. > >> > >> OK, this is no answer to your issue, but Pharo 7 latest is far from > stable, it is intentionally the development head. > >> > >> It is very good that you test it and help out, more eyes and all that, > but using it is at your own risk, there are no promises about stability. > > > > I understand this. The point of my post was to try and diagnose the > issue and help make Pharo 7 more stable. > > > > Does my diagnosis of a missing or outdated primitive look reasonable? > > Not really :-) > > > > > If so, how do I check? > > If you can successfully open World Menu -> Tools -> File Browser then > the primitive is working. > > > > That is, where are is this primitive > > > > <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' > error: errorCode > > > > > supposed to come from? Iâm guessing that there should be a file with > âFilePluginâ somewhere in its name somewhere in one of my VMs. There isnât > â although some older Cog vms from back in the day (Iâm talking Pharo 1.4) > have something called > > âlibAsynchFilePlugin.dylibâ > > Plugins can either be built-in or external. FilePlugin is built-in. > > > > If this plugin is now essential to run Pharo, shouldnât downloading the > launcher and using the launcher to grab a fresh image and launch it (after > checking for the appropriate VM) be all that is required to ensure that it > is installed? If not, what other steps should I take? > > The error handling in #lookupEntryIn:index: is less than ideal. I'm > working on a replacement, so I don't think it is worthwhile spending a > lot of time on it. > > This primitive returns a directory entry by index number. Just taking > a couple of wild guesses: One possibility is that the directory was > modified while you were iterating over the directory. I'm also not > sure how it handles entries that you don't have permission to read. > > But to help track down your issue, maybe temporarily replace the code with: > > <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' error: > errorCode > > errorCode ifNotNil: [self halt: errorCode asString]. > ^ #badDirectoryPath > > > That should allow you to track down the issue a bit more. > > P.S. If the primitive really is missing, errorCode will be #'not found'. > > > > Iâm getting on a l-o-n-g flight in a few hours, and would really like to > be able to run Pharo ... > > > > Andrew > > HTH, > Alistair > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 21, 2018

Re: [Pharo-users] Unable to execute example code from "The Spec UI Framework" Book

by Alistair Grant

On 21 March 2018 at 08:37, dragoncity <dragoncitybrett(a)gmail.com> wrote: > I had already defined & accepted defaultSpec , as per page 6. > > Attached is my CustomerSatisfaction.st file : I assume Pharo will suck it > back in ! You've defined this as an instance method, not a class method. If what I've said doesn't make sense, let us know and we can point you to a description (which I don't have handy). One tip: Assuming you're using Pharo 6, in the System Browser, roughly in the middle is a "Class" button. Pressing that will show you the class methods. HTH, Alistair > On 21/03/18 17:55, Alistair Grant wrote: >> >> On 21 March 2018 at 03:12, dragoncity <dragoncitybrett(a)gmail.com> wrote: >>> >>> Hello, I'm just getting into Pharo, and am trying to >>> do the example 'tutorial' UI programs in chapter 2 of The Spec UI >>> Framework >>> book. I have a special interest in end user GUI interfaces for programs. >>> I >>> enter the first example code as written and the methods are all accepted >>> without errors. And yes, I did generate the accessors. >>> >>> However , on attempting to execute the code at the bottom of page 6 from >>> the >>> latest Spec UI Framework book, >>> >>> >>> | ui | >>> >>> ui := CustomerSatisfaction newopenWithSpec. >>> >>> ui close. >>> >>> >>> >>> this error message appears, no UI image appears of course. >>> >>> "SubclassResponsibility:CustomerSatisfaction class had the subclass >>> responsibility to implement #defaultSpec" >>> >>> ====== >>> >>> Not only don't I understand the message, but it implies I have to write >>> something called #defaultSpec !, which is not mentioned in the tutorial. >> >> CustomerSatisfaction is a subclass of ComposableModel >> (ComposablePresenter in Pharo 7). If you have a look at the >> implementation of #defaultSpec in ComposableModel or >> ComposablePresenter (depending on which version of Pharo you are >> using) it says that it is up to subclasses to implement the method >> (#subclassResponsibility). Since you haven't defined it (yet), the >> call to #defaultSpec uses the inherited definition from >> ComposableModel, which raises the error you are seeing. >> >> CustomerSatisfaction class>>defaultSpec is on page 6 of my version of >> the booklet, dated Feb 6, 2107. >> >> >> Cheers, >> Alistair >> >> > > -- > Cheers, > Brett >

March 21, 2018

How to model extension method in UML

by Jan BlizniÄenko

Hello I have a question regarding UML modelling of Pharo extension method. If I have a class ClassA in package PackageA, and I have a package PackageB which contains extension method of ClassA (so there is a new method in ClassA with protocol "*PackageB"), how exactly to model this situation in UML class/package diagram? Thank you. Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 21, 2018

Re: [Pharo-users] Unable to execute example code from "The Spec UI Framework" Book

by dragoncity

I had already defined & accepted defaultSpec , as per page 6. Attached is my CustomerSatisfaction.st file : I assume Pharo will suck it back in ! On 21/03/18 17:55, Alistair Grant wrote: > On 21 March 2018 at 03:12, dragoncity <dragoncitybrett(a)gmail.com> wrote: >> Hello, I'm just getting into Pharo, and am trying to >> do the example 'tutorial' UI programs in chapter 2 of The Spec UI Framework >> book. I have a special interest in end user GUI interfaces for programs. I >> enter the first example code as written and the methods are all accepted >> without errors. And yes, I did generate the accessors. >> >> However , on attempting to execute the code at the bottom of page 6 from the >> latest Spec UI Framework book, >> >> >> | ui | >> >> ui := CustomerSatisfaction newopenWithSpec. >> >> ui close. >> >> >> >> this error message appears, no UI image appears of course. >> >> "SubclassResponsibility:CustomerSatisfaction class had the subclass >> responsibility to implement #defaultSpec" >> >> ====== >> >> Not only don't I understand the message, but it implies I have to write >> something called #defaultSpec !, which is not mentioned in the tutorial. > CustomerSatisfaction is a subclass of ComposableModel > (ComposablePresenter in Pharo 7). If you have a look at the > implementation of #defaultSpec in ComposableModel or > ComposablePresenter (depending on which version of Pharo you are > using) it says that it is up to subclasses to implement the method > (#subclassResponsibility). Since you haven't defined it (yet), the > call to #defaultSpec uses the inherited definition from > ComposableModel, which raises the error you are seeing. > > CustomerSatisfaction class>>defaultSpec is on page 6 of my version of > the booklet, dated Feb 6, 2107. > > > Cheers, > Alistair > > -- Cheers, Brett

March 21, 2018

Re: [Pharo-users] Unable to execute example code from "The Spec UI Framework" Book

by Yuriy Babah

at the end of the fifth page " The widgets have now been defined and configured, but their placement in the UI has not yet been specified. This is the role of the class side method defaultSpec . " CustomerSatisfaction class >> defaultSpec ^ SpecLayout composed newRow: [ :row | row add: #buttonHappy; add: #buttonNeutral; add: #buttonBad ] origin: 0 @ 0 corner: 1 @ 0.7; newRow: [ :row | row add: #screen ] origin: 0 @ 0.7 corner: 1 @ 1; yourself 2018-03-21 5:12 GMT+03:00 dragoncity <dragoncitybrett(a)gmail.com>: > Hello, I'm just getting into Pharo, and am trying to > do the example 'tutorial' UI programs in chapter 2 of The Spec UI > Framework book. I have a special interest in end user GUI interfaces for > programs. I enter the first example code as written and the methods are all > accepted without errors. And yes, I did generate the accessors. > > However , on attempting to execute the code at the bottom of page 6 from > the latest Spec UI Framework book, > > > | ui | > > ui := CustomerSatisfaction newopenWithSpec. > > ui close. > > > > this error message appears, no UI image appears of course. > > "SubclassResponsibility:CustomerSatisfaction class had the subclass > responsibility to implement #defaultSpec" > > ====== > > Not only don't I understand the message, but it implies I have to write > something called #defaultSpec !, which is not mentioned in the tutorial. > > > Any help appreciated, > > Yours, > > -- > Cheers, > Brett > > >

March 21, 2018

Re: [Pharo-users] Unable to execute example code from "The Spec UI Framework" Book

by Alistair Grant

On 21 March 2018 at 03:12, dragoncity <dragoncitybrett(a)gmail.com> wrote: > Hello, I'm just getting into Pharo, and am trying to > do the example 'tutorial' UI programs in chapter 2 of The Spec UI Framework > book. I have a special interest in end user GUI interfaces for programs. I > enter the first example code as written and the methods are all accepted > without errors. And yes, I did generate the accessors. > > However , on attempting to execute the code at the bottom of page 6 from the > latest Spec UI Framework book, > > > | ui | > > ui := CustomerSatisfaction newopenWithSpec. > > ui close. > > > > this error message appears, no UI image appears of course. > > "SubclassResponsibility:CustomerSatisfaction class had the subclass > responsibility to implement #defaultSpec" > > ====== > > Not only don't I understand the message, but it implies I have to write > something called #defaultSpec !, which is not mentioned in the tutorial. CustomerSatisfaction is a subclass of ComposableModel (ComposablePresenter in Pharo 7). If you have a look at the implementation of #defaultSpec in ComposableModel or ComposablePresenter (depending on which version of Pharo you are using) it says that it is up to subclasses to implement the method (#subclassResponsibility). Since you haven't defined it (yet), the call to #defaultSpec uses the inherited definition from ComposableModel, which raises the error you are seeing. CustomerSatisfaction class>>defaultSpec is on page 6 of my version of the booklet, dated Feb 6, 2107. Cheers, Alistair

March 21, 2018