August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Moose-dev] [ann] moldable editor - with expandable elements

by Tudor Girba

Hi Tim, Thanks for the kind words. What you see now is only the first more tangible effect of what Bloc represents. Expect significantly more :). Cheers, Doru > On Aug 26, 2017, at 9:56 AM, Tim Mackinnon <tim(a)testit.works> wrote: > > Guys - this is absolutely astounding. 6 months ago I tagged a tweet with #pharoproject about why we put up with static source code when we can do so much more, and I'm stunned that in literally months this is a evolving around us. > > This community is awesome! > > Tim > > Sent from my iPhone > > On 26 Aug 2017, at 01:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. >> >> To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. >> >> Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. >> >> <pillar-mondrian-examples.png> >> >> Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). >> >> <pillar-mondrian-expanded-preview.png> >> >> Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). >> >> A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. >> >> Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. >> >> We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. >> >> All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: >> >> Iceberg enableMetacelloIntegration: true. >> Metacello new >> baseline: 'GToolkit'; >> repository: 'github://feenkcom/gtoolkit/src'; >> load. >> >> And then inspect: >> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference >> >> Cheers, >> The feenk team >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tudor Girba

Hi, Thanks. About examples: I am not completely satisfied with the existing pragma-based definition, but I am convinced that, after having used examples extensively, they are very useful. We will certainly do another iteration over the model, but as I mentioned, I would prefer to have the conversation about them another time. Now, we should talk about the editor :). In the context of the editor, the examples was a validation use case to show to what extent we can mold it to a specific application. The main issue here is that we can start to have expression possibilities at UI level that did not exist before. Really, it is quite amazing that we can now decorate a piece of text with any visual elements at no cost. For example, we did the same with pictures (referencing a picture shows it right in place). The examples support was added on top of the default Pillar without really changing the main grammar (there is only a tiny change to allow having scripts that can have parameters, but that is for convenience only). Other than that, we have a simple grammar specialization that adds syntax highlighting. We would have preferred to do it on the AST level, but the issue right now is that the AST does not carry token information and is less useful for tooling at present time. The final goal should be to enrich the AST have the syntax highlighter be a visitor, but again, that is secondary. The way we captured examples now is not ideal, and I actually would like to have a conversation about how to make Pillar more extensible (probably to reintroduce something like *refâ¦). As we will move Pillar towards the image, we will certainly need ways to both link to objects and code (methods, classes) and to insert various representations in place. Cheers, Doru > On Aug 26, 2017, at 5:41 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi doru > > This is cool. Now I did not change my veto on GTExample. There will not get integrated. Period. > We do not want to be forced to use special tools to manage semantic metadata when we can have simple call. > I'm already scared and amazed by the complexity of annotations in the Java world. > So to me if the Pillar part cannot be separated from GTExample then too bad. > > > Stef > > On Sat, Aug 26, 2017 at 1:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. > > To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. > > Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. > > <pillar-mondrian-examples.png> > > Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). > > <pillar-mondrian-expanded-preview.png> > > Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). > > A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. > > Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. > > We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. > > All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > And then inspect: > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference > > Cheers, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Aug. 26, 2017

Dark Mode

by horrido

I found this interesting article <https://hackernoon.com/apple-and-others-need-a-dark-mode-for-people-like-mo…> . I wanted to express my opinion... Dark mode looks cool and all, but it does have a downside. I was very happy with the normal Pharo 5.0 look, but when Pharo 6.0 came out with its dark theme, I was rather put off by it. For me, at least, the dark theme makes it harder to read the text. Too bad Pharo isn't themable. -- View this message in context: http://forum.world.st/Dark-Mode-tp4964409.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 26, 2017

Re: [Pharo-users] The Wisdom of the Crowd Redux

by horrido

