[Pharo-project] Pharogenesis anew
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/ge... Or you can see diffs between particular versions. E.g., httpFileIn: was changed in 2005 as follows: https://github.com/pharogenesis/pharogenesis/commit/d88d2b9c9fdb234c7d6b977e... 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/ge...
Or you can see diffs between particular versions. E.g., httpFileIn: was changed in 2005 as follows:
https://github.com/pharogenesis/pharogenesis/commit/d88d2b9c9fdb234c7d6b977e... 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 <renggli@gmail.com> 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
Sure, will do. 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 <renggli@gmail.com> 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
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
http://book.pharo-project.org/book/PharoTools/
?
On Tue, Mar 15, 2011 at 7:02 PM, Lukas Renggli <renggli@gmail.com> 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
On Sat, Mar 19, 2011 at 3:10 PM, Max Leske <maxleske@gmail.com> 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 <renggli@gmail.com> 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
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:
On Sat, Mar 19, 2011 at 3:10 PM, Max Leske <maxleske@gmail.com> 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 <renggli@gmail.com> 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, 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 <maxleske@gmail.com> 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 <renggli@gmail.com> 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 <maxleske@gmail.com> 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 <renggli@gmail.com> 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
participants (4)
-
Adrian Lienhard -
Lukas Renggli -
Mariano Martinez Peck -
Max Leske