- Pharo-dev - lists.pharo.org

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

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