Hi everyone. This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector. Uko
We cannot do that because they are based on two radically different technologies. Doru On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com "Every thing has its own flow"
Yes, I know. And this is sad :( On 07 Mar 2014, at 18:45, Tudor Girba <tudor@tudorgirba.com> wrote:
We cannot do that because they are based on two radically different technologies.
Doru
On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Hi everyone.
This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
Why do you say that? You get two different solutions. GTInspector is around since almost four years and it was brewed in the more research-oriented Moose environment. At the moment, the Pharo solution adopted just the multiple presentations part. I agree that it is not at all as powerful as GTInspector (both implementation and conceptual wise), but it's already better than it exists in other environments. In the meantime, GTInspector will grow more to show what else is possible, and hopefully, the community will finally look at it and see that it offers a completely new way of developing :). Doru On Fri, Mar 7, 2014 at 8:39 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Yes, I know. And this is sad :(
On 07 Mar 2014, at 18:45, Tudor Girba <tudor@tudorgirba.com> wrote:
We cannot do that because they are based on two radically different technologies.
Doru
On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com>wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
I would like to have some idea, that object can provide a way to inspect itself (similar like every object should define how to print itself). And then all the browsers could use it. Because now Iâm developing something and Iâm implementing special inspections for my objects. Would be nice to give other people a possibility to also inspect my objects in a special way. On 07 Mar 2014, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Why do you say that?
You get two different solutions. GTInspector is around since almost four years and it was brewed in the more research-oriented Moose environment. At the moment, the Pharo solution adopted just the multiple presentations part. I agree that it is not at all as powerful as GTInspector (both implementation and conceptual wise), but it's already better than it exists in other environments.
In the meantime, GTInspector will grow more to show what else is possible, and hopefully, the community will finally look at it and see that it offers a completely new way of developing :).
Doru
On Fri, Mar 7, 2014 at 8:39 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Yes, I know. And this is sad :(
On 07 Mar 2014, at 18:45, Tudor Girba <tudor@tudorgirba.com> wrote:
We cannot do that because they are based on two radically different technologies.
Doru
On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Hi everyone.
This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
That is precisely what GT offers you. Just use that. Doru On Fri, Mar 7, 2014 at 9:31 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
I would like to have some idea, that object can provide a way to inspect itself (similar like every object should define how to print itself). And then all the browsers could use it. Because now I'm developing something and I'm implementing special inspections for my objects. Would be nice to give other people a possibility to also inspect my objects in a special way.
On 07 Mar 2014, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Why do you say that?
You get two different solutions. GTInspector is around since almost four years and it was brewed in the more research-oriented Moose environment. At the moment, the Pharo solution adopted just the multiple presentations part. I agree that it is not at all as powerful as GTInspector (both implementation and conceptual wise), but it's already better than it exists in other environments.
In the meantime, GTInspector will grow more to show what else is possible, and hopefully, the community will finally look at it and see that it offers a completely new way of developing :).
Doru
On Fri, Mar 7, 2014 at 8:39 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com>wrote:
Yes, I know. And this is sad :(
On 07 Mar 2014, at 18:45, Tudor Girba <tudor@tudorgirba.com> wrote:
We cannot do that because they are based on two radically different technologies.
Doru
On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com>wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use. On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
I hope not. What are we trying to optimize? If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole. One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that. Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction). We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential. There is still a long way for the concept of inspector and I believe there is a large payoff in it, too. Optimizing for a small thing now should not be the way to go :) Cheers, Doru On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com "Every thing has its own flow"
Doru, Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... example. A video? I look at the blog and vids but it is a bit hard to find a basic demo to grasp things. TIA Phil On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
Thanks for the interest. I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w... The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation Please let me know what you think. Cheers, Doru On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Wow!!!!! Screenshots are (too) small? Hey people! Use the like button and enter a comment :-) We should be able to do the same thing for DBPedia. Alexandre On Mar 9, 2014, at 7:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the interest.
I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w...
The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation
Please let me know what you think.
Cheers, Doru
On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be> wrote: Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... for example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com> wrote: I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex, On Mon, Mar 10, 2014 at 1:26 AM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
Wow!!!!!
Screenshots are (too) small?
They are actually in full resolution, but the theme makes them fit the column, and the blog engine does not offer an enlarge preview :(. You can however, simply zoom the page. Hey people! Use the like button and enter a comment :-)
We should be able to do the same thing for DBPedia.
Exactly. I would love to get some case studies in this direction. The idea of the case study would be not to present the end picture (if it's a visualization) but the way to get to it. For example, in the Postgres video, the final picture is not particularly exciting, but the speed with which you can get to it once you know the platform is :). Cheers, Doru Alexandre
On Mar 9, 2014, at 7:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the interest.
I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector:
http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w...
The post includes a video that kind of gets you through the most
important parts:
- use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation
Please let me know what you think.
Cheers, Doru
On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be> wrote: Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com> wrote: I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "Every thing has its own flow"
Yes! Yesterday evening I watched the Wolfram video. I think we can produce Pharo-based video as impressive as what this strange guy did. Alexandre On Mar 10, 2014, at 2:34 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Alex,
On Mon, Mar 10, 2014 at 1:26 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Wow!!!!!
Screenshots are (too) small?
They are actually in full resolution, but the theme makes them fit the column, and the blog engine does not offer an enlarge preview :(. You can however, simply zoom the page.
Hey people! Use the like button and enter a comment :-)
We should be able to do the same thing for DBPedia.
Exactly. I would love to get some case studies in this direction. The idea of the case study would be not to present the end picture (if it's a visualization) but the way to get to it. For example, in the Postgres video, the final picture is not particularly exciting, but the speed with which you can get to it once you know the platform is :).
Cheers, Doru
Alexandre
On Mar 9, 2014, at 7:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the interest.
I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w...
The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation
Please let me know what you think.
Cheers, Doru
On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be> wrote: Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... for example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com> wrote: I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Yes! We have Roassal 2 which is pretty well advanced already. We would like to announce Roassal2 the way its deserve: with fireworks and a big fanfare. The coming months will be full of surprises. Alexandre On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Alex,
On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yesterday evening I watched the Wolfram video. I think we can produce Pharo-based video as impressive as what this strange guy did.
Please do ! Visualization and marketing is important indeed.
Sven
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Excellent Tudor! Very impressive. It blurs the line between a the Smalltalk tools and an SQL Editor. Esteban A. Maringolo 2014-03-10 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Yes!
We have Roassal 2 which is pretty well advanced already. We would like to announce Roassal2 the way its deserve: with fireworks and a big fanfare.
The coming months will be full of surprises.
Alexandre
On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Alex,
On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yesterday evening I watched the Wolfram video. I think we can produce Pharo-based video as impressive as what this strange guy did.
Please do ! Visualization and marketing is important indeed.
Sven
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thank you. In this case yes, it blurs the line between an SQL Editor and the inspector. And between a table and an Excel code editor. But, here is another blurred line between the file browser and the inspector: http://www.humane-assessment.com/blog/browsing-files-with-gtinspector-video/ The GTInspector blurs all sorts of lines and it even empowers you to blur your own lines :). Just a note: the GToolkit is also the work of Andrei. Doru On Mon, Mar 10, 2014 at 8:01 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Excellent Tudor!
Very impressive. It blurs the line between a the Smalltalk tools and an SQL Editor. Esteban A. Maringolo
2014-03-10 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Yes!
We have Roassal 2 which is pretty well advanced already. We would like to announce Roassal2 the way its deserve: with fireworks and a big fanfare.
The coming months will be full of surprises.
Alexandre
On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Alex,
On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yesterday evening I watched the Wolfram video. I think we can produce Pharo-based video as impressive as what this strange guy did.
Please do ! Visualization and marketing is important indeed.
Sven
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "Every thing has its own flow"
Doru, for the DBXTalk inspector, maybe it is useful for you this package: http://www.smalltalkhub.com/#!/~DBXTalk/DBXDatabaseModel/ That allows to retrieve database schema metadata in a polymorphic way :) On Tue, Mar 11, 2014 at 7:43 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you.
In this case yes, it blurs the line between an SQL Editor and the inspector. And between a table and an Excel code editor. But, here is another blurred line between the file browser and the inspector:
http://www.humane-assessment.com/blog/browsing-files-with-gtinspector-video/
The GTInspector blurs all sorts of lines and it even empowers you to blur your own lines :).
Just a note: the GToolkit is also the work of Andrei.
Doru
On Mon, Mar 10, 2014 at 8:01 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
Excellent Tudor!
Very impressive. It blurs the line between a the Smalltalk tools and an SQL Editor. Esteban A. Maringolo
2014-03-10 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Yes!
We have Roassal 2 which is pretty well advanced already. We would like to announce Roassal2 the way its deserve: with fireworks and a big fanfare.
The coming months will be full of surprises.
Alexandre
On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Alex,
On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yesterday evening I watched the Wolfram video. I think we can produce Pharo-based video as impressive as what this strange guy did.
Please do ! Visualization and marketing is important indeed.
Sven
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"Every thing has its own flow"
Thanks. I was looking for something like that! I will check it and get back to you. Doru On Tue, Mar 11, 2014 at 10:42 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Doru, for the DBXTalk inspector, maybe it is useful for you this package:
http://www.smalltalkhub.com/#!/~DBXTalk/DBXDatabaseModel/
That allows to retrieve database schema metadata in a polymorphic way :)
On Tue, Mar 11, 2014 at 7:43 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you.
In this case yes, it blurs the line between an SQL Editor and the inspector. And between a table and an Excel code editor. But, here is another blurred line between the file browser and the inspector:
http://www.humane-assessment.com/blog/browsing-files-with-gtinspector-video/
The GTInspector blurs all sorts of lines and it even empowers you to blur your own lines :).
Just a note: the GToolkit is also the work of Andrei.
Doru
On Mon, Mar 10, 2014 at 8:01 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
Excellent Tudor!
Very impressive. It blurs the line between a the Smalltalk tools and an SQL Editor. Esteban A. Maringolo
2014-03-10 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Yes!
We have Roassal 2 which is pretty well advanced already. We would like to announce Roassal2 the way its deserve: with fireworks and a big fanfare.
The coming months will be full of surprises.
Alexandre
On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Alex,
On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yesterday evening I watched the Wolfram video. I think we can produce Pharo-based video as impressive as what this strange guy did.
Please do ! Visualization and marketing is important indeed.
Sven
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On 10 Mar 2014, at 16:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yes!
We have Roassal 2 which is pretty well advanced already. We would like to announce Roassal2 the way its deserve: with fireworks and a big fanfare.
The coming months will be full of surprises.
I want to be like a kid :)
Tudor Thanks for amazing work, just report a trouble , i follow the http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w... Instructions and trying with one postgres database, one table with date fields fire problem's SqNumberParser class is missing in moose image, and the postgres use this to read dates or timestamps fields . best regards jmdc On Sun, Mar 9, 2014 at 7:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the interest.
I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector:
http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w...
The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation
Please let me know what you think.
Cheers, Doru
On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Tudor what steps I need to follow to load the file-exploration example of video ? any ConfigurationOfxx . package, monticello repository etc... best jmdc On Tue, Mar 11, 2014 at 2:11 PM, Juan <smalltalker.marcelo@gmail.com> wrote:
Tudor
Thanks for amazing work, just report a trouble , i follow the http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w... Instructions and trying with one postgres database, one table with date fields fire problem's SqNumberParser class is missing in moose image, and the postgres use this to read dates or timestamps fields .
best regards jmdc
On Sun, Mar 9, 2014 at 7:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the interest.
I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector:
http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w...
The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation
Please let me know what you think.
Cheers, Doru
On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com>wrote:
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Hi Juan, Just download the latest Moose image and you can explore the file system. Cheers, Doru On Tue, Mar 11, 2014 at 6:17 PM, Juan <smalltalker.marcelo@gmail.com> wrote:
Tudor
what steps I need to follow to load the file-exploration example of video ? any ConfigurationOfxx . package, monticello repository etc...
best
jmdc
On Tue, Mar 11, 2014 at 2:11 PM, Juan <smalltalker.marcelo@gmail.com>wrote:
Tudor
Thanks for amazing work, just report a trouble , i follow the http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w... Instructions and trying with one postgres database, one table with date fields fire problem's SqNumberParser class is missing in moose image, and the postgres use this to read dates or timestamps fields .
best regards jmdc
On Sun, Mar 9, 2014 at 7:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the interest.
I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector:
http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-w...
The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation
Please let me know what you think.
Cheers, Doru
On Sat, Mar 8, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Doru,
Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open... example. A video?
I look at the blog and vids but it is a bit hard to find a basic demo to grasp things.
TIA Phil
On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor@tudorgirba.com>wrote:
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Indeed having particular views is only one (minor) aspect. The coding and navigation flow GTTools offers is fantastic. I am not a big fan of Glamour scripting language, but what is built on top of it is remarkable. It may even be a killing app for Pharo. Alexandre
Le 08-03-2014 à 4:16, Tudor Girba <tudor@tudorgirba.com> a écrit :
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
Thanks, Alex. I showed the above demo to non-Smalltalk developers with the idea of positioning Pharo/Moose as a one-stop-tool-for-all-sorts-of-analyses (I also showed them file manipulation). By the look in their eyes (they know the real pain of having poor and incomplete tools), I am pretty convinced that this is a significant opportunity that Pharo should take. Doru On Sat, Mar 8, 2014 at 1:13 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
Indeed having particular views is only one (minor) aspect. The coding and navigation flow GTTools offers is fantastic. I am not a big fan of Glamour scripting language, but what is built on top of it is remarkable. It may even be a killing app for Pharo.
Alexandre
Le 08-03-2014 à 4:16, Tudor Girba <tudor@tudorgirba.com> a écrit :
I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers, Doru
On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use.
On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
This day I've attended Moose dojo and I'm pretty impressed with the possibilities of GTInspector. The one thing that I've noticed is that both GTInspactor and EyeInspector support custom inspections for objects. I'm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector.
Uko
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
participants (8)
-
Alexandre Bergel -
Esteban A. Maringolo -
Guillermo Polito -
Juan -
Pharo4Stef -
phil＠highoctane.be -
Sven Van Caekenberghe -
Tudor Girba -
Yuriy Tymchuk