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

Re: [Pharo-project] FileStream Squeak harvested

by StÃ©phane Ducasse

>>> >> >> StandardFileStream >> #readInto:startingAt:count: is wrong, there's a >> newer version. StandardFileStream >> #skip: is missing. >> The changes for MultiByteFileStream are also missing. Without those, the >> files' state may become corrupt and the expected system-wide speedup will >> be less significant. >> Changes of classes other than StandardFileStream are unrelated to the read >> buffering in the slice. > > There's also a new version of StandardFileStream >> #upTo: in the trunk, > which still begs for a cleanup (I wonder who thought that recursion > combined with #, will be fast). :)

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by StÃ©phane Ducasse

thanks levente. Now since this can also help squeak people. The trunk does not contain the complete history so this breaks monticello then browsing history. In pharo we pay attention to get **all** the ancestor chain for such a kind of analysis. Stef On Jan 15, 2010, at 7:14 PM, Levente Uzonyi wrote: > On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: > >> Hi: Today Stef and I have being harvested Squeak changes in FileStream. The >> most important is the work from Levente and the buffer. >> >> We commit the first slide in inbox: SLICE-FileStream-StephaneDucasse.1 >> >> Can someone take a look please because is this quite "important" to >> integrate. > > StandardFileStream >> #readInto:startingAt:count: is wrong, there's a > newer version. StandardFileStream >> #skip: is missing. > The changes for MultiByteFileStream are also missing. Without those, the > files' state may become corrupt and the expected system-wide speedup will > be less significant. > Changes of classes other than StandardFileStream are unrelated to the read > buffering in the slice. > > > Levente > >> >> Thanks >> >> Mariano >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 15, 2010

Re: [Pharo-project] Smalltalk interactive tutorial in good English

by Mariano Martinez Peck

2010/1/15 laurent laffont <laurent.laffont(a)gmail.com> > >> which I converted in a workspace. I used ShoutWorkspace for that because >> you have colors and is nicer :) >> > > Totally stupid question: how can I change the text inside a ShoutWorkspace > once it's opened ? > > Maybe my answer is more stupid than your question ;) I think I don't understand. If you change an opened Workspace, you are just changed that object. It is not persisted any more. In the example I gave you (DEVImageWorkspaces openWelcomeWorkspace for example) when I write the text, I write it inside the method in the class browser. I happens to me a lot of times that I start to modify it in the opened workspace instead of the code...so then I need to copy paste :) Cheers Mariano > If you want to see what I did, download the package >> ImageForDevelopers-pharo-MarianoMartinezPeck.212 >> from http://www.squeaksource.com/ImageForDevelopers >> >> See the class methods of DEVImageWorkspaces class >> >> I will add this tutorial also to the getting started part. What do you >> think ? >> > > If you want :) > > Laurent > > > > >> >> Cheers >> >> Mariano >> >> >> 2010/1/15 laurent laffont <laurent.laffont(a)gmail.com> >> >>> Hi >>> >>> I've written a sort of interactive tutorial based on (old) Stephane's >>> screencasts about Smalltalk syntax. >>> >>> It's called PrStef ;). To load it: >>> >>> Gofer new >>> squeaksource: 'PrStef'; >>> package: 'PrStef'; >>> load. >>> >>> and to run it: PrStef go. >>> >>> I'm looking for English-speaking people to check that the texts are >>> written in a correct English before I make a screencast on it. Thank you ! >>> >>> Cheers, >>> >>> Laurent >>> >>> _______________________________________________ >>> 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 >

Jan. 15, 2010

Re: [Pharo-project] About mime encoding

by StÃ©phane Ducasse

Thanks http://code.google.com/p/pharo/issues/detail?id=1822 Stef (I was in place where pop and smtp are forbidden ;-/ yes I could attack the nasa with them). On Jan 15, 2010, at 9:22 PM, Nicolas Cellier wrote: > 2010/1/15 Levente Uzonyi <leves(a)elte.hu>: >> On Fri, 15 Jan 2010, Nicolas Cellier wrote: >> >>> Sounds hackish to me. You are right to ask for a rationale and a >>> requirement before letting such line in. >> >> The line is in Pharo, but not in Squeak. >> >> >> Levente >> > > Oh, then it's easier, just post a short ultimatum and if no hands up, slay! > > Nicolas > >>> >>> Nicolas >>> >>> 2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> Hi >>>> >>>> in the squeak trunk >>>> >>>> jcg in collections-jcg.124 did >>>> >>>> mimeEncode: aStream >>>> "Return a ReadWriteStream of characters. The data of aStream is >>>> encoded as 65 innocuous characters. (See class comment). 3 bytes in aStream >>>> goes to 4 bytes in output." >>>> >>>> | me | >>>>>> >>>>>> aStream position: 0. >>>> >>>> me := self new dataStream: aStream. >>>> me mimeStream: (ReadWriteStream on: (String new: aStream size + 20 >>>> * 4 // 3)). >>>> me mimeEncode. >>>> me mimeStream position: 0. >>>> ^ me mimeStream >>>> >>>> I would like to know if one of you agree on that. >>>> >>>> Thanks >>>> Stef >>>> _______________________________________________ >>>> 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

