October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Collaboractive book chapter 10

by Tudor Girba

To order the subpages, go to parent page, and then choose the Order command. For example, to order the chapters you should go to: http://book.pharo-project.org/book/ Doru On 12 Oct 2010, at 09:56, Mariano Martinez Peck wrote: > Yes, the order of the book is very very bad. The problem is that I have no idea how to sort it. > > > On Tue, Oct 12, 2010 at 9:06 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I just had a look at the book and wondered why the chapter introduction is chapter 10. Looks like it is supposed to be 1 or 2 > > Norbert > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Oct. 12, 2010

Re: [Pharo-project] Collaboractive book chapter 10

by Mariano Martinez Peck

Yes, the order of the book is very very bad. The problem is that I have no idea how to sort it. On Tue, Oct 12, 2010 at 9:06 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I just had a look at the book and wondered why the chapter introduction is > chapter 10. Looks like it is supposed to be 1 or 2 > > Norbert > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 12, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

> > On 10/12/2010 09:35 AM, Paolo Bonzini wrote: >> On 10/11/2010 11:29 PM, StÃ©phane Ducasse wrote: >>>>> Let's go forward in time. NativeBoost, Alien or FFI provide >>>>> callbacks, I do some adaptation on my end, and out comes a pretty >>>>> capable wrapper for the GNU Scientific Library. That sentence >>>>> trivializes a LOT of work :( Details aside, is the wrapper code >>>>> itself affected by GPL >> >> Yes. > > That said, there is a way out. You could have a simple-minded library which has the same interface as the bindings but is written in pure Smalltalk. Then, the same thing can run fast under the GPL, or slow under MIT license. > > I meant to do this exactly for GSL for a long time, making it compatible with the code from "Object-Oriented Implementation of Numerical Methods" so that it could act as a fallback. However, I never even started it. > > http://www.amazon.com/Object-Oriented-Implementation-Numerical-Methods-Intr… > > Paolo

Oct. 12, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

> > Yes. See this question in the GPL FAQ: > > "If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?" > > Despite the phrasing of the question, it actually includes the relevant answer: > > ---- > However, when the interpreter is extended to provide âbindingsâ to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. > > Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. > > If you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. > ---- > > GSL is the "facilities" in this case. So the first paragraph means that the bindings themselves are under the GPL. > > So the bindings are a "GPL'd module" in the second/third paragraph, and the third paragraph means that any program using the GSL bindings is also under the GPL. > > Paolo

Oct. 12, 2010

[Pharo-project] Collaboractive book chapter 10

by Norbert Hartl

I just had a look at the book and wondered why the chapter introduction is chapter 10. Looks like it is supposed to be 1 or 2 Norbert

Oct. 12, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by StÃ©phane Ducasse

thanks! On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: > Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. > > ISSUE 2653. > http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… > > I did a test, maybe a good start would be to see if its failing now. > > Fernando > > On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > >> Hi Folks, >> >> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >> >> Cheers, >> Juan Vuletich >> >> Mariano Martinez Peck wrote: >>> Guille, if I remember correctly (not sure), these new classes like >>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>> think he is in the mailing list but not read it so frequently. So, for >>> this issues maybe you can cc'ed him. >>> >>> Cheers >>> >>> Mariano >>> >>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>> <mailto:guillermopolito@gmail.com>> >>> >>> Here is the piece of code that's behaving weird >>> >>> TextEditor>>dispatchOn: >>> >>> ... >>> ... >>> char := aKeyboardEvent keyCharacter. >>> openers := '([{'. >>> closers := ')]}'. >>> ( closers includes: char) ifTrue: [ self blinkPrevParen: >>> char ]. >>> result := self normalCharacter: aKeyboardEvent. >>> (self class autoEnclose and: [ openers includes: char ]) >>> not ifTrue: [ ^ result ]. >>> suffix := closers at: (openers indexOf: char). >>> paragraph text append: suffix asString. >>> self moveCursor: [ : position | position ] forward: true >>> specialBlock: [ : pos | "no special behavior" ] event: >>> aKeyboardEvent . >>> self userHasEdited. >>> >>> ------------------------------------- >>> >>> So, if I evaluate "TextEditor autoEnclose: false", it is stops >>> behaving like that :) >>> >>> What should be the desired behavior? Having it configurable as it >>> is today but fix the strange bracket adding? remove this behavior? >>> I can't find now how ParagraphEditor did this. >>> >>> Guille >>> >>> >>> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Yes, the issue can be reduced to: >>> >>> open parenthesis (or brackets), then something else (anywhere >>> in the editor). >>> >>> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >>> <mailto:marianopeck@gmail.com>> >>> >>> I detected a similar problem: >>> >>> once you type an opening parenthesis, and then something >>> else, it adds a new one at the END of the code >>> >>> check http://code.google.com/p/pharo/issues/detail?id=2939 >>> >>> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >>> <mailto:guillermopolito@gmail.com>> >>> >>> http://code.google.com/p/pharo/issues/detail?id=3069 >>> >>> if you type: >>> >>> [] -> []] >>> >>> () -> ()) >>> >>> {} -> {}} >>> >>> >>> >>> >>> Bye! >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>> >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 12, 2010

