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

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by David T. Lewis

On Tue, Jan 29, 2013 at 09:34:37PM -0300, St?phane Ducasse wrote: > David > > The first version is loading in 2.0:) > Do you want me to publish it in the www.squeaksource.com. repository? Yes, that would be fine. I don't know if it should go in the CommandShell repository or a Pharo one? I added you as developer on CommandShell so you can commit it there. > > Some feedback: > - you have some circular dependencies between base and Commands. > Commandshell in base relies on ShellBuiltin > installCommands: aCommandArray self builtinCommands: (ShellBuiltin commandDictionaryFor: self commands: aCommandArray) > Hmmm, probably so. I have not been too careful about the dependencies in the packages within CommandShell. The hard part for me was to break all of the dependencies between CommandShell and OSProcess. I was able to do that, but I ended up with PipeableOSProcess in the CommandShell package. But most of the people who use it only want OSProcess, so I need to figure out a better way to split it. > > > - when I typed ls in the command tools I get an error because withBlanksTrimmed DNU > we could add it as an extension as follows. > String>> withBlanksTrimmed > ^ self trimBoth > > - same for withoutTrailingBlanks Oops I missed those, I meant to make compatibility methods for them. I don't want to make it a String extension because then it would be an override in Squeak. I'll probably do something like CommandShell class>>withBlanksTrimmed: aString which will work in both. > > Strange I finally typed ls and I got > > cannot access system to run 'ls' > Probably you need to load OSProcess. From a package point of view, the two are completely independent. You can load either OSProcess or CommandShell without loading the other. But from a practical point of view, CommandShell is not very useful without OSProcess to access the operating system. Thanks a lot! Dave > > On Jan 29, 2013, at 12:14 AM, David T. Lewis wrote: > > > I have updated CommandShell for Pharo 2.0, and made a few additional > > updates to OSProcess also. In addition to CommandShell-Piping, the rest > > of the CommandShell package (except for CommandShell-MVC) can now be > > loaded into Pharo 2.0. CommandShellPharo provides the menu registration > > to make "Command shell" available under "Tools" in the world menu. > > > > The repository is at http://www.squeaksource.com/CommandShell, and the > > latest versions are: > > > > CommandShell-Base-dtl.29 > > CommandShell-Piping-dtl.13 > > CommandShell-Commands-dtl.13 > > CommandShell-UI-dtl.10 > > CommandShell-Morphic-dtl.2 > > CommandShellPharo-dtl.2 > > > > Yes I know, it needs a ConfigurationOfCommandShell. > > > > There are test failures related to VM issues but the basic functionality > > is now working, and both OSProcess and CommandShell should now be working > > for Pharo on Unix/Linux (and hopefully Mac) VMs. > > > > Dave > > > > > > On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: > >> > >> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. > >> > >> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 > >> in the SqueakSource repositories for OSProcess and CommandShell. > >> > >> Thanks to Damien Cassou for doing the original work for OSProcess support > >> in Coral. I adapted his work so it will now load in both Squeak and Pharo. > >> > >> Unit test notes: > >> > >> The AioEventHandlerTestCase failures are due to AioPlugin not included in > >> the VM. I expect the tests will pass if AioPlugin is added to VM builds. > >> > >> Many test rely on #forkSqueak to create cooperating OS processes for the > >> tests. These tests fail on Cog, although this does not affect basic > >> functionality of OSProcess itself. > >> > >> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem > >> introduced in the oscog branch of the OSProcessPlugin. This should be fixed > >> in the plugin but is a minor concern and does not affect normal usage > >> of OSProcess. > >> > >> Dave > >> > > >

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by StÃ©phane Ducasse

