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.uh...@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.uh...@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."