Quite right. When you tout the wisdom of the crowd, you have to back it up with simple, persuasive arguments. That's what my blog series over the past three years have been all about! I just keep hammering away at the same simple, persuasive arguments again and again and again and again. Ad nauseum. Similarly, if I insult your favourite language, whether that's C or JavaScript or Common Lisp, I better back it up with clear points. Offray Vladimir Luna CÃ¡rdenas-2 wrote > Yes, thanks for sharing it Richard. > > For me the issue with wisdom of the crowd arguments is, as you point at > the end of the article, that also crowd can be pretty stupid, so > when/how you difference between both cases? At some point seems like > crowd is wise when they share my opinion and dumb when they don't. A > different argument I have found in favor or non-popular but powerful > languages is made by Matthew Butterick[1] in the case of Lisp/Racket by > deconstructing the ad-populum falacy (something is good, because is > popular) and then going beyond the frequent flattery of authoritative > voices, giving real examples from a first person perspective. I think > that is an interesting and novel approach for advocacy. > > [1] http://practicaltypography.com/why-racket-why-lisp.html > > Cheers, > > Offray > > On 22/08/17 12:09, Ben Coman wrote: >> nice article. thanks for sharing. >> cheers -ben >> >> On Tue, Aug 22, 2017 at 4:14 AM, horrido < > horrido.hobbies@ > > <mailto: > horrido.hobbies@ > >> wrote: >> >> I'm glad people in the programming community are recognizing the >> value of >> Smalltalk: The Wisdom of the Crowd >> >> <https://medium.com/@richardeng/the-wisdom-of-the-crowd-c7aff954bd5f > > > <https://medium.com/@richardeng/the-wisdom-of-the-crowd-c7aff954bd5f>> >> . I >> was very pleasantly surprised by this. >> >> >> >> -- >> View this message in context: >> http://forum.world.st/The-Wisdom-of-the-Crowd-Redux-tp4963261.html >> >> <http://forum.world.st/The-Wisdom-of-the-Crowd-Redux-tp4963261.html> >> Sent from the Pharo Smalltalk Users mailing list archive at >> Nabble.com. >> >> -- View this message in context: http://forum.world.st/The-Wisdom-of-the-Crowd-Redux-tp4963261p4964407.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Thierry Goubier

