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

Re: [Pharo-project] Rio: binary mode copy not keep

by StÃ©phane Ducasse

May be keith will reply to you. For 1.1 I really want to kick FileDirectory crap out. I'm tired about it. Stef On Sep 3, 2009, at 8:52 AM, Vicnet wrote: > > Hello, > > I try to use Directory addTree: > > The src directory I use containts jpeg file. > addTree fails because FileKernel use a FileJpeg in InputStream and > there is > a input pb on this file. > > I try to add binary mode : > > base binary addTree: dest > > but it is the same result: input error. > > When I copy this file directly with binary mode, it is ok. > > addTree collect files/dirs to copy but dot not transmit the binary > flag. > Is it normal ? > > Directory home binary files first isBinary ==> false ! > > Should it be true ? > > Is there another, 'official', way to binary recursive copy ? > > > I use Pharo on Windows plateform. > > a+ > Vicnet > -- > View this message in context: http://n2.nabble.com/Rio-binary-mode-copy-not-keep-tp3571512p3571512.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2009

Re: [Pharo-project] [Squeak-fr] Copier un fichier d'un rep. vers un autre

by Luc Fabresse

I confirm the syntax error in Rio (File-Kernel-kph-31) reported by Vicnet. Just try : Installer ss project: 'Rio'; install: 'File-Kernel' to reproduce it. This error wasn't in the previous version (30). It is just a pragma that is not in comment in the FileMacOSXExecutive class>>getenv: method. #Luc Le 1 septembre 2009 15:34, Vicnet-2 <oselev(a)yahoo.fr> a Ã©crit : > > Par contre, avec la derniÃ¨re version de File-Kernel, la kph-31, j'ai une > "Syntax Error": > FileMacOSXExecutive class as yet unclassified getenv: > > Je ne vois pas Ã quoi cela correspond et si je fais Proceed, ca passe et > cela semble fonctionner. > > D'autre part la version prÃ©cÃ©dente est ok ! > > a+ > Vicnet >

Sept. 3, 2009

[Pharo-project] Installer bug

by Luc Fabresse

Installer cache project: 'CustomProject' ; install: 'CustomProject' does not work properly because in InstallerMonticello>>project:, a ByteString path is stored instead of a FileDirectory and because MCCacheRepository default is a directory *without subdir*. I attached a quick fix, that make it work for both Cache and repository with subdirs. #Luc

Sept. 3, 2009

[Pharo-project] Rio: binary mode copy not keep

by Vicnet

Hello, I try to use Directory addTree: The src directory I use containts jpeg file. addTree fails because FileKernel use a FileJpeg in InputStream and there is a input pb on this file. I try to add binary mode : base binary addTree: dest but it is the same result: input error. When I copy this file directly with binary mode, it is ok. addTree collect files/dirs to copy but dot not transmit the binary flag. Is it normal ? Directory home binary files first isBinary ==> false ! Should it be true ? Is there another, 'official', way to binary recursive copy ? I use Pharo on Windows plateform. a+ Vicnet -- View this message in context: http://n2.nabble.com/Rio-binary-mode-copy-not-keep-tp3571512p3571512.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 3, 2009

Re: [Pharo-project] Added package SLICE-RemoveReferencesToReadStreamOn-PeterHugossonMiller.3 to PharoInbox

by StÃ©phane Ducasse

I asked damien because I thought it was something he already did to ease Nile integration. On Sep 2, 2009, at 7:35 PM, Henrik Johansen wrote: > Loads fine for me, and tests remain unchanged. > Also seems like a reasonable change. > Will you do WriteStream on: and friends next? ;) > > Cheers, > Henry > > On Sep 2, 2009, at 6:21 35PM, Peter Hugosson-Miller wrote: > >> Hi there, >> >> This is my first contribution to PharO :-) >> >> I've followed the instructions on the "How to Contribute" page, and >> there is now a bunch of packages, and a SLICE-package that depends >> on all of them (named in the subject of this message) in the PharO >> inbox. One of the packages (KernelTests-PeterHugossonMiller. >> 142.mcz) I have managed to miss the log message, but otherwise I >> believe I have done everything correctly. I attach screenshots of >> the TestRunner results run before and after my changes. >> >> Please could someone review the changes and let me know how I did. >> >> -- >> Cheers, >> Peter >> >> Before my changes: >> >> <Before_RemoveReferencesToReadStreamOn.png> >> >> After my changes: >> <After_RemoveReferencesToReadStreamOn.png> >> >> _______________________________________________ >> 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. 3, 2009

