Re: [rust-dev] Mutability and borrowing

[Madhu Srinivasan]

Going by the suggested solution of using Atomic Reference Counters (std::arc) 
for sharing immutable data across different tasks, I would presume that the 
most generic solution would be to use the arc module. You can see an example of 
this in action here : 
https://github.com/smadhueagle/rustlings/blob/master/borrow.rs
Madhu

From: hata...@gmail.com
Date: Sat, 1 Jun 2013 22:30:35 -0700
To: abhijeet.ga...@gmail.com
CC: rust-dev@mozilla.org
Subject: Re: [rust-dev] Mutability and borrowing

True. I suppose I meant generic and memory efficient at the same time. I guess 
it shouldn't be too much of a hassle to implement the specialized case of this 
function if memory is absolutely critical.

Thanks


--
Ziad


On Sat, Jun 1, 2013 at 10:03 PM, Abhijeet Gaiha  
wrote:



The 'copy' parameter is the most generic way for the client to 
handle this situation.


-- Abhijeet Gaihahttp://about.me/abhijeet.gaiha

 
On Sunday, 2 June 2013 at 10:32 AM, Ziad Hatahet wrote:

Thanks everyone. I actually thought about the two 
suggestions before posting. I thought there might be some common paradigm for 
this in the language though.



So I take it that implementing a += operator overload function would not have a 
generic way to handle the case where the same parameter is passed on both sides?



--
Ziad


On Sat, Jun 1, 2013 at 9:42 PM, Tim Chevalier  wrote:


On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet  wrote:

> I have the following function:

>

> fn add_equal(x: &mut Complex, y: &Complex) {

> x.real += y.real;

> x.imag += y.imag;

> }

>

> Calling the function with the same variable being passed to both arguments

> (i.e. add_equal(&mut c, &c)), results in the compile error:

>

> error: cannot borrow `c` as immutable because it is also borrowed as mutable

>

> I am guessing this is to avoid aliasing issues? What is the way around this?

>



You can copy y instead of passing a reference to it:

