December 2014 - Pharo-users

Re: [Pharo-users] Umlauts in ZnUrl

by Sven Van Caekenberghe

> On 03 Dec 2014, at 13:54, Udo Schneider <Udo.Schneider(a)homeaddress.de> wrote: > > On 03.12.2014 10:19, Sven Van Caekenberghe wrote: >> Hmm, have you seen that ZnClient>>#addPath: actually does this already for non-string arguments (assumed to be collections) ? > No I didn't. That's even better for my purposes! > >> That is too specific, to add for everyone I think. Now, the #split: behaviour is already in there. > I just deleted this method. I can work with intances of Path - so no need to #split: Strings anymore. > >> 'http://myhost.com' asUrl / 'foo' / 'Ã©lÃ¨ve-Ã¼mlaut.txt'. >> >> It is about as short as it gets, right ? >> >> Here is how to get the #split: behaviour: >> >> 'http://myhost.com' asUrl / 'foo/Ã©lÃ¨ve-Ã¼mlaut.txt' >> >> When adding a string, the argument is split on / automatically. > As always I amazed of Smalltalk in general and the design of Zinc specifically ... Good ! Don't forget: if you get something working that hasn't been done before (it seems you are working on WebDAV), write something short about it to share with the rest of the community. Sven

Dec. 3, 2014

Re: [Pharo-users] Umlauts in ZnUrl

by Udo Schneider

On 03.12.2014 10:19, Sven Van Caekenberghe wrote: > Hmm, have you seen that ZnClient>>#addPath: actually does this already for non-string arguments (assumed to be collections) ? No I didn't. That's even better for my purposes! > That is too specific, to add for everyone I think. Now, the #split: behaviour is already in there. I just deleted this method. I can work with intances of Path - so no need to #split: Strings anymore. > 'http://myhost.com' asUrl / 'foo' / 'Ã©lÃ¨ve-Ã¼mlaut.txt'. > > It is about as short as it gets, right ? > > Here is how to get the #split: behaviour: > > 'http://myhost.com' asUrl / 'foo/Ã©lÃ¨ve-Ã¼mlaut.txt' > > When adding a string, the argument is split on / automatically. As always I amazed of Smalltalk in general and the design of Zinc specifically ... CU, Udo

Dec. 3, 2014

Re: [Pharo-users] Alternate browser

by Thierry Goubier

2014-12-03 9:24 GMT+01:00 Craig Johnson <craig(a)hivemind.net>: > > I'm cleaning up a lot of small issues I had with it as I write (mostly > refreshing/deselection issues > > when redefining/renaming classes). > > > > I'm done with the pharo3.0 branch on github; I'm now merging those into > the pharo4.0 branch with git > > (i.e. merging with git on the command line without Monticello merge). > > > > Just tell how it goes for you; even if this is not the browser you like, > > your feedback will tell us where we can improve. > > Thierry > > A few comments on my side. Running AltBrowser Stable in Pharo 4 under > Windows. > * In the code pane - the short-cut key - Meta-S for Save - resets the > dirty code indicator, but does not actually save the code, using the > context menu does. > * Trying to open the Window Menu causes a warning - > "MenuMorph>>add:target:action: is depreciated" > Thanks Craig. I'll correct that. Thierry > > Craig > > > > >

Dec. 3, 2014

Re: [Pharo-users] Umlauts in ZnUrl

by Sven Van Caekenberghe

