September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] HashedCollection showstopper :(

by Igor Stasenko

2010/9/23 Levente Uzonyi <leves(a)elte.hu>: > On Wed, 22 Sep 2010, Igor Stasenko wrote: > >> Unfortunately, when preparing new finalization stuff, i got stuck with >> HashedCollection >> which is not yet integrated to Pharo. >> (Sets with nils also depending on that). >> >> In Squeak, old WeakRegistry does the trick by setting a #finalizer: to >> WeakKeyDictionary instance. >> >> Levente, can i ask you to give me a bits, (changesets or mcz packages), >> which contain HashedCollection refactorings. > > I could extract them from the Squeak trunk, but it wouldn't be usable for > Pharo, because these rely on previous changes done to Sets/Dictionaries in > Squeak. Even if those are extracted it's still very hard to add them to > Pharo, because there were serveral changes applied to Sets/Dictionaries in > Pharo. The most important are: > - AndrÃ©s' changes were integrated with additional stuff to change > #identityHash -> #basicIdentityHash and #scaledIdentityHash -> > #identityHash. - WeakKeyDictionaries were replaced with another > implementation (http://code.google.com/p/pharo/issues/detail?id=1565 ) > > I think i found a way how to workaround differences between squeak/pharo in new WeakRegistry class. So, then a new finalization can be integrated into Pharo right now. Will post later, if i'll have any success on that. > Levente > >> >> Or, we can follow an easier path, just extract the delta from two >> packages, >> which i found in mail archives: >> --- >> I uploaded two packages which contain this change. To load it evaluate >> the following: >> >> (Installer squeakfoundation project: 'inbox') >> Â Â Â install: 'Collections-ul.310.mcz'; >> Â Â Â install: 'Collections-ul.311.mcz' >> --- >> >> these are only related to WeakKeyDictionary, made by Levente to >> speedup old finalization. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] decompiledSource

by Henrik Johansen

On Sep 23, 2010, at 1:35 18PM, Herve Verjus wrote: > Hello All, > > I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? > > Thank you... > > Herve If you mean CompiledBlock/CompiledCode #decompiledSource, I think the equivalent in Pharo would be BlockClosure / CompiledMethod #decompile Cheers, Henry

Sept. 23, 2010

[Pharo-project] decompiledSource

by Herve Verjus

Hello All, I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? Thank you... Herve

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Levente, We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one. ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes. If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it: Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork. What do you mean by "servers"? ConnectionQueue? Levente > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 22, 2010 9:55 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> the one running the gui > > In that case, you're wrong. The UI Process will be able to run, because > other processes using Sockets will wait on Semaphores and not because of > "time limits". So I just convinced myself (and hopefully you too) about > that using Socket instances will not hang the entire image, just the > Process that uses the Socket. Therefore the SocketPlugin is as good as > possible. > > > Levente > >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Monday, September 20, 2010 10:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. >> >> Where? In the Socket class? And what's the "main thread"? >> >> >> Levente >> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 8:13 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Levente, >>>> >>>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >>> >>> I guess you're using Socket>>#connectTo:port: which uses >>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>> implement your own low level method which waits on semaphore until it's >>> signaled. If you want to terminate the connection attempt, just signal the >>> semaphore yourself, like here: >>> >>> s := Socket newTCP. >>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >>> s semaphore waitTimeoutMSecs: 1000. >>> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >>> >>> And for ConnectionQueue, simply don't use it if you don't like it. It >>> doesn't have to poll at all, AFAIK it's just implemented that way. >>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>> don't block the image at all. But correct me if I'm wrong. >>> >>> >>> Levente >>> >>>> >>>> Bill >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 7:01 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Guillermo, >>>>> >>>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>>> >>>> When does a Socket block the image? >>>> >>>> >>>> Levente >>>> >>>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>>> >>>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>>> >>>>> Guille >>>>> >>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>>> >>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>> where you can add any properties to object >>>>> on the fly, without need of adding a methods or declaring additional >>>>> instance variable in class... >>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>> >>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>>> hi guys >>>>>>> >>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>>> So we should really have a way to specify silent ui action. >>>>>>> Does anybody have an idea how I could do that? >>>>>>> >>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>>> >>>>>> >>>>>> use morph propertyAt: #borderStyle >>>>>> so you don't have to break your head with it :) >>>>>> >>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>> them even don't using any >>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>> style etc should belong to root classes >>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>> properties (which is currently sits in morphic >>>>>> extensions are more appropriate storage for them). The only problem is >>>>>> that accessing them is much slower than ivars. >>>>>> >>>>>>> Stef >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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 >

Sept. 23, 2010

[Pharo-project] [ANN] JQueryWidgetBox 1.5 for Seaside 3.0

by Torsten Bergmann

Hi there, version 1.5 of the "JQueryWidgetBox" project [1] is available for Seaside 3.0. There are now 32 interesting JQuery widgets wrapped that you can easily use in your Seaside applications. Most noteably we now have a wrapper for mbMenu [2] and uilayout [3]. Also a jQuery Grid is included. I updated some scripts and after some adoptions of existing packages all 81 tests went green again. Thanks to all who helped wrapping the jquery widgets out there!!! To try: ======= Open a clean Pharo 1.1. image and evaluate: Gofer new squeaksource:'MetacelloRepository'; package:'ConfigurationOfJQueryWidgetBox'; load. ((Smalltalk at: #ConfigurationOfJQueryWidgetBox) project version: '1.5') load. You can now load some additional Seaside tools by evaluating: ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.0.0-rc') load: #('Seaside-Pharo-Tools-OmniBrowser' 'Seaside-Adaptors-Comanche') Now select "Tools -> SeasideControl Panel" to open the control panel. Using the context menu add an WAComancheAdaptor and start it. Now point your browser to http://localhost:8080/browse/jquery-widgets Bye T. [1] http://squeaksource.com/JQueryWidgetBox.html [2] http://pupunzi.open-lab.com/mb-jquery-components/mb-_menu/ [3] http://layout.jquery-dev.net -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl

Sept. 23, 2010

Re: [Pharo-project] Metacello repositories in the future

by Norbert Hartl

On 23.09.2010, at 09:41, Mariano Martinez Peck wrote: > > > On Thu, Sep 23, 2010 at 4:46 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Mariano, > > 2010/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi. I don't like to loose my time of ESUG answering/reading emails, but a > > summary was that we can implement something like #latestVersion or > > #lastVersion but called #stableVersion > > which could be something like this: > > > > ConfigurationOfXXX >> stableVersion > > for: #pharo10 do: [ ^ self version: '1.35.5' ] > > > > for: #pharo11 do: [ ^ self version: '3.23' ] > > > > for: #pharo12 do: [ self error: 'Not yet supported' ] > > > > Maybe you could implement some form of > > forGreaterThan: #pharo12 do: [ ... ] ? > > > but what would you do inside the block? I guess doing something like "self error: 'Not yet supported'" > > We also thought with Dale, what happens if the Pharo version where you are loading it, does not have an entry in that method....suppose I am now in Pharo 1.3, and I send #stableVersion....what happens? Two options: > > - Load the latest one, and nobody knows if that will work or not (I don't like this option) > - Thrown an error like "There isn't any stable version specified for this Pharo version" or something like that > > what do you think? > I think the basic idea is "I know more or less that it works for this and that between version x and version y". If you combine this with promises you can make regarding the software then you would probably say - the xxx stuff changed from pharo 1.1 to pharo 1.2. I rely on the 1.2 stuff. So I can say at least you need _a_ 1.2 version. That you know for sure - there is no need to assume that the stuff you referring to will change immediately to something different. So together with the above statement that will be >= 1.2 - if you encounter a problem with 1.3 not working with your software than you will even need < 1.3. - everything above is complicated if you replace the real package names with virtual ones. So you can say: Oh, they changed the networking stuff from 1.1 to 1.2 but I want my software to run on 1.1 as well. This is possible if there is a virtual package network-1.2 that can be provided by pharo 1.2 (of course) but also from a compatibility package for 1.1 that provides the same API - you can imagine the compatibility package approach could also work for the 1.3 version but I never encountered a compat package that downgrades an API To me that is the basic assumptions that give you: <, <=, =, >=, > relationship of dependencies (or a combination of those to get a range) Taking the installable targets, stable is strong promise. So you end up reducing the range acquired above to a single version of a package. A beta label is similar. On the other hand bleedingEdge is also a promise :) You will always get the upper bound of the range, the newest package known to probably work. For those you don't know it I strongly recommend reading the debian policy about packages [1]. They went down a long road and you can get the idea what will end up with if you proceeding to cover use cases. hope this helps in any way. My 2 cents, Norbert [1] http://www.debian.org/doc/debian-policy/ch-relationships.html > > so developers do not have to monitor new Pharo versions and update > their configurations. Does it makes sense? > > Cordialement, > > > > > Then the user can do something like: > > > > ConfigurationOfXXX project stableVersion load. > > > > And Metacello will load the stable version for the current Pharo version you > > are running in. And he will apply and use probably the same for the > > different Gemstone versions. > > > > In addition, even if not needed, we could commit this confs (with this new > > #stableVersion) into the 3 different MetacelloPharo repositories. With this, > > it is easier to know which confs work for each pharo versions. > > > > Finally, we thought I could do a test of implementing all those #stable > > methods in all the confs of the PharoDev and try to recreate a Pharo1.0 > > dev and a Pharo 1.1 dev, using the correct core but using this "stable" > > version and see if it works. > > > > Cheeers > > > > Mariano > > > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. > > _______________________________________________ > 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

Sept. 23, 2010

Re: [Pharo-project] [Moose-dev] News on Mondrian

by Tudor Girba

The documentation is nice, indeed. Doru On 21 Sep 2010, at 19:47, Alexandre Bergel wrote: > Hi! > > I am please to announce that Mondrian now includes an help and tutorial. These are accessible from the Easel menu and the World menu (help item). > > You can load Mondrian with: > Gofer new > squeaksource: 'Mondrian'; > package: 'ConfigurationOfMondrian'; > load. > (Smalltalk at: #ConfigurationOfMondrian) perform: #loadDefault. > > > I would be please to hear feedback on them. The PharoByExampleV2 chapter on Mondrian will be based on the tutorial. I am currently working on a Tutorial->Latex importer. > > What I did in the plane on the way back form esug. > > 582: No leaf class is abstract. Move down some methods from MOShape to MONodeShape > 581: Help and tutorial finished. Added some new test and renamed a few things > 580: easel examples are better commented and more descriptive > 579: Added submenu in Easel help > 578: MOAnnouncer>>forward: > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow."

Sept. 23, 2010

Re: [Pharo-project] Metacello repositories in the future

by Mariano Martinez Peck

On Thu, Sep 23, 2010 at 4:46 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Mariano, > > 2010/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi. I don't like to loose my time of ESUG answering/reading emails, but a > > summary was that we can implement something like #latestVersion or > > #lastVersion but called #stableVersion > > which could be something like this: > > > > ConfigurationOfXXX >> stableVersion > > for: #pharo10 do: [ ^ self version: '1.35.5' ] > > > > for: #pharo11 do: [ ^ self version: '3.23' ] > > > > for: #pharo12 do: [ self error: 'Not yet supported' ] > > > > Maybe you could implement some form of > > forGreaterThan: #pharo12 do: [ ... ] ? > > but what would you do inside the block? I guess doing something like "self error: 'Not yet supported'" We also thought with Dale, what happens if the Pharo version where you are loading it, does not have an entry in that method....suppose I am now in Pharo 1.3, and I send #stableVersion....what happens? Two options: - Load the latest one, and nobody knows if that will work or not (I don't like this option) - Thrown an error like "There isn't any stable version specified for this Pharo version" or something like that what do you think? mariano > so developers do not have to monitor new Pharo versions and update > their configurations. Does it makes sense? > > Cordialement, > > > > > Then the user can do something like: > > > > ConfigurationOfXXX project stableVersion load. > > > > And Metacello will load the stable version for the current Pharo version > you > > are running in. And he will apply and use probably the same for the > > different Gemstone versions. > > > > In addition, even if not needed, we could commit this confs (with this > new > > #stableVersion) into the 3 different MetacelloPharo repositories. With > this, > > it is easier to know which confs work for each pharo versions. > > > > Finally, we thought I could do a test of implementing all those #stable > > methods in all the confs of the PharoDev and try to recreate a > Pharo1.0 > > dev and a Pharo 1.1 dev, using the correct core but using this "stable" > > version and see if it works. > > > > Cheeers > > > > Mariano > > > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Alain Plantec

Le 23/09/2010 09:17, StÃ©phane Ducasse a Ã©crit : > Yes > I think that we should just get better at packaging/loading.... > But this package is important so it should be a supported package. > > Stef > > Concerning the size issue: On a fresh image: after a cleanUpForRelease -> 13.4 Mo Then, I've load the full dejaVu font and I've removed the old accuny one, also removed old dejaVu (the current one with 3 sizes), cleaned StrikeFont class then cleanUpForRelease -> 14.1 Mo In this image, only one dejaVu font with all sizes, so that standard and demo mode are working. Of course we can also remove small sizes (maybe 5, 6 and 7) to decrease the size more. Cheers Alain

Sept. 23, 2010

Re: [Pharo-project] [Vm-dev] failing/errors Pharo Tests with CogVM

by Mariano Martinez Peck

Hi. Today I run the tests with the new build 2312 and it is better, at least the Float tests are passing: 9715 run, 9708 passes, 0 expected failures, 5 failures, 2 errors, 0 unexpected passes Failures: FileStreamTest>>#testPositionPastEndIsAtEnd PCCByLiteralsTest>>#testSwitchPrimCallOffOn AllocationTest>>#testOneGigAllocation MethodContextTest>>#testClosureRestart ReleaseTest>>#testUndeclared Errors: MessageTallyTest>>#testSampling1 WeakSetInspectorTest>>#testSymbolTableM6812 Thanks Mariano On Mon, Sep 20, 2010 at 4:18 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Ok....that's to all the responses. The thread is now far away my > knoweldege, so I will naively ask: is it worth creating a Pharo 1.1.1 one > click with CogVM? > > Marcus released a PharoCore 1.1.1 with changes for CogVM and some important > fixes. I took that core image and I created a new dev. But before releasing, > I run the tests and I found them. > > Seems you all discussed about the Float problems...but what about the > others? I remember them and I thing they were fixed in newest versions of > VMMaker. > > So...the question is now....are the failure/error of those tests means that > Pharo is "unreleasable" with CogVM? Should we wait for the fix or we should > release anyway? > > Thanks in advance, > > Mariano > > On Fri, Sep 17, 2010 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> >> On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <andreas.raab(a)gmx.de>wrote: >> >>> >>> On 9/16/2010 2:44 PM, Eliot Miranda wrote: >>> >>>> I realise we need to be more precise. Are you talking about NaNs >>>> specifically or NaN and Inf? >>>> >>> >>> NaN only. +-Inf are fine as they have a well-defined mathematical >>> relationship over the set of numbers. NaN does not. >>> >>> >>> The Squeak VM happily answers Inf from its >>>> float primitives. In fact the only guard against a NaN or Inf result >>>> being produced by the floating-point primitives is the guard against >>>> dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) >>>> isInfinite and there is no failure. So specifically failing for aFloat >>>> / 0.0 seems a bit of a fig leaf to me. >>>> >>>> So what would your ideal semantics be? >>>> a) - fail whenever the result is Inf or NaN? >>>> b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer >>>> Inf >>>> c) - fail whenever the result is NaN but fail aFloat / 0.0 >>>> d) - the Interpreter status quo, fail only for aFloat / 0.0 >>>> e) - never fail and answer Nan and Inf as specified in IEEE 754 >>>> >>>> The situation with VW before IEEE was that it did a) and we changed it >>>> so that the mode switch selected either a) or e), with, IIRC, the >>>> current default being e). >>>> >>> >>> f) Fail whenever the result is NaN or when dividing by zero. >>> >> >> OK, to be pedantic that's c) above. But fine. This is a reasonable >> choice. >> >> >>> My preference for f) is that division by zero should be consistent >>> between floating point numbers and integers. It would be strange if "1 / 0" >>> => boom but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't >>> division by zero and may silently result in Inf. In other words: >>> >>> self should:[1.0 / 0.0] raise: ZeroDivide. >>> >>> but (#successor produces the smallest float larger than the receiver) >>> >>> self shouldnt:[1.0 / 0.0 successor] raise: Error. >>> self assert: (1.0 / 0.0 successor) = Float infinity. >>> >>> Cheers, >>> - Andreas >>> >> >> >> >

Sept. 23, 2010