why gt is here to stay

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

why gt is here to stay

Tudor Girba-2
Hi,

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

stepharo
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

Uko2
I think that Doru said that we can have our tools:

EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.



On 26 Jun 2014, at 16:54, stepharo <[hidden email]> wrote:

So you mean that we cannot have our old tools?

Ok now I know what I have to do. 

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

-- 

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

Tudor Girba-2
In reply to this post by stepharo
I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

DiegoLont
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

stepharo
It depends if Moose is an infrastructure to build tools or an ide to do analyses.

For the second one I can understand that GT is part of the "Moose" now we when we sell tools to clients
GT is simply out!

So we will maintain a Moose infrastructure configuration because this is too important for us.

Stef


On 27/6/14 14:56, Diego Lont wrote:
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

Tudor Girba-2
Hi Stef,

Certainly. If you want to ship ready-made tools that hide the Pharo environment, then the whole Pharo IDE is out.

Cheers,
Doru


On Fri, Jun 27, 2014 at 11:13 PM, stepharo <[hidden email]> wrote:
It depends if Moose is an infrastructure to build tools or an ide to do analyses.

For the second one I can understand that GT is part of the "Moose" now we when we sell tools to clients
GT is simply out!

So we will maintain a Moose infrastructure configuration because this is too important for us.

Stef



On 27/6/14 14:56, Diego Lont wrote:
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

stepharo

On 28/6/14 08:19, Tudor Girba wrote:
Hi Stef,

Certainly. If you want to ship ready-made tools that hide the Pharo environment, then the whole Pharo IDE is out.
This is why I think that we should have

    MooseInfrastructure
    MooseIDE


Cheers,
Doru


On Fri, Jun 27, 2014 at 11:13 PM, stepharo <[hidden email]> wrote:
It depends if Moose is an infrastructure to build tools or an ide to do analyses.

For the second one I can understand that GT is part of the "Moose" now we when we sell tools to clients
GT is simply out!

So we will maintain a Moose infrastructure configuration because this is too important for us.

Stef



On 27/6/14 14:56, Diego Lont wrote:
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

Tudor Girba-2
We have half of it :).

The MooseIDE is called GToolkit.

For the core part, we have only a group:

spec
group: 'Core' with: #(
'Moose-Core'
'Famix-Core'
'Famix-Implementation'
'Famix-Smalltalk'
'Famix-Java'
'Famix-Extensions'
'Famix-File'
'Moose-Hismo'
'Famix-SourceAnchor'
'Moose-GenericImporter'
'Moose-SmalltalkImporter'
'Moose-MonticelloImporter'
'Roassal'
'MooseAlgos'
'Glamour'
'DSM'
'Merlin'
'Fame'
'Metanool');

This is certainly not ideal at all. We should have explicit configurations for the relevantly grouped subparts.

Doru


On Sat, Jun 28, 2014 at 9:25 AM, stepharo <[hidden email]> wrote:

On 28/6/14 08:19, Tudor Girba wrote:
Hi Stef,

Certainly. If you want to ship ready-made tools that hide the Pharo environment, then the whole Pharo IDE is out.
This is why I think that we should have

    MooseInfrastructure
    MooseIDE



Cheers,
Doru


On Fri, Jun 27, 2014 at 11:13 PM, stepharo <[hidden email]> wrote:
It depends if Moose is an infrastructure to build tools or an ide to do analyses.

For the second one I can understand that GT is part of the "Moose" now we when we sell tools to clients
GT is simply out!

So we will maintain a Moose infrastructure configuration because this is too important for us.

Stef



On 27/6/14 14:56, Diego Lont wrote:
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

Ben Coman
Tudor Girba wrote:
> We have half of it :).
>
> The MooseIDE is called GToolkit.
>

As an aside, I think "MooseIDE" has a nice feel to it.

"GToolkit" has never really grabbed me.   Is it an end user interface?  
The term "Toolkit" doesn't sound like it.  And what does the "G" stand for?

Would "MooseBase" be more conventional than "MooseInfrastructure"?  
Hmmm... makes me think of "MoonBase" for no good reason.

cheers -ben
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

Tudor Girba-2
Hi,