> On 03 Dec 2014, at 08:49, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > Hi Sven, > > the distinction between external and internal representations was the part I didn't get - but it really makes sense. OK. > Your approach with adding pathSegments works perfectly! I'm working with ZnClient though and reusing it for different requests. So I added the following two (three) methods to make my life easier: > > ZnClient>>#addPathSegments: pathSegments > "Modify the receiver's path by adding the elements of pathSegments at the end" > > pathSegments do: [ :each | self addPathSegment: each ] Hmm, have you seen that ZnClient>>#addPath: actually does this already for non-string arguments (assumed to be collections) ? > ZnClient>>#resetPath > self path: '' Yeah, that is maybe useful (there is already #resetEntity). I am also reusing ZnClient instances and I never needed to reset the path like that, I always do #path: and #url: I guess - mostly the second. > I didn't want to overwrite #path: because I only need this for some special edge case. > > ZnClient>>#webdavPath: path > self > resetPath; > addPathSegments: ($/ split: path) That is too specific, to add for everyone I think. Now, the #split: behaviour is already in there. But I also forgot to mention earlier that this works too: 'http://myhost.com' asUrl / 'foo' / 'Ã©lÃ¨ve-Ã¼mlaut.txt'. It is about as short as it gets, right ? Here is how to get the #split: behaviour: 'http://myhost.com' asUrl / 'foo/Ã©lÃ¨ve-Ã¼mlaut.txt' When adding a string, the argument is split on / automatically. > BTW: The whole Zinc framework is a real pleasure to work with. Once I got used to thinking in terms of objects and not only strings I didn't want to look back :-) Thanks. > CU, > > Udo > > > > On 03/12/14 00:02, Sven Van Caekenberghe wrote: >> Hi Udo, >> >> With a URL/URI there are two representations: the external one (the way they are written) and the internal one (what is really meant). ZnUrl follows this distinction. >> >> When you say #asUrl (or #asZnUrl) you are actually parsing an external string representation. When doing so, percent decoding is done by ZnPercentEncoder. This class is strict, in that it does not allow non-safe, non-ascii characters in its input. AFAIK this is correct, but I can imagine a less strict interpretation (like the URL input box of a browser would allow). If you have a reading of the specs that says otherwise I would be very interested. >> >> To save you from doing the encoding yourself, you have to construct the URL from its parts explicitly, like this: >> >> ZnUrl new >> scheme: #http; >> host: 'myhost'; >> addPathSegments: #('path' 'with' 'unlaut' 'Ã¤Ã¶Ã¼.txt'); >> yourself. >> >> => http://myhost/path/with/unlaut/%C3%A4%C3%B6%C3%BC.txt >> >> Class comments and unit tests should help. >> >> There is also this draft: >> >> http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ >> >> HTH, >> >> Sven >> >> PS: Incidentally, this does work >> >> 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asFileReference asUrl. >> >> because #asFileReference works differently. >> >>> On 02 Dec 2014, at 23:32, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >>> >>> All, >>> >>> What's the expected behavior with non-ASCII characters in URLs. Let's say I want to access a file named "Ã¤Ã¶Ã¼.txt" - My assumption was that Zinc takes care of the UTF-8 -> 7bit (ASCII) -> Escape encoding. But there is either something I don't understand or some manual steps I'm missing. >>> >>> The "straightforward" way doesn't work: >>> 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asUrl. "ZnCharacterEncodingError: ASCII character expected" >>> >>> Although the actual encoding seems to be able to handle it (ignoring the escapes slashes for the moment: >>> 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' urlEncoded. >>> "'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'" >>> >>> Creating a URL from already escaped characters works as well: >>> 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl. >>> "http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt" >>> >>> As does the decoding of such an URL: >>> 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded. >>> "'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt'" >>> >>> At them moment I'm manually encoding UTF-8 characters in paths segments before trying to build the URL. But is this the correct way? >>> >>> Best Regards, >>> >>> Udo >>> >>> >>> >> >> >> > > >

Dec. 3, 2014

Re: [Pharo-users] Alternate browser

by Craig Johnson

> I'm cleaning up a lot of small issues I had with it as I write (mostly refreshing/deselection issues > when redefining/renaming classes). > > I'm done with the pharo3.0 branch on github; I'm now merging those into the pharo4.0 branch with git > (i.e. merging with git on the command line without Monticello merge). > > Just tell how it goes for you; even if this is not the browser you like, > your feedback will tell us where we can improve. Thierry A few comments on my side. Running AltBrowser Stable in Pharo 4 under Windows. * In the code pane - the short-cut key - Meta-S for Save - resets the dirty code indicator, but does not actually save the code, using the context menu does. * Trying to open the Window Menu causes a warning - "MenuMorph>>add:target:action: is depreciated" Craig

Dec. 3, 2014

