Re: [Pharo-dev] Pharo Downloads are sluggish

[ponyatov]

Just add Torrent as download variant



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

[Julien]

Hello,

Ok, I read all the mails. I see your point about not cancelling the possibility 
to use #to:by: on any Number.

However, the remark from David Grandi seems really relevant to me.

You can NOT write anything else than a *rational number* when writing a literal 
using the XXX.XXX pattern.

I think it would be legit to generate scaled decimal by default from float 
literals and to be able to get Float only by either explicitly specify it 
(#asFloat, etc…) or because of computation that lead to a Float (e.g. the need 
to approach an irrational number ?).

I would be curious to see the impact of such change in the compiler on the 
system.

Maybe a first step is indeed to implement a rule in Renraku to encourage people 
to use ScaledDecimals.

Cheers,

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

> Le 19 sept. 2018 à 09:22, Davide Grandi  a écrit :
> 
> > 0.0 to: 1.0 by: 0.1
> Receiver and arguments, lexically (the dot), are float BUT
> are written as decimal number (zero, one, one tenth).
> 
> I think that in a text you can ONLY write "decimal" numbers or (in bases 
> other than 10 [or with factors other than 2^x and 5 ?]), at worst, repeating 
> decimals
> (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions.
> 
> So, may be, if the receiver or an argument is a float the compiler may issue 
> a warning and compile to non-float,
> if receiver or arguments are computed ... there should be a default behaviour.
> 
> Best regards,
> 
> Davide Grandi
> (PS : I work mainly in an ERP that has only integers ... and doubles) 
> 
> On 18/09/2018 11:52, Guillaume Larcheveque wrote:
>> Maybe #to:by: should convert its parameters in Fraction to avoid Floats 
>> problems (not sure, just an idea)
>> 
>> 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano > >:
>> 
>>> On 18 Sep 2018, at 11:13, Guillermo Polito >> > wrote:
>>> 
>>> 
>>> 
>>> On Tue, Sep 18, 2018 at 11:06 AM Julien >> > wrote:
>>> Hello,
>>> 
>>> I realised that it is possible to create an interval of floats.
>>> 
>>> I think this is bad because, since intervals are computed by successively 
>>> adding a number, it might result in precision errors.
>>> 
>>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30004 0.4 0.5 
>>> 0.6001 0.7001 0.8 0.9 1.0)
>>> 
>>> The correct (precise) way to do it would be to use ScaledDecimal:
>>> 
>>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 
>>> 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1)
>>> 
>>> I opened an issue about it: 
>>> https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc
>>>  
>>> 
>>> 
>>> And I’d like to discuss this with you.
>>> 
>>> What do you think?
>>> 
>>> Well, I think it's a matter of balance :)
>>> 
>>> #to:by: is defined in Number. So we could, for example, cancel it in Float.
>>> However, people would still be able to do
>>> 
>>> 1 to: 1.0 by: 0.1
>>> 
>>> Which would still show problems.
>> 
>> Nevertheless, I have seen this a lot of times. 
>> 
>> 0.0 to: 1.0 by: 0.1
>> 
>> Is a common use case.
>> 
>>> 
>>> And moreover, we could try to do
>>> 
>>> 1 to: 7 by: (Margin fromNumber: 1)
>>> 
>>> And even worse
>>> 
>>> 1 to: Object new by: (Margin fromNumber: 1)
>>> 
>>> I think adding type-validations all over the place is not a good solution, 
>>> and is kind of opposite to our philosophy...
>>> 
>>> So we should
>>>  - document the good usages
>>>  - document the bad ones
>>>  - and live with the fact that we have a relaxed type system that will fail 
>>> at runtime :)
>> 
>> yup. 
>> But not cancel.
>> 
>> Esteban
>> 
>>> 
>>> Guille
>> 
>> 
>> 
>> 
>> -- 
>> Guillaume Larcheveque
>> 