Re: [Pharo-project] ODBCWarning

by Schwab,Wilhelm K

Brian, I'm not sure if I did it correctly, but it did not quite do the right thing. It caught the extension methods, but there are a few required classes that are still in the ODBC branch of the Dolphincompatibility package. Does that sound familiar and fixable? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Brian Brown Sent: Wednesday, September 02, 2009 10:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ODBCWarning On Sep 2, 2009, at 9:12 PM, Schwab,Wilhelm K wrote: Failing that, is there a way to get Monticello to save only part of a package? For example, it would be a lot easier for me to screen DolphinCompatibility-ODBC than all of DolphinCompatibility. Are there tools to save only that part of it? Bill I believe if you create a new package in the Monticello browser named DolphinCompatibility-ODBC and save it, you will get what you want. It's always easy to save sub packages using the more specfic category. - Brian -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban A. Maringolo Sent: Wednesday, September 02, 2009 9:21 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] ODBCWarning Bill, I celebrate your work of bringing the dolphin near the pharo ;-) Thanks for your collaboration, Esteban A. Maringolo 2009/9/2 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> Hello all, I think I have the catalog (tables and field name/type given a table name) working. The latest ODBC offering appears to work, but in fairness to me, it does not work the same way it did (some time ago) when I crossed database access off of my potential-show-stopper list. Re the warnings about change of language, for some strange reason, I find it very easy to believe that this is a Microsoft idiosyncrasy and so I added a suitable #on:do: to capture the warning. That could be bad though; better ideas are welcome. The problem I had going from Linux to Windows will probably persist. Of course, I would like to see the startup/shutdown system revised to make such things easier to get right, after which it would hopefully become short work to fix. The ODBC package derives ODBCRow from IdentityDictionary and ODBCResultSet from Stream. IMHO, it always seems cleaner to compose rather than inherit the limited functionality that the base class provides. However, the inheritance is not really hurting anything here; socket addresses being inherited from byte arrays *is* hurting us. I brushed up against that at one point, but was able to work around it. When it gets between me and something I need, I will introduce an InternetAddress class and try to lazily resolve names and addresses, fix the printing, etc. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Tuesday, September 01, 2009 3:15 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: [Pharo-project] ODBCWarning The porting continues... It is getting closer to doing something. It just raised an ODBCWarning about the server changing the language to us_english. Any ideas? Either I do not care or should set it up front?? One thing really surprised me, and note that I might have brought this on myself (though I think that is unlikely) by messing with startup and shutdown: the ODBCLibrary was stubbornly clinging to the Linux library from my home machine. I finally used ODBCLibrary default initialize. which seemed to put an end to the separation anxiety. Is there a better fix? I suppose I should try this in a clean image to see if there is really a problem therein, but that will be a little hard to do without a lot of my code, almost any of which either depends on changes I have made or could have caused the problem. Maybe I should ask whether some of you use ODBC on Windows and Linux and have no problems moving between the machines. Bill _______________________________________________ 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 _______________________________________________ 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

Sept. 3, 2009

Re: [Pharo-project] ODBCWarning

by Brian Brown

