- Pharo-dev - lists.pharo.org

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

by Ben Coman

On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > You hit several birds with one single mail. > > 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > > Jimmie et al. nicely reasoned arguments - and Doru's point about > controlling > > the syntax is an interesting one that I hadnât thought about. > > > > Personally, I find having too many similar syntaxâs confusing - > contributing > > to things is hard enough - having to remember that its !! Instead of ## > and > > ââ instead of ** is just frustrating for me. > > +1 > Not only for docs, most platforms like Slack/Discord share the syntax, > so now I'm getting "muscle memory" when typing literals using the > backtick (`) character, quoting with > or pasting snippets using ``` > +1. So I've posted this before... https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… describing that "The only strategy in getting people to switch to your product is to eliminate barriers" But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). cheers -ben > > > Sure, maybe we were first with Pillar, but for me, lots of programming > is in > > other languages, and I use Smalltalk where I can, and a hybrid of > multiple > > languages and projects is often the reality - so a lowest common > denominator > > of Markdown is just easier. The fact that we are quite close to what our > > colleagues in other languages use (regardless of what Python has > chosen), is > > quite interesting. > > This helps building "bridges" with other communities. > > The language as a means of exchange is always the lowest common > denominator. > As long as it's "efficient enough" then I vote to use what other > communities use. > > > That said, if the community wants to stick to its gunâs thats fine - I > will > > probably still investigate how to use Commonmark for myself, and will > still > > contribute to Pillar docs where I can (and curse history) - but I think > we > > are long better off trying to join emerging standards where we can > > particularly if they arenât our core language thing. And it just makes it > > less frictionless for ourselves and newcomers. > > The "Not Invented Here" syndrome is strong among Smalltalkers, it's > important to be aware of this bias and think more than once whether > eating our own dogfood adds value to the core of what Pharo brings. > > I think we missed some good years fighting with our own SCM and in the > end git (or any other file based SCM) prevailed, even when it has > limitations. > > Pareto (80-20) for everything non-core business should be a guide. > > > Of course, if we were to move, we would need to translate a lot of > quality > > docs to a new format - but I would be up for contributing to that if that > > was a deciding factor. > > There are some Markdown exporters AFAIK, or it could be written. > > > Esteban A. Maringolo > >

Aug. 15, 2017

Re: [Pharo-dev] New line on command line

by Rajula Vineet

Hey Guille, I think I found the fix. But I would like to run by you first. I want to get a review before making a PR. In the method nextPut: in ZnCrProtableWriteStream, when a new line character is sent using 'OSPlatform current lineEnding', there isn`t any statement which satisfies in this nextPut:. So at the end where the character is checked if it`s a new line, when I added a ifFalse statement and added self newline. Full code is as follows nextPut: aCharacter (String crlf includes: aCharacter ) ifFalse: [ previous ifNotNil: [ self newLine ]. ^ stream nextPut: aCharacter ]. previous = Character cr ifTrue: [ self newLine ]. aCharacter ~= Character lf ifTrue: [ previous := aCharacter ] ifFalse:[ self newLine ]. The only change is the last line. Rajula -- View this message in context: http://forum.world.st/New-line-on-command-line-tp4960327p4961385.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Ben Coman

In case any of the shutdown/startup scripts use a delay, now or in the future, I'd first try at highestPriority-1 to avoid influence on the DelayScheduler. but then Eliot's suggestion to valueUnpreemptively may avoid that anyway. btw, what happens if an error occurs inside valueUnpreemptively? Does the normal priority debugger still get to run? cheers -ben On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi all, > > I'm proposing a kind-of critical change that I believe is very good for > the health of the system: I want that the startup of the system runs in > maximum priority and becomes non-interruptable. > > Right now, when you save your image, the shutdown and startup are run in > the same priority than the process that triggered the save (usually the ui > or the command line, priority 40). This can cause lots of problems and race > conditions: processes with higher priorities can interrupt the > shutdown/startup and try to do something while the system is unstable. As a > side effect also, when you use extensively the command line, you start > stacking startup contexts from old sessions: > > ... > session 3 ctxt 4 <- This guy makes a save and a new session starts > session 3 ctxt 3 > session 3 ctxt 2 > session 3 ctxt 1 > session 2 ctxt 4 <- This guy makes a save and a new session starts > session 2 ctxt 3 > session 2 ctxt 2 > session 2 ctxt 1 > session 1 ctxt 4 <- This guy makes a save and a new session starts > session 1 ctxt 3 > session 1 ctxt 2 > session 1 ctxt 1 > > Old contexts are never collected, and the objects they referenced neither. > > To fix these two problems I propose to do every image save/session start > in a new process in maximum priority. That way, other process should not be > able to interrupt the startup process. Moreover, every session > shutdown/startup should happen in a new clean process, to avoid the session > stacking. > > For normal users, this should have no side effect at all. This change will > have a good impact on people working on the debugger and the stack such as > fueling-out the stack because they will have a cleaner stack. > > There is however a side-effect/design point to consider: startup actions > should be quick to run. If a startup action requires to run a long-running > action such as starting a server or managing a command line action, that > should run in a separate process with lower priority (usually > userPriority). In other words, the startup action should create a new > process managing its action. > > If you want to review (and I'd be glad) > > Pull request: https://github.com/pharo-project/pharo/pull/198 > Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 > Current validation going on: https://ci.inria.fr/pharo-ci- > jenkins2/job/Test%20pending%20pull%20request%20and% > 20branch%20Pipeline/view/change-requests/job/PR-198/ > > Guille > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Aug. 15, 2017

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

