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
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
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: W
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 bool
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:2
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/v
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
> 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'.
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 prog
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,
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:
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 reca
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
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 an
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 welcom
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 bi
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
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
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 b
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 Bou
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
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 larg
22 matches
Mail list logo
