- Pharo-dev - lists.pharo.org

I need update of ConfigurationOfZincHTTPComponents

by Sabine KnÃ¶fel

Hi Jan, Hi Sven, in ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.51 (http://mc.stfx.eu/ZincHTTPComponents) there is following entry package: 'Zinc-SSO-OAuth2-Core' with: 'Zinc-SSO-OAuth2-Core-JanVanDeSandt.15'; which has an invalid reference to removed variable refreshToken could you please reference Name: Zinc-SSO-OAuth2-Core-JanVanDeSandt.16 instead or allow me to do this? regards Sabine -- View this message in context: http://forum.world.st/I-need-update-of-ConfigurationOfZincHTTPComponents-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 3, 2013

Re: [Pharo-dev] Distributing File Resources

by J.F. Rick

I'll certainly create one to serve my own needs. I'll also think about how a more general purpose one might look. Ideally, it would just integrate with Monticello so that each package could contain its own resources. On the other hand, code is small and can easily be saved in each version whereas resources are quite large and could cause each saved thing to be huge. I'll keep people informed of where I get to. I'll also take a look at FileSystemST and see where that leads me. Cheers, Jeff On Tue, Sep 3, 2013 at 12:48 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Jeff, > > Would you have an interest looking into this and prototyping a solution? > > Doru > > > On Tue, Sep 3, 2013 at 12:44 PM, J.F. Rick <self(a)je77.com> wrote: > >> I'm surprised this doesn't exist yet. It seems like it would be a natural >> thing to be part of Monticello. >> >> Cheers, >> >> Jeff >> >> >> On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> What I would like to have is >>> >>> -> A way to save files per package in the image in a virtual file system >>> -> Monticello support to save that virtual file system as part of the >>> .mcz >>> >>> We could clean up *a lot* of methods in the image and even save memory: >>> right now >>> the "save Base64 encoded strings in methods" means that we have the data >>> two times: the string literal and the >>> object created from it. (and the source on disk). >>> >>> >>> On Sep 3, 2013, at 11:23 AM, phil(a)highoctane.be wrote: >>> >>> yes that would be great to have indeed. >>> >>> >>> >>> On Tuesday, September 3, 2013, J.F. Rick <self(a)je77.com> wrote: >>> > Hi everyone, >>> > I've been trying to move things over to Pharo and may be a bit more >>> active on the list. Part of that is trying to use smalltalkhub to manage my >>> code. Since I do a lot of visual work, I tend to have a lot of images (and >>> sounds) to manage. I'd like to be able to distribute them easily but I >>> can't seem to find a way to upload them to a shared directory. In Squeak, >>> there was this idea of .SAR files for distributing files. Is there a good >>> solution for this outside of the Seaside approach of embedding the file >>> information in class methods. I'm talking about hundreds of files and >>> multiple MBs here, rather than one or two small files. >>> > Cheers, >>> > Jeff >>> > -- >>> > Jochen "Jeff" Rick, Ph.D. >>> > http://www.je77.com/ >>> > Skype ID: jochenrick >>> >>> -- >>> --- >>> Philippe Back >>> Dramatic Performance Improvements >>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 >>> Mail:phil@highoctane.be | Web: http://philippeback.eu >>> Blog: http://philippeback.be | Twitter: @philippeback >>> Youtube: http://www.youtube.com/user/philippeback/videos >>> >>> High Octane SPRL >>> rue cour Boisacq 101 | 1301 Bierges | Belgium >>> >>> Pharo Consortium Member - http://consortium.pharo.org/ >>> Featured on the Software Process and Measurement Cast - >>> http://spamcast.libsyn.com >>> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value >>> Added Reseller >>> >>> >>> >>> >>> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 3, 2013

Switching context(s) in browser while method is not-yet accepted

by Igor Stasenko

this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action. often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :) what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do. And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window). -- Best regards, Igor Stasenko.

Sept. 3, 2013

[update 3.0] #30366

by Marcus Denker

