- Pharo-users - lists.pharo.org

Re: [Pharo-users] If comments seperate from the source code and have your own comments

by lb

At 2015-06-13 23:02:16, "lb" <liangbing64(a)126.com> wrote: Hi, I know the comment is very important for reading source code and it is also important to write your own comment after understand somethings. I created a rough annotation application----AnnoApp for Nautilus, please give me good advice to improve it. Attached are the monticello files. Thank you in advance! Liang PS I love Smalltalk and I love Pharo.

June 13, 2015

Re: [Pharo-users] If comments seperate from the source code and have your own comments

by lb

At 2015-06-13 23:02:16, "lb" <liangbing64(a)126.com> wrote: Hi, I know the comment is very important for reading source code and it is also important to write your own comment after understand somethings. I created a rough annotation application----AnnoApp for Nautilus, please give me good advice to improve it. Attached are the monticello files. Thank you in advance! Liang PS I love Smalltalk and I love Pharo.

June 13, 2015

If comments seperate from the source code and have your own comments

by lb

Hi, I know the comment is very important for reading source code and it is also important to write your own comment after understand somethings. I created a rough annotation application----AnnoApp for Nautilus, please give me good advice to improve it. Attached are the monticello files. Thank you in advance! Liang PS I love Smalltalk and I love Pharo.

June 13, 2015

Re: [Pharo-users] HTML Parser w. custom nodes

by Sean P. DeNigris