Re: [Pharo-dev] Platform file encoding for FFI

[Eliot Miranda]

Hi Henry,
On Tue, Sep 18, 2018 at 1:43 AM Henrik Sperre Johansen <
henrik.s.johan...@veloxit.no> wrote:

> Guillermo Polito wrote
> > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant <
>
> > akgrant0710@
>
> > >
> > wrote:
> >
> >> Hi Esteban, Guille and Everyone,
> >>
> >> I haven't looked at using FFI much, however it is easy to imagine that
> >> different file encoding rules on different platforms will make writing
> >> FFI calls more difficult,
> >
> >
> > Well not really (from my point of view :))
> > From the point of view of the FFI call an encoded string is just a bunch
> > of
> > bytes. FFI does not do any interpretation of them.
>
> It *would* be pretty handy for adding some auto-conversion into the
> marshaller based on parameter encoding options though... (other than
> filename, could be done in smalltalk using exisiting encoders)
>
> self
> ffiCall: #(bool saveContentsToFile(String fileName, String contents))
> options: #(+stringEncodings( fileName return , platformAPI contents)
>
> (And yes, I've probably badly mangled the options syntax)
>

Why not go for some generic escape sequence that can inject Smalltalk code
into the marshaling?  Right now e.g.

primExport: aName value: aValue

^ self ffiCall: #(void moz_preferences_set_bool (short* aName, bool aValue))

is compiled as

primExport: arg1 value: arg2
| tmp1 tmp2 |
''
invokeWithArguments:
{(tmp2 := arg1 packToArity: 1).
arg2}

where '' is the ExternalFunction object
(it could usefully print itself ass a literal and then decompilation would
be meaningful; there is already code in the Squeak FFI repository).

Let's say one added {}'s as characters that can't ever appear in C
parameter lists (of course and alas []'s can because of arrays)≥  Then you
could perhaps write

primExport: aName value: aValue

^ self ffiCall: #(void moz_preferences_set_bool ( { short* aName }
asUTF8String, bool aValue))

and have that generate a send of asUTF8String to arg1 or tmp2.  One could
surround the whole thing to apply a coercion to the return value, but
there's no need because one can write e.g.

primExport: aName value: aValue

^(self ffiCall: #(void moz_preferences_set_bool ( { short* aName }
asUTF8String, bool aValue))) fromUTF8String

So then there would be a generic mechanism for in jetting Smalltalk code
into the marshaling and one could develop the string encoding support
independently from the FFI.  The options syntax however requires parsing
support, more documentation, and constant extension to support new
facilities, etc.

Is much less verbose than having to manually convert Strings to the proper
> platform Unicode encodings before calling.
> Depends a bit on whether the primitive argument is
> Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one
> has
> to convert first anyways.
>
> It's not like this isn't a pain point, there are plenty of currently used
> API's that are broken if you try to use non-ascii.
>
> Cheers,
> Henry
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Platform file encoding for FFI

[Alistair Grant]

On Wed, 19 Sep 2018 at 10:26, Guillermo Polito
 wrote:
>
> On Tue, Sep 18, 2018 at 4:40 PM Alistair Grant  wrote:
>>
>> I realise of course that this could all be done in FFI, and I agree with
>> all Estaban's arguments in favour of FFI, my main motivation was that
>> the code is already in the VM, and to avoid code duplication with the
>> obvious benefit that if a bug is fixed it will apply everywhere.
>
>
> Yeh. At the end it's a matter of debugging cycles.
> Imagine making the "compile-restart" steps that you're facing while changing 
> the plugin almost negligible in the "change-compile-restart-test" loop :).

This is true if the code only resides in the image, but in this case
the code won't be going away from the VM any time soon.

Anyway, for whoever does implement the code for FFI the option is always there.

Thanks to everyone for their replies!

Cheers,
Alistair

