Stef, we need to think about it carefullly. Streams are used in the
kernel for many tasks. Replacing them by a big framework will be a huge
drawback for bootstrapping purposes.
Alternatively, we could think of refactoring the kernel to not use
streams, but so far this is not possible... the kernel uses the compiler
and the code importer that depend on parsing streams...
We should plan :)
sure as always :)
On Sat, Jan 21, 2017 at 10:07 PM, stepharong <stephar...@free.fr> wrote:
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, p...@highoctane.be
<p...@highoctane.be> wrote:
There is also this
https://github.com/SquareBracketAssociates/PharoLimbo/tree/master/Xtreams
On Sat, 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
--Using Opera's mail client: http://www.opera.com/mail/
--
Using Opera's mail client: http://www.opera.com/mail/
