- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec new release :)

by Benjamin

Have a look at http://jgm.github.io/lunamark/ :) It may be a dirty hack, that I do not know :) Ben On 13 Nov 2013, at 20:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 13 Nov 2013, at 20:22, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> On 13 Nov 2013, at 20:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>> >>>> It was a real question, and it feels like you overreacted the answer â¦ >>>> >>>> To me, markdown or pier is a new syntax to learn so I am asking â¦ >>>> To me, doing Pier because you do or because you said to is no really an argument. >>>> >>>> Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) >>>> and that a lot of people knows about markdown. >>>> >>>> This was a real question, not a troll â¦ >>> >>> I like .md as well and yes, the github integration makes it compelling. >>> >>> But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books. >>> >>> There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version). >> >> Ok :) >> But as an end user, do you feel the difference ? > > I know, but the documentation is meant to be integrated in the Pharo ecosystem. > > It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦ > >> There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) >> then one could generate Pier format out of markdown :) > > So indeed, that is what we need. [And what we already have for Pier]. > But be sure to ask Camillo how his 2 attempts went before you get ambitious. > I look at the PP MD code and thought, I can do better, but after writing some actual code, I stopped ;-) > > BTW, please point me to grammar, I never found one ! Each MD parser is one big hack. > >> Ben >> >>> >>>> Ben >>>> >>>> On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> do you really think that I insist of using pier syntax because >>>>> A- I want to lose my time >>>>> B- this is for my ego? >>>>> C- because I'm funny >>>>> D- ... >>>>> >>>>> No seriously? >>>>> >>>>> If you want to get an answer read the thread that yuri raised a while ago. >>>>> Because we already discussed discussed and discussed it. >>>>> >>>>> I will not write any book in markdown. Now you can try and we see. >>>>> >>>>> Stef >>>>> >>>>>> Stef, what is the advantages of writing it in Pier compared to markdown ? >>>>>> >>>>>> Ben

Nov. 14, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

On 13 Nov 2013, at 21:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦ > > With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. > Now one step at a time. > >>> There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) >>> then one could generate Pier format out of markdown :) > > What most of you do not get is that. But I do not care about Pier format. I care about a REAL solution that can produce a REAL document tree AND that ***I*** can edit and maintain and enhance so that I can create books. So why not extending markdown then ? Ben > So I'm pragmatic we wrote the seaside book with pier so I took pier because I do not want to write a MD parser and building model > and reinventing the wheel. And I do not want to have to learn a new language just to make sure that I can write books. > > Stef > >

Nov. 14, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

That would be appreciated :) Ben On 13 Nov 2013, at 21:18, kilon alios <kilon.alios(a)gmail.com> wrote: > Stephane I think you need to sit down and write the Guidelines for Pharo Documentation, explaining the tools, the workflow, the goals, the principles and most importantly where documentation can be found. Post it on pharo website. This way you will save a lot of time from answering questions here . So next time someone asks a relevant question you only post a link to it. > > > > > On Wed, Nov 13, 2013 at 9:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > Why not generating markdown code from pier code? > > If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? > > I did => suicidal tendencies. > The results looks like shit. > > I did not try pdf2html. > > Now pier is a compromise so that normal people can write chapter without being a latex freaks like us. > > Stef > > > > Maybe my question is naive, I do not know. > > > > On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files. > > > > Alexandre > > > > > > On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> > >> On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> > >>> It was a real question, and it feels like you overreacted the answer â¦ > >>> > >>> To me, markdown or pier is a new syntax to learn so I am asking â¦ > >>> To me, doing Pier because you do or because you said to is no really an argument. > >>> > >>> Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) > >>> and that a lot of people knows about markdown. > >>> > >>> This was a real question, not a troll â¦ > >> > >> I like .md as well and yes, the github integration makes it compelling. > >> > >> But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books. > >> > >> There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version). > >> > >>> Ben > >>> > >>> On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> > >>>> do you really think that I insist of using pier syntax because > >>>> A- I want to lose my time > >>>> B- this is for my ego? > >>>> C- because I'm funny > >>>> D- ... > >>>> > >>>> No seriously? > >>>> > >>>> If you want to get an answer read the thread that yuri raised a while ago. > >>>> Because we already discussed discussed and discussed it. > >>>> > >>>> I will not write any book in markdown. Now you can try and we see. > >>>> > >>>> Stef > >>>> > >>>>> Stef, what is the advantages of writing it in Pier compared to markdown ? > >>>>> > >>>>> Ben > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Nov. 14, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