Jan. 15, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by StÃ©phane Ducasse

On Jan 15, 2010, at 5:55 PM, Romain Robbes wrote: > yes it has overrides ... > > that's because as far as I know, there's no keyboard shortcut management facility > in Pharo. If there was one, I suppose Algernon and WorkingSet would coexist. I would love if someone would have a look at Keymapper and keybinding because we need to clear the mapping. People should be able to add emacs binding if they want (like me) wihtout impacting the complete system ;0 > > Romain > > > On Jan 15, 2010, at 6:49 AM, Damien Cassou wrote: > >> 2010/1/15 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> Thanks Damien. I did that, run the load of both projects but none of them >>> warn me. >>> >>> Are you sure they have overrides? >> >> I'm sure that WorkingSet has overrides, my detection code is probably >> not correct. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Romain Robbes > http://www.inf.unisi.ch/phd/robbes > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 15, 2010

Re: [Pharo-project] Smalltalk interactive tutorial in good English

by StÃ©phane Ducasse

+1 Yes We should clean this part. I remember that there was a fun expression to fetch an image over the network Stef On Jan 15, 2010, at 5:28 PM, Mariano Martinez Peck wrote: > Cool. But I think the idea is not to use Sensor anymore but InputEventSensor. At least, when possible. > > Cheers > > Mariano > > On Fri, Jan 15, 2010 at 5:24 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > There is also the World's smallest drawing program > > http://wiki.squeak.org/squeak/126 > > which has to be adapted due to sensor changes > (take care it is dog slow compared to squeak): > > > | myPen | > myPen := Pen new defaultNib: 2. > myPen up. > myPen goto: Sensor cursorPoint. > myPen down. > [Sensor waitButton. Sensor yellowButtonPressed] whileFalse: > [Sensor redButtonPressed > ifTrue: [myPen goto: Sensor cursorPoint]]. > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > 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

Jan. 15, 2010

Re: [Pharo-project] Smalltalk interactive tutorial in good English

by StÃ©phane Ducasse

I love it! especially the PrStef previous :) and the expression with the PrStef next inside It was a great idea. > Gofer new > squeaksource: 'PrStef'; > package: 'PrStef'; > load. On Jan 15, 2010, at 4:29 PM, laurent laffont wrote: > Hi > > I've written a sort of interactive tutorial based on (old) Stephane's screencasts about Smalltalk syntax. > > It's called PrStef ;). To load it: > > Gofer new > squeaksource: 'PrStef'; > package: 'PrStef'; > load. > > and to run it: PrStef go. > > I'm looking for English-speaking people to check that the texts are written in a correct English before I make a screencast on it. Thank you ! > > Cheers, > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 15, 2010

Re: [Pharo-project] MC case sensitity and sub-packages

by StÃ©phane Ducasse

On Jan 15, 2010, at 4:09 PM, Schwab,Wilhelm K wrote: > Stef, > > It looks as though this might work as I had hoped, though I am giving careful consideration to your concern. I had both DolphCompatibility and Dolphincompatibility in package names; there were a few of the later form. I used PackageOrganizer to enumerate the package names, selected the incorrect ones, then unregistered them. pay attention PackageOrganizer was full of dust > After the above and fixing a couple of things in my Migrate pacakge names list, my suspect methods report is down to five methods that are expected to appear. The save of the enumerated top-level packages *appears* to have worked. I will need to try building an image from them before getting too full of myself. :) > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K > Sent: Friday, January 15, 2010 9:17 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] MC case sensitity and sub-packages > > Stef, > > I am doing some housekeeping toward building a new image. Changes such as below have allowed me to get Migrate into an almost-releasable state. One of its jobs is to look for code that is at risk of being lost, and that feature is detecting a LOT of code that should be safe; it is probably due to the extra packages. I had hoped that I could safely avoid the "double save" problem, but this is even worse than that :( > > Absent a simple solution, the answer is to delete DolphinCompatibility and others. The next question is then: will I have problems with dependencies between the sub-packages? I am wondering whether there could be problems saving separate packages like > > DolphinCompatibility-Streams > DolphinCompatibility-ODBC > > when DolphinCompatibility would be perfectly happy. > > Does that make sense? > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Wednesday, January 13, 2010 2:40 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] MC case sensitity and sub-packages > > > On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote: > >> Brian and others have told me that I could expect to define packages >> such as >> >> DolphinCompatibility-ODBC >> DolphinCompatibility-Streams >> >> and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC. I was unable to make it work reliably, and I think I might have just figured out why. > > I really encourage you to save them as separate packages if you want to load and save them all build a metacelloConfig (not difficult and worth). > don;t define a package DolphinCompatibility in addition (else you will get in trouble because your classes will be saved somehow twice)., I hate this pattern matching behavior. > >> Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving. >> >> It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that. > > probably I do not like that part of the system >> >> Does that sound right? Am I missing something that might cost me later? >> >> Bill >> >> >> _______________________________________________ >> 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