Hi Tim, 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > I think you pose some interesting design challenges - but it's worthy of > experimentation. > > I share Denis' enthusiasm to build something better - but it's true it's > not an easy problem space. > > I'm a big fan of GTInspector, but sometimes I slide across and lose my > context (not always, and not for all types of problems). > I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia. I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser. > > For unique extractions - inlining is a no brainer (it's just like code > folding in many editors). For non-unique, maybe something in the gutter > might let you easily flip... I don't know, but I'm not convinced our > current way is always optimal. > Agreed. I have changed the way I code to reduce the context needed to understand it. > > Still, the whole moldable idea is to make it easy to experiment - and > that's the cool bit. That's where we thrive. > Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier? Regards, Thierry > > Tim > > Sent from my iPhone > > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> No Thierry, Newspeak do not allow it. And it not looks similar to what I >> want. >> > > Hum, you would still get the same overall approach: editor inside editor > (or view inside view). Now, you can say it is not the same, up to you. > > For me, it has the same effect: the editor isn't in a single place > anymore. You may consider it doesn't matter; IMHO it does matter (and it > makes for me the Newspeak editor slightly less efficient; the same that the > Smalltalk system browser seemed more effective than the Self in-place > method edit, for having used both). > > >> >> Now command+click on selector opens implementors window. In past it moved >> browser to single implementor. It was nice and it is how other IDEs are >> working. >> > > You miss the past behaviour? Why not adding it again? > > >> But as Tim notice it always loses context. And it is quite difficult to >> browse long call chain which include many small methods. >> > > I'm not sure it would solve that one. > > Either it is a long call chain with a fan-out of one, in which case the > developper is creating many useless single line methods because it is "the > right way"(tm), or it has a fan-out greater than one (your typical > polymorphic code) and then each time you open, you have half a dozen > implementors. > > For that, you already have the flow browser. > > >> So with new editor command+click will be able expand implementor just in >> place. I think it will be big improvement for IDE. >> > > As I said, with Calypso and Nautilus handling badly long methods, then a > method inside a method just makes the top level method longer... I'd like > to see you do that on Metacello or SmaCC code, where important methods > easily go over 50 lines before you expand anything. > > I'd say there that the GTInspector approach would work better -> expand on > the right, with the ability to keep two side by side, and overlaid with > lines clearly showing what has been expanded (for that "context" thing). > > Regards, > > Thierry > > >> >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> >>> >>> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> >>>> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>>> >>>>> Denis - that's a very cool idea if I've understood you - expand in the >>>>> source code of the current method, literally inline? So you could scroll up >>>>> and down to view the context as you expand it out? >>>>> >>>> >>>> Yes, exactly. >>>> >>> >>> Then that would look a bit like the NewSpeak code browser, if you would >>> like to try the concept. >>> >>> There are disadvantages to that paradigm. One of those is that the >>> system browser in Pharo is ill-suited to long methods. >>> >>> Thierry >>> >>> >>>> >>>> >>>>> One of the complaints around refactoring is that you lose context of >>>>> surrounding code - intelligent in place expansion would be the best of both >>>>> worlds... >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> >>>>> wrote: >>>>> >>>>> This is really cool. It opens so many possibilities. >>>>> >>>>> I imaging method editor where message sends can be expanded to >>>>> implementors just in place. >>>>> >>>>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>> >>>>>> Hi, >>>>>> >>>>>> We are really pleased to announce another major advancement in the >>>>>> development of the moldable editor, and most of it was enabled because of >>>>>> one new feature: expandable elements. We think this will impact >>>>>> significantly our day to day interactions. >>>>>> >>>>>> To exemplify what we mean, we will make use of two more alpha >>>>>> projects that we did not announce yet: GT Documenter (a set of >>>>>> documentation tools based on Pillar and GT Examples) and GT Mondrian (the >>>>>> graph visualization engine), both of which are being implemented in Bloc. >>>>>> >>>>>> Please take a look at the following pictures showing the >>>>>> documentation Pillar file that ships together with GT Mondrian. What stands >>>>>> out are the two embedded pictures. These are actually not pictures, but >>>>>> visualizations rendered live during the viewing of the document out of a >>>>>> referenced GT Example. >>>>>> >>>>>> >>>>>> Now, GT Examples are likely also new for most people. We introduced >>>>>> them a couple of years ago based on the original idea of Markus Gaelli. >>>>>> These are a kind of tests that return an object and that can be built out >>>>>> of other examples. The nice thing is that they are always executable and >>>>>> testable. So, of course, if you see the resulting object, you can also see >>>>>> the code that created it, and if you see the code, you can even execute it >>>>>> live, right in place (notice the preview of the second snippet). >>>>>> >>>>>> <pillar-mondrian-expanded-preview.png> >>>>>> >>>>>> Perhaps the most controversial part of GT Examples is that they offer >>>>>> a mechanism to define static dependencies via pragmas. Please, letâs leave >>>>>> this debate to another occasion, but please also notice that tools can use >>>>>> that static information to unfold the code of the referenced method (notice >>>>>> the nested code editors). >>>>>> >>>>>> A side note: if you look closer at the list with three items at the >>>>>> top of the Tutorial section, you will notice numbering next to #. That is >>>>>> actually syntax highlighting and so is the mechanism that embeds the >>>>>> expandable elements. Itâs really cool. >>>>>> >>>>>> Taking step back, when we introduced the editor a few weeks ago, we >>>>>> called it moldable because we said we can make it take different shapes >>>>>> easily. GT Documenter with everything you see in the above screenshots has >>>>>> currently ~500 lines of code, and all this while still having an editor >>>>>> that is highly scalable. >>>>>> >>>>>> We think that Bloc and Brick will change dramatically face of Pharo >>>>>> and now we can start to get a glimpse of what is possible. For example, the >>>>>> use case presented above is more than a technical tool, and we think this >>>>>> will change both the way we write documentation and the way we consume it. >>>>>> >>>>>> All these will be presented at ESUG both during presentations and at >>>>>> the Innovation Awards competition. In the meantime, those that want to play >>>>>> with it can execute the following in both Pharo 6.1 and Pharo 7.0: >>>>>> >>>>>> Iceberg enableMetacelloIntegration: true. >>>>>> Metacello new >>>>>> baseline: 'GToolkit'; >>>>>> repository: 'github://feenkcom/gtoolkit/src'; >>>>>> load. >>>>>> >>>>>> And then inspect: >>>>>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' >>>>>> asFileReference >>>>>> >>>>>> Cheers, >>>>>> The feenk team >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.feenk.com >>>>>> >>>>>> "Innovation comes in the least expected form. >>>>>> That is, if it is expected, it already happened." >>>>>> >>>>>> >>>>> >>>> >>> >> >

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tim Mackinnon

