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

[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

[Pharo-project] relation to squeak

by Milan Mimica

Hello! One thing is not clear to me. How is Pharo related to standard Squeak? I know Pharo is a fork with its own mission, but is the development related? Do fixes in Pharo propagate upstream to Squeak? Is Squeak even considered "upstream"? Do fixes in Squeak propagate into Pharo? Automatically or manually? Or have they started being developed completely independently from some point in time? -- Milan Mimica http://sparklet.sf.net

Nov. 3, 2011

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

by Igor Stasenko

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] FSReference

by Sean P. DeNigris

More ugly conditionals from inside the FS library... (self exists: path) ifTrue: [ (self isFile: path) ifTrue: [ self signalFileExists: path ] ifFalse: [ self signalDirectoryExists: path ] ]. (self isDirectory: parent) -- View this message in context: http://forum.world.st/FSReference-tp3985640p3985973.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

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

by Igor Stasenko

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] Moving a file

by Sean P. DeNigris

I found FSReference>>renameAs:, which doesn't work (there's already an issue filed), but seems to provide something similar. So maybe we just need a moveTo: that forwards to renameAs:, or v.v. I'll know more if I can get renameAs: working. Trying now... -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3985924.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011