Yesterday I had a look at AppeX (from Cincom in VW) and gave a test drive to Tide in Pharo/Amber. AppeX is interesting as it allows one to embed javascript code directly in methods. Like: myMethod: x { // this is javascript here. alert('Welcome ' + x); } This indeed reduces the friction between Smalltalk and Javascript (which we still need to write somewhere, for example with JSStream / JSFunction in Seaside or elsewhere). Since we do now have OpalCompiler and compiler override possibilities, how hard would it be to look into this? I remember Helvetia from Lukas which looked like something similar. Phil
Hi Phil, if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term. Regarding integration of different resources ============================================ 1. we need a better text editor and not only doing Smalltalk completion/styling but have this pluggable as well => if I'm not mistaken this is what TxText project partly is caring about If I remember correctly in VW there were browser plugins to the browsers code pane allowing you for instance to directly edit XML as a tree and styling while the XML text it is stored in a method, etc. Similar to Eclipse where depending on the content type one or more different pluggable editors could be used. 2. it should be possible to store and save different code/text formats as source for methods => you can already do it similar to Seaside by just returning Strings => maybe a pragma could be used foo <language: #JavaScript> ^'alert("hi");' => the selector could/should be decoupled from the method body to be more flexible, not only in editing (interesting idea and already in Moose, see Tudors talk from ESUG 2014 https://www.youtube.com/watch?v=LKVPJU3W5Ys&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl...) especially at the beginning of video 3/3. 3. we should think about where the source code (Smalltalk or not) is stored, it should be more flexible as well => there already was a discussion of integrating the source file into the image Pharo4.0 but I would additionally also like to integrate the other way around (why not edit an external file (CSS, JavaScript, XML, ...) linked as a method in the system with the internal Smalltalk tools) So one could imagine a method like this where the string is stored in an external file. zincMustacheTemplate <language: 'HTML' external: 'index.html'> ^'<html><body><head><title>{{AppTitle}}</title></head></body>' Many other ideas come to mind. Regarding the integration of multiple languages: ================================================ As we all know we have our image and VM provides a dynamic object system and Smalltalk is only a language that is built into it. So can be others and we would open up more. There are many examples of this already in the Smalltalk world: - VisualAge for Java was implemented and running inside of VisualAge for Smalltalk using all the tools - running Java inside of Smalltalk/X - C Source code of the VM can edited and changed in Smalltalk/X tools - JavaScript on top of VW as seen on ESUG 2014, https://www.youtube.com/watch?v=ZGAMCz62OM0 - Helvetia (http://scg.unibe.ch/research/helvetia) Helvetia could be a starting point for Pharo here, also parser frameworks like PetitParser, ... Many things are already possible from the meta side. Maybe one could port the MIT licensed JavaScript implementation from VW to Pharo and try out if our infrastructure (Compiler, Parser, source code editing) could really be made pluggable. Would open up Pharo also to JavaScript developers and maybe realign better with Amber. So many things we could do to reduce the friction between Smalltalk and the outside world ... but lots of work if done right. Bye T.
1. We have some of the pieces for that coming together. We have a large array of programming language parsers with PetitParser and SmaCC (Java, C#, Python, JavaScript?, R?) (some of them proprietary, however: C, ADA) and they can be used for styling (thanks Usman for showing me how) and probably completion. This could probably fit in the current text editor just about fine, but a better one wouldn't hurt. That the current text morphs sees everything as smalltalk source code isn't hard to correct :) 2. and 3. Same. Once you abstract a bit some of the IDE building blocks, you can store code anywhere you want: even at the Pharo IDE level, a code pane is just a text editor with a specific way of saving code, which could be changed in a snap. However, I wouldn't be too much into emulating a language: it may be a very heavy and complex endeavour. Running behind a Pharo based IDE the interpreter or the compiler of a language X (R, Python) looks to me a more reasonable proposition. I'm currently looking at leveraging some of the IDE stuff I have and the SmaCC infrastructure to be able to build experimental IDEs for non-Smalltalk languages and external DSLs. Write or get a SmaCC parser for a language and you would have an IDE core building blocks ready for reuse and customization. Thierry 2014-09-04 14:18 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
Regarding integration of different resources ============================================ 1. we need a better text editor and not only doing Smalltalk completion/styling but have this pluggable as well => if I'm not mistaken this is what TxText project partly is caring about
If I remember correctly in VW there were browser plugins to the browsers code pane allowing you for instance to directly edit XML as a tree and styling while the XML text it is stored in a method, etc.
Similar to Eclipse where depending on the content type one or more different pluggable editors could be used.
2. it should be possible to store and save different code/text formats as source for methods => you can already do it similar to Seaside by just returning Strings => maybe a pragma could be used foo <language: #JavaScript> ^'alert("hi");' => the selector could/should be decoupled from the method body to be more flexible, not only in editing (interesting idea and already in Moose, see Tudors talk from ESUG 2014
https://www.youtube.com/watch?v=LKVPJU3W5Ys&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl... ) especially at the beginning of video 3/3.
3. we should think about where the source code (Smalltalk or not) is stored, it should be more flexible as well
=> there already was a discussion of integrating the source file into the image Pharo4.0 but I would additionally also like to integrate the other way around (why not edit an external file (CSS, JavaScript, XML, ...) linked as a method in the system with the internal Smalltalk tools) So one could imagine a method like this where the string is stored in an external file.
zincMustacheTemplate <language: 'HTML' external: 'index.html'>
^'<html><body><head><title>{{AppTitle}}</title></head></body>'
Many other ideas come to mind.
Regarding the integration of multiple languages: ================================================ As we all know we have our image and VM provides a dynamic object system and Smalltalk is only a language that is built into it. So can be others and we would open up more.
There are many examples of this already in the Smalltalk world: - VisualAge for Java was implemented and running inside of VisualAge for Smalltalk using all the tools - running Java inside of Smalltalk/X - C Source code of the VM can edited and changed in Smalltalk/X tools - JavaScript on top of VW as seen on ESUG 2014, https://www.youtube.com/watch?v=ZGAMCz62OM0 - Helvetia (http://scg.unibe.ch/research/helvetia)
Helvetia could be a starting point for Pharo here, also parser frameworks like PetitParser, ... Many things are already possible from the meta side.
Maybe one could port the MIT licensed JavaScript implementation from VW to Pharo and try out if our infrastructure (Compiler, Parser, source code editing) could really be made pluggable. Would open up Pharo also to JavaScript developers and maybe realign better with Amber.
So many things we could do to reduce the friction between Smalltalk and the outside world ... but lots of work if done right.
Bye T.
Hi Torsten, Phil, On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
Maybe we can start small. I've current needs that could well be handled in the environment. The FileBrowser is in my view quite not used enough. When doing web applications, I deal with Javascript, CSS, content files etc all the time. The FileBrowser allows to edit files in its content pane. Doing an Accept (Alt-S) on the pane saves the file. So, instead of starting an external edit session in Vim, I mostly work there for some smaller changes (like tweaking CSS). Now, if we could have a syntax highlighter in there it would be nice. For CSS it wouldn't be too damn hard I think. Phil On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi Torsten, Phil,
On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
2014-09-05 16:03 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Maybe we can start small.
I've current needs that could well be handled in the environment.
The FileBrowser is in my view quite not used enough.
When doing web applications, I deal with Javascript, CSS, content files etc all the time.
The FileBrowser allows to edit files in its content pane. Doing an Accept (Alt-S) on the pane saves the file.
So, instead of starting an external edit session in Vim, I mostly work there for some smaller changes (like tweaking CSS).
Now, if we could have a syntax highlighter in there it would be nice.
Yes. Anybody knows what is the API for adding / changing the styler on a text morph? I'll have a use for a SmaCC grammar styler as well. Anybody has a CSS parser around? Thierry
For CSS it wouldn't be too damn hard I think.
Phil
On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi Torsten, Phil,
On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
Hi, As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser. You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load. Cheers, Doru On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-05 16:03 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Maybe we can start small.
I've current needs that could well be handled in the environment.
The FileBrowser is in my view quite not used enough.
When doing web applications, I deal with Javascript, CSS, content files etc all the time.
The FileBrowser allows to edit files in its content pane. Doing an Accept (Alt-S) on the pane saves the file.
So, instead of starting an external edit session in Vim, I mostly work there for some smaller changes (like tweaking CSS).
Now, if we could have a syntax highlighter in there it would be nice.
Yes. Anybody knows what is the API for adding / changing the styler on a text morph? I'll have a use for a SmaCC grammar styler as well.
Anybody has a CSS parser around?
Thierry
For CSS it wouldn't be too damn hard I think.
Phil
On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi Torsten, Phil,
On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
-- www.tudorgirba.com "Every thing has its own flow"
Thanks for that, I'll look into it. Rubric looks definitely nicer that the old thing. It opens a lot of doors and may allow me to do the little I wanted to do when I started using Pharo. Hey, patience pays off :-) Glamour indeed is a powerful tool to craft content explorers. Phil On Mon, Sep 15, 2014 at 6:44 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load.
Cheers, Doru
On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
2014-09-05 16:03 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Maybe we can start small.
I've current needs that could well be handled in the environment.
The FileBrowser is in my view quite not used enough.
When doing web applications, I deal with Javascript, CSS, content files etc all the time.
The FileBrowser allows to edit files in its content pane. Doing an Accept (Alt-S) on the pane saves the file.
So, instead of starting an external edit session in Vim, I mostly work there for some smaller changes (like tweaking CSS).
Now, if we could have a syntax highlighter in there it would be nice.
Yes. Anybody knows what is the API for adding / changing the styler on a text morph? I'll have a use for a SmaCC grammar styler as well.
Anybody has a CSS parser around?
Thierry
For CSS it wouldn't be too damn hard I think.
Phil
On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi Torsten, Phil,
On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
-- www.tudorgirba.com
"Every thing has its own flow"
2014-09-15 6:44 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
I'll have a look. I find that PluggableTextMorph automatic behavior (smart characters, styling) is very nice when doing Smalltalk code, but a pain in anything else. I'd like to see that Smalltalk-customized code be refactored elsewhere than in the editor. What I'd like to see is the ability to customize the behavior for islands of text inside a text (recursively of course :)).
You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load.
Ok. The Moose image is a bit of a down to me when trying to understand code because code exploration capabilities are limited / non obvious compared to what I use in Pharo. Thierry
Cheers, Doru
On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
2014-09-05 16:03 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Maybe we can start small.
I've current needs that could well be handled in the environment.
The FileBrowser is in my view quite not used enough.
When doing web applications, I deal with Javascript, CSS, content files etc all the time.
The FileBrowser allows to edit files in its content pane. Doing an Accept (Alt-S) on the pane saves the file.
So, instead of starting an external edit session in Vim, I mostly work there for some smaller changes (like tweaking CSS).
Now, if we could have a syntax highlighter in there it would be nice.
Yes. Anybody knows what is the API for adding / changing the styler on a text morph? I'll have a use for a SmaCC grammar styler as well.
Anybody has a CSS parser around?
Thierry
For CSS it wouldn't be too damn hard I think.
Phil
On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi Torsten, Phil,
On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, On Mon, Sep 15, 2014 at 9:57 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-15 6:44 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
I'll have a look. I find that PluggableTextMorph automatic behavior (smart characters, styling) is very nice when doing Smalltalk code, but a pain in anything else. I'd like to see that Smalltalk-customized code be refactored elsewhere than in the editor.
What I'd like to see is the ability to customize the behavior for islands of text inside a text (recursively of course :)).
This is not yet possible. I would hope we get this to work within the context of TxText.
You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load.
Ok. The Moose image is a bit of a down to me when trying to understand code because code exploration capabilities are limited / non obvious compared to what I use in Pharo.
What do you mean? What is different for you in this area? Doru
Thierry
Cheers, Doru
On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-09-05 16:03 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Maybe we can start small.
I've current needs that could well be handled in the environment.
The FileBrowser is in my view quite not used enough.
When doing web applications, I deal with Javascript, CSS, content files etc all the time.
The FileBrowser allows to edit files in its content pane. Doing an Accept (Alt-S) on the pane saves the file.
So, instead of starting an external edit session in Vim, I mostly work there for some smaller changes (like tweaking CSS).
Now, if we could have a syntax highlighter in there it would be nice.
Yes. Anybody knows what is the API for adding / changing the styler on a text morph? I'll have a use for a SmaCC grammar styler as well.
Anybody has a CSS parser around?
Thierry
For CSS it wouldn't be too damn hard I think.
Phil
On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi Torsten, Phil,
On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
Hi Phil,
if there is something I would like to see our Pharo ecosystem and ST in general moving towards is to such a "multilanguage"/"multisourcecode"/"flexible ressources" kind of thing. Even when this could not be a short term goal I would like to see this in the long term.
I've been working in this area for many years now. And have learned a good deal while doing that :-) Making one language to execute within other's environment is the easy part, though it could be a lot of work (especially, if you care about performance). Making tools to be aware of different languages is not hard too, thought it is "just" a huge amount of work that has to be done. The tricky part is to allow one to talk to each other, preserving each other's semantics and still stay intuitive, clear and free of unnecessary boilerplate code. Another tricky bit is to make other workflows and ways of coding things in other languages work nicely with the way Smalltalk way we do it in Smalltalk. These are tough bits. That's where a real research has yet to be done...
- running Java inside of Smalltalk/X
Well, Smalltalk/X can do much more with Java than "just" run it. Java has been fully integrated into development tools supporting full development cycle :-)
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Hi, 2014-09-15 10:28 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Mon, Sep 15, 2014 at 9:57 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-09-15 6:44 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
I'll have a look. I find that PluggableTextMorph automatic behavior (smart characters, styling) is very nice when doing Smalltalk code, but a pain in anything else. I'd like to see that Smalltalk-customized code be refactored elsewhere than in the editor.
What I'd like to see is the ability to customize the behavior for islands of text inside a text (recursively of course :)).
This is not yet possible. I would hope we get this to work within the context of TxText.
I was thinking of having a look at TxText ;) I noticed that I have already started to reimplement part of the StringHolder / PluggableTextMorph logic outside it (via menu command objects / keymapping shortcuts instead of using the hardcoded versions inside the Morph or Model object) and I wanted to see if this was already done (or prepared for) in TxText. I think that, even in the context of the current TextEditor, I could customize based on islands based on what I already have. But I have to spend some time on it.
You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load.
Ok. The Moose image is a bit of a down to me when trying to understand code because code exploration capabilities are limited / non obvious compared to what I use in Pharo.
What do you mean? What is different for you in this area?
I'm accustomed to the smart suggestion stuff as I implemented it, makes it very easy to drill down in code... What I use a lot: Right mouse button on a global, select 'Browse' : inspect the class variable or open a browser on the class (depending on what it is). Also valid in a class #subclass: display in the browser, to browse the super class. Implementors / sendors of / accesses to instance var under right mouse button: open a full browser showing all the resulting methods (and not a message list :( ). Also works in the string containing instance variable names in a class definition pane. Double click on a package / class -> open a browser scoped to that package / class (where all search operations are limited to that scope). Ctrl+F -> open the finder toolbar on top of the browser, with reduced gui (no package choice) : result of the finder will appear in a new browser, and finder is scoped by the initial browser scope. So, when I end up in Nautilus, I just find myself very clumsy looking around (which is not good for my self-esteem ;) ) Not forgetting the fact that opening a Nautilus browser takes a lot longer. In Moose also, GTInspector is slow. Take it as a different experience on the GUI side; I know I invest a lot in the motor skill part of the GUI, and this has an effect when I switch platform. Thierry
Hi, On Mon, Sep 15, 2014 at 11:27 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Hi,
I'm accustomed to the smart suggestion stuff as I implemented it, makes it very easy to drill down in code...
What I use a lot:
Right mouse button on a global, select 'Browse' : inspect the class variable or open a browser on the class (depending on what it is). Also valid in a class #subclass: display in the browser, to browse the super class.
Implementors / sendors of / accesses to instance var under right mouse button: open a full browser showing all the resulting methods (and not a message list :( ). Also works in the string containing instance variable names in a class definition pane.
Double click on a package / class -> open a browser scoped to that package / class (where all search operations are limited to that scope).
Ctrl+F -> open the finder toolbar on top of the browser, with reduced gui (no package choice) : result of the finder will appear in a new browser, and finder is scoped by the initial browser scope.
So, when I end up in Nautilus, I just find myself very clumsy looking around (which is not good for my self-esteem ;) ) Not forgetting the fact that opening a Nautilus browser takes a lot longer.
Are you comparing with the AltBrowser?
In Moose also, GTInspector is slow.
What is slow?
Take it as a different experience on the GUI side; I know I invest a lot in the motor skill part of the GUI, and this has an effect when I switch platform.
It seems to me that you are not comparing the Moose image with the Pharo image, right? What are you comparing with? Can I look at these changes? Cheers, Doru
Thierry
-- www.tudorgirba.com "Every thing has its own flow"
Hi, 2014-09-15 11:37 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Mon, Sep 15, 2014 at 11:27 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hi,
I'm accustomed to the smart suggestion stuff as I implemented it, makes it very easy to drill down in code...
What I use a lot:
Right mouse button on a global, select 'Browse' : inspect the class variable or open a browser on the class (depending on what it is). Also valid in a class #subclass: display in the browser, to browse the super class.
Implementors / sendors of / accesses to instance var under right mouse button: open a full browser showing all the resulting methods (and not a message list :( ). Also works in the string containing instance variable names in a class definition pane.
Double click on a package / class -> open a browser scoped to that package / class (where all search operations are limited to that scope).
Ctrl+F -> open the finder toolbar on top of the browser, with reduced gui (no package choice) : result of the finder will appear in a new browser, and finder is scoped by the initial browser scope.
So, when I end up in Nautilus, I just find myself very clumsy looking around (which is not good for my self-esteem ;) ) Not forgetting the fact that opening a Nautilus browser takes a lot longer.
Are you comparing with the AltBrowser?
Yes.
In Moose also, GTInspector is slow.
What is slow?
Switching from one instance variable to another with the keyboard (i.e. doing arrow down or up multiple times) : each time a new presentation is built to be erased immediately (well, not immediately sadly :( ). Significantly worse when the host computer isn't very powerfull.
Take it as a different experience on the GUI side; I know I invest a lot in the motor skill part of the GUI, and this has an effect when I switch platform.
It seems to me that you are not comparing the Moose image with the Pharo image, right? What are you comparing with? Can I look at these changes?
Simply AltBrowser loaded. There isn't much changes overall: AltBrowser is a bit larger than the old system browser and a lot smaller than Nautilus while providing the system browser, the message list and the finder. It is certainly the proof Pharo provides a good infrastructure for IDE development and experimentation :) Thierry
Cheers, Doru
Thierry
-- www.tudorgirba.com
"Every thing has its own flow"
Take it as a different experience on the GUI side; I know I invest a lot in the motor skill part of the GUI, and this has an effect when I switch platform.
It seems to me that you are not comparing the Moose image with the Pharo image, right? What are you comparing with? Can I look at these changes?
Simply AltBrowser loaded. There isn't much changes overall: AltBrowser is a bit larger than the old system browser and a lot smaller than Nautilus while providing the system browser, the message list and the finder.
It is certainly the proof Pharo provides a good infrastructure for IDE development and experimentation :)
:) I encourage people to build the next generation that will make us switch :)
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
I'll have a look. I find that PluggableTextMorph automatic behavior (smart characters, styling) is very nice when doing Smalltalk code, but a pain in anything else. I'd like to see that Smalltalk-customized code be refactored elsewhere than in the editor.
What I'd like to see is the ability to customize the behavior for islands of text inside a text (recursively of course :)).
This is not yet possible. I would hope we get this to work within the context of TxText.
I was thinking of having a look at TxText ;)
Please Igor added the possibility to have span different attributes (like changing mouse cursor)
I noticed that I have already started to reimplement part of the StringHolder / PluggableTextMorph logic outside it (via menu command objects / keymapping shortcuts instead of using the hardcoded versions inside the Morph or Model object) and I wanted to see if this was already done (or prepared for) in TxText.
I think that, even in the context of the current TextEditor, I could customize based on islands based on what I already have. But I have to spend some time on it.
I'm accustomed to the smart suggestion stuff as I implemented it, makes it very easy to drill down in code...
What I use a lot:
Right mouse button on a global, select 'Browse' : inspect the class variable or open a browser on the class (depending on what it is). Also valid in a class #subclass: display in the browser, to browse the super class.
Implementors / sendors of / accesses to instance var under right mouse button: open a full browser showing all the resulting methods (and not a message list :( ). Also works in the string containing instance variable names in a class definition pane.
Double click on a package / class -> open a browser scoped to that package / class (where all search operations are limited to that scope).
Ctrl+F -> open the finder toolbar on top of the browser, with reduced gui (no package choice) : result of the finder will appear in a new browser, and finder is scoped by the initial browser scope.
So, when I end up in Nautilus, I just find myself very clumsy looking around (which is not good for my self-esteem ;) ) Not forgetting the fact that opening a Nautilus browser takes a lot longer. In Moose also, GTInspector is slow.
Take it as a different experience on the GUI side; I know I invest a lot in the motor skill part of the GUI, and this has an effect when I switch platform.
Thierry
This is not yet possible. I would hope we get this to work within the context of TxText.
Igor got nearly embedded morphs to react to event: we embedded a simpleButtonMorph in TxText and we can click on it, delete it... Now there are some problems with positionning but it should be fixed soon. We are looking for scenario to work with txText to check the api - igor wants to have handling event (to support smart sugs, click on a text to jump...) - syntax highlithing - replacing existing editor? Stef
2014-09-19 20:32 GMT+02:00 stepharo <stepharo@free.fr>:
This is not yet possible. I would hope we get this to work within the
context of TxText.
Igor got nearly embedded morphs to react to event: we embedded a simpleButtonMorph in TxText and we can click on it, delete it... Now there are some problems with positionning but it should be fixed soon.
Cool. I did exactly that in VisualWorks when I was a student, and, when you get it to work, it is really great!
We are looking for scenario to work with txText to check the api
- igor wants to have handling event (to support smart sugs, click on a text to jump...) - syntax highlithing - replacing existing editor?
I'll have a look. Thierry
Stef
Hi Doru, I'm looking through it. Interestingly simple :) You do have the styler inside another styler stuff working (smalltalk code styler inside a Pillar code bloc) which is very neat. Thierry Le 15/09/2014 06:44, Tudor Girba a écrit :
Hi,
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Hi Thierry, Thanks for the feedback. Indeed, the styling part works fine. What I do is have a first level parser that creates commands for styling. When I detect a Smalltalk block, the command delegates further to Shout. I guess that this type of design will be useful also for handling Helvetia multi languages. But, we still cannot have actions that are segment specific :). I would love to be able to have some sort of composite editor where the leaf editors correspond to a segment. Cheers, Doru On Tue, Sep 16, 2014 at 11:10 PM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Hi Doru,
I'm looking through it. Interestingly simple :) You do have the styler inside another styler stuff working (smalltalk code styler inside a Pillar code bloc) which is very neat.
Thierry
Le 15/09/2014 06:44, Tudor Girba a écrit :
Hi,
As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser.
You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Le 17/09/2014 06:08, Tudor Girba a écrit :
Hi Thierry,
Thanks for the feedback.
Indeed, the styling part works fine. What I do is have a first level parser that creates commands for styling. When I detect a Smalltalk block, the command delegates further to Shout.
I guess that this type of design will be useful also for handling Helvetia multi languages.
Yes. Is Helvetia still active or are most of its components moved/incorporated in Moose? I had a look because I have to work on DSL for the next few weeks / months.
But, we still cannot have actions that are segment specific :).
Why? As soon as you have a parser that can structure the contents (build a tree of it), then it's easy to have specific actions. Unless you're talking of segment specific keyboard shortcuts (and even those could be accomodated).
I would love to be able to have some sort of composite editor where the leaf editors correspond to a segment.
Yes, it sounds like a reasonable vision. But hard when you consider the fact that editing the text may make it flow between segments (and hence between editors). Copy/paste of text over segment boundaries (or simply selection) could really be a challenge. This is why Stéphane doesn't like my vision of a code editor which displays and edit an ast instead of a text understood by a parser. Now we should really have enough text display capabilities to display nicely formatted pillar documents as documentation. The current Help format is ... very nicely minimalistic :( Thierry
participants (6)
-
Jan Vrany -
phil＠highoctane.be -
stepharo -
Thierry Goubier -
Torsten Bergmann -
Tudor Girba