On Sun, Jun 29, 2014 at 6:51 AM, Ben Coman <[hidden email]> wrote:
Tudor Girba wrote:
We have half of it :).

The MooseIDE is called GToolkit.


As an aside, I think "MooseIDE" has a nice feel to it.
"GToolkit" has never really grabbed me.   Is it an end user interface?  The term "Toolkit" doesn't sound like it.  And what does the "G" stand for?

The full name was Glamorous Toolkit :). But, you can think of Great Toolkit as well :). The main reason for G is that it is based on Glamour.
 
Would "MooseBase" be more conventional than "MooseInfrastructure"?  Hmmm... makes me think of "MoonBase" for no good reason.

MooseInfrastructure is not a good name. We should use MooseEngines.

Doru

 
cheers -ben

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

stepharo
In reply to this post by Tudor Girba-2
Hi doru

I tried to build a first cut at Engines and Others but I need to think about them because I want to understand
how we handle this antagonist needs
    we need to express dependencies like if this package is not loaded I will not work
    we need to express groups of things potentially working together.

There is a parallel with XMLSupport (a group loading XMLparser, writer, SIXX, Pastell....
and XMLParser, XMLWriter

So may be we should have
    PetitParserProject = XMLSupport
        - PetitParser
        - PetitParserUI -> Glamour

    PetitParser

What do you think?






On 29/6/14 00:10, Tudor Girba wrote:
We have half of it :).

The MooseIDE is called GToolkit.

For the core part, we have only a group:

spec
group: 'Core' with: #(
'Moose-Core'
'Famix-Core'
'Famix-Implementation'
'Famix-Smalltalk'
'Famix-Java'
'Famix-Extensions'
'Famix-File'
'Moose-Hismo'
'Famix-SourceAnchor'
'Moose-GenericImporter'
'Moose-SmalltalkImporter'
'Moose-MonticelloImporter'
'Roassal'
'MooseAlgos'
'Glamour'
'DSM'
'Merlin'
'Fame'
'Metanool');

This is certainly not ideal at all. We should have explicit configurations for the relevantly grouped subparts.

Doru


On Sat, Jun 28, 2014 at 9:25 AM, stepharo <[hidden email]> wrote:

On 28/6/14 08:19, Tudor Girba wrote:
Hi Stef,

Certainly. If you want to ship ready-made tools that hide the Pharo environment, then the whole Pharo IDE is out.
This is why I think that we should have

    MooseInfrastructure
    MooseIDE



Cheers,
Doru


On Fri, Jun 27, 2014 at 11:13 PM, stepharo <[hidden email]> wrote:
It depends if Moose is an infrastructure to build tools or an ide to do analyses.

For the second one I can understand that GT is part of the "Moose" now we when we sell tools to clients
GT is simply out!

So we will maintain a Moose infrastructure configuration because this is too important for us.

Stef



On 27/6/14 14:56, Diego Lont wrote:
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

stepharo
In reply to this post by Ben Coman

> As an aside, I think "MooseIDE" has a nice feel to it.

Yes like that it is clear what it is.

> "GToolkit" has never really grabbed me.   Is it an end user
> interface?  The term "Toolkit" doesn't sound like it.  And what does
> the "G" stand for?
>
> Would "MooseBase" be more conventional than "MooseInfrastructure"?  
> Hmmm... makes me think of "MoonBase" for no good reason.

Cosmos 99 strikes back.
For me this the way you want.


> cheers -ben
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: why gt is here to stay

stepharo
In reply to this post by stepharo
I created another thread. Do not reply to this one.

On 30/6/14 10:19, stepharo wrote:
Hi doru

I tried to build a first cut at Engines and Others but I need to think about them because I want to understand
how we handle this antagonist needs
    we need to express dependencies like if this package is not loaded I will not work
    we need to express groups of things potentially working together.

There is a parallel with XMLSupport (a group loading XMLparser, writer, SIXX, Pastell....
and XMLParser, XMLWriter

So may be we should have
    PetitParserProject = XMLSupport
        - PetitParser
        - PetitParserUI -> Glamour

    PetitParser

What do you think?






On 29/6/14 00:10, Tudor Girba wrote:
We have half of it :).

The MooseIDE is called GToolkit.

For the core part, we have only a group:

