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

Re: [Pharo-project] [ANN]

by Michael van der Gulik

Argh. Please reply below other people's emails. Bill > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Michael van > der Gulik > *Sent:* Thursday, September 03, 2009 5:54 PM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] [ANN] > > > > 2009/9/4 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > >> El vie, 04-09-2009 a las 09:33 +1200, Michael van der Gulik escribiÃ³: >> > >> > >> > On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse >> > <stephane.ducasse(a)inria.fr> wrote: >> > - Issue 1144: Many occurrences of "ReadStream on: >> > aCollection" which >> > can be replaced with "aCollection readStream" >> > >> > >> > For what it's worth, I prefer the style of "ReadStream on: xxx". I >> > prefer to choose the stream class rather than let the collection >> > choose it for me. >> >> But don't you always have the option to call ReadStream on: object, >> even though object class has a readStream method? >> > > > In Pharo, sure. > > However, in SecureSqueak, there won't be >>readStream methods. I'll spare > the details because I hate multi-page emails. Ask me if you're interested. > > 2009/9/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Ok, I'm interested :) Is there a security argument? Off the top, it does > not sound like something I would want to use. If you can make a case that > #readStream is dangerous, I'm all ears. If it is simply that it closes off > modifications to the base classes, it is probably too restictive for my > tastes. Locking it down **after** I add the missing methods and deploy on > a server, that's another matter. But then, there would be #readStream > methods... > > Excuse the funny formatting. GMail sometimes doesn't cooperate. Also, this is getting a bit off topic on the Pharo list. No, it's not really to do with security. It's to do with this package system I invented. Basically, I want to reduce package dependencies. Putting >>readStream in kernel classes would make a package dependency between the Collection package and the Stream package. If the Collections package was loaded into SecureSqueak, the package architecture would be forced to load the Stream package as well even if it isn't used. If your own package depended on both Collection and a different Streams package, anybody who loaded your code would need to load two Streams packages. There's no reason that >>readStream couldn't be included in a Collections package, provided that it's not in the Collections package provided with the SecureSqueak Kernel. I want the Kernel package to have as few dependencies as possible. Packages are read-only in SecureSqueak and the Kernel package contains special objects, meaning that Kernel and its dependencies can not be upgraded without distributing a new image. Collections would be a non-upgradable dependency of Kernel, so I'd be trying hard to not also make Streams also a non-upgradable dependency. More info: http://gulik.pbwiki.com/Namespaces http://gulik.pbwiki.com/Packages Gulik. -- http://gulik.pbwiki.com/

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

Sig, I doubt you missed anything; I dragged EndOfStreamError into it because IMHO, that's where the real problems wait for us. If I had to make code work on 3.10, I would fill in missing pieces (in this case #readStream) there rather than hold back my Pharo code; in fact, that's more or less what I am doing with Pharo too. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, September 03, 2009 6:42 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 2009/9/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case. Â It is easy to define #readStream where appropriate, and IMHO Pharo should do so. Â Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods. > I understanding this, but at that moment i weren't sure if this is a missing method, or it is missing by intent. Also i had to make sure that my code works also for 3.10. So, for me it was an easiest thing to leave things as they are. > I submit that the problem is instead all of the external code that will still explicitly reference ReadStream. Â That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board. > Right: i'm trying to not use globals if its possible, except well known classes like Arrays, collections etc. > More challenging still are the inconsistencies in exhaustion behavior. Â Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal. Â I can also not afford to wait for the decision to be made and imlemented. Â For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code. Â If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages. i missed this part of discussion, so i can't comment the above. > > FWIW, one of the first things I did was define #readStream on various collections and collection classes. Â Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days. > The arguments like 'it is done like that somewhere' is a bad way to convince me (and i assume many others). I think you are already given enough arguments before and they already good enough to convince everyone (i hope), except me, because you don't need to convince me on that :) > Bill -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Igor Stasenko

