January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3545 in pharo: FEATURE: Multiple Worlds

by Fernando Olivero

Ok, will do then. What i can do now is: a := Morph new. b animationsRunner animateFadeInOf: b. b := Morph new. b animationsRunner animatePageTurnFrom: b to: a. ..... All based on the existing methods on Form, simply adding a "Morphic layer" on top. Fernando On Wed, Jan 19, 2011 at 1:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Yes, if thats easy to do. >> >> I played with JavaFX last year and (even when it is now abondened >> and will reappear as Java API) it was a nice way to easily build >> visual appealing applications with transition effects, shadows, ... >> (see http://javafx.com/samples) >> >> Would like to see that in future for Pharo too easily allow people >> to build sexy apps. > > Me too. > Now again this is a question of time not vision. There is simpleMorphic waiting for us > >> >> Thx >> T. > >

Jan. 19, 2011

Re: [Pharo-project] Issue 3422 in pharo: Use UIManager instead of Workspace

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3422 by marcus.d...(a)gmail.com: Use UIManager instead of Workspace http://code.google.com/p/pharo/issues/detail?id=3422 13002

Jan. 19, 2011

[Pharo-project] Issue 3552 in pharo: Delete Package "DeleteMe"

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2 Milestone-1.3 New issue 3552 by marcus.d...(a)gmail.com: Delete Package "DeleteMe" http://code.google.com/p/pharo/issues/detail?id=3552 Delete Package "DeleteMe"

Jan. 19, 2011

Re: [Pharo-project] About XML Support in the 1.2

by laurent laffont

On Wed, Jan 19, 2011 at 2:49 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > On 19.01.2011, at 14:30, laurent laffont wrote: > > On Wed, Jan 19, 2011 at 1:37 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> It depends where you look at. ConfigurationOfXMLSupport exists in >> MetacelloRepository as well as in XMLSupport. The latter one being the >> official one, the former one being very outdated. My sugesstion would be to >> remove ConfigurationOfXMLSupport from MetacelloRepository to lower the >> confusion. >> > > Personnally I always look in MetacelloRepository, this should be the > reference IMHO. > > Laurent, > > I think it is up to the maintainers where to put those files. And in the > XMLSupport case the decision was made deliberately not to put it in > MetacelloRepository but in XMLSupport. The only thing I want to avoid is > having multiple different files floating around that are edited in an > inconsistent way. > I thought that all ConfigurationOfXXX working for Pharo should be put in MetacelloRepository so we have a central place to look at. But I may be wrong. Mariano ? Dale ? Laurent > > Norbert > > >> Norbert >> >> On 19.01.2011, at 13:18, Tudor Girba wrote: >> >> > The last version 1.1.6 is marked as #release. >> > >> > Cheers, >> > Doru >> > >> > >> > On 19 Jan 2011, at 12:26, laurent laffont wrote: >> > >> >> I put ConfigurationOfXMLSupport version 1.0 because blessing was >> #release. But I agree to change. >> >> >> >> Laurent >> >> >> >> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker < >> marcus.denker(a)inria.fr> wrote: >> >> >> >> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: >> >> >> >>> Indeed, this is a problem for Moose in general. We depend on >> XMLSupport, but now we cannot update it in PharoDev. I would also strongly >> support the idea of removing XMLSupport from PharoDev. >> >>> >> >> >> >> What would be important: we need the latest version in Pharo 1.2... >> else how can we ever have a version where the tests are green? >> >> (not of XML, but in general) >> >> >> >> Marcus >> >> >> >>> Cheers, >> >>> Doru >> >>> >> >>> >> >>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I have a problem with the XMLSupport version from Pharo 1.2. >> >>>> >> >>>> The problem is that I need to work with one of the last version of >> XMLSupport but in the pharo image 1.2 is loaded an old version of XMLSupport >> (I mean a version from Jan 2010). I did try to load a newer version of >> XMLSupport using ConfigurationOfXMLSupport but some errors make this >> operation impossible. >> >>>> So either Pharo-dev 1.2 load a newer (possibly the last) version of >> XMLSupport by default or Pharo-dev 1.2 should not load XMLSupport at all. >> >>>> >> >>>> I think that doesn't make sense to use by default such an old >> version, also considering that the last XMLSupport has nice and useful >> features like the XMLPluggableElementFactory. >> >>>> >> >>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by default you let >> people free to use the version that they like. >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Fabrizio >> >>>> >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> >> >>> "We cannot reach the flow of things unless we let go." >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> Marcus Denker -- http://www.marcusdenker.de >> >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> >> >> >> >> > >> > -- >> > www.tudorgirba.com >> > >> > "If you interrupt the barber while he is cutting your hair, >> > you will end up with a messy haircut." >> > >> > >> >> >> > >

Jan. 19, 2011

Re: [Pharo-project] Any Clue..

by Diogenes Moreira

Pharo's improvement is significant compared to squeak .. can restore the environmentwith 2 click .. things up to version 3.10 of squeak was almost impossible. always hadto play something on the Change .. Best. On Wed, Jan 19, 2011 at 10:03 AM, Diogenes Moreira < diogenes.moreira(a)gmail.com> wrote: > Thanks.. > > > On Wed, Jan 19, 2011 at 9:57 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> I have seen this only a couple of times, and I am not aware of a shortcut >> to returning to a working image and recovering lost changes. As an aside, I >> am suspicious that opening an image more than once leads to much more >> badness than is generally acknowledged. I am convinced it was central to my >> most recent meltdown. The only reason I don't have more trouble is that I >> have learned to scan the task bar before launching Pharo. >> >> We need a cross-platform way to detect that a given image is open and to >> at least optionally warn and offer to exit without doing any damage. >> Dolphin does so by creating a Windows synchronization object (either a >> semaphore or an event??) tied to the image name, and if that object exists, >> it sternly warns against proceeding. Deployed executables do not do this >> check by default. >> >> Good luck retrieving your work! >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Diogenes >> Moreira [diogenes.moreira(a)gmail.com] >> Sent: Wednesday, January 19, 2011 7:42 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Any Clue.. >> >> Hi folks.. >> >> this morning, at try start my enviroment, pharo said... "Read failed or >> premature end of image file".. Any Clue to solve it, will be welcome. >> >> Well I can get a clean image and apply de changes.. but somebody have a >> shortcut..?? >> >> Best >> >> >

Jan. 19, 2011

Re: [Pharo-project] About XML Support in the 1.2

by Norbert Hartl

On 19.01.2011, at 14:30, laurent laffont wrote: > On Wed, Jan 19, 2011 at 1:37 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > It depends where you look at. ConfigurationOfXMLSupport exists in MetacelloRepository as well as in XMLSupport. The latter one being the official one, the former one being very outdated. My sugesstion would be to remove ConfigurationOfXMLSupport from MetacelloRepository to lower the confusion. > > Personnally I always look in MetacelloRepository, this should be the reference IMHO. > Laurent, I think it is up to the maintainers where to put those files. And in the XMLSupport case the decision was made deliberately not to put it in MetacelloRepository but in XMLSupport. The only thing I want to avoid is having multiple different files floating around that are edited in an inconsistent way. Norbert > > Norbert > > On 19.01.2011, at 13:18, Tudor Girba wrote: > > > The last version 1.1.6 is marked as #release. > > > > Cheers, > > Doru > > > > > > On 19 Jan 2011, at 12:26, laurent laffont wrote: > > > >> I put ConfigurationOfXMLSupport version 1.0 because blessing was #release. But I agree to change. > >> > >> Laurent > >> > >> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: > >> > >>> Indeed, this is a problem for Moose in general. We depend on XMLSupport, but now we cannot update it in PharoDev. I would also strongly support the idea of removing XMLSupport from PharoDev. > >>> > >> > >> What would be important: we need the latest version in Pharo 1.2... else how can we ever have a version where the tests are green? > >> (not of XML, but in general) > >> > >> Marcus > >> > >>> Cheers, > >>> Doru > >>> > >>> > >>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a problem with the XMLSupport version from Pharo 1.2. > >>>> > >>>> The problem is that I need to work with one of the last version of XMLSupport but in the pharo image 1.2 is loaded an old version of XMLSupport (I mean a version from Jan 2010). I did try to load a newer version of XMLSupport using ConfigurationOfXMLSupport but some errors make this operation impossible. > >>>> So either Pharo-dev 1.2 load a newer (possibly the last) version of XMLSupport by default or Pharo-dev 1.2 should not load XMLSupport at all. > >>>> > >>>> I think that doesn't make sense to use by default such an old version, also considering that the last XMLSupport has nice and useful features like the XMLPluggableElementFactory. > >>>> > >>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by default you let people free to use the version that they like. > >>>> > >>>> Thanks, > >>>> > >>>> Fabrizio > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "We cannot reach the flow of things unless we let go." > >>> > >>> > >>> > >>> > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "If you interrupt the barber while he is cutting your hair, > > you will end up with a messy haircut." > > > > > > >

Jan. 19, 2011

Re: [Pharo-project] Any Clue..

by Schwab,Wilhelm K

Sig, Are we discussing the same OS? What you are describing matches my experience on Windows; on Linux, AFAIK, one can just stomp all over the files and leave a mess. Perhaps something has changed to make it safer since I last trashed an image that way. I agree that there are times when it does not matter, so any safety mechanism needs to be optional, or better yet tied to a development session vs. a deployed session. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, January 19, 2011 8:35 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Any Clue.. On 19 January 2011 14:14, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Please forgive me for being skeptical, but it is certainly worthy of a test on my end. How do the multiple processes coordinate access to the change log? Not having seen an IDE complain about access to either image or changes, and knowing that I have been bitten by this, I am not sure how to square it. Access to single .changes file are handled by image, and i think it is handled well (it barks that .changes cannot be opened, if some other process already opened it). But that is a completely different story , because .image file are handled by vm itself, not by image.. From VM perspective, a .changes file are not mandatory in order to run your image, so why it should care about it? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, January 19, 2011 8:08 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Any Clue.. > > > There is nothing wrong starting multiple processes using single .image > file. During startup, vm just reads data from it. > And when writing to an .image file, a process who first opens it > should obtain a global lock on it, so nothing will have chances to > interfere. > So, it seems that image file was damaged or not written completely.. > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 19, 2011

Re: [Pharo-project] About XML Support in the 1.2

by Guillermo Polito

I like to have related things together because they are easier to browse (from the app developer point of view) :). From the user who wants to use several packages, it is not confortable at all, I know... I think MetacelloRepository is being used as: - a bag to put everything we don't know where to put - (in companion to Monticello) a tool to browse every available metacello config. I think 1) is not a good reason to put things there, but sometimes it is useful (or mandatory when we want a config but we don't have access to the repos, hehe). And 2) is remarking our lack of tools for metacello use :). Arghhhhh, I need time :(. I would like to gather forces with someone doing this kind of tool... Guille On Wed, Jan 19, 2011 at 10:30 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > On Wed, Jan 19, 2011 at 1:37 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> It depends where you look at. ConfigurationOfXMLSupport exists in >> MetacelloRepository as well as in XMLSupport. The latter one being the >> official one, the former one being very outdated. My sugesstion would be to >> remove ConfigurationOfXMLSupport from MetacelloRepository to lower the >> confusion. >> > > Personnally I always look in MetacelloRepository, this should be the > reference IMHO. > > In MetacelloRepository, the latest version of ConfigurationOfXMLSupport is > 1.0.2 (no 1.1.6). > > > Laurent > > >> Norbert >> >> On 19.01.2011, at 13:18, Tudor Girba wrote: >> >> > The last version 1.1.6 is marked as #release. >> > >> > Cheers, >> > Doru >> > >> > >> > On 19 Jan 2011, at 12:26, laurent laffont wrote: >> > >> >> I put ConfigurationOfXMLSupport version 1.0 because blessing was >> #release. But I agree to change. >> >> >> >> Laurent >> >> >> >> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker < >> marcus.denker(a)inria.fr> wrote: >> >> >> >> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: >> >> >> >>> Indeed, this is a problem for Moose in general. We depend on >> XMLSupport, but now we cannot update it in PharoDev. I would also strongly >> support the idea of removing XMLSupport from PharoDev. >> >>> >> >> >> >> What would be important: we need the latest version in Pharo 1.2... >> else how can we ever have a version where the tests are green? >> >> (not of XML, but in general) >> >> >> >> Marcus >> >> >> >>> Cheers, >> >>> Doru >> >>> >> >>> >> >>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I have a problem with the XMLSupport version from Pharo 1.2. >> >>>> >> >>>> The problem is that I need to work with one of the last version of >> XMLSupport but in the pharo image 1.2 is loaded an old version of XMLSupport >> (I mean a version from Jan 2010). I did try to load a newer version of >> XMLSupport using ConfigurationOfXMLSupport but some errors make this >> operation impossible. >> >>>> So either Pharo-dev 1.2 load a newer (possibly the last) version of >> XMLSupport by default or Pharo-dev 1.2 should not load XMLSupport at all. >> >>>> >> >>>> I think that doesn't make sense to use by default such an old >> version, also considering that the last XMLSupport has nice and useful >> features like the XMLPluggableElementFactory. >> >>>> >> >>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by default you let >> people free to use the version that they like. >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Fabrizio >> >>>> >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> >> >>> "We cannot reach the flow of things unless we let go." >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> Marcus Denker -- http://www.marcusdenker.de >> >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> >> >> >> >> > >> > -- >> > www.tudorgirba.com >> > >> > "If you interrupt the barber while he is cutting your hair, >> > you will end up with a messy haircut." >> > >> > >> >> >> >

Jan. 19, 2011

Re: [Pharo-project] Any Clue..

by Igor Stasenko

On 19 January 2011 14:14, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Please forgive me for being skeptical, but it is certainly worthy of a test on my end. Â How do the multiple processes coordinate access to the change log? Â Not having seen an IDE complain about access to either image or changes, and knowing that I have been bitten by this, I am not sure how to square it. Access to single .changes file are handled by image, and i think it is handled well (it barks that .changes cannot be opened, if some other process already opened it). But that is a completely different story , because .image file are handled by vm itself, not by image.. From VM perspective, a .changes file are not mandatory in order to run your image, so why it should care about it? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, January 19, 2011 8:08 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Any Clue.. > > > There is nothing wrong starting multiple processes using single .image > file. During startup, vm just reads data from it. > And when writing to an .image file, a process who first opens it > should obtain a global lock on it, so nothing will have chances to > interfere. > So, it seems that image file was damaged or not written completely.. > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 19, 2011

Re: [Pharo-project] About XML Support in the 1.2

by laurent laffont

On Wed, Jan 19, 2011 at 1:37 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > It depends where you look at. ConfigurationOfXMLSupport exists in > MetacelloRepository as well as in XMLSupport. The latter one being the > official one, the former one being very outdated. My sugesstion would be to > remove ConfigurationOfXMLSupport from MetacelloRepository to lower the > confusion. > Personnally I always look in MetacelloRepository, this should be the reference IMHO. In MetacelloRepository, the latest version of ConfigurationOfXMLSupport is 1.0.2 (no 1.1.6). Laurent > Norbert > > On 19.01.2011, at 13:18, Tudor Girba wrote: > > > The last version 1.1.6 is marked as #release. > > > > Cheers, > > Doru > > > > > > On 19 Jan 2011, at 12:26, laurent laffont wrote: > > > >> I put ConfigurationOfXMLSupport version 1.0 because blessing was > #release. But I agree to change. > >> > >> Laurent > >> > >> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> > >> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: > >> > >>> Indeed, this is a problem for Moose in general. We depend on > XMLSupport, but now we cannot update it in PharoDev. I would also strongly > support the idea of removing XMLSupport from PharoDev. > >>> > >> > >> What would be important: we need the latest version in Pharo 1.2... else > how can we ever have a version where the tests are green? > >> (not of XML, but in general) > >> > >> Marcus > >> > >>> Cheers, > >>> Doru > >>> > >>> > >>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a problem with the XMLSupport version from Pharo 1.2. > >>>> > >>>> The problem is that I need to work with one of the last version of > XMLSupport but in the pharo image 1.2 is loaded an old version of XMLSupport > (I mean a version from Jan 2010). I did try to load a newer version of > XMLSupport using ConfigurationOfXMLSupport but some errors make this > operation impossible. > >>>> So either Pharo-dev 1.2 load a newer (possibly the last) version of > XMLSupport by default or Pharo-dev 1.2 should not load XMLSupport at all. > >>>> > >>>> I think that doesn't make sense to use by default such an old version, > also considering that the last XMLSupport has nice and useful features like > the XMLPluggableElementFactory. > >>>> > >>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by default you let > people free to use the version that they like. > >>>> > >>>> Thanks, > >>>> > >>>> Fabrizio > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "We cannot reach the flow of things unless we let go." > >>> > >>> > >>> > >>> > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "If you interrupt the barber while he is cutting your hair, > > you will end up with a messy haircut." > > > > > > >

Jan. 19, 2011