On Sun, Mar 13, 2016 at 9:27 AM, Ben Coman wrote:
>
>
> On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel
> wrote:
>
>> Hi
>>
>> At some point I got a feeling that actual Delay time is longer than
>> expected. It is especially visible on small delays
On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel
wrote:
> Hi
>
> At some point I got a feeling that actual Delay time is longer than
> expected. It is especially visible on small delays less than 100ms
> (otherwise difference is < 1%).
>
> [image: Inline image 1]
>
On Sat, Mar 12, 2016 at 5:27 PM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:
> Hi guys,
>
> Frequently I need to serialize contents from an inspector/explorer for
> later work or because image cannot work with big data sets.
> Do you find yourself doing this from an inspector?
>
>
Sent from my iPhone
On 12 mars 2016, at 21:01, Aliaksei Syrel wrote:
>> I get a BoxedFloat64(61.5)
>
> Very strange...
>
> For some unexpected reason you get integers in delay test. But all values
> should be floats. I double checked the script..
>
> There is a
> On 12 Mar 2016, at 21:27, Hernán Morales Durand
> wrote:
>
> Hi guys,
>
> Frequently I need to serialize contents from an inspector/explorer for later
> work or because image cannot work with big data sets.
> Do you find yourself doing this from an inspector?
>
>
> On 12 Mar 2016, at 21:22, Tudor Girba wrote:
>
> Hi,
>
> I meant to ask if you confirm that the rendering looks like the DejaVu font
> :). I know it was not intentional.
>
> Indeed, I confirm that just saving fixed the problem.
>
> I checked the issue tracker and I
Hi,
I meant to ask if you confirm that the rendering looks like the DejaVu font :).
I know it was not intentional.
Indeed, I confirm that just saving fixed the problem.
I checked the issue tracker and I did not find a bug. Is there such a report or
should I create one?
Cheers,
Doru
> On
The numbers in that csv from is in float, but with the fraction part is 0.
This is most likely caused by the fact that the precision for timing is in
milliseconds, not microseconds.
Even the #primUTCMicrosecondsClock only updates per millisecond for me.
(Windows).
((1 to: 10) collect: [:n
>
> I get a BoxedFloat64(61.5)
Very strange...
For some unexpected reason you get integers in delay test. But all values
should be floats. I double checked the script..
There is a difference in arithmetic behaviour between mac and windows!
Cheers,
Alex
On Sat, Mar 12, 2016 at 8:48 PM, Cyril
Le 12/03/2016 20:44, Aliaksei Syrel a écrit :
> I think we just found a serious bug!
>
> Cyrill, could you perform a division in the same image you used for
> delay test and post result here?
>
> 123 / 2.0
>
I get a BoxedFloat64(61.5)
--
Cyril Ferlicot
http://www.synectique.eu
165
I think we just found a serious bug!
Cyrill, could you perform a division in the same image you used for delay
test and post result here?
> 123 / 2.0
On mac I get a float 61.5
Cheers,
Alex
On Sat, Mar 12, 2016 at 8:33 PM, Cyril Ferlicot D. wrote:
> Le 12/03/2016
Le 12/03/2016 18:47, Aliaksei Syrel a écrit :
> Hi
>
> At some point I got a feeling that actual Delay time is longer than
> expected. It is especially visible on small delays less than 100ms
> (otherwise difference is < 1%).
>
> Inline image 1
> Documentation says that _Delay waits
*Difference is in milliseconds*, sorry :)
On Sat, Mar 12, 2016 at 6:47 PM, Aliaksei Syrel
wrote:
> Hi
>
> At some point I got a feeling that actual Delay time is longer than
> expected. It is especially visible on small delays less than 100ms
> (otherwise difference is <
Hi
At some point I got a feeling that actual Delay time is longer than
expected. It is especially visible on small delays less than 100ms
(otherwise difference is < 1%).
[image: Inline image 1]
Documentation says that *Delay waits approximately* for specified amount of
time. However, according
bah… “fix it” in the sense that correct fonts will be restored :)
> On 12 Mar 2016, at 14:19, Tudor Girba wrote:
>
> Hi,
>
> It looks to me as if in the latest Pharo, the default font is rendered with
> the DejaVu bitmap font instead of Source Sans Pro.
>
> Here is
Yes, that’s right.
> On 12 Mar 2016, at 14:19, Tudor Girba wrote:
>
> Hi,
>
> It looks to me as if in the latest Pharo, the default font is rendered with
> the DejaVu bitmap font instead of Source Sans Pro.
>
> Here is how the font looks like in Nautilus (look at the
no, I do not confirm (that the defaults are DejaVu): it is a bug.
what actually happens is an effect of the infamous “font bug” that is around.
in fact, if you have that effect with a latest image you should not need to
reload fonts, just saving image will fix it.
> On 12 Mar 2016, at 14:19,
Message transféré
Sujet : Really usability fix for Versionner
Date : Sat, 12 Mar 2016 13:25:43 +0100
De :stepharo
Pour : Pharo Development List
Hi
I checked with christophe and it is IMPOSSIBLE to use Versionner
Le 12/3/16 09:44, jannik laval a écrit :
Hi pharoers,
What is the status of pharo for android and pharo for iOS ?
For android not much changes. I was pushing but nothing came out.
I'm sorry.
Stef
Thank you for the answer
--
~~Jannik Laval~~
Enseignant-chercheur
Responsable Pédagogique
Hi pharoers,
What is the status of pharo for android and pharo for iOS ?
Thank you for the answer
--
~~Jannik Laval~~
Enseignant-chercheur
Responsable Pédagogique Licence Coordonnateur de Projet en Système
d'Information
IUT Lumière, Université Lyon Lumière
laboratoire DISP
here
https://github.com/SquareBracketAssociates/PharoInProgress
On Sat, Mar 12, 2016 at 10:10 AM stepharo wrote:
> Hi esteban
>
> Where did you publish the doc/tutorial of uFFI?
>
> Stef
>
>
>
>
Hi esteban
Where did you publish the doc/tutorial of uFFI?
Stef
Monty
What would be really gorgeous is to revisite the method comments with
the idea that people
do not know SAX.
characters: aString
"This call corresponds to the Java SAX call
characters(char[] ch, int start, int length)."
was not really useful to me. I got no idea about it. So I
23 matches
Mail list logo