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

Re: [Pharo-project] ProfStef -> latex files?

by laurent laffont

On Thu, Sep 16, 2010 at 9:43 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi! > > There has been an effort to produce latex files from a profstef help? > Never heard about such effort. I've generated a slideshow from it here: http://seaslides.seasidehosting.st/ (works on chrome or safari) and I want to also have a printable document for my course. So I may be interested in latex export too. Laurent > > cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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

Levente, Wasn't it obvious that I thought I found a bug? And yes, there are very long standing "features" that have not been fixed, so it is hardly unprecedented, especially when failure to raise an exception is involved. The Squeak community clearly prefers "fail and ignore" to raising exceptions; they don't see them as defects. Streams and the file system are littered with such problems. The result is a lot of time wasted hunting down things that could have been obvious. However it is of course possible that it could be as you describe, or it could be a common trap. That's why I posted a quick "have you ever seen this behavior?" question to be followed by what you want unless an explanation arises. Not long ago, FFI was raising exceptions indicating that a parameter could not be coerced (or similar language) when the problem was in fact that I was using invalid parameter types in the call sequence. IIRC, Andreas agreed and fixed it, but "lots of FFI users" had apparently not said anything. Absent an explanation of how it would be be problematic, yes, it seems to me that either both byte objects should produce the same behavior, or one of them should raise an exception. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Thursday, September 16, 2010 5:57 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another silent failure? On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > FFI, Linux. The point is that the code fails silently when given a string and performs as expected when given a byte array. That is all the more unusual given that the pointer is typed as char* (if anything, I would expect the string to succeed). Just a hunch at this point, it sure looks like something that goes wrong "down in the depths" and it does nothing rather than reporting an error. My question should have been clear (Guillermo obviously got it): does anyone else consider that combination of behaviors to be a problem? Silent failures are the order of the day in Squeak; I hope we will eliminate them in Pharo. So you think that you've found a bug in FFI, but instead of sharing more information about the problem or reporting the bug to the developers, you're blaming FFI and Squeak. There are lots of FFI users who pass Strings to functions which expect char*, and works for them. So, I'm pretty sure that if it's really a bug, then it's specific to the library/VM combination you're trying to use. Levente > > Yes, I can package and release the code. Whether that will take the form of a quick example of what I suspect is a long-standing defect in FFI or a nice wrapper around PLplot will depend on how PLplot performs. > > Windows device contexts are proving difficult to replace. Otherwise, Microsoft can keep the OS. > > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 15, 2010 10:01 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another silent failure? > > On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote: > >> I am interested in the opinions of helpful people who might have something constructive to add. > > Sorry, but don't expect any help with this attitude. Even the most helpful > people - like Henrik - can't help you, because you don't give enough > information about your problem. > > Which platform do you use? > Which VM/image do you use? > What's the library you'd like to use? > Is #cPlgver: an FFI call or do you use Alien? Maybe something else? > What's the type of the argument it expects? > If it calls a library function, does it store the pointer you're passing > to it? > Can you share your code? > > > Levente > >> >> >> >> ________________________________________ >> 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 >> >> _______________________________________________ >> 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. 16, 2010

Re: [Pharo-project] Another silent failure?

by Levente Uzonyi

On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > FFI, Linux. The point is that the code fails silently when given a string and performs as expected when given a byte array. That is all the more unusual given that the pointer is typed as char* (if anything, I would expect the string to succeed). Just a hunch at this point, it sure looks like something that goes wrong "down in the depths" and it does nothing rather than reporting an error. My question should have been clear (Guillermo obviously got it): does anyone else consider that combination of behaviors to be a problem? Silent failures are the order of the day in Squeak; I hope we will eliminate them in Pharo. So you think that you've found a bug in FFI, but instead of sharing more information about the problem or reporting the bug to the developers, you're blaming FFI and Squeak. There are lots of FFI users who pass Strings to functions which expect char*, and works for them. So, I'm pretty sure that if it's really a bug, then it's specific to the library/VM combination you're trying to use. Levente > > Yes, I can package and release the code. Whether that will take the form of a quick example of what I suspect is a long-standing defect in FFI or a nice wrapper around PLplot will depend on how PLplot performs. > > Windows device contexts are proving difficult to replace. Otherwise, Microsoft can keep the OS. > > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 15, 2010 10:01 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another silent failure? > > On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote: > >> I am interested in the opinions of helpful people who might have something constructive to add. > > Sorry, but don't expect any help with this attitude. Even the most helpful > people - like Henrik - can't help you, because you don't give enough > information about your problem. > > Which platform do you use? > Which VM/image do you use? > What's the library you'd like to use? > Is #cPlgver: an FFI call or do you use Alien? Maybe something else? > What's the type of the argument it expects? > If it calls a library function, does it store the pointer you're passing > to it? > Can you share your code? > > > Levente > >> >> >> >> ________________________________________ >> 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 >> >> _______________________________________________ >> 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. 16, 2010

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

by Mariano Martinez Peck

