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

Re: [Pharo-users] Bug in Open Workspace from File-Browser?

by Cyril Ferlicot

If you want to open a workspace or a playground we should use: viewContentsInWorkspace "View the contents of my selected file in a new workspace" | aString | self reference streamWritable: false do: [ :stream | aString := stream setConverterForCode contentsOfEntireFile ]. Smalltalk tools workspace openContents: aString label: 'Workspace from ' , self reference basename BUT! If we open a file which is not a Smalltalk code the syntax coloring is really a bad idea. Someone know if we can desable the syntax coloring for an instance of the playground or workspace ? If we can't we should change the name on the menu and not the action of the menu. Thank. On 6 June 2015 at 16:37, volkert <volkert(a)komponentenwerkstatt.de> wrote: > Is this change resonable. I have no idea, what the Design-Idea behind the > UIManager what services is should provide. May be it make sense to have the > extra services on UIManager, but think the bug is in > FileList>>viewContentsInWorkspace and not in UIManager. > > ---- > I propose for Workspace to change the current code: > > FileList>>viewContentsInWorkspace > "View the contents of my selected file in a new workspace" > | aString | > self reference streamWritable: false do: [ :stream| > aString := stream setConverterForCode contentsOfEntireFile ]. > UIManager default edit: aString label: 'Workspace from ', self reference > basename <----- WRONG > > to : > > FileList>>viewContentsInWorkspace > "View the contents of my selected file in a new workspace" > | aString | > self reference streamWritable: false do: [ :stream| > aString := stream setConverterForCode contentsOfEntireFile ]. > Workspace openContents: aString label: 'Workspace from ', self reference > basename > > And i also proposse the add a Playground case. > > New Method: > > FileList>>viewContentsInPlayground > "View the contents of my selected file in a new playground" > | aString | > self reference streamWritable: false do: [ :stream| > aString := stream setConverterForCode contentsOfEntireFile ]. > GTPlayground openContents: aString label: 'Playground from ', self > reference basename. > > and also FileList>>serviceViewContentsInPlayground and the case in > ListList>>itemsForAnyFile. > > If ok, i can fix Workspace and add Playground menu to FileList, after i have > figured out how to send an fix ;-) > > BW, > Volkert > > > Am 03.06.2015 um 16:40 schrieb Ben Coman: > > Or do we now want such to open in Playground? > > btw, these are the relevant methods. > FileList>>FileList>>viewContentsInWorkspace > FileList>>viewContentsInWorkspace > > cheers -ben > > On Wed, Jun 3, 2015 at 6:57 PM, volkert <volkert(a)komponentenwerkstatt.de> > wrote: > > The File Browser has a Context Menu "Workspace with Contents". It opens an > Edit Window (String Morph), but not a Workspace ... > > Is the Menu-Title wrong or the implementation? > > BW, > Volkert > > -- Cheers Cyril Ferlicot

June 12, 2015

Re: [Pharo-users] Mac Squeak binary virtual machine for Squeak 3.10.2

by Trygve Reenskaug

I rest my case. --Trygve On 10.06.2015 20:57, Serge Stinckwich wrote: > If I remember correctly, it was easy to port Moose from VW to Pharo, > because there was a lot of tests. > I'm currently working on porting another software from VW to Pharo > without any tests and I'm suffering;-)

June 12, 2015

Re: [Pharo-users] Getting a user input string using Morphs

by Stephan Eggermont

On 09-06-15 20:10, Hilaire wrote: > I guess you tried with Pharo4.0. > I did with 3.0 It is a difference between Workspace and GTPlayground. In GTPlayground, ActiveEvent is nil, so it doesn't work. In Workspace it works. launchMiniEditor: evt | textMorph | hasFocus := true. "Really only means edit in progress for this morph" textMorph := StringMorphEditor new contentsAsIs: contents. textMorph beAllFont: self fontToUse. textMorph bounds: (self bounds expandBy: 0@2). self addMorphFront: textMorph. evt hand newKeyboardFocus: textMorph. textMorph editor selectFrom: 1 to: textMorph paragraph text string size replace evt hand by ActiveHand to make it work in GTPlayground. Stephan

June 12, 2015

Re: [Pharo-users] Minimal delay in Pharo...

by Thierry Goubier

