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

Re: [Pharo-project] Another silent failure?

by Schwab,Wilhelm K

Guillermo, I too was taught (more by life than formal education) that things should clearly succeed or fail, but that's not what is happening here, unless I am missing something really obvious. Thanks! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Wednesday, September 15, 2010 9:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another silent failure? On Wed, Sep 15, 2010 at 3:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I am playing with a new library and for kicks thought I would call its get-version function: | buffer | buffer := String new:80. PLplotLibrary default cPlgver:buffer. buffer. The above appears to do nothing; the buffer remains blank, and there is no error raised from it. I tried something more complicated involving external address and #alloc: and got the version number. That is encouraging from a perspective of talking to the library, but then I had to square the above failure with my use of memcpy() not long ago (different topic). In that case, I had real need to allocate a buffer in a fixed heap, but was told that I could ultimately copy from said buffer (which lives across multiple gcs and would move) into a ByteArray of the needed size, which would not move during the memcpy() call. That worked. So I tried | buffer | buffer := ByteArray new:80. PLplotLibrary default cPlgver:buffer. buffer asString. and get the version number. What's up? Why is it ok to pass a byte array but not a string? If there really is a difference, there should be an exception hinting that something is wrong and what it might be - right? I was taught that when objects can't answer a message the right way, they should raise an exception :). BTW, I don't know the difference between ByteArray and String... so I have to do some research :) 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

Sept. 16, 2010

Re: [Pharo-project] Another silent failure?

by Guillermo Polito

On Wed, Sep 15, 2010 at 3:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I am playing with a new library and for kicks thought I would call its > get-version function: > > | buffer | > buffer := String new:80. > PLplotLibrary default cPlgver:buffer. > buffer. > > The above appears to do nothing; the buffer remains blank, and there is no > error raised from it. I tried something more complicated involving external > address and #alloc: and got the version number. That is encouraging from a > perspective of talking to the library, but then I had to square the above > failure with my use of memcpy() not long ago (different topic). In that > case, I had real need to allocate a buffer in a fixed heap, but was told > that I could ultimately copy from said buffer (which lives across multiple > gcs and would move) into a ByteArray of the needed size, which would not > move during the memcpy() call. That worked. So I tried > > | buffer | > buffer := ByteArray new:80. > PLplotLibrary default cPlgver:buffer. > buffer asString. > > and get the version number. What's up? Why is it ok to pass a byte array > but not a string? If there really is a difference, there should be an > exception hinting that something is wrong and what it might be - right? > I was taught that when objects can't answer a message the right way, they should raise an exception :). BTW, I don't know the difference between ByteArray and String... so I have to do some research :) > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2010

Re: [Pharo-project] Another silent failure?

by Schwab,Wilhelm K

I am interested in the opinions of helpful people who might have something constructive to add. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] Sent: Wednesday, September 15, 2010 6:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another silent failure? How do you expect us to help you debug this? Really? Cheers, Henry On Sep 15, 2010, at 8:45 38PM, Schwab,Wilhelm K wrote: > I am playing with a new library and for kicks thought I would call its get-version function: > > | buffer | > buffer := String new:80. > PLplotLibrary default cPlgver:buffer. > buffer. > > The above appears to do nothing; the buffer remains blank, and there is no error raised from it. I tried something more complicated involving external address and #alloc: and got the version number. That is encouraging from a perspective of talking to the library, but then I had to square the above failure with my use of memcpy() not long ago (different topic). In that case, I had real need to allocate a buffer in a fixed heap, but was told that I could ultimately copy from said buffer (which lives across multiple gcs and would move) into a ByteArray of the needed size, which would not move during the memcpy() call. That worked. So I tried > > | buffer | > buffer := ByteArray new:80. > PLplotLibrary default cPlgver:buffer. > buffer asString. > > and get the version number. What's up? Why is it ok to pass a byte array but not a string? If there really is a difference, there should be an exception hinting that something is wrong and what it might be - right? > > 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. 15, 2010

Re: [Pharo-project] Another silent failure?

by Henrik Johansen

How do you expect us to help you debug this? Really? Cheers, Henry On Sep 15, 2010, at 8:45 38PM, Schwab,Wilhelm K wrote: > I am playing with a new library and for kicks thought I would call its get-version function: > > | buffer | > buffer := String new:80. > PLplotLibrary default cPlgver:buffer. > buffer. > > The above appears to do nothing; the buffer remains blank, and there is no error raised from it. I tried something more complicated involving external address and #alloc: and got the version number. That is encouraging from a perspective of talking to the library, but then I had to square the above failure with my use of memcpy() not long ago (different topic). In that case, I had real need to allocate a buffer in a fixed heap, but was told that I could ultimately copy from said buffer (which lives across multiple gcs and would move) into a ByteArray of the needed size, which would not move during the memcpy() call. That worked. So I tried > > | buffer | > buffer := ByteArray new:80. > PLplotLibrary default cPlgver:buffer. > buffer asString. > > and get the version number. What's up? Why is it ok to pass a byte array but not a string? If there really is a difference, there should be an exception hinting that something is wrong and what it might be - right? > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2010

Re: [Pharo-project] [squeak-dev] RFB Server not working on Squeak 4.1?

by Lawson English