Re: [Pharo-users] Umlauts in ZnUrl

by Udo Schneider

Hi Sven, the distinction between external and internal representations was the part I didn't get - but it really makes sense. Your approach with adding pathSegments works perfectly! I'm working with ZnClient though and reusing it for different requests. So I added the following two (three) methods to make my life easier: ZnClient>>#addPathSegments: pathSegments "Modify the receiver's path by adding the elements of pathSegments at the end" pathSegments do: [ :each | self addPathSegment: each ] ZnClient>>#resetPath self path: '' I didn't want to overwrite #path: because I only need this for some special edge case. ZnClient>>#webdavPath: path self resetPath; addPathSegments: ($/ split: path) BTW: The whole Zinc framework is a real pleasure to work with. Once I got used to thinking in terms of objects and not only strings I didn't want to look back :-) CU, Udo On 03/12/14 00:02, Sven Van Caekenberghe wrote: > Hi Udo, > > With a URL/URI there are two representations: the external one (the way they are written) and the internal one (what is really meant). ZnUrl follows this distinction. > > When you say #asUrl (or #asZnUrl) you are actually parsing an external string representation. When doing so, percent decoding is done by ZnPercentEncoder. This class is strict, in that it does not allow non-safe, non-ascii characters in its input. AFAIK this is correct, but I can imagine a less strict interpretation (like the URL input box of a browser would allow). If you have a reading of the specs that says otherwise I would be very interested. > > To save you from doing the encoding yourself, you have to construct the URL from its parts explicitly, like this: > > ZnUrl new > scheme: #http; > host: 'myhost'; > addPathSegments: #('path' 'with' 'unlaut' 'Ã¤Ã¶Ã¼.txt'); > yourself. > > => http://myhost/path/with/unlaut/%C3%A4%C3%B6%C3%BC.txt > > Class comments and unit tests should help. > > There is also this draft: > > http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ > > HTH, > > Sven > > PS: Incidentally, this does work > > 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asFileReference asUrl. > > because #asFileReference works differently. > >> On 02 Dec 2014, at 23:32, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >> >> All, >> >> What's the expected behavior with non-ASCII characters in URLs. Let's say I want to access a file named "Ã¤Ã¶Ã¼.txt" - My assumption was that Zinc takes care of the UTF-8 -> 7bit (ASCII) -> Escape encoding. But there is either something I don't understand or some manual steps I'm missing. >> >> The "straightforward" way doesn't work: >> 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asUrl. "ZnCharacterEncodingError: ASCII character expected" >> >> Although the actual encoding seems to be able to handle it (ignoring the escapes slashes for the moment: >> 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' urlEncoded. >> "'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'" >> >> Creating a URL from already escaped characters works as well: >> 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl. >> "http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt" >> >> As does the decoding of such an URL: >> 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded. >> "'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt'" >> >> At them moment I'm manually encoding UTF-8 characters in paths segments before trying to build the URL. But is this the correct way? >> >> Best Regards, >> >> Udo >> >> >> > > >

Dec. 3, 2014

Re: [Pharo-users] Umlauts in ZnUrl

by Sven Van Caekenberghe

Hi Udo, With a URL/URI there are two representations: the external one (the way they are written) and the internal one (what is really meant). ZnUrl follows this distinction. When you say #asUrl (or #asZnUrl) you are actually parsing an external string representation. When doing so, percent decoding is done by ZnPercentEncoder. This class is strict, in that it does not allow non-safe, non-ascii characters in its input. AFAIK this is correct, but I can imagine a less strict interpretation (like the URL input box of a browser would allow). If you have a reading of the specs that says otherwise I would be very interested. To save you from doing the encoding yourself, you have to construct the URL from its parts explicitly, like this: ZnUrl new scheme: #http; host: 'myhost'; addPathSegments: #('path' 'with' 'unlaut' 'Ã¤Ã¶Ã¼.txt'); yourself. => http://myhost/path/with/unlaut/%C3%A4%C3%B6%C3%BC.txt Class comments and unit tests should help. There is also this draft: http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ HTH, Sven PS: Incidentally, this does work 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asFileReference asUrl. because #asFileReference works differently. > On 02 Dec 2014, at 23:32, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > All, > > What's the expected behavior with non-ASCII characters in URLs. Let's say I want to access a file named "Ã¤Ã¶Ã¼.txt" - My assumption was that Zinc takes care of the UTF-8 -> 7bit (ASCII) -> Escape encoding. But there is either something I don't understand or some manual steps I'm missing. > > The "straightforward" way doesn't work: > 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asUrl. "ZnCharacterEncodingError: ASCII character expected" > > Although the actual encoding seems to be able to handle it (ignoring the escapes slashes for the moment: > 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' urlEncoded. > "'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'" > > Creating a URL from already escaped characters works as well: > 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl. > "http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt" > > As does the decoding of such an URL: > 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded. > "'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt'" > > At them moment I'm manually encoding UTF-8 characters in paths segments before trying to build the URL. But is this the correct way? > > Best Regards, > > Udo > > >

