Re: [Pharo-users] Slots vs collections

[Ben Coman]

On Sat, 21 Mar 2020 at 01:54, Noury Bouraqadi  wrote:

> Hi Richard,
>
> My example was about having a collection of bits. So, #do: and #select: do
> continue to have the very same semantics.
> The whole point is to save memory behind the scenes, while keeping the
> same API.
> Consider a very large matrix of booleans. It would save memory to store
> booleans as bits.
> There is of course the "normal" way of doing it, by changing the
> implementation.
> But, with slots, it should be possible to use an instance 2DArray
>

What is the 2D-ness of a collection of bits.  Have you considered Bitmap?

The original paper discusses bit-fields.  I'm not sure how that maps to
current Pharo implementation.
http://scg.unibe.ch/archive/papers/Verw11bFlexibleObjectLayouts.pdf

cheers -ben

Re: [Pharo-users] Json encoding

[Vitor Medina Cruz]

Oh! I understand, desserialize is, indeed, a problem because you don't have
the types.

I find very hard to follow the mapping instructions, why can't I just tell
the class of my instvars?

jsonReader := NeoJSONReader new configure: MyCustomClass
  withInstVarMapping:
{#name -> String. #dateOrBirth -> Date}

jsonRreader fromJson: { "name":"Joe","dateOfBirth":"19900407"}
  toClass: MyCustomClass

???


Well, I am going to experiment with STON for now, I used NeoJson some time
ago, but for simpler stuff.

Ignoring the instvar worked.

Thanks!!






On Fri, Mar 20, 2020 at 7:41 PM Sven Van Caekenberghe  wrote:

> I think you have to think harder about this ;-)
>
> It would indeed be relatively easy to allow any object to be written out
> to JSON, falling back to just writing out its instance variables. You could
> hack that today by overwriting/implementing #neoJsonOn:
>
> But you would never be able to read that back, because you don't known the
> types/classes (in general).
>
> Say you have a Person object with a dateOfBirth in it, a Date.
>
> { "name":"Joe","dateOfBirth":"19900407" }
>
> You don't know this is a Person, nor that dateOfBirth is a Date. You have
> to tell the JSON reader/parser that explicitly. And even if you tell it to
> start with Person, no reflection in Pharo tells you that dateOfBirth is a
> Date.
>
> In statically typed languages you do know that.
>
> That is why NeoJSON has mappings (section 5 of the document). These
> provide that missing information. But this mechanism is not perfect (it can
> become quite complex with deep nesting or variant types).
>
> The unit tests show many usages of mappings.
>
> But even so, the original JSON is not self describing.
>
> This is why STON exists.
>
> It was a design choice to restrict which classes can automatically be
> converted to JSON without an explicit mapping to the primitive JSON types.
>
> > On 20 Mar 2020, at 21:47, Vitor Medina Cruz 
> wrote:
> >
> > Thanks Sven,
> >
> > One of the pages provided one solution I need: to ignore certain
> instance variable while encoding.
> >
> > I, however, do not understand the problem for Pharo to produce json for
> arbitrary objects just like any Java API — I thought it would even be
> simpler.
> >
> > " In Pharo/Smalltalk, contrary to Java, we are not used to full type
> descriptions. "
> >
> > Well, but you need to? Java APIs use reflection to do this job, when
> looking inside an object you can tell it's type. Every API will do a best
> effort to navigate through object nesting and, very often, it will find
> known primitive objects  down the road. So complex objects are created from
> less complex ones, that area created eventually from from primitives. If it
> cannot deal with the object serialization, it raises an error and generally
> there are mapping features to deal with those border cases. I was surprised
> to see that was not the case with STON and NeoJSON (well, it appears that
> STON tries to do it for it's format)
> >
> > The serialization is also simple, you do something like:
> >
> > ston forClass: MyComplexObject desserialize: aJsonString
> >
> >
> > And well, that is it.
> >
> > On Fri, Mar 20, 2020 at 8:46 AM PBKResearch 
> wrote:
> > Vitor
> >
> >
> >
> > First clarification: There are two different serialization formats, json
> and STON. The content of a json file can only be number, Boolean, string,
> array, dictionary. STON is an extended form based on json, designed to
> represent (almost) any Smalltalk object.
> >
> >
> >
> > Second clarification: What are you trying to do? Do you want to
> serialize data for your own use, to read back into your own Pharo app? Or
> do you want to export data in json format, so that other users, not using
> necessarily using Pharo, can import it? For the first case, STON is a very
> flexible and convenient system. For the second case, you must stick to
> strict json, using only the classes allowed in json.
> >
> >
> >
> > Coming to your specific examples, Date is not a class allowed in json.
> This is not a limitation of NeoJson or STON, it is a limitation of the
> definition of json. If you want to include a Date in a json file, you must
> turn it into an instance of a permitted class. So you could write:
> >
> >
> >
> > STON toJsonString: Date today asString.
> >
> >
> >
> > The only complication here is, if the json is read by other users, they
> must understand the format generated by Date>>asString.
> >
> >
> >
> > If you are using STON to serialise objects for your own use, you may
> want to exclude some instvars (e.g. block closures). This is described in
> the class comments to the STON-Core package. You need to include a class
> side message #stonAllInstVarNames in the class, which lists the names of
> the instvars that are to be serialized.
> >
> >
> >
> > If you want to go deeper into STON, I think Sven has an article on his
> website telling the whole 

Re: [Pharo-users] Slots vs collections

[Tim Mackinnon]

Wow - I hadn’t quite understood the implications here- can you explain that 
2DArray reference a bit more?

I keep thinking slots are cool but haven’t quite spotted when to use them and 
this seems like a compelling example that I haven’t quite grasped...

Tim

> On 20 Mar 2020, at 17:54, Noury Bouraqadi  wrote:
> 
> Hi Richard,
> 
> My example was about having a collection of bits. So, #do: and #select: do 
> continue to have the very same semantics.
> The whole point is to save memory behind the scenes, while keeping the same 
> API.
> Consider a very large matrix of booleans. It would save memory to store 
> booleans as bits.
> There is of course the "normal" way of doing it, by changing the 
> implementation.
> But, with slots, it should be possible to use an instance 2DArray.
> 
> Noury
> 
>> 
>> On 20 Mar 2020, at 15:34, Richard Sargent 
>>  wrote:
>> 
>>> On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi  wrote:
>>> Thanks Julien. So, what I did experienced is because BooleanSlot is work in 
>>> progress.
>>> To address my issue using slots, I guess collections should implement asBit 
>>> method (Sent by BooleanSlot).
>> 
>> 
>> Noury, when modelling something like this, think whether "all collections 
>> should implement asBit". I've added the word all, of course. There are so 
>> many possible collections for which #asBit wouldn't make sense that I would 
>> conclude the hypothesis to be incorrect. Even if you were to implement it on 
>> a single collection class, such as Array, there are still so many examples 
>> where #asBit could not apply.
>> 
>> Perhaps, there could be an e.g. Bits class in the Collection hierarchy. But, 
>> even then, it seems to me that there are so many inherited methods that 
>> wouldn't make sense. What would be the use of #do:? What would #select: 
>> mean? You get the idea.
>> 
>> An alternative possibility, and not the only one, is to model the bits as 
>> part of an integer, small or large. 
>> 
>> Of course, for performance, a ByteArray might be a good way to store bits. 
>> It has the benefit that every instance *can* represent bits. But, the 
>> inherited API operates on the bytes, not the bits.
>> 
>> Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray 
>> and provides the API that is needed.
>> 
>> 
>> That's a rather long answer, admittedly.
>> 
>> 
>>> 
>>> Noury
>>> 
>>> > On 20 Mar 2020, at 13:56, Julien Delplanque  
>>> > wrote:
>>> > 
>>> > Hello,
>>> > 
>>> > There is a work in progress prototype slot named BooleanSlot in the 
>>> > Slot-Example package built-in the image.
>>> > 
>>> > I think this slot does what you want.
>>> > 
>>> > So, the answer is yes, it is possible to do that. But you will need to 
>>> > fix todos left in BooleanSlot methods.
>>> > 
>>> > Julien
>>> > 
>>> > Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
>>> >> Hi,
>>> >> 
>>> >> Suppose I have an instance variable referencing a collection of booleans.
>>> >> I want to have all elements of the collection be stored as bits.
>>> >> Is there a way I can express it using slots?
>>> >> 
>>> >> This idea can be generalized to other types of slots.
>>> >> 
>>> >> Noury
>>> >> 
>>> > 
>>> 
>>> 
> 

Re: [Pharo-users] Json encoding

[Sven Van Caekenberghe]

I think you have to think harder about this ;-)

