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

Re: [Pharo-project] Some bugs

by Nicolas Cellier

2011/9/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > BTW mike roberts is building a tool to be able to understand and fix the code range of the debugger hilighting. > Probably your bug is also related to the closure introduction. > > Now the abstraction used is so low level that this is a pain and fragile. > Ideally using an AST would be much better but this is for the future. > > Stef > Stef, If you are saying that implementation is not crystal clear, I can only agree with you. Eliot did avoid a full rewrite (I guess he took the shortest path to make the available implementation work with closures), and this design decision can be questioned indeed. But speaking of abstraction level by itself, I don't understand your sentence. To me, the abstraction is at the correct level. The Debugger has to map the low level execution machinery (Context/program counter/CompiledMethod/byteCodes) to high level specification visible to the user (source code). The Debugger does so by mapping bytecodes to source ranges via AST, no more, no less. In case of inlined blocks, there are more instructions on the bytecode side than messages sent on the AST side, just to make the problem a bit more complex, so maybe there are more intelligent way to address the mapping problem (maybe you mean via an intermediate transformation of AST), but you'll have to explain this a bit deeper. Nicolas > > On Sep 5, 2011, at 9:07 AM, Andrea BrÃ¼hlmann wrote: > >> Hello Stef, >> >> I appreciate the work of the pharo community! We will continue reporting bugs and submit fixes that >> we made. Of course I do not expect anyone to fix all reported bugs, but there are issues like 4694 >> (debugger) where we really need your help. Other issues like the buggy code completion can be >> workarounded by me by disabling code completion ;-) >> >> So thanks for the welcome and I am looking forward to having 4694 fixed! >> >> Andrea >> >> >> >> >> StÃ©phane Ducasse schrieb: >>> Thanks andrea >>> Welcome to the pharo mailing-list and community. Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine) that you should also contribute. Bug reporting is already a contribution. Â Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that). I also understand that people can get frustrated by changes but what can we do? >>> May be people can gather and check the fixes that are important to fix but we do not have the force to maintain. >>> Imagine well that we have one engineer full time since 8 months. Stef >>> On Aug 23, 2011, at 8:54 AM, Andrea BrÃ¼hlmann wrote: >>>> Hello, >>>> >>>> I reported some bugs on the issue tracker and hope you can help me with them! >>>> >>>> >>>> 4681: Accepting with the enter key does not work >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4681 >>>> >>>> 4682: Code completion makes strange cursor placements and too many spaces >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4682 >>>> >>>> 4683: Code completion breaks some search fields (errors during typing) >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4683 >>>> >>>> 4684: Missing ctrl+w (methodNamesContainingIt:) >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4684 >>>> >>>> 4685: Merge dialog: cannot resolve conflict with removed method >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4685 >>>> >>>> 4686: Method category change creates no new version >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4686 >>>> >>>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil) >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4687 >>>> >>>> 4688: Progress bar disappears on image save >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4688 >>>> >>>> 4689: MessageTally bug >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4689 >>>> >>>> 4690: Progress bar position >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4690 >>>> >>>> 4691: Bad line breaks in code until window is resized (because of bold text?) >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4691 >>>> >>>> 4692: Drop downs should select the default entry (topmost) instead of a middle one >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4692 >>>> >>>> 4693: Line breaks in tooltips are wrong >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4693 >>>> >>>> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+. >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4694 >>>> >>>> 4695: Time asString prints nanos unrounded >>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4695 >>>> >>>> >>>> -- >>>> Andrea BrÃ¼hlmann >>>> >> >> >> -- >> AB Â Â | Â ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER >> Â Â Â | Â NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN >> Â Â Â | Â TEL Â +41 31 356 42 54 Â· FAX Â +41 31 356 42 51 >> Â Â Â | Â WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >> > > >

Sept. 5, 2011

Re: [Pharo-project] Towards better HTTP client usage

by Sven Van Caekenberghe

