- Pharo-dev - lists.pharo.org

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

[Pharo-project] Storing all source code in a relational database

by Reg Krock

Igor, I am emailing you offline but I just do not get why people are so interested in storing source code in a relational database. We have objects, there is a known mismatch between the object and relational world. So how does the relational database help out? Cincom has spent many man-years attempting to make STORE work well. A few grad students wrote ENVY in the 80's and it is a way superior in most ways to all other code repositories.Â Has anyone at INRIA looked at ENVY?Â Regards, Reg ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, November 3, 2011 10:00:31 AM Subject: Re: [Pharo-project] Storing all source code in a relational database On 3 November 2011 00:20, Stephan Eggermont <stephan(a)stack.nl> wrote: > ... is a waste of time and computing resources. Relational databases are optimized > for specific usage scenarios. CAD systems and source code management systems > are the archetypical examples of systems that are a bad fit and will kill the performance > of a relational database. Of course 30 years later you can brute force it, but that doesn't > make it a good idea. Git is far superior to rdb based systems for the day-to-day work > and the analytics should be done from a ram-based object model. > Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal. > Stephan > -- Best regards, Igor Stasenko.

Nov. 3, 2011

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

by Max Leske

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?) 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 StÃ©phane Ducasse

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

Re: [Pharo-project] FSReference

by StÃ©phane Ducasse

we should record what you find so that we can fix it. On Nov 3, 2011, at 2:25 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote: >> >> Would it be valuable to have FSFileReference and FSDirectoryReference >> subclasses? >> > > Another weird ramification of FSReference's identity ambiguity is, on a > reference to an existing file: > * #allChildren -> anArray containing only the file itself > * children -> an error > > -- > View this message in context: http://forum.world.st/FSReference-tp3985640p3985818.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 3, 2011

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

by Hilaire Fernandes

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