It would indeed be relatively easy to allow any object to be written out to 
JSON, falling back to just writing out its instance variables. You could hack 
that today by overwriting/implementing #neoJsonOn:

But you would never be able to read that back, because you don't known the 
types/classes (in general).

Say you have a Person object with a dateOfBirth in it, a Date.

{ "name":"Joe","dateOfBirth":"19900407" }

You don't know this is a Person, nor that dateOfBirth is a Date. You have to 
tell the JSON reader/parser that explicitly. And even if you tell it to start 
with Person, no reflection in Pharo tells you that dateOfBirth is a Date.

In statically typed languages you do know that.

That is why NeoJSON has mappings (section 5 of the document). These provide 
that missing information. But this mechanism is not perfect (it can become 
quite complex with deep nesting or variant types).

The unit tests show many usages of mappings.

But even so, the original JSON is not self describing.

This is why STON exists.

It was a design choice to restrict which classes can automatically be converted 
to JSON without an explicit mapping to the primitive JSON types.

> On 20 Mar 2020, at 21:47, Vitor Medina Cruz  wrote:
> 
> Thanks Sven,
> 
> One of the pages provided one solution I need: to ignore certain instance 
> variable while encoding. 
> 
> I, however, do not understand the problem for Pharo to produce json for 
> arbitrary objects just like any Java API — I thought it would even be 
> simpler. 
> 
> " In Pharo/Smalltalk, contrary to Java, we are not used to full type 
> descriptions. "
> 
> Well, but you need to? Java APIs use reflection to do this job, when looking 
> inside an object you can tell it's type. Every API will do a best effort to 
> navigate through object nesting and, very often, it will find known primitive 
> objects  down the road. So complex objects are created from less complex 
> ones, that area created eventually from from primitives. If it cannot deal 
> with the object serialization, it raises an error and generally there are 
> mapping features to deal with those border cases. I was surprised to see that 
> was not the case with STON and NeoJSON (well, it appears that STON tries to 
> do it for it's format)
> 
> The serialization is also simple, you do something like:
> 
> ston forClass: MyComplexObject desserialize: aJsonString
> 
> 
> And well, that is it.
> 
> On Fri, Mar 20, 2020 at 8:46 AM PBKResearch  wrote:
> Vitor
> 
>  
> 
> First clarification: There are two different serialization formats, json and 
> STON. The content of a json file can only be number, Boolean, string, array, 
> dictionary. STON is an extended form based on json, designed to represent 
> (almost) any Smalltalk object.
> 
>  
> 
> Second clarification: What are you trying to do? Do you want to serialize 
> data for your own use, to read back into your own Pharo app? Or do you want 
> to export data in json format, so that other users, not using necessarily 
> using Pharo, can import it? For the first case, STON is a very flexible and 
> convenient system. For the second case, you must stick to strict json, using 
> only the classes allowed in json.
> 
>  
> 
> Coming to your specific examples, Date is not a class allowed in json. This 
> is not a limitation of NeoJson or STON, it is a limitation of the definition 
> of json. If you want to include a Date in a json file, you must turn it into 
> an instance of a permitted class. So you could write:
> 
>  
> 
> STON toJsonString: Date today asString.
> 
>  
> 
> The only complication here is, if the json is read by other users, they must 
> understand the format generated by Date>>asString.
> 
>  
> 
> If you are using STON to serialise objects for your own use, you may want to 
> exclude some instvars (e.g. block closures). This is described in the class 
> comments to the STON-Core package. You need to include a class side message 
> #stonAllInstVarNames in the class, which lists the names of the instvars that 
> are to be serialized.
> 
>  
> 
> If you want to go deeper into STON, I think Sven has an article on his 
> website telling the whole story. This maybe enough to get you started.
> 
>  
> 
> HTH
> 
>  
> 
> Peter Kenny
> 
>  
> 
> From: Pharo-users  On Behalf Of Vitor 
> Medina Cruz
> Sent: 20 March 2020 01:20
> To: Any question about pharo is welcome 
> Subject: [Pharo-users] Json encoding
> 
>  
> 
> Hello,
> 
>  
> 
> I know two projects of json encoding/decoding — NeoJson and STON.
> 
>  
> 
> In Java I have two most used ones too: Gson and Jackson. Using those I can 
> simply pass any object and it they can convert to a json string, the former 
> can't deal with cycles, the latter can with some little config.
> 
>  
> 
> NeoJson seems to be limited to primitives, for example, in Pharo 8 I can't run
> 
>  
> 
> NeoJSONWriter toString: (Date today)
> 
>  
> 
> Since I got:
> 
>  
> 
> 

Re: [Pharo-users] Json encoding

[Vitor Medina Cruz]

Peter,

Oh, you gave me the answer, but I read the doc sven provided before I read
your response lol. Thanks anyway, ignoring the instvar will do the job.

I don't understand why date cannot be used in Json, nor do I think this is
a limitation to json: you must only provide a string representation for the
date. This is even source of debate, some argue that ISO string format for
json is the best, but the point is that  you just need to provide one... If
the user of the dislike it, it can change providing a map.

Regards,
Vitor



On Fri, Mar 20, 2020 at 8:46 AM PBKResearch  wrote:

> Vitor
>
>
>
> First clarification: There are two different serialization formats, json
> and STON. The content of a json file can only be number, Boolean, string,
> array, dictionary. STON is an extended form based on json, designed to
> represent (almost) any Smalltalk object.
>
>
>
> Second clarification: What are you trying to do? Do you want to serialize
> data for your own use, to read back into your own Pharo app? Or do you want
> to export data in json format, so that other users, not using necessarily
> using Pharo, can import it? For the first case, STON is a very flexible and
> convenient system. For the second case, you must stick to strict json,
> using only the classes allowed in json.
>
>
>
> Coming to your specific examples, Date is not a class allowed in json.
> This is not a limitation of NeoJson or STON, it is a limitation of the
> definition of json. If you want to include a Date in a json file, you must
> turn it into an instance of a permitted class. So you could write:
>
>
>
> STON toJsonString: Date today asString.
>
>
>
> The only complication here is, if the json is read by other users, they
> must understand the format generated by Date>>asString.
>
>
>
> If you are using STON to serialise objects for your own use, you may want
> to exclude some instvars (e.g. block closures). This is described in the
> class comments to the STON-Core package. You need to include a class side
> message #stonAllInstVarNames in the class, which lists the names of the
> instvars that are to be serialized.
>
>
>
> If you want to go deeper into STON, I think Sven has an article on his
> website telling the whole story. This maybe enough to get you started.
>
>
>
> HTH
>
>
>
> Peter Kenny
>
>
>
> *From:* Pharo-users  *On Behalf Of *Vitor
> Medina Cruz
> *Sent:* 20 March 2020 01:20
> *To:* Any question about pharo is welcome 
> *Subject:* [Pharo-users] Json encoding
>
>
>
> Hello,
>
>
>
> I know two projects of json encoding/decoding — NeoJson and STON.
>
>
>
> In Java I have two most used ones too: Gson and Jackson. Using those I can
> simply pass any object and it they can convert to a json string, the former
> can't deal with cycles, the latter can with some little config.
>
>
>
> NeoJson seems to be limited to primitives, for example, in Pharo 8 I can't
> run
>
>
>
> NeoJSONWriter toString: (Date today)
>
>
>
> Since I got:
>
>
>
> NeoJSONMappingNotFound: No mapping found for Date in NeoJSONWriter
>
>
>
>
>
> STON works fine with
>
>
>
> STON toString: (Date today).
>
>
>
> but fail with:
>
>
>
> STON toJsonString: (Date today).
>
>
>
> Also, STON fails if I try to serialize an object which contains an
> instance variable pointing to a block closure. I didn't find out how to
> ignore these instance variable as it is unnecessary for what I need at the
> moment.
>
>
>
> So, which lib for json or some object/string encoding/decoding should I be
> using on Pharo? Is there something better than those libs? Am I doing
> something wrong? My experience tells this should be simple, but it is not.
>
>
>
> Thanks in advance,
>
> Vitor
>

Re: [Pharo-users] Json encoding

[Vitor Medina Cruz]

Thanks Sven,

One of the pages provided one solution I need: to ignore certain instance
variable while encoding.

I, however, do not understand the problem for Pharo to produce json for
arbitrary objects just like any Java API — I thought it would even be
simpler.

" In Pharo/Smalltalk, contrary to Java, we are not used to full type
descriptions. "

Well, but you need to? Java APIs use reflection to do this job, when
looking inside an object you can tell it's type. Every API will do a best
effort to navigate through object nesting and, very often, it will find
known primitive objects  down the road. So complex objects are created from
less complex ones, that area created eventually from from primitives. If it
cannot deal with the object serialization, it raises an error and generally
there are mapping features to deal with those border cases. I was surprised
to see that was not the case with STON and NeoJSON (well, it appears that
STON tries to do it for it's format)

The serialization is also simple, you do something like:

ston forClass: MyComplexObject desserialize: aJsonString


And well, that is it.

On Fri, Mar 20, 2020 at 8:46 AM PBKResearch  wrote:

> Vitor
>
>
>
> First clarification: There are two different serialization formats, json
> and STON. The content of a json file can only be number, Boolean, string,
> array, dictionary. STON is an extended form based on json, designed to
> represent (almost) any Smalltalk object.
>
>
>
> Second clarification: What are you trying to do? Do you want to serialize
> data for your own use, to read back into your own Pharo app? Or do you want
> to export data in json format, so that other users, not using necessarily
> using Pharo, can import it? For the first case, STON is a very flexible and
> convenient system. For the second case, you must stick to strict json,
> using only the classes allowed in json.
>
>
>
> Coming to your specific examples, Date is not a class allowed in json.
> This is not a limitation of NeoJson or STON, it is a limitation of the
> definition of json. If you want to include a Date in a json file, you must
> turn it into an instance of a permitted class. So you could write:
>
>
>
> STON toJsonString: Date today asString.
>
>
>
> The only complication here is, if the json is read by other users, they
> must understand the format generated by Date>>asString.
>
>
>
> If you are using STON to serialise objects for your own use, you may want
> to exclude some instvars (e.g. block closures). This is described in the
> class comments to the STON-Core package. You need to include a class side
> message #stonAllInstVarNames in the class, which lists the names of the
> instvars that are to be serialized.
>
>
>
> If you want to go deeper into STON, I think Sven has an article on his
> website telling the whole story. This maybe enough to get you started.
>
>
>
> HTH
>
>
>
> Peter Kenny
>
>
>
> *From:* Pharo-users  *On Behalf Of *Vitor
> Medina Cruz
> *Sent:* 20 March 2020 01:20
> *To:* Any question about pharo is welcome 
> *Subject:* [Pharo-users] Json encoding
>
>
>
> Hello,
>
>
>
> I know two projects of json encoding/decoding — NeoJson and STON.
>
>
>
> In Java I have two most used ones too: Gson and Jackson. Using those I can
> simply pass any object and it they can convert to a json string, the former
> can't deal with cycles, the latter can with some little config.
>
>
>
> NeoJson seems to be limited to primitives, for example, in Pharo 8 I can't
> run
>
>
>
> NeoJSONWriter toString: (Date today)
>
>
>
> Since I got:
>
>
>
> NeoJSONMappingNotFound: No mapping found for Date in NeoJSONWriter
>
>
>
>
>
> STON works fine with
>
>
>
> STON toString: (Date today).
>
>
>
> but fail with:
>
>
>
> STON toJsonString: (Date today).
>
>
>
> Also, STON fails if I try to serialize an object which contains an
> instance variable pointing to a block closure. I didn't find out how to
> ignore these instance variable as it is unnecessary for what I need at the
> moment.
>
>
>
> So, which lib for json or some object/string encoding/decoding should I be
> using on Pharo? Is there something better than those libs? Am I doing
> something wrong? My experience tells this should be simple, but it is not.
>
>
>
> Thanks in advance,
>
> Vitor
>

Re: [Pharo-users] Slots vs collections

[Noury Bouraqadi]

Hi Richard,

My example was about having a collection of bits. So, #do: and #select: do 
continue to have the very same semantics.
The whole point is to save memory behind the scenes, while keeping the same API.
Consider a very large matrix of booleans. It would save memory to store 
booleans as bits.
There is of course the "normal" way of doing it, by changing the implementation.
But, with slots, it should be possible to use an instance 2DArray.

Noury

> 
> On 20 Mar 2020, at 15:34, Richard Sargent 
>  wrote:
> 
> On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi  > wrote:
> Thanks Julien. So, what I did experienced is because BooleanSlot is work in 
> progress.
> To address my issue using slots, I guess collections should implement asBit 
> method (Sent by BooleanSlot).
> 
> Noury, when modelling something like this, think whether "all collections 
> should implement asBit". I've added the word all, of course. There are so 
> many possible collections for which #asBit wouldn't make sense that I would 
> conclude the hypothesis to be incorrect. Even if you were to implement it on 
> a single collection class, such as Array, there are still so many examples 
> where #asBit could not apply.
> 
> Perhaps, there could be an e.g. Bits class in the Collection hierarchy. But, 
> even then, it seems to me that there are so many inherited methods that 
> wouldn't make sense. What would be the use of #do:? What would #select: mean? 
> You get the idea.
> 
> An alternative possibility, and not the only one, is to model the bits as 
> part of an integer, small or large. 
> 
> Of course, for performance, a ByteArray might be a good way to store bits. It 
> has the benefit that every instance *can* represent bits. But, the inherited 
> API operates on the bytes, not the bits.
> 
> Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray 
> and provides the API that is needed.
> 
> 
> That's a rather long answer, admittedly.
> 
> 
> 
> Noury
> 
> > On 20 Mar 2020, at 13:56, Julien Delplanque  > > wrote:
> > 
> > Hello,
> > 
> > There is a work in progress prototype slot named BooleanSlot in the 
> > Slot-Example package built-in the image.
> > 
> > I think this slot does what you want.
> > 
> > So, the answer is yes, it is possible to do that. But you will need to fix 
> > todos left in BooleanSlot methods.
> > 
> > Julien
> > 
> > Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
> >> Hi,
> >> 
> >> Suppose I have an instance variable referencing a collection of booleans.
> >> I want to have all elements of the collection be stored as bits.
> >> Is there a way I can express it using slots?
> >> 
> >> This idea can be generalized to other types of slots.
> >> 
> >> Noury
> >> 
> > 
> 
> 

Re: [Pharo-users] Morphs with Spec2

[Sebastian Jordan]

Hi,

It worked. For center the morph I do it in the naive way. I called the method 
position: of the morph.
Thanks,
Sebastian Jordan

De: Pharo-users  en nombre de Esteban 
Lorenzano 
Enviado: jueves, 19 de marzo de 2020 05:25
Para: Any question about pharo is welcome 
Asunto: Re: [Pharo-users] Morphs with Spec2

Hi,

1. Spec styles define a “default” font applied to all components (morphs in 
this case) that understand font, and if you want to change it you need to 
define your own style.
2. A string morph cannot center the string (this is a morphic stuff)

You can solve your problem by adding a PanelMorph instead a string:

obtainSpMorphPresenterwithAStringMorph
| morph |
morph := StringMorph
contents: 'A String Morph'
font:
(LogicalFont
familyName: Smalltalk ui theme labelFont familyName
pointSize: Smalltalk ui theme labelFont pointSize + 10).
^ SpMorphPresenter new
morph: (PanelMorph new
addMorphBack: morph;
yourself);
yourself


This will produce this morph:

[cid:4B595F37-F62E-4AD8-9D0E-515284AC24C4]


And since I hate morphic, I will let you to fight with morph to center your sub 
morph ;)

Esteban

On 18 Mar 2020, at 17:41, Sebastian Jordan 
mailto:sebastian...@hotmail.com>> wrote:


button1 := self newButton.

Re: [Pharo-users] Pharo float precision vs Python

[Sven Van Caekenberghe]

Thanks for sharing, this is indeed something quite subtle.

> On 20 Mar 2020, at 16:19, Tim Mackinnon  wrote:
> 
> Actually I can answer my own question - its the difference between #sum and 
> #sumNumbers (and an easy mistake to make - I almost wish that sum was the 
> sumNumbers implementation and there was a sumSample that behaved like now)