30366 ----- 11515 Rename protocols shortcut changed https://pharo.fogbugz.com/f/cases/11515 11450 Protocol rename duplication https://pharo.fogbugz.com/f/cases/11450 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.529.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ClassOrganizer-Core-MarcusDen…

Sept. 3, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by David T. Lewis

On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: > > Le 03/09/2013 13:36, David T. Lewis a ?crit : > >On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: > >> > >>I'm attempting something. Is is OK if I save in the OSProcess > >>squeaksource repository? > >> > >>Thierry > > > >Can you post the method here first? I'd like to check it on some Squeak > >images > >before it goes into the repository. > > Here it is (at least an example): > Thank you! I will check this when I get home this evening. Dave > in OSProcess class > > isPharo3AndLater > "Test if we are on Pharo 3.0" > > ^ (Smalltalk classNamed: 'SystemVersion') > ifNil: [ false ] > ifNotNil: [ :v | v current type = 'Pharo' and: [ v current > major >= 3 ] ] > > platformName > "After Squeak version 3.6, #platformName was moved to SmalltalkImage > Some > versions of Pharo move this to OSPlatform and issue deprecation > warnings > about the other usages. Then Pharo moved away from OSPlatform and > deprecated > its use." > > "self platformName" > > self isPharo3AndLater > ifTrue: [ ^ Smalltalk os name ]. > ^ (((Smalltalk hasClassNamed: #OSPlatform) > and: [(Smalltalk at: #OSPlatform) > respondsTo: #platformName]) > ifTrue: [Smalltalk at: #OSPlatform] > ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') > ifNil: [^ Smalltalk osVersion]) current]) > platformName >

Sept. 3, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... :) Thierry Le 03/09/2013 14:22, Camillo Bruni a Ã©crit : > bah... I would just go for maintaining a fork of OSProcess with simple > rewriters for these methods and backporting fixes from the main repository. > > I think all-in-one solutions only result in bad code.. > > On 2013-09-03, at 08:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> Le 03/09/2013 13:36, David T. Lewis a Ã©crit : >>> On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: >>>> >>>> >>>> Le 03/09/2013 12:56, David T. Lewis a ?crit : >>>>> On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: >>>>>> >>>>>> At the same time, parts of OSProcess seems to not be working under >>>>>> Pharo2 anyway :( I don't even think I'm able to run the tests (locked up >>>>>> my 3.0 image it did). >>>>>> >>>>> >>>>> My last set of updates to OSProcess for Pharo were done in January 2013, >>>>> and it worked at that time. Has something stopped working since then? >>>> >>>> I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a >>>> long time now; however, when trying to test if I did everything right on >>>> a 3.0 adaptation, running the tests ended up >>>> 1- uncovering more deprecated warnings with things that do not exist >>>> under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and >>>> the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). >>>> 2- test failures due to missing Xcontrol plugin? (and permanent process >>>> error afterwards) so I scrapped that image and my implementation, will >>>> rewrite everything with a fresh new image. >>>> >>>> Can I give up on trying to run OSProcess tests? >>> >>> The tests require XDisplayControlPlugin in the VM in order to do many of >>> the multi-process tests, because #forkSqueak is used to create cooperating >>> VM processes for the tests. In addition, some OSProcess function will not >>> work on Cog. >>> >>> If you can run the tests on an interpreter VM they should pass. If you >>> can get XDisplayControlPlugin included in the VM, then I expect that most >>> of the tests would pass (we would have to try it to be sure). >> >> Ok. >> >>> Otherwise, yes, you can give up on running the tests. You may still find >>> them useful as a source of examples and for running specific tests that >>> do not require #forkSqueak. >> >> Thanks. >> >> Thierry >> >>> Dave >>> >>> >>>> >>>>>> Looks like a version / implementation test would be the way to go. I'll >>>>>> write something which should work on 2.0 / 3.0, and failure protection >>>>>> to fallback for anything else. >>>>>> >>>>>> Is there a standard way to test for implementation/version on all Squeak >>>>>> and Pharo versions ? >>>>>> >>>>> >>>>> No. And as you can see from the examples in OSProcess, it is becoming >>>>> increasingly difficult to cobble up a solution that works for an externally >>>>> maintained package. If you can find a better solution, that would be great >>>>> :) >>>> >>>> I'm attempting something. Is is OK if I save in the OSProcess >>>> squeaksource repository? >>>> >>>> Thierry >>> >>> Can you post the method here first? I'd like to check it on some Squeak images >>> before it goes into the repository. >> >> Here it is (at least an example): >> >> in OSProcess class >> >> isPharo3AndLater >> "Test if we are on Pharo 3.0" >> >> ^ (Smalltalk classNamed: 'SystemVersion') >> ifNil: [ false ] >> ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ] >> >> platformName >> "After Squeak version 3.6, #platformName was moved to SmalltalkImage Some >> versions of Pharo move this to OSPlatform and issue deprecation warnings >> about the other usages. Then Pharo moved away from OSPlatform and deprecated >> its use." >> >> "self platformName" >> >> self isPharo3AndLater >> ifTrue: [ ^ Smalltalk os name ]. >> ^ (((Smalltalk hasClassNamed: #OSPlatform) >> and: [(Smalltalk at: #OSPlatform) >> respondsTo: #platformName]) >> ifTrue: [Smalltalk at: #OSPlatform] >> ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') >> ifNil: [^ Smalltalk osVersion]) current]) platformName >> >>> Thanks! >>> Dave >>> >>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 3, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Camillo Bruni

bah... I would just go for maintaining a fork of OSProcess with simple rewriters for these methods and backporting fixes from the main repository. I think all-in-one solutions only result in bad code.. On 2013-09-03, at 08:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 03/09/2013 13:36, David T. Lewis a Ã©crit : >> On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: >>> >>> >>> Le 03/09/2013 12:56, David T. Lewis a ?crit : >>>> On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: >>>>> >>>>> At the same time, parts of OSProcess seems to not be working under >>>>> Pharo2 anyway :( I don't even think I'm able to run the tests (locked up >>>>> my 3.0 image it did). >>>>> >>>> >>>> My last set of updates to OSProcess for Pharo were done in January 2013, >>>> and it worked at that time. Has something stopped working since then? >>> >>> I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a >>> long time now; however, when trying to test if I did everything right on >>> a 3.0 adaptation, running the tests ended up >>> 1- uncovering more deprecated warnings with things that do not exist >>> under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and >>> the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). >>> 2- test failures due to missing Xcontrol plugin? (and permanent process >>> error afterwards) so I scrapped that image and my implementation, will >>> rewrite everything with a fresh new image. >>> >>> Can I give up on trying to run OSProcess tests? >> >> The tests require XDisplayControlPlugin in the VM in order to do many of >> the multi-process tests, because #forkSqueak is used to create cooperating >> VM processes for the tests. In addition, some OSProcess function will not >> work on Cog. >> >> If you can run the tests on an interpreter VM they should pass. If you >> can get XDisplayControlPlugin included in the VM, then I expect that most >> of the tests would pass (we would have to try it to be sure). > > Ok. > >> Otherwise, yes, you can give up on running the tests. You may still find >> them useful as a source of examples and for running specific tests that >> do not require #forkSqueak. > > Thanks. > > Thierry > >> Dave >> >> >>> >>>>> Looks like a version / implementation test would be the way to go. I'll >>>>> write something which should work on 2.0 / 3.0, and failure protection >>>>> to fallback for anything else. >>>>> >>>>> Is there a standard way to test for implementation/version on all Squeak >>>>> and Pharo versions ? >>>>> >>>> >>>> No. And as you can see from the examples in OSProcess, it is becoming >>>> increasingly difficult to cobble up a solution that works for an externally >>>> maintained package. If you can find a better solution, that would be great >>>> :) >>> >>> I'm attempting something. Is is OK if I save in the OSProcess >>> squeaksource repository? >>> >>> Thierry >> >> Can you post the method here first? I'd like to check it on some Squeak images >> before it goes into the repository. > > Here it is (at least an example): > > in OSProcess class > > isPharo3AndLater > "Test if we are on Pharo 3.0" > > ^ (Smalltalk classNamed: 'SystemVersion') > ifNil: [ false ] > ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ] > > platformName > "After Squeak version 3.6, #platformName was moved to SmalltalkImage Some > versions of Pharo move this to OSPlatform and issue deprecation warnings > about the other usages. Then Pharo moved away from OSPlatform and deprecated > its use." > > "self platformName" > > self isPharo3AndLater > ifTrue: [ ^ Smalltalk os name ]. > ^ (((Smalltalk hasClassNamed: #OSPlatform) > and: [(Smalltalk at: #OSPlatform) > respondsTo: #platformName]) > ifTrue: [Smalltalk at: #OSPlatform] > ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') > ifNil: [^ Smalltalk osVersion]) current]) platformName > >> Thanks! >> Dave >> >>> >>>> Dave >>>> >>>> >>>> >>>> >>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Sept. 3, 2013

Re: [Pharo-dev] Distributing File Resources

by Camillo Bruni

I started an in-image filesystem which would add resources to each Class and Package. Of course this currently does not yet tackle the versioning part, but it could be built on top. In any case, my idea was that these resources can either live in the image or on the normal os filesystem. you can have a peek at it here: http://smalltalkhub.com/#!/~dh83/FileSystemST On 2013-09-03, at 07:48, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Jeff, > > Would you have an interest looking into this and prototyping a solution? > > Doru > > > On Tue, Sep 3, 2013 at 12:44 PM, J.F. Rick <self(a)je77.com> wrote: > >> I'm surprised this doesn't exist yet. It seems like it would be a natural >> thing to be part of Monticello. >> >> Cheers, >> >> Jeff >> >> >> On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> What I would like to have is >>> >>> -> A way to save files per package in the image in a virtual file system >>> -> Monticello support to save that virtual file system as part of the >>> .mcz >>> >>> We could clean up *a lot* of methods in the image and even save memory: >>> right now >>> the "save Base64 encoded strings in methods" means that we have the data >>> two times: the string literal and the >>> object created from it. (and the source on disk). >>> >>> >>> On Sep 3, 2013, at 11:23 AM, phil(a)highoctane.be wrote: >>> >>> yes that would be great to have indeed. >>> >>> >>> >>> On Tuesday, September 3, 2013, J.F. Rick <self(a)je77.com> wrote: >>>> Hi everyone, >>>> I've been trying to move things over to Pharo and may be a bit more >>> active on the list. Part of that is trying to use smalltalkhub to manage my >>> code. Since I do a lot of visual work, I tend to have a lot of images (and >>> sounds) to manage. I'd like to be able to distribute them easily but I >>> can't seem to find a way to upload them to a shared directory. In Squeak, >>> there was this idea of .SAR files for distributing files. Is there a good >>> solution for this outside of the Seaside approach of embedding the file >>> information in class methods. I'm talking about hundreds of files and >>> multiple MBs here, rather than one or two small files. >>>> Cheers, >>>> Jeff >>>> -- >>>> Jochen "Jeff" Rick, Ph.D. >>>> http://www.je77.com/ >>>> Skype ID: jochenrick >>> >>> -- >>> --- >>> Philippe Back >>> Dramatic Performance Improvements >>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 >>> Mail:phil@highoctane.be | Web: http://philippeback.eu >>> Blog: http://philippeback.be | Twitter: @philippeback >>> Youtube: http://www.youtube.com/user/philippeback/videos >>> >>> High Octane SPRL >>> rue cour Boisacq 101 | 1301 Bierges | Belgium >>> >>> Pharo Consortium Member - http://consortium.pharo.org/ >>> Featured on the Software Process and Measurement Cast - >>> http://spamcast.libsyn.com >>> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value >>> Added Reseller >>> >>> >>> >>> >>> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Sept. 3, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

Le 03/09/2013 13:36, David T. Lewis a Ã©crit : > On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: >> >> >> Le 03/09/2013 12:56, David T. Lewis a ?crit : >>> On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: >>>> >>>> At the same time, parts of OSProcess seems to not be working under >>>> Pharo2 anyway :( I don't even think I'm able to run the tests (locked up >>>> my 3.0 image it did). >>>> >>> >>> My last set of updates to OSProcess for Pharo were done in January 2013, >>> and it worked at that time. Has something stopped working since then? >> >> I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a >> long time now; however, when trying to test if I did everything right on >> a 3.0 adaptation, running the tests ended up >> 1- uncovering more deprecated warnings with things that do not exist >> under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and >> the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). >> 2- test failures due to missing Xcontrol plugin? (and permanent process >> error afterwards) so I scrapped that image and my implementation, will >> rewrite everything with a fresh new image. >> >> Can I give up on trying to run OSProcess tests? > > The tests require XDisplayControlPlugin in the VM in order to do many of > the multi-process tests, because #forkSqueak is used to create cooperating > VM processes for the tests. In addition, some OSProcess function will not > work on Cog. > > If you can run the tests on an interpreter VM they should pass. If you > can get XDisplayControlPlugin included in the VM, then I expect that most > of the tests would pass (we would have to try it to be sure). Ok. > Otherwise, yes, you can give up on running the tests. You may still find > them useful as a source of examples and for running specific tests that > do not require #forkSqueak. Thanks. Thierry > Dave > > >> >>>> Looks like a version / implementation test would be the way to go. I'll >>>> write something which should work on 2.0 / 3.0, and failure protection >>>> to fallback for anything else. >>>> >>>> Is there a standard way to test for implementation/version on all Squeak >>>> and Pharo versions ? >>>> >>> >>> No. And as you can see from the examples in OSProcess, it is becoming >>> increasingly difficult to cobble up a solution that works for an externally >>> maintained package. If you can find a better solution, that would be great >>> :) >> >> I'm attempting something. Is is OK if I save in the OSProcess >> squeaksource repository? >> >> Thierry > > Can you post the method here first? I'd like to check it on some Squeak images > before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater "Test if we are on Pharo 3.0" ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ] platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use." "self platformName" self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName > Thanks! > Dave > >> >>> Dave >>> >>> >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 3, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by David T. Lewis

On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: > > > Le 03/09/2013 12:56, David T. Lewis a ?crit : > >On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: > >> > >>At the same time, parts of OSProcess seems to not be working under > >>Pharo2 anyway :( I don't even think I'm able to run the tests (locked up > >>my 3.0 image it did). > >> > > > >My last set of updates to OSProcess for Pharo were done in January 2013, > >and it worked at that time. Has something stopped working since then? > > I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a > long time now; however, when trying to test if I did everything right on > a 3.0 adaptation, running the tests ended up > 1- uncovering more deprecated warnings with things that do not exist > under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and > the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). > 2- test failures due to missing Xcontrol plugin? (and permanent process > error afterwards) so I scrapped that image and my implementation, will > rewrite everything with a fresh new image. > > Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Dave > > >>Looks like a version / implementation test would be the way to go. I'll > >>write something which should work on 2.0 / 3.0, and failure protection > >>to fallback for anything else. > >> > >>Is there a standard way to test for implementation/version on all Squeak > >>and Pharo versions ? > >> > > > >No. And as you can see from the examples in OSProcess, it is becoming > >increasingly difficult to cobble up a solution that works for an externally > >maintained package. If you can find a better solution, that would be great > >:) > > I'm attempting something. Is is OK if I save in the OSProcess > squeaksource repository? > > Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Thanks! Dave > > >Dave > > > > > > > > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 3, 2013