BTW rountTo: does not solve my problem.
I will check the printing solution.
On Tue, Dec 26, 2017 at 11:51 PM, Nicolas Cellier
wrote:
> Hi Hilaire,
> it' not just funny: it's the exact case round: was made for.
> Note that there is an opened issue suggesting
Hi nicolas
Thanks for the information of color I was also looking for it. The
other packages that extended color used 1/1000 so I followed the
pattern.
I was thinking that I should use something like "printInexactlyOn:"
Now (too early for my brain to work) but I'm wondering the different
between
Hi Ronie,
Have a look at:
https://github.com/hernanmd/MetacelloFileDownload
Best regards,
Hernán
2017-12-26 22:43 GMT-03:00 Ronie Salgado :
> Hi All,
>
> During the last month I have been doing a massive refactoring to Woden 2. By
> using Lowtalk for the math library,
Hi All,
During the last month I have been doing a massive refactoring to Woden 2.
By using Lowtalk for the math library, the requirement on the Lowcode VM is
now optional. However, there are still some native library dependencies
required for distributing Woden:
- AbstractGpu, a wrapper for
There is a port to Pharo (and gemstone) of Chronos here:
http://smalltalkhub.com/#!/~Chronos/Chronos
I think I last tested it in Pharo 4.
publius789 wrote
> This is very helpful. Nice holiday weekend reading!
>
> Sure, if its not too much trouble you can send it to me.
>
> Thanks.
>
>
Hi Hilaire,
it' not just funny: it's the exact case round: was made for.
Note that there is an opened issue suggesting the removal of round: (no
time to check the exact ref now).
Alternatives if round: is deprecated could be:
(c / 255 roundTo: 1/1000) asFloat.
(c / 255 roundTo: 0.001s) asFloat.
2017-12-25 23:54 GMT+01:00 Ben Coman :
> As a half-way house, consider that "upgrade" scripts could be a good
> mechanism
> post-Release when changes should be less-deep/less-arduous on the system.
> This might avoid Esteban's time being needed to re-Release for each
>
It i s funny to note how #round: message seems to have more success for
that:
0.94201 round: 3.
"0.942"
Le 26/12/2017 à 21:27, Stephane Ducasse a écrit :
0.94201 roundUpTo: 0.001
and the same truncatedTo: 0.001
do not work
--
Dr. Geo
http://drgeo.eu
Hi Hilaire
yes you can have multiple approaches. I was focusing on tiles-based
ones: sokoban, miners..
SDL2.0 is our plan.
For Cairo we asked Bloc guys to make sure that we can use Cairo as
back end to avoid to have 20 mb by default
with Mozz2d (and mozz2d is not really packaged by their creators
Hi Evan
yes thierry was discussing with clement and we will see :).
Stef
On Mon, Dec 25, 2017 at 6:55 PM, Evan Donahue wrote:
> Given the recent stirrings of AI-related applications in Pharo, I guess I'm
> wishing for vm support for vector operations/fast math. I heard
Yes saw and my second answer took that into account. We were
discussing about making sure that we can write applications vs. code.
We should be able to package an application.
The experience accumulated with the launcher and the effort on making
Pharo silent (not forcing to write everywhere files)
Hi
I'm working on improving the number of named colors we have.
I got this list
And I did the following to convert numbers to float and I want to keep
only max three decimal
Now I do not get
0.94201 roundUpTo: 0.001
and the same truncatedTo: 0.001
do not work
list collect: [ :each |
|
Read. SDL + Cairo is the way you have been. I did not imagine Cairo was
good at manipulating block of bitmap.
Is Cairo stable over time in Pharo? I wonder will it be wiped out. More
generally, I wonder what is the stable ground to build graphic
application on Pharo?
Le 25/12/2017 à 19:32,
I meant more tests in DrGeo to expose its features, and to discover
where newer Pharo breaks it.
Hilaire
Le 25/12/2017 à 23:59, Ben Coman a écrit :
really took me a long time to get drgeo right on P3 because these
oddities only show up at runtime, under specific scenario. There
14 matches
Mail list logo