There was a *LOT* of debate about that (especially that #() sum isZero).

I also would would prefer #sum to be like you describe.

>> On 20 Mar 2020, at 14:52, Tim Mackinnon  wrote:
>> 
>> Hi guys - I recall this came up a few months ago, but I’m curious about the 
>> difference of Pharo’s use of Float64 vs Python - as I assumed that if 
>> languages use the same IEEE spec (or whatever spec it is) that simple stuff 
>> would be quite similar.
>> 
>> I am curious why in Python adding these numbers:
>> 
>> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
>> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 
>> 1008.2985131833999 + 1194.956457522 + 893.9680444336799 + 
>> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 
>> 784.5488305664002 + 957.3522631840398 + 1001.7526196294
>> print(y)
>> print(y / 15)
>> 
>> Gives:
>> 
>> 14832.682458496522
>> 988.8454972331015
>> 
>> In pharo I have noticed an anomaly which I thought was precision but it may 
>> be something odd with iterators.
>> 
>> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
>> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 
>> 1008.2985131833999 + 1194.956457522 + 893.9680444336799 + 
>> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 
>> 784.5488305664002 + 957.3522631840398 + 1001.7526196294.
>> y.
>> y / 15.
>> 
>> 
>> Gives the same as Python.
>> 
>> 
>> BUT:
>> 
>> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601  . 
>> 1021.6996069333198  . 1019.8750146478401 . 1084.5603759764 . 
>> 1008.2985131833999 . 1194.956457522 . 893.9680444336799 . 
>> 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 
>> 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum.
>> z.
>> z / 15.
>> 
>> 
>> Gives
>> 14832.68245849652
>> 988.8454972331014
>> 
>> Is this correct?
>> 
>> 
> 

Re: [Pharo-users] Pharo float precision vs Python

[Tim Mackinnon]

Actually this isn’t quite so simple - as the problem outline below compounds 
itself by the use of #average (which uses #sum and not #sumNumbers) and thus 
gives a less precise answer.

Why wouldn’t #average use #sumNumbers inside? Or does there need to be 
#averageNumbers as a complement …. Ar it makes my head hurt.

Its important as we compare differently to python and this then makes us waste 
time.

Tim

> On 20 Mar 2020, at 15:19, Tim Mackinnon  wrote:
> 
> Actually I can answer my own question - its the difference between #sum and 
> #sumNumbers (and an easy mistake to make - I almost wish that sum was the 
> sumNumbers implementation and there was a sumSample that behaved like now)
> 
>> On 20 Mar 2020, at 14:52, Tim Mackinnon > > wrote:
>> 
>> Hi guys - I recall this came up a few months ago, but I’m curious about the 
>> difference of Pharo’s use of Float64 vs Python - as I assumed that if 
>> languages use the same IEEE spec (or whatever spec it is) that simple stuff 
>> would be quite similar.
>> 
>> I am curious why in Python adding these numbers:
>> 
>> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
>> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 
>> 1008.2985131833999 + 1194.956457522 + 893.9680444336799 + 
>> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 
>> 784.5488305664002 + 957.3522631840398 + 1001.7526196294
>> print(y)
>> print(y / 15)
>> 
>> Gives:
>> 
>> 14832.682458496522
>> 988.8454972331015
>> 
>> In pharo I have noticed an anomaly which I thought was precision but it may 
>> be something odd with iterators.
>> 
>> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
>> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 
>> 1008.2985131833999 + 1194.956457522 + 893.9680444336799 + 
>> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 
>> 784.5488305664002 + 957.3522631840398 + 1001.7526196294.
>> y.
>> y / 15.
>> 
>> Gives the same as Python.
>> 
>> BUT:
>> 
>> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601  . 
>> 1021.6996069333198  . 1019.8750146478401 . 1084.5603759764 . 
>> 1008.2985131833999 . 1194.956457522 . 893.9680444336799 . 
>> 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 
>> 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum.
>> z.
>> z / 15.
>> 
>> Gives
>> 14832.68245849652
>> 988.8454972331014
>> 
>> Is this correct?
>> 
>> 
> 