Le 12/06/2015 04:08, Ben Coman a Ã©crit : > On Fri, Jun 12, 2015 at 1:00 AM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Hi all, >> >> anybody knows if, when doing something like: >> >> (Delay forMilliseconds: n) wait >> >> It is possible for the Delay to return immediately if n is small enough or >> do we have a guaranteed behavior of at least a 'yield' equivalent? > > For sufficiently small values of 'n', there will be no yield behaviour. > > To follow the logic (assuming timingPriority > pollingPriority > > userPriority)... > 1. Delay>>#wait calls DelayMicrosecondScheduler>>#schedule: (your > pollingPriority process) > 2. where "timingSemaphore signal" > 3. passes control to #runTimerEventLoop and #handleEventTimer: > (running in the timingPriority process) > 4. which invokes #scheduleDelay: to add your delay to /suspendedDelays/ > 5. back in #handleEventTimer: "Signal any expired delays" cycles > through /suspendedDelays/ such that if 'n' time has passed your > delay's delaySemaphore is immediately signalled, then > 6. control returns to #schedule: (your pollingPriority process) > 7. and thence to #wait: which does "delaySemaphore wait" -- but this > has already been signalled, so it zooms straight without any chance to > yield. > > If you want to ensure yield behaviour I would add the obvious... > Delay>>waitWithYield > self wait. > Processor yield. > > However for other sufficiently low values 'n2' (n2>n), not enough > lines of the userPriority process will be executed before your > pollingPriority process takes of, so the UI will effectively be locked > again. > > Perhaps what is needed is for your polling process to observe the > /lastCycleTime/ ivar set by WorldState>>interCyclePause: and > dynamically adjust your polling interval to keep lastCycleTime at a > reasonable value. Thanks Ben for the analysis. I suspected something like that could happen, and I'm happy to have the confirmation. Thierry

June 12, 2015

Re: [Pharo-users] Minimal delay in Pharo...

by Ben Coman

On Fri, Jun 12, 2015 at 1:00 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi all, > > anybody knows if, when doing something like: > > (Delay forMilliseconds: n) wait > > It is possible for the Delay to return immediately if n is small enough or > do we have a guaranteed behavior of at least a 'yield' equivalent? For sufficiently small values of 'n', there will be no yield behaviour. To follow the logic (assuming timingPriority > pollingPriority > userPriority)... 1. Delay>>#wait calls DelayMicrosecondScheduler>>#schedule: (your pollingPriority process) 2. where "timingSemaphore signal" 3. passes control to #runTimerEventLoop and #handleEventTimer: (running in the timingPriority process) 4. which invokes #scheduleDelay: to add your delay to /suspendedDelays/ 5. back in #handleEventTimer: "Signal any expired delays" cycles through /suspendedDelays/ such that if 'n' time has passed your delay's delaySemaphore is immediately signalled, then 6. control returns to #schedule: (your pollingPriority process) 7. and thence to #wait: which does "delaySemaphore wait" -- but this has already been signalled, so it zooms straight without any chance to yield. If you want to ensure yield behaviour I would add the obvious... Delay>>waitWithYield self wait. Processor yield. However for other sufficiently low values 'n2' (n2>n), not enough lines of the userPriority process will be executed before your pollingPriority process takes of, so the UI will effectively be locked again. Perhaps what is needed is for your polling process to observe the /lastCycleTime/ ivar set by WorldState>>interCyclePause: and dynamically adjust your polling interval to keep lastCycleTime at a reasonable value. cheers -ben > I'm looking into active polling for parallel stuff and I noticed that a busy > loop with Processor yield may result in more or less locking the vm since it > only gives scheduling to processes which have a higher or equal priority, so > this is why I'm looking into using Delay wait instead. But I'd like the > delay to be as short as possible for performance reason while allowing lower > priority processes a chance to run. > > Thanks, > > Thierry > >

June 12, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by Thierry Goubier

Hi Jose, I have pushed a new version of GitFileTree (the development version for Pharo4) with a complete rewrite of the underlying OSProcess use. Could you test to see if it solves your deadlocks? It should also be a tad faster. Regards, Thierry Le 03/06/2015 17:03, Jose San Leandro a Ã©crit : > Unfortunately it doesn't fix it, or at least I get the same sympthoms. >

June 11, 2015

Re: [Pharo-users] Styling UI using Spec

by Nicolai Hess

2015-06-11 13:23 GMT+02:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > 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). > I think spec does not support this. It could work (see example) but sadly the layout for creates non-translucent panels, and therefore you can not see between the controls: | ui layout | ui := DynamicComposableModel new. ui instantiateModels: #(#logo #ImageModel #input #TextInputFieldModel #label #LabelModel #button1 ButtonModel). ui label label: 'Label'. ui button1 label: 'Go'. ui logo image: PolymorphSystemSettings pharoLogoForm. layout := SpecLayout composed add: #logo top: 0 bottom: 1; newRow:[:c | c newColumn:[:r | r add: #label; add: #input; add: #button1] left:0.5] height:90; yourself. ui openWithSpecLayout: layout. see screenshot (PharoScreenshot.png) if the PanelMorphs are translucent, it would look like the second screenshot (PharoScreenshot.1.png) > > 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./ > What does not work in this example? > > > > -- > 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 Johan Brichau

Hi all, Sven, I think what many people need is to have a ZnClient subclass that follows the âbetter safe than sorryâ approach. In this way, there is an easy escape when someone bumps into a server that is not strictly implementing the standard. We bumped into this too with the + character when upgrading from an earlier version of Zinc. In particular, a lightweight Java http server we were communicating with was excepting the + character to be encoded in the path, although it should not. Just off the top of my head, this seems quite easy to do as all the abstractions are present in Zinc to achieve this, no? But I do support that Zinc is teaching us to behave according to the standard (although the standard is crap :) cheers, Johan > On 11 Jun 2015, at 00:56, Norbert Hartl <norbert(a)hartl.name> 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 <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] ZnClient and percent characters

