November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FS Quirks

by StÃ©phane Ducasse

Thanks somebody has to take some times and go over them, write some tests and some fixes. I noticed that the chapter has some code that does not work anymore with the latest version. stef On Nov 3, 2011, at 4:23 PM, Sean P. DeNigris wrote: > I noticed a few things about FS, but I don't understand it well enough yet to > know if they are bugs: > * there are #basicXxx methods scattered around with no corresponding #xxx > method. It seems like these should be renamed to #xxx > * FSFileSystem has #open:writable which does not call #basicOpen:writable, > which exists > * FSReference>>rename:as:, but FSFilePluginPrims>>rename:to: (to: sounds > better to me) > > -- > View this message in context: http://forum.world.st/FS-Quirks-tp3986296p3986296.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Igor Stasenko

On 3 November 2011 17:16, Max Leske <maxleske(a)gmail.com> wrote: > :-D > I said: "In MY opinion" > > Ok, so the .changes file serves as a backup. But shouldn't the file be optional? e.g. the source code is in the image and changes are backed up to an extra file to guard against crashes. But I think, the image should not depend on that file. > Does this make more sense? > It is. > Max > > > On 03.11.2011, at 16:12, Sean P. DeNigris wrote: > >> >> Frank Shearar-3 wrote: >>> >>> I'm tempted to say that if you've never had to use your .changes file >>> to recover, you're not working hard enough :) >> >> Oh my, how my *ss has been saved by the .changes file. Especially while >> doing dangerous but important things (e.g testing bleeding edge cog vms). I >> can't count the hours... >> >> -- >> View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Best regards, Igor Stasenko.

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Max Leske

:-D I said: "In MY opinion" Ok, so the .changes file serves as a backup. But shouldn't the file be optional? e.g. the source code is in the image and changes are backed up to an extra file to guard against crashes. But I think, the image should not depend on that file. Does this make more sense? Max On 03.11.2011, at 16:12, Sean P. DeNigris wrote: > > Frank Shearar-3 wrote: >> >> I'm tempted to say that if you've never had to use your .changes file >> to recover, you're not working hard enough :) > > Oh my, how my *ss has been saved by the .changes file. Especially while > doing dangerous but important things (e.g testing bleeding edge cog vms). I > can't count the hours... > > -- > View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 3, 2011

Re: [Pharo-project] relation to squeak

by Frank Shearar

On 3 November 2011 15:05, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > While there is no official relationship, it seems to me that the communities > are becoming very friendly and symbiotic, after the initial tension that > always accompanies a "break up" ;-) There were lively, fun, interesting > dinners including key members of both at ESUG this year. Fixes are > propagated both ways if the devs think they are valuable. Much of the API > seems to still be the same, as the major focus so far seems to be clean up. > During this process, Pharo has been much more aggressive about removing > ugly/dirty code because backward compatibility is not as primary to the > mission as it is in Squeak. Also, there are many exciting fundamental > projects underway in Pharo (new filesystem, compiler, browser, on and on), > so the forks may diverge quite a bit in the near future. There are also a number of folks spending time in both communities: I wouldn't be surprised to see many of those exciting new projects being ported to Squeak. frank > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/relation-to-squeak-tp3986029p3986229.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 3, 2011

[Pharo-project] FS Quirks

by Sean P. DeNigris

I noticed a few things about FS, but I don't understand it well enough yet to know if they are bugs: * there are #basicXxx methods scattered around with no corresponding #xxx method. It seems like these should be renamed to #xxx * FSFileSystem has #open:writable which does not call #basicOpen:writable, which exists * FSReference>>rename:as:, but FSFilePluginPrims>>rename:to: (to: sounds better to me) -- View this message in context: http://forum.world.st/FS-Quirks-tp3986296p3986296.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Sean P. DeNigris

Frank Shearar-3 wrote: > > I'm tempted to say that if you've never had to use your .changes file > to recover, you're not working hard enough :) Oh my, how my *ss has been saved by the .changes file. Especially while doing dangerous but important things (e.g testing bleeding edge cog vms). I can't count the hours... -- View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] Moving a file

by Sean P. DeNigris

I wrote a partial fix (move and rename now work for disk filesystems on my mac) and uploaded it to sqs/fs. Here's the package comment for FS-Core-SeanDeNigris.16 (the other affected package is FS-Disk-SeanDeNigris.4): > * Partially fixed FSReference>>renameAs:. It now works for disk > filesystems. > * added FSReference>>moveTo: > > WARNING: this introduces a slight change into the API. #renameAs: now is a > shortcut to simply change a file's name while staying in the same parent > directory. As such, it now takes a string (used to take a path or string). > What renameAs: used to do (move to an arbitrary other location) is now > done by #moveTo: which takes a target reference. > I tested by hand, but at minimum, it's less broken than before :) It doesn't touch any other parts of FS, so shouldn't have broken anything else. Sean -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3986244.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] relation to squeak