Peter Kenny wrote > allows the specification of a node factory to provide custom handling of > nodes Sound like exactly what I had in mind! Although, now that I've played with it, I realize that most of the web scraping use cases that I've encountered seem like they could really benefit from a PetitParser style tool, where one could specify the output for each rule (e.g. `dataRowRule ==> [ "code translating the node/element into a domain object" ]`, and so parse the markup directly to domain objects... ----- Cheers, Sean -- View this message in context: http://forum.world.st/HTML-Parser-w-custom-nodes-tp4832169p4832257.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 13, 2015

storeOn: and literal limits

by Sean P. DeNigris

Does anything exist to handle uses of #storeOn: that bump into the literal limit? E.g. that splits the offending constructor method into several methods? Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/storeOn-and-literal-limits-tp4832255.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 13, 2015

Re: [Pharo-users] HTML Parser w. custom nodes

by PBKResearch

Sean XMLHTMLParser is a subclass of XMLDOMParser, which allows the specification of a node factory to provide custom handling of nodes. Depending on what you want to achieve, this might help. Best wishes Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sean P. DeNigris Sent: 12 June 2015 23:45 To: pharo-users(a)lists.pharo.org Subject: [Pharo-users] HTML Parser w. custom nodes Now that we have the cool new Catalog Browser, I see we have at least 4 HTML parsing options - cool! Do any of these allow one to inject custom node classes? Kind of like Zincs converter support, but for individual nodes. When using Soup, I've often thought something like, "gee I wish I could have told it that a tr with a certain background color was really a ProjectDescriptionRow!". It seems clunky to have to parse it once, and then query it again (usually procedurally) to make domain sense of the data, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/HTML-Parser-w-custom-nodes-tp4832169.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 13, 2015

Re: [Pharo-users] Use array of float to GPU memory

by Ronie Salgado

> > sounds interesting, but what is the context of this? Is this built > into Pharo, what version? Or what library? Those methods are not built into Pharo. They are present in the OpenCL bindings ( http://smalltalkhub.com/#!/~ronsaldo/OpenCL ), and I don't think they are very efficient in my opinion. See my answer to the original question for more information. Greetings, Ronie 2015-06-12 22:22 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > On Fri, Jun 12, 2015 at 10:38 PM, cheikhou <cheikhouka(a)gmail.com> wrote: > > > > Finally I have found a useful method called "asCLFloatArray" that > converts > > float arrays of CPU as CL float arrays of GPU. The reverse action is > > possible by using "asFloatArrayFromCL".(from GPU to CPU memory) > > sounds interesting, but what is the context of this? Is this built > into Pharo, what version? Or what library? > cheers -ben > >

June 13, 2015

Re: [Pharo-users] Copy array of float to GPU memory

by Ronie Salgado

Hi Cheikhou, Sorry for the late answering. I needed to check some stuffs. But the problem is it works only with ByteArray objects. > When I load array of floats to GPU , data are modify and I don't know how > and why and results are wrong. What kind of error are you getting? a NativeBoost error or incorrect results? Since you were originally asking me about FloatArray or IntegerArray, I am assuming you are getting incorrect results or a segmentation fault. The OpenCL package is just a binding with a bit of object orientation to the OpenCL C library that I wrote manually. Those binding don't try to do a lot of magic when receiving a Pharo object. The OpenCL C API when allocating a GPU side buffer is expecting a size in bytes. According to the class comment in IntegerArray and in FloatArray, they are composed of 32 bits elements. So, when passing their size to OpenCL, you have to multiply them by 4. For an actual example, check the new tests that I just added to the OpenCL-Tests packages. I tried using IntegerArray and FloatArray, and it did work. It seems that you found the asCLFloatArray and the asFloatArrayFromCL methods, that are used to convert from an Array into a ByteArray and backwards. For completeness, I just added the following new methods. asCLInt16Array <-> asInt16ArrayFromCL asCLInt32Array <-> asInt32ArrayFromCL asCLInt64Array <-> asInt64ArrayFromCL asCLUInt16Array <-> asUInt16ArrayFromCL asCLUInt32Array <-> asUInt32ArrayFromCL asCLUInt64Array <-> asUInt64ArrayFromCL asCLDoubleArray <-> asDoubleArrayFromCL Unlike passing an IntegerArray or a FloatArray, these are method are creating a new array, looping over all elements and doing marshalling/unmarshalling. These methods can be very inefficient. Be careful when using them. Best regards, Ronie Salgado 2015-06-12 8:09 GMT-03:00 cheikhou <cheikhouka(a)gmail.com>: > Hello. > > I use OpenCL package developed by Ronie Salgado package to program on GPU. > When I initialize an array with ByteArray class and load data to GPU memory > it works without any problem. > > But the problem is it works only with ByteArray objects. > When I load array of floats to GPU , data are modify and I don't know how > and why and results are wrong. > > Please someone have any idea > First: how to load integer values upper than 255 (not possible with > ByteArray) > Second: use float arrays correctly in GPU memory. > > Thanks for your help. > > > > ----- > Cheikhou > -- > View this message in context: > http://forum.world.st/Copy-array-of-float-to-GPU-memory-tp4831970.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 13, 2015

Re: [Pharo-users] Use array of float to GPU memory

by Ben Coman

On Fri, Jun 12, 2015 at 10:38 PM, cheikhou <cheikhouka(a)gmail.com> wrote: > > Finally I have found a useful method called "asCLFloatArray" that converts > float arrays of CPU as CL float arrays of GPU. The reverse action is > possible by using "asFloatArrayFromCL".(from GPU to CPU memory) sounds interesting, but what is the context of this? Is this built into Pharo, what version? Or what library? cheers -ben

June 13, 2015

Re: [Pharo-users] ZnClient and percent characters

by PBKResearch

Norbert I agree. I was angry and went over the top â sorry. Letâs consider it closed. Peter From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Norbert Hartl Sent: 12 June 2015 12:18 To: Pharo users users Subject: Re: [Pharo-users] ZnClient and percent characters Am 12.06.2015 um 12:03 schrieb PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> >: Norbert Some comments on your latest post below. I just wrote because you told Jimmie to alter a method of a third-party library. And that is a no-go. Zinc, like almost all of Pharo, is MIT licenced, âincluding without limitation the rights to use, copy, modify, merge, publishâ¦â Once the code is on my machine, I am entitled to alter it for my own use in any way I see fit; so is Jimmie. It is clear from Svenâs comments that not encoding commas is a design decision, and a departure from earlier Zinc working. Sven himself says â maybe we made a mistake, maybe not.â I am entitled to disagree with that decision, and to act on that disagreement; so is Jimmie. I just told him how to do it quickly and safely. So, the misunderstanding is because we seem to have different views on the topic. I have always projects in mind that are built together by a build system and they produce something deployable. Your proposal doesn't fit in this view for me. If you alter a third-party function you need to make that a repeatable task which is having an expression to patch the third-party library again if you build the project again. The way to change it and have Sven it commited is doable. Obviously it would be ideal if Sven made a change which allowed encoding of commas. However, that does not seem likely to happen any time soon. Meanwhile, Jimmie was stuck with a program which would not carry out a function that should be quite normal. As is my proposal that you can change the code in a reliable way without changing a third-party library. That's all I wanted to say. No doubt your subclassing approach would work, though not as easily as you imply. The method that encodes the key-value pairs of a query is not #encodeQuery:on:, it is #printQueryOn: (see ZnUrl>>#printPathQueryFragmentOn:); changing that would involve having variant versions of ZnResourceMetaUtils>>#writeQueryFields:on: and >>writeQueryFields:withEncoder:on:, as well as a new safe list. Yes, but it is still the thing you can do immediately without having to patch code that is not under your control. That's my whole point. I wouldn't consider my approach good or even nice. And yes I think it applies to monkey patching. Choosing weaker terms just to avoid problems is not the way to go IMHO. I was not asking for a weaker term, I was asking for a less offensive one. I think this term is offensive in all contexts, and should not be used. Henryâs comment implies that it is widely used, and everyone knows what it means. In my youth, 60-70 years ago, the n-word was widely used to refer to people of African origin, and everyone knew what it meant. Now, thank goodness, we see how offensive it was. To me, this expression is equally offensive. You used it, in a derogatory sense, to criticise what I had done in helping Jimmie. Frankly, I do not think you were sincere in saying âNo offense meant.â I like the term monkey patching because it is as funny as it might be offensive. The rest I don't want to comment because I could easily be offended by your paragraph aboveâ¦if I only had those kinds of sensitivities. And btw. don't hide behind something like not using a certain word. You can still be a racist without using the n-word. What is needed is to change attitude not words. I had thought of just ignoring your comment, thinking that we will have to agree to differ. However, your reiteration of the m-word has got me sufficiently riled to make another protest. I may be a lone voice here, but that does not make my views any less valid. dito. Let's close this case. To me it is a little misunderstanding that took the wrong route. Norbert Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Norbert Hartl Sent: 11 June 2015 17:07 To: Pharo users users Subject: Re: [Pharo-users] ZnClient and percent characters Am 11.06.2015 um 16:51 schrieb PBKResearch < <mailto:peter@pbkresearch.co.uk> peter(a)pbkresearch.co.uk>: Norbert Apology accepted â I had never heard this term before. However, having read the Wikipedia article Henry mentioned, I do not think it applies to what I had done. If Sven accepts the argument that commas should always be encoded in query lines â and I can see a strong argument for that from what I have read â then the change I made is just what he will need to do. I simply anticipated the decision. If it goes the other way, then it was just a hack to solve Jimmieâs problem â but it might be better to say âhackâ rather than use a term which is potentially offensive. I just wrote because you told Jimmie to alter a method of a third-party library. And that is a no-go. The way to change it and have Sven it commited is doable. As is my proposal that you can change the code in a reliable way without changing a third-party library. That's all I wanted to say. And yes I think it applies to monkey patching. Choosing weaker terms just to avoid problems is not the way to go IMHO. I also note Jimmieâs argument that, as long as there are some sites which insist on encoded commas, it must be possible to generate such lines if Zinc is to be generally useful. Whether this should be a user-controlled option, as Sven seems to suggest, is open to discussion â but if so I would argue for encoding of commas as the safe default, which can be overridden if necessary. Sure. Zinc should behave correctly and it should provide functionalities to make it "less correct". And these functionalities shouldn't be too easy to use ;) Norbert 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: 11 June 2015 11:25 To: Pharo users users Subject: Re: [Pharo-users] ZnClient and percent characters 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 < <mailto:peter@pbkresearch.co.uk> 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 < <mailto:peter@pbkresearch.co.uk> peter(a)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 < <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 13, 2015