David I commited a first version here: MCHttpRepository location: 'http://smalltalkhub.com/mc/StephaneDucasse/PetitsBazars/main' user: 'StephaneDucasse' password: '' Stef On Jan 29, 2013, at 9:34 PM, StÃ©phane Ducasse wrote: > David > > The first version is loading in 2.0:) > Do you want me to publish it in the www.squeaksource.com. repository? > > Some feedback: > - you have some circular dependencies between base and Commands. > Commandshell in base relies on ShellBuiltin > installCommands: aCommandArray self builtinCommands: (ShellBuiltin commandDictionaryFor: self commands: aCommandArray) > > > > - when I typed ls in the command tools I get an error because withBlanksTrimmed DNU > we could add it as an extension as follows. > String>> withBlanksTrimmed > ^ self trimBoth > > - same for withoutTrailingBlanks > > Strange I finally typed ls and I got > > cannot access system to run 'ls' > > > On Jan 29, 2013, at 12:14 AM, David T. Lewis wrote: > >> I have updated CommandShell for Pharo 2.0, and made a few additional >> updates to OSProcess also. In addition to CommandShell-Piping, the rest >> of the CommandShell package (except for CommandShell-MVC) can now be >> loaded into Pharo 2.0. CommandShellPharo provides the menu registration >> to make "Command shell" available under "Tools" in the world menu. >> >> The repository is at http://www.squeaksource.com/CommandShell, and the >> latest versions are: >> >> CommandShell-Base-dtl.29 >> CommandShell-Piping-dtl.13 >> CommandShell-Commands-dtl.13 >> CommandShell-UI-dtl.10 >> CommandShell-Morphic-dtl.2 >> CommandShellPharo-dtl.2 >> >> Yes I know, it needs a ConfigurationOfCommandShell. >> >> There are test failures related to VM issues but the basic functionality >> is now working, and both OSProcess and CommandShell should now be working >> for Pharo on Unix/Linux (and hopefully Mac) VMs. >> >> Dave >> >> >> On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: >>> >>> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. >>> >>> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 >>> in the SqueakSource repositories for OSProcess and CommandShell. >>> >>> Thanks to Damien Cassou for doing the original work for OSProcess support >>> in Coral. I adapted his work so it will now load in both Squeak and Pharo. >>> >>> Unit test notes: >>> >>> The AioEventHandlerTestCase failures are due to AioPlugin not included in >>> the VM. I expect the tests will pass if AioPlugin is added to VM builds. >>> >>> Many test rely on #forkSqueak to create cooperating OS processes for the >>> tests. These tests fail on Cog, although this does not affect basic >>> functionality of OSProcess itself. >>> >>> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem >>> introduced in the oscog branch of the OSProcessPlugin. This should be fixed >>> in the plugin but is a minor concern and does not affect normal usage >>> of OSProcess. >>> >>> Dave >>> >> > >

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by StÃ©phane Ducasse

David The first version is loading in 2.0:) Do you want me to publish it in the www.squeaksource.com. repository? Some feedback: - you have some circular dependencies between base and Commands. Commandshell in base relies on ShellBuiltin installCommands: aCommandArray self builtinCommands: (ShellBuiltin commandDictionaryFor: self commands: aCommandArray) - when I typed ls in the command tools I get an error because withBlanksTrimmed DNU we could add it as an extension as follows. String>> withBlanksTrimmed ^ self trimBoth - same for withoutTrailingBlanks Strange I finally typed ls and I got > cannot access system to run 'ls' On Jan 29, 2013, at 12:14 AM, David T. Lewis wrote: > I have updated CommandShell for Pharo 2.0, and made a few additional > updates to OSProcess also. In addition to CommandShell-Piping, the rest > of the CommandShell package (except for CommandShell-MVC) can now be > loaded into Pharo 2.0. CommandShellPharo provides the menu registration > to make "Command shell" available under "Tools" in the world menu. > > The repository is at http://www.squeaksource.com/CommandShell, and the > latest versions are: > > CommandShell-Base-dtl.29 > CommandShell-Piping-dtl.13 > CommandShell-Commands-dtl.13 > CommandShell-UI-dtl.10 > CommandShell-Morphic-dtl.2 > CommandShellPharo-dtl.2 > > Yes I know, it needs a ConfigurationOfCommandShell. > > There are test failures related to VM issues but the basic functionality > is now working, and both OSProcess and CommandShell should now be working > for Pharo on Unix/Linux (and hopefully Mac) VMs. > > Dave > > > On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: >> >> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. >> >> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 >> in the SqueakSource repositories for OSProcess and CommandShell. >> >> Thanks to Damien Cassou for doing the original work for OSProcess support >> in Coral. I adapted his work so it will now load in both Squeak and Pharo. >> >> Unit test notes: >> >> The AioEventHandlerTestCase failures are due to AioPlugin not included in >> the VM. I expect the tests will pass if AioPlugin is added to VM builds. >> >> Many test rely on #forkSqueak to create cooperating OS processes for the >> tests. These tests fail on Cog, although this does not affect basic >> functionality of OSProcess itself. >> >> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem >> introduced in the oscog branch of the OSProcessPlugin. This should be fixed >> in the plugin but is a minor concern and does not affect normal usage >> of OSProcess. >> >> Dave >> >

