June 2015 - Pharo-users - lists.pharo.org

Styling UI using Spec

by Jigyasa Grover

Hi I am using Spec to build the UI for an application. It would be great if anyone could help me put up nice background and images (just like we can do in Morphs). Thanks Jigyasa PS: Can I put up an image like this ? (It doesnt seem to work) /ImageModel new image: (Form fromFileNamed: FileSystem workingDirectory / 'header.gif'); openWithSpec./ -- View this message in context: http://forum.world.st/Styling-UI-using-Spec-tp4831673.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 11, 2015

Re: [Pharo-users] ZnClient and percent characters

by Norbert Hartl

No offense meant. I assumed you would know the term. Sorry! Henry explained it quite good what I meant. Norbert > Am 11.06.2015 um 09:51 schrieb PBKResearch <peter(a)pbkresearch.co.uk>: > > I donât quite understand Norbertâs comment. Does âmonkeyâ apply to me or to what I have done? Either way, it seems unnecessary and abusive. > > Thanks to Svenâs careful use of informative method names, the effect of my change is quite clear. Any comma in the value part of a query line will be encoded. Nothing else. I did my best to trace any side effects, and didnât find any. What is not âreliableâ about that? > > Peter Kenny > > > I was thinking of a reliable solution. Of course if it only needs to be tested than monkey patching foreign packages is ok. > > Norbert > >> Am 11.06.2015 um 01:22 schrieb PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk>>: >> >> There is a simpler way than Norbertâs suggestion. Find the class ZnResourceMetaUtils (in the package Zinc-Resource-Meta-Core). Locate the class side method #queryKeyValueSafeSet. Remove the comma from the string. With this change your âGoogleâ example generates the query line with the â%2Câ encoding of the commas. >> >> Of course, with this change a comma in the value field of a query will always be encoded. It is not clear to me whether this is correcting an error in Zinc, or just a hack to solve your problem â earlier posts here endorse both views. No doubt Sven is the person to sort this out. Meanwhile, this will enable you to get moving. >> >> Hope this helps >> >> Peter Kenny >> >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of Norbert Hartl >> Sent: 10 June 2015 23:56 >> To: Pharo users users >> Subject: Re: [Pharo-users] ZnClient and percent characters >> >> Just to clarify: >> >> "Characters in the "reserved" set are not reserved in all contexts. >> The set of characters actually reserved within any given URI >> component is defined by that component. In general, a character is >> reserved if the semantics of the URI changes if the character is >> replaced with its escaped US-ASCII encoding." >> If I were you I'd subclass ZnUrl and implement >> #encodeQuery:on: >> on that class. You could have an extension method in ZnResourceMetaUtils that returns the character set you need to have encoded. In ZnClient you just set your ZnUrl derived class object as #url: >> Cannot think of anything better for a quick resolve of your problem. >> Norbert >>> Am 11.06.2015 um 00:26 schrieb Jimmie Houchin <jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>>: >>> >>> I am not an expert on URIs or encoding. However, this is a requirement of the API I am using and I am required to submit an encoded URI with %2C and no commas. >>> >>> As far as commas needing to be escaped, it seems from other sources that they should be. >>> >>> From https://www.ietf.org/rfc/rfc2396.txt <https://www.ietf.org/rfc/rfc2396.txt> >>> >>> >>> The plus "+", dollar "$", and comma "," characters have been added to >>> those in the "reserved" set, since they are treated as reserved >>> within the query component. >>> >>> States that commas are reserved within the query component. >>> >>> http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded <http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded> >>> >>> Regardless of what is or is not required, I do need the ability to have a query string with commas encoded as %2C in order to satisfy and use the API which states. >>> >>> fields: Optional An URL encoded (%2C) comma separated list of instrument fields that are to be returned in the response. The instrument field will be returned regardless of the input to this query parameter. Please see the Response Parameters section below for a list of valid values. >>> >>> Which will look like this or something similar. >>> >>> fields=displayName%2Cinstrument%2Cpip >>> >>> >>> Thanks. >>> >>> Jimmie >>> >>> On 06/10/2015 03:27 PM, Norbert Hartl wrote: >>>> That's because the comma does not need to be escaped in the query part of the uri. >>>> >>>> Norbert >>>> >>>>> Am 10.06.2015 um 22:00 schrieb Jimmie Houchin <jlhouchin(a)gmail.com> <mailto:jlhouchin@gmail.com>: >>>>> >>>>> On 06/10/2015 10:32 AM, Sven Van Caekenberghe wrote: >>>>>>> On 10 Jun 2015, at 17:24, David <stormbyte(a)gmail.com> <mailto:stormbyte@gmail.com> wrote: >>>>>>> >>>>>>> El Wed, 10 Jun 2015 10:14:37 -0500 >>>>>>> Jimmie Houchin <jlhouchin(a)gmail.com> <mailto:jlhouchin@gmail.com> >>>>>>> escribiÃ³: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am attempting to use ZnClient to request data. The request requires >>>>>>>> a %2C (comma) delimited string as part of the query. Below is a >>>>>>>> snippet. >>>>>>>> >>>>>>>> znClient >>>>>>>> addPath: '/v1/instruments'; >>>>>>>> queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; >>>>>>>> get ; >>>>>>>> contents) >>>>>>>> >>>>>>>> The string 'displayName%2Cinstrument%2Cpip' >>>>>>>> is being converted to 'displayName%252Cinstrument%252Cpip' >>>>>>>> which causes the request to fail. >>>>>>>> >>>>>>>> The query needs to be >>>>>>>> fields=displayName%2Cinstrument%2Cpip >>>>>>>> >>>>>>>> I have not found how to do this correctly. >>>>>>>> Any help greatly appreciated. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Jimmie >>>>>>>> >>>>>>>> >>>>>>> Maybe a silly thing, but since %2C = , ... Did you tried already to >>>>>>> make itself encode that? Like >>>>>>> znClient >>>>>>> addPath: '/v1/instruments'; >>>>>>> queryAt: 'fields' putAll: 'displayName,instrument,pip'; >>>>>>> get ; >>>>>>> contents) >>>>>>> >>>>>>> I suspect it is using encoding internally, that is why % is also >>>>>>> encoded if you try to put it. >>>>>>> >>>>>>> I hope that works >>>>>> Not silly and no need to suspect, but absolutely correct ! >>>>>> >>>>>> Sven >>>>> My apologies for not having full disclosure. >>>>> >>>>> Pharo 4, new image, freshly installed Zinc stable version. >>>>> Xubuntu 15.04 >>>>> >>>>> >>>>> >>>>> That is what I thought would happen and what I tried first. But it is not being encoded from what I can find. >>>>> >>>>> Inspect this in a workspace/playground. >>>>> >>>>> ZnClient new >>>>> https; >>>>> host: 'google.com <http://google.com/>'; >>>>> addPath: '/commaTest'; >>>>> queryAt: 'fields' put: 'displayName,instrument,pip'; >>>>> yourself >>>>> >>>>> View the request / requestLine / uri. The commas are still present in the URI. >>>>> So I tried encoding myself and get the other error. >>>>> >>>>> Of course Google won't understand this and in this snippet won't receive it. >>>>> >>>>> And please let me know if I am doing something wrong. >>>>> >>>>> Any help greatly appreciated. >>>>> >>>>> Jimmie

