I just pushed the (hopefully) final version of Pharogenesis to github (github.com/pharogenesis/pharogenesis). I appologize to the followers for deleting and recreating the repository but that's the only way to keep the history clean.
Max |
Wow, very cool!
Just for others to realize what this is... Let's assume you want to see the change history of HTTPSocket class>>httpGetDocument:args:accept:request:. With blame you can see for each line who changed it and when: https://github.com/pharogenesis/pharogenesis/blame/pharo/HTTPSocket/class/get%20the%20page/httpGetDocument-3A-args-3A-accept-3A-request-3A-.cs Or you can see diffs between particular versions. E.g., httpFileIn: was changed in 2005 as follows: https://github.com/pharogenesis/pharogenesis/commit/d88d2b9c9fdb234c7d6b977e513561a8d45d1c04#HTTPSocket/class/get the page/httpFileIn-3A-.cs Could the method versions dialog be extended to grab this data from GitHub? Cheers, Adrian On Mar 15, 2011, at 10:22 , Max Leske wrote: > I just pushed the (hopefully) final version of Pharogenesis to github (github.com/pharogenesis/pharogenesis). I appologize to the followers for deleting and recreating the repository but that's the only way to keep the history clean. > > Max |
Enabling remote access is an important next step but I haven't yet done any work in that area.
I just checked out the github API and they give very convenient access to any object of a repository via JSON. So it should be pretty straight forward to tap github. What is probably not as easy is a more general approach with Git only. The design of Git is such that it is expected of a user to clone a repository (or part of it) to read / manipulate data. One solution there might be (I'm not 100% sure) to clone "on the fly", i.e. only clone the data explicitly requested. The data would then of course accumulate locally and also I don't know how performance would hold up for such an approach. I'll defenitely try to come up with something to access github soon. It will probably not use OB though because that's just too much of a hack. Especially because it effectively disables the version browser for changes files. Any suggestions are of course appreciated. Cheers, Max On 15.03.2011, at 12:10, Adrian Lienhard wrote: > Wow, very cool! > > Just for others to realize what this is... > > Let's assume you want to see the change history of HTTPSocket class>>httpGetDocument:args:accept:request:. With blame you can see for each line who changed it and when: > > https://github.com/pharogenesis/pharogenesis/blame/pharo/HTTPSocket/class/get%20the%20page/httpGetDocument-3A-args-3A-accept-3A-request-3A-.cs > > Or you can see diffs between particular versions. E.g., httpFileIn: was changed in 2005 as follows: > > https://github.com/pharogenesis/pharogenesis/commit/d88d2b9c9fdb234c7d6b977e513561a8d45d1c04#HTTPSocket/class/get the page/httpFileIn-3A-.cs > > > Could the method versions dialog be extended to grab this data from GitHub? > > Cheers, > Adrian > > > On Mar 15, 2011, at 10:22 , Max Leske wrote: > >> I just pushed the (hopefully) final version of Pharogenesis to github (github.com/pharogenesis/pharogenesis). I appologize to the followers for deleting and recreating the repository but that's the only way to keep the history clean. >> >> Max > > |
> I'll defenitely try to come up with something to access github soon. It will probably not use OB though because that's just too much of a hack. Especially because it effectively disables the version browser for changes files.
You really don't need to hack OB: Why don't you just add a completely new command (the complete refactoring infrastructure was added that way and can be optionally loaded and unloaded) and let the Git history live aside of the traditional versioning functionality? Lukas -- Lukas Renggli www.lukas-renggli.ch |
can you add your project in
http://book.pharo-project.org/book/PharoTools/ ? On Tue, Mar 15, 2011 at 7:02 PM, Lukas Renggli <[hidden email]> wrote:
|
Sure, will do.
On 19.03.2011, at 14:32, Mariano Martinez Peck wrote: can you add your project in |
In reply to this post by Mariano Martinez Peck
I don't have an account for the book. Who should I turn to for this?
Max On 19.03.2011, at 14:32, Mariano Martinez Peck wrote: can you add your project in |
On Sat, Mar 19, 2011 at 3:10 PM, Max Leske <[hidden email]> wrote:
Me or any other of the admis. I have just created one for you and sent by private the data. Thanks Mariano
|
Thanks Mariano. Lukas, I just remembered why I chose to 'break' the OB versions button. The collecting of method versions happens in OBMethodNode>>versions. When a node is selected in a method list, that node is sent the message #versions. It's nearly impossible (as far as I can tell) to not touch anything because I would have to replace the model class of the method nodes (OBMethodNode) with a custom class. There are many references to OBMethodNode all over the place that would probably break unless I replaced them too. So, as I see it my 'ugly' approach is really a compromise to not spending 20 hours replacing OBMethodNode. Or did you have another idea? I'm not an OB guru... Cheers, Max On 19.03.2011, at 19:38, Mariano Martinez Peck wrote:
|
> Lukas, I just remembered why I chose to 'break' the OB versions button. The
> collecting of method versions happens in OBMethodNode>>versions. When a node > is selected in a method list, that node is sent the message #versions. It's > nearly impossible (as far as I can tell) to not touch anything because I > would have to replace the model class of the method nodes (OBMethodNode) > with a custom class. There are many references to OBMethodNode all over the > place that would probably break unless I replaced them too. > So, as I see it my 'ugly' approach is really a compromise to not spending 20 > hours replacing OBMethodNode. Yeah, create a new browser (probably a subclass of OBVersionBrowser) with a different meta-model (override the method OBVersionBrowser class>>defaultMetaNode) , that doesn't use the selector #versions to retrieve the versions but your own method that you add as an extension method to OBMethodNode. Lukas > Or did you have another idea? I'm not an OB guru... > Cheers, > Max > > On 19.03.2011, at 19:38, Mariano Martinez Peck wrote: > > > On Sat, Mar 19, 2011 at 3:10 PM, Max Leske <[hidden email]> wrote: >> >> I don't have an account for the book. Who should I turn to for this? > > Me or any other of the admis. I have just created one for you and sent by > private the data. > > Thanks > > Mariano > >> >> Max >> >> On 19.03.2011, at 14:32, Mariano Martinez Peck wrote: >> >> can you add your project in >> >> http://book.pharo-project.org/book/PharoTools/ >> >> ? >> >> On Tue, Mar 15, 2011 at 7:02 PM, Lukas Renggli <[hidden email]> wrote: >>> >>> > I'll defenitely try to come up with something to access github soon. It >>> > will probably not use OB though because that's just too much of a hack. >>> > Especially because it effectively disables the version browser for changes >>> > files. >>> >>> You really don't need to hack OB: Why don't you just add a completely >>> new command (the complete refactoring infrastructure was added that >>> way and can be optionally loaded and unloaded) and let the Git history >>> live aside of the traditional versioning functionality? >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> > > > -- Lukas Renggli www.lukas-renggli.ch |
Hey, wicked!
Only took me 30 minutes. Thanks for the input. This is *way* better than what I had before. It also means that Pharogenesis is actually already usable for development :) Max On 20.03.2011, at 12:19, Lukas Renggli wrote: >> Lukas, I just remembered why I chose to 'break' the OB versions button. The >> collecting of method versions happens in OBMethodNode>>versions. When a node >> is selected in a method list, that node is sent the message #versions. It's >> nearly impossible (as far as I can tell) to not touch anything because I >> would have to replace the model class of the method nodes (OBMethodNode) >> with a custom class. There are many references to OBMethodNode all over the >> place that would probably break unless I replaced them too. >> So, as I see it my 'ugly' approach is really a compromise to not spending 20 >> hours replacing OBMethodNode. > > Yeah, create a new browser (probably a subclass of OBVersionBrowser) > with a different meta-model (override the method OBVersionBrowser > class>>defaultMetaNode) , that doesn't use the selector #versions to > retrieve the versions but your own method that you add as an extension > method to OBMethodNode. > > Lukas > >> Or did you have another idea? I'm not an OB guru... >> Cheers, >> Max >> >> On 19.03.2011, at 19:38, Mariano Martinez Peck wrote: >> >> >> On Sat, Mar 19, 2011 at 3:10 PM, Max Leske <[hidden email]> wrote: >>> >>> I don't have an account for the book. Who should I turn to for this? >> >> Me or any other of the admis. I have just created one for you and sent by >> private the data. >> >> Thanks >> >> Mariano >> >>> >>> Max >>> >>> On 19.03.2011, at 14:32, Mariano Martinez Peck wrote: >>> >>> can you add your project in >>> >>> http://book.pharo-project.org/book/PharoTools/ >>> >>> ? >>> >>> On Tue, Mar 15, 2011 at 7:02 PM, Lukas Renggli <[hidden email]> wrote: >>>> >>>>> I'll defenitely try to come up with something to access github soon. It >>>>> will probably not use OB though because that's just too much of a hack. >>>>> Especially because it effectively disables the version browser for changes >>>>> files. >>>> >>>> You really don't need to hack OB: Why don't you just add a completely >>>> new command (the complete refactoring infrastructure was added that >>>> way and can be optionally loaded and unloaded) and let the Git history >>>> live aside of the traditional versioning functionality? >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>> >>> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > |
Free forum by Nabble | Edit this page |