[rust-dev] TCP Library Selection
Hi, Looks like there are three different libraries for TCP socket functionality: Net_tcp Uv_ll Net::tcp Could someone enlighten me as to which one is the recommended library to use? Thanks very much! Regards, Abhijeet ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cloning RWARC
Try data.clone() instead. On Wednesday, April 17, 2013, Alexander Stavonin wrote: > Hi, > > I'd like to clone RWARC object. For example: > > let data = arc::RWARC(get_data()); > > How can I do it? I tried next: > > let read_data = arc::clone(&data); > > But looks like I have to write something different: > > error: mismatched types: expected `&std::arc::ARC<>` but found > `&std::arc::RWARC<~[uint]>` > > Next forme doesn't work too: > > let read_data = arc::RWARC::clone(&data); > -- http://about.me/abhijeet.gaiha ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] String Internment Library
There is an issue on Servo #282, which talks about having a uniform string internment strategy across Rust, Spidermonkey and NetsurfCSS. Is there any existing string internment library in Rust? If not, any plans to provide one? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutability and borrowing
Trying to concurrently borrow a value twice is never going to work.
You could write a function like "double" for such a situation.
--
Abhijeet Gaiha
http://about.me/abhijeet.gaiha
On Sunday, 2 June 2013 at 10:03 AM, 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?
>
> Thanks
>
> --
> Ziad
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org (mailto: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] Mutability and borrowing
The 'copy' parameter is the most generic way for the client to handle this
situation.
--
Abhijeet Gaiha
http://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 (mailto:catamorph...@gmail.com)> wrote:
> > On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet > (mailto:hata...@gmail.com)> 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 list
> Rust-dev@mozilla.org (mailto: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] Memory pool for C lib malloc calls
Hi, Servo uses several c libraries through Rust wrappers. In such a situation, I'm curious as to where is the memory for malloc calls inside these libraries allocated from? This doesn't seem to fit into the standard locations viz. Task Heap, Exchange Heap and Local stack. In C programs there is a global heap, but nothing in the rust docs I've looked at so far suggests such a thing exists right now. Which leads me to this question. Thanks, Abhijeet -- http://about.me/abhijeet.gaiha ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Memory pool for C lib malloc calls
This suggests that any data allocated in C libs (including statics) is basically part of a "global" address space available to all tasks in a Rust program. Is that correct? Is there as equivalent of malloc() for Rust as well? On 6 June 2013 22:09, Daniel Micay wrote: > On Thu, Jun 6, 2013 at 12:29 PM, Abhijeet Gaiha > wrote: > > Hi, > > > > Servo uses several c libraries through Rust wrappers. In such a > situation, > > I'm curious as to where is the memory for malloc calls inside these > > libraries allocated from? This doesn't seem to fit into the standard > > locations viz. Task Heap, Exchange Heap and Local stack. In C programs > there > > is a global heap, but nothing in the rust docs I've looked at so far > > suggests such a thing exists right now. Which leads me to this question. > > > > Thanks, > > Abhijeet > > The malloc/free functions are wrappers on top of sbrk and/or mmap (or > similar calls on Windows) to obtain memory from the OS. All memory > allocators get the memory from the same place and the process has one > address space, so there isn't really a difference. > > In fact right now, Rust obtains all heap memory from the system's C > library malloc/free (likely soon to be jemalloc instead). > > The local heap and exchange heap don't really exist, they're terms the > documentation used as an attempt to explain how things work, but it > was never really accurate. Unique pointers/vectors containing managed > boxes would be on the "local heap" if we did have one. > > The only distinction we should make is that Owned types (soon to be > renamed Send) are sendable and other types are task-local. > -- http://about.me/abhijeet.gaiha ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Static initialisation of LinearMap
Hi Folks, Is there a way to statically initialise a LinearMap in code? Something like you can do with a vector. Any other suggestions to save time for inserting a fixed set of values into a hash map? Thanks, Abhijeet -- Abhijeet Gaiha http://about.me/abhijeet.gaiha ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Static initialisation of LinearMap
If I did write a macro, that would amount to the same thing as doing the
inserts at run-time (I think).
I was looking for something like: static h:HashMap = {(K,V),(K,V).}.
Is this possible at all? Any potential equivalents in the std/ext library to
just writing a custom map of my own to do the same?
--
Abhijeet Gaiha
http://about.me/abhijeet.gaiha
On Tuesday, 2 July 2013 at 7:10 PM, Corey Richardson wrote:
> On Tue, Jul 2, 2013 at 9:26 AM, Abhijeet Gaiha (mailto:abhijeet.ga...@gmail.com)> wrote:
> > Hi Folks,
> >
> > Is there a way to statically initialise a LinearMap in code? Something like
> > you can do with a vector.
> > Any other suggestions to save time for inserting a fixed set of values into
> > a hash map?
> >
>
>
> LinearMap is now std::hashmap::HashMap (in 0.7 and in master). There
> is no way to have a *static* hashmap, I think (`static h: HashMap V> = HashMap::new()`, would be immutable and useless), but you could
> write a macro that expands to a bunch of inserts into a hashmap. Not
> sure, though.
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Dynamic in Rust
You could define an enum that encapsulates all known types.
enum monster {
Integer(int),
Float(float),
}
Then use a container for this type.
On Aug 23, 2013 10:20 AM, "Oren Ben-Kiki" wrote:
> Is it possible to implement something like Haskell's Dynamic value holder
> in Rust? (This would be similar to supporting C++'s dynamic_cast).
> Basically, something like this:
>
> pub struct Dynamic { ... }
> impl Dynamic {
> pub fn put(value: ~T) { ... }
> pub fn get() -> Option { ... }
> }
>
> I guess this would require unsafe code... even so, it seems to me that
> Rust pointers don't carry sufficient meta-data for the above to work. A
> possible workaround would be something like:
>
> pub struct Dynamic { type_name: ~str, ... }
> impl Dynamic {
> pub fn put(type_name: &str, value: ~T) { Dynamic { type_name:
> type_name, ... } }
> pub fn get(&'a self, type_name: &str) -> Option<&'a T> {
> assert_eq!(type_name, self.type_name); ... } }
> }
>
> And placing the burden on the caller to always use the type name "int"
> when putting or getting `int` values, etc. This would still require some
> sort of unsafe code to cast the `~T` pointer into something and back, while
> ensuring that the storage for the `T` (whatever its size is) is not
> released until the `Dynamic` itself is.
>
> (Why do I need such a monstrosity? Well, I need it to define a
> `Configuration` container, which holds key/value pairs where whoever sets a
> value knows its type, whoever gets the value should ask for the same type,
> and the configuration can hold values of "any" type - not from a predefined
> list of types).
>
> Is such a thing possible, and if so, how?
>
> Thanks,
>
> Oren Ben-Kiki
>
> ___
> 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] Dynamic in Rust
I think your second solution is what will work. You can use unsafe code and
a void pointer combined with a type descriptor string. I would probably
combine the void pointer and string in a struct.
On Aug 23, 2013 10:27 AM, "Oren Ben-Kiki" wrote:
> That would require me to declare up front which types were usable and
> which weren't. I'm looking for a solution where I don't need to do that;
> that is, allow me to add new components to the system with new
> configuration parameter types, without having to go to a central source
> location and declare these types there.
>
>
> On Fri, Aug 23, 2013 at 7:54 AM, Abhijeet Gaiha
> wrote:
>
>> You could define an enum that encapsulates all known types.
>>
>> enum monster {
>> Integer(int),
>> Float(float),
>>
>> }
>>
>> Then use a container for this type.
>> On Aug 23, 2013 10:20 AM, "Oren Ben-Kiki" wrote:
>>
>>> Is it possible to implement something like Haskell's Dynamic value
>>> holder in Rust? (This would be similar to supporting C++'s dynamic_cast).
>>> Basically, something like this:
>>>
>>> pub struct Dynamic { ... }
>>> impl Dynamic {
>>> pub fn put(value: ~T) { ... }
>>> pub fn get() -> Option { ... }
>>> }
>>>
>>> I guess this would require unsafe code... even so, it seems to me that
>>> Rust pointers don't carry sufficient meta-data for the above to work. A
>>> possible workaround would be something like:
>>>
>>> pub struct Dynamic { type_name: ~str, ... }
>>> impl Dynamic {
>>> pub fn put(type_name: &str, value: ~T) { Dynamic { type_name:
>>> type_name, ... } }
>>> pub fn get(&'a self, type_name: &str) -> Option<&'a T> {
>>> assert_eq!(type_name, self.type_name); ... } }
>>> }
>>>
>>> And placing the burden on the caller to always use the type name "int"
>>> when putting or getting `int` values, etc. This would still require some
>>> sort of unsafe code to cast the `~T` pointer into something and back, while
>>> ensuring that the storage for the `T` (whatever its size is) is not
>>> released until the `Dynamic` itself is.
>>>
>>> (Why do I need such a monstrosity? Well, I need it to define a
>>> `Configuration` container, which holds key/value pairs where whoever sets a
>>> value knows its type, whoever gets the value should ask for the same type,
>>> and the configuration can hold values of "any" type - not from a predefined
>>> list of types).
>>>
>>> Is such a thing possible, and if so, how?
>>>
>>> Thanks,
>>>
>>> Oren Ben-Kiki
>>>
>>> ___
>>> 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
