Hi - This is more of an FYI than anything
I'm interacting with an API that is sending "expires=0" value as part of the
only cookie of their response.
Changing #expiresTimeStamp to
(self expires isNil or:[self expires size<28] ) ifTrue:[ ^ DateAndTime now + 1
day ].
^ ZnUtils pa
Guillermo Polito wrote
> I've done also some profiling and it does not look like we've lost in
> performance either (reading and decoding a 35MB file):
Your 1st (new API) example: "0:00:00:01.535"
Your 2nd (old API) example:"0:00:00:01.732"
*** but ***
Your 1st (new API) example using the same con
Clement I added a little section right at the beginning on car/cdr and others.
Tx
On Sun, Mar 18, 2018 at 11:32 AM, Clément Bera wrote:
> p.3
> simpliciyty -> simplicity
>
> p.4
> we will have the define their semantics.
> -> to define ? I am not sure I understand the sentence
>
> p.10
> and may
Since I was born in lisp it looks natural to me so I will imporve the cdr use
tx for this feedback
On Sun, Mar 18, 2018 at 11:32 AM, Clément Bera wrote:
> p.3
> simpliciyty -> simplicity
>
> p.4
> we will have the define their semantics.
> -> to define ? I am not sure I understand the sentence
Yes there!
Tx in advance for copy edition.
Stef
On Sun, Mar 18, 2018 at 4:59 PM, Cyril Ferlicot
wrote:
>
> On dim. 18 mars 2018 at 16:24, Sean P. DeNigris
> wrote:
>>
>> Stephane Ducasse-3 wrote
>> > I would like to get feedback and fix
>> > what can be fixed.
>>
>> Is there a public link to t
+ 1
:)
On Mon, Mar 19, 2018 at 2:16 PM, Petr Fischer wrote:
> That sounds correct. In this context, my "universal ifTrue:" is really
> terrible idea.
>
> Thanks for clarification! pf
>
>
>> Why would you do such aberration?
>>
>> It goes against the "fail noisily" "Rule of Repair": Developers s
I love the idea of measuring statement :)
On Mon, Mar 19, 2018 at 6:10 PM, Guillermo Polito wrote:
> Well, I'd say it we did it in the name of modularity. And yes, I believe
> that having separate responsibilities help in designing, testing and
> ensuring more easily the correctness of each of
Thanks Guille for this great post!
I will turn it into a doc :)
On Mon, Mar 19, 2018 at 6:10 PM, Guillermo Polito wrote:
> Well, I'd say it we did it in the name of modularity. And yes, I believe
> that having separate responsibilities help in designing, testing and
> ensuring more easily the
Yes we should migrate it and probably include it in Pharo and clean it.
Stef
On Mon, Mar 19, 2018 at 6:59 PM, Mariano Badoglio
wrote:
> Hi Stephean, Sean,
>
> Thanks for your response. I have installed the Monticello Package
> "Sound" from http://smalltalkhub.com/mc/PharoExtras/Sound/main, the l
https://www.hrworks.de/en/international-applicants/
Stef
Hi Stephean, Sean,
Thanks for your response. I have installed the Monticello Package
"Sound" from http://smalltalkhub.com/mc/PharoExtras/Sound/main, the last
update is Sound-StephaneDucasse.80 package from year 2013. It is from
Pharo Extras. Is this the right package?
Best regards,
Mariano
El 1
Well, I'd say it we did it in the name of modularity. And yes, I believe
that having separate responsibilities help in designing, testing and
ensuring more easily the correctness of each of the parts in isolation.
I've done also some profiling and it does not look like we've lost in
performance ei
The idea of stacking things like character coding and buffering &c
by using layers of wrapping is very much in the spirit of Java and
is neither good for performance nor helpful for correctness.
On 20 March 2018 at 05:19, Guillermo Polito
wrote:
> Hi all,
>
> I've put some minutes summarizing t
Hi all,
I've put some minutes summarizing the new APIs provided by the combination
of the new File implementation and the Zn encoders. They all basically
follow the decorator pattern to stack different responsibilities such as
buffering, encoding, line ending convertions.
Please, do not hesitate
The idea in Smalltalk is to push a method as high as makes sense
and no higher, so that if you send a message to an object where it
really does not make sense (like trying to add two strings) you
get a runtime failure. (Try asking an old-timer about automatic
conversions in PL/I some time.) Now L
That sounds correct. In this context, my "universal ifTrue:" is really terrible
idea.
Thanks for clarification! pf
> Why would you do such aberration?
>
> It goes against the "fail noisily" "Rule of Repair": Developers should
> design programs that fail in a manner that is easy to localize and
> On 19 March 2018 at 13:40, Petr Fischer wrote:
>
> > > How would you define the semantics of
> > >
> > > 123 ifTrue: [ ... ]
> >
> > 123 is not "true", so, ignore the block.
> >
>
> What anout 123 ifFalse: [ … ], then, given that 123 is not false either?
Yes :) 123 is not false, so ignore the
Why would you do such aberration?
It goes against the "fail noisily" "Rule of Repair": Developers should
design programs that fail in a manner that is easy to localize and
diagnose or in other words “fail noisily”. This rule aims to prevent
incorrect output from a program from becoming an input an
On 19 March 2018 at 13:40, Petr Fischer wrote:
> > How would you define the semantics of
> >
> > 123 ifTrue: [ ... ]
>
> 123 is not "true", so, ignore the block.
>
What anout 123 ifFalse: [ … ], then, given that 123 is not false either?
> Infinite recursion ?
>
> You use #ifTrue: in your implementation of Object>>#ifTrue:
>
> Plus, non-booleans cannot meaningfully respond.
>
> How would you define the semantics of
>
> 123 ifTrue: [ ... ]
123 is not "true", so, ignore the block.
Do the ifTrue block only if the receiver is ins
On 19 March 2018 at 16:05, Peter Uhnák wrote:
> Certainly.
>
> Basically I want to avoid a situation, where diving in would result in an
> empty spotter:
>
>
>
>
>
> So instead I would like to remove the dive in capability (both the icon,
> and the action), when the result will be empty. (And of
Infinite recursion ?
You use #ifTrue: in your implementation of Object>>#ifTrue:
Plus, non-booleans cannot meaningfully respond.
How would you define the semantics of
123 ifTrue: [ ... ]
> On 19 Mar 2018, at 10:18, Petr Fischer wrote:
>
> Hello, I have some sort of philosophical question ab
Hello, I have some sort of philosophical question about ifTrue:/ifFalse:
implementation.
Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True
and False classes, so, we can send this message to the boolean expressions
(instances) only, otherwise DND occurs.
But we can
That can be an option.
Doru
> On Mar 19, 2018, at 9:52 AM, Peter Uhnák wrote:
>
> So I imagine something like the following
>
> spotterFieldsFor: aStep
>
> ^ aStep listProcessor
> title: 'Fields';
> canDiveIn: [ false "or some dynamic condition" ];
>
So I imagine something like the following
spotterFieldsFor: aStep
^ aStep listProcessor
title: 'Fields';
*canDiveIn: [ false "or some dynamic condition" ];*
...
On Mon, Mar 19, 2018 at 9:05 AM, Peter Uhnák wrote:
> Certainly.
>
> Basically I want to avoid a situation, where diving in would res
Certainly.
Basically I want to avoid a situation, where diving in would result in an
empty spotter:
So instead I would like to remove the dive in capability (both the icon,
and the action), when the result will be empty. (And of course keep it if
there will be something).
Ideally it should b
26 matches
Mail list logo
