December 2017 - Pharo-dev - lists.pharo.org

an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

by Esteban Lorenzano

Hi all, Sven Iâm doing some experiments with twitter and posting and I found that twitter does not accept a post with $? in the status string (it throws an error). Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from the safe set it works correctly. the question is: this is a twitter error or a ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldnât be considered safe (and then it should be percent encoded?) cheers, Esteban

Dec. 28, 2017

Can't load libgit2 in 7.0 on some major Linux distros

by Martin McClure

Took my first crack at running 7.0 last night. 64-bit, on Linux. Iceberg won't open; says that libgit2 is the wrong version. After some investigation, this is because: It's picking up the system's version of libgit2, not the version included with the vm. This is because: The version included with the VM depends on libcurl-gnutls.so.4. This library is not packed with the VM, nor is it on my system. A bit more investigation shows that although Ubuntu does seem to typically use libcurl-gnutls.so, other distributions (Red Hat / CentOS, Gentoo) do not. My Gentoo system's /usr/lib64/libgit2.so.0.24.6 depends on libcurl.so.4, not on libcurl-gnutls.so.4. I haven't looked at API differences and such, but would it be possible for Pharo to build libgit2 against libcurl instead of against libcurl-gnutls? Libcurl seems to be present on Ubuntu systems as well as on CentOS/RedHat and Gentoo, so might work more widely. Regards, -Martin

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Martin McClure

On 12/26/2017 12:27 PM, Stephane Ducasse wrote: > 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 "float" and "three decimal" are fundamentally incompatible goals. Float is a binary format, not decimal, so you cannot expect results to always be exact in decimal. > > Now I do not get > > 0.9420000000001 roundUpTo: 0.001 There are many numbers that cannot be represented exactly as floats. 1/1000 is one of them: 0.001 > (1/1000)Â Â Â Â Â --->Â true So what you're actually asking for is to round to some multiple of a binary number that is close to, but not quite exactly, 1/1000. Therefore, #roundUpTo: determines (correctly) that the answer should be 943 * 0.001, and computes that, and answers it. But since 0.001 is greater than 1/1000, the result is greater than 943/1000. There are a number of conceivable alternatives, depending on what you want. But here, it's not clear why you want to do rounding at all in this case -- the expense of a float is the same whether rounded or not, so if you want floats I'd leave them unrounded and therefore more accurately approximating the original input numbers. Or if you want them exact, use fractions instead of floats. Regards, -Martin

Dec. 27, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Bernhard Pieber

Hi Esteban, Thanks for asking. My one and only wish is more stability for the stable version, i.e. bug fixes for Pharo 6, especially the VMs but also the image. Thanks for Pharo! Cheers, Bernhard > Am 23.12.2017 um 17:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi everybody, > > This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year. > Features, improvements, radical changes, etcâ¦. whatever you want. > > Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :) > > So, letâs those wishes come! > > cheers, > Esteban

Dec. 27, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Cyril Ferlicot D.

On 12/23/2017 06:57 PM, Cyril Ferlicot D. wrote: > On 12/23/2017 05:58 PM, Esteban Lorenzano wrote: >> Hi everybody, >> > > Hi :) > >> This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year. >> Features, improvements, radical changes, etcâ¦. whatever you want. >> > > I'll list the things I wanted the most those last months :) > > - To be able to load a private git project from a private server via > Metacello API > - To be able to depend on a git project from a private server in > BaselineOf/ConfigurationOf > - 64bits vm more recent that does not crash 1/4 of the time (It would > help to deploy apps for some customers with older linux distributions) > - 64bits Windows vm (But as far as I know, there is progress on this > side already) > - Continue to push Iceberg (I am not really specific because I want a > lot on that part. For more details, I open issues on Iceberg repository > often :) ) > > All those points are in the optic to make business with Pharo easier. I also forgot: a real headless :) > >> Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :) >> > > Of course :) > >> So, letâs those wishes come! >> > > Also, I would like to thanks everyone because I really like my Pharo > journey and it would not be possible without you! :) > >> cheers, >> Esteban >> > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Hilaire

My funny was ironical because ;-) : 1. I just learn about this #round: method. 2. it is doing a better job than #roundTo: 3. it is mathematically identical to #roundTo: but use positive power of 10 whereas the former use negative power of 10. I guess it produces a different impact on the internal representation of Float as powers of 2 sum It is doing a better job, it correctly rounds 1.45 to 1.5 and not 1.4: 1.45 roundTo: 0.1 "1.4000000000000001" 1.45 round: 1 "1.5" It looks like the right method to deprecate will be roundTo:, or may be there are cases when one method is better, and vis versa. I am curious. Le 26/12/2017 Ã 23:51, Nicolas Cellier a Ã©critÂ : > 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). -- Dr. Geo http://drgeo.eu

Dec. 27, 2017

Re: [Pharo-dev] Calendrical capabilities

by Stephane Ducasse

Excellent I did not know it. Stef On Wed, Dec 27, 2017 at 1:54 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > 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. >> >> Regards, >> Jim >> >> -----Original Message----- >> From: Pharo-dev [mailto: > >> pharo-dev-bounces@.pharo > >> ] On Behalf Of Stephane Ducasse >> Sent: Saturday, December 23, 2017 5:02 PM >> To: Pharo Development List < > >> pharo-dev@.pharo > >> > >> Subject: Re: [Pharo-dev] Calendrical capabilities >> >> Aconcagua is available via the catalog. >> Here is what I found in my harddisc about chronos. >> I can send you the zipped file with old code (probably should be ported to >> Pharo). >> >> >> On Sat, Dec 23, 2017 at 10:32 PM, < > >> publius789@ > >> > wrote: >>> I am new to the Pharo world and looking at capabilities for potential >>> applications. >>> >>> >>> >>> One of the first things I am interested in is Calendar processing >>> capabilities. I havenât had a chance to look at the code yet, but >>> specifically how much does Pharoâs Date/Calendar capabilities match >>> that in the java.util package for Java 9? Additionally, is there any >>> way to give the number of business days between two dates for a >>> particular local calendar? If so, whatâs the format for a local >>> calendar? >>> >>> >>> >>> Iâm going to take a look at the code shortly, but if anyone can shed a >>> general light what currently exists it would be greatly appreciated. >>> >>> >>> >>> Regards, >>> >>> Jim > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 27, 2017

Re: [Pharo-dev] Distributing native libraries with Metacello

by Stephane Ducasse

Hi ronie We were discussing with guille that we need a notion of project repository so that people can access to external resources once they clone their repo. Right now we can use IceRepository "default". Stef On Wed, Dec 27, 2017 at 2:43 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > 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 graphics API (Vulkan, Metal and D3D12). > - AbstracPhysicsa wrapper for physics engines (Bullet). > > I saw that when loading Bloc via the Metacello script, it does download the > Moz2D dependency. So, I am wondering how I could do the same for Woden?. > > There is also a dependency on the data present in a repository with some > core assets, mostly the required shaders, and some textures. I am also > wondering wondering on how I could tell Metacello to clone this repository, > or download its zip file from GitHub? > > Best regards, > Ronie

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Stephane Ducasse

BTW rountTo: does not solve my problem. I will check the printing solution. On Tue, Dec 26, 2017 at 11:51 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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. > > I didn't verify if Pharo did change that, but Squeak RGB color components > have 10 bits internally. > 10 bits is 1024. > So rounding to 1/1000 was not enough to distinguish different colors. > > Nicolas > > > > 2017-12-26 22:26 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: >> >> It i s funny to note how #round: message seems to have more success for >> that: >> >> 0.9420000000001 round: 3. >> "0.942" >> >> >> >> Le 26/12/2017 Ã 21:27, Stephane Ducasse a Ã©crit : >>> >>> 0.9420000000001 roundUpTo: 0.001 >>> and the same truncatedTo: 0.001 >>> do not work >> >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Stephane Ducasse

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 round and roundUpTo: I remember that once we discuss having an exact method where we can pass the precision. Stef On Tue, Dec 26, 2017 at 11:51 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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. > > I didn't verify if Pharo did change that, but Squeak RGB color components > have 10 bits internally. > 10 bits is 1024. > So rounding to 1/1000 was not enough to distinguish different colors. > > Nicolas > > > > 2017-12-26 22:26 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: >> >> It i s funny to note how #round: message seems to have more success for >> that: >> >> 0.9420000000001 round: 3. >> "0.942" >> >> >> >> Le 26/12/2017 Ã 21:27, Stephane Ducasse a Ã©crit : >>> >>> 0.9420000000001 roundUpTo: 0.001 >>> and the same truncatedTo: 0.001 >>> do not work >> >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

Dec. 27, 2017