Re: [Pharo-users] Pharo float precision vs Python

[Tim Mackinnon]

Actually I can answer my own question - its the difference between #sum and 
#sumNumbers (and an easy mistake to make - I almost wish that sum was the 
sumNumbers implementation and there was a sumSample that behaved like now)

> On 20 Mar 2020, at 14:52, Tim Mackinnon  wrote:
> 
> Hi guys - I recall this came up a few months ago, but I’m curious about the 
> difference of Pharo’s use of Float64 vs Python - as I assumed that if 
> languages use the same IEEE spec (or whatever spec it is) that simple stuff 
> would be quite similar.
> 
> I am curious why in Python adding these numbers:
> 
> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 
> 1008.2985131833999 + 1194.956457522 + 893.9680444336799 + 
> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 
> + 957.3522631840398 + 1001.7526196294
> print(y)
> print(y / 15)
> 
> Gives:
> 
> 14832.682458496522
> 988.8454972331015
> 
> In pharo I have noticed an anomaly which I thought was precision but it may 
> be something odd with iterators.
> 
> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 
> 1008.2985131833999 + 1194.956457522 + 893.9680444336799 + 
> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 
> + 957.3522631840398 + 1001.7526196294.
> y.
> y / 15.
> 
> Gives the same as Python.
> 
> BUT:
> 
> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601  . 
> 1021.6996069333198  . 1019.8750146478401 . 1084.5603759764 . 
> 1008.2985131833999 . 1194.956457522 . 893.9680444336799 . 
> 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 
> . 957.3522631840398 . 1001.7526196294} sum.
> z.
> z / 15.
> 
> Gives
> 14832.68245849652
> 988.8454972331014
> 
> Is this correct?
> 
> 