[Pharo-project] R: R: R: R: R: Problem with inspector

by morod

Hello FrÃ©d All right, huge thank you and sorry again for my shallowness Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: lunedÃ¬ 11 ottobre 2010 21.58 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: R: R: Problem with inspector Did you expand the category NewInspector and check the two first options ? See my attached screenshot. Once done, close the inspector and reopen it. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/11 morod <morod(a)tiscali.it> IÂm sorry but something may be wrong. My Pharo.image NewInspector installed System settings I tried again and the result has not changed Thanks again for your patience Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: lunedÃ¬ 11 ottobre 2010 00:23 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: R: Problem with inspector It's really strange. It works perfectly here. Step by step: - Download the last image of Pharo - Go to Monticello and load the last package of NewInspector - Go to System > Settings > Debugging > NewInspector - Check the options - Open a new inspector on an object The new children must appear. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Thanks for your interest, I have done what was suggested, but nothing has changed. Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: domenica 10 ottobre 2010 17:00 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: Problem with inspector If you load the last version of NewInspector (posted this morning), you go to the Settings Browser (System > Settings in the World menu), expand "Debugging" > "NewInspector" and check the options you want. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Hello, How can I switch from the two different versions of tool ÂInspectorÂ Best regards Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: sabato 9 ottobre 2010 14:08 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: Problem with inspector Hello, It's the NewInspector on both pictures but two different versions of this tool. In the old version, the class and the methods were displayed for each inspected object. In the current version, there are not displayed (because the community prefers less children for each object). FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/8 morod <morod(a)tiscali.it> Hi Mariano I tried it with multiple images and the behavior is the same with all the images. Sent the sample is made with: Pharo-1.1-11411 Latest update: #11411 The first one is my image and the second is taken from the book ÂPharo by ExampleÂ Thanks again Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Mariano Martinez Peck Inviato: venerdÃ¬ 8 ottobre 2010 21:43 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Problem with inspector Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> Hi iÂm new to smalltalk and Pharo and my inspector show Errore. Il nome file non Ã¨ specificato. instead of Errore. Il nome file non Ã¨ specificato. Why? Thanks _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Levente Uzonyi

On Tue, 12 Oct 2010, Levente Uzonyi wrote: > On Tue, 12 Oct 2010, Nicolas Cellier wrote: > >>> >>> I just realized that sometimes the 100 ms timeout is not enough even on >>> Cog >>> and the test fails, 200 ms works well. It typically happens when running >>> #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, >>> to >>> make sure it doesn't fail with SqueakVM or on slower machines. >>> >>> >>> Levente >>> >> >> Hmm, I increased to 1000ms, but still get some random failures... > > Yes, it's a bit strange. If I change it to 200ms, every test passes, no > random failures. If I increase it to 1000ms, I get random failures. Okay, I really tracked down the cause of the problem. The tests perform simple producer-consumer scenarios, but the consumers won't wait at all. If there's nothing to consume, the test fails. The randomness come from the scheduler. The server process is started first, the client is the second. If the server process can produce enough input to the client process the test will pass. If you decrease the priority of the client process by one in #timeout:server:client:, the randomness will be gone and the tests will reliably pass, because the client won't be able to starve the server. To avoid false timeouts I had to increase the timeout value to 2000 milliseconds using SqueakVM. I also found an issue: the process in XTTransformWriteStream doesn't terminate. If you run the tests, you'll get 12 lingering processes. Levente > > > Levente > >> >> Nicolas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 12, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Schwab,Wilhelm K

