August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] #< if at first you dont succeed..

by Schwab,Wilhelm K

Ken, You seem determined to have the behavior of Float change when the complex package is installed, and there are various objections to that from multiple people; those objections are well founded. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Friday, August 14, 2009 10:38 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Treating reals as complex (giving them a zero imaginary part) is a bad > idea. Â Reasons include: > > (1) need float and double for FFI ?? > (2) compatibility with other dialects Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new). I do agree that dialect compatibility is a good thing in general. > (3) avoid wasting space to hold unneeded imaginary parts No need for extra space. Number>>real ^self Number>>imaginary ^0 > Sig is correct to point out that sometimes one wants to do purely real > arithmetic with the domains of various functions restricted as appropriate. > Â Complex numbers should be separate from reals. I think that this might be approached differently. Thought experiment. I have a Smalltalk without negative numbers (How can you take something away from nothing? Screen pixels start at 0@0 I can't draw pixels off-screen! If I get "negative" pixels I have to check every pixel calculation to see if I am on screen or not.). So now I make a package which supplies NegativeNumbers. The argument is that this changes the behavior which people rely on (breaks existing code) and that nobody uses these imaginary negative things anyway. Should one not allow this package? Note that again, for consistency, I suggest that making Complex a package implies removing the current Complex implementation. If a Complex package exists, I expect (-1 sqrt) to give 1i. My intent is for consistency. Packages allow for completeness. Can we both be happy? $0.02, -KenD _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

Re: [Pharo-project] #< if at first you dont succeed..

by Ken.Dickey

"Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Treating reals as complex (giving them a zero imaginary part) is a bad > idea. Â Reasons include: > > (1) need float and double for FFI ?? > (2) compatibility with other dialects Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new). I do agree that dialect compatibility is a good thing in general. > (3) avoid wasting space to hold unneeded imaginary parts No need for extra space. Number>>real ^self Number>>imaginary ^0 > Sig is correct to point out that sometimes one wants to do purely real > arithmetic with the domains of various functions restricted as appropriate. > Â Complex numbers should be separate from reals. I think that this might be approached differently. Thought experiment. I have a Smalltalk without negative numbers (How can you take something away from nothing? Screen pixels start at 0@0 I can't draw pixels off-screen! If I get "negative" pixels I have to check every pixel calculation to see if I am on screen or not.). So now I make a package which supplies NegativeNumbers. The argument is that this changes the behavior which people rely on (breaks existing code) and that nobody uses these imaginary negative things anyway. Should one not allow this package? Note that again, for consistency, I suggest that making Complex a package implies removing the current Complex implementation. If a Complex package exists, I expect (-1 sqrt) to give 1i. My intent is for consistency. Packages allow for completeness. Can we both be happy? $0.02, -KenD

Aug. 14, 2009

Re: [Pharo-project] Complex number support discussion

by Ken.Dickey

Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > A 2-10x performance hit is all the more reason why such a creation should > be dormant unless specifically invoked - translation, no coercion into the > controversial type. Â While there are uses for systems that are "smart" > enough to give exact answers, most computation happens in a world of > tolerances, with numbers that are not cherry picked for aesthetics. Â > > As somebody else (Sig perhaps) said, the behavior of the base system > magnitude classes should not change when a different package is loaded. > Â #asComplex is the gateway through which one can tell the system that > complex numbers are expected and desired. Â The more you write, the more it > becomes clear that there also would need to be a #asComplexSymbolic or > something to invoke behavior one might expect from Maple and other symbolic > systems. > > I strongly recommend starting with a numerical approach to a "closed > system" of complex numbers. Â GSL provides much of what should be available, > and can be mapped into Pharo by FFI/Alien. Â The result would get used. Â If > you then want to compete with Maple and Mathematica, that really should be > done separately. Â For examle, there are times when I use logs to estimate > the number of digits required to hold a number, and if the argument is > negative, I goofed and expect an error. Bill, My apologies for mixing a personal "philosophy discussion" into the Complex header. Â The Complex implementation does not suffer from the performance hit mentioned and as I stated earlier, I have no current desire to make Pharo into Mathematica. Â I would welcome a package which did this, however. -KenD

Aug. 14, 2009

Re: [Pharo-project] [Fix] Call initialsPerSe in isHarvester

by Alexandre Bergel

Ah sorry. I checked on google code for "initialsPerSe" and "fullNamePerSe" and I could not find it. Moreover, I did an update yesterday and I still had the error. Cheers, Alexandre On 14 Aug 2009, at 11:13, Adrian Lienhard wrote: > This is already fixed (see my mail from this morning regarding issue > #1069). > > Cheers, > Adrian > > On Aug 14, 2009, at 17:01 , Alexandre Bergel wrote: > >> Issue #1070 >> initialsPerSe is a deprecated method. When opening an image, a >> deprecated error shows up. "Author uniqueInstance fullNamePerSe" >> should be used in instead. The following .cs fixes this. >> >> On google code >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 14, 2009

Re: [Pharo-project] [Fix] Call initialsPerSe in isHarvester

by Adrian Lienhard

This is already fixed (see my mail from this morning regarding issue #1069). Cheers, Adrian On Aug 14, 2009, at 17:01 , Alexandre Bergel wrote: > Issue #1070 > initialsPerSe is a deprecated method. When opening an image, a > deprecated error shows up. "Author uniqueInstance fullNamePerSe" > should be used in instead. The following .cs fixes this. > > On google code > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

[Pharo-project] [Fix] Call initialsPerSe in isHarvester

by Alexandre Bergel

Issue #1070 initialsPerSe is a deprecated method. When opening an image, a deprecated error shows up. "Author uniqueInstance fullNamePerSe" should be used in instead. The following .cs fixes this. On google code Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 14, 2009

Re: [Pharo-project] Help on Polymorph [was How to build a GUI]

by Alexandre Bergel

>> Is DrDoc on SqueakSource? I'll take a look. > > Yes I would be more than happy if someone could take the lead there. > I could embed images (UML diagram). It could maybe be used with Mondrian :-) Alexandre > > > >> >> - Brian >> >> >> >>> >>> Stef >>> >>>>> So far we should invent it. >>>>> And I totally agree with you. If people do not see the good doc >>>>> they >>>>> will not write good comment. >>>>> I started to work on DrDoc a kind of package meta data to add >>>>> documentation to a package but it got stole >>>>> I should push that again. What would be nice is to take one >>>>> package >>>>> and do it well as an example. >>>>> >>>>> >>>>> It think it should be possible to write documentation at the >>>>> package level. So developpers have a place where they can write an >>>>> overview of their package. When we click on a package, >>>>> documentation should be displayed by default or easily. >>>> >>>> Yes! Here is a post I made in April of 2003: >>>> >>>> >>>>> The biggest frustration with using comments is that there is no >>>>> good >>>>> "starting place" for a given class category. For example, go >>>>> browse >>>>> the Seaside classes and categories and figure out where one should >>>>> start. You can repeat this exercise for any number of >>>>> categories. I >>>>> propose that we we add a documentation attribute to the >>>>> PackageInfo >>>>> stuff, so there is a category level documentation spot, with links >>>> to >>>>> the appropriate class comments. >>>> >>>>> Any thoughts? >>>> I didn't get any response, and I sent a similar type of thought to >>>> Stef recently, but he's so busy I don't even know if he read my >>>> email :) >>>> >>>> - Brian >>>>> >>>>> In the rubygems world, it is a common practice to write >>>>> documentation in a README file which is displayed by RDoc on >>>>> startup page (github works the same way). It seems to me that >>>>> there's the same level of comment between Ruby class/methods and >>>>> Pharo. The documentation at the package level may be the >>>>> difference. >>>>> >>>>> Python has a real documentation effort.Each release come with its >>>>> up to date documentation. It's a release criteria. Python shares >>>>> some similarities with Pharo as they both have "batteries >>>>> included". May be there should have a process to contribute to a >>>>> centralized Pharo documentation which can be accessed within the >>>>> IDE. >>>>> >>>>> Laurent. >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 14, 2009

[Pharo-project] Create a changeset for an entire package?

by Javier PimÃ¡s

It seems fixing bugs is not the only hard part... I've a bunch of fixes for GLCanvas, and a small proposed change for the class browser but I can't find a way to export a diff of all the changed packages, nor a diff of an entire package nor a diff of a class so anybody can see the changes before commiting... Do I have to file out every class I changed? there has to some easier way. Thanks, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 14, 2009

Re: [Pharo-project] Question about MD5

by Henrik Johansen

Strange, retested now. With .cs from 1065 also installed I got (first result with what I posted): Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]] 23267 32033 and without it: Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]] 38877 50751 Guess I tested the old version in an image without 1065 when I wrote the 2x :) Cheers, Henry On Aug 14, 2009, at 3:18 58PM, Mariano Martinez Peck wrote: > > > 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > I added a version to the issue which is almost 2x faster (for large > ByteArrays at least). I'm not sure if the needs of DBX are such that > the performance increase can justify the added uglyness (using > to:do: instead of do: ), but it'd be nice if you would have a look. > > Henry: Thanks for your feedback and work! I tried both solutions. > The one I posted, with your benchmark give me 34734. However, with > your version, I have 29675. > > best, > > Mariano > > > Cheers, > Henry > > On Aug 13, 2009, at 3:23 08PM, Mariano Martinez Peck wrote: > >> Ok. I opened the ticket: http://code.google.com/p/pharo/issues/detail?id=1067 >> >> I replaced _ to := and take into considerations the henrik >> suggestions. >> >> Best, >> >> Mariano >> >> On Thu, Aug 13, 2009 at 9:47 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no >> > wrote: >> Please also use (String new: (self size * 2)) writeStream instead of >> '' writeStream. >> In this case it won't lead to any noticeable performance increases, >> but it's good practice anyways :) >> >> I'd also argue the expected returnvalue of "hex" might not be clear >> as >> something like "asHexString" when applied to a collection (hex >> previously only implemented on single values), but that's a minor >> issue. >> >> When looking around, I also noticed WriteStream nextPut: does an >> unnecessary check for ByteStrings which is pretty ugly (plus, it >> decreases nextPut: performance for all ByteString writeStreams), >> filed >> as Issue 1065. >> >> Cheers, >> Henry >> >> >> Issue 1065 >> On Aug 13, 2009, at 10:32 19AM, StÃ©phane Ducasse wrote: >> >> > add a nice method comment and a couple of tests! >> > >> > Stef >> > >> > On Aug 13, 2009, at 1:26 AM, Mariano Martinez Peck wrote: >> > >> >> Hi folks: Me and the rest of the team is developing SqueakDBX >> which >> >> is a driver to talk with major databases. However, I think the >> most >> >> persistence alternatives pharo has, the best. There is no better >> >> solution for every escenario. So, I am also trying to get the >> >> PostgreSQL native driver to work in Pharo. This package depends on >> >> Cryptography because of MD5. I know that there were added to Pharo >> >> packages like System-Hashing-core, System-Hashing-SHA1 and >> System- >> >> Hashing-MD5. However, the driver doesn't work yet. But adding this >> >> single method: >> >> >> >> ByteArray>>hex >> >> | stream | >> >> stream _ '' writeStream. >> >> self do: [ :each | >> >> stream >> >> nextPut: ('0123456789ABCDEF' at: each // 16 + 1); >> >> nextPut: ('0123456789ABCDEF' at: each \\ 16 + 1)]. >> >> ^ stream contents >> >> >> >> The driver works like a charm in Pharo without needing >> Cryptography >> >> package. As far as I remember there were no MIT problem with this >> >> package. Because of this those packages ( System-Hashing-core, >> >> System-Hashing-SHA1 and System-Hashing-MD5) were integrated in >> Pharo. >> >> >> >> So, can I add it? >> >> >> >> Thanks >> >> >> >> Mariano >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >> project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

Re: [Pharo-project] Question about MD5

by Mariano Martinez Peck

2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > I added a version to the issue which is almost 2x faster (for large > ByteArrays at least). I'm not sure if the needs of DBX are such that the > performance increase can justify the added uglyness (using to:do: instead of > do: ), but it'd be nice if you would have a look. > Henry: Thanks for your feedback and work! I tried both solutions. The one I posted, with your benchmark give me 34734. However, with your version, I have 29675. best, Mariano > > Cheers, > Henry > > On Aug 13, 2009, at 3:23 08PM, Mariano Martinez Peck wrote: > > Ok. I opened the ticket: > http://code.google.com/p/pharo/issues/detail?id=1067 > > I replaced _ to := and take into considerations the henrik suggestions. > > Best, > > Mariano > > On Thu, Aug 13, 2009 at 9:47 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> Please also use (String new: (self size * 2)) writeStream instead of >> '' writeStream. >> In this case it won't lead to any noticeable performance increases, >> but it's good practice anyways :) >> >> I'd also argue the expected returnvalue of "hex" might not be clear as >> something like "asHexString" when applied to a collection (hex >> previously only implemented on single values), but that's a minor issue. >> >> When looking around, I also noticed WriteStream nextPut: does an >> unnecessary check for ByteStrings which is pretty ugly (plus, it >> decreases nextPut: performance for all ByteString writeStreams), filed >> as Issue 1065. >> >> Cheers, >> Henry >> >> >> Issue 1065 >> On Aug 13, 2009, at 10:32 19AM, StÃ©phane Ducasse wrote: >> >> > add a nice method comment and a couple of tests! >> > >> > Stef >> > >> > On Aug 13, 2009, at 1:26 AM, Mariano Martinez Peck wrote: >> > >> >> Hi folks: Me and the rest of the team is developing SqueakDBX which >> >> is a driver to talk with major databases. However, I think the most >> >> persistence alternatives pharo has, the best. There is no better >> >> solution for every escenario. So, I am also trying to get the >> >> PostgreSQL native driver to work in Pharo. This package depends on >> >> Cryptography because of MD5. I know that there were added to Pharo >> >> packages like System-Hashing-core, System-Hashing-SHA1 and System- >> >> Hashing-MD5. However, the driver doesn't work yet. But adding this >> >> single method: >> >> >> >> ByteArray>>hex >> >> | stream | >> >> stream _ '' writeStream. >> >> self do: [ :each | >> >> stream >> >> nextPut: ('0123456789ABCDEF' at: each // 16 + 1); >> >> nextPut: ('0123456789ABCDEF' at: each \\ 16 + 1)]. >> >> ^ stream contents >> >> >> >> The driver works like a charm in Pharo without needing Cryptography >> >> package. As far as I remember there were no MIT problem with this >> >> package. Because of this those packages ( System-Hashing-core, >> >> System-Hashing-SHA1 and System-Hashing-MD5) were integrated in Pharo. >> >> >> >> So, can I add it? >> >> >> >> Thanks >> >> >> >> Mariano >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 14, 2009