2009/9/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case. Â It is easy to define #readStream where appropriate, and IMHO Pharo should do so. Â Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods. > I understanding this, but at that moment i weren't sure if this is a missing method, or it is missing by intent. Also i had to make sure that my code works also for 3.10. So, for me it was an easiest thing to leave things as they are. > I submit that the problem is instead all of the external code that will still explicitly reference ReadStream. Â That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board. > Right: i'm trying to not use globals if its possible, except well known classes like Arrays, collections etc. > More challenging still are the inconsistencies in exhaustion behavior. Â Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal. Â I can also not afford to wait for the decision to be made and imlemented. Â For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code. Â If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages. i missed this part of discussion, so i can't comment the above. > > FWIW, one of the first things I did was define #readStream on various collections and collection classes. Â Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days. > The arguments like 'it is done like that somewhere' is a bad way to convince me (and i assume many others). I think you are already given enough arguments before and they already good enough to convince everyone (i hope), except me, because you don't need to convince me on that :) > Bill -- Best regards, Igor Stasenko AKA sig.

Sept. 3, 2009

Re: [Pharo-project] FFI meets 74 bits - there be dragons here??

by Schwab,Wilhelm K

Obviously I mean 64 bits :) -----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: Thursday, September 03, 2009 6:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] FFI meets 74 bits - there be dragons here?? Hello all, So far, I am one for two on getting ODBC to work on my 64 bit Ubuntu system. I'm using a pre-production (the only option we were given by our IT guys) Cisco vpn that does not support 64 bit systems; enter a 32 bit vpn and some copied libraries. After that fun, I have been able to get isql (unixODBC test utility) to see a MySQL server I have living on a blade machine. That much works. My Pharo image seems unable to talk to it, and I am wondering whether it might be because the library is 64 bit - please excuse me if that's just plain stupid. Of course, so was installing the 64 bit OS<g>, but I figure there will not be an option some day, so I'm trying to get my bad news early. Any ideas about how to proceed? I'm thinking of subclassing ODBCLibrary and tweaking the types (something on the net addresses some changes) to see if I can get some success and then keep going as needed. Does that sound reasonable? Any better ideas? FreeTDS is letting me down talking to a SQL server machine. If anyone has set that up successfully, I would greatly enjoy knowing what you did. 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

[Pharo-project] FFI meets 74 bits - there be dragons here??

by Schwab,Wilhelm K

Hello all, So far, I am one for two on getting ODBC to work on my 64 bit Ubuntu system. I'm using a pre-production (the only option we were given by our IT guys) Cisco vpn that does not support 64 bit systems; enter a 32 bit vpn and some copied libraries. After that fun, I have been able to get isql (unixODBC test utility) to see a MySQL server I have living on a blade machine. That much works. My Pharo image seems unable to talk to it, and I am wondering whether it might be because the library is 64 bit - please excuse me if that's just plain stupid. Of course, so was installing the 64 bit OS<g>, but I figure there will not be an option some day, so I'm trying to get my bad news early. Any ideas about how to proceed? I'm thinking of subclassing ODBCLibrary and tweaking the types (something on the net addresses some changes) to see if I can get some success and then keep going as needed. Does that sound reasonable? Any better ideas? FreeTDS is letting me down talking to a SQL server machine. If anyone has set that up successfully, I would greatly enjoy knowing what you did. Bill

Sept. 3, 2009

Re: [Pharo-project] [ANN] 10430

by Carlos Crosetti

- Polymorph Widgets what widgets were added, changed? -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Stephane Ducasse Enviado el: Miercoles, 02 de Septiembre de 2009 02:42 p.m. Para: Pharo Development Asunto: [Pharo-project] [ANN] 10430 - Issue 1135: FreeType fonts render incorrectly after repeated image save without quitting Thanks andy!!! - Issue 1062: Deprecation of String>>asCharacter leads to strange behavior - Polymorph Widgets Thanks gary!!!! Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008 11:07 a.m.

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

