[rust-dev] Minimal raytracer

[John Mija]

Since a post in HN about a raytracer into a business card, a guy built 
the implementation in Go:


https://groups.google.com/forum/#!topic/golang-nuts/mxYzHQSV3rw

The C++ version: https://gist.github.com/kid0m4n/6680629
The Go version: https://github.com/kid0m4n/gorays

Performance (2.2 Ghz Quad Core (2675QM), 16 GB RAM, OX 10.9, Go 1.1.2):

C++ version: 11.803 s
Go version: 28.883 s

* * *
It would be interesting if somebody with experience in Rust could build 
the version in Rust to compare the speed.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Windows Users can build Rust properly again !

[Thad Guidry]

So, in my experiments tonight...

I had to have the following copied into stage0/bin in order to build with
mingw32 (gcc 4.8.1)

Older libstdc++-6.dll which I got from here:
http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.6.2-1/libstdc%2B%2B-4.6.2-1-mingw32-dll-6.tar.lzma/download

AND

libpthread-2.dll (which I created by copying & renaming pthreadGC2.dll )
... and now it builds just fine with i686-pc-mingw-32.

I also agree with klutzy that we should bundle them for now.  (and will
enjoy getting a Clang build version to work from stage0 + whenever we can
muster that origami)



On Fri, Sep 20, 2013 at 12:49 AM, klutzy  wrote:

> > I wonder if we should just bundle runtime libraries with the stage0
> snapshot in the future?
>
> I think we should bundle them: https://github.com/mozilla/rust/issues/9252
>
> On Thu, Sep 19, 2013 at 7:16 AM, Vadim  wrote:
> > Okay, looks like my mingw 4 fix went in last night.
> >
> > Here's my personal recipe for setting up mingw:
> > 1. Download and install mingw-get
> > 2. Install the required packages.  One can do this in GUI, but I prefer
> the
> > command line, as it's less ambiguous:
> >  mingw-get install mingw-developer-toolkit
> >  mingw-get install mingw32-base
> >  mingw-get install mingw32-gcc-g++
> >  mingw-get install mingw32-libpthreadgc
> >  mingw-get install msys-wget
> > 3. Install GIT and Python, make sure they are on the PATH
> > 4. In MSYS shell:  ../configure; make check-fast
> >
> > Until stage0 snapshot compiler has been rebuilt with new mingw, stage0
> > compilation will fail because latest mingw has wrong versions of the
> runtime
> > libraries that rustc depends on.  So:
> > 5.. Get old versions of these dlls:
> > mingw-get upgrade "g++<4.6"
> > mingw-get upgrade "libpthread=2.8.0-3"
> > 6.. Copy libgcc_s_dw2-1.dll, libstdc++-6.dll and libpthread-2.dll from
> > %mingw%\bin into %build%\i686-pc-mingw32\stage0\bin.
> > 7. Roll mingw back to the latest:
> > mingw-get upgrade
> > 8.. make check-fast
> >
> > I wonder if we should just bundle runtime libraries with the stage0
> snapshot
> > in the future?
> >
> > Vadim
> >
> >
> > On Mon, Sep 16, 2013 at 6:33 PM, Alex Crichton 
> > wrote:
> >>
> >> Hey guys, so we're gonna hold off on upgrading the windows builders
> until
> >> we're 100% sure that we won't bork them with a mingw upgrade. What I
> think
> >> that we can do, on the other hand, is:
> >>
> >> 1. Land Vadim's patch onto master
> >> 2. I spin up a clean windows vm (need to do that anyway)
> >> 3. Could you guys send me a list of instructions to build rust on "the
> >> most recent" mingw?
> >> 4. Once verified, and possible bugs fixed, we can go upgrade the
> builders
> >> and documentation about mingw
> >>
> >> Ideally the "build instructions" would be:
> >>
> >> A. Acquire mingw.
> >> B. Acquire relevant gcc version 4.X
> >> C. ./configure && make
> >>
> >> It'd be awesome to keep it that simple, and it seems that your patches
> >> would have eliminated the need for patching system files?
> >>
> >> How does that sound to you guys?
> >>
> >> On Sep 16, 2013, at 6:20 PM, Vadim  wrote:
> >>
> >
>



