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

[Pharo-project] What Collection is suitable for binary stream
by Andrey Larionov Oct. 2, 2009

Oct. 2, 2009

I'm a novice for Smalltalk. Can any body suggest proper collection for binary stream. I try ByteArray - it dosn't allow Characters, try ByteString - it not allow non literals. Which collection (or maybe pattern) should be used to write binary and character data?

2 1

[Pharo-project] [update] #10465
by Marcus Denker Oct. 2, 2009

Oct. 2, 2009

10465 ----- Issue 1203: ThreadSafeTranscript(Object)>>doesNotUnderstand: #print: Issue 773: Comment and category in Utilities class>>addUpdateServer: Issue 1259: ProcessorScheduler>>selfEvaluating -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

1 0

[Pharo-project] PositionableStream and uintXXX
by Andrey Larionov Oct. 2, 2009

Oct. 2, 2009

I'm try to launch FastCGI for Seaside. And there is a question. >From socket stream reads some byte sequence which wraped by ReadStream on which reading operations is continued. In some place called unit24 message, which sends bitShift: message. But from stream returned not an Integer but Character, which dosnt have an bitShift: method. What i'm missed? is there should be special calls to made stream binary?

2 2

[Pharo-project] better error handling
by Mariano Martinez Peck Oct. 2, 2009

Oct. 2, 2009

Hi folks: First of all I have to say I am pretty sad that error handling hasn't a special place in the PBE. In my opinion having a good error handling is a MUST in every piece of code. We need to use exceptions. I didn't collaborate at all with PBE so I cannot say anything to no one :) I will try to write something for the next version if you want. But first... We need a better error handling. It is very common to have a hierarchy of exceptions or errors. You have subclasses of Error for example. And many times, you want to do or not to do or even do something different depending on the error you got. Now, the question is, how you do this in Squeak ??? This is the only (ugly) way I find to do it: [ a block of code where you do something that can singal different exceptions ] on: XXXErrror do: [ : ex | ex class = XXXError if True: [ 'I do what I need to do when I get the error XXX' ]. ex class = YYYError if True: [ 'I do what I need to do when I get the error YYY' ]. 'here I do in the rest of the cases' ] But, I would like to have something like this: [ a block of code where you do something that can singal different exceptions ] on: XXXError do: [ : ex | 'I do what I need to do when I get the error XXX' ] on: YYYError do: [ : ex | 'I do what I need to do when I get the error YYY' ] on: Error do: [ : ex | 'here I do in the rest of the cases' ] ensure: [ 'Here I do what I always need to do, no matter if there is an error or not' ] What do you think about this? does someone ever did something like this ? perhaps we can put this as part of 1.1 I listen opinions. Best, Mariano

7 9

[Pharo-project] generic completion
by Tudor Girba Oct. 2, 2009

Oct. 2, 2009

Hi, I would need a generic completion mechanism that can be used for any text and that I can configure. I took a brief look at the EC model, but it looks like it is geared towards code. Does anyone have an example for using EC, or similar, to handle generic completion? Cheers, Doru -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

2 1

[Pharo-project] New inspector
by Schwab,Wilhelm K Oct. 2, 2009

Oct. 2, 2009

Hello all, I would rather not have to rain on the parade, but how do I disable the new inspector? Bill

2 2

[Pharo-project] test pragmas
by Tudor Girba Oct. 1, 2009

Oct. 1, 2009

Hi, How can I mark a test as being an expected failure? Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

5 5

[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
by StÃ©phane Ducasse Oct. 1, 2009

Oct. 1, 2009

I agree with andreas point. :) Begin forwarded message: > From: codesite-noreply(a)google.com > Date: September 29, 2009 6:31:41 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Issue 1129 in pharo: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > > > Comment #22 on issue 1129 by andreas.raab: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > http://code.google.com/p/pharo/issues/detail?id=1129 > > I'll give it one last shot: From my perspective, the problem is not > how difficult it > is to fix it, the problem is that there is a change in semantics of > a widely deployed > method that affects every single place that uses it. I could follow > your reasoning > more easily if the situation where such that for 80% of the users > everything stays > the same but the change you are proposing necessitates that every > single place that > uses these methods needs to be changed. And not being able to tell > whether a > particular place has been fixed or not is just bad engineering since > you are making > it strictly harder for your users to determine whether they still > need to do > something for addressing this issue or not. That's what deprecations > are for - > telling users that there is something they need to take care of. > > I think that the change you are proposing is a decidedly bad choice > and urge you to > reconsider for the following reasons: > > 1) It is subtle breakage that creates a major and completely > unnecessary PITA for > anyone who needs to write UIManager code that works across Pharo, > Squeak, Croquet etc. > > 2) It weakens the framework. Toolbuilder is based on having the same > semantics across > platforms and UIs and this change means that the entire family of > input requests is > no longer reliable as it will behave differently between Pharo and > anything else in > existence. > > 3) The alternatives are every bit as good. The protocol complication > of using > onCancel: are minimal to non-existent (since in many cases the > ability to provide a > cancel action is what you'll want anyway) and even if that were the > case, a new > protocol that over time can be supported by other UIs would solve > that completely and > in a proper evolutionary way. > > 4) With the choice you've made, you need to touch every user of that > method anyway. > If that's true, there is no penalty for changing the protocol and it > will make > migration easier since you can simply browse for all senders of > #request: and find > those that haven't been converted yet. > > Please do consider these issues carefully. I really don't think > there is any > advantage for you or your users by introducing such a subtle breakage. > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

5 8

[Pharo-project] Pharo ESUG Video
by Torsten Bergmann Oct. 1, 2009

Oct. 1, 2009

http://mimer.msc.se/esug/M2U00055.mp4 includes Stef's presentation on Pharo from ESUG. Anyone able to link it on the webpage. Thx T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

4 5

[Pharo-project] Question about FFI and constants
by Mariano Martinez Peck Oct. 1, 2009

Oct. 1, 2009

Hi folks: I am calling to the OpenDBX library and this library uses C constants. Suppose something like this: enum odbxerr { ODBX_ERR_SUCCESS, #define ODBX_ERR_SUCCESS ODBX_ERR_SUCCESS ODBX_ERR_BACKEND, #define ODBX_ERR_BACKEND ODBX_ERR_BACKEND ODBX_ERR_NOCAP, #define ODBX_ERR_NOCAP ODBX_ERR_NOCAP ODBX_ERR_PARAM, ......... Then I have a function like this: char* odbx_error( odbx_t* handle, int error ) In that case the int error es the index of the array or I can use the constant. Right now, I am using int from 0 to N. But I would like to invoke calls to that function using Smalltalk Strings that represent C constants. For example, now I have this: OpenDBXUnix>>apiError: handle number: err "long odbx_error(odbx_t*, int)" <cdecl: char* 'odbx_error' (ulong long) module: 'opendbx' > ^self externalCallFailed And I call them this way for example: OpenDBXUnix apiError: handle number: 1. But, I would love to do: OpenDBXUnix apiError: handle number: 'ODBX_ERR_BACKEND'. Of course this fails because it cannot coerce and String to a long. So, that someone know how can I do this (if I can) ? Thanks Mariano

3 2