December 2017 - Pharo-users

Re: [Pharo-users] Is there a way to stop arrays sorting automatically?

by Ben Coman

On 31 December 2017 at 04:00, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > I suspect I am missing something very obvious, in which case could some > kind soul put me straight? > > I have the following code > > col := OrderedCollection new. > (1 to: 9) permutationsDo: [ :each | col add: (each )]. > > I thought this would give me a collection containing all the permutations. > However, what actually happens is that each of the arrays has been > 'magically' sorted back into numerical order. If I change the code to read > > col := OrderedCollection new. > (1 to: 9) permutationsDo: [ :each | col add: (each asOrderedCollection )]. > > Then the permutations are retained. Is this how it is supposed to work? > Or, am I doing something wrong? > > Cheers > Andy > Its not so much that your first example sorted the permutations, but that the collection contained only one permutation. I've swapped the order of your examples and downsized them to the simplest case to observe. Something seems broken. It works as expected if the "copy" is uncommented. Transcript clear. oc1 := OrderedCollection new. oc2 := OrderedCollection new. Transcript crShow:'a---'. (1 to: 3) permutationsDo: [ :each | Transcript crShow: each. oc1 add: each asOrderedCollection]. Transcript crShow:'b---'. (1 to: 3) permutationsDo: [ :each | Transcript crShow: each. oc2 add: each "copy"]. Transcript crShow:'c---'. Transcript crShow: { oc1 asSet size. oc2 asSet size}. Transcript crShow:'d---'. oc2 do: [ :x | Transcript crShow: x ]. ==> a--- #(1 2 3) #(1 3 2) #(2 1 3) #(2 3 1) #(3 2 1) #(3 1 2) b--- #(1 2 3) #(1 3 2) #(2 1 3) #(2 3 1) #(3 2 1) #(3 1 2) c--- #(6 1) d--- #(1 2 3) #(1 2 3) #(1 2 3) #(1 2 3) #(1 2 3) #(1 2 3) cheers -ben

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Sean P. DeNigris