[Pharo-users] Pharo float precision vs Python

[Tim Mackinnon]

Hi guys - I recall this came up a few months ago, but I’m curious about the 
difference of Pharo’s use of Float64 vs Python - as I assumed that if languages 
use the same IEEE spec (or whatever spec it is) that simple stuff would be 
quite similar.

I am curious why in Python adding these numbers:

y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 
+ 1194.956457522 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 
+ 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294
print(y)
print(y / 15)

Gives:

14832.682458496522
988.8454972331015

In pharo I have noticed an anomaly which I thought was precision but it may be 
something odd with iterators.

y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 
1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 
+ 1194.956457522 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 
+ 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294.
y.
y / 15.

Gives the same as Python.

BUT:

z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601  . 
1021.6996069333198  . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 
. 1194.956457522 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 
. 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} 
sum.
z.
z / 15.

Gives
14832.68245849652
988.8454972331014

Is this correct?

Re: [Pharo-users] Slots vs collections

[Richard Sargent]

On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi  wrote:

> Thanks Julien. So, what I did experienced is because BooleanSlot is work
> in progress.
> To address my issue using slots, I guess collections should implement
> asBit method (Sent by BooleanSlot).
>

Noury, when modelling something like this, think whether "all collections
should implement asBit". I've added the word all, of course. There are so
many possible collections for which #asBit wouldn't make sense that I would
conclude the hypothesis to be incorrect. Even if you were to implement it
on a single collection class, such as Array, there are still so many
examples where #asBit could not apply.