Hi. I don't like to loose my time of ESUG answering/reading emails, but a summary was that we can implement something like #latestVersion or #lastVersion but called #stableVersion which could be something like this: ConfigurationOfXXX >> stableVersion for: #pharo10 do: [ ^ self version: '1.35.5' ] for: #pharo11 do: [ ^ self version: '3.23' ] for: #pharo12 do: [ self error: 'Not yet supported' ] Then the user can do something like: ConfigurationOfXXX project stableVersion load. And Metacello will load the stable version for the current Pharo version you are running in. And he will apply and use probably the same for the different Gemstone versions. In addition, even if not needed, we could commit this confs (with this new #stableVersion) into the 3 different MetacelloPharo repositories. With this, it is easier to know which confs work for each pharo versions. Finally, we thought I could do a test of implementing all those #stable methods in all the confs of the PharoDev and try to recreate a Pharo1.0 dev and a Pharo 1.1 dev, using the correct core but using this "stable" version and see if it works. Cheeers Mariano On Thu, Sep 16, 2010 at 11:38 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > We got a discussion with dale/simon/mariano and I'm sure that dale will > reply. > > Stef > > On Sep 15, 2010, at 4:36 PM, Miguel Enrique CobÃ¡ MartÃnez wrote: > > > 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 > > > > > > _______________________________________________ > > 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. 16, 2010

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

by StÃ©phane Ducasse

We got a discussion with dale/simon/mariano and I'm sure that dale will reply. Stef On Sep 15, 2010, at 4:36 PM, Miguel Enrique CobÃ¡ MartÃnez wrote: > 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 > > > _______________________________________________ > 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

[Pharo-project] ESUG 2010 Tech Awards Results

by Noury Bouraqadi

Hi, Monday evening we had demos of participants. It was great and we had hard time voting. Yesterday evening we had the awards ceremony. And the winners are... -1st Physical Etoys (Squeak Etoys) â¢ Developers: Lic. Gonzalo Zabala, Ricardo Moran, SebastiÃ¡n Blanco â¢ Keywords: Visual programming, Programming Real world objects -2nd Cog (Squeak, Pharo) â¢ Developers: Eliot Miranda â¢ Keywords: Virtual machine -3rd Mars (Pharo) â¢ Developers: Esteban Lorenzano â¢ Keywords: MVC framework, native UI, OSX Videos and more info about participants and winners are on: http://www.esug.org/wiki/pier/Conferences/2010/InnovationTechnologyAwards Thanx to all participants and congratulations to the winners! Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010

Sept. 16, 2010

[Pharo-project] ProfStef -> latex files?

by Alexandre Bergel

Hi! There has been an effort to produce latex files from a profstef help? cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2010

[Pharo-project] Implicit conversions ?

by Sven Van Caekenberghe

Why is that the following 2 expressions work #(1 2 3 4 5 6) asByteArray replaceFrom: 1 to: 3 with: 'abc'. 'abcdef' replaceFrom: 1 to: 3 with: #(70 71 72) asByteArray. while the next 2 don't (#(70 71 72) asByteArray) at: 1 put: $a; yourself. 'abcdef' at: 1 put: 75; yourself. and there exists 'abcdef' byteAt: 1 put: 75; yourself. but there is no (#(70 71 72) asByteArray) charAt: 1 put: $a; yourself. Is the implicit conversion in #replaceFrom:to:with: by design ? And why is there no equivalent single operation ? Sven PS: I ran into this trying to deal with the concept of a 'bivalent' stream, one that can be read/written both byte and char based, some streams like SocketStream support this a little bit, but not really.

Sept. 16, 2010

Re: [Pharo-project] Another silent failure?

by Schwab,Wilhelm K

Levente, FFI, Linux. The point is that the code fails silently when given a string and performs as expected when given a byte array. That is all the more unusual given that the pointer is typed as char* (if anything, I would expect the string to succeed). Just a hunch at this point, it sure looks like something that goes wrong "down in the depths" and it does nothing rather than reporting an error. My question should have been clear (Guillermo obviously got it): does anyone else consider that combination of behaviors to be a problem? Silent failures are the order of the day in Squeak; I hope we will eliminate them in Pharo. Yes, I can package and release the code. Whether that will take the form of a quick example of what I suspect is a long-standing defect in FFI or a nice wrapper around PLplot will depend on how PLplot performs. Windows device contexts are proving difficult to replace. Otherwise, Microsoft can keep the OS. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Wednesday, September 15, 2010 10:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another silent failure? On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote: > I am interested in the opinions of helpful people who might have something constructive to add. Sorry, but don't expect any help with this attitude. Even the most helpful people - like Henrik - can't help you, because you don't give enough information about your problem. Which platform do you use? Which VM/image do you use? What's the library you'd like to use? Is #cPlgver: an FFI call or do you use Alien? Maybe something else? What's the type of the argument it expects? If it calls a library function, does it store the pointer you're passing to it? Can you share your code? Levente > > > > ________________________________________ > 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 > > _______________________________________________ > 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. 16, 2010

Re: [Pharo-project] Another silent failure?

by Levente Uzonyi

On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote: > I am interested in the opinions of helpful people who might have something constructive to add. Sorry, but don't expect any help with this attitude. Even the most helpful people - like Henrik - can't help you, because you don't give enough information about your problem. Which platform do you use? Which VM/image do you use? What's the library you'd like to use? Is #cPlgver: an FFI call or do you use Alien? Maybe something else? What's the type of the argument it expects? If it calls a library function, does it store the pointer you're passing to it? Can you share your code? Levente > > > > ________________________________________ > 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 > > _______________________________________________ > 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