June 11, 2015

Re: [Pharo-users] New Tool: Catalog Browser in Pharo 5.0

by Torsten Bergmann

Esteban wrote: > > If you want to contribute just tell Esteban so he can add you to the project. > well noâ¦ I just made it public access, so anyone can commit changes thereâ¦ :) > (And I will move it to PharoExtras team soon, thatâs the correct place once integrated in imageâ¦ but wellâ¦ time is tyrant :P) I moved it to PharoExtras, MCZs are copied and config adopted (with a new version 0.5): http://smalltalkhub.com/#!/~PharoExtras/CatalogBrowser/ This is tracked for integration in: https://pharo.fogbugz.com/f/cases/15744/CatalogBrowser-moved-to-PharoExtras BTW: IMHO we can close https://pharo.fogbugz.com/f/cases/15703/ Thanks T.

June 11, 2015

Re: [Pharo-users] ZnClient and percent characters

by PBKResearch

Sven As I read the code, there are two methods in ZnMetaResourceUtils class which specify percent encoding of queries, #queryKeyValueSafeSet and #querySafeSet. The first is used in encoding the (key, value) pairs, the second in encoding the fragment after the #. It is not clear whether we need separate safe sets for the two cases, but in any case the first one was obviously the one to change to fix Jimmie's original problem. Having been accused of monkeying with your code in an unreliable way, I shall keep my head down in future. It's a pity - I find it quite enjoyable trying to help people, and trying to prove that my elderly brain is not completely addled. Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 11 June 2015 07:35 To: Any question about pharo is welcome Subject: Re: [Pharo-users] ZnClient and percent characters @everybody The key method that defines how the query part of a URL is percent encoded is ZnMetaResourceUtils class>>#querySafeSet Years ago, Zinc HTTP Components followed the better safe than sorry approach of encoding almost every character except for the ones that are safe in all contexts. Later on, we began reading the specs better and decided to follow them more closely, that is why there are now different safe sets. Now, we can (and should) all read the different specs, and try to learn from things in the wild as well from other implementations. The quote from http://en.wikipedia.org/wiki/Query_string was incomplete, it said 'for HTML 5 when submitting a form using GET', which is a very specific context. ZnUrl was written against RFC 3986 mostly. Now, maybe we made a mistake, maybe not. But maybe it also would be a good idea to allow users to decide this for themselves on a case by case basis. > On 11 Jun 2015, at 05:18, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > Thanks for the reply. > > I implemented Peter's suggestion as an easy keep moving solution. > > As I said, I am not expert in what is or is not legal according to the standards. > However, looking at Python, their urllib library in the quote and urlencode methods they encode the commas by default. > > _ALWAYS_SAFE = frozenset(b'ABCDEFGHIJKLMNOPQRSTUVWXYZ' > b'abcdefghijklmnopqrstuvwxyz' > b'0123456789' > b'_.-') > > https://docs.python.org/3/library/urllib.parse.html > https://hg.python.org/cpython/file/3.4/Lib/urllib/parse.py > > That's at least how one major language understands the standard. And Python 2.7 is the same. > > According to Wikipedia > http://en.wikipedia.org/wiki/Query_string > â¢ Characters that cannot be converted to the correct charset are > replaced with HTML numeric character references[9] â¢ SPACE is encoded as '+' > â¢ Letters (AâZ and aâz), numbers (0â9) and the characters '*','-','.' > and '_' are left as-is > > It appeared in the stackoverflow article I quoted previously that ASP.NET encodes commas. I could misunderstand or be reading into it. > http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encode > d Just a little more information to add to the discussion. > > Thanks. > > Jimmie > > > > > On 06/10/2015 05:56 PM, Norbert Hartl wrote: >> Just to clarify: >> >> " >> Characters in the "reserved" set are not reserved in >> all contexts. >> >> The set of characters actually reserved within any given URI >> component is defined by that component. In general, a character is >> reserved if the semantics of the URI changes if the character is >> replaced with its escaped US-ASCII encoding." >> >> If I were you I'd subclass ZnUrl and implement >> #encodeQuery:on: >> on that class. You could have an extension method in ZnResourceMetaUtils that returns the character set you need to have encoded. In ZnClient you just set your ZnUrl derived class object as #url: >> Cannot think of anything better for a quick resolve of your problem. >> Norbert >>> Am 11.06.2015 um 00:26 schrieb Jimmie Houchin <jlhouchin(a)gmail.com>: >>> >>> I am not an expert on URIs or encoding. However, this is a requirement of the API I am using and I am required to submit an encoded URI with %2C and no commas. >>> >>> As far as commas needing to be escaped, it seems from other sources that they should be. >>> >>> From https://www.ietf.org/rfc/rfc2396.txt >>> The plus "+", dollar "$", and comma "," characters have been added to >>> those in the "reserved" set, since they are treated as reserved >>> within the query component. >>> >>> States that commas are reserved within the query component. >>> >>> >>> http://stackoverflow.com/questions/8828702/why-is-the-comma-url-enco >>> ded >>> >>> >>> Regardless of what is or is not required, I do need the ability to have a query string with commas encoded as %2C in order to satisfy and use the API which states. >>> >>> fields: Optional An URL encoded (%2C) comma separated list of instrument fields that are to be returned in the response. The instrument field will be returned regardless of the input to this query parameter. Please see the Response Parameters section below for a list of valid values. >>> >>> Which will look like this or something similar. >>> >>> fields=displayName%2Cinstrument%2Cpip >>> >>> >>> Thanks. >>> >>> Jimmie >>> >>> >>> On 06/10/2015 03:27 PM, Norbert Hartl wrote: >>>> That's because the comma does not need to be escaped in the query part of the uri. >>>> >>>> Norbert >>>> >>>> >>>>> Am 10.06.2015 um 22:00 schrieb Jimmie Houchin >>>>> <jlhouchin(a)gmail.com> >>>>> : >>>>> >>>>> On 06/10/2015 10:32 AM, Sven Van Caekenberghe wrote: >>>>> >>>>>>> On 10 Jun 2015, at 17:24, David <stormbyte(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> El Wed, 10 Jun 2015 10:14:37 -0500 Jimmie Houchin >>>>>>> <jlhouchin(a)gmail.com> >>>>>>> >>>>>>> escribiÃ³: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am attempting to use ZnClient to request data. The request >>>>>>>> requires a %2C (comma) delimited string as part of the query. >>>>>>>> Below is a snippet. >>>>>>>> >>>>>>>> znClient >>>>>>>> addPath: '/v1/instruments'; >>>>>>>> queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; >>>>>>>> get ; >>>>>>>> contents) >>>>>>>> >>>>>>>> The string 'displayName%2Cinstrument%2Cpip' >>>>>>>> is being converted to 'displayName%252Cinstrument%252Cpip' >>>>>>>> which causes the request to fail. >>>>>>>> >>>>>>>> The query needs to be >>>>>>>> fields=displayName%2Cinstrument%2Cpip >>>>>>>> >>>>>>>> I have not found how to do this correctly. >>>>>>>> Any help greatly appreciated. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Jimmie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Maybe a silly thing, but since %2C = , ... Did you tried already >>>>>>> to make itself encode that? Like znClient >>>>>>> addPath: '/v1/instruments'; >>>>>>> queryAt: 'fields' putAll: 'displayName,instrument,pip'; >>>>>>> get ; >>>>>>> contents) >>>>>>> >>>>>>> I suspect it is using encoding internally, that is why % is also >>>>>>> encoded if you try to put it. >>>>>>> >>>>>>> I hope that works >>>>>>> >>>>>> Not silly and no need to suspect, but absolutely correct ! >>>>>> >>>>>> Sven >>>>>> >>>>> My apologies for not having full disclosure. >>>>> >>>>> Pharo 4, new image, freshly installed Zinc stable version. >>>>> Xubuntu 15.04 >>>>> >>>>> >>>>> >>>>> That is what I thought would happen and what I tried first. But it is not being encoded from what I can find. >>>>> >>>>> Inspect this in a workspace/playground. >>>>> >>>>> ZnClient new >>>>> https; >>>>> host: ' >>>>> google.com >>>>> '; >>>>> addPath: '/commaTest'; >>>>> queryAt: 'fields' put: 'displayName,instrument,pip'; >>>>> yourself >>>>> >>>>> View the request / requestLine / uri. The commas are still present in the URI. >>>>> So I tried encoding myself and get the other error. >>>>> >>>>> Of course Google won't understand this and in this snippet won't receive it. >>>>> >>>>> And please let me know if I am doing something wrong. >>>>> >>>>> Any help greatly appreciated. >>>>> >>>>> Jimmie >>>>> >>>>> >>>>> >>>>> >>> >> >