Perhaps, there could be an e.g. Bits class in the Collection hierarchy.
But, even then, it seems to me that there are so many inherited methods
that wouldn't make sense. What would be the use of #do:? What would
#select: mean? You get the idea.

An alternative possibility, and not the only one, is to model the bits as
part of an integer, small or large.

Of course, for performance, a ByteArray might be a good way to store bits.
It has the benefit that every instance *can* represent bits. But, the
inherited API operates on the bytes, not the bits.

Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray
and provides the API that is needed.


That's a rather long answer, admittedly.



> Noury
>
> > On 20 Mar 2020, at 13:56, Julien Delplanque 
> wrote:
> >
> > Hello,
> >
> > There is a work in progress prototype slot named BooleanSlot in the
> Slot-Example package built-in the image.
> >
> > I think this slot does what you want.
> >
> > So, the answer is yes, it is possible to do that. But you will need to
> fix todos left in BooleanSlot methods.
> >
> > Julien
> >
> > Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
> >> Hi,
> >>
> >> Suppose I have an instance variable referencing a collection of
> booleans.
> >> I want to have all elements of the collection be stored as bits.
> >> Is there a way I can express it using slots?
> >>
> >> This idea can be generalized to other types of slots.
> >>
> >> Noury
> >>
> >
>
>
>

