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

Re: [Pharo-dev] [squeak-dev] Serializers/Encoders

by henry

To clarify, external type declarations are different that the type specification of a structure, such as an X509Certificate and its TBSCertificate. These are type applied, in similar fashion to NeoJSON, will forecite and predeterminization on both encoding and decoding sides. These type definitions are applied ad-hoc. In the case of an external type declaration, as understood so far, these declare new types recognizable by the internal type identification. Why is important to system? When presentation layer is decoding a message, arbitrary objects may be encoded inthe graph of arguments or receiver. As these are discovered in tracing these graphs, these arbitrary objects will have ASN.1 schema definitionModels from the declarations and should de/manifest appropriately. Hopefully. - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] [squeak-dev] Serializers/Encoders > Local Time: August 15, 2017 2:28 AM > UTC Time: August 15, 2017 6:28 AM > From: henry(a)callistohouse.club > To: Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>, Pharo Development List <pharo-dev(a)lists.pharo.org> > > After more research, including TJSON, we realized the choice of ASN.1 at the lower layer is exactly what could continue at the higher layer, with more work to expand ASN.1 capability. > > Sorry for the huge 1 MB image. The classes in Fuel are, beginning with serialization or demanifestation: > > Serializer > * Serialization > * Analyzer > * Encoder > ** Analysis > ***[] Clusterizations { handling source-substitutions } > > onthe wire these clusterizations are encoded. On the receiving side, the process of materialization or manifestation is straightforwards, activate the clusterizations, with a decoder forming a proxy instance graph, then annealing them as references. I think these are the points of substitution, but I am honestly guessing from a faint memory. > > Materializer > * Materialization > * Decoder > (***[]) on the wire clusterizations... > > I really want/need/desire to dive into where and how substitutions are occurring, on source-side and destination. This in order to add this ability to the ASN.1 system. > > In ASN.1 specification, there is a mechanism to specify external structures and expand the definitional nature of ASN.1. ASN.1 carries a notation and we have the start of a DefinitionModel. Fitting this into Fuel would be sweet and it may be straightforward: break the graph walking of ASN.1 just have the target encoding, in nesting: so pre and post, and change the Fuel Encoder/Decoder. I believe that since clusterizations will not pass across, a decode analyzer will be needed. > > Getting III (Interactive Invocation Interface) support to generate ASN.1 definition models and classes to model them, bi-directionally, will enable the analyzers to setup clusterizations that en/decode properly. Here's to hope that this will be so. > > Among the varied requirements, the core requirement is passing extended substitutable types/schemas between environments: Squeak - Pharo - Java. I think ASN.1 with its types is the best choice. I have no idea if Bouncy Castle can support external types. I am happy it can do CHOICE, though with manual coding to implement this. Separating the Types in Squeak/Pharo Cryptograghy turns out to be a good choice and interchangeable we hope. > > I hope this clarifies and illuminates, I am driven to share these thoughts. > > Warmly, > - HH > >> -------- Original Message -------- >> Subject: Re: [squeak-dev] [Pharo-dev] Serializers/Encoders >> Local Time: August 14, 2017 6:27 PM >> UTC Time: August 14, 2017 10:27 PM >> From: henry(a)callistohouse.club >> To: Pharo Development List <pharo-dev(a)lists.pharo.org>, Squeak-dev <squeak-dev(a)lists.squeakfoundation.org> >> >> In further consideration, what seems missing from JSON encoding is an ANY type and a CHOICE type. With these and proper type encoding extension to JSON, we could pass arbitrary types w/o being required to specify a specific decoding structure. I think this is so. Types would be helpful. I found TJSON, which may be good, but no arbitrary types, still. >> >> I notice JSON decoding is where magic happens and it requires full specification of what is expected. Perhaps there is a way for ANY & CHOICE with a CustomMapper. Contrarily, Fuel does all analysis on encoding, the front side, and encodes the found clusters on-stream so the materialized is lightweight. ASN1MODULES does a little of both with external types but also with ANY & CHOICE. >> >> In looking at Fuel-Core, here are main classes.., >> >> - HH >> >> On Mon, Aug 14, 2017 at 13:44, henry <henry(a)callistohouse.club> wrote: >> >>> I find I do not necessarily have a specific question regarding a specific implementations, but a higher-level question of feasible solution. I need substitutable, type-relevant JSON encoding, perhaps based upon JSON Schemas. >>> >>> I am looking at ASN1Modules & types, Fuel clusterings/substitutions and NeoJSON clusters & mappers. Is it feasible to bring all these together? I would use ASN1Types, Fuel graph walking/substitutions and NeoJSON encoding and cluster hooks. >>> >>> Fuel also has Clusters but I see that Fuel encodes these clusters in each encoding. I am torn about this philosophically: good to have self-describing data encoding, but not suitable for JSON, unless just a type-name extension. Lightweight & robust descriptions? Well, this is all Fuel cluster specs within the encoding really is: a type-specification. >>> >>> The aspect of NeoJSON that has me wondering is the lack of polymorphism in type-spec lookup and recursive substitution. This is where Fuel shines, I feel. >>> >>> So what is the vision of the end state encoder? Use ASN1 Types as cluster descriptors, Fuel proxification on materializations and NeoJSON encoding and mappers. >>> >>> Would you have for me guidances in this area? >>> >>> - HH