Johannes, On 05 Sep 2011, at 12:34, Johannes Rasche wrote: > Hi Sven, I'm eagerly looking forward. > > Is this an announcement about what you're actually doing, or is it open for experiments? Both I guess. > Is there already a repository I can load? Yes, just load the latest version of Zn (see http://zn.stfx.eu) > Johannes Thanks for your interest! Sven > Am 04.09.2011 um 20:22 schrieb Sven Van Caekenberghe: > >> Towards better HTTP client usage >> >> At the last Pharo Sprint in Lille (July 8th), StÃ©phane and I were at one point trying to remove some old HTTPSocket usage (which indirectly uses Zn) and replace it with direct and clean Zn usage. We hadn't much time left and didn't get very far. But I realized afterwards that although technically everything was there to write good HTTP client code, it was way too difficult (it required to much code on the user's behalf). >> >> Hence I decided to try write a new client that would support this usage much better and encourage better HTTP client usage in general. Another goal of this new client is to ultimately replace all other clients currently in Zn (these different client are creating some confusion among users). >> >> ZnNeoClient (a temporary name, to be renamed to ZnClient in the future) is a single object with a lot of (convenience) API to build, execute and process HTTP client requests. It is somewhat similar to Gofer like classes. It is also somewhat comparable to ZnHttpClient but it contains even more functionality. >> >> The new tests in ZnNeoClientTests show some of the ways the client can be used. In the current Zn version all ZnClient class functionality as well as all ZnHTTPSocketFacade (and thus HTTPSocket and thus the rest of the image) has already been reimplemented using ZnNeoClient. These are good examples to look at. >> >> At one point I plan to write some proper documentation, when the design settles down a bit, but here are some examples: >> >> The simplest possible usage: >> >> ZnNeoClient new get: 'http://zn.stxfx.eu/zn/small.html'. >> >> This is shorthand for: >> >> ZnNeoClient new >> url: 'http://zn.stxfx.eu/zn/small.html'; >> get. >> >> Which is actually shorthand for: >> >> ZnNeoClient new >> url: 'http://zn.stxfx.eu/zn/small.html'; >> get; >> contents. >> >> If you know upfront that you will do only one request, you can help conserve resources by doing: >> >> ZnNeoClient new >> beOneShot; >> get: 'http://zn.stxfx.eu/zn/small.html'. >> >> Connections are kept open whenever possible unless #beOneShot is chosen. Multiple requests (possibly to the same host) can be issued using the same client instance. At the end, #close should be send to the client, but garbage collection cleans up as well. >> >> Specifying URLs as strings can sometimes be tricky when special characters such as spaces are involved, for this ZnNeoClient has a whole URL and request construction API. Here is an example: >> >> ZnNeoClient new >> http; >> host: 'www.google.com'; >> addPath: 'search'; >> queryAt: 'q' put: 'Pharo Smalltalk'; >> get. >> >> There is also API for specifying headers, forms, multipart uploads and so on. See the unit tests, the ZnClient class side as well as the ZnHTTPSocketFacade for examples. >> >> The result of an HTTP request is an HTTP response, modelled by ZnResponse. Hence, you can ask a client for the last #response, #entity, #contents or test for #isSuccess. >> >> Which brings us to the problem that it is not easy to properly set up and handle the various things that can go wrong. It is here that ZnNeoClient aims to make a big contribution. >> >> Assume the following example: at some URL there is a list of numbers as lines in a text file that we want to download and use. Let's start simple: >> >> ^ ZnNeoClient new >> get: 'http://www.example.com/numbers.txt'. >> >> When all is well, this will return the text file as string. Let's add parsing: >> >> ^ ZnNeoClient new >> contentReader: [ :entity | >> (entity contents lines do: [ :each | >> Integer readFrom: each ifFail: [ nil ] ]) >> select: [ :each | each notNil ] ]; >> get: 'http://www.example.com/numbers.txt'. >> >> This will make sure we get a (possibly empty) list of numbers. The problem is, when number.txt is not found by the server, we don't deal properly with that situation. We can fix that: >> >> ^ ZnNeoClient new >> enforceHttpSuccess: true; >> contentReader: [ :entity | >> (entity contents lines do: [ :each | >> Integer readFrom: each ifFail: [ nil ] ]) >> select: [ :each | each notNil ] ]; >> get: 'http://www.example.com/numbers.txt'. >> >> Now, a non-success code will throw an error. We should also make sure that we do get a text/plain document back, and we want a uniform error handler reaction: >> >> ^ ZnNeoClient new >> enforceHttpSuccess: true; >> enforceAcceptContentType: true; >> accept: ZnMimeType textPlain; >> contentReader: [ :entity | >> (entity contents lines do: [ :each | >> Integer readFrom: each ifFail: [ nil ] ]) >> select: [ :each | each notNil ] ]; >> ifFail: [ :exception | >> self log: exception printString, ' while fetching numbers'. >> ^ #() ]; >> get: 'http://www.example.com/numbers.txt'. >> >> The failBlock will be execute on any exception, including ZnHttpUnsuccessful and ZnUnexpectedContentType. >> >> What about unreliable networking in general: we need a timeout, but better still, we could retry the request once or twice to cover for (possibly transient) networking/server problems. >> >> ^ ZnNeoClient new >> timeout: 15; >> numberOfRetries: 1; >> retryDelay: 2; >> enforceHttpSuccess: true; >> enforceAcceptContentType: true; >> accept: ZnMimeType textPlain; >> contentReader: [ :entity | >> (entity contents lines do: [ :each | >> Integer readFrom: each ifFail: [ nil ] ]) >> select: [ :each | each notNil ] ]; >> ifFail: [ :exception | >> self log: exception printString, ' while fetching numbers'. >> ^ #() ]; >> get: 'http://www.example.com/numbers.txt'. >> >> If anything goes wrong, there will be one retry after a delay of 2 seconds. >> >> Although there are sensible defaults for all options, it will probably make sense to group the options, like this: >> >> ^ ZnNeoClient new >> systemPolicy; >> accept: ZnMimeType textPlain; >> contentReader: [ :entity | >> (entity contents lines do: [ :each | >> Integer readFrom: each ifFail: [ nil ] ]) >> select: [ :each | each notNil ] ]; >> ifFail: [ :exception | >> self log: exception printString, ' while fetching numbers'. >> ^ #() ]; >> get: 'http://www.example.com/numbers.txt'. >> >> Finding the proper defaults and policies will take some trial and error. Another strategy is factory method like ZnClient class>>#client or ZnHTTPSocketFacade class>>#client. >> >> Here is another real-world example, invoking a REST service that returns JSON (you need the JSJsonParser class that comes with Seaside): >> >> ^ ZnNeoClient new >> systemPolicy; >> beOneShot; >> url: 'http://easy.t3-platform.net/rest/geo-ip'; >> queryAt: 'address' put: '81.83.7.35'; >> accept: ZnMimeType applicationJson; >> contentReader: [ :entity | >> (JSJsonParser parse: entity contents) at: #country ]; >> ifFail: [ nil ]; >> get. >> >> Or as a utility method: >> >> XYZUtils class>>#countryForIpAddress: ipAddressString ifFail: failBlock >> ^ ZnNeoClient new >> systemPolicy; >> beOneShot; >> url: 'http://easy.t3-platform.net/rest/geo-ip'; >> queryAt: 'address' put: ipAddressString; >> accept: ZnMimeType applicationJson; >> contentReader: [ :entity | >> (JSJsonParser parse: entity contents) at: #country ]; >> ifFail: failBlock; >> get >> >> That's it for now. There is still some implementation and testing work to be done. As always, all feedback is welcome. >> >> Sven

Sept. 5, 2011

Re: [Pharo-project] about Shout default to shout any text?

by Lukas Renggli

> And what about the Inspector pane which has two text editors ? Typically you have a separate model for each part of the UI. At least OB does it that way. > Only one has to be shouted. So how would you implement #shoutAboutToStyle: > in this case ? The same problem with the standard browser that was broken since the changes: there is a class definition (shouted) and a comment pane (not shouted). Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 5, 2011

Re: [Pharo-project] Towards better HTTP client usage

by Johannes Rasche

Hi Sven, I'm eagerly looking forward. Is this an announcement about what you're actually doing, or is it open for experiments? Is there already a repository I can load? Johannes Am 04.09.2011 um 20:22 schrieb Sven Van Caekenberghe: > Towards better HTTP client usage > > At the last Pharo Sprint in Lille (July 8th), StÃ©phane and I were at one point trying to remove some old HTTPSocket usage (which indirectly uses Zn) and replace it with direct and clean Zn usage. We hadn't much time left and didn't get very far. But I realized afterwards that although technically everything was there to write good HTTP client code, it was way too difficult (it required to much code on the user's behalf). > > Hence I decided to try write a new client that would support this usage much better and encourage better HTTP client usage in general. Another goal of this new client is to ultimately replace all other clients currently in Zn (these different client are creating some confusion among users). > > ZnNeoClient (a temporary name, to be renamed to ZnClient in the future) is a single object with a lot of (convenience) API to build, execute and process HTTP client requests. It is somewhat similar to Gofer like classes. It is also somewhat comparable to ZnHttpClient but it contains even more functionality. > > The new tests in ZnNeoClientTests show some of the ways the client can be used. In the current Zn version all ZnClient class functionality as well as all ZnHTTPSocketFacade (and thus HTTPSocket and thus the rest of the image) has already been reimplemented using ZnNeoClient. These are good examples to look at. > > At one point I plan to write some proper documentation, when the design settles down a bit, but here are some examples: > > The simplest possible usage: > > ZnNeoClient new get: 'http://zn.stxfx.eu/zn/small.html'. > > This is shorthand for: > > ZnNeoClient new > url: 'http://zn.stxfx.eu/zn/small.html'; > get. > > Which is actually shorthand for: > > ZnNeoClient new > url: 'http://zn.stxfx.eu/zn/small.html'; > get; > contents. > > If you know upfront that you will do only one request, you can help conserve resources by doing: > > ZnNeoClient new > beOneShot; > get: 'http://zn.stxfx.eu/zn/small.html'. > > Connections are kept open whenever possible unless #beOneShot is chosen. Multiple requests (possibly to the same host) can be issued using the same client instance. At the end, #close should be send to the client, but garbage collection cleans up as well. > > Specifying URLs as strings can sometimes be tricky when special characters such as spaces are involved, for this ZnNeoClient has a whole URL and request construction API. Here is an example: > > ZnNeoClient new > http; > host: 'www.google.com'; > addPath: 'search'; > queryAt: 'q' put: 'Pharo Smalltalk'; > get. > > There is also API for specifying headers, forms, multipart uploads and so on. See the unit tests, the ZnClient class side as well as the ZnHTTPSocketFacade for examples. > > The result of an HTTP request is an HTTP response, modelled by ZnResponse. Hence, you can ask a client for the last #response, #entity, #contents or test for #isSuccess. > > Which brings us to the problem that it is not easy to properly set up and handle the various things that can go wrong. It is here that ZnNeoClient aims to make a big contribution. > > Assume the following example: at some URL there is a list of numbers as lines in a text file that we want to download and use. Let's start simple: > > ^ ZnNeoClient new > get: 'http://www.example.com/numbers.txt'. > > When all is well, this will return the text file as string. Let's add parsing: > > ^ ZnNeoClient new > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > get: 'http://www.example.com/numbers.txt'. > > This will make sure we get a (possibly empty) list of numbers. The problem is, when number.txt is not found by the server, we don't deal properly with that situation. We can fix that: > > ^ ZnNeoClient new > enforceHttpSuccess: true; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > get: 'http://www.example.com/numbers.txt'. > > Now, a non-success code will throw an error. We should also make sure that we do get a text/plain document back, and we want a uniform error handler reaction: > > ^ ZnNeoClient new > enforceHttpSuccess: true; > enforceAcceptContentType: true; > accept: ZnMimeType textPlain; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > ifFail: [ :exception | > self log: exception printString, ' while fetching numbers'. > ^ #() ]; > get: 'http://www.example.com/numbers.txt'. > > The failBlock will be execute on any exception, including ZnHttpUnsuccessful and ZnUnexpectedContentType. > > What about unreliable networking in general: we need a timeout, but better still, we could retry the request once or twice to cover for (possibly transient) networking/server problems. > > ^ ZnNeoClient new > timeout: 15; > numberOfRetries: 1; > retryDelay: 2; > enforceHttpSuccess: true; > enforceAcceptContentType: true; > accept: ZnMimeType textPlain; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > ifFail: [ :exception | > self log: exception printString, ' while fetching numbers'. > ^ #() ]; > get: 'http://www.example.com/numbers.txt'. > > If anything goes wrong, there will be one retry after a delay of 2 seconds. > > Although there are sensible defaults for all options, it will probably make sense to group the options, like this: > > ^ ZnNeoClient new > systemPolicy; > accept: ZnMimeType textPlain; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > ifFail: [ :exception | > self log: exception printString, ' while fetching numbers'. > ^ #() ]; > get: 'http://www.example.com/numbers.txt'. > > Finding the proper defaults and policies will take some trial and error. Another strategy is factory method like ZnClient class>>#client or ZnHTTPSocketFacade class>>#client. > > Here is another real-world example, invoking a REST service that returns JSON (you need the JSJsonParser class that comes with Seaside): > > ^ ZnNeoClient new > systemPolicy; > beOneShot; > url: 'http://easy.t3-platform.net/rest/geo-ip'; > queryAt: 'address' put: '81.83.7.35'; > accept: ZnMimeType applicationJson; > contentReader: [ :entity | > (JSJsonParser parse: entity contents) at: #country ]; > ifFail: [ nil ]; > get. > > Or as a utility method: > > XYZUtils class>>#countryForIpAddress: ipAddressString ifFail: failBlock > ^ ZnNeoClient new > systemPolicy; > beOneShot; > url: 'http://easy.t3-platform.net/rest/geo-ip'; > queryAt: 'address' put: ipAddressString; > accept: ZnMimeType applicationJson; > contentReader: [ :entity | > (JSJsonParser parse: entity contents) at: #country ]; > ifFail: failBlock; > get > > That's it for now. There is still some implementation and testing work to be done. As always, all feedback is welcome. > > Sven > >

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

BTW mike roberts is building a tool to be able to understand and fix the code range of the debugger hilighting. Probably your bug is also related to the closure introduction. Now the abstraction used is so low level that this is a pain and fragile. Ideally using an AST would be much better but this is for the future. Stef On Sep 5, 2011, at 9:07 AM, Andrea BrÃ¼hlmann wrote: > Hello Stef, > > I appreciate the work of the pharo community! We will continue reporting bugs and submit fixes that > we made. Of course I do not expect anyone to fix all reported bugs, but there are issues like 4694 > (debugger) where we really need your help. Other issues like the buggy code completion can be > workarounded by me by disabling code completion ;-) > > So thanks for the welcome and I am looking forward to having 4694 fixed! > > Andrea > > > > > StÃ©phane Ducasse schrieb: >> Thanks andrea >> Welcome to the pharo mailing-list and community. Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine) that you should also contribute. Bug reporting is already a contribution. Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that). I also understand that people can get frustrated by changes but what can we do? >> May be people can gather and check the fixes that are important to fix but we do not have the force to maintain. >> Imagine well that we have one engineer full time since 8 months. Stef >> On Aug 23, 2011, at 8:54 AM, Andrea BrÃ¼hlmann wrote: >>> Hello, >>> >>> I reported some bugs on the issue tracker and hope you can help me with them! >>> >>> >>> 4681: Accepting with the enter key does not work >>> http://code.google.com/p/pharo/issues/detail?id=4681 >>> >>> 4682: Code completion makes strange cursor placements and too many spaces >>> http://code.google.com/p/pharo/issues/detail?id=4682 >>> >>> 4683: Code completion breaks some search fields (errors during typing) >>> http://code.google.com/p/pharo/issues/detail?id=4683 >>> >>> 4684: Missing ctrl+w (methodNamesContainingIt:) >>> http://code.google.com/p/pharo/issues/detail?id=4684 >>> >>> 4685: Merge dialog: cannot resolve conflict with removed method >>> http://code.google.com/p/pharo/issues/detail?id=4685 >>> >>> 4686: Method category change creates no new version >>> http://code.google.com/p/pharo/issues/detail?id=4686 >>> >>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil) >>> http://code.google.com/p/pharo/issues/detail?id=4687 >>> >>> 4688: Progress bar disappears on image save >>> http://code.google.com/p/pharo/issues/detail?id=4688 >>> >>> 4689: MessageTally bug >>> http://code.google.com/p/pharo/issues/detail?id=4689 >>> >>> 4690: Progress bar position >>> http://code.google.com/p/pharo/issues/detail?id=4690 >>> >>> 4691: Bad line breaks in code until window is resized (because of bold text?) >>> http://code.google.com/p/pharo/issues/detail?id=4691 >>> >>> 4692: Drop downs should select the default entry (topmost) instead of a middle one >>> http://code.google.com/p/pharo/issues/detail?id=4692 >>> >>> 4693: Line breaks in tooltips are wrong >>> http://code.google.com/p/pharo/issues/detail?id=4693 >>> >>> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+. >>> http://code.google.com/p/pharo/issues/detail?id=4694 >>> >>> 4695: Time asString prints nanos unrounded >>> http://code.google.com/p/pharo/issues/detail?id=4695 >>> >>> >>> -- >>> Andrea BrÃ¼hlmann >>> > > > -- > AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER > | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN > | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 > | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >

Sept. 5, 2011

Re: [Pharo-project] Towards better HTTP client usage

by StÃ©phane Ducasse

Thanks for this mail. I loved it. And for a novice like me at the network level, it sounds exciting. Stef On Sep 4, 2011, at 8:22 PM, Sven Van Caekenberghe wrote: > Towards better HTTP client usage > > At the last Pharo Sprint in Lille (July 8th), StÃ©phane and I were at one point trying to remove some old HTTPSocket usage (which indirectly uses Zn) and replace it with direct and clean Zn usage. We hadn't much time left and didn't get very far. But I realized afterwards that although technically everything was there to write good HTTP client code, it was way too difficult (it required to much code on the user's behalf). > > Hence I decided to try write a new client that would support this usage much better and encourage better HTTP client usage in general. Another goal of this new client is to ultimately replace all other clients currently in Zn (these different client are creating some confusion among users). > > ZnNeoClient (a temporary name, to be renamed to ZnClient in the future) is a single object with a lot of (convenience) API to build, execute and process HTTP client requests. It is somewhat similar to Gofer like classes. It is also somewhat comparable to ZnHttpClient but it contains even more functionality. > > The new tests in ZnNeoClientTests show some of the ways the client can be used. In the current Zn version all ZnClient class functionality as well as all ZnHTTPSocketFacade (and thus HTTPSocket and thus the rest of the image) has already been reimplemented using ZnNeoClient. These are good examples to look at. > > At one point I plan to write some proper documentation, when the design settles down a bit, but here are some examples: > > The simplest possible usage: > > ZnNeoClient new get: 'http://zn.stxfx.eu/zn/small.html'. > > This is shorthand for: > > ZnNeoClient new > url: 'http://zn.stxfx.eu/zn/small.html'; > get. > > Which is actually shorthand for: > > ZnNeoClient new > url: 'http://zn.stxfx.eu/zn/small.html'; > get; > contents. > > If you know upfront that you will do only one request, you can help conserve resources by doing: > > ZnNeoClient new > beOneShot; > get: 'http://zn.stxfx.eu/zn/small.html'. > > Connections are kept open whenever possible unless #beOneShot is chosen. Multiple requests (possibly to the same host) can be issued using the same client instance. At the end, #close should be send to the client, but garbage collection cleans up as well. > > Specifying URLs as strings can sometimes be tricky when special characters such as spaces are involved, for this ZnNeoClient has a whole URL and request construction API. Here is an example: > > ZnNeoClient new > http; > host: 'www.google.com'; > addPath: 'search'; > queryAt: 'q' put: 'Pharo Smalltalk'; > get. > > There is also API for specifying headers, forms, multipart uploads and so on. See the unit tests, the ZnClient class side as well as the ZnHTTPSocketFacade for examples. > > The result of an HTTP request is an HTTP response, modelled by ZnResponse. Hence, you can ask a client for the last #response, #entity, #contents or test for #isSuccess. > > Which brings us to the problem that it is not easy to properly set up and handle the various things that can go wrong. It is here that ZnNeoClient aims to make a big contribution. > > Assume the following example: at some URL there is a list of numbers as lines in a text file that we want to download and use. Let's start simple: > > ^ ZnNeoClient new > get: 'http://www.example.com/numbers.txt'. > > When all is well, this will return the text file as string. Let's add parsing: > > ^ ZnNeoClient new > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > get: 'http://www.example.com/numbers.txt'. > > This will make sure we get a (possibly empty) list of numbers. The problem is, when number.txt is not found by the server, we don't deal properly with that situation. We can fix that: > > ^ ZnNeoClient new > enforceHttpSuccess: true; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > get: 'http://www.example.com/numbers.txt'. > > Now, a non-success code will throw an error. We should also make sure that we do get a text/plain document back, and we want a uniform error handler reaction: > > ^ ZnNeoClient new > enforceHttpSuccess: true; > enforceAcceptContentType: true; > accept: ZnMimeType textPlain; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > ifFail: [ :exception | > self log: exception printString, ' while fetching numbers'. > ^ #() ]; > get: 'http://www.example.com/numbers.txt'. > > The failBlock will be execute on any exception, including ZnHttpUnsuccessful and ZnUnexpectedContentType. > > What about unreliable networking in general: we need a timeout, but better still, we could retry the request once or twice to cover for (possibly transient) networking/server problems. > > ^ ZnNeoClient new > timeout: 15; > numberOfRetries: 1; > retryDelay: 2; > enforceHttpSuccess: true; > enforceAcceptContentType: true; > accept: ZnMimeType textPlain; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > ifFail: [ :exception | > self log: exception printString, ' while fetching numbers'. > ^ #() ]; > get: 'http://www.example.com/numbers.txt'. > > If anything goes wrong, there will be one retry after a delay of 2 seconds. > > Although there are sensible defaults for all options, it will probably make sense to group the options, like this: > > ^ ZnNeoClient new > systemPolicy; > accept: ZnMimeType textPlain; > contentReader: [ :entity | > (entity contents lines do: [ :each | > Integer readFrom: each ifFail: [ nil ] ]) > select: [ :each | each notNil ] ]; > ifFail: [ :exception | > self log: exception printString, ' while fetching numbers'. > ^ #() ]; > get: 'http://www.example.com/numbers.txt'. > > Finding the proper defaults and policies will take some trial and error. Another strategy is factory method like ZnClient class>>#client or ZnHTTPSocketFacade class>>#client. > > Here is another real-world example, invoking a REST service that returns JSON (you need the JSJsonParser class that comes with Seaside): > > ^ ZnNeoClient new > systemPolicy; > beOneShot; > url: 'http://easy.t3-platform.net/rest/geo-ip'; > queryAt: 'address' put: '81.83.7.35'; > accept: ZnMimeType applicationJson; > contentReader: [ :entity | > (JSJsonParser parse: entity contents) at: #country ]; > ifFail: [ nil ]; > get. > > Or as a utility method: > > XYZUtils class>>#countryForIpAddress: ipAddressString ifFail: failBlock > ^ ZnNeoClient new > systemPolicy; > beOneShot; > url: 'http://easy.t3-platform.net/rest/geo-ip'; > queryAt: 'address' put: ipAddressString; > accept: ZnMimeType applicationJson; > contentReader: [ :entity | > (JSJsonParser parse: entity contents) at: #country ]; > ifFail: failBlock; > get > > That's it for now. There is still some implementation and testing work to be done. As always, all feedback is welcome. > > Sven > >

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

Thanks for the point. Yes it is important. I will ask igor to have a look in two or three weeks. Stef On Sep 5, 2011, at 9:07 AM, Andrea BrÃ¼hlmann wrote: > Hello Stef, > > I appreciate the work of the pharo community! We will continue reporting bugs and submit fixes that > we made. Of course I do not expect anyone to fix all reported bugs, but there are issues like 4694 > (debugger) where we really need your help. Other issues like the buggy code completion can be > workarounded by me by disabling code completion ;-) > > So thanks for the welcome and I am looking forward to having 4694 fixed! > > Andrea > > > > > StÃ©phane Ducasse schrieb: >> Thanks andrea >> Welcome to the pharo mailing-list and community. Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine) that you should also contribute. Bug reporting is already a contribution. Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that). I also understand that people can get frustrated by changes but what can we do? >> May be people can gather and check the fixes that are important to fix but we do not have the force to maintain. >> Imagine well that we have one engineer full time since 8 months. Stef >> On Aug 23, 2011, at 8:54 AM, Andrea BrÃ¼hlmann wrote: >>> Hello, >>> >>> I reported some bugs on the issue tracker and hope you can help me with them! >>> >>> >>> 4681: Accepting with the enter key does not work >>> http://code.google.com/p/pharo/issues/detail?id=4681 >>> >>> 4682: Code completion makes strange cursor placements and too many spaces >>> http://code.google.com/p/pharo/issues/detail?id=4682 >>> >>> 4683: Code completion breaks some search fields (errors during typing) >>> http://code.google.com/p/pharo/issues/detail?id=4683 >>> >>> 4684: Missing ctrl+w (methodNamesContainingIt:) >>> http://code.google.com/p/pharo/issues/detail?id=4684 >>> >>> 4685: Merge dialog: cannot resolve conflict with removed method >>> http://code.google.com/p/pharo/issues/detail?id=4685 >>> >>> 4686: Method category change creates no new version >>> http://code.google.com/p/pharo/issues/detail?id=4686 >>> >>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil) >>> http://code.google.com/p/pharo/issues/detail?id=4687 >>> >>> 4688: Progress bar disappears on image save >>> http://code.google.com/p/pharo/issues/detail?id=4688 >>> >>> 4689: MessageTally bug >>> http://code.google.com/p/pharo/issues/detail?id=4689 >>> >>> 4690: Progress bar position >>> http://code.google.com/p/pharo/issues/detail?id=4690 >>> >>> 4691: Bad line breaks in code until window is resized (because of bold text?) >>> http://code.google.com/p/pharo/issues/detail?id=4691 >>> >>> 4692: Drop downs should select the default entry (topmost) instead of a middle one >>> http://code.google.com/p/pharo/issues/detail?id=4692 >>> >>> 4693: Line breaks in tooltips are wrong >>> http://code.google.com/p/pharo/issues/detail?id=4693 >>> >>> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+. >>> http://code.google.com/p/pharo/issues/detail?id=4694 >>> >>> 4695: Time asString prints nanos unrounded >>> http://code.google.com/p/pharo/issues/detail?id=4695 >>> >>> >>> -- >>> Andrea BrÃ¼hlmann >>> > > > -- > AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER > | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN > | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 > | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >

Sept. 5, 2011

Re: [Pharo-project] about Shout default to shout any text?

by Alain Plantec

Hi Lukas, I've no problem at all with the view creation. Indeed, the view creation is clean. Now, my point is about #shoutAboutToStyle: a PluggableTextMorph is passed as argument, so, from the model, one have a direct access to the view and to the view styler. So, the Model implementation can be broken if another view class is used instead of PluggableTextMorph. And what about the Inspector pane which has two text editors ? Only one has to be shouted. So how would you implement #shoutAboutToStyle: in this case ? Thanks Alain On 05/09/2011 09:06, Lukas Renggli wrote: > No, this is not strange. The view-creation code is completely separate > from the model itself, even if it lives in the model class. The view > creation code is never called from within the model and in fact could > and should be packaged with the view. There are no references from the > model to the view, multiple views can concurrently co-exist on the > same model, and we can even support different view kinds at once > (morphic, toolbuilder, seaside, ...) by creating different UI creation > methods. > > Lukas > > On 5 September 2011 08:24, Alain Plantec<alain.plantec(a)yahoo.com> wrote: >> >>> right now the separation is bogus because to me a model should not refer >>> to methods that cretae the UI. :) >>> anyway. we will see that later. >> >> yes, it is a bit strange to be allowed to directly manipulate a view element >> from them model. >> Alain >> >> >> > > >

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Andrea BrÃ¼hlmann