On Sep 2, 2009, at 9:12 PM, Schwab,Wilhelm K wrote: > > > Failing that, is there a way to get Monticello to save only part of > a package? For example, it would be a lot easier for me to screen > DolphinCompatibility-ODBC than all of DolphinCompatibility. Are > there tools to save only that part of it? > > Bill I believe if you create a new package in the Monticello browser named DolphinCompatibility-ODBC and save it, you will get what you want. It's always easy to save sub packages using the more specfic category. - Brian > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of Esteban A. > Maringolo > Sent: Wednesday, September 02, 2009 9:21 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] ODBCWarning > > Bill, > > I celebrate your work of bringing the dolphin near the pharo ;-) > > Thanks for your collaboration, > > Esteban A. Maringolo > > > 2009/9/2 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> >> Hello all, >> >> I think I have the catalog (tables and field name/type given a >> table name) working. The latest ODBC offering appears to work, but >> in fairness to me, it does not work the same way it did (some time >> ago) when I crossed database access off of my potential-show- >> stopper list. >> >> Re the warnings about change of language, for some strange reason, >> I find it very easy to believe that this is a Microsoft >> idiosyncrasy and so I added a suitable #on:do: to capture the >> warning. That could be bad though; better ideas are welcome. >> >> The problem I had going from Linux to Windows will probably >> persist. Of course, I would like to see the startup/shutdown >> system revised to make such things easier to get right, after which >> it would hopefully become short work to fix. >> >> The ODBC package derives ODBCRow from IdentityDictionary and >> ODBCResultSet from Stream. IMHO, it always seems cleaner to >> compose rather than inherit the limited functionality that the base >> class provides. However, the inheritance is not really hurting >> anything here; socket addresses being inherited from byte arrays >> *is* hurting us. I brushed up against that at one point, but was >> able to work around it. When it gets between me and something I >> need, I will introduce an InternetAddress class and try to lazily >> resolve names and addresses, fix the printing, etc. >> >> Bill >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Schwab,Wilhelm K >> Sent: Tuesday, September 01, 2009 3:15 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] ODBCWarning >> >> The porting continues... It is getting closer to doing something. >> It just raised an ODBCWarning about the server changing the >> language to us_english. Any ideas? Either I do not care or should >> set it up front?? >> >> One thing really surprised me, and note that I might have brought >> this >> on myself (though I think that is unlikely) by messing with startup >> and shutdown: the ODBCLibrary was stubbornly clinging to the Linux >> library from my home machine. I finally used >> >> ODBCLibrary default initialize. >> >> which seemed to put an end to the separation anxiety. Is there a >> better fix? I suppose I should try this in a clean image to see if >> there is really a problem therein, but that will be a little hard >> to do without a lot of my code, almost any of which either depends >> on changes I have made or could have caused the problem. >> >> Maybe I should ask whether some of you use ODBC on Windows and >> Linux and have no problems moving between the machines. >> >> Bill >> >> _______________________________________________ >> 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. 3, 2009

Re: [Pharo-project] ODBCWarning

by Schwab,Wilhelm K

Esteban, Of course the real goal is to bring the dolphin to the penguin with the pharo's help :) Thanks to all for making it an attainable goal. A good next step would be to package the catalog functions for others to use. The code currently lives in an ODBC sub-package (or whatever the correct term is) of my DolphinCompatibility package, some of which is very preliminary at present. One concern I have is checking code for comments that should not be made public due to non-disclosure agreements. It would be nice if there were a way to create syntax-highlighted HTML from a PackageInfo instance. Any ideas? Failing that, is there a way to get Monticello to save only part of a package? For example, it would be a lot easier for me to screen DolphinCompatibility-ODBC than all of DolphinCompatibility. Are there tools to save only that part of it? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban A. Maringolo Sent: Wednesday, September 02, 2009 9:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ODBCWarning Bill, I celebrate your work of bringing the dolphin near the pharo ;-) Thanks for your collaboration, Esteban A. Maringolo 2009/9/2 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > > Hello all, > > I think I have the catalog (tables and field name/type given a table name) working. Â The latest ODBC offering appears to work, but in fairness to me, it does not work the same way it did (some time ago) when I crossed database access off of my potential-show-stopper list. > > Re the warnings about change of language, for some strange reason, I find it very easy to believe that this is a Microsoft idiosyncrasy and so I added a suitable #on:do: to capture the warning. Â That could be bad though; better ideas are welcome. > > The problem I had going from Linux to Windows will probably persist. Â Of course, I would like to see the startup/shutdown system revised to make such things easier to get right, after which it would hopefully become short work to fix. > > The ODBC package derives ODBCRow from IdentityDictionary and ODBCResultSet from Stream. Â IMHO, it always seems cleaner to compose rather than inherit the limited functionality that the base class provides. Â However, the inheritance is not really hurting anything here; socket addresses being inherited from byte arrays *is* hurting us. Â I brushed up against that at one point, but was able to work around it. Â When it gets between me and something I need, I will introduce an InternetAddress class and try to lazily resolve names and addresses, fix the printing, etc. > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Schwab,Wilhelm K > Sent: Tuesday, September 01, 2009 3:15 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] ODBCWarning > > The porting continues... Â It is getting closer to doing something. Â It just raised an ODBCWarning about the server changing the language to us_english. Â Any ideas? Â Either I do not care or should set it up front?? > > One thing really surprised me, and note that I might have brought this > on myself (though I think that is unlikely) by messing with startup > and shutdown: the ODBCLibrary was stubbornly clinging to the Linux > library from my home machine. Â I finally used > > Â Â ODBCLibrary default initialize. > > which seemed to put an end to the separation anxiety. Â Is there a better fix? Â I suppose I should try this in a clean image to see if there is really a problem therein, but that will be a little hard to do without a lot of my code, almost any of which either depends on changes I have made or could have caused the problem. > > Maybe I should ask whether some of you use ODBC on Windows and Linux and have no problems moving between the machines. > > Bill > > _______________________________________________ > 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. 3, 2009

