January 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Tools for easy subtext extraction from text

by Peter Uhnak

On Sat, Jan 21, 2017 at 07:09:19PM +0100, Denis Kudriashov wrote: > 2017-01-21 17:09 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > > I collected some content about that and wanted to do something about it > > but, yeah, it got on the backburner. > > > > This is currently just the extract of the package comment or something > > like that. > > > > https://github.com/philippeback/xstreamsdoc > > > > And look here: > > https://github.com/mkobetic/Xtreams Ah, the wiki has several pages. I just saw the welcome page and uninformative readme. > https://code.google.com/archive/p/xtreams/wikis Thanks! Peter

Jan. 21, 2017

Re: [Pharo-users] super super

by Peter Uhnak

Out of curiosity, wouldn't it be better to temporarily duplicate the code in your class and talk with the upstream owner? (That would be my usual approach.) Peter On Sat, Jan 21, 2017 at 06:04:12PM +0100, Hilaire wrote: > Agree on the hook. However the super class are not mine. Not an ideal > situation > > Le 21/01/2017 Ã 11:19, stepharong a Ã©crit : > > No and I'm happy that this is like that. > > I think that it means that you need to create special hooks in the super > > superclass. > > -- > Dr. Geo > http://drgeo.eu > >

Jan. 21, 2017

Re: [Pharo-users] Tools for easy subtext extraction from text

by Denis Kudriashov

2017-01-21 17:09 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > I collected some content about that and wanted to do something about it > but, yeah, it got on the backburner. > > This is currently just the extract of the package comment or something > like that. > > https://github.com/philippeback/xstreamsdoc > And look here: https://github.com/mkobetic/Xtreams https://code.google.com/archive/p/xtreams/wikis

Jan. 21, 2017

Re: [Pharo-users] Tools for easy subtext extraction from text

by Tudor Girba