Re: [Pharo-users] Slots vs collections

[Noury Bouraqadi]

Thanks Julien. So, what I did experienced is because BooleanSlot is work in 
progress.
To address my issue using slots, I guess collections should implement asBit 
method (Sent by BooleanSlot).

Noury

> On 20 Mar 2020, at 13:56, Julien Delplanque  
> wrote:
> 
> Hello,
> 
> There is a work in progress prototype slot named BooleanSlot in the 
> Slot-Example package built-in the image.
> 
> I think this slot does what you want.
> 
> So, the answer is yes, it is possible to do that. But you will need to fix 
> todos left in BooleanSlot methods.
> 
> Julien
> 
> Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
>> Hi,
>> 
>> Suppose I have an instance variable referencing a collection of booleans.
>> I want to have all elements of the collection be stored as bits.
>> Is there a way I can express it using slots?
>> 
>> This idea can be generalized to other types of slots.
>> 
>> Noury
>> 
> 

Re: [Pharo-users] Best ways to retrieve JSON objects from a feed?

[Sven Van Caekenberghe]

> On 20 Mar 2020, at 14:40, Sven Van Caekenberghe  wrote:
> 
> And a very simple one:
> 
> ZnClient new
>  forJsonREST;
>  get: 'https://api.ipify.org?format=json'.

Here is another cool example:

ZnClient new
  forJsonREST;
  get: 'https://ip.seeip.org/geoip'.

Re: [Pharo-users] Best ways to retrieve JSON objects from a feed?

[Sven Van Caekenberghe]

Hi Tim,

Sure this is possible (with the latest Zn of course):

ZnClient new
  forJsonREST;
  url: 