Jan. 30, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by StÃ©phane Ducasse

I'm working on a configuration. I will let you know if it loads :) can you tell me a bit the dependencies between the package? Base Pipping Commands For now I will do it really simple. Stef On Jan 29, 2013, at 12:14 AM, David T. Lewis wrote: > I have updated CommandShell for Pharo 2.0, and made a few additional > updates to OSProcess also. In addition to CommandShell-Piping, the rest > of the CommandShell package (except for CommandShell-MVC) can now be > loaded into Pharo 2.0. CommandShellPharo provides the menu registration > to make "Command shell" available under "Tools" in the world menu. > > The repository is at http://www.squeaksource.com/CommandShell, and the > latest versions are: > > CommandShell-Base-dtl.29 > CommandShell-Piping-dtl.13 > CommandShell-Commands-dtl.13 > CommandShell-UI-dtl.10 > CommandShell-Morphic-dtl.2 > CommandShellPharo-dtl.2 > > Yes I know, it needs a ConfigurationOfCommandShell. > > There are test failures related to VM issues but the basic functionality > is now working, and both OSProcess and CommandShell should now be working > for Pharo on Unix/Linux (and hopefully Mac) VMs. > > Dave > > > On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: >> >> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. >> >> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 >> in the SqueakSource repositories for OSProcess and CommandShell. >> >> Thanks to Damien Cassou for doing the original work for OSProcess support >> in Coral. I adapted his work so it will now load in both Squeak and Pharo. >> >> Unit test notes: >> >> The AioEventHandlerTestCase failures are due to AioPlugin not included in >> the VM. I expect the tests will pass if AioPlugin is added to VM builds. >> >> Many test rely on #forkSqueak to create cooperating OS processes for the >> tests. These tests fail on Cog, although this does not affect basic >> functionality of OSProcess itself. >> >> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem >> introduced in the oscog branch of the OSProcessPlugin. This should be fixed >> in the plugin but is a minor concern and does not affect normal usage >> of OSProcess. >> >> Dave >> >

Jan. 30, 2013

Re: [Pharo-project] [Issue Tracker] [Action Needed] Show Stoppers 2.0

by StÃ©phane Ducasse

thanks This is the best way to get the system better. Stef On Jan 29, 2013, at 3:16 PM, Denis Kudriashov wrote: > I uploaded fix to PharoInbox > With it image not hangs and starts correctly. > But existed loaded fonts are not valid in moved images because of saved absolute file path > > > 2013/1/29 Marcus Denker <marcus.denker(a)inria.fr> > > On Jan 29, 2013, at 10:25 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> Just want to notice issue http://code.google.com/p/pharo/issues/detail?id=6885 >> It about hanging image when it can not load fonts. >> >> If it will not fixed in 2.0 release I think many non latin users will have many bad words about pharo when they can't move their images on different computers. Images with loaded specific fonts can't start on computers which not have it (or placed in different directories). >> >> I was wait somebody with fonts knowledge look at this issue. I'm sure it is not difficult problem. Now when nobody solve it I will try fix it by myself. > > There are two solutions: > > 1) decide which issues are needed to be fixed and fixable, fix them and release > 2) Do not decide, claim that "only a perfect release is a good release", and *never* release. > > Marcus >

Jan. 29, 2013

Re: [Pharo-project] Monticello class V.S. classSide

by StÃ©phane Ducasse

> On Tue, Jan 29, 2013 at 5:49 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> What do you mean? > > the screenshot shows a line ending with 'classSide' and a line ending > with 'class'. We don't understand why there are 2 different suffixes Ok I saw after. me neither :) This is strange. Can you open a bug entry so we do not forget. Stef

Jan. 29, 2013

Re: [Pharo-project] [update 2.0] #20496

by StÃ©phane Ducasse