Ok, I'm interested :) Is there a security argument? Off the top, it does not sound like something I would want to use. If you can make a case that #readStream is dangerous, I'm all ears. If it is simply that it closes off modifications to the base classes, it is probably too restictive for my tastes. Locking it down **after** I add the missing methods and deploy on a server, that's another matter. But then, there would be #readStream methods... Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik Sent: Thursday, September 03, 2009 5:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 2009/9/4 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>> El vie, 04-09-2009 a las 09:33 +1200, Michael van der Gulik escribiÃ³: > > > On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > - Issue 1144: Many occurrences of "ReadStream on: > aCollection" which > can be replaced with "aCollection readStream" > > > For what it's worth, I prefer the style of "ReadStream on: xxx". I > prefer to choose the stream class rather than let the collection > choose it for me. But don't you always have the option to call ReadStream on: object, even though object class has a readStream method? In Pharo, sure. However, in SecureSqueak, there won't be >>readStream methods. I'll spare the details because I hate multi-page emails. Ask me if you're interested. Gulik. -- http://gulik.pbwiki.com/

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Michael van der Gulik

2009/9/4 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El vie, 04-09-2009 a las 09:33 +1200, Michael van der Gulik escribiÃ³: > > > > > > On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > > - Issue 1144: Many occurrences of "ReadStream on: > > aCollection" which > > can be replaced with "aCollection readStream" > > > > > > For what it's worth, I prefer the style of "ReadStream on: xxx". I > > prefer to choose the stream class rather than let the collection > > choose it for me. > > But don't you always have the option to call ReadStream on: object, > even though object class has a readStream method? > In Pharo, sure. However, in SecureSqueak, there won't be >>readStream methods. I'll spare the details because I hate multi-page emails. Ask me if you're interested. Gulik. -- http://gulik.pbwiki.com/

Sept. 3, 2009

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

by Schwab,Wilhelm K

I don't have a copy of VW handy, but Dolphin uses #readStream and #writeStream. I agree that this is not really an #as* situation, even w/o the dialoect compatibility reasons against it. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Thursday, September 03, 2009 5:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Added package SLICE-RemoveReferencesToReadStreamOn-PeterHugossonMiller.3 to PharoInbox In VW, the methods are called readStream and writeStream. Personally, I prefer that, as a method starting with as... to me indicates having created a new equivalent object, not just a wrapper which is used to access the original object. There's a big difference between calling f.ex. _as_Array on an SequenceableCollection, then messing with the elements of the object returned, and doing the same with a method called asReadStream. Cheers, Henry On Sep 3, 2009, at 4:46 13PM, Peter Hugosson-Miller wrote: I don't know how this is done in VW, but in any case I would also prefer the method to be called #asReadStream, since it more clearly expresses the fact that there is a conversion happening. In the same way, I would like to suggest the method SequenceableCollection>>#writeStream would be better named #asWriteStream, and I also think that the creation of a new method SequenceableCollection>>#asReadWriteStream would be a good idea. -- Cheers, Peter On Thu, Sep 3, 2009 at 4:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: I'm integrating your changes. Now I was wondering if somebody knows if it VW we get readStream too because I would prefer to have a better message than readStream aCol asReadStream ? What do you think? Stef On Sep 2, 2009, at 9:59 PM, Peter Hugosson-Miller wrote: > On Wed, Sep 2, 2009 at 9:30 PM, Adrian Lienhard <adi(a)netstyle.ch<mailto:adi@netstyle.ch>> > wrote: > Welcome, Peter! > > When you commit a change it would be good to also open an issue in the > tracker (and tell there which slice this is and in the slice comment > say which issue number it is). Like this it is easier to keep track of > changes. > > Cheers, > Adrian > > Strange, I thought I had done that, but it was probably just the > wrong part of the system (I'm just learning). > > This is the issue I created for the slice: http://code.google.com/p/pharo/issues/detail?id=1144 > so could you please tell me what I should have done instead (or as > well ;-))? > > Thanks in advance, > Peter > _______________________________________________ > 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

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

Sure. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Thursday, September 03, 2009 4:56 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] El vie, 04-09-2009 a las 09:33 +1200, Michael van der Gulik escribiÃ³: > > > On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > - Issue 1144: Many occurrences of "ReadStream on: > aCollection" which > can be replaced with "aCollection readStream" > > > For what it's worth, I prefer the style of "ReadStream on: xxx". I > prefer to choose the stream class rather than let the collection > choose it for me. But don't you always have the option to call ReadStream on: object, even though object class has a readStream method? > > > Gulik. > > -- > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ 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