by Ben Coman

On Mon, Aug 14, 2017 at 4:49 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Is there a way for this to get back into 6.1 - so we can shoot for a > stable 6.x version that will last us for a year while 7.x is under > development? > > Iâm not familiar with how point release are handled in Pharo, and I get > the impression that this is going to be a slightly rockier year as there > have been some pretty revolutionary changes made to get us here. > > As its a vm change does this mean we get 6.2 queued up somehow? > We don't (yet) have a massive-cyber-corp backer, so with limited resources there are only limited point releases - usually only one, half-way to two-thirds through the year. But we already got 6.1, so I'm not sure affects things. Now the first rule is that fixes must go into the current dev branch and then backported. So get it into Pharo 7 and queue it up for (maybe) 6.2. cheers -ben > > Tim > > > On 13 Aug 2017, at 20:12, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Tx eliot. > > > > > > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Andrei, > >> > >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis < > chisvasileandrei(a)gmail.com> > >> wrote: > >>> > >>> > >>> Hi, > >>> > >>> I was executing this code '(2009/2000) ** (3958333/100000)' with the > >>> Pharo6.1 distribution and the vm crashed with she stack attached below. > >>> Tried it on both mac and windows 10. > >>> Seems that #raisedTo: has a special case for fractions that ends up > >>> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. > >> > >> > >> The plugin is now fixed; see VMMaker.oscog-eem.2262. I'll generate code > >> soon (am debugging something you're familiar with that takes several > hours > >> to run and don't want to generate sources while it's running). But I'm > glad > >> you've found a better way! This case creates 600k byte large integers > and > >> takes forever to run :-) > >> > >>> > >>> Cheers, > >>> Andrei > >>> > >>> > >>> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: > >>> a(n) LargePositiveInteger > >>> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: > a(n) > >>> LargePositiveInteger > >>> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 > >>> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction > >>> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction > >>> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction > >>> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject > >>> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler > >>> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) > >>> RubSmalltalkEditor > >>> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) > >>> RubSmalltalkEditor > >>> 0xade0b8 M > >>> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint > >>> 0x3062fdc8: a(n) GLMMorphicPharoScri > >>> enderer > >>> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) > MorphicAlarm > >>> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm > >>> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState > >>> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) > WorldState > >>> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState > >>> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph > >>> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState > >>> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState > >>> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph > >>> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class > >>> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) > >>> MorphicUIManager > >>> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure > >>> > >> > >> > >> > >> -- > >> _,,,^..^,,,_ > >> best, Eliot > > > > >