'http://climatedataapi.worldbank.org/climateweb/rest/v1/country/annualavg/pr';
  addPath: { '20190101'. '20191231'. #bel };
  get.

I do not know how to use this API to get actual data, but the above succeeds 
with an empty JSON result.

If you study #forJsonREST you should be able to figure out how this is done.

Here is another example (from the unit tests):

ZnClient new
  forJsonREST;
  url: 'http://easy.t3-platform.net/rest/geo-ip';
  queryAt: 'address' put: '81.83.7.35';
  get.

And a very simple one:

ZnClient new
  forJsonREST;
  get: 'https://api.ipify.org?format=json'.

Note that the result depends a bit on whether NeoJSON is loaded or not (the 
fallback is to use STONJSON which is always present in the image).

HTH,

Sven

> On 20 Mar 2020, at 14:14, Tim Mackinnon  wrote:
> 
> Hi everyone, I’m finally finding some space from world chaos and looking more 
> into Pharo, and I have a question about retrieving json data from feeds - how 
> is the best way to elegantly parse it - e.g. 
> 
> I am doing :
> 
> url := ZnUrl fromString: 
> 'http://climatedataapi.worldbank.org/climateweb/rest/v1/country/annualavg/pr’.
>  
> url addPathSegments: {aDate1 asString. aDate2 asString. aCountryCode}. 
> result := ZnEasy get: url. 
> content := STONJSON fromString: result contents.
> ...
> 
> However I was kind of surprised there wasn't something on a ZnResponse for 
> getting json objects e.g. 
>  result getJsonObjects 
> 
> or something like that? 
> 
> It’s so common I wonder if I am missing some trick? What aren’t there helpers 
> in place for this or is there a better way to do this that I haven’t found 
> yet?
> 
> 
> I was kind of thinking something like (which obviously I can add myself)
> 
> result asJsonObjects sum: [:obj | (obj at: ‘annualData’) first ]
> 
> Tim

[Pharo-users] Best ways to retrieve JSON objects from a feed?

[Tim Mackinnon]

Hi everyone, I’m finally finding some space from world chaos and looking more 
into Pharo, and I have a question about retrieving json data from feeds - how 
is the best way to elegantly parse it - e.g. 

I am doing :

url := ZnUrl fromString: 
'http://climatedataapi.worldbank.org/climateweb/rest/v1/country/annualavg/pr’. 
url addPathSegments: {aDate1 asString. aDate2 asString. aCountryCode}. 
 result := ZnEasy get: url. 
 content := STONJSON fromString: result contents.
...

However I was kind of surprised there wasn't something on a ZnResponse for 
getting json objects e.g. 
  result getJsonObjects 

or something like that? 

It’s so common I wonder if I am missing some trick? What aren’t there helpers 
in place for this or is there a better way to do this that I haven’t found yet?


I was kind of thinking something like (which obviously I can add myself)

result asJsonObjects sum: [:obj | (obj at: ‘annualData’) first ]

Tim

Re: [Pharo-users] Slots vs collections

[Julien Delplanque]

Hello,

There is a work in progress prototype slot named BooleanSlot in the 
Slot-Example package built-in the image.


I think this slot does what you want.

So, the answer is yes, it is possible to do that. But you will need to 
fix todos left in BooleanSlot methods.


Julien

Le 20/03/20 à 12:24, N. Bouraqadi a écrit :

Hi,

Suppose I have an instance variable referencing a collection of booleans.
I want to have all elements of the collection be stored as bits.
Is there a way I can express it using slots?

This idea can be generalized to other types of slots.

Noury

Re: [Pharo-users] Slots vs collections

[K K Subbu]

On 20/03/20 4:54 PM, N. Bouraqadi wrote:

Hi,

Suppose I have an instance variable referencing a collection of booleans.
I want to have all elements of the collection be stored as bits.
Is there a way I can express it using slots?


What do the bits represent? Is there an ordering among these booleans?

You could use a Set of integers (for ordinals) or symbols (for cardinals 
like flags).


HTH .. Subbu

Re: [Pharo-users] Json encoding

[PBKResearch]

Vitor

 

First clarification: There are two different serialization formats, json and 
STON. The content of a json file can only be number, Boolean, string, array, 
dictionary. STON is an extended form based on json, designed to represent 
(almost) any Smalltalk object.

 

Second clarification: What are you trying to do? Do you want to serialize data 
for your own use, to read back into your own Pharo app? Or do you want to 
export data in json format, so that other users, not using necessarily using 
Pharo, can import it? For the first case, STON is a very flexible and 
convenient system. For the second case, you must stick to strict json, using 
only the classes allowed in json.

 

Coming to your specific examples, Date is not a class allowed in json. This is 
not a limitation of NeoJson or STON, it is a limitation of the definition of 
json. If you want to include a Date in a json file, you must turn it into an 
instance of a permitted class. So you could write:

 

STON toJsonString: Date today asString.

 

The only complication here is, if the json is read by other users, they must 
understand the format generated by Date>>asString.

 

If you are using STON to serialise objects for your own use, you may want to 
exclude some instvars (e.g. block closures). This is described in the class 
comments to the STON-Core package. You need to include a class side message 
#stonAllInstVarNames in the class, which lists the names of the instvars that 
are to be serialized.

 

If you want to go deeper into STON, I think Sven has an article on his website 
telling the whole story. This maybe enough to get you started.

 

HTH

 

Peter Kenny

 

From: Pharo-users  On Behalf Of Vitor 
Medina Cruz
Sent: 20 March 2020 01:20
To: Any question about pharo is welcome 
Subject: [Pharo-users] Json encoding

 

Hello,

 

I know two projects of json encoding/decoding — NeoJson and STON.

 

In Java I have two most used ones too: Gson and Jackson. Using those I can 
simply pass any object and it they can convert to a json string, the former 
can't deal with cycles, the latter can with some little config.

 

NeoJson seems to be limited to primitives, for example, in Pharo 8 I can't run 

 

NeoJSONWriter toString: (Date today)

 

Since I got:

 

NeoJSONMappingNotFound: No mapping found for Date in NeoJSONWriter

 

 

STON works fine with 

 

STON toString: (Date today).

 

but fail with:

 

STON toJsonString: (Date today).

 

Also, STON fails if I try to serialize an object which contains an instance 
variable pointing to a block closure. I didn't find out how to ignore these 
instance variable as it is unnecessary for what I need at the moment. 

 

So, which lib for json or some object/string encoding/decoding should I be 
using on Pharo? Is there something better than those libs? Am I doing something 
wrong? My experience tells this should be simple, but it is not.

 

Thanks in advance,

Vitor

Re: [Pharo-users] Json encoding

[Sven Van Caekenberghe]

Hi Victor,

I would first suggest you read the following two book chapters:

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/NeoJSON/NeoJSON.html

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/STON/STON.html

These should explain the basics and answer a lot of your questions.

Now, from a higher level, you have to understand that without an explicit 
mapping, arbitrary object encoding cannot work for JSON.

Furthermore, since there is no type encoding in JSON, parsing back to the 
original types cannot happen without help, again using an explicit mapping.

In Pharo/Smalltalk, contrary to Java, we are not used to full type descriptions.

Both NeoJSON and STON offer lots of options to do mapping, see the links above 
to get started.

HTH,

Sven 

> On 20 Mar 2020, at 02:20, Vitor Medina Cruz  wrote:
> 
> Hello,
> 
> I know two projects of json encoding/decoding — NeoJson and STON.
> 
> In Java I have two most used ones too: Gson and Jackson. Using those I can 
> simply pass any object and it they can convert to a json string, the former 
> can't deal with cycles, the latter can with some little config.
> 
> NeoJson seems to be limited to primitives, for example, in Pharo 8 I can't 
> run 
> 
> NeoJSONWriter toString: (Date today)
> 
> Since I got:
> 
> NeoJSONMappingNotFound: No mapping found for Date in NeoJSONWriter
> 
> 
> STON works fine with 
> 
> STON toString: (Date today).
> 
> but fail with:
> 
> STON toJsonString: (Date today).
> 
> Also, STON fails if I try to serialize an object which contains an instance 
> variable pointing to a block closure. I didn't find out how to ignore these 
> instance variable as it is unnecessary for what I need at the moment. 
> 
> So, which lib for json or some object/string encoding/decoding should I be 
> using on Pharo? Is there something better than those libs? Am I doing 
> something wrong? My experience tells this should be simple, but it is not.
> 
> Thanks in advance,
> Vitor

[Pharo-users] Slots vs collections

[N. Bouraqadi]

Hi,

Suppose I have an instance variable referencing a collection of booleans.
I want to have all elements of the collection be stored as bits. 
Is there a way I can express it using slots?

This idea can be generalized to other types of slots.

Noury