fn add_equal(x: &mut Complex, y: Complex) { ...



Of course, that means that at the call site, you will have to write

something like add_equal(&mut c, copy c).



Unless you want to write a function that just takes one argument and

doubles it, like Abhijeet suggested, I don't know of another way

around this.



Cheers,

Tim





--

Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt

"Not a riot, it's a rebellion." -- Boots Riley

"Attention Bros and Trolls: When I call out your spew, I'm not angry,

I'm defiant." -- Reg Braithwaite



___Rust-dev mailing 
listrust-...@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 mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Access to COM/IUnknown objects from Rust?

[Vadim]

Rust traits are not binary-compatible with C++ vtables, so no, you cannot
use them directly.

I think it's possible to implement COM interop by doing some clever code
generation via macros. I briefly looked into doing this a couple of months
ago, but at the time it was not possible to specify calling convention on
function pointers, and you can't generate COM vtables without that.  Once
v0.7 is out, I'll try again.

Vadim


On Mon, Jun 3, 2013 at 5:04 AM, Alexandre Mutel wrote:

> Hi,
> I have not seen any reference about this, so sorry If I'm posting a
> question that got already an answer somewhere.
>
> Rust seems to provide an infrastructure for accessing exported DLL
> functions, but is there a mechanism to access COM/IUnknown objects? There
> are lots of API - under Windows - that are only accessible through COM (the
> whole DirectX API for example), or even the whole new WinRT API. Would it
> be possible to develop use traits to develop a IUnknown interface with
> virtual methods and cast a pointer to it easily?
>
>
> ___
> 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

Re: [rust-dev] Traits & "mod"

[Graydon Hoare]

On 01/06/2013 2:21 PM, Tom Lee wrote:


This is fixed by adding "use some_mod::SomeTrait" at the start of
some_use.rs. It's as though traits need to be in the same scope as
code that expects to make use of their behaviour (where I'd expect the
behaviour would be associated with the implementation for the "self"
type).


No, the methods in this case are scoped to the trait. See all the traits 
we 'pub use' in std::prelude so that they are available as methods 
ubiquitously.



My question is: is this intended behaviour? If not, what's the
expected behaviour & is there an outstanding issue for this?


This is intended behavior. Note that there _is_ a single 
inherent-to-the-type impl (set of methods) which you can use to 
associated methods with a type:


   struct Foo { ... }
   impl Foo {
   .. inherent methods
   }

Such that anyone who can see Foo can see these methods. But that impl 
has to be defined in the same crate[1] as the struct itself, such that 
we can check that there's only one of them. For implementations of a 
named trait, you must have the trait in-scope in order to see the 
methods[2].


If you think about this in terms of colliding names and separate 
compilation, it makes more sense. We want to make it possible to always 
link together two crates A and B both compiled independently. Suppose A 
and B both defined different traits P and Q on some type Foo with some 
methods P::bar() and Q::bar(). Then someone calling (Foo::new()).bar() 
would be producing a link-time error due to the ambiguity between 
P::bar() and Q::bar().


We want such things to be caught during compilation of the client code 
-- where it can be resolved by making a module that does not 
simultaneously 'use' P and Q -- rather than at link time.


-Graydon

[1] Possibly the inherent impl has to be in the same module as the 
struct, not just the same crate. I don't remember where we drew that 
line. I think it's mostly equivalent either way.


[2] You must also implement any trait T for a struct S in either the 
crate defining T or the crate defining S. This is a different but 
related restriction, to ensure we never have two different impls of T for S.

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

Re: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon?

[Erick Tryzelaar]

Hey all! I think we have critical mass for a presentation or two. Would
anyone be interested in giving a presentation? If so, how much time would
you need to put one together?


On Mon, May 27, 2013 at 4:27 PM, Kevin Cantu  wrote:

> Count me in.  :)
>
>
> Kevin
>
>
> --
> Kevin Cantu
>
>
> On Fri, May 24, 2013 at 3:48 PM, Brian Anderson wrote:
>
>> On 05/24/2013 03:31 PM, Erick Tryzelaar wrote:
>>
>>> Glad to help.
>>>
>>> So far I've heard from 10 others so far, which I think is pretty good
>>> for our first one in the bay area. When do the interns start? This could be
>>> a good way to introduce them into the community / convince them work on my
>>> feature requests :)
>>>
>>>
>> All the rust interns will be here by 6/10.
>>
>> __**_
>> 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] Access to COM/IUnknown objects from Rust?

[Alexandre Mutel]

Hi,
I have not seen any reference about this, so sorry If I'm posting a question 
that got already an answer somewhere.

Rust seems to provide an infrastructure for accessing exported DLL functions, 
but is there a mechanism to access COM/IUnknown objects? There are lots of API 
- under Windows - that are only accessible through COM (the whole DirectX API 
for example), or even the whole new WinRT API. Would it be possible to develop 
use traits to develop a IUnknown interface with virtual methods and cast a 
pointer to it easily?

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

Re: [rust-dev] Using new I/O error handling

[Felix S. Klock II]

On 01/06/2013 06:10, Brian Anderson wrote:

On 05/31/2013 01:44 AM, Sanghyeon Seo wrote:
Is it actually possible to use new I/O error handling at the moment? 
It seems to me that
it is not possible to get at std::rt::io::io_error at all, because 
conditions are private and

do not work cross-crate.

https://github.com/mozilla/rust/issues/5446
https://github.com/mozilla/rust/issues/6009
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


You are right that it is not possible because of those errors. I 
believe that the fix for #6009 is 1cbf0a8 and has been snapshotted, so 
io_error and read_error can have their /*pub*/ uncommented.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I had thought that conditions were currently public, due to commit 
fe13b865.  (Commit 1cbf0a8 is indeed related to all this, but it did not 
revert conditions to being private-by-default; that is planned for 
later, as described on pull request #6271)


But certainly the ICE described by #5446 sounds serious.  I'll poke at 
it (and probably take care of the rest of #6009 while I am at it).


Cheers,
-Felix


-- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.org
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev