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

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

by laurent laffont

> > Not exactly a compreensive documentation but rather a quick start: > > In a workspace evaluate: > > UITheme exampleBasicControls. > UITheme exampleColorControls. > UITheme exampleDialogs. > UITheme exampleGroups. > UITheme exampleOtherControls. > UITheme exampleWindowWithToolbars. > Hi In fact I've managed to build some windows with controls but I feel missing several concepts on how to use Polymorph the right way ( funny, I've built Gtk, Qt, Swing, ... GUI quite easily ... ). - What is the idea behind the word "Pluggable" (PluggableButton, PluggableDialogWindow, ....) ? - It seems that many (all ?) UI in Pharo use the builder pattern. Great, but that's a lot of stuff for me while trying to learn (with almost no time, I had forgotten that a new child take soooo much time). Do you know a package/class with simpler UI to study ? - In Toolbuilder, what the word "Spec" means ? Some thoughts: - Toolbuilder-Examples package is great to study how to use Toolbuilder. I think it should be included in Pharo with some other XXX-Examples packages that might exists. - Is there a somewhat easier way to navigate through class and methods documentation than in System Browser ? I think that documentation is not easily seen, so it doesn't push developers to write documentation, so there's not a lot of documentation, so people don't write tools to read documentation, ... There should be a system / tool to reward developpers that write good class / package documentation with examples. Regards, Laurent

Aug. 12, 2009

Re: [Pharo-project] Complex neurotic

by csrabak＠bol.com.br

Aug. 12, 2009

Re: [Pharo-project] [Ann] RFB/VNC fully configurable by code.

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 12-08-2009 a las 18:18 -0100, Mariano Martinez Peck escribiÃ³: > > > What sort of packages should be put there? For example, I am woring in > SqueakDBX and Glorp and both of them work there. However, they are not > dev tools or something like. Thus, I don't understand which type or > packages should be added. Every package that loads and runs ok on pharo. This will motivate to port even more packages. I hope it will be a catalyzer because if we can show that a lot of packages are already running ok on pharo, the stability and maturity of pharo will make it a good platform to base new software and to port software from other smalltalk versions. So, if you have a package that load/runs, please by any means add it. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 12, 2009

Re: [Pharo-project] [squeak-dev] Squeak 4.x should adopt Pharo 1.0

by csrabak＠bol.com.br

Aug. 12, 2009

Re: [Pharo-project] Complex neurotic

by csrabak＠bol.com.br

Em 11/08/2009 23:45, Ken.Dickey escreveu: > > AFAIK, one has to be careful ordering complex numbers: > > I am aware of this. There are a large number of ways to define < for complex > numbers -- and a large number of problems with each of them. > > What I object to are bad behaviors for things which are perfectly well > defined. > > Currently: > > -1 asComplex isNumber --> true > 1 asComplex isNumber -> true Those are well defined. > -1 asComplex < 1 asComplex --> error > This now would only be "well definede" if you make a painstakingly checking that the imaginary part is equal as well. . . > -4 sqrt --> error > -3 ln -> NaN Most applications do not work in Complex but rather in Real (in the sense of 'non imaginary') corpus, so the only way to evade this conundrum would be to have a System wide setting (which I frown at) or a per package (better even if could do in a way to circumscribe to application level), like a Number>>complexResultsAllowed Number>>complexResultsNotAllowed pair, to allow or disallow the results come in Complex or not. > > > If in doubt, I would #shouldNotImplement #< until we can get a conclusive > > answer. > > An answer to what? I wrote the test cases first and then did code to make the > tests pass. > > I am certainly open to alternate definitions, but I think if an object answers > true to isNumber it should behave as a number. The problem is that the result to this answer is arbitrary and result of Smalltalk modeling, not a thesis in type theory or Mathematics... The same kind of "countersense" happens today in Matrix. It is located in the Collections-Unordered package, but we have the following: Matrix>>isSequenceable "LIE so that arithmetic on matrices will work. What matters for arithmetic is not that there should be random indexing but that the structure should be stable and independent of the values of the elements. #isSequenceable is simply the wrong question to ask." ^true Depending upon what kind of rigour you want to defend you'l find the comment "funny" or something else ;-). > > What would you expect of the following? > > -1 asFloat < 1 asFloat. true > -1 asNumber < 1 asNumber. true > -1 asFraction < 1 asFraction. true > -1 asComplex < 1 asComplex. an exception. > > > One can add checks and make off-axis complex numbers fail (why?), but why > cause the last case above to fail? > Because even in pure mathematics there is not a ordering for Complex numbers. In problem domain (like certain problems in Electrical Engineering, for example) -1 asComplexSubclass < 1 asComplexSubclass. would return 'false' and -1 asComplexSubclass = 1 asComplexSubclass. could return 'true'. > Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + (1/3) + 1/6) Not missing the oportunity of the pun, this is Complex case to obtain reasonable behaviour :-D

Aug. 12, 2009

Re: [Pharo-project] Extending #< to compare all numbers

by Schwab,Wilhelm K

Ken, 1/2 = 0.5 comes close to making an important point, but it doesn't quite get there. However, inspect 0.1+0.1+0.1-0.3 Floating point is not always what it seems. By extension, I argue that computer-represented complex numbers are not always what they seem, only more so. Not only do they have the representation/precision quirks of floats, they are sometimes appropriate and sometimes indicative of nonsense. The line between those two cases is best left to the application programmer who will happily signal their desire to use complex numbers by inserting #asComplex. "Every number is-equivalent-to a complex number because 1 = (1 + 0i). [In the Scheme language every number _is_ a complex number, BTW]." The same is (AFAIK) true in matlab, but that does not make the machine number problems go away, at least not if one wants to use floating point coprocessors. Treating the real line as a subspace of complex plane is fine in a purely mathematical setting, but things get interesting once real-world data, and the occaisional non-representable number, start flying through an algorithm running on hardware. Also, matlab is not the first thing people think of when they want blazing speed, in part because of the way it treats numbers and because of its interpreted execution[*]. Intuition resulting from lots of exposure to mathematicians suggests that they consider this non-trivial but well-known. As a result, there are fleeting insights in exercises and other forums intended for teaching. That can make it difficult to get a clear answer. However, their official reading appears to be that while one can create total orders on the complex numbers, something will always suffer. That is probably because arbitrary decisions have to be made (what is greater than what, does the real or imaginary part get to break the tie?) and result in arbitrary behavior. A couple of IEEE sources state that orders on complex numbers are "meaningless." That means those most likely to take notice of the work will fault us for defining such an order. If I am reading this correctly, defining $< is making a promise we can't keep, or perhaps we simply should not try. You will be doing a great service if you can simply get all the arithmetic and transcendental functions to work properly on complex arguments. However, I think there are compelling reasons to *not* try to make the existing magnitudes coerce into complex numbers. If you can find something that claims to produce a sensible ordering of complex numbers, please post a reference. For now, my sense is that such a thing cannot exist. Bill [*] Interpreters can be fast, as Object Arts showed in nice paper some time back, but, matlab's is apparently not terribly quick. I base that on cautions I received from various sources in a recent exploration of Octave as a possible vehicle to solving a problem. -----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: Wednesday, August 12, 2009 1:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Extending #< to compare all numbers Greetings, Since there is some discussion around comparing using#< let me try to explain the context of my thinking. I am approaching this as a programmer and a user of mathematics, not as a mathematician. I prefer the Principle of Least Surprise. I prefer simple, easy to explain rules and simple implementations. I expect the following expressions all to answer true. 1/2 = 0.5. 1 = 1 asComplex. 1 = (1 + 0i). "same as the previous line" 0 < 1. 0 < 1 asComplex. Every number is-equivalent-to a complex number because 1 = (1 + 0i). [In the Scheme language every number _is_ a complex number, BTW]. So to me, saying that 0 and (1 asComplex) are not comparable is saying that 0 and 1 are also not comparable, because I consider them numerically the same as (0+0i) and (1+0i). My observation is that I don't want to lose properties. If A and B are numbers, I want them to be comparable on the real number line -- no matter how many other dimensions I add. If B is to the right on the real number line from A, then I expect (A < B) to answer true. I expect this to be true NO MATTER HOW MANY DIMENSIONS I ADD. To put this in context, say that I have an object which is a "basket of measurements" at a place and time (say position, density, temperature, pressure). Now if I add a new dimension, say electrical conductivity, I do not expect temperature comparisons to stop working. I can still compare temperatures between objects which lack the conductivity slot/measurement and those which have them. OK. Now to the extension. I suspect this is the root of the (potential) controversy. I chose to say that if the real/x component of a 2d number is equal, then one number may be considered less than another if the imaginary/y value is less. This means that (0+0i) < (0+1i) holds. These are the properties (and test cases) I care about. Currently, the definition for Complex>>< is just this (see below). This implies that (3+0i) < (3+1i) holds, even though the x/real components are equal. I think that this is OK. What do you think? Are there simpler, least surprising definitions for Complex>>< ? What useful properties/invariants/tests would you add? [As unit tests] Thanks for your thoughtful input. -KenD --------------------------------Complex < other "self < other if other's real-part is to the right or the real-parts are equal and the oher's imaginary part is larger" | otherCpx | otherCpx := other asComplex. ^self real < otherCpx real or: [self real = otherCpx real and: [self imag < otherCpx imag]] --------------------------------- _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 12, 2009

Re: [Pharo-project] [Ann] RFB/VNC fully configurable by code.

by Mariano Martinez Peck

On Wed, Aug 12, 2009 at 6:17 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > good initiative > May be put the date of the last edit of the package > On Aug 12, 2009, at 6:54 AM, Miguel Enrique CobÃ¡ Martinez wrote: > > > El miÃ©, 12-08-2009 a las 02:43 +0100, Keith Hodges escribiÃ³: > > > >> Why not just use the REPLServer > >> > > > > Woa, woa, I remember some mails mentioning it but never check it. > > > > This opens a world of possibilities to me. > > > > Thanks for the pointer. > > > > BTW: > > REPL-mvdg.16.mcz from > > > > http://squeaksource.com/SecureSqueak/ > > > > loads cleanly and works correctly on PharoCore 10413, after installing > > > > DynamicBindings > > KomServices > > > > from project KomHttpServer. > > > > By the way I have created a new wiki page to track the list of > > packages > > that load correctly on Pharo. > > > > http://code.google.com/p/pharo/wiki/PackagesTestedInPharo > > > > This list will eventually get outdated but, in the meantime, will help > > to promote the use of Pharo and the porting of new packages to it. > > > What sort of packages should be put there? For example, I am woring in SqueakDBX and Glorp and both of them work there. However, they are not dev tools or something like. Thus, I don't understand which type or packages should be added. best, Mariano > > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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. 12, 2009

[Pharo-project] Extending #< to compare all numbers

by Ken.Dickey

Greetings, Since there is some discussion around comparing using#< let me try to explain the context of my thinking. I am approaching this as a programmer and a user of mathematics, not as a mathematician. I prefer the Principle of Least Surprise. I prefer simple, easy to explain rules and simple implementations. I expect the following expressions all to answer true. 1/2 = 0.5. 1 = 1 asComplex. 1 = (1 + 0i). "same as the previous line" 0 < 1. 0 < 1 asComplex. Every number is-equivalent-to a complex number because 1 = (1 + 0i). [In the Scheme language every number _is_ a complex number, BTW]. So to me, saying that 0 and (1 asComplex) are not comparable is saying that 0 and 1 are also not comparable, because I consider them numerically the same as (0+0i) and (1+0i). My observation is that I don't want to lose properties. If A and B are numbers, I want them to be comparable on the real number line -- no matter how many other dimensions I add. If B is to the right on the real number line from A, then I expect (A < B) to answer true. I expect this to be true NO MATTER HOW MANY DIMENSIONS I ADD. To put this in context, say that I have an object which is a "basket of measurements" at a place and time (say position, density, temperature, pressure). Now if I add a new dimension, say electrical conductivity, I do not expect temperature comparisons to stop working. I can still compare temperatures between objects which lack the conductivity slot/measurement and those which have them. OK. Now to the extension. I suspect this is the root of the (potential) controversy. I chose to say that if the real/x component of a 2d number is equal, then one number may be considered less than another if the imaginary/y value is less. This means that (0+0i) < (0+1i) holds. These are the properties (and test cases) I care about. Currently, the definition for Complex>>< is just this (see below). This implies that (3+0i) < (3+1i) holds, even though the x/real components are equal. I think that this is OK. What do you think? Are there simpler, least surprising definitions for Complex>>< ? What useful properties/invariants/tests would you add? [As unit tests] Thanks for your thoughtful input. -KenD --------------------------------Complex < other "self < other if other's real-part is to the right or the real-parts are equal and the oher's imaginary part is larger" | otherCpx | otherCpx := other asComplex. ^self real < otherCpx real or: [self real = otherCpx real and: [self imag < otherCpx imag]] ---------------------------------

Aug. 12, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by John M McIntosh

On 12-Aug-09, at 6:33 AM, Adrian Lienhard wrote: > We need to change the startup list such that the InputEventSensor > comes after OSPlatform. This can be done in InputEventSensor > class>>initialize. Will do that in one of the next updates. > > Adrian > If you are going to do this I would suggest you *audit* the entire startup/shutdown ordered collection to understand if the order is correct and somehow ensure perhaps by a initialization method that does the reorder for all classes in the sequence that is run when you build a new official image. The Sophie team was burned from time to time by this order problem and having different team members just drop a class somewhere random in the sequence. As you see the order *can* be important, and bizarre things can happen. A wiki page documenting the why might be useful too. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 12, 2009

Re: [Pharo-project] a process to maintain non core package

by Brian Brown

Unfortunately, Bob is not open source: On Aug 10, 2009, at 2:07 PM, Keith Hodges wrote: > > p.p.s. Bob is not going to be released as open source, if you would > like > the ability to build your images daily, and run the test suites > against > your deliverables, then please do email me for licensing terms. Of course, the community could still choose to use it for managing the release process, but that seems unlikely. - Brian On Aug 10, 2009, at 1:54 PM, Douglas Brebner wrote: > Miguel Enrique CobÃ¡ Martinez wrote: >> El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribiÃ³: >> >>> Keith Hodges wrote: >>> >>>> Adrian Lienhard wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I really think we need a package management system and a process >>>>> to >>>>> maintain it. >>>>> >>>>> The goal is that loading and using non-core packages "just >>>>> works" >>>>> >>> Same goal as for Sake/Packages, and it works for me. >>> >>> >>>>> (unlike for instance SqueakMap, where loading more often fails >>>>> than succeeds because there are a lot of obsolete packages and a >>>>> dependency mechanism is missing). >>>>> >>>>> - There should be a responsible maintainer for each package >>>>> >>>>> >>> Not a realistic proposition. Better to be open to all to maintain on >>> behalf of the community. >>> >> >> Why not, the debian project use this model since 1996 or something >> like >> that. >> The same package system the use report packages not maintained >> anymore >> (orphans and waiting for mantainer) >> >> >>>>> - For each package there should be a known way to discuss and >>>>> report >>>>> problems >>>>> >>>>> >>> That's just arbitrary metadata in the package definition, for more >>> general topics we use the packages(a)squeakfoundation.org mailing list >>> >>>>> - A gate keeper includes and removes packages from the set >>>>> depending >>>>> on their status >>>>> >>>>> >>> Probably too complicated to be practical. >>> >>>>> This limits the set of included packages (at least initially) but >>>>> would increase the quality and hence the user experience. >>>>> >>>>> Maybe there could be two sets, a stable and an unstable set. New >>>>> >>>>> >>> Sake/Packages supports a stable and a beta release of each package. >>> >>>>> packages would first go to the unstable set and then move up to >>>>> the >>>>> stable set after a while. >>>>> >>>>> An automated build process could load packages into new builds and >>>>> report the result of the tests. >>>>> >>>>> >>> Bob does that. >>> >>>>> The package management system does not need to be very >>>>> sophisticated, >>>>> >>>>> >>> Sake is as simple as possible for defining actions with >>> dependencies. >>> >>>>> but it should manage dependencies and have a simple GUI (to >>>>> search for >>>>> packages and see what is already loaded). >>>>> >>>>> >>> Sake/Packages uses the class browser as is, no extra GUI is >>> required. >>> >>> Packages provided explore >>> >>> shows you what is loaded, and this should be merged into >>> PackageOrganization. >>> >>> Keith >>> >> >> Keith, it really appear that you have built the platform to bring >> this >> dream a reality, but somehow (the details are not relevant now) you >> haven't materialized a "steve jobs" kind of show off of it. >> I believe your words, based on your other projects that I use. What >> do >> you need, as Stephan said, to bring a complete, working, and as >> simple >> to understand for all of us of your tools. >> This is my proposal: >> >> I think that if you can put a working example (minimal, a couple of >> packages, and the core) using Pharo, the pharo community happily will >> support you. No more fights, no more angry mails, just the working >> full >> simple demo. >> I offer to you access to a server with a homologated IP to install (I >> can help you here too) to setup the repositories to test your tools. >> If the community agree to use your tools and process I can also buy >> and >> donate the domain to host this infrastructure. In the beginning I >> will >> host it, if someday it grows more than I can support (bandwidth >> mainly, >> the space isn't problem) then we will discuss with the community to >> migrate the repos to a bigger servers or to ask for donations or some >> other party that can host it (maybe the folks of seasidehosting). >> We'll >> see in that moment. >> >> But, Keith, we need to see to believe and support you. >> >> >> > I've seen Keiths Seaside gui he made for Bob though I don't know if he > wants it to be shown around. It looks nice. > > Here's a quick explanation for those not familiar with them. > Sake is essentially Make for Smalltalk, allowing you to define tasks > that can depend on other tasks. > Bob is a build tool, which handles all the actual building using Sake > tasks to define what to do. > > With Bob+Sake, you can define a build to: > 1. Start with a defined image. > 2. Load a set of packages into that image (either specific versions or > the latest ones). > 3. Apply specific fixes from the bug tracker. > 4. Run tests. > 5. Save the new image and export all the new package versions to a new > folder. > > You can define tasks to apply features to an image such as closures or > perform updates between versions or even update applications. > > For example, you can define tasks to do the following sort of things > Pharo1.0beta -> Pharo1.0final > Pharo1.0beta -> Pharo-latest. > Squeak 3.10.2 image -> 3.10.2+closures. > Squeak 3.8 image -> 3.8+closures. > Seaside 2.8 -> 2.9. > Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite > packages. > > Once defined, these will allow anyone to repeatably and reliably > produce > an updated image+packages without changing the original image. You can > then do things like upgrade a production image based on 1.0beta to > 1.0final just by using the same task but telling it to start with your > production image instead of the 1.0beta distribution image. Since it > produces a new image you don't risk clobbering your original. > > You should also be able to replace the update stream with distributing > build definitions for Bob. > > I believe one of the key points to this setup is that you don't need > to > work on the image as a single blob any more, you only work on the > packages and use Bob to handle the messy image building stuff. That > does > depend on the image being sectioned into packages of course. > > If I've had any misunderstandings here I hope Keith will correct me > but > the system looks awesome :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 12, 2009