Dec. 2, 2014

Umlauts in ZnUrl

by Udo Schneider

All, What's the expected behavior with non-ASCII characters in URLs. Let's say I want to access a file named "Ã¤Ã¶Ã¼.txt" - My assumption was that Zinc takes care of the UTF-8 -> 7bit (ASCII) -> Escape encoding. But there is either something I don't understand or some manual steps I'm missing. The "straightforward" way doesn't work: 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' asUrl. "ZnCharacterEncodingError: ASCII character expected" Although the actual encoding seems to be able to handle it (ignoring the escapes slashes for the moment: 'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt' urlEncoded. "'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'" Creating a URL from already escaped characters works as well: 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl. "http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt" As does the decoding of such an URL: 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded. "'http://myhost/path/with/umlaut/Ã¤Ã¶Ã¼.txt'" At them moment I'm manually encoding UTF-8 characters in paths segments before trying to build the URL. But is this the correct way? Best Regards, Udo

Dec. 2, 2014

Re: [Pharo-users] Alternate browser

by Hilaire

Are you running your web service on a Linux box? If so mail me privately to hilaire(a)drgeo.eu Hilaire Le 01/12/2014 23:07, Tudor Girba a Ã©crit : > Indeed. > > Can anyone help me with doing this? > > Doru > > On Mon, Dec 1, 2014 at 9:36 PM, Hilaire > <hilaire(a)drgeo.eu > <mailto:hilaire@drgeo.eu>> wrote: > > Le 01/12/2014 15:09, Tudor Girba a Ã©crit : > > > > Sorry for the trouble. I will try to migrate my websites to a more > > stable technology :(. > > > > Not perfect, but you can set a cron to restart it daily. > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 2, 2014

Re: [Pharo-users] Alternate browser

by Tudor Girba

Thanks for the kind words, Kilon. Please feel free to ask questions. Cheers, Doru On Tue, Dec 2, 2014 at 11:29 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > "In my image, I have 144 such extensions taking on average 9 lines of > code." > > Impressive then apparently GT tools goes exactly the direction I wanted. I > was aware of Glamour but to be frank I have not seen anyone else use it but > you guys so I was kinda sceptical about it and did not took it very > seriously. I was not aware that GT tools were built on top of Glamour and > this certainly gives it more credit, I thought it was merely for making > custom browsers looks like its a lot more than that. Thank you Tudor you > gave me a lot of to read. > > I definetly when to develop my tools and libraries in sync to the > direction Pharo is going so I can take advantage of the existing code and > not reinvent the wheel. So now I will sit down and study all these > technologies and see how I can utilise them better in my workflow. Thank > you for you hard work and taking the time explaining. > > On Tue, Dec 2, 2014 at 12:29 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> > On 01 Dec 2014, at 23:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > >> > Glamour is an engine by itself, but for the inspector you mainly need >> the presentations, which are essentially widgets that can be parameterized >> through blocks. A custom presentation like this typically requires one >> method. If you want to get examples of how to apply it for the inspector, >> you can use the inspector to answer that question, as described here: >> > http://www.humane-assessment.com/blog/managing-gtinspector-extensions/ >> >> Yes, yes, very nice. >> > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 2, 2014