On 13 Nov 2013, at 20:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Why not generating markdown code from pier code? >> If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? > > I did => suicidal tendencies. > The results looks like shit. > > I did not try pdf2html. > > Now pier is a compromise so that normal people can write chapter without being a latex freaks like us. > > Stef Thatâs also the thing, md is designed in a (shitty) way so one does not have to âlearnâ it since itâs is âcloseâ to what one will write in an email Ben > > >> Maybe my question is naive, I do not know. >> >> On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files. >> >> Alexandre >> >> >> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>> >>>> It was a real question, and it feels like you overreacted the answer â¦ >>>> >>>> To me, markdown or pier is a new syntax to learn so I am asking â¦ >>>> To me, doing Pier because you do or because you said to is no really an argument. >>>> >>>> Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) >>>> and that a lot of people knows about markdown. >>>> >>>> This was a real question, not a troll â¦ >>> >>> I like .md as well and yes, the github integration makes it compelling. >>> >>> But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books. >>> >>> There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version). >>> >>>> Ben >>>> >>>> On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> do you really think that I insist of using pier syntax because >>>>> A- I want to lose my time >>>>> B- this is for my ego? >>>>> C- because I'm funny >>>>> D- ... >>>>> >>>>> No seriously? >>>>> >>>>> If you want to get an answer read the thread that yuri raised a while ago. >>>>> Because we already discussed discussed and discussed it. >>>>> >>>>> I will not write any book in markdown. Now you can try and we see. >>>>> >>>>> Stef >>>>> >>>>>> Stef, what is the advantages of writing it in Pier compared to markdown ? >>>>>> >>>>>> Ben >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

Nov. 14, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

On 13 Nov 2013, at 20:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > So read the thread that yuriy rasied last week > my sumarry > - write in pier > publish in latex, html, markdong âmarkdongâ ? thatâs a chinese variant :P For md, there is pandoc (http://johnmacfarlane.net/pandoc/) it converts a lot of format into a lot of other formats :) > - too many variation of markdown > - do not want to ask in haskell, rubyâ¦ to extend libraries I do not get it > - markdown does not support references and other essential points for making decent books What do you mean by "references and other essential pointsâ ? Ben > > Stef > > > On Nov 13, 2013, at 7:59 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> It was a real question, and it feels like you overreacted the answer â¦ >> >> To me, markdown or pier is a new syntax to learn so I am asking â¦ >> To me, doing Pier because you do or because you said to is no really an argument. >> >> Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) >> and that a lot of people knows about markdown. >> >> This was a real question, not a troll ... >> >> Ben >> >> On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> do you really think that I insist of using pier syntax because >>> A- I want to lose my time >>> B- this is for my ego? >>> C- because I'm funny >>> D- ... >>> >>> No seriously? >>> >>> If you want to get an answer read the thread that yuri raised a while ago. >>> Because we already discussed discussed and discussed it. >>> >>> I will not write any book in markdown. Now you can try and we see. >>> >>> Stef >>> >>>> Stef, what is the advantages of writing it in Pier compared to markdown ? >>>> >>>> Ben >>>> >>> >>> >> >

Nov. 14, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

I ask Damien Cassou this morning about that. He told me it should be quite easy to do :) (just another visitor I guess) Ben On 13 Nov 2013, at 20:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 13 Nov 2013, at 20:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Why not generating markdown code from pier code? >> If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? Maybe my question is naive, I do not know. > > It is not silly, and yes it could be done quite easily I guess, if it even has not yet been done already. > >> On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files. >> >> Alexandre >> >> >> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>> >>>> It was a real question, and it feels like you overreacted the answer â¦ >>>> >>>> To me, markdown or pier is a new syntax to learn so I am asking â¦ >>>> To me, doing Pier because you do or because you said to is no really an argument. >>>> >>>> Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) >>>> and that a lot of people knows about markdown. >>>> >>>> This was a real question, not a troll â¦ >>> >>> I like .md as well and yes, the github integration makes it compelling. >>> >>> But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books. >>> >>> There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version). >>> >>>> Ben >>>> >>>> On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> do you really think that I insist of using pier syntax because >>>>> A- I want to lose my time >>>>> B- this is for my ego? >>>>> C- because I'm funny >>>>> D- ... >>>>> >>>>> No seriously? >>>>> >>>>> If you want to get an answer read the thread that yuri raised a while ago. >>>>> Because we already discussed discussed and discussed it. >>>>> >>>>> I will not write any book in markdown. Now you can try and we see. >>>>> >>>>> Stef >>>>> >>>>>> Stef, what is the advantages of writing it in Pier compared to markdown ? >>>>>> >>>>>> Ben >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