Aug. 15, 2017

Re: [Pharo-dev] [squeak-dev] Serializers/Encoders

by henry

After more research, including TJSON, we realized the choice of ASN.1 at the lower layer is exactly what could continue at the higher layer, with more work to expand ASN.1 capability. Sorry for the huge 1 MB image. The classes in Fuel are, beginning with serialization or demanifestation: Serializer * Serialization * Analyzer * Encoder ** Analysis ***[] Clusterizations { handling source-substitutions } onthe wire these clusterizations are encoded. On the receiving side, the process of materialization or manifestation is straightforwards, activate the clusterizations, with a decoder forming a proxy instance graph, then annealing them as references. I think these are the points of substitution, but I am honestly guessing from a faint memory. Materializer * Materialization * Decoder (***[]) on the wire clusterizations... I really want/need/desire to dive into where and how substitutions are occurring, on source-side and destination. This in order to add this ability to the ASN.1 system. In ASN.1 specification, there is a mechanism to specify external structures and expand the definitional nature of ASN.1. ASN.1 carries a notation and we have the start of a DefinitionModel. Fitting this into Fuel would be sweet and it may be straightforward: break the graph walking of ASN.1 just have the target encoding, in nesting: so pre and post, and change the Fuel Encoder/Decoder. I believe that since clusterizations will not pass across, a decode analyzer will be needed. Getting III (Interactive Invocation Interface) support to generate ASN.1 definition models and classes to model them, bi-directionally, will enable the analyzers to setup clusterizations that en/decode properly. Here's to hope that this will be so. Among the varied requirements, the core requirement is passing extended substitutable types/schemas between environments: Squeak - Pharo - Java. I think ASN.1 with its types is the best choice. I have no idea if Bouncy Castle can support external types. I am happy it can do CHOICE, though with manual coding to implement this. Separating the Types in Squeak/Pharo Cryptograghy turns out to be a good choice and interchangeable we hope. I hope this clarifies and illuminates, I am driven to share these thoughts. Warmly, - HH > -------- Original Message -------- > Subject: Re: [squeak-dev] [Pharo-dev] Serializers/Encoders > Local Time: August 14, 2017 6:27 PM > UTC Time: August 14, 2017 10:27 PM > From: henry(a)callistohouse.club > To: Pharo Development List <pharo-dev(a)lists.pharo.org>, Squeak-dev <squeak-dev(a)lists.squeakfoundation.org> > > In further consideration, what seems missing from JSON encoding is an ANY type and a CHOICE type. With these and proper type encoding extension to JSON, we could pass arbitrary types w/o being required to specify a specific decoding structure. I think this is so. Types would be helpful. I found TJSON, which may be good, but no arbitrary types, still. > > I notice JSON decoding is where magic happens and it requires full specification of what is expected. Perhaps there is a way for ANY & CHOICE with a CustomMapper. Contrarily, Fuel does all analysis on encoding, the front side, and encodes the found clusters on-stream so the materialized is lightweight. ASN1MODULES does a little of both with external types but also with ANY & CHOICE. > > In looking at Fuel-Core, here are main classes.., > > - HH > > On Mon, Aug 14, 2017 at 13:44, henry <henry(a)callistohouse.club> wrote: > >> I find I do not necessarily have a specific question regarding a specific implementations, but a higher-level question of feasible solution. I need substitutable, type-relevant JSON encoding, perhaps based upon JSON Schemas. >> >> I am looking at ASN1Modules & types, Fuel clusterings/substitutions and NeoJSON clusters & mappers. Is it feasible to bring all these together? I would use ASN1Types, Fuel graph walking/substitutions and NeoJSON encoding and cluster hooks. >> >> Fuel also has Clusters but I see that Fuel encodes these clusters in each encoding. I am torn about this philosophically: good to have self-describing data encoding, but not suitable for JSON, unless just a type-name extension. Lightweight & robust descriptions? Well, this is all Fuel cluster specs within the encoding really is: a type-specification. >> >> The aspect of NeoJSON that has me wondering is the lack of polymorphism in type-spec lookup and recursive substitution. This is where Fuel shines, I feel. >> >> So what is the vision of the end state encoder? Use ASN1 Types as cluster descriptors, Fuel proxification on materializations and NeoJSON encoding and mappers. >> >> Would you have for me guidances in this area? >> >> - HH