Offray Vladimir Luna CÃ¡rdenas-2 wrote > no problem with adding *extra* support for Markdown > (not killing Pillar) :-). Go, go, go!! It seems clear (from this thread and others) that the important thing about Pillar is the /model/, not the syntax. Since it now also seems clear that no one is asking the Pillar devs to do the work, how could facilities to import/export other formats do anything but support whatever we are trying to achieve with Pillar? The reality is that there is a wealth of information already in other common formats. It seems obvious that we would want to have access! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 30/12/17 16:28, Stephane Ducasse wrote: > Can you explain to me the abstractions you mention about pandoc > because I'm curious? I think that the best places to start are the Filters documentation[1] and the Pandoc types package [2]. They essentially show how Pandoc provides structures to build a document programmaticaly including reading, exporting and manipulate it. Filters are explained in Haskell, but the documentation shows how you can use other languages to access the doc programmability. [1] http://pandoc.org/filters.html#summary [2] https://hackage.haskell.org/package/pandoc-types Quoting from the filters Summary: """ Pandoc consists of a set of readers and writers. When converting a document from one format to another, text is parsed by a reader into pandocâs intermediate representation of the documentâan âabstract syntax treeâ or ASTâwhich is then converted by the writer into the target format. The pandoc AST format is defined in the module |Text.Pandoc.Definition| in pandoc-types <https://hackage.haskell.org/package/pandoc-types>. A âfilterâ is a program that modifies the AST, between the reader and the writer: |INPUT --reader--> AST --filter--> AST --writer--> OUTPUT| Filters are âpipesâ that read from standard input and write to standard output. """ > > BTW you did not say: > Ok guys I want to write a Markdown parser (to contribute to > pillar, which would be cool.) > You said I want to have a playground to edit markdown. This is > quite different to me. Because the second thing (Markdown support inside the Playground) is the one I want to contribute to Pharo(!), not to Pillar. Contributing should not be so hard, but each time I bring this theme is an uphill battle in just getting the initial exploration questions answered (because they're about Markdown and not about Pillar). I think that Markdown support in Pharo is healthy for Pharo and a meaningful learning experience for me. At least I should be able to test that by myself in this community with a little of support like "hey we have CommonMark inside PettitParser" or "here is how you increase the Playground Syntax support, by specializing this class".Â > About the not invented syndrome remarks, why then don't we drop Pharo? > Now if each time we want to install pharo we should install Python, > why not installing lua and Ruby and a bit of Javascript in case. Because is not an all or nothing proposal and it has never been. It's about Pharo *playing well with* others, not about *being replaced by* others. I don't see any worth in taking this stuff to the extremes. When someone advise me Pharo, I don't think that he/she is advising me to drop my operative system and to run Pharo from bare metal because you go the Pharo way or the No Way(!). > > You are under estimating the effort that we put in Pillar. We > extracted pillar from pier to be able to have an autonomous document > system with which we can write good pdf and good HTML for > documentation point of view. Because people did not like to write in > LaTeX. > Now if we would stop something each time somebody mention something > else we would be doing python, Javascript or ... > all the time. I don't underestimate anyone's work. Nor in Pillar, nor in Pharo, nor in Pandoc. In fact trying to make them work better together and giving back to this community by making software with Pharo and teaching people Pharo (for free) are clear examples of my appreciation for the work done in several fronts, inside and outside Pharo. The choice of LaTeX and HTML in your case, shows practical appreciation for those formats and I don't think that we should reimplement them in Pharo (despite of several advantages of live objects as documents instead of dead-files). Instead of putting valuations I have never done on me, I would advice to try seeing worth in the reasons behind a lot of people outside this community is using (Pandoc's) Markdown for documentation and the added value that adding Markdown support brings by having more people exposed to Pharo ecosystem, ideas, community, values and technology. > So yes I'm dense and I focus on my stuff and my stuff is Pharo. > And yes I do not care about pandoc because I want to write my > exporters and tools in Pharo and I will fight for that. But we don't need to fight for that. I value your decisions and work and I think that is healthy to ask for reciprocity and build from that, instead of wasting time because we don't think the same. Diversity is healthy in a community. The only thing I'm asking for (besides such reciprocity) is pointers to start *my* exploration. > > This is why I want to use Scale instead of *&%*^)&%^ bash. > And this is why I spent most of time trying to improve Pharo because > it is not at the level I want but I can contribute > and make it better. > > Stef > I don't use bash or Json config files for anything related with documentation in Grafoscopio. Just plain Pharo inside an interactive "%metadata" playground node in the Grafoscopio notebook. Spoon, Coral, Scale, would be welcomed when integration with them is ready. I spent good time also trying to make my contributions and improvements to Pharo. We don't need to fight because our ways of contribution are different. Cheers, Offray

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

Thanks Glenn. It's nice to know that this community has at least 3 members that have no problem with adding *extra* support for Markdown (not killing Pillar) :-). I see that many of your examples come from scientific computing environments (R, Jupyter, Stata). If you're interested in reproducible research with Markdown support in Pharo, you could check Grafoscopio [1]. We have made complete books contained in a single Grafoscopio notebook (see [2]) thanks to the outline capabilities we have in the notebook. It's a feature I have not seen in other scientific computing systems, including Mathematica, Jupyter, R, and I'm aware of being available only on Org Mode and Leo Editor (and of course, Grafoscopio). Having complex (book size) documents organized in single diff-friendly files is very powerful. The integration of Pandoc's Markdown and interactive playgrounds in the Grafoscopio interactive notebooks create a unique computing experience. And because of the self-referential properties of the environment we can put all metadata inside the notebook, as playgrounds of Pharo dictionaries. We don't even use external bash or json config files and all the information for creating a particular output, including external commands are all expressed using just Pharo code. This is how we're creating the (Grafoscopio backed) books & publications. [1] http://mutabit.com/grafoscopio/index.en.html [2] http://mutabit.com/repos.fossil/mapeda/ I think that Smalltalk systems are pretty well suited for reproducible research, because of their self-contained nature and the image concept that allow you to "freeze" a whole computing environment and recover it intact decades later (as we discussed/exemplified in a couple of threads[3][4] recently) and this will be a hot topic in upcoming research on several fronts (science, journalims, activism, etc). This will be improved with Pharo 7 and the possibility to bootstrap the environment from a zero stage. Now imagine if that could be coupled with functional package managers (Chocolatey, Nix, Guix) and a widespread and used light markup language. It could bring a lot of worthy and diverse people to Pharo. It has already done that in a little scale at our local hackerspace [5]. I just want to start with proper support for Markdown inside a more diverse language aware Playground (and helping to build it). [3] https://twitter.com/khinsen/status/938719570235482112 [4] https://twitter.com/khinsen/status/938801977462591490 [5] http://mutabit.com/dataweek/ So yes, the past, present and current efforts for Pillar and Markdown support are worthy and opening a really interesting scenario. Cheers, Offray On 30/12/17 16:41, Glenn Hoetker wrote: > Offray et al, > > Cheers to all who want to add more Markdown capabilities to Pharo. As a relatively new user who thinks Pharo is one of the coolest systems on Earth, I would love to see such. I donât think it is a coincidence that so many new apps/language/etc. brag about Markdown capabilities (e.g., R lets you write Markdown, Stataâa stats DSLâhas increased its Markdown capabilities, Jupyter Notebook/Lab has Markdown cells to make writing reproducible analyses easier, Appleâs Swift has added Markdown-derived documenting features, the iThought mind-mapping program uses Markdown for formatting, etc.). Despite the diversity of flavors and certain limitations, Markdown has (Markdowns have??) clearly become a lingua franca for the larger programming community. Other humane markup systems like ReStructuredText seem to be more narrow in appeal (e.g., RST in Python). My personal hunch is that popularity comes from its ease to write, read as plain text and process using any toolchain aimed at plain text. > > Many of the things Iâve come to love about Pharoâimages, coding and browsing in the System Browser, the versioning systemâare, frankly, barriers to entry for the novice. Taking Pillarâs strengths and role in making Pharo more self-contained as given, it is still one more barrier to entry. How great it would be to provide an easier entry path via Markdown, even if we expect/hope folks will move to Pillar when they need more and have built up some overall comfort!!! > > Also, the GFM dialect of Markdown is a key part of the Github ecosystem. So, Markdown would seem to have at least symbolicâand perhaps practicalâsynergies with efforts to integrate with Git. > > Of somewhat less importance, there is an image factor. I personally havenât seen tremendous value in having a Markdown parser in Python, Swift, GoLang, Racket, etc., but it seems like every language except COBOL and, maybe, BrainF**k now has a Markdown parser. > > Lastly, I sense a concern that Markdown might displace Pillar for many users, draining energy away from it. On the one hand, that would indicate that it was better serving the needs of, say, 80% of the users despite being less capable than Pillar. On the other hand, what to do for the remaining 20% is a legitimate concern. On the third hand, letting the perfect be the enemy of the good often doesnât work out well. > > Which dialect of Markdown gets used seems less important than being able to handle **a** dialect, whichever it is. If Offray is going to do the work, seems like it is his choice. (That said, Iâm *really* fond of the Pandoc dialect, even if GFM is most synergistic with Git-ward momentum.) > > Many thanks to all for their past, current and future efforts on both Markdown and Pillar. > > Glenn > > > Sent from my iPad > >> On Dec 30, 2017, at 1:18 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Sean, >> >> I don't think there is any conflict between having Pillar and Markdown >> support inside Pharo. I tried to explain myself as many times as I can, >> but time and again when Markdown gets mentioned, the next is "we already >> have Pillar" and then a holy war restarts because someone wants another >> markup system supported. All the old arguments for Pillar are mentioned >> and all about (Pandoc's) Markdown ignored and we, the community, rinse >> an repeat as a broken record. >> >> At least this time I know about support existing CommonMark. So maybe in >> 100 to 1000 iterations more of the above community cycle, we could have >> a versatile playground supporting at least two documentation markup >> systems and will be closer to a rich text/document editor system on Pharo. >> >> Cheers, >> >> Offray >> >> >>> On 30/12/17 14:58, Sean P. DeNigris wrote: >>> Stephane Ducasse-3 wrote >>>> Pillar is not about syntax but about the text model and all the visitors. >>> Ah! Good to know. I was also confused on this point. Since we don't yet have >>> a rich text editor, I only ever see static markup and static exports. I >>> should take a deeper look. >>> >>> That said, is there really a conflict with what Offray is saying/doing? IIUC >>> he wants to create a Markdown parser, which presumable could be used to >>> import into the Pillar model (I would assume when the tools become >>> attractive enough to encourage this) and back out to Markdown for >>> interoperability, no? Or am I missing something? >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >> >

Dec. 30, 2017

Re: [Pharo-users] Iceberg, Git and Package version

by Vitor Medina Cruz

Hi Stef For example, my project can depend on Iceberg using the following definition: spec baseline: 'Iceberg' with: [ spec repository: > 'github://pharo-vcs/iceberg/:<someversion>' ]; But now suppose my project have one package that depends on Iceberg "minimal" and other that depends on the "default" group, how do I describe that in my baseline? Using project:with I can define two different names for the same dependency but in different version or group. For example, I could define "Iceberg Minimal" project that loads the "minimal" group and another "Iceberg Default" that loads the "default"group and then refer to them by name, right? I would like to know how to do that with projects from Iceberg (git) that defines only BaselineOf. On Sat, Dec 30, 2017 at 7:12 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi vitor > > I'm sorry but I do not understand your question? can you rephrase it and > give an example? > > Stef > > On Sat, Dec 30, 2017 at 10:03 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Hello Stephane >> >> What if I want to define two projects for the same baseline: both >> pointing to different groups? >> >> >> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Livre >> de vÃrus. www.avg.com >> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>. >> >> <#m_-6869378333471435460_m_-7133589263725951599_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> From a baseline you can refer to a none github configuration >>> >>> here is an example from the pillar newpipeline dev branch it shows you >>> both: dependencies on github projects and smalltalkhub >>> >>> >>> baseline: spec >>> <baseline> >>> spec >>> for: #common >>> do: [ spec blessing: #baseline. >>> spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main/'. >>> spec >>> baseline: 'OSSubprocess' >>> with: [ spec >>> repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ]; >>> >>> baseline: 'Mustache' >>> with: [ spec repository: 'github://noha/mustache:v1.0/repository' >>> ]; >>> >>> project: 'Cocoon' >>> with: [ spec >>> className: #ConfigurationOfCocoon; >>> versionString: #stable; >>> repository: 'http://smalltalkhub.com/mc/PharoExtras/Cocoon/main' ]; >>> >>> project: 'JSON' >>> with: [ spec >>> className: #ConfigurationOfJSON; >>> versionString: #stable; >>> repository: >>> 'http://smalltalkhub.com/mc/PharoExtras/JSON/main/' ]; >>> >>> >>> project: 'LightPhaser' >>> with: [ spec >>> className: #ConfigurationOfLightPhaser; >>> versionString: '1.0.2'; >>> repository: 'http://smalltalkhub.com/mc/Pier/LightPhaser/main/' ]; >>> project: 'PetitParser' >>> with: [ spec >>> className: #ConfigurationOfPetitParser; >>> versionString: #stable; >>> loads: #('Tests'); >>> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ]; >>> project: 'PetitParserTest' >>> with: [ spec >>> className: #ConfigurationOfPetitParser; >>> versionString: #stable; >>> loads: #('Tests'); >>> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ]. >>> spec >>> package: 'Pillar-Cli' with: [ spec requires: #('Pillar-ExporterCore') ]; >>> package: 'Pillar-Cli-PillarVersion' with: [ spec requires: >>> #('Pillar-Cli') ]; >>> package: #'Pillar-ExporterAsciiDoc' >>> >>> >>> >>> On Thu, Dec 21, 2017 at 3:48 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >> This is mostly true, but ATM you may want to wrap your BaselineOf in a >>> >> ConfigurationOf (i.e. refer to A with a SHA from B) for tool >>> integration >>> >> e.g. only Configs show up in the catalog. IIUC, one additional >>> constraint >>> >> to >>> >> be aware of (not sure how important it is in practice) is that in the >>> past >>> >> with mcz repos, one could refer to a specific version of each >>> package, but >>> >> now you would only be able to specify a version for the whole git >>> repo. >>> > >>> > >>> > I was about to ask that after reading through Metacello docs â While I >>> find >>> > usefull to define groups and dependencies at package level (I need only >>> > package A from ThatProject on version 2.6, cool!), I didn't understand >>> why >>> > define version at package level.... If many dependencies exists to >>> different >>> > versions of different packages belonged to the same project, doesn't >>> that >>> > means (or is an indicative) that those packages should be separeted in >>> > different projects? I don't think this constraint will be a problem. >>> > >>> > >>> > On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris < >>> sean(a)clipperadams.com> >>> > wrote: >>> >> >>> >> CyrilFerlicot wrote >>> >> >> Now I got lost >>> >> >>> >> A ConfigurationOfXyz was doing two things: >>> >> 1) Declaring the project structure of packages and their dependencies >>> in a >>> >> #baselineXyz: method >>> >> 2) Tagging specific sets of package versions with meaning symbolic to >>> the >>> >> project e.g. 1.2 or stable or whatever >>> >> >>> >> >>> >> CyrilFerlicot wrote >>> >> > So, you just need Metacello to manage the dependencies... This is >>> what >>> >> > BaselineOf do. You just manage the dependencies part and >>> >> > not the versionning part that is already managed by git. >>> >> >>> >> A BaselineOfXyz is very similar to what configurations did for #1, >>> with a >>> >> few simplifications (e.g. you don't need to declare the method a >>> >> "baseline" >>> >> or specify a repo because you obviously already know the repo because >>> >> that's >>> >> where you just got the baseline itself) >>> >> >>> >> >>> >> CyrilFerlicot wrote >>> >> > The equivalent of a ConfigurationOf version in now the SHA of a >>> commit >>> >> > or >>> >> > a tag/release >>> >> > of git). >>> >> >>> >> This is mostly true, but ATM you may want to wrap your BaselineOf in a >>> >> ConfigurationOf (i.e. refer to A with a SHA from B) for tool >>> integration >>> >> e.g. only Configs show up in the catalog. IIUC, one additional >>> constraint >>> >> to >>> >> be aware of (not sure how important it is in practice) is that in the >>> past >>> >> with mcz repos, one could refer to a specific version of each >>> package, but >>> >> now you would only be able to specify a version for the whole git >>> repo. >>> >> >>> >> HTH >>> >> >>> >> >>> >> >>> >> ----- >>> >> Cheers, >>> >> Sean >>> >> -- >>> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> >>> > >>> >>> >> >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Kjell Godo

And yes I do not care about pandoc because I want to write my exporters and tools in Pharo and I will fight for that. +1

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Glenn Hoetker

Offray et al, Cheers to all who want to add more Markdown capabilities to Pharo. As a relatively new user who thinks Pharo is one of the coolest systems on Earth, I would love to see such. I donât think it is a coincidence that so many new apps/language/etc. brag about Markdown capabilities (e.g., R lets you write Markdown, Stataâa stats DSLâhas increased its Markdown capabilities, Jupyter Notebook/Lab has Markdown cells to make writing reproducible analyses easier, Appleâs Swift has added Markdown-derived documenting features, the iThought mind-mapping program uses Markdown for formatting, etc.). Despite the diversity of flavors and certain limitations, Markdown has (Markdowns have??) clearly become a lingua franca for the larger programming community. Other humane markup systems like ReStructuredText seem to be more narrow in appeal (e.g., RST in Python). My personal hunch is that popularity comes from its ease to write, read as plain text and process using any toolchain aimed at plain text. Many of the things Iâve come to love about Pharoâimages, coding and browsing in the System Browser, the versioning systemâare, frankly, barriers to entry for the novice. Taking Pillarâs strengths and role in making Pharo more self-contained as given, it is still one more barrier to entry. How great it would be to provide an easier entry path via Markdown, even if we expect/hope folks will move to Pillar when they need more and have built up some overall comfort!!! Also, the GFM dialect of Markdown is a key part of the Github ecosystem. So, Markdown would seem to have at least symbolicâand perhaps practicalâsynergies with efforts to integrate with Git. Of somewhat less importance, there is an image factor. I personally havenât seen tremendous value in having a Markdown parser in Python, Swift, GoLang, Racket, etc., but it seems like every language except COBOL and, maybe, BrainF**k now has a Markdown parser. Lastly, I sense a concern that Markdown might displace Pillar for many users, draining energy away from it. On the one hand, that would indicate that it was better serving the needs of, say, 80% of the users despite being less capable than Pillar. On the other hand, what to do for the remaining 20% is a legitimate concern. On the third hand, letting the perfect be the enemy of the good often doesnât work out well. Which dialect of Markdown gets used seems less important than being able to handle **a** dialect, whichever it is. If Offray is going to do the work, seems like it is his choice. (That said, Iâm *really* fond of the Pandoc dialect, even if GFM is most synergistic with Git-ward momentum.) Many thanks to all for their past, current and future efforts on both Markdown and Pillar. Glenn Sent from my iPad > On Dec 30, 2017, at 1:18 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Sean, > > I don't think there is any conflict between having Pillar and Markdown > support inside Pharo. I tried to explain myself as many times as I can, > but time and again when Markdown gets mentioned, the next is "we already > have Pillar" and then a holy war restarts because someone wants another > markup system supported. All the old arguments for Pillar are mentioned > and all about (Pandoc's) Markdown ignored and we, the community, rinse > an repeat as a broken record. > > At least this time I know about support existing CommonMark. So maybe in > 100 to 1000 iterations more of the above community cycle, we could have > a versatile playground supporting at least two documentation markup > systems and will be closer to a rich text/document editor system on Pharo. > > Cheers, > > Offray > > >> On 30/12/17 14:58, Sean P. DeNigris wrote: >> Stephane Ducasse-3 wrote >>> Pillar is not about syntax but about the text model and all the visitors. >> Ah! Good to know. I was also confused on this point. Since we don't yet have >> a rich text editor, I only ever see static markup and static exports. I >> should take a deeper look. >> >> That said, is there really a conflict with what Offray is saying/doing? IIUC >> he wants to create a Markdown parser, which presumable could be used to >> import into the Pillar model (I would assume when the tools become >> attractive enough to encourage this) and back out to Markdown for >> interoperability, no? Or am I missing something? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > > >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Peter UhnÃ¡k

> > On Sat, Dec 30, 2017 at 10:15 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > >> Jan Kurs made an extensive petitparser for CommonMark with tests and > >> everything... it is not complete but it had support for most common > stuff. > >> So the best approach would be two write a visitor on top of this parser > to > >> output Pillar document model. > > > > Good to know. I will see if we can ask students to do something we > > have a lecture that starts first week or we could ask asbath. > > (why a visitor? you mean that he already has production rules that > > outputs a tree?). > There was a visitor that produced HTML from the markdown, so the same could be done to produce pillar. > > > > > >> Stef, would it make sense to name them differently? > >> E.g. "Pillar" is the syntax and "Pier" the model (or some other name). > >> Maybe it could reduce the confusion, and improve the dialog surrounding > it. > >> Because people use same word when then mean different things. > > > > I do not have the energy for that. > > Pharo it is the system or the syntax? > I tend to call "Pharo" the system, and "Smalltalk language" the syntax.

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

Can you explain to me the abstractions you mention about pandoc because I'm curious? BTW you did not say: Ok guys I want to write a Markdown parser (to contribute to pillar, which would be cool.) You said I want to have a playground to edit markdown. This is quite different to me. About the not invented syndrome remarks, why then don't we drop Pharo? Now if each time we want to install pharo we should install Python, why not installing lua and Ruby and a bit of Javascript in case. You are under estimating the effort that we put in Pillar. We extracted pillar from pier to be able to have an autonomous document system with which we can write good pdf and good HTML for documentation point of view. Because people did not like to write in LaTeX. Now if we would stop something each time somebody mention something else we would be doing python, Javascript or ... all the time. So yes I'm dense and I focus on my stuff and my stuff is Pharo. And yes I do not care about pandoc because I want to write my exporters and tools in Pharo and I will fight for that. This is why I want to use Scale instead of *&%*^)&%^ bash. And this is why I spent most of time trying to improve Pharo because it is not at the level I want but I can contribute and make it better. Stef On Sat, Dec 30, 2017 at 10:15 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Jan Kurs made an extensive petitparser for CommonMark with tests and >> everything... it is not complete but it had support for most common stuff. >> So the best approach would be two write a visitor on top of this parser to >> output Pillar document model. > > Good to know. I will see if we can ask students to do something we > have a lecture that starts first week or we could ask asbath. > (why a visitor? you mean that he already has production rules that > outputs a tree?). > > >> Stef, would it make sense to name them differently? >> E.g. "Pillar" is the syntax and "Pier" the model (or some other name). >> Maybe it could reduce the confusion, and improve the dialog surrounding it. >> Because people use same word when then mean different things. > > I do not have the energy for that. > Pharo it is the system or the syntax?

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

> Jan Kurs made an extensive petitparser for CommonMark with tests and > everything... it is not complete but it had support for most common stuff. > So the best approach would be two write a visitor on top of this parser to > output Pillar document model. Good to know. I will see if we can ask students to do something we have a lecture that starts first week or we could ask asbath. (why a visitor? you mean that he already has production rules that outputs a tree?). > Stef, would it make sense to name them differently? > E.g. "Pillar" is the syntax and "Pier" the model (or some other name). > Maybe it could reduce the confusion, and improve the dialog surrounding it. > Because people use same word when then mean different things. I do not have the energy for that. Pharo it is the system or the syntax?

Dec. 30, 2017