Jan. 15, 2010

Re: [Pharo-project] MC case sensitity and sub-packages

by StÃ©phane Ducasse

Bill your english is too rich for us poor non native speakers so we may miss what you imply :) > Stef, > > I am doing some housekeeping toward building a new image. Changes such as below have allowed me to get Migrate into an almost-releasable state. One of its jobs is to look for code that is at risk of being lost, and that feature is detecting a LOT of code that should be safe; it is probably due to the extra packages. I had hoped that I could safely avoid the "double save" problem, but this is even worse than that :( what happen? > Absent a simple solution, the answer is to delete DolphinCompatibility and others. The next question is then: will I have problems with dependencies between the sub-packages? which subpackages? > I am wondering whether there could be problems saving separate packages like > > DolphinCompatibility-Streams > DolphinCompatibility-ODBC > > when DolphinCompatibility would be perfectly happy. > > Does that make sense? > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Wednesday, January 13, 2010 2:40 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] MC case sensitity and sub-packages > > > On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote: > >> Brian and others have told me that I could expect to define packages >> such as >> >> DolphinCompatibility-ODBC >> DolphinCompatibility-Streams >> >> and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC. I was unable to make it work reliably, and I think I might have just figured out why. > > I really encourage you to save them as separate packages if you want to load and save them all build a metacelloConfig (not difficult and worth). > don;t define a package DolphinCompatibility in addition (else you will get in trouble because your classes will be saved somehow twice)., I hate this pattern matching behavior. > >> Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving. >> >> It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that. > > probably I do not like that part of the system >> >> Does that sound right? Am I missing something that might cost me later? >> >> Bill >> >> >> _______________________________________________ >> 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

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Levente Uzonyi

On Fri, 15 Jan 2010, Nicolas Cellier wrote: > 2010/1/15 Levente Uzonyi <leves(a)elte.hu>: >> On Fri, 15 Jan 2010, Levente Uzonyi wrote: >> >>> On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: >>> >>>> Hi: Today Stef and I have being harvested Squeak changes in FileStream. The >>>> most important is the work from Levente and the buffer. >>>> >>>> We commit the first slide in inbox: Â SLICE-FileStream-StephaneDucasse.1 >>>> >>>> Can someone take a look please because is this quite "important" to >>>> integrate. >>> >>> StandardFileStream >> #readInto:startingAt:count: is wrong, there's a >>> newer version. StandardFileStream >> #skip: is missing. >>> The changes for MultiByteFileStream are also missing. Without those, the >>> files' state may become corrupt and the expected system-wide speedup will >>> be less significant. >>> Changes of classes other than StandardFileStream are unrelated to the read >>> buffering in the slice. >> >> There's also a new version of StandardFileStream >> #upTo: in the trunk, >> which still begs for a cleanup (I wonder who thought that recursion >> combined with #, will be fast). >> >> >> Levente >> > > Yeah, kust peek code in Xtream, it's faster I'm not about to fix it. The method comment made me think, that #upTo: is used by #nextChunk, so I added the check for the simple case, but later realized that #nextChunk doesn't use #upTo:, because it can't, so I just kept the fallback code. (The bug was unnoticed for more than a month, so I guess #upTo: is not used at all, I found it while I was reviewing the code.) Levente > > Nicolas > >>> >>> Levente >>> >>>> >>>> Thanks >>>> >>>> Mariano >>>> >>> >>> _______________________________________________ >>> 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 >

Jan. 15, 2010