I've played similar games for a long time. Originally, I had to run on a Novell network, and it was a BSOD waiting to happen. So, I added a machine with the Novell client that did nothing but use a mapped drive to read from a source and push data over TCP/IP to my server, which happily no longer ran the Novell client, and hence did not throw a BSOD twice or more each week. Some time after that, I realized that the second machine could do more to help the server, and it ended up doing a fair amount of crunching, sending only summary data to the server. Works great. It's more boxes to maintain, but otherwise it's a nice arrangement. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 7:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] how to get the diff on commit on the pharo source? On 11 October 2010 20:03, Lukas Renggli <renggli(a)gmail.com> wrote: > It is not the mailing list that is the problem, it is the > squeaksource.com server that is. It takes several minutes to calculate > a simple diff of a single version and that just kills responsiveness > at the current rate of commits. > Its not necessary to do diff processing on squeaksource.com host. Another host could simply watch repositor(ies), and then download new versions and do diff & email it to mailing list. > Lukas > > On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Maybe on a separate mailing list. >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: >> >>> I would really like to have the same behavior than the squeak system ie having the source modification >>> send to the list. I could not see how to set it up on squeaksource. >>> May be this is not the same version running. >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, You seem to be doing a good job of this, so if you think I'm off, feel free to prove it. The executors (in Dolphin, the objects themselves) probably know more than the registry about how to handle errors, and (it seems to me) either generated them or could have readily caught them if there were something different to do based on the information. Maybe the crux of the matter is as follows: are you thinking of an executor class with subclasses that implement #handleFinalizationError: (a hook), or is it more "this happened, thought you might like to know." I think I read it more as the latter, probably assuming that #finalize would retry if that could reasonably be expected to help. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 6:35 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 12 October 2010 00:32, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > How hard it is or isn't is not nearly as important as your tackling it and doing so with the right tools. So again I say, carry on :) > > On self vs. executor as the receiver of #handleFinalizationError:, I might lean toward "self" as it will be closer to the system. There is probably little the executor can do, and it either missed or raised the error in the first place, right? I *think* the most you are going to to do is log that something went wrong, but I could be missing something. > I'm not sure about that . >From other size, a finalizer could better know why error can occur and how to handle it graciously, if its possible, and not just showing 'you suck' at the center of screen ;) Because weak registry can tell even less about nature of error, because it propably knows nothing about its finalizers, except that they understand #finalize message. > #ensure: attempts to evaluate the argument block whenever the receiver of it is completed (modulo some ominous sounding questions raised in the past months to a year??). #ifCurtailed: should be similar, but evaluating the argument/block only on abnormal (including, I think, ^) exit of the block. > > Does that help at all? > Yes. Thanks. I now remember semantics of it. Been there when dealt with Process>>terminate voodo. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 4:17 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The most important words in there are "critical section." Carry on :) >> > > Oh, please. This is not too hard to code. > > My mind rolling around following choice(s) (there may be others i don't see). > What would be a proper way to handle error during #finalize. > > [ executor finalize ] on: Error do: [:ex | > self handleFinalizationError: ex "where self is registry" > ]. > > or: > > [ executor finalize ] on: Error do: [:ex | > executor handleFinalizationError: ex > ]. > > > of course, i should catch this error in test, so i can verify that: > > a) test is get notified upon synthetically made error > b) no matter what i do inside error handler (up to 'Processor > activeProcess terminate'), a finalization process continues working > (or restarts without losing remainder of executors). > > > Also, i used #ensure: and #ifCurtailed: but i tend to forget where > they are applicable and how. > So, little help in this regard will be wellcome. > >> Bill >> > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010