by Johan Brichau

Hi, first off, I found this article a good read on the topic: http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-abou… <http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-abou…> > One thing which has not been looked at in this discussion is why Jimmie's first attempt to solve the problem failed. He replaced every comma in the query by its percent encoding, '%2C'. This failed because ZnClient replaced this by '%252C', i.e. it percent encoded the percent sign. In my first attempt to help him, I tried replacing the query line by: > queryAt: 'fields' put: 'displayName,instrument,pip' urlEncoded; > but this produced the same result. The puzzling thing is why ZnClient is doing this. This is because the #queryAt:put: method accept non-url-encoded strings. The application is not responsible for encoding the URL, Zinc is. How could I otherwise ever send a string with a percent character via a url ? > In http://www.w3.org/Addressing/URL/uri-spec.html it is stated that: > " The percent sign ("%", ASCII 25 hex) is used as the escape character in the encoding scheme and is never allowed for anything else." > Further on, there are two examples of strings which are illegal as URIs because they contain percent signs which are not followed by two decodable hex characters. Hence, if ZnClient encounters a percent sign in a query string, either it is the beginning of a percent encoded character or it is illegal. This is true when Zn is parsing a URL, not when itâs accepting parts to construct the URL (like when youâre using the #queryAt:put: methods). cheers Johan

June 11, 2015

Re: [Pharo-users] ZnClient and percent characters

by PBKResearch

Sven One thing which has not been looked at in this discussion is why Jimmie's first attempt to solve the problem failed. He replaced every comma in the query by its percent encoding, '%2C'. This failed because ZnClient replaced this by '%252C', i.e. it percent encoded the percent sign. In my first attempt to help him, I tried replacing the query line by: queryAt: 'fields' put: 'displayName,instrument,pip' urlEncoded; but this produced the same result. The puzzling thing is why ZnClient is doing this. In http://www.w3.org/Addressing/URL/uri-spec.html it is stated that: " The percent sign ("%", ASCII 25 hex) is used as the escape character in the encoding scheme and is never allowed for anything else." Further on, there are two examples of strings which are illegal as URIs because they contain percent signs which are not followed by two decodable hex characters. Hence, if ZnClient encounters a percent sign in a query string, either it is the beginning of a percent encoded character or it is illegal. In neither case is it right to percent encode the percent sign. Presumably the correct action for ZnClient is to examine the two characters following the percent sign and see if together they can be decoded to a legal character. Of course, if this were strictly enforced, it would still be possible for some perverse user to smuggle a percent sign through as part of a literal string by percent encoding it first - but this would not involve any illegality. On the other hand, anyone in Jimmie's position would be able to pre-encode a comma to %2C and have it accepted, while still allowing commas to be used where the site is happy with them. I may have misunderstood something, but anyway that's my 2p worth. Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 11 June 2015 15:49 To: Any question about pharo is welcome Subject: Re: [Pharo-users] ZnClient and percent characters Here is one older discussion that let to Zn going away from the better safe than sorry approach to encoding: http://forum.world.st/Zinc-How-to-use-the-character-in-an-URL-td4716386.htm… You have to read it up to the end. > On 11 Jun 2015, at 16:19, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > This is exactly why I expressly state I am not a language lawyer and explicitly do not know what is and is not expressly forbidden or allowed with regards to a comma. > > You are correct about the Wikipedia article. > > Is it every wrong or illegal to use a complete safely encoded request? Is it just simply not required? > So not fully encoded is still valid and legal and also the fully encode is also fully valid and legal. Yes, any server should accept all encodings. However, the following are different: http://foo.com/bar?x=1 http://foo.com/bar?x%3D1 In the second case, you take away the meaning of = by encoding it. So you just can't encode everything everywhere. > eg: > http://yourserver.com/path?options=eggs,toast,coffee > is fully valid and legal, but may encounter problems depending to whom the request is made and their implementation? > Encoding is not required but is at the discretion of the server implementation? > > http://yourserver.com/path?options=eggs%2Ctoast%2Ccoffee > is fully valid and legal and is always usable and will never encounter problems? > All valid server side implementations will handle this properly? > > Since I am sure that the API that I am writing for is probably not the only server implementation which requires the comma to be encoded. Actually, this is the first time I hear of a problem with , So, from that perspective, the server might be in error. > And regardless of legality of the use of comma it appears that some implementers are on the "to be safe we encode everything" side of things. It would be nice to have some option which allows us to encode all to be safe option. Yes, maybe such an option would be good, but only if it is really needed. > Thanks for listening and your help. > > Jimmie > > > > > On 06/11/2015 01:35 AM, Sven Van Caekenberghe wrote: >> @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-enco >>> ded 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-en >>>>> coded >>>>> >>>>> >>>>> 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