Aug. 15, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Aug. 15, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by henry

Yes, here it is, in Pharo6.1, as mentioned previously. Just run the eventual_test tests and it will exit on Ubuntu 32-bit. https://ufile.io/pa9ym Thank you, - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 7:45 PM > UTC Time: August 14, 2017 11:45 PM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > Hi Henry, > > On Mon, Aug 14, 2017 at 3:58 PM, henry <henry(a)callistohouse.club> wrote: > >> If you need more info, please ask and I will try to get ths to you. > > yes, if you can make the image & changes available somewhere that would be nice. Thanks. > >> - HH >> >>> -------- Original Message -------- >>> Subject: Re: [Pharo-dev] eventual crashes pharo vm >>> Local Time: August 14, 2017 6:54 PM >>> UTC Time: August 14, 2017 10:54 PM >>> From: henry(a)callistohouse.club >>> To: Eliot Miranda <eliot.miranda(a)gmail.com> >>> Pharo Development List <pharo-dev(a)lists.pharo.org> >>> >>> Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on ubuntu 32-bit. Here is the vm version info below. >>> >>> I loaded this package and ran the tests and it exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz >>> >>> Here is the pharo 6.1 version... >>> 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] >>> CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >>> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ >>> Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux >>> plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: /usr/local/lib/pharo/5.0-201707201942/] >>> >>> - HH >>> >>>> -------- Original Message -------- >>>> Subject: Re: [Pharo-dev] eventual crashes pharo vm >>>> Local Time: August 14, 2017 6:47 PM >>>> UTC Time: August 14, 2017 10:47 PM >>>> From: eliot.miranda(a)gmail.com >>>> To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> >>>> Hi Henry, >>>> >>>> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >>>> >>>>> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >>>>> >>>>> http://www.squeaksource.com/TurquoiseTesting.html >>>> >>>> Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. >>>> >>>> _,,,^..^,,,_ >>>> best, Eliot > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 15, 2017

[ANN] VistaCursor now scalable

by Torsten Bergmann