Aug. 15, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Tue, Aug 15, 2017 at 10:04:31AM +0200, Stephane Ducasse wrote: > tx a lot for the summary, this is super useful :) > I will over them later (because I must work on my new lectures :). > > Stef I've just realised that: - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing has merge conflicts, and that #20307 adds more merge conflicts. The easiest thing to do is to defer this issue until after #20307 has been merged. I'll then update the patch to remove the merge conflicts and resubmit. Cheers, Alistair > On Tue, Aug 15, 2017 at 7:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > I've added the PR to fix automatic canonicalisation of path references > > to the parent directory (".."): > > > > - https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… > > - https://github.com/pharo-project/pharo/pull/206 > > > > Other open issues (to help keep track): > > > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > > https://github.com/pharo-project/pharo/pull/133 > > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > > https://github.com/pharo-project/pharo/pull/137 > > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > > This is the first step in fixing FileReference>>isSymlink and > > extending support for all file attributes returned by stat() and > > lstat(). > > The parent issue is: > > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > > > > Since #13217 has been accepted, #18042 and its associated PR should be > > closed (won't fix): > > > > - https://pharo.fogbugz.com/f/cases/18042 > > - https://github.com/pharo-project/pharo/pull/75 > > > > > > Thanks! > > Alistair > > > > > > > > On Thu, Aug 10, 2017 at 08:23:49PM +0000, Alistair Grant wrote: > >> Hi Stef, > >> > >> On Wed, Aug 09, 2017 at 10:12:17PM +0200, Stephane Ducasse wrote: > >> > Hi alistair > >> > > >> > I went on fogbugz to find the fix to be included and I'm not sure not > >> > that find them. > >> > I looked for FileSystem. > >> > > >> > I found > >> > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > >> > > >> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > >> > https://github.com/pharo-project/pharo/pull/133 > >> > > >> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > >> > https://github.com/pharo-project/pharo/pull/137 > >> > > >> > Did I miss some others? > >> > > >> > Stef > >> > >> - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > >> This is the first step in fixing FileReference>>isSymlink and > >> extending support for all file attributes returned by stat() and > >> lstat(). > >> The parent issue is: > >> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > >> > >> Just for completeness, the two issues relating to FileReference>>/: > >> > >> - https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri… > >> - https://github.com/pharo-project/pharo/pull/192 > >> - https://pharo.fogbugz.com/f/cases/18042 > >> - https://github.com/pharo-project/pharo/pull/75 > >> > >> > >> Cheers, > >> Alistair > > >

Aug. 15, 2017

Re: [Pharo-dev] New line on command line

by Rajula Vineet

Oh ok sure. I will try my best. :) Rajula -- View this message in context: http://forum.world.st/New-line-on-command-line-tp4960327p4961307.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

tx a lot for the summary, this is super useful :) I will over them later (because I must work on my new lectures :). Stef On Tue, Aug 15, 2017 at 7:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > I've added the PR to fix automatic canonicalisation of path references > to the parent directory (".."): > > - https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… > - https://github.com/pharo-project/pharo/pull/206 > > Other open issues (to help keep track): > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > https://github.com/pharo-project/pharo/pull/133 > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > https://github.com/pharo-project/pharo/pull/137 > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > This is the first step in fixing FileReference>>isSymlink and > extending support for all file attributes returned by stat() and > lstat(). > The parent issue is: > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > Since #13217 has been accepted, #18042 and its associated PR should be > closed (won't fix): > > - https://pharo.fogbugz.com/f/cases/18042 > - https://github.com/pharo-project/pharo/pull/75 > > > Thanks! > Alistair > > > > On Thu, Aug 10, 2017 at 08:23:49PM +0000, Alistair Grant wrote: >> Hi Stef, >> >> On Wed, Aug 09, 2017 at 10:12:17PM +0200, Stephane Ducasse wrote: >> > Hi alistair >> > >> > I went on fogbugz to find the fix to be included and I'm not sure not >> > that find them. >> > I looked for FileSystem. >> > >> > I found >> > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing >> > >> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >> > https://github.com/pharo-project/pharo/pull/133 >> > >> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… >> > https://github.com/pharo-project/pharo/pull/137 >> > >> > Did I miss some others? >> > >> > Stef >> >> - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… >> This is the first step in fixing FileReference>>isSymlink and >> extending support for all file attributes returned by stat() and >> lstat(). >> The parent issue is: >> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… >> >> Just for completeness, the two issues relating to FileReference>>/: >> >> - https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri… >> - https://github.com/pharo-project/pharo/pull/192 >> - https://pharo.fogbugz.com/f/cases/18042 >> - https://github.com/pharo-project/pharo/pull/75 >> >> >> Cheers, >> Alistair >

Aug. 15, 2017

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