[Pharo-dev] [Pharo 7.0-dev] Build #1259: 21660-Changing-the-superclass-of-a-Class-using-superclass-method-does-not-update-instSize-correctly

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1259 was: FAILURE.

The Pull Request #1618 was integrated: 
"21660-Changing-the-superclass-of-a-Class-using-superclass-method-does-not-update-instSize-correctly"
Pull request url: https://github.com/pharo-project/pharo/pull/1618

Issue Url: https://pharo.fogbugz.com/f/cases/21660
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1259/

[Pharo-dev] [Pharo 7.0-dev] Build #1258: 22457-Provide-a-CalendarPresenter-fully-written-in-Spec

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1258 was: SUCCESS.

The Pull Request #1804 was integrated: 
"22457-Provide-a-CalendarPresenter-fully-written-in-Spec"
Pull request url: https://github.com/pharo-project/pharo/pull/1804

Issue Url: https://pharo.fogbugz.com/f/cases/22457
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1258/

Re: [Pharo-dev] Pharo Downloads are sluggish

[Esteban A. Maringolo]

Hi Marcus,

Thank you.

Anybody WILLING to use it will wait whatever it takes, but my concern,
and rant, is about these that want to give it a try and will abort it
even before running it.

I'm happily using Pharo in Windows preparing it for a demo I'll be making.


Regards!

On 19/09/2018 10:06, Marcus Denker wrote:
> I will have a look how to improve the situation.
> 
> (I hope to be able to do it by next week).
> 
> Marcus
> 
>> On 19 Sep 2018, at 02:10, Esteban Maringolo > > wrote:
>>
>> After sending the previous email I checked the progress and it was
>> aborted due to a network error.
>>
>> 
>>
>> I retried and apparently the speed got to a more reasonable one, with
>> peaks of 300KB/sec.
>>
>> 
>>
>>
>> My guess is that the bottleneck is at where the files are hosted, and
>> if you attempt to download while maybe there are several CI builds
>> running or something else is using the fileserver bandwidth, then it
>> impacts the overall download speed of those attempting to download
>> just the basic elements.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo
>> (mailto:emaring...@gmail.com>>) escribió:
>>
>> Is there a reason why the latest version of the builds linked from
>> the website are not hosted in some CDN, Amazon S3 or similar?
>>
>> Maybe in Europe the speed is fast, but where I am (Argentina) it
>> is really slow, the screenshot shows 3.5KB/s, it averages 10KB/s,
>> with peaks of 40KB/s.
>>
>> This is an pitiful boarding experience, that will make many cancel
>> it even before getting to open the downloaded launcher.
>>
>> 
>>
>> The screenshot shows that is not a problem with my home
>> connection, which isn't the fastest but is "normal" for my use cases.
>>
>> Regards,
>>
>> Esteban A. Maringolo
>>
>> ps: When I finished writing this email, this was the progress...
>> 
>>
> 

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Pharo Downloads are sluggish

[Marcus Denker]

I will have a look how to improve the situation.

(I hope to be able to do it by next week).

Marcus

> On 19 Sep 2018, at 02:10, Esteban Maringolo  wrote:
> 
> After sending the previous email I checked the progress and it was aborted 
> due to a network error.
> 
> 
> 
> I retried and apparently the speed got to a more reasonable one, with peaks 
> of 300KB/sec.
> 
> 
> 
> 
> My guess is that the bottleneck is at where the files are hosted, and if you 
> attempt to download while maybe there are several CI builds running or 
> something else is using the fileserver bandwidth, then it impacts the overall 
> download speed of those attempting to download just the basic elements.
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 
> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo ( >) escribió:
> Is there a reason why the latest version of the builds linked from the 
> website are not hosted in some CDN, Amazon S3 or similar?
> 
> Maybe in Europe the speed is fast, but where I am (Argentina) it is really 
> slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks of 40KB/s.
> 
> This is an pitiful boarding experience, that will make many cancel it even 
> before getting to open the downloaded launcher.
> 
> 
> 
> The screenshot shows that is not a problem with my home connection, which 
> isn't the fastest but is "normal" for my use cases.
> 
> Regards,
> 
> Esteban A. Maringolo
> 
> ps: When I finished writing this email, this was the progress...
> 

[Pharo-dev] [Pharo 7.0-dev] Build #1257: 22469-Small-cleanup-in-NEC-Model-classes

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1257 was: FAILURE.

The Pull Request #1815 was integrated: 
"22469-Small-cleanup-in-NEC-Model-classes"
Pull request url: https://github.com/pharo-project/pharo/pull/1815

Issue Url: https://pharo.fogbugz.com/f/cases/22469
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1257/

[Pharo-dev] [Pharo 7.0-dev] Build #1256: 22448 Cleanup ManifestSystemModel and related package

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1256 was: FAILURE.

The Pull Request #1796 was integrated: "22448 Cleanup ManifestSystemModel and 
related package"
Pull request url: https://github.com/pharo-project/pharo/pull/1796

Issue Url: https://pharo.fogbugz.com/f/cases/22448
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1256/

Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format

[Julien]

Hello,Le 18 sept. 2018 à 16:45, Sven Van Caekenberghe  a écrit :Hi Julien,Good and interesting point.Your summary is correct: STON, inheriting from JSON so to speak, only knowns about integer and float numbers. All other Smalltalk numbers get converted, which results in a loss of type and precision. That might not be a perfect situation, but nobody complained so far.That’s what I guessed to be the reason of this feature. :-)If we would change it, efficiency has to be taken into account: speed/memory efficiency as well as human typing efficiency/complexity. Compatibility, especially between different Smalltalk and other object languages, is also an aspect.Apart from the current approach, the full STON approach could be, for example for 1/3 and 1.5s2Fraction { #numerator:1, #denominator:3 }ScaledDecimal { #numerator:3, #denominator:2, #scale:2}For some types, STON uses shorter notations, either using positional arguments Point [ 1, 2 ]Fraction [ 1, 3 ]ScaledFraction [ 3, 2, 2 ]Or a string argument, when there is a clear external representationDateAndTime [ '2018-09-18T16:39:10.325129+02:00' ]Fraction [ '1/3' ]ScaledFraction [ '3/2s2' ]Of course, we could also extend the basic number parser and allow the native (stored) notation1/33/2s2Note how that last one should use the more exact #storeOn: notation, not the #printOn: I'll have to think about this a bit more, as I can really not choose right now.SvenTell me if you need help to implement this feature, I’ll be happy to contribute! :-)Cheers,Julien---Julien DelplanqueDoctorant à l’Université de Lillehttp://juliendelplanque.be/phd.htmlEquipe Rmod, InriaBâtiment B 40, Avenue Halley 59650 Villeneuve d'AscqNuméro de téléphone: +333 59 35 86 40

Re: [Pharo-dev] Platform file encoding for FFI

[Guillermo Polito]

On Tue, Sep 18, 2018 at 4:40 PM Alistair Grant 
wrote:

> > I haven't looked at using FFI much, however it is easy to imagine
> that
> > different file encoding rules on different platforms will make
> writing
> > FFI calls more difficult,
> >
> > Well not really (from my point of view :))
> > From the point of view of the FFI call an encoded string is just a bunch
> of
> > bytes. FFI does not do any interpretation of them.
>
> Right, but getting the appropriately encoded bunch of bytes is the issue.
> :-)
>
>
Yes, the thing is that this would require some new extensions in uFFI to
support encodings.
The good point of that is that that would have a positive impact in ***ALL**
FFI bindings using strings (by making explicit to people that they should
care about encodings :)).


> > Maybe... Are the OSX routines exposed as C functions (that we can call
> through
> > FFI) or they are objective-C methods/functions (that are more
> complicated to
> > map)?
>
> The OSX routines are exposed as C functions (and available as
> Objective-C methods), see convertChars() in
> platforms/unix/vm/sqUnixCharConv.c.
>

Nice!

On Tue, Sep 18, 2018 at 11:21:41AM +0200, Esteban Lorenzano wrote:
> > > self
> > >ffiCall: #(bool saveContentsToFile(String fileName, String
> contents))
> > >options: #(+stringEncodings( fileName return , platformAPI contents)
> >
> > This is cool.
> > What I do not like is to rely on primitives to do that encoding.
> > This should be in image??? using FFI if needed (this is all because we
> > want to rely less and less on plugins :P)
>
> I realise of course that this could all be done in FFI, and I agree with
> all Estaban's arguments in favour of FFI, my main motivation was that
> the code is already in the VM, and to avoid code duplication with the
> obvious benefit that if a bug is fixed it will apply everywhere.


Yeh. At the end it's a matter of debugging cycles.
Imagine making the "compile-restart" steps that you're facing while
changing the plugin almost negligible in the "change-compile-restart-test"
loop :).

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

[Davide Grandi]

> 0.0 to: 1.0 by: 0.1
Receiver and arguments, lexically (the dot), are float BUT
are written as decimal number (zero, one, one tenth).

I think that in a text you can ONLY write "decimal" numbers or (in bases 
other than 10 [or with factors other than 2^x and 5 ?]), at worst, 
repeating decimals

(eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions.

So, may be, if the receiver or an argument is a float the compiler may 
issue a warning and compile to non-float,
if receiver or arguments are computed ... there should be a default 
behaviour.


Best regards,

    Davide Grandi
(PS : I work mainly in an ERP that has only integers ... and doubles)

On 18/09/2018 11:52, Guillaume Larcheveque wrote:
Maybe #to:by: should convert its parameters in Fraction to avoid 
Floats problems (not sure, just an idea)


2018-09-18 11:25 GMT+02:00 Esteban Lorenzano >:




On 18 Sep 2018, at 11:13, Guillermo Polito
mailto:guillermopol...@gmail.com>> wrote:



On Tue, Sep 18, 2018 at 11:06 AM Julien
mailto:julien.delplan...@inria.fr>>
wrote:

Hello,

I realised that it is possible to create an interval of floats.

I think this is bad because, since intervals are computed by
successively adding a number, it might result in precision
errors.

(0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2
0.30004 0.4 0.5 0.6001
0.7001 0.8 0.9 1.0)

The correct (precise) way to do it would be to use ScaledDecimal:

(0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1
0.3s1 0.4s1 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1)

I opened an issue about it:

https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc



And I’d like to discuss this with you.

What do you think?


Well, I think it's a matter of balance :)

#to:by: is defined in Number. So we could, for example, cancel it
in Float.
However, people would still be able to do

1 to: 1.0 by: 0.1

Which would still show problems.


Nevertheless, I have seen this a lot of times.

0.0 to: 1.0 by: 0.1

Is a common use case.



And moreover, we could try to do

1 to: 7 by: (Margin fromNumber: 1)

And even worse

1 to: Object new by: (Margin fromNumber: 1)

I think adding type-validations all over the place is not a good
solution, and is kind of opposite to our philosophy...

So we should
 - document the good usages
 - document the bad ones
 - and live with the fact that we have a relaxed type system that
will fail at runtime :)


yup.
But not cancel.

Esteban



Guille





--
*Guillaume Larcheveque*

[Pharo-dev] [Pharo 7.0-dev] Build #1255: 20111-Some-Collection-tests-fail-on-64-bit-because-they-assume-Floats-are-non-immediate

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1255 was: SUCCESS.

The Pull Request #1624 was integrated: 
"20111-Some-Collection-tests-fail-on-64-bit-because-they-assume-Floats-are-non-immediate"
Pull request url: https://github.com/pharo-project/pharo/pull/1624

Issue Url: https://pharo.fogbugz.com/f/cases/20111
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1255/