I think you pose some interesting design challenges - but it's worthy of experimentation. I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space. I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems). For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal. Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive. Tim Sent from my iPhone > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> No Thierry, Newspeak do not allow it. And it not looks similar to what I want. > > Hum, you would still get the same overall approach: editor inside editor (or view inside view). Now, you can say it is not the same, up to you. > > For me, it has the same effect: the editor isn't in a single place anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both). > >> >> Now command+click on selector opens implementors window. In past it moved browser to single implementor. It was nice and it is how other IDEs are working. > > You miss the past behaviour? Why not adding it again? > >> But as Tim notice it always loses context. And it is quite difficult to browse long call chain which include many small methods. > > I'm not sure it would solve that one. > > Either it is a long call chain with a fan-out of one, in which case the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors. > > For that, you already have the flow browser. > >> So with new editor command+click will be able expand implementor just in place. I think it will be big improvement for IDE. > > As I said, with Calypso and Nautilus handling badly long methods, then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything. > > I'd say there that the GTInspector approach would work better -> expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing). > > Regards, > > Thierry > >> >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>> >>> >>> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>>>> Denis - that's a very cool idea if I've understood you - expand in the source code of the current method, literally inline? So you could scroll up and down to view the context as you expand it out? >>>> >>>> Yes, exactly. >>> >>> Then that would look a bit like the NewSpeak code browser, if you would like to try the concept. >>> >>> There are disadvantages to that paradigm. One of those is that the system browser in Pharo is ill-suited to long methods. >>> >>> Thierry >>> >>>> >>>>> One of the complaints around refactoring is that you lose context of surrounding code - intelligent in place expansion would be the best of both worlds... >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>>> >>>>>> This is really cool. It opens so many possibilities. >>>>>> >>>>>> I imaging method editor where message sends can be expanded to implementors just in place. >>>>>> >>>>>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>>>> Hi, >>>>>>> >>>>>>> We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. >>>>>>> >>>>>>> To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. >>>>>>> >>>>>>> Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). >>>>>>> >>>>>>> <pillar-mondrian-expanded-preview.png> >>>>>>> >>>>>>> Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). >>>>>>> >>>>>>> A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. >>>>>>> >>>>>>> Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. >>>>>>> >>>>>>> We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. >>>>>>> >>>>>>> All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: >>>>>>> >>>>>>> Iceberg enableMetacelloIntegration: true. >>>>>>> Metacello new >>>>>>> baseline: 'GToolkit'; >>>>>>> repository: 'github://feenkcom/gtoolkit/src'; >>>>>>> load. >>>>>>> >>>>>>> And then inspect: >>>>>>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference >>>>>>> >>>>>>> Cheers, >>>>>>> The feenk team >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> "Innovation comes in the least expected form. >>>>>>> That is, if it is expected, it already happened." >>>>>>> >>>>>> >>>> >>> >> >

Aug. 26, 2017

The Spec UI Framework. first translation to korean finish.

by peter yoo

hello. for pharo guys. Long time no see. It is not easy for Korean people to study pharo. Very few people use smalltalk. Of course, it is hard to find Korean language resources. Recently I went to find the spec framework to study Pharo. Of course I looked at morphic designer in squeak, but I believe in pharo team. I have translated it with the help of google for those who want to study. I refer to the pillar source of git. I wanted to work with pdf, but I know xetex, but I do not know about pillar and luatex. So I put it on the wiki. Thank you for always making good pharo. http://trans.onionmixer.net/mediawiki/index.php?title=TheSpecUIframework -- http://lookandwalk.com http://looknw.com | http://onionmixer.net peter yoo(Jonghwa Yoo). ROK

Aug. 26, 2017

pillar image in external link (or html a tag)

by Peter UhnÃ¡k

Hi, how can I embed an image into an anchor in Pillar? I've tried *+Pharo>https://pharo.org/web/files/pharo.png+>http://pharo.org/* I've also tried to create document by hand and export it, but every single exporter failed on it. doc := PRDocument new add: (PRExternalLink new reference: 'http://pharo.org/'; add: (PRFigure new reference: 'https://pharo.org/web/files/pharo.png'; add: (PRText content: 'Pharo'); yourself ); yourself ); yourself Thanks, Peter

Aug. 26, 2017

Re: [Pharo-users] [ANN] Pharo wiki , is here

by Offray Vladimir Luna CÃ¡rdenas

Thanks for keep me posted about your experiments. I would like to know where the current interface doesn't suit your needs/tastes and how easy was to use/extend the tool. I think that mind mapping problem would be particularly well suited for your GUI approaches. Cheers, Offray On 26/08/17 14:53, Dimitris Chloupis wrote: > mind mapping is an interest of mine too, though i never tried to make > one app for it yet. Ok will see if I will go down the Grafoscopio > route and will keep you posted. I was thinking using it as an in-image > interface for the wiki. > > On Sat, Aug 26, 2017 at 10:15 PM Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > That would be pretty interesting and yes, it is under MIT. > > On custom GUI's I have thought about a mind mapping interface for > Grafoscopio, for presentations. I would like to stretch the > tree/graph metaphor so it can make what we do with different > metaphors right now on "offimatics" (writing, calculation and > presentation), so this custom metaphors are interesting to me. > > Cheers, > > Offray > > > On 26/08/17 12:28, Dimitris Chloupis wrote: >> How would you feel if I took grafoscopio and made a custom GUI >> for it, mainly for personal usage ? Does it use the MIT license ? >> >> On Sat, Aug 26, 2017 at 6:56 PM Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> >> No it can't. Grafoscopio Markdown nodes just plain text boxes >> with Markdown code inside, but I would like to have at least >> syntax hightlighting for it. What Grafoscopio can do is to >> traverse a tree and process node headers as markdown titles, >> footnotes and others to produce a flat Markdown file to be >> processed by Pandoc. Also, thanks to special %metadata nodes >> in the tree, Grafoscopio can control & feedback the Pandoc >> command line options *inside* the notebook, increasing >> reproducibility, just by using plain Pharo dictionaries and >> dynamic arrays. Then, you can use the Notebook menu to export >> as PDF by running such options from the GUI. >> >> Cheers, >> >> Offray >> >> >> >> On 26/08/17 10:31, Dimitris Chloupis wrote: >>> Grafoscopio can display markdown files ? >>> >>> On Sat, Aug 26, 2017 at 5:38 PM Offray Vladimir Luna >>> CÃ¡rdenas <offray.luna(a)mutabit.com >>> <mailto:offray.luna@mutabit.com>> wrote: >>> >>> Dimitris, >>> >>> I understand your practical reasons to have Markdown >>> over Pillar and in fact I have advocated several of >>> them. As I have said, Markdown ubiquity for complete >>> documentation workflows (including complete books) is >>> similar to git ubiquity for code. Despite having other >>> personal preferences in markup and DVCS, I think is >>> strategic to give them support in Pharo, without >>> precluding any work on our own tools (Monticello, >>> Metacello, Pillar, etc.). >>> >>> I'll try to make some experiments with integration of >>> Documenter in Grafoscopio and Markdown. They'll advance >>> slowly, because time constrains now that I'm trying to >>> finish my thesis, but once a week I'll try to show >>> advancements and make questions. >>> >>> Cheers, >>> >>> Offray >>> >>> >>> On 26/08/17 01:55, Dimitris Chloupis wrote: >>>> As I said the format is not so important for me, the >>>> reason why I chose markdown instead of pillar is >>>> because you can edit it using github web interface >>>> making it easier. The books will continue to use >>>> Pillar, because making a book is obviously a lot more >>>> sophisticated than creating a wiki that mainly has web >>>> links to various internet locations. Pillar already can >>>> export to markdown , latex, html and through latex it >>>> can also export to pdf. >>>> >>>> After Stef requested it, I moved the wiki inside the >>>> pharo git repository here >>>> >>>> https://github.com/pharo-project/pharo >>>> >>>> I also added a link to it inside the git wiki of pharo >>>> >>>> https://github.com/pharo-project/pharo/wiki >>>> >>>> >>>> On Sat, Aug 26, 2017 at 2:17 AM Offray Vladimir Luna >>>> CÃ¡rdenas <offray.luna(a)mutabit.com >>>> <mailto:offray.luna@mutabit.com>> wrote: >>>> >>>> So, we're going to have Markdown for the wiki and >>>> probably for documentation (via GitBooks)..., which >>>> is not surprising considering the vast amount of >>>> support such documentation format has and the >>>> extensions for a complete documentation toolchain >>>> and features. As I said, I think that is an >>>> important syntax and we should put Scholarly/Pandoc >>>> Markdown in the radar for documentation support in >>>> Pharo. Is what I'm doing with Grafoscopio and now >>>> that Pillar support is again taking momentum, the >>>> infrastructure there (parsers, highlighters, >>>> editors) could be extended to support Pandoc's >>>> Markdown. >>>> >>>> I'll keep you posted. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> >>>> On 24/08/17 17:59, Dimitris Chloupis wrote: >>>>> >>>>> >>>>> On Thu, Aug 24, 2017 at 11:32 PM Stephane Ducasse >>>>> <stepharo.self(a)gmail.com >>>>> <mailto:stepharo.self@gmail.com>> wrote: >>>>> >>>>> You have Netstyle/Workflow too. >>>>> >>>>> >>>>> done >>>>> >>>>> "Why are you using markup documents to create the >>>>> wiki when you could >>>>> use Github wiki itself? >>>>> >>>>> For portability?" >>>>> >>>>> good question. Yes for flexibility , another >>>>> reason however is that Github wiki is a separate >>>>> repo and I did not want that because in the very >>>>> back of my head I am considering the option of >>>>> creating software to allow access to wiki from >>>>> inside Pharo and I wanted to be all (content and >>>>> code) in the same repo. Its a very low priority >>>>> for now. >>>>> >>>>> Also Github wiki is basically the same as I am >>>>> doing with some extra format (table of contents) , >>>>> in my case I dont care because Github allows me to >>>>> define HTML templates that will format the wiki >>>>> webpage and make it look a a lot more polished >>>>> that pharo wiki looks like. Generally there are >>>>> some cool stuff you can do with Markdown and >>>>> Github , plus the fact that markdown can embed >>>>> HTML etc. >>>>> >>>>> There is also the option of Gitbook which has some >>>>> nice features for generating polished and well >>>>> structured documentation. >>>>> >>>>> So I like to keep my options open. For now I am >>>>> focusing 100% on content. >>>> >>> >> >

Aug. 26, 2017

Re: [Pharo-users] [ANN] Pharo wiki , is here

by Dimitris Chloupis

mind mapping is an interest of mine too, though i never tried to make one app for it yet. Ok will see if I will go down the Grafoscopio route and will keep you posted. I was thinking using it as an in-image interface for the wiki. On Sat, Aug 26, 2017 at 10:15 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > That would be pretty interesting and yes, it is under MIT. > > On custom GUI's I have thought about a mind mapping interface for > Grafoscopio, for presentations. I would like to stretch the tree/graph > metaphor so it can make what we do with different metaphors right now on > "offimatics" (writing, calculation and presentation), so this custom > metaphors are interesting to me. > > Cheers, > > Offray > > On 26/08/17 12:28, Dimitris Chloupis wrote: > > How would you feel if I took grafoscopio and made a custom GUI for it, > mainly for personal usage ? Does it use the MIT license ? > > On Sat, Aug 26, 2017 at 6:56 PM Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> No it can't. Grafoscopio Markdown nodes just plain text boxes with >> Markdown code inside, but I would like to have at least syntax >> hightlighting for it. What Grafoscopio can do is to traverse a tree and >> process node headers as markdown titles, footnotes and others to produce a >> flat Markdown file to be processed by Pandoc. Also, thanks to special >> %metadata nodes in the tree, Grafoscopio can control & feedback the Pandoc >> command line options *inside* the notebook, increasing reproducibility, >> just by using plain Pharo dictionaries and dynamic arrays. Then, you can >> use the Notebook menu to export as PDF by running such options from the GUI. >> >> Cheers, >> >> Offray >> >> >> >> On 26/08/17 10:31, Dimitris Chloupis wrote: >> >> Grafoscopio can display markdown files ? >> >> On Sat, Aug 26, 2017 at 5:38 PM Offray Vladimir Luna CÃ¡rdenas < >> offray.luna(a)mutabit.com> wrote: >> >>> Dimitris, >>> >>> I understand your practical reasons to have Markdown over Pillar and in >>> fact I have advocated several of them. As I have said, Markdown ubiquity >>> for complete documentation workflows (including complete books) is similar >>> to git ubiquity for code. Despite having other personal preferences in >>> markup and DVCS, I think is strategic to give them support in Pharo, >>> without precluding any work on our own tools (Monticello, Metacello, >>> Pillar, etc.). >>> >>> I'll try to make some experiments with integration of Documenter in >>> Grafoscopio and Markdown. They'll advance slowly, because time constrains >>> now that I'm trying to finish my thesis, but once a week I'll try to show >>> advancements and make questions. >>> >>> Cheers, >>> >>> Offray >>> >>> On 26/08/17 01:55, Dimitris Chloupis wrote: >>> >>> As I said the format is not so important for me, the reason why I chose >>> markdown instead of pillar is because you can edit it using github web >>> interface making it easier. The books will continue to use Pillar, because >>> making a book is obviously a lot more sophisticated than creating a wiki >>> that mainly has web links to various internet locations. Pillar already can >>> export to markdown , latex, html and through latex it can also export to >>> pdf. >>> >>> After Stef requested it, I moved the wiki inside the pharo git >>> repository here >>> >>> https://github.com/pharo-project/pharo >>> >>> I also added a link to it inside the git wiki of pharo >>> >>> https://github.com/pharo-project/pharo/wiki >>> >>> >>> On Sat, Aug 26, 2017 at 2:17 AM Offray Vladimir Luna CÃ¡rdenas < >>> offray.luna(a)mutabit.com> wrote: >>> >>>> So, we're going to have Markdown for the wiki and probably for >>>> documentation (via GitBooks)..., which is not surprising considering the >>>> vast amount of support such documentation format has and the extensions for >>>> a complete documentation toolchain and features. As I said, I think that is >>>> an important syntax and we should put Scholarly/Pandoc Markdown in the >>>> radar for documentation support in Pharo. Is what I'm doing with >>>> Grafoscopio and now that Pillar support is again taking momentum, the >>>> infrastructure there (parsers, highlighters, editors) could be extended to >>>> support Pandoc's Markdown. >>>> >>>> I'll keep you posted. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> On 24/08/17 17:59, Dimitris Chloupis wrote: >>>> >>>> >>>> >>>> On Thu, Aug 24, 2017 at 11:32 PM Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> >>>>> You have Netstyle/Workflow too. >>>>> >>>> >>>> done >>>> >>>> "Why are you using markup documents to create the wiki when you could >>>> use Github wiki itself? >>>> >>>> For portability?" >>>> >>>> good question. Yes for flexibility , another reason however is that >>>> Github wiki is a separate repo and I did not want that because in the very >>>> back of my head I am considering the option of creating software to allow >>>> access to wiki from inside Pharo and I wanted to be all (content and code) >>>> in the same repo. Its a very low priority for now. >>>> >>>> Also Github wiki is basically the same as I am doing with some extra >>>> format (table of contents) , in my case I dont care because Github allows >>>> me to define HTML templates that will format the wiki webpage and make it >>>> look a a lot more polished that pharo wiki looks like. Generally there are >>>> some cool stuff you can do with Markdown and Github , plus the fact that >>>> markdown can embed HTML etc. >>>> >>>> There is also the option of Gitbook which has some nice features for >>>> generating polished and well structured documentation. >>>> >>>> So I like to keep my options open. For now I am focusing 100% on >>>> content. >>>> >>>> >>>> >>> >> >

Aug. 26, 2017