- Pharo-dev - lists.pharo.org

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

by Schwab,Wilhelm K

I'm still filling gaps in my Linux juju kit, and in this case learned that one uses the file command to discover the nature of a binary. Libodbc.so tuns out to be symbolic link to a 64 bit binary. unixodbc.org (under manuals aka /doc) has a document on changes for 64 bits. I do not yet vouch for its correctness, but they have me fooled so far :) Could some kind FFI guru give me an idea of what ugliness might await me? 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: 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. 4, 2009

Re: [Pharo-project] Added package SLICE-ReplaceOccurrencesOfWriteStreamOn-PeterHugossonMiller.2.mcz

by Peter Hugosson-Miller

On Fri, Sep 4, 2009 at 3:49 AM, Peter Hugosson-Miller <oldmanlink(a)gmail.com>wrote: > Name: SLICE-ReplaceOccurrencesOfWriteStreamOn-PeterHugossonMiller.2 > Author: PeterHugossonMiller > Time: 4 September 2009, 3:38:05 am > UUID: 91c806ad-26c3-43a4-b1b6-85c520a9c710 > Ancestors: SLICE-ReplaceOccurrencesOfWriteStreamOn-PeterHugossonMiller.1 > Dependencies: Balloon-PeterHugossonMiller.31, > Collections-Abstract-PeterHugossonMiller.23, > Collections-Streams-PeterHugossonMiller.26, > Collections-Strings-PeterHugossonMiller.35, > Collections-Text-PeterHugossonMiller.13, > Collections-Unordered-PeterHugossonMiller.37, > CollectionsTests-PeterHugossonMiller.389, Compiler-PeterHugossonMiller.122, > Compression-PeterHugossonMiller.36, Files-PeterHugossonMiller.ducasse.76, > FreeType-PeterHugossonMiller.461, Graphics-PeterHugossonMiller.127, > GraphicsTests-PeterHugossonMiller.19, HostMenus-PeterHugossonMiller.30, > Kernel-PeterHugossonMiller.397, KernelTests-PeterHugossonMiller.146, > Morphic-PeterHugossonMiller.367, Multilingual-PeterHugossonMiller.79, > Network-Kernel-PeterHugossonMiller.16, > Network-MailSending-PeterHugossonMiller.3, > Network-Protocols-PeterHugossonMiller.15, > Network-RFC822-PeterHugossonMiller.3, > Network-RemoteDirectory-PeterHugossonMiller.14, > Network-URI-PeterHugossonMiller.7, Network-UUID-PeterHugossonMiller.5, > Network-Url-PeterHugossonMiller.13, NetworkTests-PeterHugossonMiller.15, > Polymorph-EventEnhancements-PeterHugossonMiller.5, > ST80-PeterHugossonMiller.80, SUnit-PeterHugossonMiller.76, > Services-Base-PeterHugossonMiller.53, System-Changes-PeterHugossonMiller.13, > System-Digital Signatures-PeterHugossonMiller.4, > System-FilePackage-PeterHugossonMiller.11, > System-Hashing-PeterHugossonMiller.2, System-Object > Storage-PeterHugossonMiller.29, System-Serial Port-PeterHugossonMiller.7, > System-Support-PeterHugossonMiller.80, System-Tools-PeterHugossonMiller.11, > Tests-PeterHugossonMiller.17, Tools-PeterHugossonMiller.197, > Traits-PeterHugossonMiller.312, TrueType-PeterHugossonMiller.12, > VB-Regex-PeterHugossonMiller.32 > > Fix for Issue 1153 - Many occurrences of "WriteStream on: aCollection" > which can be replaced with "aCollection writeStream" > > -- > Cheers, > Peter > Link to issue: http://code.google.com/p/pharo/issues/detail?id=1153

Sept. 4, 2009

[Pharo-project] Added package SLICE-ReplaceOccurrencesOfWriteStreamOn-PeterHugossonMiller.2.mcz

by Peter Hugosson-Miller

Name: SLICE-ReplaceOccurrencesOfWriteStreamOn-PeterHugossonMiller.2 Author: PeterHugossonMiller Time: 4 September 2009, 3:38:05 am UUID: 91c806ad-26c3-43a4-b1b6-85c520a9c710 Ancestors: SLICE-ReplaceOccurrencesOfWriteStreamOn-PeterHugossonMiller.1 Dependencies: Balloon-PeterHugossonMiller.31, Collections-Abstract-PeterHugossonMiller.23, Collections-Streams-PeterHugossonMiller.26, Collections-Strings-PeterHugossonMiller.35, Collections-Text-PeterHugossonMiller.13, Collections-Unordered-PeterHugossonMiller.37, CollectionsTests-PeterHugossonMiller.389, Compiler-PeterHugossonMiller.122, Compression-PeterHugossonMiller.36, Files-PeterHugossonMiller.ducasse.76, FreeType-PeterHugossonMiller.461, Graphics-PeterHugossonMiller.127, GraphicsTests-PeterHugossonMiller.19, HostMenus-PeterHugossonMiller.30, Kernel-PeterHugossonMiller.397, KernelTests-PeterHugossonMiller.146, Morphic-PeterHugossonMiller.367, Multilingual-PeterHugossonMiller.79, Network-Kernel-PeterHugossonMiller.16, Network-MailSending-PeterHugossonMiller.3, Network-Protocols-PeterHugossonMiller.15, Network-RFC822-PeterHugossonMiller.3, Network-RemoteDirectory-PeterHugossonMiller.14, Network-URI-PeterHugossonMiller.7, Network-UUID-PeterHugossonMiller.5, Network-Url-PeterHugossonMiller.13, NetworkTests-PeterHugossonMiller.15, Polymorph-EventEnhancements-PeterHugossonMiller.5, ST80-PeterHugossonMiller.80, SUnit-PeterHugossonMiller.76, Services-Base-PeterHugossonMiller.53, System-Changes-PeterHugossonMiller.13, System-Digital Signatures-PeterHugossonMiller.4, System-FilePackage-PeterHugossonMiller.11, System-Hashing-PeterHugossonMiller.2, System-Object Storage-PeterHugossonMiller.29, System-Serial Port-PeterHugossonMiller.7, System-Support-PeterHugossonMiller.80, System-Tools-PeterHugossonMiller.11, Tests-PeterHugossonMiller.17, Tools-PeterHugossonMiller.197, Traits-PeterHugossonMiller.312, TrueType-PeterHugossonMiller.12, VB-Regex-PeterHugossonMiller.32 Fix for Issue 1153 - Many occurrences of "WriteStream on: aCollection" which can be replaced with "aCollection writeStream" -- Cheers, Peter