Hi, Mike Davis asked about changing the cursor size as he runs Pharo with Windows 10 on a Microsoft Surface @ 2736 x 1824 dpi. He discussed on Discord and said that all of the display is well scaled, except the mouse cursor which is too small for him. As the Windows VM supports larger cursors I added some support to my loadable goodie package "VistaCursor" now. So there is now a new setting to scale the provided cursors (see screenshots). Either freshly load the package from catalog or update to "VistaCursors-TorstenBergmann.5" if you want to check this out. This might be also be useful for presentations. Have fun T.

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, On Mon, Aug 14, 2017 at 3:58 PM, henry <henry(a)callistohouse.club> wrote: > If you need more info, please ask and I will try to get ths to you. > yes, if you can make the image & changes available somewhere that would be nice. Thanks. > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:54 PM > UTC Time: August 14, 2017 10:54 PM > From: henry(a)callistohouse.club > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on > ubuntu 32-bit. Here is the vm version info below. > > I loaded this package and ran the tests and it exited...http://www. > squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz > > Here is the pharo 6.1 version... > 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur > VM] > CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad > Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Jul 20 12:42:21 2017 -0700 $ > Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk- > vm.git $ > Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic > #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 > GNU/Linux > plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: > /usr/local/lib/pharo/5.0-201707201942/] > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:47 PM > UTC Time: August 14, 2017 10:47 PM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club>, Pharo Development List < > pharo-dev(a)lists.pharo.org> > > Hi Henry, > > On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the >> pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html >> > > Care to share how to reproduce the crash? Image version, VM version & > word size, OS, Smalltalk expression, supporting files, if any. > > _,,,^..^,,,_ > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by henry

If you need more info, please ask and I will try to get ths to you. - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:54 PM > UTC Time: August 14, 2017 10:54 PM > From: henry(a)callistohouse.club > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on ubuntu 32-bit. Here is the vm version info below. > > I loaded this package and ran the tests and it exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz > > Here is the pharo 6.1 version... > 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ > Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux > plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: /usr/local/lib/pharo/5.0-201707201942/] > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 14, 2017 6:47 PM >> UTC Time: August 14, 2017 10:47 PM >> From: eliot.miranda(a)gmail.com >> To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> Hi Henry, >> >> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >> >>> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >>> >>> http://www.squeaksource.com/TurquoiseTesting.html >> >> Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. >> >> _,,,^..^,,,_ >> best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by henry

Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on ubuntu 32-bit. Here is the vm version info below. I loaded this package and ran the tests and it exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz Here is the pharo 6.1 version... 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: /usr/local/lib/pharo/5.0-201707201942/] - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:47 PM > UTC Time: August 14, 2017 10:47 PM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> > > Hi Henry, > > On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html > > Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. > > _,,,^..^,,,_ > best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > Hi all. I was testing with this eventual_test package and it blows up the > pharo 6.1 vm. I'd welcome pointers > > http://www.squeaksource.com/TurquoiseTesting.html > Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. _,,,^..^,,,_ best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Tudor Girba

Hi, > On Aug 14, 2017, at 3:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > again, I think this is a discussion for pharo-dev. > Please keep it there (is good discussion, btw ;) ). > > What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P) I am for it, but there will be some work to repackage PetitParser2. Also, I notice that the French lessons start to pay off :) Cheers, Doru > Esteban > > >> On 14 Aug 2017, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi Tim, >> >> The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. >> >> The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. >> >> Cheers, >> Doru >> >> >>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). >>> >>> My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). >>> >>> Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. >>> >>> >>> Tim >>> >>>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi tim >>>> >>>> I personally do not care much about the syntax but I care about what I >>>> can do with it >>>> (ref, cite, ... ) >>>> I cannot write books in markdown because reference to figures!!!!!! >>>> were missing. >>>> >>>> And of course a parser because markdown is not really nice to parse >>>> and I will not write a parser because I have something else to do. I >>>> want to make pillar smaller, simpler, nicer. >>>> >>>> Now if someone come up with a parser that parse for REAL a markdown >>>> that can be extended with decent behavior (figure reference, section >>>> reference, cite) and can be extended because there are many things >>>> that can be nice to have (for example I want to be able to write the >>>> example below) and emit a PillarModel (AST) we can talk to have >>>> another syntax for Pillar but not before. >>>> >>>> [[[test >>>> 2+3 >>>>>>> 5 >>>> ]]] >>>> >>>> and being able to verify that the doc is in sync. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>>>> >>>>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>> >>>>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>>>> >>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>>>> >>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>> >>>>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>> >>>>>> Peter >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> âLive like you mean it." >> >> > > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

Aug. 14, 2017