Hello Stef, I appreciate the work of the pharo community! We will continue reporting bugs and submit fixes that we made. Of course I do not expect anyone to fix all reported bugs, but there are issues like 4694 (debugger) where we really need your help. Other issues like the buggy code completion can be workarounded by me by disabling code completion ;-) So thanks for the welcome and I am looking forward to having 4694 fixed! Andrea StÃ©phane Ducasse schrieb: > Thanks andrea > > Welcome to the pharo mailing-list and community. > > Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine) > that you should also contribute. Bug reporting is already a contribution. Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that). > I also understand that people can get frustrated by changes but what can we do? > > May be people can gather and check the fixes that are important to fix but we do not have the force to maintain. > > Imagine well that we have one engineer full time since 8 months. > > Stef > > > On Aug 23, 2011, at 8:54 AM, Andrea BrÃ¼hlmann wrote: > >> Hello, >> >> I reported some bugs on the issue tracker and hope you can help me with them! >> >> >> 4681: Accepting with the enter key does not work >> http://code.google.com/p/pharo/issues/detail?id=4681 >> >> 4682: Code completion makes strange cursor placements and too many spaces >> http://code.google.com/p/pharo/issues/detail?id=4682 >> >> 4683: Code completion breaks some search fields (errors during typing) >> http://code.google.com/p/pharo/issues/detail?id=4683 >> >> 4684: Missing ctrl+w (methodNamesContainingIt:) >> http://code.google.com/p/pharo/issues/detail?id=4684 >> >> 4685: Merge dialog: cannot resolve conflict with removed method >> http://code.google.com/p/pharo/issues/detail?id=4685 >> >> 4686: Method category change creates no new version >> http://code.google.com/p/pharo/issues/detail?id=4686 >> >> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil) >> http://code.google.com/p/pharo/issues/detail?id=4687 >> >> 4688: Progress bar disappears on image save >> http://code.google.com/p/pharo/issues/detail?id=4688 >> >> 4689: MessageTally bug >> http://code.google.com/p/pharo/issues/detail?id=4689 >> >> 4690: Progress bar position >> http://code.google.com/p/pharo/issues/detail?id=4690 >> >> 4691: Bad line breaks in code until window is resized (because of bold text?) >> http://code.google.com/p/pharo/issues/detail?id=4691 >> >> 4692: Drop downs should select the default entry (topmost) instead of a middle one >> http://code.google.com/p/pharo/issues/detail?id=4692 >> >> 4693: Line breaks in tooltips are wrong >> http://code.google.com/p/pharo/issues/detail?id=4693 >> >> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+. >> http://code.google.com/p/pharo/issues/detail?id=4694 >> >> 4695: Time asString prints nanos unrounded >> http://code.google.com/p/pharo/issues/detail?id=4695 >> >> >> -- >> Andrea BrÃ¼hlmann >> > > > -- AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH

Sept. 5, 2011

Re: [Pharo-project] about Shout default to shout any text?

by Lukas Renggli

No, this is not strange. The view-creation code is completely separate from the model itself, even if it lives in the model class. The view creation code is never called from within the model and in fact could and should be packaged with the view. There are no references from the model to the view, multiple views can concurrently co-exist on the same model, and we can even support different view kinds at once (morphic, toolbuilder, seaside, ...) by creating different UI creation methods. Lukas On 5 September 2011 08:24, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > >> right now the separation is bogus because to me a model should not refer >> to methods that cretae the UI. :) >> anyway. we will see that later. > > yes, it is a bit strange to be allowed to directly manipulate a view element > from them model. > Alain > > > -- Lukas Renggli www.lukas-renggli.ch

Sept. 5, 2011