Hi Stephane,
I think there are few libraries, but I'm unsure how complete they are,
searching Github for Rust regex yields all possible candidates.
Here is the one that seems the most recent
https://github.com/ferristseng/regex-rust
Sincerely,
Daniel
On Thu, Mar 27, 2014 at 8:58 AM, Stephane
Thanks for your feedback, I was looking for a re lib with named group because I
wanted to implement a minimalist lexer.
I think I will implement my own lexer by hand without the regex.
Thanks
On 27 mars 2014, at 10:47 AM, Corey Richardson co...@octayn.net wrote:
There is a ton of
may be the wrong choice for lexers, but the most simple way to test
something in one hour. ;-)
I know that Rob Pike implemented the Lexer of Golang by hand.
Thanks for your feedback,
Stephane
On 27 Mar 2014, at 11:48, Daniel Fagnan wrote:
There is also http://www.rust-ci.org/cadencemarseille/rust-pcre which
provides a rust binding to pcre. It supports named groups (see
https://github.com/cadencemarseille/rust-pcre/blob/master/src/pcredemo/main.rs#L46-L57for
an example use).
On Thu, Mar 27, 2014 at 6:52 AM,
aside: Your last message didn't get CC'd to rust-dev. I've re-added them,
and hope dearly I haven't committed a social faux pas.
That's interesting. You're kinda looking for exception handling in rust!
Unfortunately the language seems pretty principled in its opinion that
failure should be
On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel cg.wowus...@gmail.com wrote:
aside: Your last message didn't get CC'd to rust-dev. I've re-added them,
and hope dearly I haven't committed a social faux pas.
That's interesting. You're kinda looking for exception handling in rust!
Unfortunately
On Thu, Mar 27, 2014 at 10:25 AM, Vladimir Lushnikov
vladi...@slate-project.org wrote:
We do really need a good parser generator for rust though...
Ragel has a Rust backend (not that I've used it)
--
Tony Arcieri
___
Rust-dev mailing list
[The following post has nothing to do with thread. I'm posting it here because
my new posts to this mailing list don't go through (this happens to me a lot).
Replies to existing posts tend to go through, thus I'm hijacking my own thread.]
Title: Compiling with no bounds checking for vectors?
Good luck at the meetup tonight, Tom. The last one I attended in PDX was
a lot of fun.
On 03/26/2014 12:01 PM, Tom Lee wrote:
Hey folks,
Per the subject, there's a Rust meetup in Portland, OR tomorrow night
from 6:30pm. Details here:
http://calagator.org/events/1250465822
I'm waiting on a
Why isn't there a compiler flag like 'noboundscheck' which would disable all
bounds checking for vectors? It would make it easier to have those language
performance benchmarks (which people are bound to make with no bounds
checking in C++ at least) be more apples-to-apples comparisons.
On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote:
Why isn't there a compiler flag like 'noboundscheck' which would disable all
bounds checking for vectors? It would make it easier to have those language
performance benchmarks (which people are bound to make with no bounds
I think your hypothetical situation of saving millions by disabling
bounds checks is absurd: To save $10 per machine, assuming $0.20 per
kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need
to be avoiding about 10^14 check. That's equivalent to avoiding 1
million bounds checks
I think the point is that the compiler should not be forcing people to
do things, but enabling people to do things, with sensible defaults.
Personally, whilst I would advocate MORE bounds checking in rust for
debugging / prototyping purposes, I don't think bounds checking is even
ideal. It's
Alternatively, in this future where people are deploying Rust
applications to hundreds of thousands of servers, we could be using
Intel's Memory Protection Extensions for much cheaper bounds checking
etc. Which surely other applications will be using once bounds checks
are nearly free. Rust will
It's not about debugging, it's about memory safety. It'd be ridiculous
to disable bounds checking just because you've done QA. How many
security exploits are over- or under-flows?
On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr...@gmail.com wrote:
I think the point is that the compiler should
a) I think Rust is making a mistake by considering boundary checks only
on memory accesses
b) No, it really wouldn't be ridiculous, if you've checked it properly
at a QA stage. By definition, it's ridiculous to KEEP checking it, once
it's already been checked thoroughly, as a proper QA
On Thu, Mar 27, 2014 at 4:51 PM, Lee Braiden leebr...@gmail.com wrote:
b) No, it really wouldn't be ridiculous, if you've checked it properly at
a QA stage. By definition, it's ridiculous to KEEP checking it, once it's
already been checked thoroughly, as a proper QA process would do.
I'm
On 27/03/14 07:16 PM, Lee Braiden wrote:
I think the point is that the compiler should not be forcing people to
do things, but enabling people to do things, with sensible defaults.
Personally, whilst I would advocate MORE bounds checking in rust for
debugging / prototyping purposes, I don't
On 27/03/14 04:42 PM, Tommi wrote:
A flag that removes safety is pretty antithical to the goals of the
language, IMHO.
Yes, I agree it's not the official Rust way of things. But not providing the
option seems quite totalitarian. An example use case might be a company that
runs its code
On 27/03/14 10:43 AM, Clark Gaebel wrote:
That's interesting. You're kinda looking for exception handling in rust!
Unfortunately the language seems pretty principled in its opinion that
failure should be handled at the task boundary exclusively, and this is
a pretty heavyweight opinion.
Compiling with that flag would figuratively speaking wrap everything inside an
unsafe block and then omit vector bounds checking. The flag wouldn't be allowed
for library builds.
What I find a bit totalitarian about this situation is that the language forces
a decision which the programmer
On 27/03/14 09:02 PM, Tommi Tissari wrote:
Compiling with that flag would figuratively speaking wrap everything inside
an unsafe block and then omit vector bounds checking. The flag wouldn't be
allowed for library builds.
What I find a bit totalitarian about this situation is that the
Hi.
I have very exciting news. Rust now has binary installers for Linux and
Mac, as well as nightly builds for Windows, Linux and Mac.
Official Rust installers now come in the following forms:
* source .tar.gz - the same old source tarball
* binary .tar.gz - Generic Unix installers,
Oh, ok, well in that case I suppose the flag should cause all indexing
operations to become their unsafe variants instead, all functions that call
those to become unsafe, etc. propagating the unsafety where it's needed to make
the code compile.
On 28 Mar 2014, at 03:15, Daniel Micay
On Thu, Mar 27, 2014 at 6:25 PM, Brian Anderson bander...@mozilla.com wrote:
I have very exciting news. Rust now has binary installers for Linux and Mac,
as well as nightly builds for Windows, Linux and Mac.
I am unclear what Windows is missing that it's in your nightly
builds list but not your
Hello!
@Clark: I must've hit reply instead of reply-all, thanks for re-adding
rust-dev.
I'm not sure I agree about the fail! thing. I think crashing a task on an
unexpected condition is easier to code and to reason about. It forces me to
think about recovery and atomicity. Also even if I
That's right. I didn't mention it because nothing has changed (yet) in
the windows installers. Sorry for the confusion.
On 03/27/2014 06:59 PM, Matthew McPherrin wrote:
On Thu, Mar 27, 2014 at 6:25 PM, Brian Anderson bander...@mozilla.com wrote:
I have very exciting news. Rust now has binary
Opting in case by case is not the same thing as having a compiler flag which
you can toggle without modifying the source.
Perhaps bounds checking is the only safety measure which has runtime penalty?
(Not sure about that) But that would explain why it would be a separate flag.
By the way, D
On 27/03/14 10:04 PM, Tommi Tissari wrote:
Opting in case by case is not the same thing as having a compiler flag which
you can toggle without modifying the source.
A case-by-case basis preserves the safety guarantees of the language and
doesn't introduce a new dialect. It also means you can
On 03/27/2014 10:04 PM, Tommi Tissari wrote:
By the way, D is memory safe (although it's opt-in) and it has this
noboundscheck flag. So I don't see what the problem is.
Rust takes a very different stance to safety than to D (e.g. making it
safe by default). In the D community my perception
On 28 Mar 2014, at 03:41, Jeffery Olson olson.jeff...@gmail.com wrote:
forces a decision which the programmer should be allowed to make for
himself. A bit like someone dictating my hair style.
Yes. Rust is just like hair salon that forbids you from setting your own hair
on fire.
If you want sharp scissors, use unsafe indexing. You generally don't need
it everywhere, just in your inner loop.
Profile, then optimize. Rust gives you the tools needed to optimize where
things get hot, but we also like safety by default.
- Clark
On Thu, Mar 27, 2014 at 10:31 PM, Tommi
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him. While I'm trying to argue that
the programmer should be *free* to test how fast his code would run without
bounds checking, just for the hell of it. You want to enforce
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity. This
is clear in the design of lifetimes. For example,
On 3/27/14 1:42 PM, Tommi wrote:
On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote:
Why isn't there a compiler flag like 'noboundscheck' which would disable all
bounds checking for vectors? It would make it easier to have those language
performance benchmarks (which people
I'd like to point out that I agree with your central premise that most
bounds checks are useless. Some huge percentage of them, in fact.
But I still enjoy the peace of mind that they bring. If I actually need a
piece of code to be manually checked, covered in tests, and benchmarked to
be fast,
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
Can we please not recommend people pipe random text from across the
internet into a fricking *root shell*?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Oh hush at least it's https.
...oh wait. :(
On Fri, Mar 28, 2014 at 12:05 AM, György Andrasek jur...@gmail.com wrote:
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
Can we please not recommend people pipe random text from across the
internet into a fricking *root shell*?
On 03/27/2014 09:05 PM, György Andrasek wrote:
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
Can we please not recommend people pipe random text from across the
internet into a fricking *root shell*?
Yes. In fact my original email said exactly that.
On 28/03/14 12:05 AM, György Andrasek wrote:
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
Can we please not recommend people pipe random text from across the
internet into a fricking *root shell*?
The snapshot binaries aren't signed, and they're downloaded via http.
Only the releases
On Fri, Mar 28, 2014 at 12:05 AM, György Andrasek jur...@gmail.com wrote:
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
Can we please not recommend people pipe random text from across the
internet into a fricking *root shell*?
But it's okay for Windows/Mac users to download random
I'm thinking about putting together a server that acts similar to
play.golang.org - it allows you to learn rust from the comfort of your own
browser.
Of course, there are some restrictions that must be placed on compilation.
Is there a good way to blacklist some standard libraries?
Daniel Micay (strcat) already has a sandbox. It drives the rusti bot
in IRC, and has a web frontend sometimes available at
http://strcat.zapto.org:8000/. The source is at
https://github.com/thestinger/rust-playpen. There are plans to have a
VM run a similar thing on rust-lang.org
On Fri, Mar 28,
On 27/03/14 11:56 PM, Clark Gaebel wrote:
I'd like to point out that I agree with your central premise that most
bounds checks are useless. Some huge percentage of them, in fact.
In my opinion, this isn't necessarily true for Rust. Iterators provide a
lot of functionality without the overhead
On 28/03/14 01:15 AM, Corey Richardson wrote:
Daniel Micay (strcat) already has a sandbox. It drives the rusti bot
in IRC, and has a web frontend sometimes available at
http://strcat.zapto.org:8000/. The source is at
https://github.com/thestinger/rust-playpen. There are plans to have a
VM run
Depending on your server setup, this might be a great place for a cheap
docker container. You get fairly safe sandboxing for cheap.
On Thu, Mar 27, 2014 at 11:21 PM, Daniel Micay danielmi...@gmail.comwrote:
On 28/03/14 01:15 AM, Corey Richardson wrote:
Daniel Micay (strcat) already has a
On Fri, Mar 28, 2014 at 1:28 AM, Jared Forsyth jabap...@gmail.com wrote:
Depending on your server setup, this might be a great place for a cheap
docker container. You get fairly safe sandboxing for cheap.
Fairly safe is not really all that safe.
I'm not sure it really matters, but I'd go for
47 matches
Mail list logo