spec
group: 'Core' with: #(
'Moose-Core'
'Famix-Core'
'Famix-Implementation'
'Famix-Smalltalk'
'Famix-Java'
'Famix-Extensions'
'Famix-File'
'Moose-Hismo'
'Famix-SourceAnchor'
'Moose-GenericImporter'
'Moose-SmalltalkImporter'
'Moose-MonticelloImporter'
'Roassal'
'MooseAlgos'
'Glamour'
'DSM'
'Merlin'
'Fame'
'Metanool');

This is certainly not ideal at all. We should have explicit configurations for the relevantly grouped subparts.

Doru


On Sat, Jun 28, 2014 at 9:25 AM, stepharo <[hidden email]> wrote:

On 28/6/14 08:19, Tudor Girba wrote:
Hi Stef,

Certainly. If you want to ship ready-made tools that hide the Pharo environment, then the whole Pharo IDE is out.
This is why I think that we should have

    MooseInfrastructure
    MooseIDE



Cheers,
Doru


On Fri, Jun 27, 2014 at 11:13 PM, stepharo <[hidden email]> wrote:
It depends if Moose is an infrastructure to build tools or an ide to do analyses.

For the second one I can understand that GT is part of the "Moose" now we when we sell tools to clients
GT is simply out!

So we will maintain a Moose infrastructure configuration because this is too important for us.

Stef



On 27/6/14 14:56, Diego Lont wrote:
Hi all,

Just some pro’s and con’s of the GT Toolkit from a commercial point of view:
Pro:
The toolkit is way ahead of the other tools.
The toolkit is well maintained. Bugs are fixed pretty quick, once located.
The tools can be expanded quite easily. This is a key advantage, and now causes more people to work on the tools. And we need more people working on the development environment ...

Con:
GTDebugger has been unstable (had unstable features) a few time the last couple of months. One can notice there is development going on here.
The tools, especially the debugger, needs a bit getting used to.

To be honest, this is not much different from Pharo itself. One can notice there is development going on, and from time to time something critical breaks. Since the debugger, inspector and system browser are such a key tools, one probably notices this a bit faster when it concerns one of these tools.

But I consider that development is going on in those key areas a good thing. I must admit that I reverted to pharo for the moment, but I plan on going back once the moose tools are a bit more stable again.

So yes, I agree with Doru that these tools should be a default part of moose. This is the only way to get enough users for these tools. And I do not want to get stuck with the old things, that maybe work reliable, but do not improve any more.

Diego

On 26 Jun 2014, at 16:58, Tudor Girba <[hidden email]> wrote:

I am not convinced you read the whole mail :). So, just to make sure, here is the snippet for you again (which is how things are done in plain Pharo code - no Moose magic involved):
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

Doru




On Thu, Jun 26, 2014 at 4:54 PM, stepharo <[hidden email]> wrote:
So you mean that we cannot have our old tools?

Ok now I know what I have to do.

Stef

At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)

The Coder will likely follow but first in a different format than one expects. Namely, it will appear first as a code editor inside the inspector.

GT is neither a whim, nor is it experimental. GT is a long term project. For example, the inspector was incubated for more than 4 years, and it is time to work with it and evolve it based on real-life experience. It is true that sometimes it is still moving but that is because it is alive :). Yet, the functionality is there, and if there are issues they should be treated as such: report them and they will be fixed.

Now, the main reason why GT is not optional for the main Moose distribution is that, as I explained one year ago at the MooseDay, Moose will provide the IDE. First, we need a new IDE in Pharo and I think we have cool set of concepts and the Moose engines are perfect for it. Second, when analyzing data from XML structures, plain files, DB, or even Pharo objects, the Inspector is cornerstone. And so is the Playground. As for the Debugger, I will remind you that it comes with working dedicated debuggers for PetitParser, Glamour, and Announcements. These alone make it worth the effort when developing Moose-based solutions.

Not to mention that we are building something that is ridiculously small for the power it harnesses. We should not stop this because we find a couple of bugs along the way.

For all these reasons, GT is here to stay.

Cheers,
Doru

p.s. Btw, the development of GT is not reserved to a closed circle. We would like to invite anyone interested in participating in the development of GT.

p.p.s. Of course, because this system is properly engineered, it can be safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.

--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev