From tapplek at gmail.com Tue Dec 4 04:54:13 2007 From: tapplek at gmail.com (Matthew Fulmer) Date: Mon, 3 Dec 2007 20:54:13 -0700 Subject: [sbe-discussion] code error on page 33 Message-ID: <20071204035413.GA24660@tacobell.ph.cox.net> On page 33, in section 2.4, method 2.2 (SBECell>>initialize), references three undeclared variables: bounds, offColor, and onColor. It seems they should be instance variables, but they were not declared as such in Class 2.1 (and some screenshots). When accepting the method, one gets a popup about each variable, which is not mentioned in the book and confusing to a new user. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 From black at cs.pdx.edu Tue Dec 4 05:26:56 2007 From: black at cs.pdx.edu (Andrew P. Black) Date: Mon, 3 Dec 2007 20:26:56 -0800 Subject: [sbe-discussion] Re: code error on page 33 In-Reply-To: <20071204035413.GA24660@tacobell.ph.cox.net> References: <20071204035413.GA24660@tacobell.ph.cox.net> Message-ID: <496AB55A-30D1-45E1-A05C-29B646867D4D@cs.pdx.edu> When I wrote the code, all three of those variables were instance variables of SimpleSwitchMorph, of which SBECell is a subclass. Are they no longer? Andrew On 3 Dec 2007, at 19:54, Matthew Fulmer wrote: > On page 33, in section 2.4, method 2.2 (SBECell>>initialize), > references three undeclared variables: bounds, offColor, and > onColor. It seems they should be instance variables, but they > were not declared as such in Class 2.1 (and some screenshots). Professor Andrew P. Black Department of Computer Science Portland State University +1 503 725 2411 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/sbe-discussion/attachments/20071204/916c6aa6/attachment-0001.html From tapplek at gmail.com Tue Dec 4 05:31:33 2007 From: tapplek at gmail.com (Matthew Fulmer) Date: Mon, 3 Dec 2007 21:31:33 -0700 Subject: [sbe-discussion] Re: code error on page 33 In-Reply-To: <496AB55A-30D1-45E1-A05C-29B646867D4D@cs.pdx.edu> References: <20071204035413.GA24660@tacobell.ph.cox.net> <496AB55A-30D1-45E1-A05C-29B646867D4D@cs.pdx.edu> Message-ID: <20071204043133.GB24660@tacobell.ph.cox.net> On Mon, Dec 03, 2007 at 08:26:56PM -0800, Andrew P. Black wrote: > When I wrote the code, all three of those variables were instance > variables > of SimpleSwitchMorph, of which SBECell is a subclass. > Are they no longer? So they are. The person I was helping on IRC must have made it a subclass of Object by mistake. I didn't ask. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 From ksulli at volny.cz Tue Dec 4 11:36:23 2007 From: ksulli at volny.cz (Kim Sullivan) Date: Tue, 4 Dec 2007 11:36:23 +0100 Subject: [sbe-discussion] Chapter on streams - bad analogy, or broken implementation? Message-ID: Hello, I have been working on some parsing stuff for a school project. I already had read the chapter on streams, and it seemed perfectly clear to me that the "pointer" is between elements, and on "on" an element. Unfortunately, that assumption doesn't hold when you start using back and peekBack - those two methods work as if the position was on the item that the previous next returned, and return the item that is before that. At first I thought that the way it is described in SBE is wrong, but now I think that the back methods are broken, and wrote my own implementations, previous and peekPrevious. The back methods don't seem to be used much anyway, at least in the image that I have which is based on 3.7 I think, and the code that uses them could be fixed. My question is - how should I proceed? Should I report a bug in Squeak so that the back method gets fixed, or should I submit my own implementations of previous and peekPrevious, keeping the back methods for backwards compatibility? In any case, I think that the current behaviour of the back methods should be mentioned in SBE (in the version of the book that I have, they aren't mentioned at all). Regards, Kim Sullivan From alicebot at seznam.cz Tue Dec 4 11:50:29 2007 From: alicebot at seznam.cz (Kim Sullivan) Date: Tue, 4 Dec 2007 11:50:29 +0100 Subject: [sbe-discussion] Chapter on streams - bad analogy, or broken implementation? Message-ID: Hello, I have been working on some parsing stuff for a school project. I already had read the chapter on streams, and it seemed perfectly clear to me that the "pointer" is between elements, and on "on" an element. Unfortunately, that assumption doesn't hold when you start using back and peekBack - those two methods work as if the position was on the item that the previous next returned, and return the item that is before that. At first I thought that the way it is described in SBE is wrong, but now I think that the back methods are broken, and wrote my own implementations, previous and peekPrevious. The back methods don't seem to be used much anyway, at least in the image that I have which is based on 3.7 I think, and the code that uses them could be fixed. My question is - how should I proceed? Should I report a bug in Squeak so that the back method gets fixed, or should I submit my own implementations of previous and peekPrevious, keeping the back methods for backwards compatibility? In any case, I think that the current behaviour of the back methods should be mentioned in SBE (in the version of the book that I have, they aren't mentioned at all). Regards, Kim Sullivan From stephane.ducasse at free.fr Tue Dec 4 12:04:21 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Tue, 4 Dec 2007 12:04:21 +0100 Subject: [sbe-discussion] Re: Chapter on streams - bad analogy, or broken implementation? In-Reply-To: References: Message-ID: <81861FC8-8E98-49B3-80DD-2853FA6FDCC9@free.fr> Hi kim can you check if this is fixed in 3.10? because it seems that damien fixed all the buggy stream methods but may be only for 3.10 Stef On 4 d?c. 07, at 11:50, Kim Sullivan wrote: > Hello, > > I have been working on some parsing stuff for a school project. I > already > had read the chapter on streams, and it seemed perfectly clear to > me that > the "pointer" is between elements, and on "on" an element. > Unfortunately, > that assumption doesn't hold when you start using back and peekBack > - those > two methods work as if the position was on the item that the > previous next > returned, and return the item that is before that. At first I > thought that > the way it is described in SBE is wrong, but now I think that the back > methods are broken, and wrote my own implementations, previous and > peekPrevious. The back methods don't seem to be used much anyway, > at least > in the image that I have which is based on 3.7 I think, and the > code that > uses them could be fixed. > > My question is - how should I proceed? Should I report a bug in > Squeak so > that the back method gets fixed, or should I submit my own > implementations > of previous and peekPrevious, keeping the back methods for backwards > compatibility? > > In any case, I think that the current behaviour of the back methods > should > be mentioned in SBE (in the version of the book that I have, they > aren't > mentioned at all). > > Regards, > Kim Sullivan > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From damien.cassou at gmail.com Tue Dec 4 13:05:15 2007 From: damien.cassou at gmail.com (Damien Cassou) Date: Tue, 4 Dec 2007 13:05:15 +0100 Subject: [sbe-discussion] Re: Chapter on streams - bad analogy, or broken implementation? In-Reply-To: References: Message-ID: <6ac749c10712040405m725b8264qbafb6aaab389c845@mail.gmail.com> Hi Kim, 2007/12/4, Kim Sullivan : > I have been working on some parsing stuff for a school project. I already > had read the chapter on streams, and it seemed perfectly clear to me that > the "pointer" is between elements, and on "on" an element. Unfortunately, > that assumption doesn't hold when you start using back and peekBack - those > two methods work as if the position was on the item that the previous next > returned, and return the item that is before that. At first I thought that > the way it is described in SBE is wrong, but now I think that the back > methods are broken, and wrote my own implementations, previous and > peekPrevious. The back methods don't seem to be used much anyway, at least > in the image that I have which is based on 3.7 I think, and the code that > uses them could be fixed. > > My question is - how should I proceed? Should I report a bug in Squeak so > that the back method gets fixed, or should I submit my own implementations > of previous and peekPrevious, keeping the back methods for backwards > compatibility? > > In any case, I think that the current behaviour of the back methods should > be mentioned in SBE (in the version of the book that I have, they aren't > mentioned at all). Bugs have already been reported: http://bugs.squeak.org/view.php?id=6583 http://bugs.squeak.org/view.php?id=368 In Squeak 3.10, the methods should be fixed. -- Damien Cassou From kbrown at mac.com Fri Dec 7 20:29:11 2007 From: kbrown at mac.com (Ken G. Brown) Date: Fri, 7 Dec 2007 12:29:11 -0700 Subject: [sbe-discussion] SBE paperback is of good quality Message-ID: Received paperback copy of SBE from Lulu and have been pleased with the quality. Thx for all of your efforts, and for making it freely downloadable as well as optionally for a fee to help support the effort. The book will be very helpful. And the way that the book has been published should serve as a great model for others. Because of your work, I have already mentioned Lulu publishing a few times to others who are toying with the idea of writing a book but are stumbling with respect to the roadblocks encountered following normal publishing paths. I've slowly been going through SBE and have found a small typo that does not appear to have been mentioned yet. pg 172 end of first paragraph 'form' should be 'from'. Suggestion: Since this is a work in progress, perhaps the downloadable pdfs could have versions added and the errata fixes note which version they have been fixed in? I see that the paper book has version of 2007-09-13 inside on the title page but the downloadable pdf from is just SBE.pdf. Thx, Ken G. Brown From oscar at iam.unibe.ch Fri Dec 7 20:37:16 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Fri, 7 Dec 2007 20:37:16 +0100 Subject: [sbe-discussion] Re: SBE paperback is of good quality In-Reply-To: References: Message-ID: <150FEAF1-739E-42D3-9914-BFC592E9EE2C@iam.unibe.ch> Hi Ken, thanks for the new erratum. Errata do refer to version numbers. https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/Book/errata.txt The versions are available too (though there are only two for the moment): https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/versions/ More too come very very soon. The main URL is intended to have a single web location for the latest version. Older versions can be accessed from the repository, but we do not advertise that yet. Thanks for the feedback and the encouragement! - on On Dec 7, 2007, at 20:29, Ken G. Brown wrote: > Received paperback copy of SBE from Lulu and have been pleased with > the quality. > > Thx for all of your efforts, and for making it freely downloadable > as well as optionally for a fee to help support the effort. > The book will be very helpful. And the way that the book has been > published should serve as a great model for others. Because of your > work, I have already mentioned Lulu publishing a few times to others > who are toying with the idea of writing a book but are stumbling > with respect to the roadblocks encountered following normal > publishing paths. > > I've slowly been going through SBE and have found a small typo that > does not appear to have been mentioned yet. > > pg 172 end of first paragraph 'form' should be 'from'. > > Suggestion: Since this is a work in progress, perhaps the > downloadable pdfs could have versions added and the errata fixes > note which version they have been fixed in? I see that the paper > book has version of 2007-09-13 inside on the title page but the > downloadable pdf from is just > SBE.pdf. > > Thx, > Ken G. Brown > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion From alexandre at bergel.eu Sat Dec 8 13:31:39 2007 From: alexandre at bergel.eu (Alexandre Bergel) Date: Sat, 8 Dec 2007 09:31:39 -0300 Subject: [sbe-discussion] Monticello chapter in Message-ID: Dear all, Reviewers for the Monticello chapter are wanted :-) I think it says what one should know about this tool. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From oscar at iam.unibe.ch Sat Dec 8 23:47:24 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Sat, 8 Dec 2007 23:47:24 +0100 Subject: [sbe-discussion] Re: squeak-dev reference in SBE In-Reply-To: <475AFBAB.6000107@douglasedmunds.com> References: <475AFBAB.6000107@douglasedmunds.com> Message-ID: Hi Doug, Thanks for pointing this out. Actually it has been updated in the svn already and will appear in the next edition [soon]. According to Damien, the correct link is http://damien.cassou.free.fr/squeak-dev.html I stumbled across this too. Have added this now to the errata. Cheers, - on On Dec 8, 2007, at 21:16, Doug Edmunds wrote: > Hello, > > Re http://www.iam.unibe.ch/~scg/SBE/index.html > > It looks like the site you give in SBE for > downloading squeak-dev has recently moved. > > You may want to update the book (page 4). > > old link > http://damien.cassou.free.fr/squeak-dev/ > > new link (as of December 2007) > http://squeak.ofset.org/squeak-dev/ > > Note: I have not posted this info anywhere else > so if you have a mailing list/blog to send it to, go ahead. > > -- Doug Edmunds From oscar at iam.unibe.ch Mon Dec 10 17:38:57 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Mon, 10 Dec 2007 17:38:57 +0100 Subject: [sbe-discussion] Re: Question raised by SBE alternative coding In-Reply-To: <475D6770.2040904@douglasedmunds.com> References: <475AFBAB.6000107@douglasedmunds.com> <475D6770.2040904@douglasedmunds.com> Message-ID: Hi Doug. Good question. If you look at the code, you will see that they are different, but very similar. My guess is it makes no appreciable difference. Generally you should not worry about performance too much, and only when it is a problem, run some benchmarks, instrument your code, identify bottlenecks and optimize. You should focus on what you want to model rather than on how it is implemented. Hope that helps. Oscar [PS: I moved this thread back to the sbe-discussion list.] On Dec 10, 2007, at 17:21, Doug Edmunds wrote: > Hello, > > I am looking at pages 59-60 (pdf pages 71-72) > On one page you have: > > send the message to:do: to an number > > n := 0. > 1 to: 10 do: [ :counter | n := n + counter ]. > n ---> 55 > > and on the other you have > > 1 to: 10 represents the interval from 1 to > 10. Since it is a collection, we can send the message do: to it. > > n := 0. > (1 to: 10) do: [ :element | n := n + element ]. > n ?--> 55 > > > The first approach (to:do) shows up in the system browser > under Category Kernel Numbers, Class Magnitude -> Number > > The second approach (to:) followed by (do:) > also has (to:) under Category Kernel Numbers, Class Magnitude -> > Number > but (do:) by itself shows up under Category Collections-Sequences, > Class Interval > > > My question is twofold: > 1. Does squeak process these two approaches differently > (using different bits of code)? > 2. If processed differently, is one preferred to the other (for speed, > or for other reasons)? > > Thanks. > > -- Doug Edmunds. > From damien.cassou at gmail.com Mon Dec 10 17:49:26 2007 From: damien.cassou at gmail.com (Damien Cassou) Date: Mon, 10 Dec 2007 17:49:26 +0100 Subject: [sbe-discussion] Re: Question raised by SBE alternative coding In-Reply-To: References: <475AFBAB.6000107@douglasedmunds.com> <475D6770.2040904@douglasedmunds.com> Message-ID: <6ac749c10712100849j254963d6n9f4523d9eee1db33@mail.gmail.com> Hi, in fact, #to:do: is much more efficient than #to: followed by #do: (according to squeak-dev mailing list). The second approach creates an interval object only required to iterate over it. The first approach does not create anything. 2007/12/10, Oscar Nierstrasz : > > Hi Doug. > > Good question. > > If you look at the code, you will see that they are different, but > very similar. > > My guess is it makes no appreciable difference. > > Generally you should not worry about performance too much, and only > when it is a problem, run some benchmarks, instrument your code, > identify bottlenecks and optimize. > > You should focus on what you want to model rather than on how it is > implemented. > > Hope that helps. > > Oscar > > [PS: I moved this thread back to the sbe-discussion list.] > > On Dec 10, 2007, at 17:21, Doug Edmunds wrote: > > > Hello, > > > > I am looking at pages 59-60 (pdf pages 71-72) > > On one page you have: > > > > send the message to:do: to an number > > > > n := 0. > > 1 to: 10 do: [ :counter | n := n + counter ]. > > n ---> 55 > > > > and on the other you have > > > > 1 to: 10 represents the interval from 1 to > > 10. Since it is a collection, we can send the message do: to it. > > > > n := 0. > > (1 to: 10) do: [ :element | n := n + element ]. > > n ?--> 55 > > > > > > The first approach (to:do) shows up in the system browser > > under Category Kernel Numbers, Class Magnitude -> Number > > > > The second approach (to:) followed by (do:) > > also has (to:) under Category Kernel Numbers, Class Magnitude -> > > Number > > but (do:) by itself shows up under Category Collections-Sequences, > > Class Interval > > > > > > My question is twofold: > > 1. Does squeak process these two approaches differently > > (using different bits of code)? > > 2. If processed differently, is one preferred to the other (for speed, > > or for other reasons)? > > > > Thanks. > > > > -- Doug Edmunds. > > > > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > -- Damien Cassou From renggli at gmail.com Mon Dec 10 18:31:56 2007 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 10 Dec 2007 18:31:56 +0100 Subject: [sbe-discussion] Re: Question raised by SBE alternative coding In-Reply-To: <6ac749c10712100849j254963d6n9f4523d9eee1db33@mail.gmail.com> References: <475AFBAB.6000107@douglasedmunds.com> <475D6770.2040904@douglasedmunds.com> <6ac749c10712100849j254963d6n9f4523d9eee1db33@mail.gmail.com> Message-ID: <67628d690712100931h6622aa13j35cd71ccf9dfc3a8@mail.gmail.com> > The second approach creates an > interval object only required to iterate over it. The expensive thing is not the interval object, but the block-copy and the block activation on every iteration. > The first approach > does not create anything. Exactly, that's a macro in-lined by the compiler. Anyway, the difference is subtle and only matters for large collections. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From black at cs.pdx.edu Mon Dec 10 20:33:07 2007 From: black at cs.pdx.edu (Andrew P. Black) Date: Mon, 10 Dec 2007 11:33:07 -0800 Subject: [sbe-discussion] Re: Question raised by SBE alternative coding In-Reply-To: <6ac749c10712100849j254963d6n9f4523d9eee1db33@mail.gmail.com> References: <475AFBAB.6000107@douglasedmunds.com> <475D6770.2040904@douglasedmunds.com> <6ac749c10712100849j254963d6n9f4523d9eee1db33@mail.gmail.com> Message-ID: <5D1C8BCF-04A8-4802-9DB2-E35E3DAB9A8A@cs.pdx.edu> Doug, What Damien says about performance is true, and is one of the reasons that to: do: exists. The other reason is that do: requires an extra set of parentheses, and Smalltalkers dislike having to use parentheses; they hamper readability. As for semantics: they both do the same thing. Actually, real Smalltkers would do neither of these things: they would use inject: into: to abstract out the declaration of the temp variable and its initialization. So, rather than >>> n := 0. >>> 1 to: 10 do: [ :counter | n := n + counter ]. >>> n ---> 55 they would write: (1 to: 10) inject: 0 into: [ :sum :n | sum + n ] ---> 55 Of course, for this particular example, one can write (1 to: 10) sum ---> 55 So where does this take us? do:, inject:into: and sum: are general messages that can be sent to any collection. (OK, for sum, the elements had better understand +, but you get the idea). to:do: (and timesRepeat:) applies to numbers, not to collections. To avoid confusion, it should always be the case that a to: b by: i do: [:each | stmts ] and (a to: b by: i) do: [:each | stmts ] have the same effect, but they do it by sending different messages to different objects, and it's up to the implementors of those messages to ensure that the behaviour is what one expects. (Incidentally, a similar thing is true of a=b and b=a: here the message (=) is the same, but the objects are different, and it takes some careful programming to ensure that the results are the same, i.e., to ensure that = is reflexive). Oscar, do you think that some of this discussion should go in the book? Perhaps a forward reference from the "conditionals and loops in nutshell" section to the "collections" section, where these things can be discussed in more detail? Andrew On 10 Dec 2007, at 8:49, Damien Cassou wrote: > Hi, > > in fact, #to:do: is much more efficient than #to: followed by #do: > (according to squeak-dev mailing list). The second approach creates an > interval object only required to iterate over it. The first approach > does not create anything. > > 2007/12/10, Oscar Nierstrasz : >> >> Hi Doug. >> >> Good question. >> >> If you look at the code, you will see that they are different, but >> very similar. >> >> My guess is it makes no appreciable difference. >> >> Generally you should not worry about performance too much, and only >> when it is a problem, run some benchmarks, instrument your code, >> identify bottlenecks and optimize. >> >> You should focus on what you want to model rather than on how it is >> implemented. >> >> Hope that helps. >> >> Oscar >> >> [PS: I moved this thread back to the sbe-discussion list.] >> >> On Dec 10, 2007, at 17:21, Doug Edmunds wrote: >> >>> Hello, >>> >>> I am looking at pages 59-60 (pdf pages 71-72) >>> On one page you have: >>> >>> send the message to:do: to an number >>> >>> n := 0. >>> 1 to: 10 do: [ :counter | n := n + counter ]. >>> n ---> 55 >>> >>> and on the other you have >>> >>> 1 to: 10 represents the interval from 1 to >>> 10. Since it is a collection, we can send the message do: to it. >>> >>> n := 0. >>> (1 to: 10) do: [ :element | n := n + element ]. >>> n ?--> 55 >>> >>> >>> The first approach (to:do) shows up in the system browser >>> under Category Kernel Numbers, Class Magnitude -> Number >>> >>> The second approach (to:) followed by (do:) >>> also has (to:) under Category Kernel Numbers, Class Magnitude -> >>> Number >>> but (do:) by itself shows up under Category Collections-Sequences, >>> Class Interval >>> >>> >>> My question is twofold: >>> 1. Does squeak process these two approaches differently >>> (using different bits of code)? >>> 2. If processed differently, is one preferred to the other (for >>> speed, >>> or for other reasons)? >>> >>> Thanks. >>> >>> -- Doug Edmunds. >>> >> >> >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >> > > > -- > Damien Cassou > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > Professor Andrew P. Black Department of Computer Science Portland State University +1 503 725 2411 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/sbe-discussion/attachments/20071210/896e0930/attachment-0001.html From serge.stinckwich at gmail.com Tue Dec 11 10:20:38 2007 From: serge.stinckwich at gmail.com (Serge Stinckwich) Date: Tue, 11 Dec 2007 10:20:38 +0100 Subject: [sbe-discussion] Obscure habit Message-ID: The following sentences (in 2.9, Monticello packages) are not very clear : "A good trick is to always develop in the same folder. This way you get a copy of all the code that you publish on squeaksource on your local machine. You can then backup and browse at will.". This seems to be an habit of the writer. But why this related to Monticello ? and why we need to backup ? -- Serge Stinckwich http://doesnotunderstand.free.fr/ From stephane.ducasse at free.fr Tue Dec 11 19:01:43 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Tue, 11 Dec 2007 19:01:43 +0100 Subject: [sbe-discussion] Re: Obscure habit In-Reply-To: References: Message-ID: because MC also keeps a copy of the published files into the package folder and that way you always have a copy and this copy can be backp using your backup procedure. stef On 11 d?c. 07, at 10:20, Serge Stinckwich wrote: > The following sentences (in 2.9, Monticello packages) are not very > clear : "A good trick is to always develop in the same folder. This > way you get a copy of all the code that you publish on squeaksource on > your local machine. You can then backup and browse at will.". This > seems to be an habit of the writer. But why this related to Monticello > ? and why we need to backup ? > > > -- > Serge Stinckwich > http://doesnotunderstand.free.fr/ > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From oscar at iam.unibe.ch Tue Dec 11 19:07:26 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Tue, 11 Dec 2007 19:07:26 +0100 Subject: [sbe-discussion] Re: Obscure habit In-Reply-To: References: Message-ID: Yes, it was obscure to me too. Then I figured it out and now I am doing the same. We should fix the explanation. - on On Dec 11, 2007, at 19:01, stephane ducasse wrote: > because MC also keeps a copy of the published files into the package > folder > and that way you always have a copy and this copy can be backp using > your backup procedure. > > stef > > On 11 d?c. 07, at 10:20, Serge Stinckwich wrote: > >> The following sentences (in 2.9, Monticello packages) are not very >> clear : "A good trick is to always develop in the same folder. This >> way you get a copy of all the code that you publish on squeaksource >> on >> your local machine. You can then backup and browse at will.". This >> seems to be an habit of the writer. But why this related to >> Monticello >> ? and why we need to backup ? >> >> >> -- >> Serge Stinckwich >> http://doesnotunderstand.free.fr/ >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >> > > > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From stephane.ducasse at free.fr Tue Dec 11 19:15:42 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Tue, 11 Dec 2007 19:15:42 +0100 Subject: [sbe-discussion] Re: Obscure habit In-Reply-To: References: Message-ID: please go and sorry for that Stef On 11 d?c. 07, at 19:07, Oscar Nierstrasz wrote: > > Yes, it was obscure to me too. Then I figured it out and now I am > doing the same. > > We should fix the explanation. > > - on > > On Dec 11, 2007, at 19:01, stephane ducasse wrote: > >> because MC also keeps a copy of the published files into the package >> folder >> and that way you always have a copy and this copy can be backp using >> your backup procedure. >> >> stef >> >> On 11 d?c. 07, at 10:20, Serge Stinckwich wrote: >> >>> The following sentences (in 2.9, Monticello packages) are not very >>> clear : "A good trick is to always develop in the same folder. This >>> way you get a copy of all the code that you publish on squeaksource >>> on >>> your local machine. You can then backup and browse at will.". This >>> seems to be an habit of the writer. But why this related to >>> Monticello >>> ? and why we need to backup ? >>> >>> >>> -- >>> Serge Stinckwich >>> http://doesnotunderstand.free.fr/ >>> _______________________________________________ >>> Sbe-discussion mailing list >>> Sbe-discussion at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>> >> >> >> >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >> > > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From black at cs.pdx.edu Tue Dec 11 23:33:57 2007 From: black at cs.pdx.edu (Andrew P. Black) Date: Tue, 11 Dec 2007 14:33:57 -0800 Subject: [sbe-discussion] Re: Obscure habit In-Reply-To: References: Message-ID: <63CFC58A-8933-43D4-B09D-D843539651A4@cs.pdx.edu> Good. So when the explanation is fixed, I might know what you are talking about too. I've never understood my Monticello keeps a cache in a particular directory, rather than on a particular machine. Andrew On 11 Dec 2007, at 10:07, Oscar Nierstrasz wrote: > > Yes, it was obscure to me too. Then I figured it out and now I am > doing the same. > > We should fix the explanation. > > - on > > On Dec 11, 2007, at 19:01, stephane ducasse wrote: > >> because MC also keeps a copy of the published files into the package >> folder >> and that way you always have a copy and this copy can be backp using >> your backup procedure. >> >> stef >> >> On 11 d?c. 07, at 10:20, Serge Stinckwich wrote: >> >>> The following sentences (in 2.9, Monticello packages) are not very >>> clear : "A good trick is to always develop in the same folder. This >>> way you get a copy of all the code that you publish on squeaksource >>> on >>> your local machine. You can then backup and browse at will.". This >>> seems to be an habit of the writer. But why this related to >>> Monticello >>> ? and why we need to backup ? >>> >>> >>> -- >>> Serge Stinckwich >>> http://doesnotunderstand.free.fr/ >>> _______________________________________________ >>> Sbe-discussion mailing list >>> Sbe-discussion at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>> >> >> >> >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >> > > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From oscar at iam.unibe.ch Thu Dec 13 10:10:03 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Thu, 13 Dec 2007 10:10:03 +0100 Subject: [sbe-discussion] Re: SBE star vs. asterisk In-Reply-To: <47600E6D.1060800@douglasedmunds.com> References: <47600E6D.1060800@douglasedmunds.com> Message-ID: Ugh! Thanks Doug. I fixed those two pages (actually numbered 21 and 125). - on On Dec 12, 2007, at 17:38, Doug Edmunds wrote: > Hello, > > I ran a search in Adobe Reader for discussions of the use of > the asterisk, but could not find one that I had read about > in earlier pages. Looking back, I happened onto Figure 1.19 > and saw it. > > The problem is that in a few rare locations, you use the > word 'star' instead of 'asterisk' (p 33 and p 137). Those > should be changed to asterisk. > > (But don't do a global search and replace. In other sections, > you refer to a 'star' morph.) > > = Doug Edmunds. > > > From oscar at iam.unibe.ch Thu Dec 13 10:44:03 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Thu, 13 Dec 2007 10:44:03 +0100 Subject: [sbe-discussion] Re: Obscure habit In-Reply-To: <63CFC58A-8933-43D4-B09D-D843539651A4@cs.pdx.edu> References: <63CFC58A-8933-43D4-B09D-D843539651A4@cs.pdx.edu> Message-ID: It is not very deep. Monticello keeps a package cache per directory. If you have you images all over the place, then you have lots of package caches. If you keep them all in the same place, then you have just one package cache. Useful if you are looking for something, or if you want to build a new image without having to connect to the server. Everything that you load or save appears in the package cache. That means you can also easily backup everything that you have checked in. At least that's the way I understood it. - on On Dec 11, 2007, at 23:33, Andrew P. Black wrote: > Good. So when the explanation is fixed, I might know what you are > talking about too. > > I've never understood my Monticello keeps a cache in a particular > directory, rather than on a particular machine. > > Andrew > > On 11 Dec 2007, at 10:07, Oscar Nierstrasz wrote: > >> >> Yes, it was obscure to me too. Then I figured it out and now I am >> doing the same. >> >> We should fix the explanation. >> >> - on >> >> On Dec 11, 2007, at 19:01, stephane ducasse wrote: >> >>> because MC also keeps a copy of the published files into the package >>> folder >>> and that way you always have a copy and this copy can be backp using >>> your backup procedure. >>> >>> stef >>> >>> On 11 d?c. 07, at 10:20, Serge Stinckwich wrote: >>> >>>> The following sentences (in 2.9, Monticello packages) are not very >>>> clear : "A good trick is to always develop in the same folder. This >>>> way you get a copy of all the code that you publish on squeaksource >>>> on >>>> your local machine. You can then backup and browse at will.". This >>>> seems to be an habit of the writer. But why this related to >>>> Monticello >>>> ? and why we need to backup ? >>>> >>>> >>>> -- >>>> Serge Stinckwich >>>> http://doesnotunderstand.free.fr/ >>>> _______________________________________________ >>>> Sbe-discussion mailing list >>>> Sbe-discussion at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>>> >>> >>> >>> >>> _______________________________________________ >>> Sbe-discussion mailing list >>> Sbe-discussion at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>> >> >> >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >> > > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From stephane.ducasse at free.fr Thu Dec 13 14:03:46 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Thu, 13 Dec 2007 14:03:46 +0100 Subject: [sbe-discussion] Re: Obscure habit In-Reply-To: References: <63CFC58A-8933-43D4-B09D-D843539651A4@cs.pdx.edu> Message-ID: Yes it is correct. I found that handy to only. Stef On 13 d?c. 07, at 10:44, Oscar Nierstrasz wrote: > > It is not very deep. > > Monticello keeps a package cache per directory. If you have you > images all over the place, then you have lots of package caches. If > you keep them all in the same place, then you have just one package > cache. Useful if you are looking for something, or if you want to > build a new image without having to connect to the server. > > Everything that you load or save appears in the package cache. That > means you can also easily backup everything that you have checked in. > > At least that's the way I understood it. > > - on > > On Dec 11, 2007, at 23:33, Andrew P. Black wrote: > >> Good. So when the explanation is fixed, I might know what you are >> talking about too. >> >> I've never understood my Monticello keeps a cache in a particular >> directory, rather than on a particular machine. >> >> Andrew >> >> On 11 Dec 2007, at 10:07, Oscar Nierstrasz wrote: >> >>> >>> Yes, it was obscure to me too. Then I figured it out and now I am >>> doing the same. >>> >>> We should fix the explanation. >>> >>> - on >>> >>> On Dec 11, 2007, at 19:01, stephane ducasse wrote: >>> >>>> because MC also keeps a copy of the published files into the >>>> package >>>> folder >>>> and that way you always have a copy and this copy can be backp >>>> using >>>> your backup procedure. >>>> >>>> stef >>>> >>>> On 11 d?c. 07, at 10:20, Serge Stinckwich wrote: >>>> >>>>> The following sentences (in 2.9, Monticello packages) are not very >>>>> clear : "A good trick is to always develop in the same folder. >>>>> This >>>>> way you get a copy of all the code that you publish on >>>>> squeaksource >>>>> on >>>>> your local machine. You can then backup and browse at will.". This >>>>> seems to be an habit of the writer. But why this related to >>>>> Monticello >>>>> ? and why we need to backup ? >>>>> >>>>> >>>>> -- >>>>> Serge Stinckwich >>>>> http://doesnotunderstand.free.fr/ >>>>> _______________________________________________ >>>>> Sbe-discussion mailing list >>>>> Sbe-discussion at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sbe-discussion mailing list >>>> Sbe-discussion at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>>> >>> >>> >>> _______________________________________________ >>> Sbe-discussion mailing list >>> Sbe-discussion at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>> >> >> >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >> > > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From oscar at iam.unibe.ch Thu Dec 13 16:03:08 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Thu, 13 Dec 2007 16:03:08 +0100 Subject: [sbe-discussion] Re: [sbe] Fwd: SBE errata In-Reply-To: <04457EA9-F6D1-4670-B9BF-31EC72F94B6A@free.fr> References: <20071212222732.GA4732@bloom2.lsi.upc.edu> <04457EA9-F6D1-4670-B9BF-31EC72F94B6A@free.fr> Message-ID: Hi Jordi, Thanks for all these fixes! I am a bit embarrassed by all the new mistakes you found, but am glad to have them. All but one of these are fixed now. (Just a couple had already been fixed, but not logged in detail in the arrat list -- I have updated the list as well.) I hope we can release a corrected edition of the book soon! Cheers, - on PS: I am posting this on the discussion list so everyone who is following will be aware of the fixes. Begin forwarded message: > From: Jordi Delgado > Date: 12 d?cembre 2007 23:27:32 HNEC > To: stephane ducasse > Subject: SBE errata > > Hi Stephane, > > After my first reading of SBE I found the following errors not listed > in the current errata file (assuming they are real errors; please, > accept my > apologies for all the false errors). > > > p 4: line 14 from top: 'sources' should be 'changes'. > > p 106: Are you sure that the sentence "Classes cannot directly access > instance variables of their instances, and instances cannot > access --->class<--- variables of their class." is correct? > Should the highlighted 'class' be instead 'instance' or > 'class-instance'? Otherwise I do not understand what this > sentence > means. > > p 124: line 9 from bottom: 'chapter A'? It should be 'Appendix A' but > that does not make sense. > > p 135: Besides what is already said in the errata file, the reference > to p.154 is absurd, since it is a blank page! > > p 164: First paragraph: '...you will then [then] have to create...' > > p 170: Method 7.14: It should start 'TestCase class >> > testSelectors ...' > > p 191: This is an errata in the errata file: 'conjuncations' should be > 'conjunctions'. > > p 194: It would be a good idea to include 'ByteString' in figure 9.1 > since it is mentioned in figure 9.2 > > p 214: Line 3 from bottom: '..., Dictionary AND its subclasses...' > > p 234: Class 11.2 Its category should be 'SBE-Morphs' to mantain > consistency with other chapters. > > p 236: You should use colors to refer to mouse buttons, as in previous > chapters, not 'left mouse button' nor 'middle button' nor > 'right click'. > > Bests, > > Jordi Delgado > From stephane.ducasse at free.fr Thu Dec 13 17:15:25 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Thu, 13 Dec 2007 17:15:25 +0100 Subject: [sbe-discussion] Re: [sbe] Fwd: SBE errata In-Reply-To: References: <20071212222732.GA4732@bloom2.lsi.upc.edu> <04457EA9-F6D1-4670-B9BF-31EC72F94B6A@free.fr> Message-ID: <32089F52-075C-4020-9E84-6A064F7F4B97@free.fr> thanks oscar Jordi will participate to the spanish translation :) Stef On 13 d?c. 07, at 16:03, Oscar Nierstrasz wrote: > > Hi Jordi, > > Thanks for all these fixes! I am a bit embarrassed by all the new > mistakes you found, but am glad to have them. > > All but one of these are fixed now. (Just a couple had already been > fixed, but not logged in detail in the arrat list -- I have updated > the list as well.) > > I hope we can release a corrected edition of the book soon! > > Cheers, > - on > > PS: I am posting this on the discussion list so everyone who is > following will be aware of the fixes. > > Begin forwarded message: > >> From: Jordi Delgado >> Date: 12 d?cembre 2007 23:27:32 HNEC >> To: stephane ducasse >> Subject: SBE errata >> >> Hi Stephane, >> >> After my first reading of SBE I found the following errors not listed >> in the current errata file (assuming they are real errors; please, >> accept my >> apologies for all the false errors). >> >> >> p 4: line 14 from top: 'sources' should be 'changes'. >> >> p 106: Are you sure that the sentence "Classes cannot directly access >> instance variables of their instances, and instances cannot >> access --->class<--- variables of their class." is correct? >> Should the highlighted 'class' be instead 'instance' or >> 'class-instance'? Otherwise I do not understand what this >> sentence >> means. >> >> p 124: line 9 from bottom: 'chapter A'? It should be 'Appendix A' but >> that does not make sense. >> >> p 135: Besides what is already said in the errata file, the reference >> to p.154 is absurd, since it is a blank page! >> >> p 164: First paragraph: '...you will then [then] have to create...' >> >> p 170: Method 7.14: It should start 'TestCase class >> >> testSelectors ...' >> >> p 191: This is an errata in the errata file: 'conjuncations' >> should be >> 'conjunctions'. >> >> p 194: It would be a good idea to include 'ByteString' in figure 9.1 >> since it is mentioned in figure 9.2 >> >> p 214: Line 3 from bottom: '..., Dictionary AND its subclasses...' >> >> p 234: Class 11.2 Its category should be 'SBE-Morphs' to mantain >> consistency with other chapters. >> >> p 236: You should use colors to refer to mouse buttons, as in >> previous >> chapters, not 'left mouse button' nor 'middle button' nor >> 'right click'. >> >> Bests, >> >> Jordi Delgado >> > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From dae at douglasedmunds.com Thu Dec 13 21:12:53 2007 From: dae at douglasedmunds.com (Doug Edmunds) Date: Thu, 13 Dec 2007 12:12:53 -0800 Subject: [sbe-discussion] page 214 removing an element Message-ID: <47619245.8050004@douglasedmunds.com> Reference to this example on p214: range := (2 to: 20) asOrderedCollection. range do: [:aNumber | aNumber isPrime ifFalse: [ range remove: aNumber ] ]. range ?--> an OrderedCollection(2 3 5 7 9 11 13 15 17 19) The result may be 'clearly incorrect' but the reason that it is incorrect is far from clear. The discussion would be more helpful if it explained why this fails. dae From damien.cassou at gmail.com Fri Dec 14 08:14:30 2007 From: damien.cassou at gmail.com (Damien Cassou) Date: Fri, 14 Dec 2007 08:14:30 +0100 Subject: [sbe-discussion] Re: page 214 removing an element In-Reply-To: <47619245.8050004@douglasedmunds.com> References: <47619245.8050004@douglasedmunds.com> Message-ID: <6ac749c10712132314x4df1c1f4s27dd4fdf13dc8a53@mail.gmail.com> What about something like: ? As it is the case with most Collection libraries in other languages, when you iterate over a collection you must not change it: neither adding nor removing elements. This is because, to be efficient, the library uses an index to remember what is the element currently being passed to the #do: block parameter; the #do: method is not informed that an element is removed or added which leads to an old index in a new collection. ? 2007/12/13, Doug Edmunds : > Reference to this example on p214: > > range := (2 to: 20) asOrderedCollection. > range do: [:aNumber | aNumber isPrime ifFalse: [ range remove: aNumber ] ]. > range ?--> an OrderedCollection(2 3 5 7 9 11 13 15 17 19) > > The result may be 'clearly incorrect' but the reason that it > is incorrect is far from clear. The discussion would be more > helpful if it explained why this fails. > > dae > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > -- Damien Cassou From stephane.ducasse at free.fr Fri Dec 14 10:14:56 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Fri, 14 Dec 2007 10:14:56 +0100 Subject: [sbe-discussion] Re: page 214 removing an element In-Reply-To: <47619245.8050004@douglasedmunds.com> References: <47619245.8050004@douglasedmunds.com> Message-ID: On 13 d?c. 07, at 21:12, Doug Edmunds wrote: > Reference to this example on p214: > > range := (2 to: 20) asOrderedCollection. > range copy > do: [:aNumber | aNumber isPrime ifFalse: [ range remove: aNumber ] ]. > range ?--> an OrderedCollection(2 3 5 7 9 11 13 15 17 19) > > The result may be 'clearly incorrect' but the reason that it > is incorrect is far from clear. The discussion would be more > helpful if it explained why this fails. > > dae > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From serge.stinckwich at gmail.com Sun Dec 23 23:17:57 2007 From: serge.stinckwich at gmail.com (Serge Stinckwich) Date: Sun, 23 Dec 2007 23:17:57 +0100 Subject: [sbe-discussion] Cover for french book Message-ID: Hi all, we are near the end of the translation in french of the SBE. We have to work on the cover now. Where should we put the french cover ? We also need to have a dedicated home page for the french version. Maybe http://www.squeakbyexample.org/fr/ ? Best regards, -- Serge Stinckwich http://doesnotunderstand.free.fr/ From oscar at iam.unibe.ch Wed Dec 26 11:45:40 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Wed, 26 Dec 2007 11:45:40 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: References: Message-ID: I guess you have seen the original cover is here: https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/Cover/ I suggest you make a new one: https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/FrenchCover/ No problem for a dedicated page, if you prepare it. Cheers, Oscar On Dec 23, 2007, at 23:17, Serge Stinckwich wrote: > Hi all, > we are near the end of the translation in french of the SBE. > We have to work on the cover now. Where should we put the french > cover ? > > We also need to have a dedicated home page for the french version. > Maybe http://www.squeakbyexample.org/fr/ ? > > Best regards, > -- > Serge Stinckwich > http://doesnotunderstand.free.fr/ > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion From stephane.ducasse at free.fr Wed Dec 26 12:06:40 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Wed, 26 Dec 2007 12:06:40 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: References: Message-ID: <8F9765FD-E239-4268-AB4D-E27CA07C667E@free.fr> you want to have an eiffel tower :) below the balloon? On 23 d?c. 07, at 23:17, Serge Stinckwich wrote: > Hi all, > we are near the end of the translation in french of the SBE. > We have to work on the cover now. Where should we put the french > cover ? > > We also need to have a dedicated home page for the french version. > Maybe http://www.squeakbyexample.org/fr/ ? > > Best regards, > -- > Serge Stinckwich > http://doesnotunderstand.free.fr/ > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From serge.stinckwich at gmail.com Wed Dec 26 12:11:56 2007 From: serge.stinckwich at gmail.com (Serge Stinckwich) Date: Wed, 26 Dec 2007 12:11:56 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: References: Message-ID: 2007/12/26, Oscar Nierstrasz : > > I guess you have seen the original cover is here: > > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/Cover/ > > I suggest you make a new one: > > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/FrenchCover/ Why covers are not in the corresponding language directory ? Something like that : https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/en/cover https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/fr/cover https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/de/cover -- Serge Stinckwich http://doesnotunderstand.free.fr/ From serge.stinckwich at gmail.com Wed Dec 26 12:12:23 2007 From: serge.stinckwich at gmail.com (Serge Stinckwich) Date: Wed, 26 Dec 2007 12:12:23 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: <8F9765FD-E239-4268-AB4D-E27CA07C667E@free.fr> References: <8F9765FD-E239-4268-AB4D-E27CA07C667E@free.fr> Message-ID: 2007/12/26, stephane ducasse : > you want to have an eiffel tower :) > below the balloon? Why not, but we need a graphic designer to do that in order to have a coherent look. -- Serge Stinckwich http://doesnotunderstand.free.fr/ From oscar at iam.unibe.ch Wed Dec 26 12:14:33 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Wed, 26 Dec 2007 12:14:33 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: References: Message-ID: <87D2F87B-45D1-447E-BCB7-396B0C5AE9CB@iam.unibe.ch> That would make sense. Oscar On Dec 26, 2007, at 12:11, Serge Stinckwich wrote: > 2007/12/26, Oscar Nierstrasz : >> >> I guess you have seen the original cover is here: >> >> https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/Cover/ >> >> I suggest you make a new one: >> >> https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/FrenchCover/ > > Why covers are not in the corresponding language directory ? > > Something like that : > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/en/cover > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/fr/cover > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/de/cover > > -- > Serge Stinckwich > http://doesnotunderstand.free.fr/ > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion From oscar at iam.unibe.ch Thu Dec 27 10:37:48 2007 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Thu, 27 Dec 2007 10:37:48 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: References: <8F9765FD-E239-4268-AB4D-E27CA07C667E@free.fr> Message-ID: I can ask my resident graphic designer ;-) - on On Dec 26, 2007, at 12:12, Serge Stinckwich wrote: >> you want to have an eiffel tower :) >> below the balloon? > > > Why not, but we need a graphic designer to do that in order to have a > coherent look. From stephane.ducasse at free.fr Thu Dec 27 11:15:55 2007 From: stephane.ducasse at free.fr (stephane ducasse) Date: Thu, 27 Dec 2007 11:15:55 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: References: <8F9765FD-E239-4268-AB4D-E27CA07C667E@free.fr> Message-ID: <5F58B336-1A4E-4906-8B9F-6EE589B1EE53@free.fr> would be fun to have just the same plus a little eiffel tower stef On 27 d?c. 07, at 10:37, Oscar Nierstrasz wrote: > > I can ask my resident graphic designer ;-) > > - on > > On Dec 26, 2007, at 12:12, Serge Stinckwich wrote: > >>> you want to have an eiffel tower :) >>> below the balloon? >> >> >> Why not, but we need a graphic designer to do that in order to have a >> coherent look. > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > From Martial.Boniou at ifrance.com Fri Dec 28 10:54:42 2007 From: Martial.Boniou at ifrance.com (Martial Boniou) Date: Fri, 28 Dec 2007 10:54:42 +0100 Subject: [sbe-discussion] Re: Cover for french book In-Reply-To: <5F58B336-1A4E-4906-8B9F-6EE589B1EE53@free.fr> References: <8F9765FD-E239-4268-AB4D-E27CA07C667E@free.fr> <5F58B336-1A4E-4906-8B9F-6EE589B1EE53@free.fr> Message-ID: <20071228095442.GA523@cendre> We probably should change the color chart too. Not to confuse in a library. For the rest, an Eiffel Tower, why not! An Eiffel Studio, NO! ;-) Cheers, -- Martial stephane ducasse a ?crit : | would be fun to have just the same plus a little eiffel tower | | stef | On 27 d?c. 07, at 10:37, Oscar Nierstrasz wrote: | | > | > I can ask my resident graphic designer ;-) | > | > - on | > | > On Dec 26, 2007, at 12:12, Serge Stinckwich wrote: | > | >>> you want to have an eiffel tower :) | >>> below the balloon? | >> | >> | >> Why not, but we need a graphic designer to do that in order to have a | >> coherent look. | > | > _______________________________________________ | > Sbe-discussion mailing list | > Sbe-discussion at iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion | > | | | _______________________________________________ | Sbe-discussion mailing list | Sbe-discussion at iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion | From Martial.Boniou at ifrance.com Fri Dec 28 12:25:17 2007 From: Martial.Boniou at ifrance.com (Martial Boniou) Date: Fri, 28 Dec 2007 12:25:17 +0100 Subject: [sbe-discussion] SUnit figure replacement Message-ID: <20071228112517.GA604@cendre> Hi, In Book/SUnit/figures/sunit-scenario, I noticed an ugly superposition of the method text layer above the arrows. I fixed that for the FrenchBook. You could replace it: (I don't do this coz I'm not official maintainer) $ cp FrenchBook/SUnit/figures/sunit-scenario.graffle FrenchBook/SUnit/figures/sunit-scenario.pdf Book/SUnit/figures/ (of course, this can be done directly with svn) Cheers, -- Martial