On 9/15/10 2:32 PM, Levente Uzonyi wrote: > On Wed, 15 Sep 2010, Lawson English wrote: > >> Someone pointed out to me a workaround for this issue. Apparently the >> only way any client (including the Squeak RFBClient) will work with >> the RFBServer in Squeak 4.1 is if you set the client to only accept >> rawEncoding. > > ZRLE works fine, but you have to enable it on the server and set your > client's encoding to ZRLE only. > > > Levente > > Thanks. A change in behavior I didn't know how to cope with (until now). Lawson

Sept. 15, 2010

Re: [Pharo-project] [squeak-dev] RFB Server not working on Squeak 4.1?

by Levente Uzonyi

On Wed, 15 Sep 2010, Lawson English wrote: > Someone pointed out to me a workaround for this issue. Apparently the only > way any client (including the Squeak RFBClient) will work with the RFBServer > in Squeak 4.1 is if you set the client to only accept rawEncoding. ZRLE works fine, but you have to enable it on the server and set your client's encoding to ZRLE only. Levente > > Works fine at that point, but is likely a bit slower than it could be. > > Thanks to all that responded. > > > Lawson > > On 9/8/10 7:30 AM, Lawson English wrote: >> Has anyone tested the RFB server class in Squeak 4.1? I can't get it to >> work in Mac OS X 10.6 or in at least variant of Linux. >> Haven't tested it in Pharo. >> >> Lawson >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 15, 2010

Re: [Pharo-project] [squeak-dev] RFB Server not working on Squeak 4.1?

by Lawson English

Someone pointed out to me a workaround for this issue. Apparently the only way any client (including the Squeak RFBClient) will work with the RFBServer in Squeak 4.1 is if you set the client to only accept rawEncoding. Works fine at that point, but is likely a bit slower than it could be. Thanks to all that responded. Lawson On 9/8/10 7:30 AM, Lawson English wrote: > Has anyone tested the RFB server class in Squeak 4.1? I can't get it > to work in Mac OS X 10.6 or in at least variant of Linux. > Haven't tested it in Pharo. > > Lawson > >

Sept. 15, 2010

[Pharo-project] Another silent failure?

by Schwab,Wilhelm K

I am playing with a new library and for kicks thought I would call its get-version function: | buffer | buffer := String new:80. PLplotLibrary default cPlgver:buffer. buffer. The above appears to do nothing; the buffer remains blank, and there is no error raised from it. I tried something more complicated involving external address and #alloc: and got the version number. That is encouraging from a perspective of talking to the library, but then I had to square the above failure with my use of memcpy() not long ago (different topic). In that case, I had real need to allocate a buffer in a fixed heap, but was told that I could ultimately copy from said buffer (which lives across multiple gcs and would move) into a ByteArray of the needed size, which would not move during the memcpy() call. That worked. So I tried | buffer | buffer := ByteArray new:80. PLplotLibrary default cPlgver:buffer. buffer asString. and get the version number. What's up? Why is it ok to pass a byte array but not a string? If there really is a difference, there should be an exception hinting that something is wrong and what it might be - right? Bill

Sept. 15, 2010

Re: [Pharo-project] Metacello repositories in the future

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 15-09-2010 a las 15:52 +0200, Torsten Bergmann escribiÃ³: > One thing I think that should be discussed at ESUG > (sorry I'm not there) is if and how we want to maintain > Metacello repositories for the different Pharo versions > in the future. > > I still think about the project/repo dependency issue: > > An example: we have a repo for Pharo 1.2: > > MetaRepoForPharo12 it may contain a ConfigurationOfFFI that works > for Pharo 1.1. and loads FFI. > it may also contain a ConfigurationOfExternalBrowser > that requires the ConfigurationOfFFI (usual Metacello project > dependency) > > When Pharo 1.3 comes out we have a new MetaRepoForPharo13 and may just > copy ConfigurationOfFFI over since it only loads packages and these packages > may be compatible to Pharo 1.3. So far so good ... but: > > What about ConfigurationOfExternalBrowser, if we just copy it to the > new repo the config still points to the "old" ConfigurationOfFFI in the old MetaRepoForPharo12 repo and not to the new one in MetaRepoForPharo13. > > So we will have to adopt the configs for any new platform version ... > and since world keeps spinnning we may also end up with forked configurations. Yes, that is expected. Mariano proposed some script that programmatically rewrites a configuration fixin and repointing dependencies to the new repository. This could be triggered when creating a new Repo and when automatically copying every configuration from the previous repo to the new repo. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 15, 2010

[Pharo-project] Metacello repositories in the future

by Torsten Bergmann

One thing I think that should be discussed at ESUG (sorry I'm not there) is if and how we want to maintain Metacello repositories for the different Pharo versions in the future. I still think about the project/repo dependency issue: An example: we have a repo for Pharo 1.2: MetaRepoForPharo12 it may contain a ConfigurationOfFFI that works for Pharo 1.1. and loads FFI. it may also contain a ConfigurationOfExternalBrowser that requires the ConfigurationOfFFI (usual Metacello project dependency) When Pharo 1.3 comes out we have a new MetaRepoForPharo13 and may just copy ConfigurationOfFFI over since it only loads packages and these packages may be compatible to Pharo 1.3. So far so good ... but: What about ConfigurationOfExternalBrowser, if we just copy it to the new repo the config still points to the "old" ConfigurationOfFFI in the old MetaRepoForPharo12 repo and not to the new one in MetaRepoForPharo13. So we will have to adopt the configs for any new platform version ... and since world keeps spinnning we may also end up with forked configurations. Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl

Sept. 15, 2010