> Stef, do you see this entry!! yes and we spent a lot of time with it. Trying a lot of different ways to understand it and fix it. Now we are sure that this is 7240 that introduced it. Don't be worry Camille: the classBuilder is an really really ugly part of the system that we should ***throw away*** but it will take time. > https://code.google.com/p/pharo/issues/detail?id=7352 > > if you continue developing you will seriously screw up the image... > > we need discipline on that, if a HorribleErrorBlockingEverything appears the world stops > and all forces focus on thatâ¦. I was not aware of that protocol. >> From santiago :) >> >> 20496 >> ----- >> >> Issue 7349: rootApplication does not exist in Pharo. Thanks Vanessa Pena and Pablo Estefo. >> http://code.google.com/p/pharo/issues/detail?id=7349 >> >> Issue 7349: rootApplication does not exist in Pharo. Thanks Vanessa Pena and Pablo Estefo. >> http://code.google.com/p/pharo/issues/detail?id=7349 >> >> Issue 7356: New comment in MessageTally> Thanks Alexandre and Milton. >> http://code.google.com/p/pharo/issues/detail?id=7356. >> >> Issue 7328: diffmorph does not shows the middle separator. Thanks Sean De Nigris. >> http://code.google.com/p/pharo/issues/detail?id=7328 >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Tools-StephaneDucasse.1020.diff >> http://ss3.gemstone.com/ss/Pharo20/Refactoring-Tests-Core-StephaneDucasse.6… >> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.761.di… >> >> > >

Jan. 29, 2013

Re: [Pharo-project] Error: cannot remove non empty category [pharo issue 7284]

by StÃ©phane Ducasse

> Hello, > > We are working on a pharo issue 7284: "Error: cannot remove non empty category". > > A simple script to reproduce this issue is the following. > Gofer new > squeaksource: 'Roassal'; > package: 'ConfigurationOfRoassal'; > load. > ((Smalltalk at: #ConfigurationOfRoassal) project version: '1.200') load. > ((Smalltalk at: #ConfigurationOfRoassal) project version: '1.269') load. > > > The problem is in the method MCOrganizationDefinition>>unload, it uses the removeCategory: method and this method don't delete the classes inside the category and raise an error: > MCOrganizationDefinition>>unload > categories do: [ :c | SystemOrganization removeCategory:c ]. > A possible solution for this could be use the removeSystemCategory: instead, since it delete the classes inside and then the category. > MCOrganizationDefinition>>unload > categories do: [ :c | SystemOrganization removeSystemCategory: c ]. > > Perhaps, we are not sure about our solution. We want to have your opinion about it :) We discussed a lot about it. and I would love to get some other opinions on it. > It's removing the classes inside the category is what we really want to do? There is a reason for not deleting the classes inside? > > Regards, > Juan Pablo & Alejandro

Jan. 29, 2013

Re: [Pharo-project] NativeBoostFFI out parameters passing pointers back and forth is confusing...

by Stefan Marr

Hi Igor: On 29 Jan 2013, at 11:26, Igor Stasenko wrote: >> | repo repoPath cb branches headHandle | >> repo := NBExternalHandle new. >> repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. > > why not just pass the string? I had the feeling (i.e., I had crashes, and was checking with GDB) that plain Smalltalk strings ala 'test' are not actually passed properly into the function. What is passed in is a reference to the begin of the string, but not a properly null terminated string. Do I miss something? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 29, 2013

Re: [Pharo-project] Where to get the VM?

by StÃ©phane Ducasse

On Jan 29, 2013, at 7:38 PM, Camillo Bruni wrote: > Yes that would be the ideal case, but the limited space on our old brittle jenkins > made our system very fragile. > > We could only keep a couple of versions of each build. > Result? > We lost the stable builds, hence I started to backup files in the easiest way possible, > on a dumb file server. > > How could we have avoided the current mess? > Simply by moving early enough to the right infrastructure half a year ago would have saved > us many burnt brain cells. Yes I totally agree! > So I naturally get upset if all of a sudden everything has to work out of the blue. I understand and you pushed a lot. Now for 2.0 we should get to the next level. > We left the old jenkins in ruins and we are building the new one ad-hoc. There is no > going back as the old server is simply dead, besides our admins are clueless about the > crashes, taking random reboots as a good habit. > > So I expect that YOU take your time to look at the new setup yes but do not alex or a guys with two months of pharo to do it and during our great sprint some smart guys just not even got 1 months of pharo. > and understand it. Yes do you think that I'm doing nothing - just relaxing in chile :) Now I'm sick and I promote Pharo and I talk with people of govermental agencies during meetings in spanish to sell projects and give job to people :). Now we are not talking about me but the outside world. You know rmod not. > If I had to take a look at our budget I would do the same, of course with my amount > if complaint because I would not know your private systemâ¦ Our team budget is freely accessible to you. This is just that you never needed to look at it. Because your salary is not on our budget :). So you are safe :) Stef

Jan. 29, 2013