Sept. 4, 2009

[Pharo-project] dnu - isScarySelector not found

by Carlos Crosetti

Hi, On any existing subclass of Object, I add a class method, I add "testSelector" Got MNU Metaclass(class) dnu isScarySelector OBMethodDefinition>>confirmMethod: What is wrong? Regards, Carlos

Sept. 4, 2009

Re: [Pharo-project] Added package KernelTests-PeterHugossonMiller.145.mcz

by Peter Hugosson-Miller

On Fri, Sep 4, 2009 at 2:14 AM, Peter Hugosson-Miller <oldmanlink(a)gmail.com>wrote: > Name: KernelTests-PeterHugossonMiller.145 > Author: PeterHugossonMiller > Time: 4 September 2009, 2:11:41 am > UUID: 1bab2752-fa51-48ab-a64d-569f6ceda5bd > Ancestors: KernelTests-PeterHugossonMiller.144 > > Fix for Issue 1150 - Incorrect test that was meant to test > Duration>>#storeOn: actually tested #printOn: instead > > -- > Cheers, > Peter > Link to the issue: http://code.google.com/p/pharo/issues/detail?id=1150

Sept. 4, 2009

Re: [Pharo-project] Added package Network-MIME-PeterHugossonMiller.11.mcz

by Peter Hugosson-Miller

On Fri, Sep 4, 2009 at 2:31 AM, Peter Hugosson-Miller <oldmanlink(a)gmail.com>wrote: > Name: Network-MIME-PeterHugossonMiller.11 > Author: PeterHugossonMiller > Time: 4 September 2009, 2:31:05 am > UUID: c3fc2fdc-5305-46e7-bc4e-189647fe2261 > Ancestors: Network-MIME-PeterHugossonMiller.10 > > Fix for Issue 1151 - broken method RFC2047MimeConverter>>#readWord > > -- > Cheers, > Peter > Oops, forgot link to the issue: http://code.google.com/p/pharo/issues/detail?id=1151

Sept. 4, 2009

[Pharo-project] Added package Network-Protocols-PeterHugossonMiller.14.mcz

by Peter Hugosson-Miller

Name: Network-Protocols-PeterHugossonMiller.14 Author: PeterHugossonMiller Time: 4 September 2009, 2:39:49 am UUID: 4b7c90af-93e4-420d-bbad-1022646f967c Ancestors: Network-Protocols-PeterHugossonMiller.13 Fix for Issue 1152 - HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading http://code.google.com/p/pharo/issues/detail?id=1152 -- Cheers, Peter

Sept. 4, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

Ok. Please note that your package system and limits it imposes might affect "market share". Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller Sent: Thursday, September 03, 2009 7:00 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 2009/9/4 Michael van der Gulik <mikevdg(a)gmail.com<mailto:mikevdg@gmail.com>> Argh. Please reply below other people's emails. Bill ________________________________ 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<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<mailto:Pharo-project@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. 2009/9/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@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/ _______________________________________________ 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 Michael, This is one of those cases that really makes me miss ENVY, and its Class extentions. Under that system you would avoid the problem completely, by extending the Collection class in the Stream package and adding the methods that depend on Streams in that package. I guess everyone knows what ENVY Class extensions are, but just in case someone doesn't, they are basically collections of methods to be added to a Class already in the image (i.e. not subclasses), when the extension is loaded. -- Cheers, Peter

Sept. 4, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

I'd love to - how do you get LookOut! 2003 to comment text? It amazes me that people who write software for a living don't grok the need for that ability, but I've been saddled with this piece of junk, and the piece of junk before it, that appear to be unable to do it. ________________________________ 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 6:51 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Argh. Please reply below other people's emails. Bill ________________________________ 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<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<mailto:Pharo-project@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. 2009/9/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@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. 4, 2009

[Pharo-project] Added package Network-MIME-PeterHugossonMiller.11.mcz

by Peter Hugosson-Miller

Name: Network-MIME-PeterHugossonMiller.11 Author: PeterHugossonMiller Time: 4 September 2009, 2:31:05 am UUID: c3fc2fdc-5305-46e7-bc4e-189647fe2261 Ancestors: Network-MIME-PeterHugossonMiller.10 Fix for Issue 1151 - broken method RFC2047MimeConverter>>#readWord -- Cheers, Peter

Sept. 4, 2009