>>> It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦ >> >> With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. > > What has this to do with athens? I want really nice font so this is not really related to athens and was confused. > We already have a prototype implementation with Markdown using the existing text model. Worked already fine, so that should be 1 afternoon of work to get the pier syntax running in the current image. Where it is? that we add it to our todo? because having a real domain model (which we have) is the way to go. I do not want to hack stuff. Now we ***HAVE*** a fully working pier parser and creating domain and we ARE enhancing it already. Stef

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

Of course, since this is a question of style, all was invented way before the computer era :) https://en.wikipedia.org/wiki/Metonymy#Synecdoche 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > These are really excellent arguments, Nicolas. Good discussion. > > On Wed, Nov 13, 2013 at 3:32 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Chris, > > I have to completely disagree. > > The idea of breaking a complex object into simpler parts is not just > > theories and extremism. > > Assigning several roles to an object is sometimes convenient for a start, > > but generally does scale very badly. > > It's a collective experience driven by pragmatic considerations in > > developping in all sort of languages. > > And it's my own experience too. > > > > A file is like the container, the stream is about reading/writing the > > contents. > > I think I remember the confusion was made at the beginning in st-80, > because > > it was simple enough at that time. > > So it's rather an historical slag, not something that was added later for > > this special case. > > And it is something that should have been revised, because when we added > > pipes, sockets or other external streams, that ruined the idea of > confusing > > the two things into a not well delimited blob without clear > > responsibilities. > > Though we kept the original implementation and started to distort the > > package by adding faked polymorphism like name ^'john doe'. > > > > Clearly, I need no stream on its contents to rename a file, query its > > permissions, or delete it, so why bother with internal states of a > stream if > > I'm interested in handling the file? > > If I am interested about the contents, I don't need to ever know about > the > > path of the file nor its name, or shall I change a $A read from it into > a $B > > if the file is named 'turnAllAinB'? > > > > Where exactly are we going to need this encapsulated blob which pretend > to > > be both a file and a stream? I would be happy to show that a rewrite is > both > > simple and good looking at end application sites. > > Of course, inside the lava of multi year hacked stream hierarchy, it > might > > be a bit less obvious to disentangle the spaghetti. > > Hence more radical solutions: table rase and complete rewrite. > > > > > > > > > > > > 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > >> > >> On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier > >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > Exactly, every specialized stream has its specialized API and/or > >> > specialized > >> > implementation. > >> > File streams don't even have a name, because they need not to. > >> > You can browse XTFileReadStream and XTFileWriteStream, you won't find > >> > such > >> > thing. > >> > The file has a name, the stream does not need any. > >> > Before adding anything to a stream, ask first, why am i going to need > >> > this? > >> > >> I agree with what Frank said, but not your suggestion that: > >> > >> > File streams don't even have a name, because they need not to. > >> > If it really need it, the application certainly can retrieve the name > >> > from a higher level object (a > >> > FIleReference, FileDirectory or whatever). > >> > >> because doing that means the FileStream is no longer > >> fully-encapsulated. And now for the same method to support a > >> non-FileStream stream, what will be passed as the new FileReference > >> argument? nil? So the code went from stream-delegation to > >> case-logic. > >> > >> This is why organic growth happened in the original Stream hierarchy > >> -- because it was "needed", not random. Not strict, yes, but not > >> "random" either. > >> > >> One final thing to consider about selector "uniformity" is how it can > >> negate the ability to effectively trace code (via senders and > >> implementors). Wow, how many senders of #next...? > >> > >> Stream-composition is cool, though, and I understand that to be a > >> benefit of the stricter API. > >> > >> > >> > >> > 2013/11/13 Frank Shearar <frank.shearar(a)gmail.com> > >> >> > >> >> On 13 November 2013 16:48, Chris Muller <asqueaker(a)gmail.com> wrote: > >> >> > I know nothing about Xtreams but, IMO, this obsession with > sterility > >> >> > borders on mental illness. > >> >> > > >> >> > "All sort of un-needed complexity?" That's overstating it a bit, > >> >> > don't you think? > >> >> > > >> >> > So you must really feel stressed that ALL Object's, in fact, have a > >> >> > #name, huh? I admit this seems to push the limits but... > >> >> > > >> >> > what's the point of having any kind of different streams at all > then? > >> >> > It's the _differences_ between them that makes composing them > useful. > >> >> > Compression, encryption, filtering, sockets, files, circular, etc. > >> >> > You think you'll be able to do all that and get away with all of > them > >> >> > having exactly the same API? > >> >> > >> >> They don't have the same API. And they shouldn't. And that's Nicolas' > >> >> whole point. A Stream does not have a name (nor should it - what's > the > >> >> name of the compressed output of an audio stream from your > >> >> microphone?). A FileStream can extend this API, and that's fine. But > >> >> keep that out of the Stream API. > >> >> > >> >> So Nicolas is arguing that _difference_ should be reflected in the > >> >> API. File streams have names, but generic streams do not. > >> >> > >> >> As it happens, Xtreams takes a very disciplined approach to this. > Some > >> >> streams have positions, and so you can go back. Some can't. This is > >> >> reflected in the API. This is good. > >> >> > >> >> > IMHO working around that, passing extra objects around, sounds more > >> >> > stressful than letting a stream on a _file_ know its filename.. > >> >> > >> >> Mu. Streams have no names. File streams have names. > >> >> > >> >> frank > >> >> > >> >> >> If it really need it, the application certainly can retrieve the > >> >> >> name > >> >> >> from a higher level object (a FIleReference, FileDirectory or > >> >> >> whatever). > >> >> > > >> >> > How does that solution allow uniformity in stream-using code? > >> >> > > >> >> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier > >> >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> Yes, a Wrapper would provide the legacy API. > >> >> >> > >> >> >> And yes, the name of a stream should better not be part of the > API. > >> >> >> Most stream don't have a name, and adding such API adds all sort > of > >> >> >> un-needed complexity. > >> >> >> It's an internal detail that can eventually help for reporting > error > >> >> >> if > >> >> >> accessible, but nothing more. > >> >> >> > >> >> >> If it really need it, the application certainly can retrieve the > >> >> >> name > >> >> >> from a > >> >> >> higher level object (a FIleReference, FileDirectory or whatever). > >> >> >> > >> >> >> > >> >> >> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > >> >> >>> > >> >> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier > >> >> >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >>> > It's just a matter of selecting a strategy. I've proposed two: > >> >> >>> > A) create a wrapper class for legacy Stream compatibility > >> >> >>> > selectors > >> >> >>> > B) create extensions for Legacy Stream compatibility selectors > >> >> >>> > My preference goes to A) > >> >> >>> > >> >> >>> By wrappers you mean the Xtreams are the innards doing the work > and > >> >> >>> the wrappers providing the legacy API? > >> >> >>> > >> >> >>> This would be a great way to test Xtreams. > >> >> >>> > >> >> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: > >> >> >>> > peek > >> >> >>> > upTo: > >> >> >>> > ...), otherwise we will import all the cruft in Xtream and > would > >> >> >>> > go > >> >> >>> > back > >> >> >>> > to > >> >> >>> > our starting point... > >> >> >>> > Once the minimal support written (a few hours should be > enough), > >> >> >>> > we > >> >> >>> > should > >> >> >>> > gradually switch each every legacy Stream usage -> Xtream. > >> >> >>> > > >> >> >>> > An area which require more work is those Streams that have > mixed > >> >> >>> > conventions > >> >> >>> > (one portion is interpreted as text, another as binary). > >> >> >>> > In theory that's easy, we just have two streams and they both > >> >> >>> > wrap > >> >> >>> > on a > >> >> >>> > low > >> >> >>> > level binary stream, but that means we have to be very cautious > >> >> >>> > with > >> >> >>> > buffers > >> >> >>> > and caches. > >> >> >>> > > >> >> >>> > Another area of work is usage of ugly selectors like name (we > try > >> >> >>> > to > >> >> >>> > access > >> >> >>> > the file name from the Stream API, arghh). Those usages are bad > >> >> >>> > and > >> >> >>> > require > >> >> >>> > a rewrite. > >> >> >>> > >> >> >>> Are you saying a FileStream knowing its #name or #filename is > bad? > >> >> >>> > >> >> >> > >> >> > > >> >> > >> > > >> > > > >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by Jan Vrany

> We already have a prototype implementation with Markdown using the > existing text model.Worked already fine, Where can I find it? I'm quite interested. Jan

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by Camillo Bruni

On 2013-11-13, at 21:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦ > > With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. What has this to do with athens? We already have a prototype implementation with Markdown using the existing text model. Worked already fine, so that should be 1 afternoon of work to get the pier syntax running in the current image.

Nov. 13, 2013