Tools for easy subtext extraction from text

In Ruby it is dead simple:
str[/\[(.*)\]/,1].hex # "=> 37" , or .to_i(16)

and dead unreadable

Pharo way is both dead simple and dead readable

str:= '       Temperature 0           37C (98F) [0x25] (TMPIN0)'.

('16r',(text copyWithRegex: '(.*\[0x)|(\].*)'  matchesReplacedWith: '')) asNumber . 

On Sat, Jan 21, 2017 at 02:01:59PM +0100, Denis Kudriashov wrote:
> Hi.
>
> 2017-01-20 16:15 GMT+01:00 Peter Uhnak <[hidden email]>:
>
> > 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

On Sat, Jan 21, 2017 at 07:09:19PM +0100, Denis Kudriashov wrote:
> 2017-01-21 17:09 GMT+01:00 [hidden email] <[hidden email]>:
>
> > 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

On Sat, Jan 21, 2017 at 02:01:59PM +0100, Denis Kudriashov wrote:
> Hi.
>
> 2017-01-20 16:15 GMT+01:00 Peter Uhnak <[hidden email]>:
>
> > 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

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.

Typing speed is pretty much the 1000th reason for a slow down, 1th is the ability to understand code, at least for me. 

Ruby is a more flexible and better designed language, but I would pick python any day over it which by the way beats even Pharo in readability because of its culture on how to write APIs. 

On the subject of your issue, this is no work around I offered, this is standard regex syntax. Exclusion and combination of matches. Nothing special. 

 I am using regex to parse python code, in pharo, for me at least Pharo regex API rocks. 

Yes I should finish to convert everything. 

I hope that in Pharo 70 we will be able add Xtream like library and remove the old stream

but this is large task.

stef

On Sat, 21 Jan 2017 21:06:34 +0100, [hidden email] <[hidden email]> wrote:

There is also this

https://github.com/SquareBracketAssociates/PharoLimbo/tree/master/Xtreams

On Sat, Jan 21, 2017 at 3:08 PM, Peter Uhnak <[hidden email]> 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 <[hidden email]>:
>
> > 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

--

Using Opera's mail client: http://www.opera.com/mail/