-- 
-Thad
Thad on Freebase.com 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Syntax for "raw" string literals

[Steven Ashley]

I also forgot to mention the possibility of putting a filename as the eos
string. I think its kind of neat.

r##index.html##"

 ...

"##index.html##
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Syntax for "raw" string literals

[Steven Ashley]

I'm a fan of always having the r prefix. Its more consistent and it leaves
#foo available for another language feature if required. Otherwise I like
it.

I've tweaked the regex I posted slightly to ensure that the # tokens are
well balanced. See it on regexpal [1].

[rR](#*)([^#"]*|#)\1"(.*?)"\1\2\1

The following match:

r"raw text"
r#"raw text"#
r##"raw text"##
r###"raw text"###
r#eos#"raw text"#eos#
r##eos##"raw text"##eos##
r###eos###"raw text"###eos###

The following don't match:

r# eos #"raw text"# eos  #  -- unbalanced spaces
r#eos"raw text"#eos -- unbalanced # around eos
r#e#os#"raw text"#e#os# -- eos contains #

I have mixed feeling regarding the inclusion of spaces in/around the eos
string.

[1]
http://regexpal.com/?flags=gs®ex=%5BrR%5D(%23*)(%5B%5E%23%22%5D*%7C%23)%5C1%22(.*%3F)%22%5C1%5C2%5C1&input=The%20following%20match%3A%0A%0Ar%22raw%20text%22%0Ar%23%22raw%20text%22%23%0Ar%23%23%22raw%20text%22%23%23%0Ar%23%23%23%22raw%20text%22%23%23%23%0Ar%23eos%23%22raw%20text%22%23eos%23%0Ar%23%23eos%23%23%22raw%20text%22%23%23eos%23%23%0Ar%23%23%23eos%23%23%23%22raw%20text%22%23%23%23eos%23%23%23%0A%0AThe%20following%20don't%20match%3A%0A%0Ar%23%20eos%20%23%22raw%20text%22%23%20eos%20%20%23%20%20--%20unbalanced%20spaces%0Ar%23eos%22raw%20text%22%23eos%20%20%20%20%20%20%20%20%20--%20unbalanced%20%23%20around%20eos%0Ar%23e%23os%23%22raw%20text%22%23e%23os%23%20%20%20%20%20--%20eos%20contains%20%23


On Mon, Sep 23, 2013 at 7:58 PM, Marvin Löbel wrote:

> Hi, I commented under the github Issue for this already, but let me post
> my proposal to the mailing list as well:
>
> My proposal is a `r""` syntax, with the option to pad the string on both
> ends with `#` to allow any string inside:
>
> foo  ==  r"foo"
> fo"o ==  r#"fo"o"#
> "##  ==  r###""##"###
>
> As far as I know we don't allow `#` in an expression context, it's only
> valid as part of the attribute syntax, so this should work.
> Heck, it would even be ok in attributes themselves, I think:
>
> #[foo = r##"test"##];
>
> Alternatively, we could also throw away the `r` token itself and say that
> any number of `#` followed by `"` starts an raw string literal:
>
> let regex = #"[\d]+"#;
>
> Or we make both forms valid: `r""` for short raw strings, and `#""#`,
> `##""##`, ... as alternative to cover every possible string.
>
> It would be similar to Luas syntax, but in my opinion has more advantages:
> - It has the same advantage of being able to delimit any text.
> - Only being limited to `#` is not a problem, you can still find a
> delimiter sequence for any input, and only need to pad with more `#`s at
> all if your string contains `"`, `"#`, `"##`etc.
> - The default case `r""` has very low typing overhead, and looks very
> similar to a regular string literal, no confusion about meaning, or
> annoyance about it not being intuitive.
> - Unlike Lua and a few of the other proposals here, r"" doesn't feel out
> of place syntax-wise.
>
> If we look at the uses casesAlex Crichton listed under the github issue:
>
> 1. Regular expressions:
>
> r"([^:]*):(\d+):(\d+): (\d+):(\d+) (.*)$".match_groups();
>
> 2. Windows paths:
>
> r"C:\Program Files\rust\bin\rust.exe".to_**path()
>
> 3. `format!` strings:
>
> println!(r"\\");
>
> 4. Blobs of text:
>
> static MARKDOWN: &'static str = r###"
> ## Scope
>
> This is an introductory tutorial for the Rust programming language. It
> covers the fundamentals of the language, including the syntax, the
> type system and memory model, generics, and modules. [Additional
> tutorials](#what-next) cover specific language features in greater
> depth.
>
> This tutorial assumes that the reader is already familiar with one or
> more languages in the C family. Understanding of pointers and general
> memory management techniques will help.
> "###;
>
> So, what do you think?
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] This Week in Rust

[Corey Richardson]

Content copied from http://cmr.github.io/blog/2013/09/23/this-week-in-rust/

--

Welcome to another issue of *This Week in Rust*. We're gearing up for a 0.8
release, tentatively planned for Thursday. Additionally, a huge welcome of
Alex Crichton to the Rust team! He's been doing some great work, it's
wonderful to have another full-time Rust dev.


# What's cooking in master?

There were 86 PRs merged this week.

## rustdoc\_ng

rustdoc\_ng was merged into mainline and enabled as the new rustdoc, in time
for 0.8. This makes me incredibly happy, as it marks the conclusion of my
quest to a better rustdoc. Not to say that rustdoc is finished or perfect,
but it's already much better than the old rustdoc. My sincere thanks go to
Jordi Boggiano (Seldaek), who worked unceasingly to create a beautiful,
usable frontend, and to Meret Vollenweider (meretv) for donating her amazing
design skills. Also thanks to Huon Wilson (dbaupp) for moral support and
creating the awesome DocFolder interface that passes over the documentation
use. And, of course, to Alex Crichton, who pushed these past few days to port
the static site generator to Rust and to integrate it into the build system.

The new docs have replaced the old docs. You can view them [on the Rust
website](http://static.rust-lang.org/doc/master/std/index.html). Still to-do
is proper cross-crate doc hyperlinking. To run it on your own crate, build a
recent Rust and do `rustdoc html path/to/your/crate.rs`. It will eventually be
integrated into `rustpkg`.

## Breaking changes

- `extra::par` has been [removed](https://github.com/mozilla/rust/pull/9380).
- Some unsound functional struct updates (FSU, `{a: 5, ..b}`) [are now
  disallowed](https://github.com/mozilla/rust/pull/9350).
- `--cfg debug` is no longer required. If you want to disable debug logging,
  use [`--cfg ndebug`](https://github.com/mozilla/rust/pull/9278).
- The various uses of `NaN` are now [lowercased to
  `nan`](https://github.com/mozilla/rust/pull/9321).
- `std::util::unreachable` has been removed in factor of the
  [`unreachable!`](https://github.com/mozilla/rust/pull/9320) macro.
- `extra::future` has been [cleaned
  up](https://github.com/mozilla/rust/pull/9285) a bit, including some method
  shuffling/renames.
- `extra::getopts` has been [cleaned
  up](https://github.com/mozilla/rust/pull/9267) as well, with most free
  functions now being methods.
- The `from_str` methods in the numeric modules have been
  [removed](https://github.com/mozilla/rust/pull/9275) in favor of the FromStr
  trait and the `from_str` free function in the prelude. Same for
  [`from_str_radix`](https://github.com/mozilla/rust/pull/9209).
- The `Drop` trait now uses [`&mut
  self`](https://github.com/mozilla/rust/pull/9244), as part of the transition
  to by-value drops.
- `extra::json` uses a [different
  encoding](https://github.com/mozilla/rust/pull/9231) when encoding/decoding
  enums, so any Rust-generated JSON before this patch will now be rejected by
  the decoder.

## Other changes

- debuginfo now works for [recursive
  types](https://github.com/mozilla/rust/pull/9168).
- You can now [pass parameters](https://github.com/mozilla/rust/pull/9213) to
  the generated test with `rust test`.
- `extern fn`s from external crates now use the [declared
  ABI](https://github.com/mozilla/rust/pull/9196), rather than assuming cdecl.
- `CString` has gained an
  [`as_str`](https://github.com/mozilla/rust/pull/9220) method.
- Some [overflow bugs](https://github.com/mozilla/rust/pull/9108) in `vec` and
  `str` have been fixed.
- `statics` are now [properly
  inlined](https://github.com/mozilla/rust/pull/9130) cross-crate.
- The `bytes!` macro's error reporting has been [tightened
  up](https://github.com/mozilla/rust/pull/9245) to make it more obvious where
  the error is.
- `rustpkg init` [has been added](https://github.com/mozilla/rust/pull/9236),
  to create a new workspace.
- File IO in newrt has been [massively
  reworked](https://github.com/mozilla/rust/pull/9235) and is much more
  complete than the oldrt.
- The exact meaning of "unsafety" [is now
  documented](https://github.com/mozilla/rust/pull/9258).
- `\0` escapes in strings [is now
  supported](https://github.com/mozilla/rust/pull/9248).
- `rustpkg` now thinks in terms of crates, not packages, to you can now have
  [multiple crates in a single
  package](https://github.com/mozilla/rust/pull/9263) and have things work
  correctly.
- newrt has [pipes and process
  support](https://github.com/mozilla/rust/pull/9260/files) now.
- `format!` now allows [trailing
  commas](https://github.com/mozilla/rust/pull/9299) in its arguments.
- The lexer now throws [vastly better
  errors](https://github.com/mozilla/rust/pull/9308).

# Weekly Meeting

The [weekly
meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-09-17)
discussed quite a bit, most interesting to me was the crypto discussion,
putting `macro_rules!` behind an experimental flag, and the default arguments
di

Re: [rust-dev] rusti - the - repl renovation

[Jason E. Aten]

On Mon, Sep 23, 2013 at 11:20 AM, Brian Anderson wrote:

> As to the issue of arbitrary global memory modifying code, only unsafe
> Rust code will do that, and it's understood that when running unsafe code
> there is no safety net.


Thanks for your thoughtful comments, Brian.

Even within a task, if I have a ~str that I change and then need to
rollback that change...

Unless there is a way to clone an entire task that I'm not aware of...


>
>  All my thoughts on this subject are above. Tasks don't address all the
> problems you want to solve, but I suggest it may be ok not to solve them.
>

It's nice to feel like there is support for a less ambitious plan.
Nonetheless, I do want aim high at first.

I'd really like a robust and bulletproof repl as much as possible. I
suspect it will entice new users as well. And I think that the choices that
flow from bulletproof are interesting. For instance, how viable is it to
have a (bare-bones if need be) single-threaded rust runtime... which is
also a question of independent interest for those considering Rust for
embedded systems development.

In any case, it might indeed turn out that worse is better or good enough.
But I want to try for better first.

Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Syntax for "raw" string literals

[Marvin Löbel]

Hi, I commented under the github Issue for this already, but let me post 
my proposal to the mailing list as well:


My proposal is a `r""` syntax, with the option to pad the string on both 
ends with `#` to allow any string inside:


foo  ==  r"foo"
fo"o ==  r#"fo"o"#
"##  ==  r###""##"###

As far as I know we don't allow `#` in an expression context, it's only 
valid as part of the attribute syntax, so this should work.

Heck, it would even be ok in attributes themselves, I think:

#[foo = r##"test"##];

Alternatively, we could also throw away the `r` token itself and say 
that any number of `#` followed by `"` starts an raw string literal:


let regex = #"[\d]+"#;

Or we make both forms valid: `r""` for short raw strings, and `#""#`, 
`##""##`, ... as alternative to cover every possible string.


It would be similar to Luas syntax, but in my opinion has more advantages:
- It has the same advantage of being able to delimit any text.
- Only being limited to `#` is not a problem, you can still find a 
delimiter sequence for any input, and only need to pad with more `#`s at 
all if your string contains `"`, `"#`, `"##`etc.
- The default case `r""` has very low typing overhead, and looks very 
similar to a regular string literal, no confusion about meaning, or 
annoyance about it not being intuitive.
- Unlike Lua and a few of the other proposals here, r"" doesn't feel out 
of place syntax-wise.


If we look at the uses casesAlex Crichton listed under the github issue:

1. Regular expressions:

r"([^:]*):(\d+):(\d+): (\d+):(\d+) (.*)$".match_groups();

2. Windows paths:

r"C:\Program Files\rust\bin\rust.exe".to_path()

3. `format!` strings:

println!(r"\\");

4. Blobs of text:

static MARKDOWN: &'static str = r###"
## Scope

This is an introductory tutorial for the Rust programming language. It
covers the fundamentals of the language, including the syntax, the
type system and memory model, generics, and modules. [Additional
tutorials](#what-next) cover specific language features in greater
depth.

This tutorial assumes that the reader is already familiar with one or
more languages in the C family. Understanding of pointers and general
memory management techniques will help.
"###;

So, what do you think?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust-dev Digest, Vol 39, Issue 61

[Brian Anderson]

On 09/21/2013 10:37 PM, Jason E. Aten wrote:

On Fri, 20 Sep 2013 Brian Anderson  wrote:
>> On 09/19/2013 11:40 PM, Jason E. Aten wrote:
>> Perhaps the best thing is just to fork(2), so we get a new (OS level)
>> process that has copy-on-write (virtual) memory, and if the
>> compilation + run succeeds in the child, then have the child "take
>> over". Otherwise the child dies with an fail! + location message, and
>> we return to the parent exactly before the child was spawned.
>
> It seems a shame to be relying on process isolation instead of tasks. If
> I were to just imagine the architecture of a repl that used task
> isolation for crash recovery it might have one task for accepting input
> and another as a sandbox that maintains the repl state and executes
> commands in a loop.

Yes, it seems a shame. It's even worse than a shame. It adds demands. 
Using fork(2) demands a single-threaded runtime. Tasks don't require a 
single threaded runtime. And tasks are more portable. Using fork(2) 
might mean only supporting Linux or Linux & OSX at first.  Windows 
support might require cygwin's fork implementation, whereas tasks are 
everywhere.


So I agree. It seems a shame. I want to do it with tasks only. I just 
don't see how. How can we do this with tasks and get the desired 
rollback on fail!()?


I'll detail the problem a little. With only tasks, how do we rollback 
changes to global state made by pre-compiled library functions that 
are called from JIT-ed and run code? The task doesn't know what the 
arbitrary code has done, so the task can't roll it back. Any functions 
in an arbitrary C library, any unsafe Rust functions, and the 
JIT-compilation itself will have updated global memory, the llvm 
module's symbols, etc. Since we've fail!-ed at the end of an 
arbitrarily long sequence of code, now we want that reverted all that 
cleanly and completely. How would a task do that?


A task can't do that, but I'd suggest that perhaps rolling back global 
state doesn't need to be a requirement. Most computation in Rust is 
task-local.




I've been down that road for syntax errors before. I've implemented 
rollback of everything that the LLVM-JIT added to an llvm module. It 
was a pain, I had to track everything that the llvm jit-compiler did, 
so I could roll back on syntax error. It was brittle, introducing a 
myraid of undersirable code-interactions and logging to the current 
transaction code intertwined with every llvm call. It was a pain, but 
it worked--for syntax error rollback.


I must defer to your judgement on the issue of JIT rollback, because I 
don't understand it.




But here we're not talking about *just* rolling back on syntax error. 
We want to roll back not only the effects of a partial 
JIT-compilation, but to also rollback after *running that code*.  That 
code can call into *arbitrary global memory modifying code*. All that 
we know is that an arbitrary set of changes to the process image has 
ended in a fail!().


What is partial JIT compilation? As to the issue of arbitrary global 
memory modifying code, only unsafe Rust code will do that, and it's 
understood that when running unsafe code there is no safety net.




I'm certainly open to alternatives.  How will that alternative address 
the rollback on fail!() problem?


All my thoughts on this subject are above. Tasks don't address all the 
problems you want to solve, but I suggest it may be ok not to solve them.


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] rusti - the - repl renovation

[Jason E. Aten]

On Mon, Sep 23, 2013 at 7:53 AM, Thad Guidry  wrote:

> Hi Jason,
>
> Nice work.
>
> Curious, this differs in POSIX, I know, but... How long should CUR wait,
> what if TRY never finishes and wait cannot retrieve the exit status to
> determine normal or abnormal (because of various scenarios) and the
> specified process never terminates ?
>
> } else {
>// I am CUR. I wait for TRY to finish. If TRY succeeds I never wake
> up. If TRY fails, I goto the
>// top of the steady-state loop and try again
>std::run::waitpid(pid);
>printfln!("%d: CUR saw TRY process exit, must have failed. Going to
> top of loop to spawn a new try.",
>  getpid() as int);
>

Hi Thad,

Thank you.

The user typing at rustxi can press ctrl-c to interrupt TRY with SIGINT at
any time. This is currently how the prototype rustxi is implemented too
(code updated with ctrl-c handling last night), so you can try it out now
if you'd like. Since TRY doesn't catch SIGINT, by default it dies when the
user presses ctrl-c, then CUR wakes up and forks another TRY.  TRY blocks
on reading from the pipe connected to VISOR, so it waits in turn for the
user input that VISOR is also blocked waiting for.

This seems like typical and expected REPL behavior. It would be quite
surprising to have a repl decide to think on its own that it can time-out
an operation, even after days, unless there was an explicit timer/watchdog
configured by the user. Since I tend to do CPU intensive things, my
preference is to have CUR wait forever.

Did you have a use case or situation in mind where you thought CUR should
timeout?

Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] rusti - the - repl renovation

[Thad Guidry]

Did you have a use case or situation in mind where you thought CUR should
> timeout?
>
> Jason
>
>
No situation, I also think CUR should wait forever for the same reasons.
 Just curious, thanks for explaining ctrl-c regarding SIGINT, makes sense.

-- 
-Thad
Thad on Freebase.com 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Syntax Extensions

[Paul Stansifer]

In libsyntax/ext, `expand.rs` and `base.rs` are the main parts of the
implementation (and `source_utils.rs` is a smaller one), and most of the
rest are implementations of existing syntax extensions. `bytes.rs` and `
env.rs` are simple ones, and `quote.rs` and `fmt.rs` are more complicated.

Note that macros are just a kind of syntax extension, so the way they are
invoked is the same: the user has to do `my_syntax_extension!(...)`; you
can't do, for example, something that walks the whole tree without wrapping
the whole thing in an invocation. I'm not sure what your requirements are
in that area.

Paul
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] rusti - the - repl renovation

[Thad Guidry]

Hi Jason,

Nice work.

Curious, this differs in POSIX, I know, but... How long should CUR wait,
what if TRY never finishes and wait cannot retrieve the exit status to
determine normal or abnormal (because of various scenarios) and the
specified process never terminates ?

} else {
   // I am CUR. I wait for TRY to finish. If TRY succeeds I never wake
up. If TRY fails, I goto the
   // top of the steady-state loop and try again
   std::run::waitpid(pid);
   printfln!("%d: CUR saw TRY process exit, must have failed. Going to
top of loop to spawn a new try.",
 getpid() as int);

-- 
-Thad
Thad on Freebase.com 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] If and pattern match

[Huon Wilson]

On 23/09/13 20:52, Jason Fager wrote:
Doesn't seem like enough bang for the buck to me. In your 
first example you save 3 vertical lines but get a really wide one in 
return, and lose some indentation levels but add more syntax and 
conceptual overhead to the language.


Might be my lack of imagination, but the feature doesn't seem to 
expand out to many other use cases, either.


Your second case you could write as:

let foo = get_option("foo");
let bar = get_option("bar");
if foo.is_some() && bar.is_some() {
  use(foo.unwrap(), bar.unwrap());
}



It's also possible to write a `matches` macro:

  macro_rules! matches {
  ($e:expr ~ $($p:pat)|*) => {
  match $e {
  $($p)|* => true,
  _ => false
  }
  }
  }

  fn main() {
  let a = Some(1);
  let b = Some(2);

  if matches!((a,b) ~ (Some(_), Some(_))) {
  println("whatever");
  }
  }

(This has the drawback that accidentally (or otherwise) using a pattern 
that always matches, e.g. `matches!((a,b) ~ (_,_))` gives a error 
message about the `_ => false` arm being unreachable, which isn't 
particularly intuitive.)


Following the use-more-macros line, one could modify the above to give 
something like


  if_matches!(foo ~ (Some(a), Some(b)) => {
  // use a, b
  })

by adding an $expr argument to use instead of `true` and replacing the 
false arm with `{}`. Note: this *may* break when match-var-hygiene is 
implemented (https://github.com/mozilla/rust/issues/9384), I'm not sure.


Huon

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] If and pattern match

[Jason Fager]

Doesn't seem like enough bang for the buck to me.  In your first example you
save 3 vertical lines but get a really wide one in return, and lose
some indentation
levels but add more syntax and conceptual overhead to the language.

Might be my lack of imagination, but the feature doesn't seem to expand out
to many other use cases, either.

Your second case you could write as:

let foo = get_option("foo");
let bar = get_option("bar");
if foo.is_some() && bar.is_some() {
use(foo.unwrap(), bar.unwrap());
}





On Monday, September 23, 2013, Oren Ben-Kiki wrote:

> A question / proposed syntax... How about allowing writing something like:
>
> if (Some(foo), Some(bar)) ~~ (get_option("foo"), get_option("bar)) {
> use(foo, bar);
> }
>
> Instead of having to write the more combersome:
>
> match (get_option("foo"), get_option("bar")) {
> (Some(foo), Some(bar)) => {
> use(foo, bar);
> },
> _otherwise => {},
> }
>
> Not to mention:
>
> let foo_bar: bool = (Some(_foo), Some(_bar)) ~~ (get_option("foo"),
> get_option("bar"));
>
> match (get_option("foo"), get_option("bar")) {
> (Some(foo), Some(bar)) => {
> use(foo, bar);
> },
> _otherwise => {},
> }
>
> Instead of the very cumbersome:
>
> let foo_bar: bool =
> match (get_option("foo"), get_option("bar")) {
> (Some(_foo), Some(_bar)) => true,
> _otherwise => false,
> }
> }
>
> So, in general allow `pattern ~~ expression` to be a boolean expression
> and if it is used in an "if" statement allow it to introduce the matched
> variables to the "then" scope.
>
> The operator doesn't have to be ~~, it could be anything unique (though
> using ~ for matching has a lot of precedence in other languages).
>
> Thoughts?
>
> Oren Ben-Kiki
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] If and pattern match

[Oren Ben-Kiki]

A question / proposed syntax... How about allowing writing something like:

if (Some(foo), Some(bar)) ~~ (get_option("foo"), get_option("bar)) {
use(foo, bar);
}

Instead of having to write the more combersome:

match (get_option("foo"), get_option("bar")) {
(Some(foo), Some(bar)) => {
use(foo, bar);
},
_otherwise => {},
}

Not to mention:

let foo_bar: bool = (Some(_foo), Some(_bar)) ~~ (get_option("foo"),
get_option("bar"));

match (get_option("foo"), get_option("bar")) {
(Some(foo), Some(bar)) => {
use(foo, bar);
},
_otherwise => {},
}

Instead of the very cumbersome:

let foo_bar: bool =
match (get_option("foo"), get_option("bar")) {
(Some(_foo), Some(_bar)) => true,
_otherwise => false,
}
}

So, in general allow `pattern ~~ expression` to be a boolean expression and
if it is used in an "if" statement allow it to introduce the matched
variables to the "then" scope.

The operator doesn't have to be ~~, it could be anything unique (though
using ~ for matching has a lot of precedence in other languages).

Thoughts?

Oren Ben-Kiki
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] rusti - the - repl renovation

[Jason E. Aten]

Since I work in R alot, I value a repl session with state very highly.  Bad
scenario: suppose I'm working at rusti, and then I make one mistake in
syntax, or do an index into a vector that is out-of-bounds and thus cause
an assert!() to fire and my current task to fail. If I'm working at a repl
without transactional rollback and recovery, suddenly rusti deletes all my
data and code and work and starts over? Yikes.  See Alex's comments earlier
in this discussion thread.

To me, casual data loss is simply unacceptable. The repl state must survive
mistakes by the user, or else it isn't usable at all. Period.

Progress update:  we have a name!  Meet Rustxi

Progress update:  and, we have code!

I've implemented transactional code evaluation using three processes and
ping-pong forking.  This was done in a prototype spike of Rust code that I
posted to the repo below, and it works well. It doesn't loose state. It
provides transactions with commit-on-success and rollback-on-failure.  Of
course, nothing is hooked up to rustc yet.

Code, design, and RFC (Request For Comments) here:

https://github.com/glycerine/rustxi
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev