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

Re: [Pharo-users] How to create a minimal image ?

by Cyril Ferlicot D.

Le 26/08/2017 Ã 21:43, Dimitris Chloupis a Ã©crit : > is this the jenkis job you talking about ? > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ > > does the image work ? is it usable ? > Not sure but I think it is more this CI: https://ci.inria.fr/pharo-ci-jenkins2/ -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 26, 2017

Re: [Pharo-users] How to create a minimal image ?

by Dimitris Chloupis

is this the jenkis job you talking about ? https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ does the image work ? is it usable ? On Sat, Aug 26, 2017 at 9:45 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > look for bootstrapped image. > And we have a github repo and jenkins job to produce it. > Stef > > On Sat, Aug 26, 2017 at 7:31 PM, Dimitris Chloupis > <kilon.alios(a)gmail.com> wrote: > > I remember that the website used to link to a minimal image download but > it > > does not seem there is one anymore > > > > Is still minimal image maintained ? > > Are there ways to make a image minimal ? > > Are there any tools for this job ? > > Is there any kind of documentation about this ? > >

Aug. 26, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

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] How to create a minimal image ?

by Stephane Ducasse

look for bootstrapped image. And we have a github repo and jenkins job to produce it. Stef On Sat, Aug 26, 2017 at 7:31 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I remember that the website used to link to a minimal image download but it > does not seem there is one anymore > > Is still minimal image maintained ? > Are there ways to make a image minimal ? > Are there any tools for this job ? > Is there any kind of documentation about this ?

Aug. 26, 2017

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by Stephane Ducasse

But it is a freeze or a screen refresh problem? Can you try to command . heavily on your frozen image? On Sat, Aug 26, 2017 at 2:48 PM, Ben Coman <btc(a)openinworld.com> wrote: > Hi Ted, > > You might consider building a debug VM. There is a random chance it > provides useful insight. > At its simplest all you need to do is... > $ git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ cd opensmalltalk-vm/build.macos32x86/pharo.cog.spur > $ ./mvm -A > > taken from... > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos32x86… > > First confirm the problem still exists in each of three generated VMs > started normally, > then later try using lldb to trace what methods are executed. > (though I'm not familiar with lldb - you'll need to google some tutorials) > > cheers -ben > > On Fri, Aug 25, 2017 at 9:55 PM, TedVanGaalen <tedvga(a)gmail.com> wrote: >> >> Hi Ben, >> Did the following >> - restoring Pharo.app/Contents/MacOS/Plugins/libFT2Plugin.dylib (by >> renaming its extension back to .dylib) >> - started Pharo >> -setting use Free type ON >> -setting Update fonts at start ON >> >> it then immediately starts loading fonts, (which I thought might be a >> good idea >> because perhaps fonts were not completely loaded in the image, >> but that didnât make any difference) >> >> -saved and quit >> -fired up Pharo again. >> >> didnât help. Same problems occur >> >> then: (as you have asked) >> >> - started Pharo again >> -setting use Free type OFF >> -setting Update fonts at start OFF >> -saved and quit >> -fired up Pharo again. >> >> didnât help either >> >> I have no idea what the cause might be, >> but if you have other suggestions to test >> I be glad to help. (if not a thousand attempts :o) >> >> in the mean time I use 5 until a next release comes out 7 ? that works ok. >> >> kind regards >> TedvG >> >> >> >> >> On 25. Aug 2017, at 06:07, Ben Coman [via Smalltalk] <[hidden email]> >> wrote: >> >> What happens if you untick "Use FreeType" in System > Settings? >> >> cheers -ben >> >> >> On Thu, Aug 24, 2017 at 10:06 PM, TedVanGaalen <<a >> href="x-msg://1/user/SendEmail.jtp?type=node&node=4963983&i=0" >> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote: >>> >>> yes, after full screen -> normal window -> minimise -> reshow it did. >>> (not in any particular order, tried al those before as well) >>> >>> TedvG >>> >>> >>> On 24. Aug 2017, at 15:46, EstebanLM [via Smalltalk] <[hidden email]> >>> wrote: >>> >>> and image still freezing? >>> >>> Esteban >>> >>> On 24 Aug 2017, at 15:28, TedVanGaalen <<a href="<a >>> href="x-msg://3/user/" >>> class="">x-msg://3/user/SendEmail.jtp?type=node&node=4963878&i=0" >>> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote: >>> >>> Hi Esteban, >>> unfortunately that doesnât make any difference. >>> What I did: >>> extension temporarily renamed to â¦..wasAdylib >>> Started Pharo app by clikcing on it (gets the downloaded maiden image) >>> then: >>> âFT2Error:Freetype2 primitive failed [error -1][canât get error string]â >>> >>> >> >> >> >> ________________________________ >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p… >> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click >> here. >> NAML >> >> >> >> ________________________________ >> View this message in context: Re: Pharo 6.0 and 6.1 64 bit freeze on >> MacMini >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 26, 2017

How to create a minimal image ?

by Dimitris Chloupis

I remember that the website used to link to a minimal image download but it does not seem there is one anymore Is still minimal image maintained ? Are there ways to make a image minimal ? Are there any tools for this job ? Is there any kind of documentation about this ?

Aug. 26, 2017

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

by Dimitris Chloupis

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

Re: [Pharo-users] Where do I find a Pillar syntax summary?

by Stephane Ducasse

the most up to date description is in the web perspective book and not much changed since then. We are picky when it is about the changing the syntax so it nearly did not change. Stef On Fri, Aug 25, 2017 at 10:55 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > At the moment my interest is to have a description of all the Pillar > syntax features Pharo 5 and 6 supports. > > a) in an example document > b) as a list > > As for Pillar syntax versions: > > I can imagine that there have been changes in the past. I just don't know. > And there might be changes in the future. So a version indication is > helpful even if it just says that Pharo 6 supports the same Pillar > version as it was in Pharo x (x = 2,3,4,5 ?). > > On 8/24/17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Good suggestion. >> Now I have no time for pillar per se. Now if you do it I will add it >> to pillar without hesitation. >> Tomorrow we will >> use bintray for all the projects to save the pdf (booklet, books). >> migrate the mooc to the makefile generator developed by luc. >> make sure that it works for Pillar 50 and 60. >> migrate other pillar projects to use the same. >> >> BTW we do not really want to have multiple version of the syntax. >> For example Pillar 50 and 60 are the same from a syntax point of view. >> >> On Thu, Aug 24, 2017 at 11:24 AM, H. Hirzel <hannes.hirzel(a)gmail.com> >> wrote: >>> Alistair, >>> >>> Thank you for the link to the Pillar syntax summary >>> >>> http://pillarhub.pharocloud.com/hub/pillarhub/pillarcheatsheet >>> >>> and the confirmation that the constructs there work in Pharo 6 & 7 for >>> basic cases. This is fine for me at the moment. >>> >>> >>> Stephan D >>> Thanks for being ready to check the full feature support in Pillar. >>> >>> A suggestion: >>> A new style sheet could come as well together with a test document >>> (with version indication included) for the Pillar parser. >>> >>> Then it is straightforward to determine if a particular Pillar >>> installation supports a particular Pillar markup version. >>> >>> The Pillar-Tests-PetitPillar package tests individual features but not >>> all in one go. If we have a test case which tests all features in one >>> go it has a triple function: >>> 1) It is a syntax summary of all features. >>> 2) It serves as a living documentation. >>> 3) It helps to determine if a particular pillar installation in an >>> image supports a particular Pillar version. >>> >>> --Hannes >>> >>> On 8/23/17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> +Handling all the cases: summing a die/die handle with a die/die >>>> handle >>>> .>file://figures/DieDoubleDispatchFull.pdf|width=70|label=figDieDoubleDispatchFull+ >>>> >>>> See Figure *@figDieDoubleDispatchFull* for internal ref is missing. >>>> >>>> Two Column is missing. I do not know it works in Latex. >>>> >>>> I will try to create one a new style sheet. >>>> >>>> >>>> On Wed, Aug 23, 2017 at 9:46 PM, Alistair Grant <akgrant0710(a)gmail.com> >>>> wrote: >>>>> On Wed, Aug 23, 2017 at 09:11:47PM +0200, H. Hirzel wrote: >>>>>> Thanks, it is useful. >>>>>> Date is 24 June 2014. >>>>>> Not sure if it is the latest version for what I have now in Pharo 6. >>>>>> >>>>>> --Hannes >>>>> >>>>> True, but it only covers the basic text mark-up and I don't think that >>>>> has changed recently. Anyway, I haven't found anything wrong with it >>>>> in >>>>> Pharo 6 & 7 (admittedly, with only basic pillar usage). >>>>> >>>>> Cheers, >>>>> Alistair >>>>> >>>>> >>>>>> On 8/23/17, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>> > How about: >>>>>> > >>>>>> > http://pillarhub.pharocloud.com/hub/pillarhub/pillarcheatsheet >>>>>> > >>>>>> > Cheers, >>>>>> > Alistair >>>>> >>>> >>>> >> >> >

Aug. 26, 2017

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

by Thierry Goubier

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] Pharo wiki , is here

by Offray Vladimir Luna CÃ¡rdenas

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