Re: [Pharo-project] ODBCWarning

by Esteban A. Maringolo

Bill, I celebrate your work of bringing the dolphin near the pharo ;-) Thanks for your collaboration, Esteban A. Maringolo 2009/9/2 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > > Hello all, > > I think I have the catalog (tables and field name/type given a table name) working. Â The latest ODBC offering appears to work, but in fairness to me, it does not work the same way it did (some time ago) when I crossed database access off of my potential-show-stopper list. > > Re the warnings about change of language, for some strange reason, I find it very easy to believe that this is a Microsoft idiosyncrasy and so I added a suitable #on:do: to capture the warning. Â That could be bad though; better ideas are welcome. > > The problem I had going from Linux to Windows will probably persist. Â Of course, I would like to see the startup/shutdown system revised to make such things easier to get right, after which it would hopefully become short work to fix. > > The ODBC package derives ODBCRow from IdentityDictionary and ODBCResultSet from Stream. Â IMHO, it always seems cleaner to compose rather than inherit the limited functionality that the base class provides. Â However, the inheritance is not really hurting anything here; socket addresses being inherited from byte arrays *is* hurting us. Â I brushed up against that at one point, but was able to work around it. Â When it gets between me and something I need, I will introduce an InternetAddress class and try to lazily resolve names and addresses, fix the printing, etc. > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K > Sent: Tuesday, September 01, 2009 3:15 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] ODBCWarning > > The porting continues... Â It is getting closer to doing something. Â It just raised an ODBCWarning about the server changing the language to us_english. Â Any ideas? Â Either I do not care or should set it up front?? > > One thing really surprised me, and note that I might have brought this on myself (though I think that is unlikely) by messing with startup and shutdown: the ODBCLibrary was stubbornly clinging to the Linux library from my home machine. Â I finally used > > Â Â ODBCLibrary default initialize. > > which seemed to put an end to the separation anxiety. Â Is there a better fix? Â I suppose I should try this in a clean image to see if there is really a problem therein, but that will be a little hard to do without a lot of my code, almost any of which either depends on changes I have made or could have caused the problem. > > Maybe I should ask whether some of you use ODBC on Windows and Linux and have no problems moving between the machines. > > Bill > > _______________________________________________ > 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. 3, 2009

Re: [Pharo-project] ODBCWarning

by Schwab,Wilhelm K

Hello all, I think I have the catalog (tables and field name/type given a table name) working. The latest ODBC offering appears to work, but in fairness to me, it does not work the same way it did (some time ago) when I crossed database access off of my potential-show-stopper list. Re the warnings about change of language, for some strange reason, I find it very easy to believe that this is a Microsoft idiosyncrasy and so I added a suitable #on:do: to capture the warning. That could be bad though; better ideas are welcome. The problem I had going from Linux to Windows will probably persist. Of course, I would like to see the startup/shutdown system revised to make such things easier to get right, after which it would hopefully become short work to fix. The ODBC package derives ODBCRow from IdentityDictionary and ODBCResultSet from Stream. IMHO, it always seems cleaner to compose rather than inherit the limited functionality that the base class provides. However, the inheritance is not really hurting anything here; socket addresses being inherited from byte arrays *is* hurting us. I brushed up against that at one point, but was able to work around it. When it gets between me and something I need, I will introduce an InternetAddress class and try to lazily resolve names and addresses, fix the printing, etc. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Tuesday, September 01, 2009 3:15 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] ODBCWarning The porting continues... It is getting closer to doing something. It just raised an ODBCWarning about the server changing the language to us_english. Any ideas? Either I do not care or should set it up front?? One thing really surprised me, and note that I might have brought this on myself (though I think that is unlikely) by messing with startup and shutdown: the ODBCLibrary was stubbornly clinging to the Linux library from my home machine. I finally used ODBCLibrary default initialize. which seemed to put an end to the separation anxiety. Is there a better fix? I suppose I should try this in a clean image to see if there is really a problem therein, but that will be a little hard to do without a lot of my code, almost any of which either depends on changes I have made or could have caused the problem. Maybe I should ask whether some of you use ODBC on Windows and Linux and have no problems moving between the machines. Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2009