I use PetitParser for this purpose. It provides: - an incremental way to build a parser especially when you use its bounded sea abilities, - a way to debug problems, and - a reasonably readable outcome that can be extended to a more complicated parser. For example, in your case, you can use: string := 'Temperature 0 37C (98F) [0x25] (TMPIN0)'. (('[' asPParser, ']' asPParser negate star flatten, ']' asPParser ==> #second) sea ==> #second) parse: string Cheers, Doru > On Jan 21, 2017, at 3:08 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Sat, Jan 21, 2017 at 02:01:59PM +0100, Denis Kudriashov wrote: >> Hi. >> >> 2017-01-20 16:15 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: >> >>> In Ruby it is dead simple: >>> str[/\[(.*)\]/,1].hex # "=> 37" >>> >> >> I always wondering when people think it is dead simple. >> I use streams for such cases. It is logical, readable and dead simple > > I've never mentioned readability, because the code is throwaway. > I guess if you are not using regexes it could look odd, but as a linux user it is very casual; if I had to extract the information I would just pipe it through sed or grep. > > I wouldn't use such thing in code that I want to keep, but I explicitly mentioned that. > > >> approach without crappy syntax. And with Xtreams library it become much >> more easy and fun > > Are there any docs for Xtreams? I found several repositories, but none explain what Xtreams even is. > > --- > >> >>> In Ruby it is dead simple: >>> >> >> and dead unreadable >> >> Pharo way is both dead simple and dead readable > > Dtto as above. Readability was never a question. And if it was, then you just doubled the regex complexity, and made the code more confusing by turning the problem upside down, due to the limited API. > > Complaining about the compact syntax makes as much sense as complaining that `1+2` is too cryptic and should be written as `1 digitAdd: 2` (which you can do btw); the point of compactness is that when you know what you are doing you can save some time. > > You can always write .match() instead of []; e.g. in python: > > int(re.split('\[(.*)\]', str)[1], 16) > int(re.search('\[(.*)\]', str).group(1), 16) > > But my point was not addressing this particular problem, but the general problem --- I often find it much easier to preprocess data with standard linux tools and then feed it to Pharo then to try to do the same in Pharo itself. > > Peter > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Jan. 21, 2017

Re: [Pharo-users] is PetitParser eager by default?

by Tudor Girba

Hi, The inspector shows the PPFailure, and the Debug View presentation of PPFailure shows you the paths the parser tried. star produces a PPPossessiveRepeatingParser, and selecting it shows that it matched all three characters: they are selected in the bottom pane which shows the input string. Cheers, Doru > On Jan 21, 2017, at 11:26 AM, stepharong <stepharong(a)free.fr> wrote: > > Hi doru > > where do we see it? > > > Stef > > On Fri, 20 Jan 2017 16:57:51 +0100, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > When you have questions like these, you can also use the built-in debugging facilities. For example, in your case, you can see that the #any parser consumed everything like this: > > <Mail Attachment.png> > > Cheers, > Doru > > >> On Jan 20, 2017, at 4:38 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >>> Am 20.01.2017 um 15:24 schrieb Peter Uhnak <i.uhnak(a)gmail.com>: >>> >>> Is PetitParser eager by default? >>> >>> I've used PetitParser countless times so I am really baffled why this doesn't work >>> >>> str := 'a0b'. >>> #any asParser star, #digit asParser, #any asParser star parse: str. >>> >>> -> PPFailure (input expected at: 3) >>> >> >> PetitParser is not greedy per default. But back tracking only works if a parser fails. Using , creates a sequence of combined parsers. If one fails the whole sequence fails. As a star parser always succeeds it would be huge luck if your rule would succeed. The probability that the parser consumes exactly one character is not high. Maybe negating the first sequence part is what you want >> >> Norbert >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ -- www.tudorgirba.com www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."

Jan. 21, 2017

Re: [Pharo-users] super super

by Hilaire

Yep, it is the first situation I face where I need it in 10 years of Smalltalk/Pharo. Otherwise I will refactor super class package, may be I should Le 21/01/2017 Ã 11:19, stepharong a Ã©crit : > pay attention and to not use it. It is evil to use that in plain domain > code. -- Dr. Geo http://drgeo.eu

Jan. 21, 2017

Re: [Pharo-users] super super

by Hilaire

Agree on the hook. However the super class are not mine. Not an ideal situation Le 21/01/2017 Ã 11:19, stepharong a Ã©crit : > No and I'm happy that this is like that. > I think that it means that you need to create special hooks in the super > superclass. -- Dr. Geo http://drgeo.eu

Jan. 21, 2017

Re: [Pharo-users] Tools for easy subtext extraction from text

by phil＠highoctane.be

I collected some content about that and wanted to do something about it but, yeah, it got on the backburner. This is currently just the extract of the package comment or something like that. https://github.com/philippeback/xstreamsdoc Phil On Sat, Jan 21, 2017 at 3:08 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Sat, Jan 21, 2017 at 02:01:59PM +0100, Denis Kudriashov wrote: > > Hi. > > > > 2017-01-20 16:15 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > > > In Ruby it is dead simple: > > > str[/\[(.*)\]/,1].hex # "=> 37" > > > > > > > I always wondering when people think it is dead simple. > > I use streams for such cases. It is logical, readable and dead simple > > I've never mentioned readability, because the code is throwaway. > I guess if you are not using regexes it could look odd, but as a linux > user it is very casual; if I had to extract the information I would just > pipe it through sed or grep. > > I wouldn't use such thing in code that I want to keep, but I explicitly > mentioned that. > > > > approach without crappy syntax. And with Xtreams library it become much > > more easy and fun > > Are there any docs for Xtreams? I found several repositories, but none > explain what Xtreams even is. > > --- > > > > >> In Ruby it is dead simple: > >> > > > > and dead unreadable > > > > Pharo way is both dead simple and dead readable > > Dtto as above. Readability was never a question. And if it was, then you > just doubled the regex complexity, and made the code more confusing by > turning the problem upside down, due to the limited API. > > Complaining about the compact syntax makes as much sense as complaining > that `1+2` is too cryptic and should be written as `1 digitAdd: 2` (which > you can do btw); the point of compactness is that when you know what you > are doing you can save some time. > > You can always write .match() instead of []; e.g. in python: > > int(re.split('\[(.*)\]', str)[1], 16) > int(re.search('\[(.*)\]', str).group(1), 16) > > But my point was not addressing this particular problem, but the general > problem --- I often find it much easier to preprocess data with standard > linux tools and then feed it to Pharo then to try to do the same in Pharo > itself. > > Peter > > >

Jan. 21, 2017

Re: [Pharo-users] [Seaside] Bad Request ZnEntityTooLarge

by Ben Coman

On Sat, Jan 21, 2017 at 1:22 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Hi Johan, > > Thank you for your detailed answer. See below. > > Am 20.01.2017 um 10:12 schrieb Johan Brichau <johan(a)inceptive.be>: > > > > imho, itâs better practice to detect too large file upload in your app > on the client side, i.e. before your user has been uploading xxx MB. For > that, you can check out various client-side programs like jQuery-FileUpload > (https://blueimp.github.io/jQuery-File-Upload/) > Thanks for the pointer. I will look into adding somthing like this on the > client side. Someone mentioned using Dropzone.js from Seaside. I had > searched stackoverflow for limiting upload file size and found some helpful > tips: > http://stackoverflow.com/questions/11514166/check-file-size-before-upload > > However, I also found warnings like these: > âKeep in mind that even if it's now possible to validate on the client, > you should still validate it on the server, though. All client side > validations can be bypassed.â > âOf course, this â¦ can be tampered with so always use server side > validation.â > > This is why I wanted to find a user-friendly way to prevent this from my > server code. Are you saying, this is not necessary in your opinion? > > In general I'd say... If someone is smart-enough and wicked enough to bypass your client side checks, you don't need to be user-friendly to them. The server checks are more to protect your server from them. cheers -ben

Jan. 21, 2017

Re: [Pharo-users] Tools for easy subtext extraction from text

by Peter Uhnak

On Sat, Jan 21, 2017 at 02:01:59PM +0100, Denis Kudriashov wrote: > Hi. > > 2017-01-20 16:15 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > In Ruby it is dead simple: > > str[/\[(.*)\]/,1].hex # "=> 37" > > > > I always wondering when people think it is dead simple. > I use streams for such cases. It is logical, readable and dead simple I've never mentioned readability, because the code is throwaway. I guess if you are not using regexes it could look odd, but as a linux user it is very casual; if I had to extract the information I would just pipe it through sed or grep. I wouldn't use such thing in code that I want to keep, but I explicitly mentioned that. > approach without crappy syntax. And with Xtreams library it become much > more easy and fun Are there any docs for Xtreams? I found several repositories, but none explain what Xtreams even is. --- > >> In Ruby it is dead simple: >> > > and dead unreadable > > Pharo way is both dead simple and dead readable Dtto as above. Readability was never a question. And if it was, then you just doubled the regex complexity, and made the code more confusing by turning the problem upside down, due to the limited API. Complaining about the compact syntax makes as much sense as complaining that `1+2` is too cryptic and should be written as `1 digitAdd: 2` (which you can do btw); the point of compactness is that when you know what you are doing you can save some time. You can always write .match() instead of []; e.g. in python: int(re.split('\[(.*)\]', str)[1], 16) int(re.search('\[(.*)\]', str).group(1), 16) But my point was not addressing this particular problem, but the general problem --- I often find it much easier to preprocess data with standard linux tools and then feed it to Pharo then to try to do the same in Pharo itself. Peter

Jan. 21, 2017