June 11, 2015

Re: [Pharo-users] New Tool: Catalog Browser in Pharo 5.0

by Esteban Lorenzano

Hi, > On 11 Jun 2015, at 08:55, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). > includes a new tool called "Catalog Browser". > > Where to go > =========== > > You will find it under "Tools" -> "Catalog Browser" and it will display the > configs together with the catalog metadata like project description. this is the most important, so people can actually know what a project is about :) but of course, that depends on you providing information in catalog methods! > > The code is managed with a configuration similar to what we have for > a few other packages/projects. The tool was written by Esteban Lorenzano with small > improvements like spotter integration from my side. Feel free to contribute more features. > > The repository can be found on SmalltalkHub [2]. > > This new tool basically gives you access to all available configurations > aggregated at [3]. You can use a small UI to search and load the configs > (see world menu -> "Tools" -> "Catalog Browser". > > But you can also use Spotter to load a config. > > Example on how to load ScriptManager config: > ============================================ > - open Spotter (SHIFT + ENTER on Windows, ...) > - type in "Script" and you will find a spotter category "Catalog Projects" with "ScriptManager" in it > - just hit enter and the config is loaded > > Same for all others, so try with "Seaside", "MongoTalk", ... > > In the short/mid-term this new tool should replace the existing config browser as it > gives more informations about the projects. > > What to do next: > ================ > - give feedback > - we should update all our configs with catalog descriptions please, this is vital to have a good entry point to your projects. > - it would be nice if the spotter integration would include also a preview of the project > description +1 > - ... > > If you want to contribute just tell Esteban so he can add you to the project. well noâ¦ I just made it public access, so anyone can commit changes thereâ¦ :) (And I will move it to PharoExtras team soon, thatâs the correct place once integrated in imageâ¦ but wellâ¦ time is tyrant :P) Esteban ps: Thanks Torsten to look at it! > > Thanks > Esteban & Torsten > > [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964… > [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser > [3] http://catalog.pharo.org/catalog/json<catalogBrowser.png>

June 11, 2015

Re: [Pharo-users] World lastKeystroke and openInWorld: aPasteUpMorph

by Markus Schlager

issues opened Markus

June 11, 2015

Re: [Pharo-users] ZnClient and percent characters

by Henrik Johansen

> On 11 Jun 2015, at 9:51 , PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > I donât quite understand Norbertâs comment. Does âmonkeyâ apply to me or to what I have done? Either way, it seems unnecessary and abusive. It's a phrase to describe the change: http://en.wikipedia.org/wiki/Monkey_patch <http://en.wikipedia.org/wiki/Monkey_patch> I think Ruby popularized it, the phrase I was familiar with in a Smalltalk context was "method override" > Thanks to Svenâs careful use of informative method names, the effect of my change is quite clear. Any comma in the value part of a query line will be encoded. Nothing else. I did my best to trace any side effects, and didnât find any. What is not âreliableâ about that? > > Peter Kenny The problem with overrides of methods in an external librarey arise when: - Other packages you load depend on the same method being monkey patched in a different way way. - Bug fixes/Refactorings in the base library renders the change incorrect/obsolete, which can be hard to notice. * Subclassing and adding your modifications there instead "solves" the first problem. Reading the specs, determining the original behaviour is a bug, submitting a fix, and have it accepted in the base library instead fixes both. Cheers, Henry * For instance, in my day job maintaining a VW application, when upgrading to new versions, verifying that all monkey patches are still correct accounts for a significant portion of the time spent

June 11, 2015

Re: [Pharo-users] ZnClient and percent characters

by PBKResearch

I donât quite understand Norbertâs comment. Does âmonkeyâ apply to me or to what I have done? Either way, it seems unnecessary and abusive. Thanks to Svenâs careful use of informative method names, the effect of my change is quite clear. Any comma in the value part of a query line will be encoded. Nothing else. I did my best to trace any side effects, and didnât find any. What is not âreliableâ about that? Peter Kenny I was thinking of a reliable solution. Of course if it only needs to be tested than monkey patching foreign packages is ok. Norbert Am 11.06.2015 um 01:22 schrieb PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> >: There is a simpler way than Norbertâs suggestion. Find the class ZnResourceMetaUtils (in the package Zinc-Resource-Meta-Core). Locate the class side method #queryKeyValueSafeSet. Remove the comma from the string. With this change your âGoogleâ example generates the query line with the â%2Câ encoding of the commas. Of course, with this change a comma in the value field of a query will always be encoded. It is not clear to me whether this is correcting an error in Zinc, or just a hack to solve your problem â earlier posts here endorse both views. No doubt Sven is the person to sort this out. Meanwhile, this will enable you to get moving. Hope this helps Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Norbert Hartl Sent: 10 June 2015 23:56 To: Pharo users users Subject: Re: [Pharo-users] ZnClient and percent characters Just to clarify: "Characters in the "reserved" set are not reserved in all contexts. The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding." If I were you I'd subclass ZnUrl and implement #encodeQuery:on: on that class. You could have an extension method in ZnResourceMetaUtils that returns the character set you need to have encoded. In ZnClient you just set your ZnUrl derived class object as #url: Cannot think of anything better for a quick resolve of your problem. Norbert Am 11.06.2015 um 00:26 schrieb Jimmie Houchin < <mailto:jlhouchin@gmail.com> jlhouchin(a)gmail.com>: I am not an expert on URIs or encoding. However, this is a requirement of the API I am using and I am required to submit an encoded URI with %2C and no commas. As far as commas needing to be escaped, it seems from other sources that they should be. >From <https://www.ietf.org/rfc/rfc2396.txt> https://www.ietf.org/rfc/rfc2396.txt The plus "+", dollar "$", and comma "," characters have been added to those in the "reserved" set, since they are treated as reserved within the query component. States that commas are reserved within the query component. <http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded> http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded Regardless of what is or is not required, I do need the ability to have a query string with commas encoded as %2C in order to satisfy and use the API which states. fields: Optional An URL encoded (%2C) comma separated list of instrument fields that are to be returned in the response. The instrument field will be returned regardless of the input to this query parameter. Please see the Response Parameters section below for a list of valid values. Which will look like this or something similar. fields=displayName%2Cinstrument%2Cpip Thanks. Jimmie On 06/10/2015 03:27 PM, Norbert Hartl wrote: That's because the comma does not need to be escaped in the query part of the uri. Norbert Am 10.06.2015 um 22:00 schrieb Jimmie Houchin <mailto:jlhouchin@gmail.com> <jlhouchin(a)gmail.com>: On 06/10/2015 10:32 AM, Sven Van Caekenberghe wrote: On 10 Jun 2015, at 17:24, David <mailto:stormbyte@gmail.com> <stormbyte(a)gmail.com> wrote: El Wed, 10 Jun 2015 10:14:37 -0500 Jimmie Houchin <mailto:jlhouchin@gmail.com> <jlhouchin(a)gmail.com> escribiÃ³: Hello, I am attempting to use ZnClient to request data. The request requires a %2C (comma) delimited string as part of the query. Below is a snippet. znClient addPath: '/v1/instruments'; queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; get ; contents) The string 'displayName%2Cinstrument%2Cpip' is being converted to 'displayName%252Cinstrument%252Cpip' which causes the request to fail. The query needs to be fields=displayName%2Cinstrument%2Cpip I have not found how to do this correctly. Any help greatly appreciated. Thanks. Jimmie Maybe a silly thing, but since %2C = , ... Did you tried already to make itself encode that? Like znClient addPath: '/v1/instruments'; queryAt: 'fields' putAll: 'displayName,instrument,pip'; get ; contents) I suspect it is using encoding internally, that is why % is also encoded if you try to put it. I hope that works Not silly and no need to suspect, but absolutely correct ! Sven My apologies for not having full disclosure. Pharo 4, new image, freshly installed Zinc stable version. Xubuntu 15.04 That is what I thought would happen and what I tried first. But it is not being encoded from what I can find. Inspect this in a workspace/playground. ZnClient new https; host: ' <http://google.com/> google.com'; addPath: '/commaTest'; queryAt: 'fields' put: 'displayName,instrument,pip'; yourself View the request / requestLine / uri. The commas are still present in the URI. So I tried encoding myself and get the other error. Of course Google won't understand this and in this snippet won't receive it. And please let me know if I am doing something wrong. Any help greatly appreciated. Jimmie

June 11, 2015

Re: [Pharo-users] [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Tudor Girba

Really cool! About the spotter integration, it is really nice to be able to search and find new projects like this. Well done. But, there are two things that I would change: - Right now, the processor order is 10. If you search for GTSpotter, you will get the catalog project before the class: [image: Inline image 1] I would rather prefer the order to be next to the Metacello configurations, so I would make it 90. The reason is that the things that are in the image should take precedence because they are much more often used. - For the preview, I would put the details that we have about the project. - Also, if you are at it, it would be nice to add an inspector extension for showing all projects of a CatalogProvider and to add a load action for a CatalogProject object :) Cheers, Doru On Thu, Jun 11, 2015 at 8:55 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > maybe you already noticed. The latest update for Pharo 5 which is 50103 > (see [1]). > includes a new tool called "Catalog Browser". > > Where to go > =========== > > You will find it under "Tools" -> "Catalog Browser" and it will display the > configs together with the catalog metadata like project description. > > The code is managed with a configuration similar to what we have for > a few other packages/projects. The tool was written by Esteban Lorenzano > with small > improvements like spotter integration from my side. Feel free to > contribute more features. > > The repository can be found on SmalltalkHub [2]. > > This new tool basically gives you access to all available configurations > aggregated at [3]. You can use a small UI to search and load the configs > (see world menu -> "Tools" -> "Catalog Browser". > > But you can also use Spotter to load a config. > > Example on how to load ScriptManager config: > ============================================ > - open Spotter (SHIFT + ENTER on Windows, ...) > - type in "Script" and you will find a spotter category "Catalog > Projects" with "ScriptManager" in it > - just hit enter and the config is loaded > > Same for all others, so try with "Seaside", "MongoTalk", ... > > In the short/mid-term this new tool should replace the existing config > browser as it > gives more informations about the projects. > > What to do next: > ================ > - give feedback > - we should update all our configs with catalog descriptions > - it would be nice if the spotter integration would include also a preview > of the project > description > - ... > > If you want to contribute just tell Esteban so he can add you to the > project. > > Thanks > Esteban & Torsten > > [1] > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964… > [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser > [3] http://catalog.pharo.org/catalog/json -- www.tudorgirba.com "Every thing has its own flow"

June 11, 2015

Re: [Pharo-users] Using GTSpotter how do I find an implementor of #accept ?

by Nicolai Hess

2015-06-11 7:05 GMT+02:00 Paul DeBruicker <pdebruic(a)gmail.com>: > Hi Doru, > > By "the old version of Spotter" I meant whatever was in Pharo 3 that would > produce a list of search results with exact matches at the top when I'd hit > shift+enter and then type e.g. 'accept.' Sorry to have said "Pharo 4" & > been unnecessarily confusing. > I miss spotlight for this fast accurate search too. It is much easier to type a message (like accept) and hit enter and you get a MessageList/Browser with that result. Instead, in spotter, you have to - scroll through the list of all other search results (like classes) - dive in the list of all implementors - scroll again and no easy way to open a message list with all implementors. But: It is MUCH easier to configure or extent Spotter (if you understand the badly documented concepts behind). Spotter is not a perfect replacement for Spotlight, but spotlight wasn't perfect/accurate too. For example, search for String and you got all possible classes or methods with String in its name but NOT the class String itself, (not even if you scroll down, because the search result includes only 100 entries). There are often symbols in the resultlist that aren't messages at all and if you select that result you get "There are no imiplementors of ..." this annoyed me a lot. I fixed some of the problems with spotlight but doing this for spottter is much cleaner and easier. > > > I'm just going to use 'accept' for this example but why show the mixed list > of 637 implementors of accept* and not lead with "accept". Why was it > decided that inexact matches to the typed input be privileged above exact > matches in the new tool? Is it a bad Levenshtein distance algorithm or > something? > "Why was it decided that ..." no decision, it was implemented successive to catch up with old spotlight. missing features were added afterwards (like search for globals and class vars) any missing feauter ? -> open an issue ( and or contribute a fix) > > > Thanks for helping me figure it out > > > Paul > > > > > > Tudor Girba-2 wrote > > Hi, > > > > What do you mean by the old version of Spotter? > > > > Just in case: you should know that Spotter is made to be extensible. This > > means that if you want to play with your own way of searching for > objects, > > you can just do it. Let me know if you to try and if you need help in > this > > direction. > > > > Cheers, > > Doru > > > > > > > > On Wed, Jun 10, 2015 at 9:10 PM, Paul DeBruicker < > > > pdebruic@ > > > > wrote: > > > >> > >> Is there any way to change back to the old version of Spotter in Pharo > 4? > >> > >> > >> > >> > >> > >> Nicolai Hess wrote > >> > 2015-06-10 16:24 GMT+02:00 Paul DeBruicker < > >> > >> > pdebruic@ > >> > >> > >: > >> > > >> >> So by default the search tool is only guaranteed to return an exact > >> term > >> >> match if there are only less than 5 non-exact match results? > >> >> > >> >> > >> > Yes > >> > > >> > > >> > > >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Nicolai Hess wrote > >> >> > 2015-06-10 7:39 GMT+02:00 Paul DeBruicker < > >> >> > >> >> > pdebruic@ > >> >> > >> >> > >: > >> >> > > >> >> >> when I hit shift+enter and type 'accept' I get things that are not > >> >> >> #accept, e.g. #accept: and AbstractAcceptor. > >> >> >> > >> >> >> If I add a space after accept it doesn't help. > >> >> >> > >> >> >> > >> >> >> What do I not understand? > >> >> >> > >> >> > > >> >> > the result list is not sorted and the result list is built by all > >> >> methods > >> >> > having the query string as part > >> >> > of its selector name. > >> >> > > >> >> > Yes this can be improved and it is not difficult, for example you > >> can > >> >> add > >> >> > this method to > >> >> > > >> >> > GTFilterImplementor>>applyFilterWithQuery > >> >> > super applyFilterWithQuery. > >> >> > items sort: [ :a :b | (self itemFilterNameFor: a) size < (self > >> >> > itemFilterNameFor: b) size ] > >> >> > > >> >> > this will sort the result list by the size of the selector name. > So, > >> if > >> >> > there is a perfect match, > >> >> > it will be listed first. > >> >> > (BUT only in the implementors category if you "dive-in", not in the > >> >> > 5-elements-result-preview-list). > >> >> > > >> >> > Maybe there is a better way without sorting. (We can modify > >> >> > applyFilterWithQuery for the implementors > >> >> > filter, to put perfect matches at the begining of the list). > >> >> > > >> >> > But all this is not easy to discover. Spotter classes make some > >> heavy > >> >> use > >> >> > of delegation, many operations > >> >> > are split and delgated to subclasses (GOOD!) > >> >> > many classes aren't documented (BAD!) and this makes it really > >> >> difficult > >> >> > to > >> >> > catch how all this is supposed to work together. > >> >> > > >> >> > > >> >> > nicolai > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >> > >> >> >> > >> >> >> Thanks > >> >> >> > >> >> >> > >> >> >> Paul > >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> >> > >> > http://forum.world.st/Using-GTSpotter-how-do-I-find-an-implementor-of-accep… > >> >> Sent from the Pharo Smalltalk Users mailing list archive at > >> Nabble.com. > >> >> > >> >> > >> > >> > >> > >> > >> > >> -- > >> View this message in context: > >> > http://forum.world.st/Using-GTSpotter-how-do-I-find-an-implementor-of-accep… > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > > -- > View this message in context: > http://forum.world.st/Using-GTSpotter-how-do-I-find-an-implementor-of-accep… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 11, 2015