by Sean P. DeNigris

While there is no official relationship, it seems to me that the communities are becoming very friendly and symbiotic, after the initial tension that always accompanies a "break up" ;-) There were lively, fun, interesting dinners including key members of both at ESUG this year. Fixes are propagated both ways if the devs think they are valuable. Much of the API seems to still be the same, as the major focus so far seems to be clean up. During this process, Pharo has been much more aggressive about removing ugly/dirty code because backward compatibility is not as primary to the mission as it is in Squeak. Also, there are many exciting fundamental projects underway in Pharo (new filesystem, compiler, browser, on and on), so the forks may diverge quite a bit in the near future. HTH, Sean -- View this message in context: http://forum.world.st/relation-to-squeak-tp3986029p3986229.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Frank Shearar

On 3 November 2011 14:41, Max Leske <maxleske(a)gmail.com> wrote: > We manage our source code with Monticello and I have never had to use the .changes file to get my code back. > As I've said before: as far as I'm concerned, .sources and .changes have outlived their usefulness (not sure about the android and iPhone ports though. There might be an advantage regarding memory / disk space?) I'm tempted to say that if you've never had to use your .changes file to recover, you're not working hard enough :) Even without doing extra tricky things, consider your image open on your laptop. You shut the lid, having realised your train's just about to arrive at your stop. You get to where you're going and your laptop's decided to switch off. (Or your laptop battery runs flat.) Your .changes file lets you recover your work. frank > Max > > > On 03.11.2011, at 15:08, Igor Stasenko wrote: > >> On 3 November 2011 12:57, Guido Stepken <gstepken(a)googlemail.com> wrote: >>> I always thought, the IMAGE *is* already an OO database!?? >>> >> >> Yes, storing all sources in image should be also possible. >> The only problem with it, if your image crashes, you losing everything >> you did without chance of restoring it. >> That's why storing sources externally is better idea, at least from >> safety point of view. >> >> But again, it should be possible to choose where to store sources, not >> like today, when you have only .source and .changes. >> >> >>> Guido Stepken >>> >>> Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> How about new source code management? >>>> >>>> In terms of: >>>> - better abstraction of source code access in image >>>> - create a shared repository (database) , which can be used to browse >>>> the history of all source code of Pharo and its predecessor up to >>>> Squeak 1.0. >>>> >>>> We are discussed this idea couple times, and we already having some >>>> pieces of puzzle , like Ring. >>>> Also, there is already a project made by someone (forgot the name) , >>>> who already storing all source code in database and managing it there. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > >

Nov. 3, 2011

Re: [Pharo-project] Small tool to edit bloc code

by Hilaire Fernandes

Yes, this is waht I did for the Script feature in DRGeo, I just the standard Browser on a class. May be I will do that again for thhis bc (anonymous method) Hilaire Le 03/11/2011 15:35, StÃ©phane Ducasse a Ã©crit : > what I did in botsinc was an editor for a single class may be you reuse that. > > Stef > > On Nov 3, 2011, at 3:31 PM, Hilaire Fernandes wrote: > >> Let's say I want the user to describe a point position with a blockclosure: >> >> [:parents | >> compute-point-coordinates] >> >> I can use a workspace to let the user write this code, then caputre the >> workspace content. >> >> I will prefer I code browser, but it is attached to classes. I can of >> course use a dummy class... Many alternatives. Are there other alternatives? >> >> Hilaire >> >> >> Le 03/11/2011 08:09, StÃ©phane Ducasse a Ã©crit : >>> What do you mean by a block of code? >>> >>> With a syntax for method >>> >>> >>> Point>>foo >>> [ >>> >>> ] >>> >>> ? >>> in that case I would use the syntax extension we did for coral based on petitparser. >>> >>> Stef >>> >>> On Nov 1, 2011, at 9:30 PM, Hilaire Fernandes wrote: >>> >>>> From DrGeo I would like the user to edit Smalltalk code in the form of >>>> block of code. >>>> The user interface I need is maninly to let the user write and compile >>>> code. When compiled, DrGeo should get a notification to fetch the code >>>> for internal use. >>>> >>>> What is the best candidate to do that ? >>>> >>>> Hilaire >>>> >>>> >>>> -- >>>> Education 0.2 -- http://blog.ofset.org/hilaire >>>> >>>> >>> >>> >>> >> >> > > >

Nov. 3, 2011