In Smalltalk you can't loose code... hum
Locked
In Smalltalk you can't loose code... hum
 
|
Hi,
the statement is true when the code is saved in the browser. But in a workspace or in the script manager that is not true. Actually it is a feature request: You can't loose code even when you are working in the script browser. Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? Francois _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
Hi,
2010/9/25 François Tanguy <[hidden email]>: > Hi, > > the statement is true when the code is saved in the browser. > But in a workspace or in the script manager that is not true. You can save a workspace into a file and it will be renewed each time you press Cmd+S. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by François Tanguy
On Sep 25, 2010, at 9:25 PM, François Tanguy wrote: > Hi, > > the statement is true when the code is saved in the browser. > But in a workspace or in the script manager that is not true. > > Actually it is a feature request: You can't loose code even when you are working in the script browser. check if you can find a way and I'm sure that the maintainer of scriptmanager will integrate it. I always prefer to define methods so I never use script or workspace to write anything useful. > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. This is why slowly we will have to think to get something better. > > Francois > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
On Sat, Sep 25, 2010 at 12:53 PM, Stéphane Ducasse <[hidden email]> wrote:
Do you mean improving the change scanner parsing or throwing away and going for something different?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Stéphane Ducasse
Le 25 sept. 2010 à 21:53, Stéphane Ducasse a écrit : > > On Sep 25, 2010, at 9:25 PM, François Tanguy wrote: > >> Hi, >> >> the statement is true when the code is saved in the browser. >> But in a workspace or in the script manager that is not true. >> >> Actually it is a feature request: You can't loose code even when you are working in the script browser. > > check if you can find a way and I'm sure that the maintainer of scriptmanager will integrate it. > I always prefer to define methods so I never use script or workspace to write anything useful. In my case, I wrote some crap and got an endless loop... Had to quit the image and lost some code. But I kind of like the script manager to write codes that build models or examples to remind me how to do some stuff. I will have a look at the script manager and hope we can come up with a solution. At least when Cmd + S is pressed, the minimum would be to save the code. > >> >> Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? > > the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. > This is why slowly we will have to think to get something better. > > >> >> Francois >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by George Herolyants-3
Le 25 sept. 2010 à 21:43, George Herolyants a écrit : > Hi, > > 2010/9/25 François Tanguy <[hidden email]>: >> Hi, >> >> the statement is true when the code is saved in the browser. >> But in a workspace or in the script manager that is not true. > > You can save a workspace into a file and it will be renewed each time > you press Cmd+S. Here is what I did: 1) Open a workspace / save the image 2) edit the workspace / save Cmd + S 3) quit Pharo without saving 4) Open pharo -> the workspace is empty > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
2010/9/26 François Tanguy <[hidden email]>:
> Here is what I did: > 1) Open a workspace / save the image > 2) edit the workspace / save Cmd + S > 3) quit Pharo without saving > 4) Open pharo -> the workspace is empty Of course :) You discarded the state of all the objects you created or modified during your Pharo session. There is no object representing workspace anymore. The same result will be if you add some method to some class, after image restart (without saving) there will be no such method. In this case you can use Recover Lost Changes tool to restore your method from .changes file. But in case of workspace you should *explicitely* save it into a file (using a window menu). And after image restart you will be able to restore it from that file. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Stéphane Ducasse
>
> > > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? > > the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. > This is why slowly we will have to think to get something better. > > Do you mean improving the change scanner parsing or throwing away and going for something different? > Hi eliot our vision is that we would like to have - all the code of all the squeak and pharo version in a queryable service available from the web. for that we want a source code metamodel a la ginsu or famix Use this metamodel to aggregate several meta models: pseudo class/rb make sure that when possible this model as a compative API with the one of classes and friends => tools reuse Veronica is working on that. Hernan will probably join. May be Colin should join. We could have a nice momentum. - for the changes we would like to have something else than a chunk format because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that and token at: 3 do that). Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool easily. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse <[hidden email]> wrote:
xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see
<method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> but this would be much mire useful: <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method>
Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
Keeping things out of the change log? Does that imply that all code must be packaged? It more or less is already, though not always meaningfully. When repackaging a class or method, do you plan to take the code out of the old package's log and put it in the new one? Dolphin uses "real" packages, but it is possible to have unpackaged code - I'm not sure if that's a good thing or not. One day, I would like to see Pharo have a *hierarchy* browser as good as Dolphin's. I think it could be built absent an ability to have unpackaged classes, but I would not want to see it sabotaged by design. Probably a bigger risk would be having work lost by gaps in the packaging system when a catch-all change log would have held onto it.
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Eliot Miranda [[hidden email]] Sent: Sunday, September 26, 2010 11:18 AM To: [hidden email] Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse <[hidden email]<mailto:[hidden email]>> wrote: > > > > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? > > the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. > This is why slowly we will have to think to get something better. > > Do you mean improving the change scanner parsing or throwing away and going for something different? > Hi eliot our vision is that we would like to have - all the code of all the squeak and pharo version in a queryable service available from the web. for that we want a source code metamodel a la ginsu or famix Use this metamodel to aggregate several meta models: pseudo class/rb make sure that when possible this model as a compative API with the one of classes and friends => tools reuse Veronica is working on that. Hernan will probably join. May be Colin should join. We could have a nice momentum. - for the changes we would like to have something else than a chunk format because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that and token at: 3 do that). xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> but this would be much mire useful: <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool easily. Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. Stef _______________________________________________ Pharo-project mailing list [hidden email]<mailto:[hidden email]> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by George Herolyants-3
Some times ago I added an option "Previous Content" in a workspace. Get the menu of the workspace (click on the top right icon of a workspace window).
Cheers, Alexandre On 26 Sep 2010, at 02:48, George Herolyants wrote: > 2010/9/26 François Tanguy <[hidden email]>: >> Here is what I did: >> 1) Open a workspace / save the image >> 2) edit the workspace / save Cmd + S >> 3) quit Pharo without saving >> 4) Open pharo -> the workspace is empty > > Of course :) You discarded the state of all the objects you created or > modified during your Pharo session. There is no object representing > workspace anymore. The same result will be if you add some method to > some class, after image restart (without saving) there will be no such > method. In this case you can use Recover Lost Changes tool to restore > your method from .changes file. But in case of workspace you should > *explicitely* save it into a file (using a window menu). And after > image restart you will be able to restore it from that file. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Eliot Miranda-2
2010/9/26 Eliot Miranda <[hidden email]>:
> > > BTW, now we have Igor's method trailers we can start playing with more than > two source files, e.g. /not/ appending a Monticello package's source to the > changes file, but merely adding it to a special directory, e.g. sources. Yes. I told about potential use of new trailers, where we can implement a model for storing/retrieving source code from any kind of storage. Unfortunately it requires some remodelling of system's source-code management system, to get rid of hard-wired SourceFiles code and add an abstract layer for source management. So we could implement different source managers, where .source and .changes will be just default one. One of my ideas was to use CouchDB for storing everything there. It opens quite interesting opportunities, like being able to browse a history of some particular method up to 1.0 squeak release :) @Stef: add this to pharo todo list :) >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Stéphane Ducasse
>
> > Hi eliot > > our vision is that we would like to have > - all the code of all the squeak and pharo version in a queryable service available from the web. > for that we want a source code metamodel a la ginsu or famix > Use this metamodel to aggregate several meta models: pseudo class/rb > make sure that when possible this model as a compative API with the one of classes and friends => tools reuse > Veronica is working on that. > Hernan will probably join. > May be Colin should join. We could have a nice momentum. > > - for the changes we would like to have something else than a chunk format > because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that > and token at: 3 do that). > > xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see > > <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > but this would be much mire useful: > > <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> I know I told you that a while ago when you were still at cincom (probably around 2002 or 2003 when doru started his phd :) In the way vw does it defeats the purpose of having a markup language. Now XML is good when we do not have a language syntax that can mimic a declarative language. I was always amazed that tweak could use xml to represent CField instead of using plain CField new name: #nameOfVariable; ... So instead of xml (which requires to have an XML parser at end. We could have MethodDefinition selector: #on: ; class: #Bar; body: 'on: aStream aStream nextPutAll: 'jlkjlkj'. ^ self'. this way no need for a bad parser. > Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. Probably the problem is that I would love to have 3 days in a row to code and be concentrated. And we cannot change eveyrthing at the same time. > BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. I have to digest that :) > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Eliot Miranda-2
I do not know exactly what you mean.
We want a good, working and flexible system. We just a problem of time. Stef On Sep 26, 2010, at 7:11 PM, Schwab,Wilhelm K wrote: > Keeping things out of the change log? Does that imply that all code must be packaged? It more or less is already, though not always meaningfully. When repackaging a class or method, do you plan to take the code out of the old package's log and put it in the new one? Dolphin uses "real" packages, but it is possible to have unpackaged code - I'm not sure if that's a good thing or not. One day, I would like to see Pharo have a *hierarchy* browser as good as Dolphin's. I think it could be built absent an ability to have unpackaged classes, but I would not want to see it sabotaged by design. Probably a bigger risk would be having work lost by gaps in the packaging system when a catch-all change log would have held onto it. > > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Eliot Miranda [[hidden email]] > Sent: Sunday, September 26, 2010 11:18 AM > To: [hidden email] > Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum > > On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse <[hidden email]<mailto:[hidden email]>> wrote: >> >>> >>> Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? >> >> the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. >> This is why slowly we will have to think to get something better. >> >> Do you mean improving the change scanner parsing or throwing away and going for something different? >> > > Hi eliot > > our vision is that we would like to have > - all the code of all the squeak and pharo version in a queryable service available from the web. > for that we want a source code metamodel a la ginsu or famix > Use this metamodel to aggregate several meta models: pseudo class/rb > make sure that when possible this model as a compative API with the one of classes and friends => tools reuse > Veronica is working on that. > Hernan will probably join. > May be Colin should join. We could have a nice momentum. > > - for the changes we would like to have something else than a chunk format > because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that > and token at: 3 do that). > > xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see > > <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > but this would be much mire useful: > > <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > > > Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool > easily. > > Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. > > BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Eliot Miranda-2
>> BTW, now we have Igor's method trailers we can start playing with more than
>> two source files, e.g. /not/ appending a Monticello package's source to the >> changes file, but merely adding it to a special directory, e.g. sources. > > Yes. I told about potential use of new trailers, where we can implement a model > for storing/retrieving source code from any kind of storage. > > Unfortunately it requires some remodelling of system's source-code > management system, > to get rid of hard-wired SourceFiles code and add an abstract layer > for source management. > So we could implement different source managers, where .source and > .changes will be just default one. > > One of my ideas was to use CouchDB for storing everything there. It > opens quite interesting opportunities, > like being able to browse a history of some particular method up to > 1.0 squeak release :) > > @Stef: add this to pharo todo list :) but this one is on the path of veronica phd so we should do it fast. Veronica likes to work under pressure so this is good. stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
On 26 September 2010 21:53, Stéphane Ducasse <[hidden email]> wrote:
>>> BTW, now we have Igor's method trailers we can start playing with more than >>> two source files, e.g. /not/ appending a Monticello package's source to the >>> changes file, but merely adding it to a special directory, e.g. sources. >> >> Yes. I told about potential use of new trailers, where we can implement a model >> for storing/retrieving source code from any kind of storage. >> >> Unfortunately it requires some remodelling of system's source-code >> management system, >> to get rid of hard-wired SourceFiles code and add an abstract layer >> for source management. >> So we could implement different source managers, where .source and >> .changes will be just default one. >> >> One of my ideas was to use CouchDB for storing everything there. It >> opens quite interesting opportunities, >> like being able to browse a history of some particular method up to >> 1.0 squeak release :) >> >> @Stef: add this to pharo todo list :) > > but this one is on the path of veronica phd so we should do it fast. > Veronica likes to work under pressure so this is good. > for phd thesis, you already had a plan & assignee for it :) Nice. > stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Stéphane Ducasse
On Sep 26, 2010, at 8:59 PM, Igor Stasenko wrote: > On 26 September 2010 21:53, Stéphane Ducasse <[hidden email]> wrote: >>>> BTW, now we have Igor's method trailers we can start playing with more than >>>> two source files, e.g. /not/ appending a Monticello package's source to the >>>> changes file, but merely adding it to a special directory, e.g. sources. >>> >>> Yes. I told about potential use of new trailers, where we can implement a model >>> for storing/retrieving source code from any kind of storage. >>> >>> Unfortunately it requires some remodelling of system's source-code >>> management system, >>> to get rid of hard-wired SourceFiles code and add an abstract layer >>> for source management. >>> So we could implement different source managers, where .source and >>> .changes will be just default one. >>> >>> One of my ideas was to use CouchDB for storing everything there. It >>> opens quite interesting opportunities, >>> like being able to browse a history of some particular method up to >>> 1.0 squeak release :) >>> >>> @Stef: add this to pharo todo list :) >> >> but this one is on the path of veronica phd so we should do it fast. >> Veronica likes to work under pressure so this is good. >> > Haha.. so, when i described it sometimes ago you told that this good > for phd thesis, > you already had a plan & assignee for it :) I do not remember. doing too much stuff. Now the PhD of veronica is not one source code management. The PhD of veronica is about: how to help merging. How could we add a bit of semantics. In this topic we would like - to get changes characterization (cf ESUg talk) - to know the potential impact of a change - compare feature in the past and feature so having a good infrastructure will help everybody. We should be able to write nice and short queries to study the past and the present. Stef > > Nice. > >> stef >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by François Tanguy
> But in a workspace or in the script manager that is not true.
Statements in workspace that were ever invoked with "do it" et al are recoverable from the changes log. But this is one feature of workspaces, they are _very_ transient. I have sometimes found a domain class' class-side method category, "scripts" or "utilities" on relevant domain class-side, helps for this recoverability while also co-locating the useful scripts with the relevant class. In extreme case, a [App-Name-Here]Utilities class can be a good script holder. > Actually it is a feature request: You can't loose code even when you are working in the script browser. > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? > > Francois > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: In Smalltalk you can't loose code... hum
|
|
In reply to this post by Stéphane Ducasse
Stef,
About the CHB (you just have to use Dolphin's for a while to see what I mean). Most of the substantive differences are probably in deference to speed?? Maybe when Cog is mainstream, we can just "let it go." Dolphin's CHB presents the entire class hierarchy rather than showing little pieces of it here and there, which has always been my experience with Squeak's CHB. About moving code away from the change log, I am simply worried about all of the complexities that can arise. I largely don't care how the system works provide it works *really* well<g> and that it has some redundancy in case I manage to fry an image, and moving code away from the log strikes me as real time sink to get right, so I am urging caution with change where code is stored. I fully supportive of a new packaging system that has concrete packages and frees up method categories. Does that help? Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Sunday, September 26, 2010 2:51 PM To: [hidden email] Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum I do not know exactly what you mean. We want a good, working and flexible system. We just a problem of time. Stef On Sep 26, 2010, at 7:11 PM, Schwab,Wilhelm K wrote: > Keeping things out of the change log? Does that imply that all code must be packaged? It more or less is already, though not always meaningfully. When repackaging a class or method, do you plan to take the code out of the old package's log and put it in the new one? Dolphin uses "real" packages, but it is possible to have unpackaged code - I'm not sure if that's a good thing or not. One day, I would like to see Pharo have a *hierarchy* browser as good as Dolphin's. I think it could be built absent an ability to have unpackaged classes, but I would not want to see it sabotaged by design. Probably a bigger risk would be having work lost by gaps in the packaging system when a catch-all change log would have held onto it. > > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Eliot Miranda [[hidden email]] > Sent: Sunday, September 26, 2010 11:18 AM > To: [hidden email] > Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum > > On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse <[hidden email]<mailto:[hidden email]>> wrote: >> >>> >>> Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? >> >> the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. >> This is why slowly we will have to think to get something better. >> >> Do you mean improving the change scanner parsing or throwing away and going for something different? >> > > Hi eliot > > our vision is that we would like to have > - all the code of all the squeak and pharo version in a queryable service available from the web. > for that we want a source code metamodel a la ginsu or famix > Use this metamodel to aggregate several meta models: pseudo class/rb > make sure that when possible this model as a compative API with the one of classes and friends => tools reuse > Veronica is working on that. > Hernan will probably join. > May be Colin should join. We could have a nice momentum. > > - for the changes we would like to have something else than a chunk format > because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that > and token at: 3 do that). > > xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see > > <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > but this would be much mire useful: > > <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > > > Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool > easily. > > Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. > > BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |