December 2017 - Pharo-users

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

by Stephane Ducasse

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_-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] Iceberg, Git and Package version

by Vitor Medina Cruz

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…>. <#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 Offray Vladimir Luna CÃ¡rdenas

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 Sean P. DeNigris

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 Offray Vladimir Luna CÃ¡rdenas

Thanks Peter, I will start my explorations here. Cheers, Offray On 30/12/17 12:06, Peter UhnÃ¡k wrote: > >Â I have argued time and again and in length about Markdown support in > Pharo > >Â Check the pillar markdown parser (not fully working). > > 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. > > >Â You confuse form and contents. > > 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. > > Cheers, > Peter > > On Sat, Dec 30, 2017 at 5:50 PM, Stephane Ducasse > <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > > Check the pillar markdown parser (not fully working). > This is the place to start having a working parser. > > Stef > > On Sat, Dec 30, 2017 at 3:29 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi, > > > > On 30/12/17 00:08, Dimitris Chloupis wrote: > > > > For me Pillar has been the most underused feature of Pharo by > far and it > > makes me sad how little we take advantage of this great technology. > > > > > > I have argued time and again and in length about Markdown > support in Pharo, > > so I will not do it again. I'll just repeat that, in order to > make Pharo > > less isolated, Git support for managing software source code has the > > strategic importance, in the same way that Markdown support for > managing > > documentation source code has strategic importance. This doesn't > preclude > > support for native/alternative DVCS in the software front > (Monticello, > > Fossil, etc) or markup languages in the documentation one > (Pillar, Dokuwiki, > > t2tags, etc). > > > > Pillar provides a feature set far longer and more important than > markdown > > but I think as a community we need to not only include Pillar > inside our > > standard distribution but built Pharo around it because itâs the > perfect > > nerve center that unites so many massively popular documentation > > technologies like Markdown , LaTex, PDF and the usual suspect HTML. > > > > The features are there. The only thing remaining is people using > them. > > > > > > Pandoc has a feature set far, far longer and more important that > Pillar and > > Markdown, including Yaml metadata blocks, fine grained > exportation control, > > ePub and a myriad of other output (an input) formats support > (see graphic > > below), a community that is mostly devoted to discuss > extensively/mainly a > > lightweight markup language for "full stack" documentation, > scholarly > > Markdown community for academic writing, annotated Markdown for > > collaborative editing and writing, programmable templates, > multilingual > > scripting support, including embedded one for Lua (which came > pretty handy > > to import our most recently publication[1][1a]). And thatÂ just > to mention > > some prominent features in the greater feature set that just > Pillar or > > Markdown provides. As community we need to not blind ourselves to > > alternatives and overcome the Not Invented Here Syndrome, to see > value in > > what is done outside Pharo for documentation in the same way we > have done > > for software management (specifically Git). > > > > A playground for Markdown will enhance Pandoc integration, which > we already > > have in Grafoscopio, but writing medium to long texts in it, > using the > > current plain text input objects support is cumbersome. Despite > that we have > > managed to have long book sized texts redone in Grafoscopio in > an agile way. > > The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb > PDF) in a > > single Grafoscopio notebook, stored under just a 600kb STON file > (and a 500 > > kb exported Markdown file). > > > > [1] > > > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog… > <http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog…> > > [1a] > > > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit… > <http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit…> > > [2] http://mutabit.com/repos.fossil/mapeda/ > <http://mutabit.com/repos.fossil/mapeda/> > > > > Several times, when I ask questions about Markdown, I'm pointed > towards the > > Pillar existence, and I reiterate/expand my motives for wanting > to implement > > *Markdown* support in Pharo. This exercise allow me to reiterate my > > questions in a more precise manner and hopefully this time > someone will > > point me to a starting place about how to create a "playground for > > Markdown". > > > > Cheers, > > > > Offray > > > > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna CÃ¡rdenas > > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > >> > >> Hi, > >> > >> Playgrounds are a really good way to write short snippets of > code and I > >> wonder if such experience could be extended for larger pieces of > >> Markdown. What I'm thinking of is have something similar butÂ > like this: > >> > >> 1. Support for Markdown instead of Smalltalk, including syntax > >> hightlighning and tab behavior (a tab equals two spaces). > >> > >> 2. Clicking on urls should load the respective web page. > Clicking on > >> images shouldÂ show an image preview. > >> > >> That's it, to start with. At some point it could be using GT > Documenter > >> previews, font support and so on. But I would like to start by > extending > >> the playground to just support this two features. Any advice > about where > >> can I start for the first feature? > >> > >> Thanks, > >> > >> Offray > >> > >> > >> > > > >

Dec. 30, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 30/12/17 11:47, Stephane Ducasse wrote: > Hello blind people > > You confuse form and contents. > May be you should try to understand. But you continue to get blind after all > everybody should carry its own cross and this is perfectly ok not to > try to understand. I could say the same about you, as continuously I have argued in favor of Pandoc's Markdown because of reasons that are not in competence with Pillar, but related with different ecosystems and features around it and I have talked about the coexistence of both. Once and again you ignore such points and reiterate yours. I understand the advantages of a native debugable solution (as I have argued), but is not because of that that I'm choosing Pandoc, and I have talked about implementing support for AST and other ways to improve *Pharo* documentation ecosystem by playing well with Pandoc. > > Pillar is not about syntax but about the text model and all the visitors. Yes. We have already talked about this several times. I understand that (see above or any of the talks where we have mention this). > We are working on a release of Pillar 70 but we are slow because busy > with other things. > Part of the effort is to redesign and remodularised the core model > since it grew too much with optional features. > But for that we needed to design the production pipeline and clean a > lot of problems (like relying on external bash files > and external servers, and saving mustache files while we can just use > stream and many more). I appreciate all that effort. > > Now where can I find a real robust parser of markdown written in Pharo > (with tests of course)? > I mean one that fully handles badly designed markdown? and one that I > can extend to support references and missing > things. I don't know. That was why I started where to start with. Peter already talked about CommonMark with tests support. > Because Pillar could use multiple input formats. Now I will not spend > MY time to write a parser. Why because I can write all the books > I want with Pillar and this is a "Soup of Stone" in Pillar dev. Again, is not about how youÂ or anyone in the community should invest your/his/her time. Is about how can I spent mine. I was asking directions to experiment on that. > > Repeat after me: the domain is more important than the syntax. The > proof is that pillar can generate > slides, book, ascii, epub, markdown (but apparently the one of git, > yes because they are multiple ones). HTML, static web sites .... I also understand that. Pandoc AST provide interesting abstractions of the documentation domain and that's why it can generate/read as much output/input formats. > > I personally do not want to be tight to any external frameworks like pandoc. > > Stef Totally understandable. I'm not pointed the only path anyone this community should follow. I'm showing other paths, for those interested, that (again!) can be parallel to the ones we have or are developing (as said in previous mails). > PS: for the record, pillar syntax was invented in 2000. So please stop > to bash us about not invented here because this syntax > was invented before markdown was well-known. So check your sources > before insulting people. Yes. You already told that when the Pillar/Markdown theme came out (but seems that our conversations about these themes restart to zero with any new comment about this). Not Invented Here Syndrome is not only about precedence, but about relluctancy to any external or alien. It's in that sense that I'm using the phrase and not as means to insult anyone. But a pretty good indicator of such syndrome is when people feel personally insulted just when any non-native solution/tech is bring into the table (for reasons mentioned several times). Cheers, Offray

Dec. 30, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

On 30/12/17 11:49, Stephane Ducasse wrote: > May be in pandoc community people helps each others. Sorry I could not resist. Yes. In that community they help each other. I was asking in *this* community about Markdown support on two specific issues *inside Pharo*. Some answers are coming on that front, after the classical deviation on why everybody should use Pillar for documentation, if wants to be part of this community. > > I want a system that we can maintain and debug. This is why we are > removing make and bash scripts from pillar. > Because this is not nice to fight with ugly generated bash files, believe me. > > stef > I believe you. I found much more easier to use Pandoc + Grafoscopio that Pillar + Grafoscopio, because of all those external dependencies. And I say this after reading the documentation of both and using one extensively not because of my prejudice against or in favor of a particular markup. I want also a system that I can debug and maintain and also play well with others. I think that having a more versatile playground is better, not worse, including supporting several syntax and markup languages. It seems not something against having such maintainable systems, but in favor of it. Cheers, Offray

Dec. 30, 2017

Regex negative look behind

by Steve Hayes

Hello - newbie question here. Is the regex implememtation meant to handle negative lookbehind, or is that out of scope? Something like (?<!-)\b[0-9]+ (which should not match negative integers) When I try to turn the string into a regex I'm getting a parsing error. If itâs out of scope, is there an alternative approach in Pharo? Thanks, Steve *Steve Hayes*

Dec. 30, 2017

Re: [Pharo-users] Is there a way to set form colours using a 'fuzzy' option?

by Stephane Ducasse

Nice I learned something :). Stef On Thu, Dec 28, 2017 at 11:42 PM, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > Nicolai wrote >>>> > > You can draw a new form with copybits and use your own color mapping. > > First, I thought there would be a bitblt operation that you could use > without explicit calculating the color mapping, a paint operation that > would convert a gray-value to an alpha value. But I could find it. > > In this special case (black text on white background) you can use an > existing method for calculating this color map. This method is used by > strike font to create apropriate glyph forms from its font bitmap. (A large > bitmap with black characters on a white background.) > > Here is an example that first, creates a form with black text on white > background, and than computes the color map and copys the source form in a > new form: > > "create a test form " > sourceForm := Form extent: 300@150 depth: 32. > sourceForm fillColor: Color white. > > "draw some black, bold text" > text := 'Hello World' asText. > text addAttribute: (TextFontReference toFont: (LogicalFont familyName: > 'Source Sans Pro' pointSize: 32)). > text addAttribute: (TextColor color: Color black). > text addAttribute: (TextEmphasis bold). > text asMorph drawOn: sourceForm getCanvas. > > "create a morph for displaying this form" > sourceImageMorph := ImageMorph withForm: sourceForm. > sourceImageMorph openInWorld; topLeft: 300@300. > > "calculate the colormap" > colorMap := Color computeColorConvertingMap: Color black from: 32 to: 32 > keepSubPixelAA: false. > > "copy the source form bits to a new form of the same size" > newForm := sourceForm deepCopy copyBits: sourceForm boundingBox from: > sourceForm at: 0@0 colorMap: (colorMap). > > "create a morph for displaying this form" > newImageMorph := ImageMorph withForm: newForm. > newImageMorph openInWorld; topLeft: 300@500. > > <<< > > Thanks Nicolai > That is very helpful. However, I agree with you that this is probably > something BitBlt should be able to handle. I have been looking at how they > do this in mathematica, and they have some interesting approaches. > > Cheers > Andy

Dec. 30, 2017

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

by Peter UhnÃ¡k

> I have argued time and again and in length about Markdown support in Pharo > Check the pillar markdown parser (not fully working). 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. > You confuse form and contents. 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. Cheers, Peter On Sat, Dec 30, 2017 at 5:50 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Check the pillar markdown parser (not fully working). > This is the place to start having a working parser. > > Stef > > On Sat, Dec 30, 2017 at 3:29 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: > > Hi, > > > > On 30/12/17 00:08, Dimitris Chloupis wrote: > > > > For me Pillar has been the most underused feature of Pharo by far and it > > makes me sad how little we take advantage of this great technology. > > > > > > I have argued time and again and in length about Markdown support in > Pharo, > > so I will not do it again. I'll just repeat that, in order to make Pharo > > less isolated, Git support for managing software source code has the > > strategic importance, in the same way that Markdown support for managing > > documentation source code has strategic importance. This doesn't preclude > > support for native/alternative DVCS in the software front (Monticello, > > Fossil, etc) or markup languages in the documentation one (Pillar, > Dokuwiki, > > t2tags, etc). > > > > Pillar provides a feature set far longer and more important than markdown > > but I think as a community we need to not only include Pillar inside our > > standard distribution but built Pharo around it because itâs the perfect > > nerve center that unites so many massively popular documentation > > technologies like Markdown , LaTex, PDF and the usual suspect HTML. > > > > The features are there. The only thing remaining is people using them. > > > > > > Pandoc has a feature set far, far longer and more important that Pillar > and > > Markdown, including Yaml metadata blocks, fine grained exportation > control, > > ePub and a myriad of other output (an input) formats support (see graphic > > below), a community that is mostly devoted to discuss extensively/mainly > a > > lightweight markup language for "full stack" documentation, scholarly > > Markdown community for academic writing, annotated Markdown for > > collaborative editing and writing, programmable templates, multilingual > > scripting support, including embedded one for Lua (which came pretty > handy > > to import our most recently publication[1][1a]). And that just to > mention > > some prominent features in the greater feature set that just Pillar or > > Markdown provides. As community we need to not blind ourselves to > > alternatives and overcome the Not Invented Here Syndrome, to see value in > > what is done outside Pharo for documentation in the same way we have done > > for software management (specifically Git). > > > > A playground for Markdown will enhance Pandoc integration, which we > already > > have in Grafoscopio, but writing medium to long texts in it, using the > > current plain text input objects support is cumbersome. Despite that we > have > > managed to have long book sized texts redone in Grafoscopio in an agile > way. > > The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a > > single Grafoscopio notebook, stored under just a 600kb STON file (and a > 500 > > kb exported Markdown file). > > > > [1] > > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/ > BibliotecaDigitalBogota/pasos-para-bidibog.pdf > > [1a] > > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/ > BibliotecaDigitalBogota/intro.md > > [2] http://mutabit.com/repos.fossil/mapeda/ > > > > Several times, when I ask questions about Markdown, I'm pointed towards > the > > Pillar existence, and I reiterate/expand my motives for wanting to > implement > > *Markdown* support in Pharo. This exercise allow me to reiterate my > > questions in a more precise manner and hopefully this time someone will > > point me to a starting place about how to create a "playground for > > Markdown". > > > > Cheers, > > > > Offray > > > > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna CÃ¡rdenas > > <offray.luna(a)mutabit.com> wrote: > >> > >> Hi, > >> > >> Playgrounds are a really good way to write short snippets of code and I > >> wonder if such experience could be extended for larger pieces of > >> Markdown. What I'm thinking of is have something similar but like this: > >> > >> 1. Support for Markdown instead of Smalltalk, including syntax > >> hightlighning and tab behavior (a tab equals two spaces). > >> > >> 2. Clicking on urls should load the respective web page. Clicking on > >> images should show an image preview. > >> > >> That's it, to start with. At some point it could be using GT Documenter > >> previews, font support and so on. But I would like to start by extending > >> the playground to just support this two features. Any advice about where > >> can I start for the first feature? > >> > >> Thanks, > >> > >> Offray > >> > >> > >> > > > >

Dec. 30, 2017