From valerii.hiora at gmail.com Thu May 1 01:15:52 2014 From: valerii.hiora at gmail.com (Valerii Hiora) Date: Thu, 1 May 2014 11:15:52 +0300 Subject: [rust-dev] Once_fns Message-ID: Hi, Which is current state of once functions? In the doc https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQit mentioned as experimental feature, which might not be enabled in 1.0. But it is Compiler shows a warning -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerii.hiora at gmail.com Thu May 1 01:24:06 2014 From: valerii.hiora at gmail.com (Valerii Hiora) Date: Thu, 1 May 2014 11:24:06 +0300 Subject: [rust-dev] Once_fns In-Reply-To: References: Message-ID: I apologize for sending draft, here goes the full version. Which is current state of once functions? In the doc https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQthey are mentioned as experimental feature, which might not be enabled in 1.0. Compiler shows a warning "once functions are experimental and likely to be removed", which raises question "how likely" considering wiki page was last edited 9 months ago. Is better to avoid them at all or it's still safe use them as experimental feature? -- Valerii On Thu, May 1, 2014 at 11:15 AM, Valerii Hiora wrote: > Hi, > > Which is current state of once functions? > In the doc > https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQ it > mentioned as experimental feature, which might not be enabled in 1.0. But > it is > Compiler shows a warning > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Thu May 1 03:04:16 2014 From: jon.mb at proinbox.com (John Mija) Date: Thu, 01 May 2014 11:04:16 +0100 Subject: [rust-dev] How does Windows is supported? Message-ID: <53621C20.2010101@proinbox.com> Is possible to create wraps to the Windows system calls? Is there any tool to do it easily? Something like [mksyscall_windows.go](https://code.google.com/p/go/source/browse/src/pkg/syscall/mksyscall_windows.go) which generates the bodies for the Windows system calls. From mborch at gmail.com Thu May 1 06:53:41 2014 From: mborch at gmail.com (Malthe Borch) Date: Thu, 1 May 2014 15:53:41 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" Message-ID: In Rust, the built-in std::str type "is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes". Meanwhile, building on experience with Python 2 and 3, I think it's worth considering a more flexible design. A string would be essentially a rope where each leaf specifies an encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two bytes). That is, a string may be comprised of segments of different encodings. On the I/O barrier you would then explicitly encode (and flatten) to a compatible encoding such as UTF-8. Likewise, data may be read as 8-bit raw and then "decoded" at a later stage. For instance, HTTP request headers are ISO8859-1, but the entire input stream is 8-bit raw. Sources: - https://maltheborch.com/2014/04/pythons-missing-string-type - http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ From farcaller at gmail.com Thu May 1 08:32:18 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Thu, 1 May 2014 16:32:18 +0100 Subject: [rust-dev] morestack prologue contains broken machine code In-Reply-To: References: Message-ID: Is there any good reason why kSplitStackAvailable is hard-coded to 256 (given that I have tasks with their whole stack on 512 bytes)? I guess, this constant should actually be externally configurable. On Fri, Apr 25, 2014 at 5:20 PM, Alex Crichton wrote: > The prologue is run on every single function executed in a program, so > I believe that in the hopes of keeping it as light as possible it > never makes any function calls. > > I do agree though, that it's at tricky situation in that case. How > does TLS otherwise work for that platform? > > On Fri, Apr 25, 2014 at 8:14 AM, Vladimir Pouzanov > wrote: > > I have a side question related to the same code. > > > > Currently __STACK_LIMIT is constant, but I would like the preamble to > verify > > stack overflow for multithreaded context, i.e. __STACK_LIMIT will depend > on > > the current running thread. Is there any reason, why it's not a function? > > Any objections if I do some refactoring and make it a function? For a > simple > > case that could be a weak symbol that returns a constant. > > > > > > On Tue, Apr 22, 2014 at 9:00 AM, Alex Crichton wrote: > >> > >> I agree with Corey, it's much better to send it upstream first. I'd be > >> more than willing to help you out with writing tests or taking a peek > >> at the patch if you want! I'm acrichto on IRC > >> > >> On Tue, Apr 22, 2014 at 12:43 AM, Vladimir Pouzanov < > farcaller at gmail.com> > >> wrote: > >> > The problem is that mrc is generated unless target is thumb1, but > >> > cortex-m3 > >> > is thumb2 that still doesn't support mrc: > >> > > >> > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka398.html > , > >> > so an additional check to ST->TargetTriple.Data is required to verify > >> > it's > >> > not thumbv7m. > >> > > >> > Do I need to submit patch against https://github.com/rust-lang/llvmor > >> > send > >> > it to upstream? > >> > > >> > > >> > On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov < > farcaller at gmail.com> > >> > wrote: > >> >> > >> >> Hm, it seems to have precautions to stop mrc from materializing on > >> >> Thumb1. > >> >> I guess I need to take a better look into what's going wrong on my > >> >> side. > >> >> I'll see what I can do with that. > >> >> > >> >> > >> >> On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton > >> >> wrote: > >> >>> > >> >>> The split stack patches for ARM were recently upstreamed, and they > >> >>> were modified when being upstreamed as well. Primarily the location > of > >> >>> the split stack is no longer at a magic address for thumb, but > rather > >> >>> it uses the same instruction as ARM (some thumb processors do indeed > >> >>> have the coprocessor). More information is in the long thread > starting > >> >>> at the initial attempt to upstream [1]. > >> >>> > >> >>> For now you'll have to use no_split_stack because the thumb split > >> >>> stack will always use a coprocessor, but I'm sure that the upstream > >> >>> LLVM devs would be quite welcoming to tweaks to the slit-stack > support > >> >>> (I'd also be willing to help). You can find the initial commit for > >> >>> support at rust-lang/llvm [2]. > >> >>> > >> >>> [1] - > >> >>> > >> >>> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html > >> >>> [2] - https://github.com/rust-lang/llvm/pull/4 > >> >>> > >> >>> On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov > >> >>> > >> >>> wrote: > >> >>> > Starting recently (no more than two weeks), rustc is generating a > >> >>> > broken > >> >>> > prologue for arm. Here's the sample assembly: > >> >>> > 0x00000f44 <+0>: push {r4, r5} > >> >>> > => 0x00000f46 <+2>: mrc 15, 0, r4, cr13, cr0, {3} > >> >>> > 0x00000f4a <+6>: mov r5, sp > >> >>> > 0x00000f4c <+8>: b.n 0xa78 > >> >>> > 0x00000f4e <+10>: ands r4, r0 > >> >>> > 0x00000f50 <+12>: cmp r4, r5 > >> >>> > 0x00000f52 <+14>: bcc.n 0xf66 > >> >>> > > >> >>> > > >> >>> > > <_ZN7drivers3lcd6c1233244C12332$LT$$x27a$C$$x20S$C$$x20T$GT$.lcd..LCD5flush20h76589116290686712394v0.0E+34> > >> >>> > 0x00000f54 <+16>: movs r4, #16 > >> >>> > 0x00000f56 <+18>: movs r5, #0 > >> >>> > 0x00000f58 <+20>: push {lr} > >> >>> > 0x00000f5a <+22>: bl 0x19d8 <__morestack> > >> >>> > 0x00000f5e <+26>: ldr.w lr, [sp], #4 > >> >>> > 0x00000f62 <+30>: pop {r4, r5} > >> >>> > 0x00000f64 <+32>: bx lr > >> >>> > > >> >>> > The problem is at 0x00000f46, where code tries to read from > >> >>> > coprocessor > >> >>> > 15 > >> >>> > register 13, which is "process id register". Well, coprocessor 15 > >> >>> > (actually, > >> >>> > all of the coprocessors) are missing from my target > >> >>> > thumbv7m-linux-eabi > >> >>> > (with added flavour of -Ctarget-cpu=cortex-m3, which should be > >> >>> > redundant > >> >>> > anyway), so I'm getting hardfaults in every function that rust > >> >>> > doesn't > >> >>> > inline. > >> >>> > > >> >>> > Any ideas on what might be going wrong? I assume that this is > >> >>> > actually > >> >>> > llvm's fault, as llvm should not materialize machine code which is > >> >>> > not > >> >>> > available for target anyway. > >> >>> > > >> >>> > Wrapping everything in #[no_split_stack] is a temporary workaround > >> >>> > and > >> >>> > surely not a long-term strategy. > >> >>> > > >> >>> > -- > >> >>> > Sincerely, > >> >>> > Vladimir "Farcaller" Pouzanov > >> >>> > http://farcaller.net/ > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Rust-dev mailing list > >> >>> > Rust-dev at mozilla.org > >> >>> > https://mail.mozilla.org/listinfo/rust-dev > >> >>> > > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Sincerely, > >> >> Vladimir "Farcaller" Pouzanov > >> >> http://farcaller.net/ > >> > > >> > > >> > > >> > > >> > -- > >> > Sincerely, > >> > Vladimir "Farcaller" Pouzanov > >> > http://farcaller.net/ > > > > > > > > > > -- > > Sincerely, > > Vladimir "Farcaller" Pouzanov > > http://farcaller.net/ > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.zabaluev at gmail.com Thu May 1 09:54:01 2014 From: mikhail.zabaluev at gmail.com (Mikhail Zabaluev) Date: Thu, 1 May 2014 19:54:01 +0300 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: Hi, 2014-05-01 16:53 GMT+03:00 Malthe Borch : > In Rust, the built-in std::str type "is a sequence of unicode > codepoints encoded as a stream of UTF-8 bytes". > > Meanwhile, building on experience with Python 2 and 3, I think it's > worth considering a more flexible design. > > A string would be essentially a rope where each leaf specifies an > encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two > bytes). > > That is, a string may be comprised of segments of different encodings. > On the I/O barrier you would then explicitly encode (and flatten) to a > compatible encoding such as UTF-8. > > Likewise, data may be read as 8-bit raw and then "decoded" at a later > stage. For instance, HTTP request headers are ISO8859-1, but the > entire input stream is 8-bit raw. > I don't think that so much hidden complexity would be justified in the built-in string type. Encoded text is typically dealt with in protocol libraries or similar "I/O barriers" where it should be passed through a validating decoder. std::str is guaranteed (within the usual safety considerations) to hold a valid UTF-8 byte sequence, which can be passed without copying to external libraries. For data domains richer than what Unicode text can provide, more complex data representations would need to be coded explicitly. Best regards, Mikhail -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Thu May 1 11:06:35 2014 From: ncm at cantrip.org (Nathan Myers) Date: Thu, 01 May 2014 11:06:35 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: <145b8f20158.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> It would be a mistake for a byte sequence container, stream, or string type to know anything about particular encodings. An encoding is an interpretation imposed on a byte sequence. Users of a sequence need to be able to choose what interpretation to apply without interference from some previous user's choice, and without need to make a copy. As an example, a given string may be seen as raw bytes, as a series of delimited records, as Unicode code points within some of those records, as a series of JSON name-value pairs within such a record, and as a decimal number in a JSON value part. The same interpretations need to work on a raw byte stream that would not tolerate in-band Rust-specific annotations. The UTF-8 view of a string is an interesting special case. Depending on context, what is considered a "character" may be a code point of at most 4 bytes, or any number of bytes representing a base and combining characters which might or might not be collapsible to a canonical, single code point, or a series of such constructs that is to be displayed as a ligature such as "Qu" or "ffi". (Some languages are best displayed as mostly ligatures.) Nathan Myers On May 1, 2014 6:54:04 AM Malthe Borch wrote: > In Rust, the built-in std::str type "is a sequence of unicode > codepoints encoded as a stream of UTF-8 bytes". > > Meanwhile, building on experience with Python 2 and 3, I think it's > worth considering a more flexible design. > > A string would be essentially a rope where each leaf specifies an > encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two > bytes). > > That is, a string may be comprised of segments of different encodings. > On the I/O barrier you would then explicitly encode (and flatten) to a > compatible encoding such as UTF-8. > > Likewise, data may be read as 8-bit raw and then "decoded" at a later > stage. For instance, HTTP request headers are ISO8859-1, but the > entire input stream is 8-bit raw. > > Sources: > > - https://maltheborch.com/2014/04/pythons-missing-string-type > - http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From mborch at gmail.com Thu May 1 11:37:21 2014 From: mborch at gmail.com (Malthe Borch) Date: Thu, 1 May 2014 20:37:21 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <145b8f20158.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> References: <145b8f20158.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> Message-ID: On Thursday, May 1, 2014, Nathan Myers wrote: > It would be a mistake for a byte sequence container, stream, or string > type to know anything about particular encodings. An encoding is an > interpretation imposed on a byte sequence. Users of a sequence need to be > able to choose what interpretation to apply without interference from some > previous user's choice, and without need to make a copy. You can "decode" an existing rope with an explicit codec without altering the stream. It's metadata essentially. As an example, from 8-bit raw to UTF-8. The byte stream does not change unless you "encode" (which really transcodes as it flattens the rope). > As an example, a given string may be seen as raw bytes, as a series of > delimited records, as Unicode code points within some of those records, as > a series of JSON name-value pairs within such a record, and as a decimal > number in a JSON value part. The same interpretations need to work on a > raw byte stream that would not tolerate in-band Rust-specific annotations. The encode operation would be free if the rope has only a single leaf and the codec is the same. The UTF-8 view of a string is an interesting special case. Depending on > context, what is considered a "character" may be a code point of at most 4 > bytes, or any number of bytes representing a base and combining characters > which might or might not be collapsible to a canonical, single code point, > or a series of such constructs that is to be displayed as a ligature such > as "Qu" or "ffi". (Some languages are best displayed as mostly ligatures.) > I think it's convenient that the string provides an encoding-aware interface. You normally want to work character by character, not byte by byte, if you have specified an encoding. Otherwise, just don't declare and use 8-bit raw. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Thu May 1 12:03:12 2014 From: bascule at gmail.com (Tony Arcieri) Date: Thu, 1 May 2014 12:03:12 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On Thu, May 1, 2014 at 6:53 AM, Malthe Borch wrote: > A string would be essentially a rope where each leaf specifies an > encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two > bytes). > > That is, a string may be comprised of segments of different encodings. Oh god no! Please no. This is what Ruby does and it's a complete nightmare. This creates an entire new class of bug when operations are performed on strings with incompatible encodings. It's an entire class of bug that simply doesn't exist if you just pick a standard encoding and stick to it. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mborch at gmail.com Thu May 1 13:06:33 2014 From: mborch at gmail.com (Malthe Borch) Date: Thu, 1 May 2014 22:06:33 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On 1 May 2014 21:03, Tony Arcieri wrote: > Oh god no! Please no. This is what Ruby does and it's a complete nightmare. > This creates an entire new class of bug when operations are performed on > strings with incompatible encodings. It's an entire class of bug that simply > doesn't exist if you just pick a standard encoding and stick to it. This is not the case in the proposed design. All string operations would behave exactly as if there was only a single encoding. The only requirement is that the strings are properly declared with an encoding (which may be different). With Ruby and most other languages, a string is just a sequence of bytes. It does not know about an encoding and therefore, the application must always know the encoding used. This is also the case with Python 2.x. Note that it may not always be possible to encode a string to a non-unicode encoding such as ASCII. But this is only a failure mode on the I/O barrier where you explicitly need to encode. When no I/O barrier and/or protocol is involved, there needs to be no awareness of string encodings. Also, note that you can't simply pick a standard encoding and stick with it. To return to the original example of an HTTP request, the header values are ISO 8859-1. If you insist on UTF-8 then you must always transcode. \malthe From mborch at gmail.com Thu May 1 13:25:57 2014 From: mborch at gmail.com (Malthe Borch) Date: Thu, 1 May 2014 22:25:57 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On 1 May 2014 18:54, Mikhail Zabaluev wrote: > I don't think that so much hidden complexity would be justified in the > built-in string type. Encoded text is typically dealt with in protocol > libraries or similar "I/O barriers" where it should be passed through a > validating decoder. std::str is guaranteed (within the usual safety > considerations) to hold a valid UTF-8 byte sequence, which can be passed > without copying to external libraries. For data domains richer than what > Unicode text can provide, more complex data representations would need to be > coded explicitly. I think it's a tremendous value for a programming language to have a single, easy and flexible string type ? that can be trivially used to implement protocols and perform I/O operations, too. And importantly, in all the cases that std::str supports (that is, UTF-8 strings and external libraries that also use UTF-8 strings), the proposed design does not need additional copying. If a string is operated on then it will need to be flattened before an external library can realistically use it, but this is just a form of laziness. \malthe From bascule at gmail.com Thu May 1 13:42:50 2014 From: bascule at gmail.com (Tony Arcieri) Date: Thu, 1 May 2014 13:42:50 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On Thu, May 1, 2014 at 1:06 PM, Malthe Borch wrote: > This is not the case in the proposed design. > You're wrong. > All string operations would behave exactly as if there was only a > single encoding. The only requirement is that the strings are properly > declared with an encoding (which may be different). > Nope, that's not how it works in practice (See below). I speak as someone who has spent blood, sweat, and tears debugging systems that work exactly like what you're proposing. > With Ruby and most other languages, a string is just a sequence of > bytes. It does not know about an encoding Wrong again, and that hasn't been the case for some 7 years. That was the case with Ruby <= 1.8, however Ruby 1.9 introduced a feature called "M17N" which works almost exactly like what you describe: each string is tagged with an encoding which is stored in a bitfield alongside the string object. > Note that it may not always be possible to encode a string to a > non-unicode encoding such as ASCII. But this is only a failure mode on > the I/O barrier where you explicitly need to encode. When no I/O > barrier and/or protocol is involved, there needs to be no awareness of > string encodings. > No, when you combine strings with different encodings, you need to transcode one of the strings. When this happens, the transcoding process may encounter some characters which are valid in one encoding, but not another, in which case the transcoding will fail, and it will fail at runtime. This can happen long after a string has crossed the I/O boundary. The result is errors which pop up at runtime in odd circumstances. This is nothing short of a fucking nightmare to debug. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu May 1 13:55:41 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 01 May 2014 16:55:41 -0400 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: <5362B4CD.3040001@gmail.com> On 01/05/14 09:53 AM, Malthe Borch wrote: > In Rust, the built-in std::str type "is a sequence of unicode > codepoints encoded as a stream of UTF-8 bytes". > > Meanwhile, building on experience with Python 2 and 3, I think it's > worth considering a more flexible design. > > A string would be essentially a rope where each leaf specifies an > encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two > bytes). > > That is, a string may be comprised of segments of different encodings. > On the I/O barrier you would then explicitly encode (and flatten) to a > compatible encoding such as UTF-8. > > Likewise, data may be read as 8-bit raw and then "decoded" at a later > stage. For instance, HTTP request headers are ISO8859-1, but the > entire input stream is 8-bit raw. > > Sources: > > - https://maltheborch.com/2014/04/pythons-missing-string-type > - http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ It needs to be a specific encoding both for sane performance and to make good use of the type system. Unicode doesn't map 1:1 with other encodings so they should be separate types with explicit conversion functions exposed dealing with encoding errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From steve at steveklabnik.com Thu May 1 14:37:20 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Thu, 1 May 2014 14:37:20 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362B4CD.3040001@gmail.com> References: <5362B4CD.3040001@gmail.com> Message-ID: Yes, this is what Ruby does, and yes, it causes a lot of tears. It's one of the biggest things that made the 1.8 -> 1.9 transition difficult. From mborch at gmail.com Thu May 1 14:45:05 2014 From: mborch at gmail.com (Malthe Borch) Date: Thu, 1 May 2014 23:45:05 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On 1 May 2014 22:42, Tony Arcieri wrote: > No, when you combine strings with different encodings, you need to transcode > one of the strings. When this happens, the transcoding process may encounter > some characters which are valid in one encoding, but not another, in which > case the transcoding will fail, and it will fail at runtime. I have not my clear enough then. The transcoding needs to happen only at the time when you "flatten" the rope into a single encoding. And yes, it may then fail if you attempt to encode into a non-unicode encoding. That is, it is perfectly valid to have a rope that consists of strings in different encodings. > This can happen long after a string has crossed the I/O boundary. The result > is errors which pop up at runtime in odd circumstances. This is nothing > short of a fucking nightmare to debug. I agree if that was the case, but it is not. The only time that a run-time error can happen is when you use the "encode" operation which flattens the rope into a single byte stream of a particular encoding. Also, I don't think that string encoding bugs qualify as nightmares ? with all respect. I can think of other scenarios that are several orders of magnitude more troubling. \malthe From pcwalton at mozilla.com Thu May 1 14:52:42 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 01 May 2014 14:52:42 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: <5362C22A.7070201@mozilla.com> On 5/1/14 6:53 AM, Malthe Borch wrote: > In Rust, the built-in std::str type "is a sequence of unicode > codepoints encoded as a stream of UTF-8 bytes". > > Meanwhile, building on experience with Python 2 and 3, I think it's > worth considering a more flexible design. > > A string would be essentially a rope where each leaf specifies an > encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two > bytes). This is too complex for a systems language with a simple library. Patrick From jdowney at gmail.com Thu May 1 15:03:04 2014 From: jdowney at gmail.com (John Downey) Date: Thu, 1 May 2014 17:03:04 -0500 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: <5362B4CD.3040001@gmail.com> Message-ID: I have actually always been a fan of how .NET did this. The System.String type is opinionated in how it is stored internally and does not allow anyone to change that (unlike Ruby). The conversion from String to byte[] is done using explicit conversion methods like: - Encoding.UTF8.GetBytes(String) - Encoding.UTF8.GetString(byte[]) - Encoding.UTF32.GetBytes(String) - Encoding.UTF32.GetString(byte[]) - and so on That way if you end up with a bunch of bytes, you know exactly what those bytes represent. On Thu, May 1, 2014 at 4:37 PM, Steve Klabnik wrote: > Yes, this is what Ruby does, and yes, it causes a lot of tears. It's > one of the biggest things that made the 1.8 -> 1.9 transition > difficult. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- John Downey -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Thu May 1 15:06:15 2014 From: bascule at gmail.com (Tony Arcieri) Date: Thu, 1 May 2014 15:06:15 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On Thu, May 1, 2014 at 2:45 PM, Malthe Borch wrote: > The transcoding needs to happen only at the time when you "flatten" > the rope into a single encoding. And yes, it may then fail if you > attempt to encode into a non-unicode encoding. > This sounds like the exact same painful failure mode as Ruby (transcoding blowing up at completely unexpected times) with even more complexity, making it even harder to debug. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Thu May 1 15:09:27 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 1 May 2014 17:09:27 -0500 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362C22A.7070201@mozilla.com> References: <5362C22A.7070201@mozilla.com> Message-ID: Agreed with Patrick. This proposal should not be in std::str ... it can live somewhere else...but not there. -- -Thad +ThadGuidry Thad on LinkedIn On Thu, May 1, 2014 at 4:52 PM, Patrick Walton wrote: > On 5/1/14 6:53 AM, Malthe Borch wrote: > >> In Rust, the built-in std::str type "is a sequence of unicode >> codepoints encoded as a stream of UTF-8 bytes". >> >> Meanwhile, building on experience with Python 2 and 3, I think it's >> worth considering a more flexible design. >> >> A string would be essentially a rope where each leaf specifies an >> encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two >> bytes). >> > > This is too complex for a systems language with a simple library. > > Patrick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Thu May 1 16:49:16 2014 From: ncm at cantrip.org (Nathan Myers) Date: Thu, 01 May 2014 16:49:16 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362C22A.7070201@mozilla.com> References: <5362C22A.7070201@mozilla.com> Message-ID: <5362DD7C.7020005@cantrip.org> On 05/01/2014 02:52 PM, Patrick Walton wrote: > On 5/1/14 6:53 AM, Malthe Borch wrote: >> In Rust, the built-in std::str type "is a sequence of unicode >> codepoints encoded as a stream of UTF-8 bytes". >> ... >> A string would be essentially a rope where each leaf specifies an >> encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two >> bytes). > > This is too complex for a systems language with a simple library. In defining a library string we always grapple over how it should differ from a raw (variable or fixed) array of bytes. Ease of appending and of assigning into substrings always comes up. In the old days, copies shared storage, but nowadays that's considered evil. Indexed random access lookup was once thought essential, but with today's variable-sized characters, strings have become sequential structures. We might snip out a substring and splice another in its place, but we must identify those places by stepping iterators to them. We need to put string values in partial or total order, but no single ordering is compellingly best. Equality depends on context. The outcome is that the context-independent requirements on strings may not differ enough from an array of bytes to justify a separate type. We might better give our byte arrays a few stringy capabilities. Most users of strings don't need to know anything about what's in them, and can operate on the raw byte arrays. To use a string as a map key, though, implies choices: fold case? canonicalize sequences? We need an object that can remember your choices, and that the map can apply to strings given to it. Ideally what we use to express our interpretation of some set of strings could be used on any sequence of bytes, not necessarily contiguous in memory, not necessarily all in memory at once, not necessarily even produced until called for. The history of programming languages is littered with mistakes around string types. There's no reason why Rust must repeat them all. Nathan Myers From danielmicay at gmail.com Thu May 1 16:57:18 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 01 May 2014 19:57:18 -0400 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362DD7C.7020005@cantrip.org> References: <5362C22A.7070201@mozilla.com> <5362DD7C.7020005@cantrip.org> Message-ID: <5362DF5E.1080106@gmail.com> On 01/05/14 07:49 PM, Nathan Myers wrote: > On 05/01/2014 02:52 PM, Patrick Walton wrote: >> On 5/1/14 6:53 AM, Malthe Borch wrote: >>> In Rust, the built-in std::str type "is a sequence of unicode >>> codepoints encoded as a stream of UTF-8 bytes". >>> ... >>> A string would be essentially a rope where each leaf specifies an >>> encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two >>> bytes). >> >> This is too complex for a systems language with a simple library. > > In defining a library string we always grapple over how it > should differ from a raw (variable or fixed) array of bytes. > Ease of appending and of assigning into substrings always > comes up. In the old days, copies shared storage, but nowadays > that's considered evil. Indexed random access lookup was once > thought essential, but with today's variable-sized characters, > strings have become sequential structures. We might snip out a > substring and splice another in its place, but we must identify > those places by stepping iterators to them. We need to put string values > in partial or total order, but no single ordering is > compellingly best. Equality depends on context. > > The outcome is that the context-independent requirements on > strings may not differ enough from an array of bytes to justify > a separate type. We might better give our byte arrays a few > stringy capabilities. Most users of strings don't need to know > anything about what's in them, and can operate on the raw byte > arrays. To use a string as a map key, though, implies choices: > fold case? canonicalize sequences? We need an object that can > remember your choices, and that the map can apply to strings > given to it. > > Ideally what we use to express our interpretation of some set > of strings could be used on any sequence of bytes, not necessarily > contiguous in memory, not necessarily all in memory at once, > not necessarily even produced until called for. > > The history of programming languages is littered with mistakes > around string types. There's no reason why Rust must repeat > them all. > > Nathan Myers There's a string type because it *enforces* the guarantee of containing valid UTF-8, meaning it can always be converted to code points. This also means all of the Unicode algorithms can assume that they're dealing with a valid sequence of code points with no out-of-range values or surrogates, per the specification. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From bascule at gmail.com Thu May 1 16:57:05 2014 From: bascule at gmail.com (Tony Arcieri) Date: Thu, 1 May 2014 16:57:05 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362DD7C.7020005@cantrip.org> References: <5362C22A.7070201@mozilla.com> <5362DD7C.7020005@cantrip.org> Message-ID: On Thu, May 1, 2014 at 4:49 PM, Nathan Myers wrote: > The history of programming languages is littered with mistakes > around string types. There's no reason why Rust must repeat > them all. FWIW, I've worked in systems that work the way you describe, and I disagree and think Rust is doing something that's close to what I'd consider to be the right thing. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Thu May 1 17:52:51 2014 From: ncm at cantrip.org (Nathan Myers) Date: Thu, 01 May 2014 17:52:51 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362DF5E.1080106@gmail.com> References: <5362C22A.7070201@mozilla.com> <5362DD7C.7020005@cantrip.org> <5362DF5E.1080106@gmail.com> Message-ID: <5362EC63.7050702@cantrip.org> On 05/01/2014 04:57 PM, Daniel Micay wrote: > On 01/05/14 07:49 PM, Nathan Myers wrote: >> In defining a library string we always grapple over how it >> should differ from a raw (variable or fixed) array of bytes. >> Ease of appending and of assigning into substrings always >> comes up. In the old days, copies shared storage, but nowadays >> that's considered evil. Indexed random access lookup was once >> thought essential, but with today's variable-sized characters, >> strings have become sequential structures. We might snip out a >> substring and splice another in its place, but we must identify >> those places by stepping iterators to them. We need to put >> string values in partial or total order, but no single ordering >> is compellingly best. Equality depends on context. >> >> The outcome is that the context-independent requirements on >> strings may not differ enough from an array of bytes to justify >> a separate type. We might better give our byte arrays a few >> stringy capabilities. Most users of strings don't need to know >> anything about what's in them, and can operate on the raw byte >> arrays. To use a string as a map key, though, implies choices: >> fold case? canonicalize sequences? We need an object that can >> remember your choices, and that the map can apply to strings >> given to it. >> >> Ideally what we use to express our interpretation of some set >> of strings could be used on any sequence of bytes, not necessarily >> contiguous in memory, not necessarily all in memory at once, >> not necessarily even produced until called for. >> >> The history of programming languages is littered with mistakes >> around string types. There's no reason why Rust must repeat >> them all. >> >> Nathan Myers > > There's a string type because it *enforces* the guarantee of containing > valid UTF-8, meaning it can always be converted to code points. This > also means all of the Unicode algorithms can assume that they're dealing > with a valid sequence of code points with no out-of-range values or > surrogates, per the specification. A UTF-8 string type can certainly earn its keep. (Probably it should have "utf8" somewhere in its name.) Not all byte sequences a program encounters are, or can or should be converted to, valid UTF-8. Any that might not be must still be put in something that users probably want to call a string. The other issues remain; there are many equally valid orderings for UTF-8 sequences, so any fixed choice will often be wrong. A discriminated string type that may be matched at runtime as a valid UTF-8 sequence or not depending on what was last put in it would probably be useful often enough to want it in std. Nathan Myers From bklooste at gmail.com Fri May 2 00:30:11 2014 From: bklooste at gmail.com (Ben Kloosterman) Date: Fri, 2 May 2014 17:30:11 +1000 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: <5362B4CD.3040001@gmail.com> Message-ID: The encoding / glob. code in .NET works well , the strings use of code-points is poor choice and both C# and Java suffer heavily for it when doing IO. Ropes / chords/ chains etc belong at a higher level not the lowest level type. Ben On Fri, May 2, 2014 at 8:03 AM, John Downey wrote: > I have actually always been a fan of how .NET did this. The System.String > type is opinionated in how it is stored internally and does not allow > anyone to change that (unlike Ruby). The conversion from String to byte[] > is done using explicit conversion methods like: > > - Encoding.UTF8.GetBytes(String) > - Encoding.UTF8.GetString(byte[]) > - Encoding.UTF32.GetBytes(String) > - Encoding.UTF32.GetString(byte[]) > - and so on > > That way if you end up with a bunch of bytes, you know exactly what those > bytes represent. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mborch at gmail.com Fri May 2 00:55:20 2014 From: mborch at gmail.com (Malthe Borch) Date: Fri, 2 May 2014 09:55:20 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On 2 May 2014 00:06, Tony Arcieri wrote: > This sounds like the exact same painful failure mode as Ruby (transcoding > blowing up at completely unexpected times) with even more complexity, making > it even harder to debug. Here is a concrete example of when this would blow up: 1. You have a rope with non-ascii characters. 2. You attempt to "encode" into "ascii". It blows up ? as expected, because "ascii" is a limited encoding. It will only ever fail during the explicit "encode" operation. How is that unexpected? All code that needs an output in "ascii" must consider whether the input is compatible. In Ruby (as I understand it now), any string operation that involves two or more strings can blow up at run-time because of the implicit transcoding. This is not how the proposed rope-like data structure would work. \malthe From bklooste at gmail.com Fri May 2 02:06:24 2014 From: bklooste at gmail.com (Ben Kloosterman) Date: Fri, 2 May 2014 19:06:24 +1000 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On 5/2/14, Malthe Borch wrote: > On 2 May 2014 00:06, Tony Arcieri wrote: >> This sounds like the exact same painful failure mode as Ruby (transcoding >> blowing up at completely unexpected times) with even more complexity, >> making >> it even harder to debug. > > Here is a concrete example of when this would blow up: > > 1. You have a rope with non-ascii characters. > 2. You attempt to "encode" into "ascii". > > I don't think this is the structure he is talking about. I think something heavier that contains the encoding type and some sort of reference to the next set of chars which may have a different encoding. . . works well with dependent types. Ben From mikhail.zabaluev at gmail.com Fri May 2 03:32:00 2014 From: mikhail.zabaluev at gmail.com (Mikhail Zabaluev) Date: Fri, 2 May 2014 13:32:00 +0300 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <5362EC63.7050702@cantrip.org> References: <5362C22A.7070201@mozilla.com> <5362DD7C.7020005@cantrip.org> <5362DF5E.1080106@gmail.com> <5362EC63.7050702@cantrip.org> Message-ID: Hi, 2014-05-02 3:52 GMT+03:00 Nathan Myers : > > There's a string type because it *enforces* the guarantee of containing >> valid UTF-8, meaning it can always be converted to code points. This >> also means all of the Unicode algorithms can assume that they're dealing >> with a valid sequence of code points with no out-of-range values or >> surrogates, per the specification. >> > > A UTF-8 string type can certainly earn its keep. (Probably it should > have "utf8" somewhere in its name.) Not all byte sequences a program > encounters are, or can or should be converted to, valid UTF-8. Any > that might not be must still be put in something that users probably > want to call a string. But is it the case for the standard string? What you describe is a sequence of bytes with application-defined encoding. There might be a custom type for it, with an API for conversion and validation. There is, however, value in the core language string type that is 1) guaranteed to contain a valid Unicode character sequence; 2) readily interoperable with C functions expecting char* strings having either ASCII or UTF-8 encoding. Best regards, Mikhail -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Fri May 2 04:12:41 2014 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 2 May 2014 13:12:41 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: On Thu, May 1, 2014 at 10:42 PM, Tony Arcieri wrote: > You're wrong. Though I agree with what you are arguing, starting emails in such a blunt and dismissive way does not further a pleasant mailing list climate, and I'd like to ask you to try and be more emphatic in the future. Best, Marijn From mborch at gmail.com Fri May 2 04:29:25 2014 From: mborch at gmail.com (Malthe Borch) Date: Fri, 2 May 2014 11:29:25 +0000 (UTC) Subject: [rust-dev] UTF-8 strings versus "encoded ropes" References: Message-ID: Ben Kloosterman writes: > On 5/2/14, Malthe Borch wrote: > > I don't think this is the structure he is talking about. I think > something heavier that contains the encoding type and some sort of > reference to the next set of chars which may have a different > encoding. . . works well with dependent types. A basic implementation was available in the standard library until recently: http://static.rust-lang.org/doc/0.7/std/rope.html. And yes, basically every leaf in the rope is a tuple (char*, encoding) where encoding is something that resolves to a codec. From artella.coding at googlemail.com Sat May 3 02:27:08 2014 From: artella.coding at googlemail.com (Artella Coding) Date: Sat, 3 May 2014 10:27:08 +0100 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec Message-ID: Hi looking at https://github.com/rust-lang/rfcs/pull/59 , is it the case that the following replacement rules apply : 1) ~T is replaced by Box 2) ~[T] is replaced by Vec and what does little "box" (as opposed to Box) do? When will these changes appear in the nightlies? I am using "rustc 0.11-pre-nightly (e97d4e6 2014-05-01 23:41:46 -0700)" and the changes don't seem to have appeared yet. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Sat May 3 03:12:24 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Sat, 3 May 2014 03:12:24 -0700 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: References: Message-ID: Yes, yes, and let x = box 5; let x = ~5; same thing. It's also more general: let x = box(GC) 5; and lets all of these pointers support placement new, which only ~ did previously: fn foo() -> int { ... let x = box foo(); Now that the RFC has been accepted, patches can be written. It'll be a few days before you'll see the change in code. From igor at mir2.org Sat May 3 05:29:32 2014 From: igor at mir2.org (Igor Bukanov) Date: Sat, 3 May 2014 14:29:32 +0200 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: References: Message-ID: On 3 May 2014 12:12, Steve Klabnik wrote: > It's also more general: > > let x = box(GC) 5; > Would x here have a copy semantic like plain numbers or would it still use move as box(Heap) 5 will? From dpx.infinity at gmail.com Sat May 3 05:35:04 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Sat, 3 May 2014 16:35:04 +0400 Subject: [rust-dev] References to trait objects are not cloneable Message-ID: Hi all, I posted this question on [Stack Overflow][1], but it is yet to be answered there, so I ask here too. Why reference to traits are not cloneable? The following code compiles: struct Test; fn clone_vec<'a>(v: Vec<&'a Test>) -> Vec<&'a Test> { v.clone() } But this one doesn't: trait Test { fn do_smt(&self); } fn clone_vec<'a>(v: Vec<&'a Test>) -> Vec<&'a Test> { v.clone() } It spits this error: main3.rs:7:5: 7:14 error: failed to find an implementation of trait std::clone::Clone for &'a Test main3.rs:7 v.clone() ^~~~~~~~~ However, Clone trait is implemented for all kinds of references, as far as I can see. I just don't see why &'a Test where Test is a trait is not cloneable. This is very strange provided that I can implement clone_vec() myself, without using Clone: fn clone_vec<'a>(v: Vec<&'a Test>) -> Vec<&'a Test> { let mut result = Vec::new(); for &e in v.iter() { result.push(e); } result } It works just fine. If this is a bug, I would gladly submit it to the tracker, but I'm not sure that I'm not doing something wrong. [1]: http://stackoverflow.com/questions/23426545/references-to-trait-objects-are-not-cloneable From tehunger at gmail.com Sat May 3 15:26:01 2014 From: tehunger at gmail.com (Thomas Hunger) Date: Sat, 3 May 2014 23:26:01 +0100 Subject: [rust-dev] Trait question (error: type `&mut Self` does not implement any method in scope named `read_le_u16`) Message-ID: Hi, I'm currently trying to implement a protocol in rust nightly [1]. The (stylized) code looks like this: [...] trait PlanReader { // read [s] type fn read_9p_s(&mut self) -> io::IoResult<~str> { let n = self.read_le_u16().unwrap(); let s = str::from_chars(self.chars().take(n)).unwrap(); return result::Ok(s); } } [...] but it throws an error on compiling: [1] $ rustc -v rustc 0.11-pre-nightly (5c0abea 2014-05-01 00:56:48 -0700) host: x86_64-unknown-linux-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From tehunger at gmail.com Sat May 3 15:28:08 2014 From: tehunger at gmail.com (Thomas Hunger) Date: Sat, 3 May 2014 23:28:08 +0100 Subject: [rust-dev] Trait question (error: type `&mut Self` does not implement any method in scope named `read_le_u16`) In-Reply-To: References: Message-ID: Apologies, here's the rest of my message: the error is. src/server.rs:36:22: 36:35 error: type `&mut Self` does not implement any method in scope named `read_le_u16` src/server.rs:36 let n = self.read_le_u16().unwrap(); I'm intending to bound the type of the trait to Reader but I'm not sure I'm doing the right thing. Would you know where I'm wrong? Thanks & best, ~ On 3 May 2014 23:26, Thomas Hunger wrote: > Hi, > > I'm currently trying to implement a protocol in rust nightly [1]. The > (stylized) code looks like this: > > [...] > > trait PlanReader { > // read [s] type > fn read_9p_s(&mut self) -> io::IoResult<~str> { > let n = self.read_le_u16().unwrap(); > let s = str::from_chars(self.chars().take(n)).unwrap(); > return result::Ok(s); > } > } > [...] > > but it throws an error on compiling: > > > [1] > $ rustc -v > rustc 0.11-pre-nightly (5c0abea 2014-05-01 00:56:48 -0700) > host: x86_64-unknown-linux-gnu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Sat May 3 22:08:37 2014 From: comexk at gmail.com (comex) Date: Sun, 4 May 2014 01:08:37 -0400 Subject: [rust-dev] Trait question (error: type `&mut Self` does not implement any method in scope named `read_le_u16`) In-Reply-To: References: Message-ID: On Sat, May 3, 2014 at 6:26 PM, Thomas Hunger wrote: > trait PlanReader { > // read [s] type > fn read_9p_s(&mut self) -> io::IoResult<~str> { > let n = self.read_le_u16().unwrap(); > let s = str::from_chars(self.chars().take(n)).unwrap(); > return result::Ok(s); > } > } This declares PlanReader as being parameterized by some type that implements io::Reader, but that type has nothing to do with Self. Also, method implementations in trait definitions are only defaults for types that implement the trait; an impl is still required to declare that a type implements it. You probably want: trait PlanReader { fn read_9p_s(&mut self) -> io::IoResult<~str>; } impl PlanReader for R { fn read_9p_s(&mut self) -> io::IoResult<~str> { ... } } From simon80 at gmail.com Sun May 4 12:13:07 2014 From: simon80 at gmail.com (Simon Ruggier) Date: Sun, 4 May 2014 15:13:07 -0400 Subject: [rust-dev] Private trait items In-Reply-To: <5AEB7055-3518-4189-B0B1-D97ED7C4F83C@icloud.com> References: <948EDBC2-0C08-4E96-B034-C2B00E93692B@icloud.com> <5356B893.2010107@mozilla.com> <5AEB7055-3518-4189-B0B1-D97ED7C4F83C@icloud.com> Message-ID: Hi Tommi, I think that, rather than creating a second fork, you'd want to create a second git branch in same repository that you cloned from the original fork, commit your second RFC in the new branch you just made, push that branch back out to github, and then use the second branch to create your pull request. See http://git-scm.com/documentation and https://help.github.com/articles/creating-a-pull-request for more information. On Tue, Apr 22, 2014 at 5:57 PM, Tommi wrote: > On 2014-04-22, at 21:44, Brian Anderson wrote: > > I'm not sure what you are asking for here. Have you submitted this as a > pull request to http://github.com/rust-lang/rfcs? > > > No, I haven't made the pull request, because I don't know how to do that > (or perhaps I would know how to do that, if I knew how to create a fork for > the second time of the same thing). I'm not even sure of what exactly it is > that I'm not capable of doing. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brogoff at gmail.com Sun May 4 15:01:56 2014 From: brogoff at gmail.com (Brian Rogoff) Date: Sun, 4 May 2014 15:01:56 -0700 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: References: Message-ID: On Sat, May 3, 2014 at 2:27 AM, Artella Coding < artella.coding at googlemail.com> wrote: > Hi looking at https://github.com/rust-lang/rfcs/pull/59 , is it the case > that the following replacement rules apply : > > 1) ~T is replaced by Box > 2) ~[T] is replaced by Vec > > and what does little "box" (as opposed to Box) do? > I have some code that makes a matrix of nested slices that looks like this (make_owned_slice is a helper fn) fn make_owned_slice(n: uint, default: T) -> ~[T] { Vec::from_elem(n, default).as_slice().to_owned() } fn make_matrix(nrows: uint, ncols: uint, default: T) -> ~[~[T]] { make_owned_slice(nrows, make_owned_slice(ncols, default)) } Is that code going to become the following fn make_matrix(nrows: uint, ncols: uint, default: T) -> Vec> { Vec::from_elem(nrows, Vec::from_elem(ncols, default)) } and will I be able to index matrices of Vec> like matrix[i][j]? Last time I checked vectors weren't indexable that way. > > When will these changes appear in the nightlies? I am using "rustc > 0.11-pre-nightly (e97d4e6 2014-05-01 23:41:46 -0700)" and the changes don't > seem to have appeared yet. Thanks > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Sun May 4 15:09:13 2014 From: sfackler at gmail.com (Steven Fackler) Date: Sun, 4 May 2014 15:09:13 -0700 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: References: Message-ID: That will be possible, but the Index trait needs to be overhauled first. Steven Fackler On Sun, May 4, 2014 at 3:01 PM, Brian Rogoff wrote: > On Sat, May 3, 2014 at 2:27 AM, Artella Coding < > artella.coding at googlemail.com> wrote: > >> Hi looking at https://github.com/rust-lang/rfcs/pull/59 , is it the case >> that the following replacement rules apply : >> >> 1) ~T is replaced by Box >> 2) ~[T] is replaced by Vec >> >> and what does little "box" (as opposed to Box) do? >> > > I have some code that makes a matrix of nested slices that looks like this > (make_owned_slice is a helper fn) > > fn make_owned_slice(n: uint, default: T) -> ~[T] { > Vec::from_elem(n, default).as_slice().to_owned() > } > > fn make_matrix(nrows: uint, ncols: uint, default: T) -> ~[~[T]] { > make_owned_slice(nrows, make_owned_slice(ncols, default)) > } > > Is that code going to become the following > > fn make_matrix(nrows: uint, ncols: uint, default: T) -> > Vec> { > Vec::from_elem(nrows, Vec::from_elem(ncols, default)) > } > > and will I be able to index matrices of Vec> like matrix[i][j]? > Last time I checked vectors weren't indexable that way. > > > > >> >> When will these changes appear in the nightlies? I am using "rustc >> 0.11-pre-nightly (e97d4e6 2014-05-01 23:41:46 -0700)" and the changes don't >> seem to have appeared yet. Thanks >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Sun May 4 15:54:59 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 4 May 2014 15:54:59 -0700 Subject: [rust-dev] Announcing ClearCrypt: a new transport encryption library Message-ID: ClearCrypt's goal is to produce a minimalist transport encryption library written in a memory-safe language: Rust. Web site: http://clearcrypt.org/ The problem: http://clearcrypt.org/tls/ Github repo: https://github.com/clearcrypt/clearcrypt The project is presently complete vaporware, but the goal is to produce a Rust implementation of a next generation transport encryption library. The protocol itself is still up for debate, but will likely be based off CurveCP or Noise. Emphasis will be placed on simplicity, clarity, and audibility. New features will be rejected unless they meet these goals. Every commit will be approved by multiple people once it has been thoroughly audited. First up: the choice of a license: https://github.com/clearcrypt/clearcrypt/pull/1 -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From brogoff at gmail.com Sun May 4 16:03:54 2014 From: brogoff at gmail.com (Brian Rogoff) Date: Sun, 4 May 2014 16:03:54 -0700 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: References: Message-ID: Fair enough, but I hope that the Index trait overhaul is merged before the ability to use slices like this is removed. To do otherwise would be unpleasant. On Sun, May 4, 2014 at 3:09 PM, Steven Fackler wrote: > That will be possible, but the Index trait needs to be overhauled first. > > Steven Fackler > > > On Sun, May 4, 2014 at 3:01 PM, Brian Rogoff wrote: > >> On Sat, May 3, 2014 at 2:27 AM, Artella Coding < >> artella.coding at googlemail.com> wrote: >> >>> Hi looking at https://github.com/rust-lang/rfcs/pull/59 , is it the >>> case that the following replacement rules apply : >>> >>> 1) ~T is replaced by Box >>> 2) ~[T] is replaced by Vec >>> >>> and what does little "box" (as opposed to Box) do? >>> >> >> I have some code that makes a matrix of nested slices that looks like >> this (make_owned_slice is a helper fn) >> >> fn make_owned_slice(n: uint, default: T) -> ~[T] { >> Vec::from_elem(n, default).as_slice().to_owned() >> } >> >> fn make_matrix(nrows: uint, ncols: uint, default: T) -> ~[~[T]] { >> make_owned_slice(nrows, make_owned_slice(ncols, default)) >> } >> >> Is that code going to become the following >> >> fn make_matrix(nrows: uint, ncols: uint, default: T) -> >> Vec> { >> Vec::from_elem(nrows, Vec::from_elem(ncols, default)) >> } >> >> and will I be able to index matrices of Vec> like matrix[i][j]? >> Last time I checked vectors weren't indexable that way. >> >> >> >> >>> >>> When will these changes appear in the nightlies? I am using "rustc >>> 0.11-pre-nightly (e97d4e6 2014-05-01 23:41:46 -0700)" and the changes don't >>> seem to have appeared yet. Thanks >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun May 4 16:10:05 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 04 May 2014 19:10:05 -0400 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: References: Message-ID: <5366C8CD.4020301@gmail.com> On 04/05/14 07:03 PM, Brian Rogoff wrote: > Fair enough, but I hope that the Index trait overhaul is merged before > the ability to use slices like this is removed. To do otherwise would be > unpleasant. The ability to grow ~[T] was already removed, and it would be really nice to remove the remaining users to improve performance by avoiding expensive conversions from Vec. The original motivation behind Vec was a performance one (it was just going to become the ~[T] implementation via a lang item) so it's quite sad that we've introduced a whole bunch of O(n) copies throughout the compiler to previously O(1) algorithms. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From brogoff at gmail.com Sun May 4 16:38:23 2014 From: brogoff at gmail.com (Brian Rogoff) Date: Sun, 4 May 2014 16:38:23 -0700 Subject: [rust-dev] Removal of sigils : ~T,~[T], Box, Vec In-Reply-To: <5366C8CD.4020301@gmail.com> References: <5366C8CD.4020301@gmail.com> Message-ID: Right, I don't need these matrices to grow, I know their permanent sizes when I create them, and I used to use slices::from_elem but that went away a few days ago. I always assumed that ~[T] was more like a builtin, fixed size, array, and Vec a growable vector. I imagine that this will all get sorted out one day, and I can accept these inefficiencies now since I don't use Rust for real work yet, but I would be disappointed if array index notation is removed from the default array-like type. On Sun, May 4, 2014 at 4:10 PM, Daniel Micay wrote: > On 04/05/14 07:03 PM, Brian Rogoff wrote: > > Fair enough, but I hope that the Index trait overhaul is merged before > > the ability to use slices like this is removed. To do otherwise would be > > unpleasant. > > The ability to grow ~[T] was already removed, and it would be really > nice to remove the remaining users to improve performance by avoiding > expensive conversions from Vec. The original motivation behind Vec > was a performance one (it was just going to become the ~[T] > implementation via a lang item) so it's quite sad that we've introduced > a whole bunch of O(n) copies throughout the compiler to previously O(1) > algorithms. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at urbanhafner.com Mon May 5 00:36:41 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Mon, 5 May 2014 09:36:41 +0200 Subject: [rust-dev] How to compile large programs Message-ID: Hey all, a question from a Rust newbie here. From languages like C or C++ I'm used to being able to compile each file separately into object files to speed up the compilation process. In Rust that doesn't seem to be easily possible. I tried to simulate it by compiling each module into a separate library, but it has been pointed out to me that it's not idiomatic but may not even improve performance [1]. As this stack overflow question is quite hidden away I'd love to get everyone's input. And even though writing the automatic Makefile [2] for it was fun I wouldn't mind having an easier solution. Urban [1] http://stackoverflow.com/questions/23385582/problems-with-gnu-make-dynamic-rules [2] https://github.com/ujh/iomrascalai/blob/3d37ddd95c2058386f748f23c1a2b2e538375093/Makefile -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nical.silva at gmail.com Mon May 5 01:15:05 2014 From: nical.silva at gmail.com (Nicolas Silva) Date: Mon, 5 May 2014 10:15:05 +0200 Subject: [rust-dev] How to compile large programs In-Reply-To: References: Message-ID: In large C++ projects (take Firefox as an example), it's actually the other way around: merging a lot of .cpp files to compile larger but fewer translation units gives you *much* faster builds (and better optimization, at least without LTO). My advice is to split your (large) program into a few libs where it makes sense, but to not go as far as putting each module in its own lib. Cheers, Nical On Mon, May 5, 2014 at 9:36 AM, Urban Hafner wrote: > Hey all, > > a question from a Rust newbie here. From languages like C or C++ I'm used > to being able to compile each file separately into object files to speed up > the compilation process. In Rust that doesn't seem to be easily possible. I > tried to simulate it by compiling each module into a separate library, but > it has been pointed out to me that it's not idiomatic but may not even > improve performance [1]. As this stack overflow question is quite hidden > away I'd love to get everyone's input. And even though writing the > automatic Makefile [2] for it was fun I wouldn't mind having an easier > solution. > > Urban > > [1] > http://stackoverflow.com/questions/23385582/problems-with-gnu-make-dynamic-rules > [2] > https://github.com/ujh/iomrascalai/blob/3d37ddd95c2058386f748f23c1a2b2e538375093/Makefile > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon May 5 10:14:33 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 05 May 2014 13:14:33 -0400 Subject: [rust-dev] How to compile large programs In-Reply-To: References: Message-ID: <5367C6F9.8060700@gmail.com> On 05/05/14 03:36 AM, Urban Hafner wrote: > Hey all, > > a question from a Rust newbie here. From languages like C or C++ I'm > used to being able to compile each file separately into object files to > speed up the compilation process. In Rust that doesn't seem to be easily > possible. I tried to simulate it by compiling each module into a > separate library, but it has been pointed out to me that it's not > idiomatic but may not even improve performance [1]. As this stack > overflow question is quite hidden away I'd love to get everyone's input. > And even though writing the automatic Makefile [2] for it was fun I > wouldn't mind having an easier solution. Crates are Rust's compilation unit, so splitting into many crates is equivalent to splitting into many object files in C++. It's true that splitting will often not improve compile time, but that applies just as much to C++. If your goal is to improve compile-time, then you need to think carefully about how you organize the crates. Keep in mind that generic / inline code will be recompiled for each crate using the code. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From contact at urbanhafner.com Mon May 5 10:54:02 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Mon, 5 May 2014 19:54:02 +0200 Subject: [rust-dev] How to compile large programs In-Reply-To: <5367C6F9.8060700@gmail.com> References: <5367C6F9.8060700@gmail.com> Message-ID: Thanks guys. I guess it just shows that I've never written any large C++ programs either :) So for now I'll stick to recompiling everything at once and if it slows down too much I'll see where it makes sense to split it up then. Urban On Mon, May 5, 2014 at 7:14 PM, Daniel Micay wrote: > On 05/05/14 03:36 AM, Urban Hafner wrote: > > Hey all, > > > > a question from a Rust newbie here. From languages like C or C++ I'm > > used to being able to compile each file separately into object files to > > speed up the compilation process. In Rust that doesn't seem to be easily > > possible. I tried to simulate it by compiling each module into a > > separate library, but it has been pointed out to me that it's not > > idiomatic but may not even improve performance [1]. As this stack > > overflow question is quite hidden away I'd love to get everyone's input. > > And even though writing the automatic Makefile [2] for it was fun I > > wouldn't mind having an easier solution. > > Crates are Rust's compilation unit, so splitting into many crates is > equivalent to splitting into many object files in C++. It's true that > splitting will often not improve compile time, but that applies just as > much to C++. If your goal is to improve compile-time, then you need to > think carefully about how you organize the crates. Keep in mind that > generic / inline code will be recompiled for each crate using the code. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From messerb at clarkson.edu Mon May 5 11:33:32 2014 From: messerb at clarkson.edu (Brad Messer - messerb) Date: Mon, 5 May 2014 18:33:32 +0000 Subject: [rust-dev] Cryptography Library Message-ID: Hello Everyone! My name is Bradley Messer and I am a senior Computer Science and Mathematics student at Clarkson University. I was speaking with a developer and was told that Rust was in need of a crypto library. I would like to write one, but I would like to know which protocols would be helpful to have in it. Thank you! Bradley Messer -------------- next part -------------- An HTML attachment was scrubbed... URL: From richo at psych0tik.net Mon May 5 11:35:41 2014 From: richo at psych0tik.net (Richo Healey) Date: Mon, 5 May 2014 11:35:41 -0700 Subject: [rust-dev] Cryptography Library In-Reply-To: References: Message-ID: <20140505183541.GA93149@xenia.local> On 05/05/14 18:33 +0000, Brad Messer - messerb wrote: >Hello Everyone! > >My name is Bradley Messer and I am a senior Computer Science and Mathematics student at Clarkson University. I was speaking with a developer and was told that Rust was in need of a crypto library. I would like to write one, but I would like to know which protocols would be helpful to have in it. > >Thank you! > >Bradley Messer Hi Bradley, You might want to have a look at clearcrypt[1]. It is basically vaporwhere at this point, but that seems to be the most plausible direction we're moving in. Cheers richo [1]: https://github.com/clearcrypt/clearcrypt From smcarthur at mozilla.com Mon May 5 11:37:59 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Mon, 05 May 2014 11:37:59 -0700 Subject: [rust-dev] Cryptography Library In-Reply-To: <20140505183541.GA93149@xenia.local> References: <20140505183541.GA93149@xenia.local> Message-ID: There's rust-crypto[1], which has quite a few implementations already. The issue isn't so much that Rust needs crypto?code, is that it needs auditing of the code that exists. [1]?https://github.com/DaGenix/rust-crypto -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Mon May 5 11:42:16 2014 From: jon.mb at proinbox.com (John Mija) Date: Mon, 05 May 2014 19:42:16 +0100 Subject: [rust-dev] Cryptography Library In-Reply-To: <20140505183541.GA93149@xenia.local> References: <20140505183541.GA93149@xenia.local> Message-ID: <5367DB88.4030503@proinbox.com> I like the project clearcrypt and it is awesome that developers start to build different algorithms than standard ones. But it's also necessary to have the most used algorithms, like i.e.: aes rsa des hmac md5 rsa sha1, sha256, sha512 As reference, the Go team added some basic algorithms to the standard library: http://golang.org/pkg/crypto/ El 05/05/14 19:35, Richo Healey escribi?: > On 05/05/14 18:33 +0000, Brad Messer - messerb wrote: >> Hello Everyone! >> >> My name is Bradley Messer and I am a senior Computer Science and >> Mathematics student at Clarkson University. I was speaking with a >> developer and was told that Rust was in need of a crypto library. I >> would like to write one, but I would like to know which protocols >> would be helpful to have in it. >> >> Thank you! >> >> Bradley Messer > > Hi Bradley, > > You might want to have a look at clearcrypt[1]. It is basically > vaporwhere at > this point, but that seems to be the most plausible direction we're moving > in. > > Cheers > > richo > > [1]: https://github.com/clearcrypt/clearcrypt > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > From richo at psych0tik.net Mon May 5 11:45:21 2014 From: richo at psych0tik.net (Richo Healey) Date: Mon, 5 May 2014 11:45:21 -0700 Subject: [rust-dev] Cryptography Library In-Reply-To: <5367DB88.4030503@proinbox.com> References: <20140505183541.GA93149@xenia.local> <5367DB88.4030503@proinbox.com> Message-ID: On May 5, 2014 at 11:42:19 AM, John Mija (jon.mb at proinbox.com) wrote: I like the project clearcrypt and it is awesome that developers start to build different algorithms than standard ones. But it's also necessary to have the most used algorithms, like i.e.: aes rsa des hmac md5 rsa sha1, sha256, sha512 As reference, the Go team added some basic algorithms to the standard library: http://golang.org/pkg/crypto/ IMHO, for the time being at least, it makes sense to treat clearcrypt as a research project- Rust is still unreleased and not ?production ready? in any formal sense of the word, and plays nicely with things that already use $major_ABI_for_your_platform. As a result, rust has a no-worse implementation of all the current primitives. Don?t get me wrong- I see enormous value in safe, provably correct implementations of the primitives in common use today, but until the language and it?s platform are ready for the main stage I?m not sure that it makes sense to limit the scope of work. richo -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon May 5 11:47:00 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 05 May 2014 14:47:00 -0400 Subject: [rust-dev] Cryptography Library In-Reply-To: <5367DB88.4030503@proinbox.com> References: <20140505183541.GA93149@xenia.local> <5367DB88.4030503@proinbox.com> Message-ID: <5367DCA4.8000807@gmail.com> On 05/05/14 02:42 PM, John Mija wrote: > I like the project clearcrypt and it is awesome that developers start to > build different algorithms than standard ones. > > But it's also necessary to have the most used algorithms, like i.e.: > > aes > rsa > des > hmac > md5 > rsa > sha1, sha256, sha512 None of these are is directly usable for authenticated encryption, and only hmac / sha256 / sha512 have sane direct use cases. These are low level primitives for a cryptography library to use rather than a high level API. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From bascule at gmail.com Mon May 5 11:46:48 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 5 May 2014 11:46:48 -0700 Subject: [rust-dev] Cryptography Library In-Reply-To: <5367DB88.4030503@proinbox.com> References: <20140505183541.GA93149@xenia.local> <5367DB88.4030503@proinbox.com> Message-ID: On Mon, May 5, 2014 at 11:42 AM, John Mija wrote: > I like the project clearcrypt and it is awesome that developers start to > build different algorithms than standard ones. > > But it's also necessary to have the most used algorithms, like i.e.: If this is what you're after, please have a look at rust-crypto: https://github.com/DaGenix/rust-crypto ClearCrypt has a different goal: to produce a minimalist transport encryption library. To that end it will only implement ciphers that will be part of the protocol's (TBD) ciphersuite. Presently the only cipher planned is ChaCha20. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon May 5 11:48:51 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 05 May 2014 14:48:51 -0400 Subject: [rust-dev] Cryptography Library In-Reply-To: References: <20140505183541.GA93149@xenia.local> <5367DB88.4030503@proinbox.com> Message-ID: <5367DD13.8050603@gmail.com> On 05/05/14 02:45 PM, Richo Healey wrote: > On May 5, 2014 at 11:42:19 AM, John Mija (jon.mb at proinbox.com > ) wrote: >> I like the project clearcrypt and it is awesome that developers start to >> build different algorithms than standard ones. >> >> But it's also necessary to have the most used algorithms, like i.e.: >> >> aes >> rsa >> des >> hmac >> md5 >> rsa >> sha1, sha256, sha512 >> >> As reference, the Go team added some basic algorithms to the standard >> library: http://golang.org/pkg/crypto/ >> > > IMHO, for the time being at least, it makes sense to treat clearcrypt as > a research project- Rust is still unreleased and not ?production ready? > in any formal sense of the word, and plays nicely with things that > already use $major_ABI_for_your_platform. As a result, rust has a > no-worse implementation of all the current primitives. > > Don?t get me wrong- I see enormous value in safe, provably correct > implementations of the primitives in common use today, but until the > language and it?s platform are ready for the main stage I?m not sure > that it makes sense to limit the scope of work. > > richo Rust is only not production ready in the sense that most people would not tolerate the frequent backwards incompatible changes for a production use case. It's not yet completely sound but it's certainly more sound than C or C++. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jon.mb at proinbox.com Mon May 5 11:49:59 2014 From: jon.mb at proinbox.com (John Mija) Date: Mon, 05 May 2014 19:49:59 +0100 Subject: [rust-dev] Cryptography Library In-Reply-To: <5367DCA4.8000807@gmail.com> References: <20140505183541.GA93149@xenia.local> <5367DB88.4030503@proinbox.com> <5367DCA4.8000807@gmail.com> Message-ID: <5367DD57.9070701@proinbox.com> El 05/05/14 19:47, Daniel Micay escribi?: > On 05/05/14 02:42 PM, John Mija wrote: >> I like the project clearcrypt and it is awesome that developers start to >> build different algorithms than standard ones. >> >> But it's also necessary to have the most used algorithms, like i.e.: >> >> aes >> rsa >> des >> hmac >> md5 >> rsa >> sha1, sha256, sha512 > > None of these are is directly usable for authenticated encryption, and > only hmac / sha256 / sha512 have sane direct use cases. These are low > level primitives for a cryptography library to use rather than a high > level API. Before of to have a high level API, in the first you need the primitives of low level. From christophe.pedretti at gmail.com Tue May 6 11:53:20 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Tue, 6 May 2014 20:53:20 +0200 Subject: [rust-dev] How to convert ~str to &str Message-ID: Hi all, i would like to parse a file, line by line, and when a line finishes with '\', the next line is considered as the continuation of the current line. I Would like to wtite something like this let mut multi = ~""; for line in BufferedReader::new(reader).lines() { match line { Ok(l) => { multi = multi.append(l); let mut buf = &*multi // we operate on buf // ................. if buf.ends_with("\\") { multi = buf.slice_to(buf.len()-1).to_owned(); continue; } // we operate on buf // ................. } Err(e) => { t=Err(e); break; } } multi=~""; } in fact, i have to write this : let mut multi = ~""; for line in BufferedReader::new(reader).lines() { match line { Ok(l) => { multi = multi.append(l); let multic = multi.clone(); let mut buf = multic.slice_from(0); // How to convert ~str to &str ??? &* is refused // we operate on buf // ................. if buf.ends_with("\\") { multi = buf.slice_to(buf.len()-1).to_owned(); continue; } // we operate on buf // ................. } Err(e) => { t=Err(e); break; } } multi=~""; } any better way to do ? Thanks -- Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue May 6 12:01:26 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 06 May 2014 15:01:26 -0400 Subject: [rust-dev] How to convert ~str to &str In-Reply-To: References: Message-ID: <53693186.1020008@gmail.com> You can convert ~str to &str with `as_slice`. It will also coerce, but that will likely go away in the near future. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From messerb at clarkson.edu Tue May 6 14:43:40 2014 From: messerb at clarkson.edu (Brad Messer - messerb) Date: Tue, 6 May 2014 21:43:40 +0000 Subject: [rust-dev] Cryptography Library In-Reply-To: References: <20140505183541.GA93149@xenia.local>, , Message-ID: Is it fair to say that Rust could use a bit of everything then? I keep seeing a bunch of different protocols being named and that seems to be leading me to the prior conclusion. My thoughts coming into the work were protocols such as RSA and ECC, but I am more than willing to work on other protocols like AES and SHA. One more question, does Rust have a number theory package? I just want to know that should I implement some of the number theory based protocols, whether or not I also should develop a number theory library. Thanks everyone! Bradley Messer ________________________________ From: Brad Messer - messerb Sent: Tuesday, May 06, 2014 1:14 PM To: Sean McArthur Subject: RE: [rust-dev] Cryptography Library Is it fair to say that Rust could use a bit of everything then? I keep seeing a bunch of different protocols being named and that seems to be leading me to the prior conclusion. My thoughts coming into the work were protocols such as RSA and ECC, but I am more than willing to work on other protocols like AES and SHA. One more question, does Rust have a number theory package? I just want to know that should I implement some of the number theory based protocols, whether or not I also should develop a number theory library. Thanks everyone! Bradley Messer ________________________________ From: Rust-dev [rust-dev-bounces at mozilla.org] on behalf of Sean McArthur [smcarthur at mozilla.com] Sent: Monday, May 05, 2014 2:37 PM To: Richo Healey; rust-dev Subject: Re: [rust-dev] Cryptography Library There's rust-crypto[1], which has quite a few implementations already. The issue isn't so much that Rust needs crypto code, is that it needs auditing of the code that exists. [1] https://github.com/DaGenix/rust-crypto -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.andradec at gmail.com Wed May 7 23:16:59 2014 From: alan.andradec at gmail.com (Alan Andrade) Date: Wed, 7 May 2014 23:16:59 -0700 Subject: [rust-dev] Bay Area Rust Hacknigts Message-ID: <6A4EE2F4-5DB0-4450-865E-E55174F66EAD@gmail.com> Hi Rusties, I created a meetup group for the Bay Area. The intention is to hack rust projects with other people. Learn, teach or do both. http://www.meetup.com/SF-Rust-Hacknights/ Thanks. - alan_andrade -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Thu May 8 08:32:49 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 8 May 2014 08:32:49 -0700 Subject: [rust-dev] Reminder: 5/8 SF Rust Meetup tonight! Message-ID: Hello all! I just wanted to remind everyone of the Bay Area Rust meetup tonight at 7pm at Mozilla's downtown office. It will be live streamed starting at 8pm on https://air.mozilla.org/rust-meetup-may-2014/ if you aren't able to make it. See you tonight! -Erick On Friday, April 11, 2014, Erick Tryzelaar wrote: > Hello Rustilians! > > I'm pleased to announce our next Rust meetup on Thursday May 8 in San > Francisco, which will be another double feature, focused on improving and > automating Rust testing. Along with this meetup, there will also be a Testing > Hackathon to be > held on Saturday May 10st. > > Our main speaker Thursday night is Professor John Regehrfrom the University of Utah. His group is focused on developing new > techniques to mechanically discover errors and missed optimizations. He > will be speaking about how his team has made a testing fuzzer for the C > language, and how we can apply those same techniques to the Rust compiler. > > Also speaking will be Andrew Gallant from the east coast, who will present > his QuickCheck , Random > property based testing with (hopefully) minimal witnesses. > > Agenda: > > ? 7:00pm - Doors open > > ? 8:00pm - Plans for the Testing Hackathon > > ? 8:15pm - John Regehr > > ? 9:15pm - Andrew Gallant > > As always, Mozilla will be graciously providing food and drink. > > If you would like to attend, sign up here: > > Meetup: http://www.meetup.com/Rust-Bay-Area/events/169434302/ > > Hackathon: http://www.meetup.com/Rust-Bay-Area/events/168373782/ > > I hope you can all make it! > -Erick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Thu May 8 16:29:59 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 8 May 2014 16:29:59 -0700 Subject: [rust-dev] Reminder: 5/8 SF Rust Meetup tonight! In-Reply-To: References: Message-ID: Hello again, I'm sorry I left off the timezones. The meetup will happen at 7pm PDT, and the live stream will start at 8pm PDT. -Erick On Thu, May 8, 2014 at 8:32 AM, Erick Tryzelaar wrote: > Hello all! > > I just wanted to remind everyone of the Bay Area Rust meetup tonight at > 7pm at Mozilla's downtown office. It will be live streamed starting at > 8pm on https://air.mozilla.org/rust-meetup-may-2014/ if you aren't able > to make it. > > See you tonight! > -Erick > > On Friday, April 11, 2014, Erick Tryzelaar > wrote: > >> Hello Rustilians! >> >> I'm pleased to announce our next Rust meetup on Thursday May 8 in San >> Francisco, which will be another double feature, focused on improving and >> automating Rust testing. Along with this meetup, there will also be a Testing >> Hackathon to be >> held on Saturday May 10st. >> >> Our main speaker Thursday night is Professor John Regehrfrom the University of Utah. His group is focused on developing new >> techniques to mechanically discover errors and missed optimizations. He >> will be speaking about how his team has made a testing fuzzer for the C >> language, and how we can apply those same techniques to the Rust compiler. >> >> Also speaking will be Andrew Gallant from the east coast, who will >> present his QuickCheck , >> Random property based testing with (hopefully) minimal witnesses. >> >> Agenda: >> >> ? 7:00pm - Doors open >> >> ? 8:00pm - Plans for the Testing Hackathon >> >> ? 8:15pm - John Regehr >> >> ? 9:15pm - Andrew Gallant >> >> As always, Mozilla will be graciously providing food and drink. >> >> If you would like to attend, sign up here: >> >> Meetup: http://www.meetup.com/Rust-Bay-Area/events/169434302/ >> >> Hackathon: http://www.meetup.com/Rust-Bay-Area/events/168373782/ >> >> I hope you can all make it! >> -Erick >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Fri May 9 00:47:26 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 09 May 2014 17:47:26 +1000 Subject: [rust-dev] Brainfuck-compiler macro Message-ID: <536C880E.4090205@gmail.com> Hi Rustillians, There was some very serious discussion on IRC about writing macros for various esolangs (*obviously* very serious :P ), so I dived in and wrote a simple one for brainfuck. https://github.com/huonw/brainfuck_macro Example: #![feature(phase)] #[phase(syntax)] extern crate brainfuck; use std::io; fn main() { let hello_world = brainfuck!{ ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.> ---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++. }; hello_world(&mut io::stdin(), &mut io::stdout()); } It's pretty basic (the macro implementation is less than 200 lines), and so probably makes a reasonable example of a procedural macro, especially macros that wish to directly handle the token stream a macro receives (rather than extracting Rust expressions etc. from it). Huon From steve at steveklabnik.com Fri May 9 11:18:27 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Fri, 9 May 2014 11:18:27 -0700 Subject: [rust-dev] Brainfuck-compiler macro In-Reply-To: <536C880E.4090205@gmail.com> References: <536C880E.4090205@gmail.com> Message-ID: <3 From christophe.pedretti at gmail.com Sat May 10 07:14:17 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Sat, 10 May 2014 16:14:17 +0200 Subject: [rust-dev] *c_char and *c_uchar Message-ID: Hi all, i am writing a wrapper to an SQLite database. If i use : extern { fn sqlite3_open(filename: *c_char, ppDb : **mut ()) -> c_int; } i can not use : let ppDb : **mut () = RawPtr::null(); unsafe { res=sqlite3_open(filename.as_ptr(), ppDb); because as_ptr() returns an *u8 and c_char is a i8, so i have to use extern { fn sqlite3_open(filename: *c_uchar, ppDb : **mut ()) -> c_int; } Now, suppose i use : extern { fn sqlite3_errmsg(pDb : *mut ()) -> *c_uchar; } i can not use : let mut desc=""; { unsafe { desc = c_str_to_static_slice(sqlite3_errmsg(*ppDb)); } } because c_str_to_static_slice taks a *c_char (so an i8) as argument, so i have to use extern { fn sqlite3_errmsg(pDb : *mut ()) -> *c_char; } If the second example is quite logical, what about the first one ? how to convert &str -> *c_char ? thanks -- Christophe http://chris-pe.github.io/Rustic/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerii.hiora at gmail.com Sat May 10 07:50:40 2014 From: valerii.hiora at gmail.com (Valerii Hiora) Date: Sat, 10 May 2014 17:50:40 +0300 Subject: [rust-dev] *c_char and *c_uchar In-Reply-To: References: Message-ID: <20140510175040.313b8bfbc8deaa2dc5f9a3b6@gmail.com> Hi Christophe, > i can not use : > let ppDb : **mut () = RawPtr::null(); > unsafe { res=sqlite3_open(filename.as_ptr(), ppDb); > because as_ptr() returns an *u8 and c_char is a i8, so i have to use > extern { fn sqlite3_open(filename: *c_uchar, ppDb : **mut ()) -> > c_int; } as_ptr() is a bad idea as there is no guarantee that Rust string is null-terminated. It should be safer to use with_c_str like: filename.with_c_str(|c_str| unsafe { sqlite3_open(c_str, ppDb) }) More details here: http://static.rust-lang.org/doc/master/std/c_str/trait.ToCStr.html#method.with_c_str > Now, suppose i use > extern { fn sqlite3_errmsg(pDb : *mut ()) -> *c_uchar; } I believe it actually should be extern { fn sqlite3_errmsg(pDB: *mut()) -> *c_char; } And for creating an owned string from it you can use std::str::raw::from_c_str More details here: http://static.rust-lang.org/doc/master/std/str/raw/fn.from_c_str.html -- Valerii From dpx.infinity at gmail.com Sat May 10 07:51:04 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Sat, 10 May 2014 18:51:04 +0400 Subject: [rust-dev] *c_char and *c_uchar In-Reply-To: References: Message-ID: Hi! First of all, if you are writing custom bindings to sqlite not only to learn Rust, I'd suggest using already existing bindings [1]. That way you probably won't have to deal with low-level C integration stuff. However, if you want to learn how to write C bindings, you should probably start with reading an official tutorial [2] on foreign function interface. That way you will learn that Rust strings are not C-compatible, they are not terminated by zero byte, so you can't get a pointer from a string and pass it to a C routine directly. In order to properly convert &str to *c_char you have to use various conversion utilities, the most simple one being with_c_str() method: let s = "some_string"; let result = s.with_c_str(|char_ptr| { // call C functions, char_ptr is a *c_char pointer // after this block finishes, a buffer pointed to by char_ptr will be freed some_result }); Here [3] is the relevant piece of documentation on C strings conversions. Your second example is also incorrect. Converting C strings to static slices is highly unsafe, for example, it will crash your program if the string is not a valid UTF-8 sequence, not to mention lifetime issues. There is a reason why it is placed in such inconvenient place as `std::str::raw`. You shouldn't use it. Instead you should use std::c_str::CString structure to wrap C strings. BTW, this structure also forces you to think about ownership. I don't know much about sqlite API, but if you're not supposed to free a string returned by sqlite3_errmsg() function, you should create CString like this CString::new(sqlite3_errmsg(*ppDb), false) false means that this CString won't own the buffer and won't free it when it goes out of scope. When you have CString structure, you can get a string slice out of it using as_str() method. This all is documented here [4]. [1]: https://github.com/linuxfood/rustsqlite. [2]: http://static.rust-lang.org/doc/master/guide-ffi.html [3]: http://static.rust-lang.org/doc/master/std/c_str/index.html [4]: http://static.rust-lang.org/doc/master/std/c_str/struct.CString.html 2014-05-10 18:14 GMT+04:00 Christophe Pedretti : > Hi all, > > i am writing a wrapper to an SQLite database. > > If i use : > extern { fn sqlite3_open(filename: *c_char, ppDb : **mut ()) -> c_int; } > i can not use : > let ppDb : **mut () = RawPtr::null(); > unsafe { res=sqlite3_open(filename.as_ptr(), ppDb); > because as_ptr() returns an *u8 and c_char is a i8, so i have to use > extern { fn sqlite3_open(filename: *c_uchar, ppDb : **mut ()) -> c_int; } > > > Now, suppose i use : > extern { fn sqlite3_errmsg(pDb : *mut ()) -> *c_uchar; } > i can not use : > let mut desc=""; { unsafe { desc = > c_str_to_static_slice(sqlite3_errmsg(*ppDb)); } } > because c_str_to_static_slice taks a *c_char (so an i8) as argument, so i > have to use > extern { fn sqlite3_errmsg(pDb : *mut ()) -> *c_char; } > > If the second example is quite logical, what about the first one ? > how to convert &str -> *c_char ? > > thanks > > -- > Christophe > http://chris-pe.github.io/Rustic/ > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From christophe.pedretti at gmail.com Sat May 10 10:38:42 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Sat, 10 May 2014 19:38:42 +0200 Subject: [rust-dev] 3 ways to do, which is the best one in terms of Rust "philosophy" ? Message-ID: Hi all, thanks to Vladimir and Valerii for their previous detailed answer to my email, now i have a more general question. My Connection struct has a "new" method with open a connection to a database. This connection can fails. Three possiblities : 1/ "new" returns an IoResult. The connection must be unwrapped from the IoResult before using it 2/ "new" returns a "Connection"; after the instantiation, a test must be made using a method like "getIoResult -> Option" 3/ any other way to do ???? For me, the 1/ is the best one, the connection can not be used until it is returned by new. With 2/, the test can be forgotten. Any suggestion ? Thanks -- Christophe http://chris-pe.github.io/Rustic From dpx.infinity at gmail.com Sat May 10 11:16:28 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Sat, 10 May 2014 22:16:28 +0400 Subject: [rust-dev] 3 ways to do, which is the best one in terms of Rust "philosophy" ? In-Reply-To: References: Message-ID: Christophe, Indeed, the idiomatic way is to use Result enum [1]. Note that you are not limited to IoResult, you can use any custom error type, for example, Result. The documentation (a link to which is below) is very nice, it contains a lot of examples and use patterns. So, your constructor method will look like this: pub fn new() -> Result { ... } Usually library-specific Result is abbreviated via a type alias: type YourLibraryResult = Result; IoResult is defined exactly like this: type IoResult = Result; [1]: http://static.rust-lang.org/doc/master/std/result/index.html 2014-05-10 21:38 GMT+04:00 Christophe Pedretti : > Hi all, > > thanks to Vladimir and Valerii for their previous detailed answer to > my email, now i have a more general question. > > My Connection struct has a "new" method with open a connection to a > database. This connection can fails. Three possiblities : > > 1/ "new" returns an IoResult. The connection must be > unwrapped from the IoResult before using it > 2/ "new" returns a "Connection"; after the instantiation, a test must > be made using a method like "getIoResult -> Option" > 3/ any other way to do ???? > > For me, the 1/ is the best one, the connection can not be used until > it is returned by new. With 2/, the test can be forgotten. > > Any suggestion ? > > Thanks > > -- > Christophe > http://chris-pe.github.io/Rustic > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From erick.tryzelaar at gmail.com Sat May 10 12:08:22 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sat, 10 May 2014 12:08:22 -0700 Subject: [rust-dev] Reminder: 5/10 SF Rust Meetup right now! Message-ID: Hello all, I just wanted to remind everyone of the testing sprint happening right now until 6pm PDT at the Mozilla headquarters. If you would like to participate remotely, we'll be hanging out on the #rust-test-sprint on irc.mozilla.org. There will also be the etherpad https://etherpad.mozilla.org/Rust-test-sprint to track our work. Thanks, Erick On Thu, May 8, 2014 at 4:29 PM, Erick Tryzelaar wrote: > Hello again, > > I'm sorry I left off the timezones. The meetup will happen at 7pm PDT, and > the live stream will start at 8pm PDT. > > -Erick > > > On Thu, May 8, 2014 at 8:32 AM, Erick Tryzelaar > wrote: > >> Hello all! >> >> I just wanted to remind everyone of the Bay Area Rust meetup tonight at >> 7pm at Mozilla's downtown office. It will be live streamed starting at >> 8pm on https://air.mozilla.org/rust-meetup-may-2014/ if you aren't able >> to make it. >> >> See you tonight! >> -Erick >> >> On Friday, April 11, 2014, Erick Tryzelaar >> wrote: >> >>> Hello Rustilians! >>> >>> I'm pleased to announce our next Rust meetup on Thursday May 8 in San >>> Francisco, which will be another double feature, focused on improving and >>> automating Rust testing. Along with this meetup, there will also be a Testing >>> Hackathon to be >>> held on Saturday May 10st. >>> >>> Our main speaker Thursday night is Professor John Regehrfrom the University of Utah. His group is focused on developing new >>> techniques to mechanically discover errors and missed optimizations. He >>> will be speaking about how his team has made a testing fuzzer for the C >>> language, and how we can apply those same techniques to the Rust compiler. >>> >>> Also speaking will be Andrew Gallant from the east coast, who will >>> present his QuickCheck , >>> Random property based testing with (hopefully) minimal witnesses. >>> >>> Agenda: >>> >>> ? 7:00pm - Doors open >>> >>> ? 8:00pm - Plans for the Testing Hackathon >>> >>> ? 8:15pm - John Regehr >>> >>> ? 9:15pm - Andrew Gallant >>> >>> As always, Mozilla will be graciously providing food and drink. >>> >>> If you would like to attend, sign up here: >>> >>> Meetup: http://www.meetup.com/Rust-Bay-Area/events/169434302/ >>> >>> Hackathon: http://www.meetup.com/Rust-Bay-Area/events/168373782/ >>> >>> I hope you can all make it! >>> -Erick >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Sat May 10 19:06:43 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sat, 10 May 2014 19:06:43 -0700 Subject: [rust-dev] Anyone in SF have an Oculus Rift? Message-ID: Hello all, colin Sheratt has offered to demo his rust binding for the Oculus Rift ( https://github.com/csherratt/vr-rs) at the yet-to-be-announced Gaming meetup in June (http://www.meetup.com/Rust-Bay-Area/events/171111672/) but unfortunately he is not local to the Bay Area. Would any Bay Area Oculus Rift owners be willing to bring in their headsets to help demo his work in person? Thanks, Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From mozilla at mcpherrin.ca Sat May 10 19:59:53 2014 From: mozilla at mcpherrin.ca (Matthew McPherrin) Date: Sat, 10 May 2014 19:59:53 -0700 Subject: [rust-dev] Anyone in SF have an Oculus Rift? In-Reply-To: References: Message-ID: Yes, I can bring a Rift to any Rust events. On Sat, May 10, 2014 at 7:06 PM, Erick Tryzelaar wrote: > Hello all, > > colin Sheratt has offered to demo his rust binding for the Oculus Rift > (https://github.com/csherratt/vr-rs) at the yet-to-be-announced Gaming > meetup in June (http://www.meetup.com/Rust-Bay-Area/events/171111672/) but > unfortunately he is not local to the Bay Area. Would any Bay Area Oculus > Rift owners be willing to bring in their headsets to help demo his work in > person? > > Thanks, > Erick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From jayhawk at cs.ucsc.edu Sun May 11 10:30:44 2014 From: jayhawk at cs.ucsc.edu (Noah Watkins) Date: Sun, 11 May 2014 10:30:44 -0700 Subject: [rust-dev] proper linking with exchange_malloc lang item Message-ID: I've used the language item `exchange_malloc` to override the default allocation routine with a custom allocator. A simple example works fine, but I'm having trouble integrating it into a larger project. In particular, how can I use my new allocator and still have access to all of libstd such that all allocations (even those done in libstd) are routed through my allocator? As it stands now it only works with `#![no_std]`, otherwise I get duplicate entries for things like `allocate`. Thanks, Noah From alex at crichton.co Sun May 11 10:34:48 2014 From: alex at crichton.co (Alex Crichton) Date: Sun, 11 May 2014 10:34:48 -0700 Subject: [rust-dev] proper linking with exchange_malloc lang item In-Reply-To: References: Message-ID: While not currently possible, we plan on accommodating use cases such as this through first-class allocators via type parameters. You'll be able to specify your own allocator an standard library routines that allocate memory. Your other option currently is to link to libcore (which doesn't provide an allocator), but you lose out on the functionality of the standard library. On Sun, May 11, 2014 at 10:30 AM, Noah Watkins wrote: > I've used the language item `exchange_malloc` to override the default > allocation routine with a custom allocator. A simple example works > fine, but I'm having trouble integrating it into a larger project. > > In particular, how can I use my new allocator and still have access to > all of libstd such that all allocations (even those done in libstd) > are routed through my allocator? As it stands now it only works with > `#![no_std]`, otherwise I get duplicate entries for things like > `allocate`. > > Thanks, > Noah > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From richo at psych0tik.net Sun May 11 13:21:02 2014 From: richo at psych0tik.net (richo) Date: Sun, 11 May 2014 13:21:02 -0700 Subject: [rust-dev] Bay Area Rust Hacknigts In-Reply-To: <6A4EE2F4-5DB0-4450-865E-E55174F66EAD@gmail.com> References: <6A4EE2F4-5DB0-4450-865E-E55174F66EAD@gmail.com> Message-ID: <20140511202102.GA54361@xenia.local> On 07/05/14 23:16 -0700, Alan Andrade wrote: >Hi Rusties, > >I created a meetup group for the Bay Area. The intention is to hack rust >projects with other people. Learn, teach or do both. > >http://www.meetup.com/SF-Rust-Hacknights/ > >Thanks. > >- alan_andrade Hi Alan, Any plans on when the first meeting will be? Unfortunately I couldn't make the testing hackathon, but keen to hack with rustlers while I'm still in town. richo >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev From erick.tryzelaar at gmail.com Sun May 11 22:21:39 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sun, 11 May 2014 22:21:39 -0700 Subject: [rust-dev] Anyone in SF have an Oculus Rift? In-Reply-To: References: Message-ID: Thanks! I'll reach out to you on irc to coordinate the demo. On Saturday, May 10, 2014, Matthew McPherrin wrote: > Yes, I can bring a Rift to any Rust events. > > On Sat, May 10, 2014 at 7:06 PM, Erick Tryzelaar > > wrote: > > Hello all, > > > > colin Sheratt has offered to demo his rust binding for the Oculus Rift > > (https://github.com/csherratt/vr-rs) at the yet-to-be-announced Gaming > > meetup in June (http://www.meetup.com/Rust-Bay-Area/events/171111672/) > but > > unfortunately he is not local to the Bay Area. Would any Bay Area Oculus > > Rift owners be willing to bring in their headsets to help demo his work > in > > person? > > > > Thanks, > > Erick > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan.software at gmail.com Sun May 11 23:08:54 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Sun, 11 May 2014 23:08:54 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? Message-ID: Hi, This email is to gauge interest in doing a Rust meetup in Seattle. If there's interest, I'll coordinate finding a place & time that accomodates people. Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamson.benjamin at gmail.com Mon May 12 10:14:55 2014 From: adamson.benjamin at gmail.com (benjamin adamson) Date: Mon, 12 May 2014 10:14:55 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: +1 where in Seattle are you thinking? On May 11, 2014 11:08 PM, "Paul Nathan" wrote: > Hi, > > This email is to gauge interest in doing a Rust meetup in Seattle. If > there's interest, I'll coordinate finding a place & time that accomodates > people. > > Regards, > Paul > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan.software at gmail.com Mon May 12 11:31:56 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Mon, 12 May 2014 11:31:56 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: Remedy Teas on Capitol Hill if interest is < 7 people. I am open to other alternatives, but don't usually prefer places with alcohol. I e I like coffee and tea shops. On May 12, 2014 10:14 AM, "benjamin adamson" wrote: > +1 where in Seattle are you thinking? > On May 11, 2014 11:08 PM, "Paul Nathan" > wrote: > >> Hi, >> >> This email is to gauge interest in doing a Rust meetup in Seattle. If >> there's interest, I'll coordinate finding a place & time that accomodates >> people. >> >> Regards, >> Paul >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayhawk at cs.ucsc.edu Mon May 12 11:50:27 2014 From: jayhawk at cs.ucsc.edu (Noah Watkins) Date: Mon, 12 May 2014 11:50:27 -0700 Subject: [rust-dev] how to capture de-reference to ~int Message-ID: I am trying to capture the reference to type `~int` with the following code. I can change it to apply to bare `int` and it works fine. #[lang="deref"] pub trait Deref { fn deref<'a>(&'a self) -> &'a Result; } impl Deref<~int> for ~int { fn deref<'a>(&'a self) -> &'a ~int { println!("deref caught"); self } } fn main() { let x: ~int = 3; *x } Thanks, Noah From christophe.pedretti at gmail.com Mon May 12 15:41:49 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Tue, 13 May 2014 00:41:49 +0200 Subject: [rust-dev] Casting *c_uchar to *c_char Message-ID: Hi all, Vladimir suggested to use CString::new(sqlite3_errmsg(*ppDb), false) and then as_str() on the CString in order to obtain a Rust String from a *c_char. Another SQLite function, sqlite3_column_text, return a *c_uchar; so, tu use the CString new, which takes a *c_char as argument, i can cast CString::new(sqlite3_column_text(pStmt, column_index) as *i8, false) But is it correct ? Thanks -- Christophe http://chris-pe.github.io/Rustic/ From comexk at gmail.com Mon May 12 16:24:34 2014 From: comexk at gmail.com (comex) Date: Mon, 12 May 2014 19:24:34 -0400 Subject: [rust-dev] Casting *c_uchar to *c_char In-Reply-To: References: Message-ID: On Mon, May 12, 2014 at 6:41 PM, Christophe Pedretti wrote: > Another SQLite function, sqlite3_column_text, return a *c_uchar; so, > tu use the CString new, which takes a *c_char as argument, i can cast > CString::new(sqlite3_column_text(pStmt, column_index) as *i8, false) > > But is it correct ? Looks correct, but note that this doesn't copy any data by itself; if the original pointer becomes invalid, which happens in various situations documented by the SQLite API, so will the CString. From eli at siliconsprawl.com Mon May 12 17:05:13 2014 From: eli at siliconsprawl.com (Eli Lindsey) Date: Mon, 12 May 2014 17:05:13 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: +1 Somewhere around Capitol Hill would be very convenient. > On May 12, 2014, at 11:31 AM, Paul Nathan wrote: > > Remedy Teas on Capitol Hill if interest is < 7 people. > > I am open to other alternatives, but don't usually prefer places with alcohol. I e I like coffee and tea shops. >> On May 12, 2014 10:14 AM, "benjamin adamson" wrote: >> +1 where in Seattle are you thinking? >> >>> On May 11, 2014 11:08 PM, "Paul Nathan" wrote: >>> Hi, >>> >>> This email is to gauge interest in doing a Rust meetup in Seattle. If there's interest, I'll coordinate finding a place & time that accomodates people. >>> >>> Regards, >>> Paul >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.pedretti at gmail.com Tue May 13 01:02:33 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Tue, 13 May 2014 10:02:33 +0200 Subject: [rust-dev] Casting *c_uchar to *c_char In-Reply-To: References: Message-ID: So, if i understand correctly, using CString::new with 'false' as a second argument implies : - as you have no control on the lifetime underlying buffer, generally, you have to as_str() and clone() the CString (the exception is when you use immediately (right after creation) and only once the CString, for example to display it) - it better to write value = unsafe { let tmp = CString::new(...., false); if tmp.is_not_null {tmp_str = tmp .as_str()}; tmp_str.clone() } to avoid any misused of a possibly transient CString than let tmp = unsafe { CString::new(...., false) }; value = if tmp.is_not_null {let tmp_str = tmp .as_str()}; tmp_str.clone() } Thanks 2014-05-13 1:24 GMT+02:00 comex : > On Mon, May 12, 2014 at 6:41 PM, Christophe Pedretti > wrote: >> Another SQLite function, sqlite3_column_text, return a *c_uchar; so, >> tu use the CString new, which takes a *c_char as argument, i can cast >> CString::new(sqlite3_column_text(pStmt, column_index) as *i8, false) >> >> But is it correct ? > > Looks correct, but note that this doesn't copy any data by itself; if > the original pointer becomes invalid, which happens in various > situations documented by the SQLite API, so will the CString. From me at kevincantu.org Tue May 13 01:52:09 2014 From: me at kevincantu.org (Kevin Cantu) Date: Tue, 13 May 2014 01:52:09 -0700 Subject: [rust-dev] Cryptography Library In-Reply-To: References: <20140505183541.GA93149@xenia.local> Message-ID: A bit of everything sounds like a good summary. IIRC no cryptographer is working full-time to contribute to Rust, so there are no plans to put more crypto than needed into standard libraries. But serious libraries are more than welcome, and feedback would be great as we get ever closer to stabilizing the language. I've found the core devs are *very* responsive. Kevin On Tue, May 6, 2014 at 2:43 PM, Brad Messer - messerb wrote: > Is it fair to say that Rust could use a bit of everything then? I keep > seeing a bunch of different protocols being named and that seems to be > leading me to the prior conclusion. My thoughts coming into the work were > protocols such as RSA and ECC, but I am more than willing to work on other > protocols like AES and SHA. > > One more question, does Rust have a number theory package? I just want > to know that should I implement some of the number theory based protocols, > whether or not I also should develop a number theory library. > > Thanks everyone! > > Bradley Messer > ------------------------------ > *From:* Brad Messer - messerb > *Sent:* Tuesday, May 06, 2014 1:14 PM > *To:* Sean McArthur > *Subject:* RE: [rust-dev] Cryptography Library > > Is it fair to say that Rust could use a bit of everything then? I keep > seeing a bunch of different protocols being named and that seems to be > leading me to the prior conclusion. My thoughts coming into the work were > protocols such as RSA and ECC, but I am more than willing to work on other > protocols like AES and SHA. > > One more question, does Rust have a number theory package? I just want > to know that should I implement some of the number theory based protocols, > whether or not I also should develop a number theory library. > > Thanks everyone! > > Bradley Messer > ------------------------------ > *From:* Rust-dev [rust-dev-bounces at mozilla.org] on behalf of Sean > McArthur [smcarthur at mozilla.com] > *Sent:* Monday, May 05, 2014 2:37 PM > *To:* Richo Healey; rust-dev > *Subject:* Re: [rust-dev] Cryptography Library > > There's rust-crypto[1], which has quite a few implementations already. > The issue isn't so much that Rust needs crypto code, is that it needs > auditing of the code that exists. > > [1] https://github.com/DaGenix/rust-crypto > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Tue May 13 02:11:41 2014 From: me at kevincantu.org (Kevin Cantu) Date: Tue, 13 May 2014 02:11:41 -0700 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: IMHO it may be more important to experiment a bit and establish some common string-like traits which can be implemented separately, as desired, by regular strings, platform-dependent strings of various sorts, and wild and crazy encodings of the future. Remember, for example, how GHC Haskell has a way to share identical syntax for string literals across many types of string back-end: the traits are important. I suspect, however, that we're committed to the current UTF-8 encoding for the core default implementation at this point. To convince people to change that, you'll probably need to implement some of your ideas and start providing performance data... And again, I think if we get the traits right, that'd be easy to do in a library! Kevin On Fri, May 2, 2014 at 4:29 AM, Malthe Borch wrote: > Ben Kloosterman writes: > > On 5/2/14, Malthe Borch wrote: > > > > I don't think this is the structure he is talking about. I think > > something heavier that contains the encoding type and some sort of > > reference to the next set of chars which may have a different > > encoding. . . works well with dependent types. > > A basic implementation was available in the standard library until > recently: http://static.rust-lang.org/doc/0.7/std/rope.html. > > And yes, basically every leaf in the rope is a tuple (char*, encoding) > where > encoding is something that resolves to a codec. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.andradec at gmail.com Tue May 13 10:19:10 2014 From: alan.andradec at gmail.com (Alan Andrade) Date: Tue, 13 May 2014 10:19:10 -0700 Subject: [rust-dev] Bay Area Rust Hacknigts Message-ID: <869757F4-9027-4C9E-88D1-6116339BBFEF@gmail.com> Hello Richo, There are no plans to hold a hack night on May. I wanted to gauge on May, and have the first one on June. I really hope you?re still in the city ! - alan_andrade From bascule at gmail.com Tue May 13 13:08:42 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 13 May 2014 13:08:42 -0700 Subject: [rust-dev] Cryptography Library In-Reply-To: References: <20140505183541.GA93149@xenia.local> Message-ID: On Tue, May 13, 2014 at 1:52 AM, Kevin Cantu wrote: > IIRC no cryptographer is working full-time to contribute to Rust, so there > are no plans to put more crypto than needed into standard libraries. > It'd be great if Mozilla could loop in their security team on Rust development *wink* *wink* *nudge* *nudge* I look at efforts like PKIX and wonder why they're being done in C++ instead of Rust > But serious libraries are more than welcome, and feedback would be great > as we get ever closer to stabilizing the language. I've found the core > devs are *very* responsive. > The main thing I'd like to see in core Rust is something like a .NET SecureString: http://msdn.microsoft.com/en-us/library/system.security.securestring(v=vs.110).aspx This is predicated on having a wrapping algorithm using a Key Encrypting Key. So yeah, crypto ;) As lower hanging fruit, how about a standard way to MemoryMap an mlocked buffer with guard pages that are PROT_NONE? I've been working on a "SecretBuffer" type for my library ClearCrypt, but I'd really like to see something like that in Rust proper (even if it's just flags for MemoryMap) -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.pedretti at gmail.com Tue May 13 14:17:17 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Tue, 13 May 2014 23:17:17 +0200 Subject: [rust-dev] How to translate and use a void(*)(void*) in Rust ? Message-ID: Hi all, SQLITE is defining the following C function : int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); How to include it in an extern block ? I have tried this fn sqlite3_bind_text(pStmt : *mut(), iCol : c_int, value : *c_char, n : c_int, f : *proc(*())) -> c_int; (a pointer to a function taking a pointer as an argument) i have also tried fn sqlite3_bind_text(pStmt : *mut(), iCol : c_int, value : *c_char, n : c_int, f : *|*()|) -> c_int; In SQLITE, this argument can takes value SQLITE_STATIC or SQLITE_TRANSIENT typedef void (*sqlite3_destructor_type)(void*); #define SQLITE_STATIC ((sqlite3_destructor_type)0) #define SQLITE_TRANSIENT ((sqlite3_destructor_type)-1) for example, how to set this argument to SQLITE_STATIC in Rust ? Thanks -- Christophe http://chris-pe.github.io/Rustic/ From alex at crichton.co Tue May 13 14:19:57 2014 From: alex at crichton.co (Alex Crichton) Date: Tue, 13 May 2014 14:19:57 -0700 Subject: [rust-dev] how to capture de-reference to ~int In-Reply-To: References: Message-ID: The ~int type has since moved to Box, which will one day be a library type with Deref implemented on it (currently it is implemented by the compiler). Regardless, there's no need to implement the Deref trait for the type today, the compiler already takes care of it. For example, your code will compile without the deref trait: fn main() { let x: Box = box 3; let y = *x; println!("{}", y); } The language only allows for one definition of each lang item, and most lang items now reside in libcore, so you shouldn't have to define them manually. On Mon, May 12, 2014 at 11:50 AM, Noah Watkins wrote: > I am trying to capture the reference to type `~int` with the following > code. I can change it to apply to bare `int` and it works fine. > > #[lang="deref"] > pub trait Deref { > fn deref<'a>(&'a self) -> &'a Result; > } > > impl Deref<~int> for ~int { > fn deref<'a>(&'a self) -> &'a ~int { > println!("deref caught"); > self > } > } > > fn main() { > let x: ~int = 3; > *x > } > > Thanks, > Noah > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From alex at crichton.co Tue May 13 14:25:19 2014 From: alex at crichton.co (Alex Crichton) Date: Tue, 13 May 2014 14:25:19 -0700 Subject: [rust-dev] How to translate and use a void(*)(void*) in Rust ? In-Reply-To: References: Message-ID: The equivalent of a function pointer in C is the bare fn type in rust. For example, you could write your binding as: // C code int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); // Rust definition fn sqlite3_bind_text(stmt: *mut sqlite3_stmt, arg1: libc::c_int, arg2: *libc::c_char, arg3: libc::c_int, arg4: extern fn(*mut libc::c_void)) -> libc::c_int; You'll note that "extern" means use the default foreign ABI, as the rust ABI is different than the C ABI. The two types you were trying, procedures and closures, have environments attached to them which is likely what the C function is not expecting. The "extern fn()" type is rust's function pointer type. Notably, however, values of "extern fn()" are assumed to be non-null by the compiler, so the interop with your C library may not be perfect because SQLITE_STATIC cannot have a value of "extern fn()" (as it would be null). To work around this, Rust has a null-pointer optimization where Option is optimized to a nullable pointer in terms of representation. There are currently some issues with ABI compatibility, but these will likely be addressed in the near future! On Tue, May 13, 2014 at 2:17 PM, Christophe Pedretti wrote: > Hi all, > > SQLITE is defining the following C function : > int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); > > How to include it in an extern block ? > I have tried this > fn sqlite3_bind_text(pStmt : *mut(), iCol : c_int, value : *c_char, n > : c_int, f : *proc(*())) -> c_int; > (a pointer to a function taking a pointer as an argument) > i have also tried > fn sqlite3_bind_text(pStmt : *mut(), iCol : c_int, value : *c_char, n > : c_int, f : *|*()|) -> c_int; > > In SQLITE, this argument can takes value SQLITE_STATIC or SQLITE_TRANSIENT > typedef void (*sqlite3_destructor_type)(void*); > #define SQLITE_STATIC ((sqlite3_destructor_type)0) > #define SQLITE_TRANSIENT ((sqlite3_destructor_type)-1) > > for example, how to set this argument to SQLITE_STATIC in Rust ? > > Thanks > > -- > Christophe > http://chris-pe.github.io/Rustic/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From jayhawk at cs.ucsc.edu Tue May 13 21:16:00 2014 From: jayhawk at cs.ucsc.edu (Noah Watkins) Date: Tue, 13 May 2014 21:16:00 -0700 Subject: [rust-dev] how to capture de-reference to ~int In-Reply-To: References: Message-ID: On Tue, May 13, 2014 at 2:19 PM, Alex Crichton wrote: > The ~int type has since moved to Box, which will one day be a > library type with Deref implemented on it (currently it is implemented > by the compiler). Thanks for the note. I'm using a slightly older version that doesn't have Box, but it sounds like ~ is also implemented with the compiler. I was actually looking into this because I was interested in intercepting the deref (as well as allocate/free) for some distributed shared-memory experiments. Some of the safety checks rust performs simplifies the coherency requirements needed of the storage layer (e.g. expensive locking). -Noah > > On Mon, May 12, 2014 at 11:50 AM, Noah Watkins wrote: >> I am trying to capture the reference to type `~int` with the following >> code. I can change it to apply to bare `int` and it works fine. >> >> #[lang="deref"] >> pub trait Deref { >> fn deref<'a>(&'a self) -> &'a Result; >> } >> >> impl Deref<~int> for ~int { >> fn deref<'a>(&'a self) -> &'a ~int { >> println!("deref caught"); >> self >> } >> } >> >> fn main() { >> let x: ~int = 3; >> *x >> } >> >> Thanks, >> Noah >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev From armin.ronacher at active-4.com Wed May 14 05:23:31 2014 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Wed, 14 May 2014 14:23:31 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: Message-ID: <53736043.50803@active-4.com> Hi, On 02/05/2014 09:55, Malthe Borch wrote: > It blows up ? as expected, because "ascii" is a limited encoding. It's not just ascii. That said, blowing up at encoding time is terrible because you don't know where the error comes from. This is especially a huge problem on Python 3 right now because of how frequently you piggyback broken unicode through surrogate escapes. By the time you encode and it tells you the string is invalid, it's impossible to figure out where it came from. Regards, Armin From armin.ronacher at active-4.com Wed May 14 05:25:35 2014 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Wed, 14 May 2014 14:25:35 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: References: <5362B4CD.3040001@gmail.com> Message-ID: <537360BF.5020305@active-4.com> Hi, On 02/05/2014 00:03, John Downey wrote: > I have actually always been a fan of how .NET did this. The System.String type > is opinionated in how it is stored internally and does not allow anyone to > change that (unlike Ruby). The conversion from String to byte[] is done using > explicit conversion methods like: Unfortunately the .NET string type does not support UCS4 and as such is a nightmare to deal with. Also because the internal encoding is not UTF-8 *any* interaction with the outside world (ignoring the win32 api) is going through an encode/decode step which can be unnecessary. For instance if you would do that on Linux you would decode from utf-8 to your internal UCS4 encoding, then encode back to utf-8 on the way back to the terminal. (Aside from that, 32bit for a charpoint is too large as unicode does not go in more than 21bit or something. Useless) Regards, Armin From matthieu.monrocq at gmail.com Wed May 14 10:43:11 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Wed, 14 May 2014 19:43:11 +0200 Subject: [rust-dev] UTF-8 strings versus "encoded ropes" In-Reply-To: <537360BF.5020305@active-4.com> References: <5362B4CD.3040001@gmail.com> <537360BF.5020305@active-4.com> Message-ID: On Wed, May 14, 2014 at 2:25 PM, Armin Ronacher wrote: > Hi, > > On 02/05/2014 00:03, John Downey wrote: > >> I have actually always been a fan of how .NET did this. The System.String >> type >> is opinionated in how it is stored internally and does not allow anyone to >> change that (unlike Ruby). The conversion from String to byte[] is done >> using >> explicit conversion methods like: >> > Unfortunately the .NET string type does not support UCS4 and as such is a > nightmare to deal with. Also because the internal encoding is not UTF-8 > *any* interaction with the outside world (ignoring the win32 api) is going > through an encode/decode step which can be unnecessary. > > For instance if you would do that on Linux you would decode from utf-8 to > your internal UCS4 encoding, then encode back to utf-8 on the way back to > the terminal. (Aside from that, 32bit for a charpoint is too large as > unicode does not go in more than 21bit or something. Useless) > > Even keeping whole bytes, 3 bytes (24 bits) is effectively sufficient for the whole of Unicode. If you don't mind some arithmetic, you could thus use a backing array of bytes and just recompose the value on output. > > > Regards, > Armin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnfagnan at gmail.com Wed May 14 12:39:45 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Wed, 14 May 2014 13:39:45 -0600 Subject: [rust-dev] Splitting The Tutorial/Guides Message-ID: I'm proposing that we split the tutorial & guides into a much better system. There's a few problems with the current system: * The tutorial is a massive page that seems to have everything stuffed into it.. * Other guides are hard to notice (I sure didn't see the links at the bottom right away). * Other guides aren't made as important as the tutorial. * The user flow is kinda ineffective. I don't think splatting a bunch of the features in a single page is a great starter. I'm thinking that something like [Julia's docs]( http://docs.julialang.org/en/release-0.2/manual/) would serve us better. It would allow us to properly guide the user through each topic separately, instead of having a giant page that one could get overwhelmed reading. Another example is [Github's docs](https://developer.github.com/v3/) Because this is curated docs, there's some flexibility in what we're able to do. Github, for example, uses [Nanoc](http://nanoc.ws/), which is like Jekyll but way more powerful. We could include the ability to compile the nanoc site in the Makefile and we could have rustdoc to still parse the markdown and ensure the examples are correct. This would allow us the opportunity to properly guide the user through each element of Rust and we could split things into sections, such as `Introduction`, `Advanced`, etc... Within the introduction, we could have the 30-minute introduction, along with other material. Thoughts? -- Daniel Fagnan Titan Analytics Inc. www.titananalytics.com M: (780) 983-4997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Wed May 14 14:50:00 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 14 May 2014 14:50:00 -0700 Subject: [rust-dev] Splitting The Tutorial/Guides In-Reply-To: References: Message-ID: https://air.mozilla.org/rust-meetup-december-2013/ (that's basically a "I agree.") From abernardes at gmail.com Wed May 14 15:04:09 2014 From: abernardes at gmail.com (Andre Bernardes) Date: Wed, 14 May 2014 15:04:09 -0700 (PDT) Subject: [rust-dev] Splitting The Tutorial/Guides In-Reply-To: References: Message-ID: <1400105049626.d4ee594a@Nodemailer> I just went through the current guides and I felt the pain. If you need any help rewriting them I'd be glad to assist.Andr? (no celular) On Wed, May 14, 2014 at 6:50 PM, Steve Klabnik wrote: > https://air.mozilla.org/rust-meetup-december-2013/ > (that's basically a "I agree.") > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.pedretti at gmail.com Thu May 15 00:59:30 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Thu, 15 May 2014 09:59:30 +0200 Subject: [rust-dev] How to implement a singleton ? Message-ID: I am trying to implement a Singleton (an object which instantiate only once, successive instantiations returning the object itself). Any tutorial for this ? any idea ? example ? best practice ? thanks From matthieu.monrocq at gmail.com Thu May 15 03:26:19 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 15 May 2014 12:26:19 +0200 Subject: [rust-dev] How to implement a singleton ? In-Reply-To: References: Message-ID: Hello, My first instinct would be: don't... but in the name of science... Have you tried looking at Stack Overflow ? Just googling around I found: http://stackoverflow.com/questions/19605132/is-it-possible-to-use-global-variables-in-rustwhich allows you to have a global variable and from there a Singleton seems easy. I guess you will need something like Mutex> if you want lazy initialization. -- Matthieu On Thu, May 15, 2014 at 9:59 AM, Christophe Pedretti < christophe.pedretti at gmail.com> wrote: > I am trying to implement a Singleton (an object which instantiate only > once, successive instantiations returning the object itself). > Any tutorial for this ? any idea ? example ? best practice ? > > thanks > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Thu May 15 04:22:33 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 15 May 2014 12:22:33 +0100 Subject: [rust-dev] How to implement a singleton ? In-Reply-To: References: Message-ID: <5374A379.60100@exyr.org> On 15/05/2014 08:59, Christophe Pedretti wrote: > I am trying to implement a Singleton (an object which instantiate only > once, successive instantiations returning the object itself). > Any tutorial for this ? any idea ? example ? best practice ? Kimundi published this macro to define lazily initialized statics, which look to me equivalent to singletons although there is no "instanciation" involved: https://gist.github.com/Kimundi/8782487 http://www.reddit.com/r/rust/comments/1wvxcn/lazily_initialized_statics/ I believe this is only memory-safe with types that satisfy the `Share` kind. http://static.rust-lang.org/doc/master/core/kinds/trait.Share.html -- Simon Sapin From jayhawk at cs.ucsc.edu Thu May 15 13:11:04 2014 From: jayhawk at cs.ucsc.edu (Noah Watkins) Date: Thu, 15 May 2014 13:11:04 -0700 Subject: [rust-dev] chaining #[start] methods Message-ID: I'd like to put the following in a crate that intercepts start-up to modify argc/argv, and then yield to whatever the normal start-up procedure is (native, green, call main, etc...). #[start] fn start(...) { /* pre-process argc/argv */ call default start-up stuff } Currently I'm having to expose my crate's start-up routine and have the program using the crate handle this start-up process. Is there a way to have this work transparently within the create? -Noah From alex at crichton.co Thu May 15 13:32:39 2014 From: alex at crichton.co (Alex Crichton) Date: Thu, 15 May 2014 13:32:39 -0700 Subject: [rust-dev] chaining #[start] methods In-Reply-To: References: Message-ID: Rust doesn't support life-before-main, which is basically what this ends up entailing. What you've done already is likely what you'll want to keep doing, which is explicitly chaining control flow through the startup process. On Thu, May 15, 2014 at 1:11 PM, Noah Watkins wrote: > I'd like to put the following in a crate that intercepts start-up to > modify argc/argv, and then yield to whatever the normal start-up > procedure is (native, green, call main, etc...). > > #[start] > fn start(...) { > /* pre-process argc/argv */ > call default start-up stuff > } > > Currently I'm having to expose my crate's start-up routine and have > the program using the crate handle this start-up process. Is there a > way to have this work transparently within the create? > > -Noah > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pnathan.software at gmail.com Thu May 15 13:46:28 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Thu, 15 May 2014 13:46:28 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: Hi, It looks like two people have expressed interest in this. I think that's enough to get together and talk. My suggestion for scheduling is next Thursday (May 22nd) at 7-9pm at Remedy Teas[1] on Capitol Hill. Proposed topics: - meet & greet - talk about extant Rust projects (if any) - planned targets for projects. Does this seem convenient & work for everyone interested? [1] http://remedyteas.com Remedy Teas 345 15th Ave E Seattle, WA 98112 On Mon, May 12, 2014 at 5:05 PM, Eli Lindsey wrote: > +1 > > Somewhere around Capitol Hill would be very convenient. > > On May 12, 2014, at 11:31 AM, Paul Nathan > wrote: > > Remedy Teas on Capitol Hill if interest is < 7 people. > > I am open to other alternatives, but don't usually prefer places with > alcohol. I e I like coffee and tea shops. > On May 12, 2014 10:14 AM, "benjamin adamson" > wrote: > >> +1 where in Seattle are you thinking? >> On May 11, 2014 11:08 PM, "Paul Nathan" >> wrote: >> >>> Hi, >>> >>> This email is to gauge interest in doing a Rust meetup in Seattle. If >>> there's interest, I'll coordinate finding a place & time that accomodates >>> people. >>> >>> Regards, >>> Paul >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.andradec at gmail.com Thu May 15 13:47:04 2014 From: alan.andradec at gmail.com (Alan Andrade) Date: Thu, 15 May 2014 13:47:04 -0700 Subject: [rust-dev] Splitting The Tutorial/Guides Message-ID: <21882992-6A64-4202-A801-C957C1E35EC6@gmail.com> I?m pretty sure everybody agree with you. The guides, tutorial and manual are always seen like a huge opportunity for improvement but few people have really put effort on it. I?m currently refactoring the guides with the following goals in mind: 1. Keep consistency when we talk about ?pointers? or ?references? 2. Nuke the idea of Managed boxes, and strive for owned boxes. 3. Get rid of the sigils where it applies and use box instead. I have no plan to improve CSS or user experience. My feeling is that we just need to coordinate efforts. Maybe we can come up with a plan where we split work by areas such as: content, style and ux ? Perhaps, this could be the goal for the first rust bay area hack night. - Alan From dnfagnan at gmail.com Thu May 15 15:38:46 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Thu, 15 May 2014 16:38:46 -0600 Subject: [rust-dev] Splitting The Tutorial/Guides In-Reply-To: References: <21882992-6A64-4202-A801-C957C1E35EC6@gmail.com> Message-ID: Here's a demo I put up: http://rust-docs.s3-website-us-west-2.amazonaws.com/ -- Daniel Fagnan Titan Analytics Inc. www.titananalytics.com M: (780) 983-4997 On Thu, May 15, 2014 at 3:02 PM, Daniel Fagnan wrote: > Awesome. I have started to refactor the curated documentation system using > nanoc to power the static site. It's still super early, but I'm working > straight out of the Rust source, so it'll be super easy to replace the > current system. > > I started with a default nanoc site and it's default styles that are > fairly decent (although it's css is pretty horrible). I'm now improving it > as I go along. > > The main page I have as Steve's 30-Minute Introduction, and each page > should link to further resources to continue the user along. After the > beginning tutorial, similar to Julia's docs, there could be a "Getting > Started" set of pages where you learn how to get Rust installed and > everything. > > The screenshot shows basically the default nanoc theme with quite a few > adjustments. It's simply a starting point. > > -- > Daniel Fagnan > Titan Analytics Inc. > www.titananalytics.com > M: (780) 983-4997 > > > On Thu, May 15, 2014 at 2:47 PM, Alan Andrade wrote: > >> I?m pretty sure everybody agree with you. The guides, tutorial and manual >> are always seen like a huge opportunity for improvement but few people have >> really put effort on it. >> >> I?m currently refactoring the guides with the following goals in mind: >> >> 1. Keep consistency when we talk about ?pointers? or ?references? >> 2. Nuke the idea of Managed boxes, and strive for owned boxes. >> 3. Get rid of the sigils where it applies and use box instead. >> >> I have no plan to improve CSS or user experience. >> >> My feeling is that we just need to coordinate efforts. Maybe we can come >> up with a plan where we split work by areas such as: content, style and ux ? >> >> Perhaps, this could be the goal for the first rust bay area hack night. >> >> - Alan >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at colomiets.name Thu May 15 15:43:46 2014 From: paul at colomiets.name (Paul Colomiets) Date: Fri, 16 May 2014 01:43:46 +0300 Subject: [rust-dev] Any way to wake up rust task? Message-ID: Hi, I have a few kinds of tasks like the ones reading from a TCP socket or listening for TCP connections, that need to be shut down when unneeded. How can I wake up/kill a task waiting for data in Reader.read() method or similar? In the master branch I can set_timeout and wake up once a while (which seems like ugly hack too) In 0.10 there is no even timeouts. Is there any way to interrupt or kill a task? -- Paul From alex at crichton.co Thu May 15 15:51:47 2014 From: alex at crichton.co (Alex Crichton) Date: Thu, 15 May 2014 15:51:47 -0700 Subject: [rust-dev] Any way to wake up rust task? In-Reply-To: References: Message-ID: There is no way to generically wake up or kill a task, it must be arranged via some other means for the task to wake up. For TCP connections, you can use the close_read() method or the set_read_timeout() methods. In 0.10, this was not implemented (we recommend you use master). On Thu, May 15, 2014 at 3:43 PM, Paul Colomiets wrote: > Hi, > > I have a few kinds of tasks like the ones reading from a TCP socket or > listening for TCP connections, that need to be shut down when > unneeded. How can I wake up/kill a task waiting for data in > Reader.read() method or similar? > > In the master branch I can set_timeout and wake up once a while (which > seems like ugly hack too) In 0.10 there is no even timeouts. Is there > any way to interrupt or kill a task? > > -- > Paul > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From dnfagnan at gmail.com Thu May 15 14:02:06 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Thu, 15 May 2014 15:02:06 -0600 Subject: [rust-dev] Splitting The Tutorial/Guides In-Reply-To: <21882992-6A64-4202-A801-C957C1E35EC6@gmail.com> References: <21882992-6A64-4202-A801-C957C1E35EC6@gmail.com> Message-ID: Awesome. I have started to refactor the curated documentation system using nanoc to power the static site. It's still super early, but I'm working straight out of the Rust source, so it'll be super easy to replace the current system. I started with a default nanoc site and it's default styles that are fairly decent (although it's css is pretty horrible). I'm now improving it as I go along. The main page I have as Steve's 30-Minute Introduction, and each page should link to further resources to continue the user along. After the beginning tutorial, similar to Julia's docs, there could be a "Getting Started" set of pages where you learn how to get Rust installed and everything. The screenshot shows basically the default nanoc theme with quite a few adjustments. It's simply a starting point. -- Daniel Fagnan Titan Analytics Inc. www.titananalytics.com M: (780) 983-4997 On Thu, May 15, 2014 at 2:47 PM, Alan Andrade wrote: > I?m pretty sure everybody agree with you. The guides, tutorial and manual > are always seen like a huge opportunity for improvement but few people have > really put effort on it. > > I?m currently refactoring the guides with the following goals in mind: > > 1. Keep consistency when we talk about ?pointers? or ?references? > 2. Nuke the idea of Managed boxes, and strive for owned boxes. > 3. Get rid of the sigils where it applies and use box instead. > > I have no plan to improve CSS or user experience. > > My feeling is that we just need to coordinate efforts. Maybe we can come > up with a plan where we split work by areas such as: content, style and ux ? > > Perhaps, this could be the goal for the first rust bay area hack night. > > - Alan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2014-05-15 15.00.05.png Type: image/png Size: 244178 bytes Desc: not available URL: From paul at colomiets.name Thu May 15 16:47:59 2014 From: paul at colomiets.name (Paul Colomiets) Date: Fri, 16 May 2014 02:47:59 +0300 Subject: [rust-dev] Any way to wake up rust task? In-Reply-To: References: Message-ID: Hi Alex, Sorry for replying off-list, previously. I would try to argue on the both points: On Fri, May 16, 2014 at 2:09 AM, Alex Crichton wrote: >>> There is no way to generically wake up or kill a task, it must be >>> arranged via some other means for the task to wake up. >> >> Is this intentional or just not implemented yet? > > Intentional, I don't think we plan on implementing this any time soon, > if at all. > Waking up on timeout is hardly a good decision. Let's think about thousands of connections, each waking up at a reasonable timeouts (sometimes between 100 ms to 1 sec for my taste). The close_read is a hack that doesn't work for many cases (listening sockets, pipes, SCTP sockets, etc.) I'm not sure what the API should be. A way to poll on two sockets, or on socket and channel simultaneously may work for me. Similarly it may be an ability to kill the task. Or a way to send an interruption signal (similar to EINTR). >>> For TCP >>> connections, you can use the close_read() method or the >>> set_read_timeout() methods. In 0.10, this was not implemented (we >>> recommend you use master). >> >> Ok. BTW, why close_xxx and set_xx_timeout are not a part of some >> trait? (they might be reused at least for TcpStream and UnixStream) > > The methods are all implemented for both TcpStream and UnixStream, I > opted to not put them on a trait because I didn't think the trait > would serve much purpose. In theory you could take "T: Reader + > Interruptible", but it seemed like you would more often just take > TcpStream/UnixStream specifically. Well, I think many networking applications would like to work with both TCP and Unix sockets. As a recent example docker uses HTTP protocol over unix socket by default (this is a prominent example, as many HTTP implementations designed without this in mind). And Stream trait is not enough for them because they need timeouts too. -- Paul From alex at crichton.co Thu May 15 17:40:49 2014 From: alex at crichton.co (Alex Crichton) Date: Thu, 15 May 2014 17:40:49 -0700 Subject: [rust-dev] Any way to wake up rust task? In-Reply-To: References: Message-ID: > Waking up on timeout is hardly a good decision. Let's think about > thousands of connections, each waking up at a reasonable timeouts > (sometimes between 100 ms to 1 sec for my taste). The close_read is a > hack that doesn't work for many cases (listening sockets, pipes, SCTP > sockets, etc.) > > I'm not sure what the API should be. A way to poll on two sockets, or > on socket and channel simultaneously may work for me. Similarly it may > be an ability to kill the task. Or a way to send an interruption > signal (similar to EINTR). I agree that waking up a task arbitrarily blocked at any location is quite useful. It is also a significant amount of implementation to do so, and we do not plan on doing so at this time. Things like selection over sockets would likely come with an async I/O library which is planned for post-1.0 From ecreed at cs.washington.edu Thu May 15 20:36:50 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Thu, 15 May 2014 20:36:50 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: I'm down for a meetup. I may be able to bring some others from UW CSE with me. On Thu, May 15, 2014 at 1:46 PM, Paul Nathan wrote: > Hi, > > It looks like two people have expressed interest in this. I think that's > enough to get together and talk. > > My suggestion for scheduling is next Thursday (May 22nd) at 7-9pm at > Remedy Teas[1] on Capitol Hill. > > Proposed topics: > > - meet & greet > - talk about extant Rust projects (if any) > - planned targets for projects. > > > Does this seem convenient & work for everyone interested? > > > [1] http://remedyteas.com > Remedy Teas > 345 15th Ave E > Seattle, WA 98112 > > > On Mon, May 12, 2014 at 5:05 PM, Eli Lindsey wrote: > >> +1 >> >> Somewhere around Capitol Hill would be very convenient. >> >> On May 12, 2014, at 11:31 AM, Paul Nathan >> wrote: >> >> Remedy Teas on Capitol Hill if interest is < 7 people. >> >> I am open to other alternatives, but don't usually prefer places with >> alcohol. I e I like coffee and tea shops. >> On May 12, 2014 10:14 AM, "benjamin adamson" >> wrote: >> >>> +1 where in Seattle are you thinking? >>> On May 11, 2014 11:08 PM, "Paul Nathan" >>> wrote: >>> >>>> Hi, >>>> >>>> This email is to gauge interest in doing a Rust meetup in Seattle. If >>>> there's interest, I'll coordinate finding a place & time that accomodates >>>> people. >>>> >>>> Regards, >>>> Paul >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Thu May 15 21:10:00 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 16 May 2014 07:10:00 +0300 Subject: [rust-dev] Why explicit named lifetimes? Message-ID: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function? From danielmicay at gmail.com Thu May 15 21:14:33 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 16 May 2014 00:14:33 -0400 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> Message-ID: <537590A9.3040809@gmail.com> On 16/05/14 12:10 AM, Tommi wrote: > I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function? Type inference is local to functions, so it couldn't do that. It would be impossible to have libraries if inference needed to be global across the entire program, and the errors would be *signicantly* harder to understand as they would span across countless functions. The named lifetimes draw a boundary where your intuition is checked, and the errors end up comprehensible by a mere human like myself. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu May 15 21:16:08 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 16 May 2014 00:16:08 -0400 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <537590A9.3040809@gmail.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> Message-ID: <53759108.3090300@gmail.com> On 16/05/14 12:14 AM, Daniel Micay wrote: > On 16/05/14 12:10 AM, Tommi wrote: >> I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function? > > Type inference is local to functions, so it couldn't do that. It would > be impossible to have libraries if inference needed to be global across > the entire program, and the errors would be *signicantly* harder to > understand as they would span across countless functions. > > The named lifetimes draw a boundary where your intuition is checked, and > the errors end up comprehensible by a mere human like myself. to a mere human* (see? if only my brain could have a bug fix release) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rusty.gates at icloud.com Thu May 15 21:30:02 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 16 May 2014 07:30:02 +0300 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <537590A9.3040809@gmail.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> Message-ID: On 2014-05-16, at 7:14, Daniel Micay wrote: > On 16/05/14 12:10 AM, Tommi wrote: >> I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function? > > Type inference is local to functions, so it couldn't do that. It would > be impossible to have libraries if inference needed to be global across > the entire program, and the errors would be *signicantly* harder to > understand as they would span across countless functions. I'm sorry, but for some reason I completely fail to understand your explanation. My thinking of how the compiler would work is that whenever it compiles a function, it would analyze it and in some sense "write in" the named lifetimes for that function. The named lifetimes would still be explicitly part of the signature of the function in the compiler's internal representation of the function, but not be visible in the source code. From sfackler at gmail.com Thu May 15 21:35:37 2014 From: sfackler at gmail.com (Steven Fackler) Date: Thu, 15 May 2014 21:35:37 -0700 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> Message-ID: Type annotations are not there for the compiler; they're there for people reading the code. If I want to use some function I don't want to be forced to read the entire implementation to figure out what the lifetime of the return value is. Steven Fackler On Thu, May 15, 2014 at 9:30 PM, Tommi wrote: > On 2014-05-16, at 7:14, Daniel Micay wrote: > > > On 16/05/14 12:10 AM, Tommi wrote: > >> I was just wondering, why do we have to explicitly specify the > lifetimes of references returned from functions? Couldn't the compiler > figure those lifetimes out by itself by analyzing the code in the function? > > > > Type inference is local to functions, so it couldn't do that. It would > > be impossible to have libraries if inference needed to be global across > > the entire program, and the errors would be *signicantly* harder to > > understand as they would span across countless functions. > > I'm sorry, but for some reason I completely fail to understand your > explanation. > > My thinking of how the compiler would work is that whenever it compiles a > function, it would analyze it and in some sense "write in" the named > lifetimes for that function. The named lifetimes would still be explicitly > part of the signature of the function in the compiler's internal > representation of the function, but not be visible in the source code. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Thu May 15 21:48:26 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 16 May 2014 07:48:26 +0300 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> Message-ID: <5409875E-AABE-40E2-81FD-7B06B27098DA@icloud.com> On 2014-05-16, at 7:35, Steven Fackler wrote: > Type annotations are not there for the compiler; they're there for people reading the code. If I want to use some function I don't want to be forced to read the entire implementation to figure out what the lifetime of the return value is. Just to be sure... I take it you are in fact implying that "yes, it is possible for the compiler to figure out those lifetimes without the programmer explicitly specifying them in the function signature"? From danielmicay at gmail.com Thu May 15 21:54:04 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 16 May 2014 00:54:04 -0400 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <5409875E-AABE-40E2-81FD-7B06B27098DA@icloud.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <5409875E-AABE-40E2-81FD-7B06B27098DA@icloud.com> Message-ID: <537599EC.9070809@gmail.com> On 16/05/14 12:48 AM, Tommi wrote: > On 2014-05-16, at 7:35, Steven Fackler wrote: > >> Type annotations are not there for the compiler; they're there for people reading the code. If I want to use some function I don't want to be forced to read the entire implementation to figure out what the lifetime of the return value is. > > Just to be sure... I take it you are in fact implying that "yes, it is possible for the compiler to figure out those lifetimes without the programmer explicitly specifying them in the function signature"? Lifetimes are based on subtyping, and AFAIK that presents huge problems for type inference. You would need to ask Niko how feasible it would be to infer it globally. I used to run into all sorts of problems with the *local* inference but it got a lot better. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From loebel.marvin at gmail.com Fri May 16 02:53:13 2014 From: loebel.marvin at gmail.com (=?UTF-8?Q?Marvin_L=C3=B6bel?=) Date: Fri, 16 May 2014 11:53:13 +0200 Subject: [rust-dev] How to implement a singleton ? In-Reply-To: <5374A379.60100@exyr.org> References: <5374A379.60100@exyr.org> Message-ID: Hm, you make a good point: I should probably add a Share bound somwhere in there... Am 15.05.2014 13:22 schrieb "Simon Sapin" : > On 15/05/2014 08:59, Christophe Pedretti wrote: > >> I am trying to implement a Singleton (an object which instantiate only >> once, successive instantiations returning the object itself). >> Any tutorial for this ? any idea ? example ? best practice ? >> > > Kimundi published this macro to define lazily initialized statics, which > look to me equivalent to singletons although there is no "instanciation" > involved: > > https://gist.github.com/Kimundi/8782487 > http://www.reddit.com/r/rust/comments/1wvxcn/lazily_initialized_statics/ > > I believe this is only memory-safe with types that satisfy the `Share` > kind. > > http://static.rust-lang.org/doc/master/core/kinds/trait.Share.html > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrandao.br at gmail.com Fri May 16 16:57:19 2014 From: rbrandao.br at gmail.com (=?UTF-8?Q?Ricardo_Brand=C3=A3o?=) Date: Fri, 16 May 2014 20:57:19 -0300 Subject: [rust-dev] New on Rust/Servo Message-ID: Hi ALL, I'd like to introduce my self. I'm a Computer Engineer and I've worked with Embedded Computer for 12 years before work with IT Management for 10 years. Now I became a Mozillian, studying Firefox OS, Gonk and Gecko and very excited to come back to technical "world". Last week I attended a lecture on FISL (a Free Software Forum) in Brazil about Rust and Servo. From Bruno Abinader I'm very interested on these project and I'd like to join it. I have a good experience with C and Assembly, but not exactly with Unix-like platform. I was used to program directly to the board. I've used ZWorld Boards (nowadays ZWorld became Digi). But I tried to see some "Easy" bugs (on rust and servo repos) to at least understand, but I'm confused. Could you give me some step-by-step, how begin the study of project, which documents to read, etc? Remember I'm not an expert on Makefile and C for Unix-like platforms. Well, I already worked with but in small projects. Thanks in advance! -- Ricardo Brand?o http://www.programonauta.com.br ........__@ ....._ \ >_ ....(_) / (_) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Fri May 16 17:54:21 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 16 May 2014 17:54:21 -0700 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <537599EC.9070809@gmail.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <5409875E-AABE-40E2-81FD-7B06B27098DA@icloud.com> <537599EC.9070809@gmail.com> Message-ID: <7D0CED41-1836-4E06-B12E-ECD61D86F6BA@sb.org> On May 15, 2014, at 9:54 PM, Daniel Micay wrote: > On 16/05/14 12:48 AM, Tommi wrote: >> On 2014-05-16, at 7:35, Steven Fackler wrote: >> >>> Type annotations are not there for the compiler; they're there for people reading the code. If I want to use some function I don't want to be forced to read the entire implementation to figure out what the lifetime of the return value is. >> >> Just to be sure... I take it you are in fact implying that "yes, it is possible for the compiler to figure out those lifetimes without the programmer explicitly specifying them in the function signature"? > > Lifetimes are based on subtyping, and AFAIK that presents huge problems > for type inference. You would need to ask Niko how feasible it would be > to infer it globally. I used to run into all sorts of problems with the > *local* inference but it got a lot better. I don't think global inference even is possible for this, because the lifetimes affect borrowing. Example: pub trait Foo { fn foo(&self) -> &str; } This is a trait that defines a method `foo()` that returns a reference. I've elided the lifetimes. Now tell me, if I'm calling this method through a generic (or a trait object), what is the lifetime of the returned value? Is it the same as `&self`, meaning does it need to borrow the receiver? Or is it 'static (which won't borrow the receiver)? -Kevin From ben.striegel at gmail.com Fri May 16 17:59:54 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 16 May 2014 20:59:54 -0400 Subject: [rust-dev] New on Rust/Servo In-Reply-To: References: Message-ID: Welcome! The easiest way to install the compiler will be to download the binaries here: http://www.rust-lang.org/install.html . Prefer the "Nightly" binaries and not the 0.10 binaries. Unzip the download and run the "install.sh" script inside. If you're using Linux, you can do the above steps using the following command: wget http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz&& tar xvf rust-nightly-x86_64-unknown-linux-gnu.tar.gz && cd rust-nightly-x86_64-unknown-linux-gnu/ && sudo ./install.sh This will give you a copy of the compiler to play around with. Test it out like this: rustc --help Compile and run the "hello world" program: echo 'fn main() { println!("Hello, Ricardo!"); }' | rustc -o hello '-' && ./hello Compile (but not run) a program from a file: rustc foo.rs Read the tutorial to get started: http://static.rust-lang.org/doc/master/tutorial.html Then join the IRC channel to ask questions: http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust And once you're ready to start working on the compiler itself, here's how you can compile it from the source code: git clone https://github.com/mozilla/rust.git && cd rust && ./configure && make install Good luck! :) On Fri, May 16, 2014 at 7:57 PM, Ricardo Brand?o wrote: > Hi ALL, > > I'd like to introduce my self. I'm a Computer Engineer and I've worked > with Embedded Computer for 12 years before work with IT Management for 10 > years. > > Now I became a Mozillian, studying Firefox OS, Gonk and Gecko and very > excited to come back to technical "world". > > Last week I attended a lecture on FISL (a Free Software Forum) in Brazil > about Rust and Servo. From Bruno Abinader > > I'm very interested on these project and I'd like to join it. > > I have a good experience with C and Assembly, but not exactly with > Unix-like platform. I was used to program directly to the board. I've used > ZWorld Boards (nowadays ZWorld became Digi). > > But I tried to see some "Easy" bugs (on rust and servo repos) to at least > understand, but I'm confused. > > Could you give me some step-by-step, how begin the study of project, which > documents to read, etc? Remember I'm not an expert on Makefile and C for > Unix-like platforms. Well, I already worked with but in small projects. > > Thanks in advance! > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Fri May 16 18:04:22 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 16 May 2014 18:04:22 -0700 Subject: [rust-dev] how to capture de-reference to ~int In-Reply-To: References: Message-ID: If you want that, you'll need to use a custom pointer type instead of ~. You can use ~ internally, and implement Deref/DerefMut to do the desired capturing. pub struct Ptr { value: ~T // assuming 0.10 here, master would be Box } impl Ptr { pub fn new(val: T) -> Ptr { Ptr { value: ~val } } } impl Deref for Ptr { fn deref<'a>(&'a self) -> &'a T { // do any capturing of the dereference here &*self.value } } impl DerefMut for Ptr { fn deref_mut<'a>(&'a mut self) -> &'a mut T { // do any capturing of the mutable dereference here &mut *self.value } } fn main() { let x = Ptr::new(3i); println!("x: {}", *x); } -Kevin On May 13, 2014, at 9:16 PM, Noah Watkins wrote: > On Tue, May 13, 2014 at 2:19 PM, Alex Crichton wrote: >> The ~int type has since moved to Box, which will one day be a >> library type with Deref implemented on it (currently it is implemented >> by the compiler). > > Thanks for the note. I'm using a slightly older version that doesn't > have Box, but it sounds like ~ is also implemented with the > compiler. I was actually looking into this because I was interested in > intercepting the deref (as well as allocate/free) for some distributed > shared-memory experiments. Some of the safety checks rust performs > simplifies the coherency requirements needed of the storage layer > (e.g. expensive locking). > > -Noah > >> >> On Mon, May 12, 2014 at 11:50 AM, Noah Watkins wrote: >>> I am trying to capture the reference to type `~int` with the following >>> code. I can change it to apply to bare `int` and it works fine. >>> >>> #[lang="deref"] >>> pub trait Deref { >>> fn deref<'a>(&'a self) -> &'a Result; >>> } >>> >>> impl Deref<~int> for ~int { >>> fn deref<'a>(&'a self) -> &'a ~int { >>> println!("deref caught"); >>> self >>> } >>> } >>> >>> fn main() { >>> let x: ~int = 3; >>> *x >>> } >>> >>> Thanks, >>> Noah >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From rusty.gates at icloud.com Fri May 16 23:37:18 2014 From: rusty.gates at icloud.com (Tommi) Date: Sat, 17 May 2014 09:37:18 +0300 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <7D0CED41-1836-4E06-B12E-ECD61D86F6BA@sb.org> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <5409875E-AABE-40E2-81FD-7B06B27098DA@icloud.com> <537599EC.9070809@gmail.com> <7D0CED41-1836-4E06-B12E-ECD61D86F6BA@sb.org> Message-ID: On 2014-05-17, at 3:54, Kevin Ballard wrote: > On May 15, 2014, at 9:54 PM, Daniel Micay wrote: > >> On 16/05/14 12:48 AM, Tommi wrote: >>> On 2014-05-16, at 7:35, Steven Fackler wrote: >>> >>>> Type annotations are not there for the compiler; they're there for people reading the code. If I want to use some function I don't want to be forced to read the entire implementation to figure out what the lifetime of the return value is. >>> >>> Just to be sure... I take it you are in fact implying that "yes, it is possible for the compiler to figure out those lifetimes without the programmer explicitly specifying them in the function signature"? >> >> Lifetimes are based on subtyping, and AFAIK that presents huge problems >> for type inference. You would need to ask Niko how feasible it would be >> to infer it globally. I used to run into all sorts of problems with the >> *local* inference but it got a lot better. > > I don't think global inference even is possible for this, because the lifetimes affect borrowing. Example: > > pub trait Foo { > fn foo(&self) -> &str; > } > > This is a trait that defines a method `foo()` that returns a reference. I've elided the lifetimes. Now tell me, if I'm calling this method through a generic (or a trait object), what is the lifetime of the returned value? Is it the same as `&self`, meaning does it need to borrow the receiver? Or is it 'static (which won't borrow the receiver)? > > -Kevin I don't think generics (static polymorphism) poses a problem, because for those the compiler knows exactly which function a call to 'a.foo()' resolves to. But your point about trait objects (dynamic polymorphism) is good. For trait objects the compiler doesn't know which function is being called. So, it seems that explicit named lifetime notation is necessary at least for functions in traits. From artella.coding at googlemail.com Sat May 17 04:11:27 2014 From: artella.coding at googlemail.com (Artella Coding) Date: Sat, 17 May 2014 12:11:27 +0100 Subject: [rust-dev] New on Rust/Servo In-Reply-To: References: Message-ID: http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/ On Sat, May 17, 2014 at 12:57 AM, Ricardo Brand?o wrote: > Hi ALL, > > I'd like to introduce my self. I'm a Computer Engineer and I've worked > with Embedded Computer for 12 years before work with IT Management for 10 > years. > > Now I became a Mozillian, studying Firefox OS, Gonk and Gecko and very > excited to come back to technical "world". > > Last week I attended a lecture on FISL (a Free Software Forum) in Brazil > about Rust and Servo. From Bruno Abinader > > I'm very interested on these project and I'd like to join it. > > I have a good experience with C and Assembly, but not exactly with > Unix-like platform. I was used to program directly to the board. I've used > ZWorld Boards (nowadays ZWorld became Digi). > > But I tried to see some "Easy" bugs (on rust and servo repos) to at least > understand, but I'm confused. > > Could you give me some step-by-step, how begin the study of project, which > documents to read, etc? Remember I'm not an expert on Makefile and C for > Unix-like platforms. Well, I already worked with but in small projects. > > Thanks in advance! > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sat May 17 05:02:35 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sat, 17 May 2014 14:02:35 +0200 Subject: [rust-dev] New on Rust/Servo In-Reply-To: References: Message-ID: And let's not forget the ever useful https://github.com/bvssvni/rust-emptyto get a pre-made Makefile for rust. On Sat, May 17, 2014 at 1:11 PM, Artella Coding < artella.coding at googlemail.com> wrote: > http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/ > > > > On Sat, May 17, 2014 at 12:57 AM, Ricardo Brand?o wrote: > >> Hi ALL, >> >> I'd like to introduce my self. I'm a Computer Engineer and I've worked >> with Embedded Computer for 12 years before work with IT Management for 10 >> years. >> >> Now I became a Mozillian, studying Firefox OS, Gonk and Gecko and very >> excited to come back to technical "world". >> >> Last week I attended a lecture on FISL (a Free Software Forum) in Brazil >> about Rust and Servo. From Bruno Abinader >> >> I'm very interested on these project and I'd like to join it. >> >> I have a good experience with C and Assembly, but not exactly with >> Unix-like platform. I was used to program directly to the board. I've used >> ZWorld Boards (nowadays ZWorld became Digi). >> >> But I tried to see some "Easy" bugs (on rust and servo repos) to at least >> understand, but I'm confused. >> >> Could you give me some step-by-step, how begin the study of project, >> which documents to read, etc? Remember I'm not an expert on Makefile and C >> for Unix-like platforms. Well, I already worked with but in small projects. >> >> Thanks in advance! >> >> -- >> Ricardo Brand?o >> http://www.programonauta.com.br >> >> ........__@ >> ....._ \ >_ >> ....(_) / (_) >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayhawk at cs.ucsc.edu Sat May 17 07:58:19 2014 From: jayhawk at cs.ucsc.edu (Noah Watkins) Date: Sat, 17 May 2014 07:58:19 -0700 Subject: [rust-dev] method on generic type parameters Message-ID: I'm running into a problem creating a generic wrapper around an FFI interface of the following form: fn ffi_process(data: *c_void, count: c_int, type: *c_void); where `data` points to an array of `count` elements of each of type `type`. Each `type` is represented by a constant opaque pointer to some fixed symbol exported by the C library and corresponding to a particular type (e.g. DT_INT32, DT_FLOAT32, etc...). My approach so far has been to use a trait to map Rust data types to data types in the library as follows: trait MySendable { fn datatype() -> *c_void; } impl MySendable for int { fn datatype() -> *c_void { DT_INT32 } } fn process(data: &[T]) { unsafe { ffi_process(data.as_ptr(), data.len(), T::datatype()); } } But, Rust does not like this at all. I have seen many many references on github issues and SO about methods on the types, but it isn't clear what the current / future approach is / will be. Is this (1) a reasonable approach to the problem (even if not currently possible), and (2) are there other ways to bend the type system to my needs here? Thanks! Noah From kevin at sb.org Sat May 17 15:12:34 2014 From: kevin at sb.org (Kevin Ballard) Date: Sat, 17 May 2014 15:12:34 -0700 Subject: [rust-dev] method on generic type parameters In-Reply-To: References: Message-ID: <57F7FF48-F85C-402B-8AC3-53DADBE1D1F1@sb.org> Rust doesn't like this because datatype() is not a method on T. It's a method on MySendable. There are various proposals that will fix this (including UFCS, and a proposal to make T::datatype() work as you just tried). But for the time being, you basically cannot have a trait method that does not use Self anywhere in its type signature (which is to say, it doesn't take a `self` parameter, and it does not use the Self pseudo-type). A common workaround here is to add a parameter of type Option, so you can pass None in order to provide the correct type info: trait MySendable { fn datatype(_: Option) -> *c_void; } impl MySendable for int { fn datatype(_: Option) -> *c_void { DT_INT32 } } fn process(data: &[T]) { unsafe { ffi_process(data.as_ptr(), data.len(), MySendable::datatype(None::)); } } I do have to wonder, though, how you intend to map from the type pointer back to the original type. Or do you not need to go in that direction? If you do, I think you'll need to ditch the trait and instead just use an enum: enum MySendable<'a> { SendableInt(&'a [int]), SendableFoo(&'a [Foo]), ... } impl<'a> MySendable<'a> { fn datatype(&self) -> *c_void { match *self { SendableInt(_) => DT_INT32, SendableFoo(_) => DT_FOO, ... } } } This approach lets you produce a reverse mapping as well. However, if you don't need the reverse mapping, then the trait approach seems like a reasonable way to handle things. -Kevin On May 17, 2014, at 7:58 AM, Noah Watkins wrote: > I'm running into a problem creating a generic wrapper around an FFI > interface of the following form: > > fn ffi_process(data: *c_void, count: c_int, type: *c_void); > > where `data` points to an array of `count` elements of each of type > `type`. Each `type` is represented by a constant opaque pointer to > some fixed symbol exported by the C library and corresponding to a > particular type (e.g. DT_INT32, DT_FLOAT32, etc...). > > My approach so far has been to use a trait to map Rust data types to > data types in the library as follows: > > trait MySendable { > fn datatype() -> *c_void; > } > > impl MySendable for int { > fn datatype() -> *c_void { DT_INT32 } > } > > fn process(data: &[T]) { > unsafe { > ffi_process(data.as_ptr(), data.len(), T::datatype()); > } > } > > But, Rust does not like this at all. I have seen many many references > on github issues and SO about methods on the types, but it isn't clear > what the current / future approach is / will be. > > Is this (1) a reasonable approach to the problem (even if not > currently possible), and (2) are there other ways to bend the type > system to my needs here? > > Thanks! > Noah > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From jayhawk at cs.ucsc.edu Sat May 17 16:36:59 2014 From: jayhawk at cs.ucsc.edu (Noah Watkins) Date: Sat, 17 May 2014 16:36:59 -0700 Subject: [rust-dev] method on generic type parameters In-Reply-To: <57F7FF48-F85C-402B-8AC3-53DADBE1D1F1@sb.org> References: <57F7FF48-F85C-402B-8AC3-53DADBE1D1F1@sb.org> Message-ID: On Sat, May 17, 2014 at 3:12 PM, Kevin Ballard wrote: > > A common workaround here is to add a parameter of type Option, so you can pass None in order to provide the correct type info: Ahh, clever workaround, thanks. I'm looking forward to see how the underlying issue is resolved in the future. > I do have to wonder, though, how you intend to map from the type pointer back to the original type. Or do you not need to go in that direction? This is a great question, and i'm not entirely sure yet. The C library (MPI) has largely two flavors that need to be handled. The first case are calls that need to be paired together and have their types match: For example, the C library has: MPI_Send(data, len, type) MPI_Recv(data, len, type) where for two processes with matching send/recv should use the same type. It seems as though one method for making this safe is two use something akin to channels two link the underlying send/recv methods for a particular use. At the moment I am exposing the raw-ish interfaces and not perform any type checking. In fact, it isn't completely clear how / if using a channel abstraction would affect the structure of MPI programs. With the low-level interfaces alone I'm not sure how type checking could be done as correctness is more of a function of the program execution. The other type is easier: MPI_Sendrecv(datain, dataout, len, type) which performs a simultaneous send/recv so the type is easy to figure out. > If you do, I think you'll need to ditch the trait and instead just use an enum: If I understand correctly, the enum would address the problem of being handed a DT_INT32 and map it back to the corresponding Rust type? I'm not sure if this will be an issue or not, because all the interfaces I can think of force the caller to specify the expected type, which we can compute from the associated type of a Rust data structure being operated on. I hope that makes sense. -Noah From aaron.devore at gmail.com Sat May 17 19:01:28 2014 From: aaron.devore at gmail.com (Aaron DeVore) Date: Sat, 17 May 2014 19:01:28 -0700 Subject: [rust-dev] Needed Small-to-Medium Projects Message-ID: I am currently in the process of learning Rust. A good way to do that is to start a small to medium size project. I want to help improve the Rust ecosystem in the process. Are there any specific niches that need a library of small to medium complexity? -Aaron DeVore -------------- next part -------------- An HTML attachment was scrubbed... URL: From phiroc at free.fr Sun May 18 02:57:55 2014 From: phiroc at free.fr (Philippe de Rochambeau) Date: Sun, 18 May 2014 11:57:55 +0200 Subject: [rust-dev] Fwd: unexpected token: `)` with new owning-pointer syntax, bis References: <783483CD-B54A-41AF-B99B-0C0008A8396D@free.fr> Message-ID: Hello again, this syntax works. let list: List = Cons(1, box Cons(2, box Cons(3, box Nil))); Please disregard my previous e-mail. Phiroc D?but du message r?exp?di? : > De: Philippe de Rochambeau > Objet: unexpected token: `)` with new owning-pointer syntax > Date: 18 mai 2014 10:56:42 UTC+2 > ?: rust-dev at mozilla.org > > > Hello, > > as a learning exercise, I have converted this code (found here: http://words.steveklabnik.com/pointers-in-rust-a-guide) > > enum List { > Nil, > Cons(T, ~List), > } > > fn main() { > let list: List = Cons(1, ~Cons(2, ~Cons(3, ~Nil))); > println!("{:?}", list); > } > to the new Rust 0.11 owning-pointer syntax (http://static.rust-lang.org/doc/master/rust.html#pointer-types): > > enum List { > Nil, > Cons(T, Box>), > } > > fn main() { > // http://words.steveklabnik.com/pointers-in-rust-a-guide > // let list: List = Cons(1, ~Cons(2, ~Cons(3, ~Nil))); > let list: List = > Cons(1,Box)>)>); > > println!("{:?}", list); > } > > When I compile the above code, I get the following error (although all my opening an closing parentheses seem to match): > > rustc pointer.rs > pointer.rs:10:40: 10:41 error: unexpected token: `)` > pointer.rs:10 Cons(1,Box)>)>); > ^ > make: *** [cmp] Error 101 > > > Am I using the new owning-pointer syntax incorrectly? > > Many thanks. > > Phiroc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at urbanhafner.com Mon May 19 01:01:23 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Mon, 19 May 2014 10:01:23 +0200 Subject: [rust-dev] Needed Small-to-Medium Projects In-Reply-To: References: Message-ID: You are much more altruistic than me Aaron ;) I just started my own projectthat probably adds nothing to the eco system. If you don't find something to work on you could just join. I'm also a Rust newbie and so is the other dev (although he knows more about it than me). Urban On Sun, May 18, 2014 at 4:01 AM, Aaron DeVore wrote: > I am currently in the process of learning Rust. A good way to do that is > to start a small to medium size project. I want to help improve the Rust > ecosystem in the process. Are there any specific niches that need a library > of small to medium complexity? > > -Aaron DeVore > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon May 19 11:52:08 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 19 May 2014 11:52:08 -0700 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> Message-ID: <537A52D8.8010001@mozilla.com> On 05/15/2014 09:30 PM, Tommi wrote: > On 2014-05-16, at 7:14, Daniel Micay wrote: > >> On 16/05/14 12:10 AM, Tommi wrote: >>> I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function? >> >> Type inference is local to functions, so it couldn't do that. It would >> be impossible to have libraries if inference needed to be global across >> the entire program, and the errors would be *signicantly* harder to >> understand as they would span across countless functions. > > I'm sorry, but for some reason I completely fail to understand your explanation. > > My thinking of how the compiler would work is that whenever it compiles a function, it would analyze it and in some sense "write in" the named lifetimes for that function. The named lifetimes would still be explicitly part of the signature of the function in the compiler's internal representation of the function, but not be visible in the source code. > I believe the compiler does this anylisis when the lifetimes in a signature are wrong - but just for the error message. It tries to suggest lifetimes that will work, but the analysis is not foolproof and can't be done automatically generally (idk why, ask niko). From walter_bz at hotmail.com Mon May 19 12:20:45 2014 From: walter_bz at hotmail.com (walter lynsdale) Date: Mon, 19 May 2014 19:20:45 +0000 Subject: [rust-dev] Rust-dev Digest, Vol 47, Issue 19 In-Reply-To: References: Message-ID: > From: rust-dev-request at mozilla.org > Subject: Rust-dev Digest, Vol 47, Issue 19 > To: rust-dev at mozilla.org > Date: Mon, 19 May 2014 12:00:03 -0700 > > Send Rust-dev mailing list submissions to > rust-dev at mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/rust-dev > or, via email, send a message with subject or body 'help' to > rust-dev-request at mozilla.org > > You can reach the person managing the list at > rust-dev-owner at mozilla.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rust-dev digest..." > > > Today's Topics: > > 1. Re: Needed Small-to-Medium Projects (Urban Hafner) > 2. Re: Why explicit named lifetimes? (Brian Anderson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 19 May 2014 10:01:23 +0200 > From: Urban Hafner > To: Aaron DeVore > Cc: Rust-dev at mozilla.org > Subject: Re: [rust-dev] Needed Small-to-Medium Projects > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > You are much more altruistic than me Aaron ;) I just started my own > projectthat probably adds nothing > to the eco system. If you don't find something > to work on you could just join. I'm also a Rust newbie and so is the other > dev (although he knows more about it than me). > > Urban > > > On Sun, May 18, 2014 at 4:01 AM, Aaron DeVore wrote: > > > I am currently in the process of learning Rust. A good way to do that is > > to start a small to medium size project. I want to help improve the Rust > > ecosystem in the process. Are there any specific niches that need a library > > of small to medium complexity? > > > > -Aaron DeVore > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Mon, 19 May 2014 11:52:08 -0700 > From: Brian Anderson > To: rust-dev at mozilla.org > Subject: Re: [rust-dev] Why explicit named lifetimes? > Message-ID: <537A52D8.8010001 at mozilla.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 05/15/2014 09:30 PM, Tommi wrote: > > On 2014-05-16, at 7:14, Daniel Micay wrote: > > > >> On 16/05/14 12:10 AM, Tommi wrote: > >>> I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function? > >> > >> Type inference is local to functions, so it couldn't do that. It would > >> be impossible to have libraries if inference needed to be global across > >> the entire program, and the errors would be *signicantly* harder to > >> understand as they would span across countless functions. > > > > I'm sorry, but for some reason I completely fail to understand your explanation. > > > > My thinking of how the compiler would work is that whenever it compiles a function, it would analyze it and in some sense "write in" the named lifetimes for that function. The named lifetimes would still be explicitly part of the signature of the function in the compiler's internal representation of the function, but not be visible in the source code. > > > > I believe the compiler does this anylisis when the lifetimes in a > signature are wrong - but just for the error message. It tries to > suggest lifetimes that will work, but the analysis is not foolproof and > can't be done automatically generally (idk why, ask niko). > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > ------------------------------ > > End of Rust-dev Digest, Vol 47, Issue 19 > **************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamson.benjamin at gmail.com Mon May 19 13:36:23 2014 From: adamson.benjamin at gmail.com (benjamin adamson) Date: Mon, 19 May 2014 13:36:23 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: I'll be there! I don't have a particular project I am working on at the moment though! On Thu, May 15, 2014 at 8:36 PM, Eric Reed wrote: > I'm down for a meetup. I may be able to bring some others from UW CSE with > me. > > > On Thu, May 15, 2014 at 1:46 PM, Paul Nathan wrote: > >> Hi, >> >> It looks like two people have expressed interest in this. I think that's >> enough to get together and talk. >> >> My suggestion for scheduling is next Thursday (May 22nd) at 7-9pm at >> Remedy Teas[1] on Capitol Hill. >> >> Proposed topics: >> >> - meet & greet >> - talk about extant Rust projects (if any) >> - planned targets for projects. >> >> >> Does this seem convenient & work for everyone interested? >> >> >> [1] http://remedyteas.com >> Remedy Teas >> 345 15th Ave E >> Seattle, WA 98112 >> >> >> On Mon, May 12, 2014 at 5:05 PM, Eli Lindsey wrote: >> >>> +1 >>> >>> Somewhere around Capitol Hill would be very convenient. >>> >>> On May 12, 2014, at 11:31 AM, Paul Nathan >>> wrote: >>> >>> Remedy Teas on Capitol Hill if interest is < 7 people. >>> >>> I am open to other alternatives, but don't usually prefer places with >>> alcohol. I e I like coffee and tea shops. >>> On May 12, 2014 10:14 AM, "benjamin adamson" < >>> adamson.benjamin at gmail.com> wrote: >>> >>>> +1 where in Seattle are you thinking? >>>> On May 11, 2014 11:08 PM, "Paul Nathan" >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> This email is to gauge interest in doing a Rust meetup in Seattle. If >>>>> there's interest, I'll coordinate finding a place & time that accomodates >>>>> people. >>>>> >>>>> Regards, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Adamson, Benjamin adamson.benjamin at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrandao.br at gmail.com Mon May 19 14:43:56 2014 From: rbrandao.br at gmail.com (=?UTF-8?Q?Ricardo_Brand=C3=A3o?=) Date: Mon, 19 May 2014 18:43:56 -0300 Subject: [rust-dev] Using gdb on rust Message-ID: Hi All, Today I've tried to use gdb to debug rust programs. I compiled with -g: rustc -g hello.rs and ran gdb hello On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already faced this issue on Mac? Thanks in advance -- Ricardo Brand?o http://www.programonauta.com.br ........__@ ....._ \ >_ ....(_) / (_) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihmccreery at gmail.com Mon May 19 14:54:20 2014 From: ihmccreery at gmail.com (Isaac Hollander McCreery) Date: Mon, 19 May 2014 17:54:20 -0400 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: Hi Ricardo, Can you provide more information about how it fails? OS X 10.9 no longer ships with gdb, instead preferring lldb, (the whole system has shifted over to LLVM's ecosystem, e.g. clang instead of gcc). Have you tried lldb? Regards, Ike On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o wrote: > Hi All, > > Today I've tried to use gdb to debug rust programs. > > I compiled with -g: rustc -g hello.rs > > and ran gdb hello > > On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already > faced this issue on Mac? > > Thanks in advance > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon May 19 15:01:30 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 19 May 2014 15:01:30 -0700 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: <537A7F3A.7070609@mozilla.com> The exact versions of the tooling here is pretty important - our ability to support debugging is extremely version dependent, especially when it comes to lldb. On mac I believe we are not putting any particular effort into supporting gdb at this point since lldb is the future. Newer lldb's work better than older, and lldb support is still a WIP. On 05/19/2014 02:54 PM, Isaac Hollander McCreery wrote: > Hi Ricardo, > > Can you provide more information about how it fails? > > OS X 10.9 no longer ships with gdb, instead preferring lldb, (the > whole system has shifted over to LLVM's ecosystem, e.g. clang instead > of gcc). Have you tried lldb? > > Regards, > Ike > > > On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o > > wrote: > > Hi All, > > Today I've tried to use gdb to debug rust programs. > > I compiled with -g: rustc -g hello.rs > > and ran gdb hello > > On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone > already faced this issue on Mac? > > Thanks in advance > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From echristo at gmail.com Mon May 19 15:27:45 2014 From: echristo at gmail.com (Eric Christopher) Date: Mon, 19 May 2014 15:27:45 -0700 Subject: [rust-dev] Using gdb on rust In-Reply-To: <537A7F3A.7070609@mozilla.com> References: <537A7F3A.7070609@mozilla.com> Message-ID: On Mon, May 19, 2014 at 3:01 PM, Brian Anderson wrote: > The exact versions of the tooling here is pretty important - our ability to > support debugging is extremely version dependent, especially when it comes > to lldb. > > On mac I believe we are not putting any particular effort into supporting > gdb at this point since lldb is the future. Newer lldb's work better than > older, and lldb support is still a WIP. > > At the moment you may wish to make sure that you emit dwarf2 era dwarf for osx if you aren't. lldb has some problems with various dwarf3+ constructs. I'm not sure if the OP is running into one of those things, I'll pay attention to the thread and see what pops up. -eric > > On 05/19/2014 02:54 PM, Isaac Hollander McCreery wrote: > > Hi Ricardo, > > Can you provide more information about how it fails? > > OS X 10.9 no longer ships with gdb, instead preferring lldb, (the whole > system has shifted over to LLVM's ecosystem, e.g. clang instead of gcc). > Have you tried lldb? > > Regards, > Ike > > > On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o > wrote: >> >> Hi All, >> >> Today I've tried to use gdb to debug rust programs. >> >> I compiled with -g: rustc -g hello.rs >> >> and ran gdb hello >> >> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already >> faced this issue on Mac? >> >> Thanks in advance >> >> -- >> Ricardo Brand?o >> http://www.programonauta.com.br >> >> ........__@ >> ....._ \ >_ >> ....(_) / (_) >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From zacharyjtong at gmail.com Tue May 20 06:37:15 2014 From: zacharyjtong at gmail.com (Zachary Tong) Date: Tue, 20 May 2014 09:37:15 -0400 Subject: [rust-dev] Splitting The Tutorial/Guides In-Reply-To: References: <21882992-6A64-4202-A801-C957C1E35EC6@gmail.com> Message-ID: This is great! My biggest frustration with the current tutorial is the navigation: it is very difficult to know what sections/guides/tutorials are available, and once you navigate to a guide, there is no navigation to other guides. I often resort to just closing the tab and googling a new section that I know exists. The demo layout looks fantastic. Can't wait :) -Zach On Thu, May 15, 2014 at 6:38 PM, Daniel Fagnan wrote: > Here's a demo I put up: > > http://rust-docs.s3-website-us-west-2.amazonaws.com/ > > -- > Daniel Fagnan > Titan Analytics Inc. > www.titananalytics.com > M: (780) 983-4997 > > > On Thu, May 15, 2014 at 3:02 PM, Daniel Fagnan wrote: > >> Awesome. I have started to refactor the curated documentation system >> using nanoc to power the static site. It's still super early, but I'm >> working straight out of the Rust source, so it'll be super easy to replace >> the current system. >> >> I started with a default nanoc site and it's default styles that are >> fairly decent (although it's css is pretty horrible). I'm now improving it >> as I go along. >> >> The main page I have as Steve's 30-Minute Introduction, and each page >> should link to further resources to continue the user along. After the >> beginning tutorial, similar to Julia's docs, there could be a "Getting >> Started" set of pages where you learn how to get Rust installed and >> everything. >> >> The screenshot shows basically the default nanoc theme with quite a few >> adjustments. It's simply a starting point. >> >> -- >> Daniel Fagnan >> Titan Analytics Inc. >> www.titananalytics.com >> M: (780) 983-4997 >> >> >> On Thu, May 15, 2014 at 2:47 PM, Alan Andrade wrote: >> >>> I?m pretty sure everybody agree with you. The guides, tutorial and >>> manual are always seen like a huge opportunity for improvement but few >>> people have really put effort on it. >>> >>> I?m currently refactoring the guides with the following goals in mind: >>> >>> 1. Keep consistency when we talk about ?pointers? or ?references? >>> 2. Nuke the idea of Managed boxes, and strive for owned boxes. >>> 3. Get rid of the sigils where it applies and use box instead. >>> >>> I have no plan to improve CSS or user experience. >>> >>> My feeling is that we just need to coordinate efforts. Maybe we can come >>> up with a plan where we split work by areas such as: content, style and ux ? >>> >>> Perhaps, this could be the goal for the first rust bay area hack night. >>> >>> - Alan >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrandao.br at gmail.com Tue May 20 08:46:01 2014 From: rbrandao.br at gmail.com (=?UTF-8?Q?Ricardo_Brand=C3=A3o?=) Date: Tue, 20 May 2014 12:46:01 -0300 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: Hi Isaac: Find below the output: $ cat h.rs fn main() { let ric = "Ricardo"; println!("Hello {}!", ric); } $ rustc -g h.rs $ gdb h GNU gdb (GDB) 7.7 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin12.5.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from h... warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't open to read symbols: No such file or directory. warning: can't find symbol 'get_num_cpus' in minsymtab warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab warning: can't find symbol 'je_chunk_dss_boot' in minsymtab warning: can't find symbol 'je_chunk_dss_postfork_child' in minsymtab warning: can't find symbol 'je_chunk_dss_postfork_parent' in minsymtab warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab warning: can't find symbol 'je_rtree_delete' in minsymtab done. (gdb) break main Breakpoint 1 at 0x1000015a0 (gdb) run Starting program: /Users/rbrandao/PrgRust/Tutorial/h Unable to find Mach task port for process-id 34102: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8)) (gdb) Regards, Ricardo On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery < ihmccreery at gmail.com> wrote: > Hi Ricardo, > > Can you provide more information about how it fails? > > OS X 10.9 no longer ships with gdb, instead preferring lldb, (the whole > system has shifted over to LLVM's ecosystem, e.g. clang instead of gcc). > Have you tried lldb? > > Regards, > Ike > > > On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o wrote: > >> Hi All, >> >> Today I've tried to use gdb to debug rust programs. >> >> I compiled with -g: rustc -g hello.rs >> >> and ran gdb hello >> >> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already >> faced this issue on Mac? >> >> Thanks in advance >> >> -- >> Ricardo Brand?o >> http://www.programonauta.com.br >> >> ........__@ >> ....._ \ >_ >> ....(_) / (_) >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- Ricardo Brand?o http://www.programonauta.com.br ........__@ ....._ \ >_ ....(_) / (_) -------------- next part -------------- An HTML attachment was scrubbed... URL: From echristo at gmail.com Tue May 20 10:04:00 2014 From: echristo at gmail.com (Eric Christopher) Date: Tue, 20 May 2014 10:04:00 -0700 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: > Type "apropos word" to search for commands related to "word"... > Reading symbols from h... > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't open to > read symbols: No such file or directory. > This seems bad. Does the file exist in that path? > warning: can't find symbol 'get_num_cpus' in minsymtab > > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab > > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab > > warning: can't find symbol 'je_chunk_dss_postfork_child' in minsymtab > > warning: can't find symbol 'je_chunk_dss_postfork_parent' in minsymtab > > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab > > warning: can't find symbol 'je_rtree_delete' in minsymtab > done. > (gdb) break main > Breakpoint 1 at 0x1000015a0 > (gdb) run > Starting program: /Users/rbrandao/PrgRust/Tutorial/h > Unable to find Mach task port for process-id 34102: (os/kern) failure (0x5). > (please check gdb is codesigned - see taskgated(8)) > This is your other real problem. You need to code sign your gdb in order for it to work. Can you try lldb and see how that works for you? Alternately you'll need to sign the gdb you built. -eric (gdb) > > Regards, > > Ricardo > > > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery > wrote: >> >> Hi Ricardo, >> >> Can you provide more information about how it fails? >> >> OS X 10.9 no longer ships with gdb, instead preferring lldb, (the whole >> system has shifted over to LLVM's ecosystem, e.g. clang instead of gcc). >> Have you tried lldb? >> >> Regards, >> Ike >> >> >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o >> wrote: >>> >>> Hi All, >>> >>> Today I've tried to use gdb to debug rust programs. >>> >>> I compiled with -g: rustc -g hello.rs >>> >>> and ran gdb hello >>> >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already >>> faced this issue on Mac? >>> >>> Thanks in advance >>> >>> -- >>> Ricardo Brand?o >>> http://www.programonauta.com.br >>> >>> ........__@ >>> ....._ \ >_ >>> ....(_) / (_) >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> > > > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From rbrandao.br at gmail.com Tue May 20 11:26:18 2014 From: rbrandao.br at gmail.com (=?UTF-8?Q?Ricardo_Brand=C3=A3o?=) Date: Tue, 20 May 2014 15:26:18 -0300 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: Eric, I tried lldb with rust: You can notice that it runs, but I could not set breakpoint, Anyway is not a problem work with Ubuntu on my VirtualBox, but could be nice have another option. :) Thanks $ lldb ./h Current executable set to './h' (x86_64). (lldb) b -l 5 error: No selected frame to use to find the default file. error: No file supplied and no default file available. (lldb) run Process 49619 launched: './h' (x86_64) Hello Ricardo! Process 49619 exited with status = 0 (0x00000000) (lldb) To be sure lldb was working, I tried with a hello world in c, and worked fine: $ lldb a.out Current executable set to 'a.out' (x86_64). (lldb) break 5 invalid command 'breakpoint 5' (lldb) b -l 5 Breakpoint 1: where = a.out`main + 22 at hello.c:5, address = 0x0000000100000f26 (lldb) run Process 49605 launched: '/Users/rbrandao/Google Drive/PrgC/a.out' (x86_64) Process 49605 stopped * thread #1: tid = 0xd01f8, 0x0000000100000f26 a.out`main + 22 at hello.c:5, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100000f26 a.out`main + 22 at hello.c:5 2 3 int main() 4 { -> 5 printf("Hello, world!\n"); 6 return 0; 7 } (lldb) step Hello, world! Process 49605 stopped * thread #1: tid = 0xd01f8, 0x0000000100000f32 a.out`main + 34 at hello.c:6, queue = 'com.apple.main-thread', stop reason = step in frame #0: 0x0000000100000f32 a.out`main + 34 at hello.c:6 3 int main() 4 { 5 printf("Hello, world!\n"); -> 6 return 0; 7 } (lldb) q On Tue, May 20, 2014 at 2:04 PM, Eric Christopher wrote: > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from h... > > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't open > to > > read symbols: No such file or directory. > > > > This seems bad. Does the file exist in that path? > > > warning: can't find symbol 'get_num_cpus' in minsymtab > > > > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab > > > > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab > > > > warning: can't find symbol 'je_chunk_dss_postfork_child' in minsymtab > > > > warning: can't find symbol 'je_chunk_dss_postfork_parent' in minsymtab > > > > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab > > > > warning: can't find symbol 'je_rtree_delete' in minsymtab > > done. > > (gdb) break main > > Breakpoint 1 at 0x1000015a0 > > (gdb) run > > Starting program: /Users/rbrandao/PrgRust/Tutorial/h > > Unable to find Mach task port for process-id 34102: (os/kern) failure > (0x5). > > (please check gdb is codesigned - see taskgated(8)) > > > > This is your other real problem. You need to code sign your gdb in > order for it to work. Can you try lldb and see how that works for you? > Alternately you'll need to sign the gdb you built. > > -eric > > (gdb) > > > > Regards, > > > > Ricardo > > > > > > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery > > wrote: > >> > >> Hi Ricardo, > >> > >> Can you provide more information about how it fails? > >> > >> OS X 10.9 no longer ships with gdb, instead preferring lldb, (the whole > >> system has shifted over to LLVM's ecosystem, e.g. clang instead of gcc). > >> Have you tried lldb? > >> > >> Regards, > >> Ike > >> > >> > >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o > > >> wrote: > >>> > >>> Hi All, > >>> > >>> Today I've tried to use gdb to debug rust programs. > >>> > >>> I compiled with -g: rustc -g hello.rs > >>> > >>> and ran gdb hello > >>> > >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already > >>> faced this issue on Mac? > >>> > >>> Thanks in advance > >>> > >>> -- > >>> Ricardo Brand?o > >>> http://www.programonauta.com.br > >>> > >>> ........__@ > >>> ....._ \ >_ > >>> ....(_) / (_) > >>> > >>> _______________________________________________ > >>> Rust-dev mailing list > >>> Rust-dev at mozilla.org > >>> https://mail.mozilla.org/listinfo/rust-dev > >>> > >> > > > > > > > > -- > > Ricardo Brand?o > > http://www.programonauta.com.br > > > > ........__@ > > ....._ \ >_ > > ....(_) / (_) > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- Ricardo Brand?o http://www.programonauta.com.br ........__@ ....._ \ >_ ....(_) / (_) -------------- next part -------------- An HTML attachment was scrubbed... URL: From echristo at gmail.com Tue May 20 11:32:08 2014 From: echristo at gmail.com (Eric Christopher) Date: Tue, 20 May 2014 11:32:08 -0700 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: On Tue, May 20, 2014 at 11:26 AM, Ricardo Brand?o wrote: > Eric, > > I tried lldb with rust: > > You can notice that it runs, but I could not set breakpoint, > > Anyway is not a problem work with Ubuntu on my VirtualBox, but could be nice > have another option. :) > > Thanks > > $ lldb ./h > Current executable set to './h' (x86_64). > (lldb) b -l 5 > error: No selected frame to use to find the default file. > error: No file supplied and no default file available. > (lldb) run > Process 49619 launched: './h' (x86_64) > Hello Ricardo! > Process 49619 exited with status = 0 (0x00000000) > (lldb) > Interesting. There's something wrong with how it's finding things. I'm not sure how the initialization in lldb is working. Might take some source hacking to get it to work. -eric > To be sure lldb was working, I tried with a hello world in c, and worked > fine: > > $ lldb a.out > Current executable set to 'a.out' (x86_64). > (lldb) break 5 > invalid command 'breakpoint 5' > (lldb) b -l 5 > Breakpoint 1: where = a.out`main + 22 at hello.c:5, address = > 0x0000000100000f26 > (lldb) run > Process 49605 launched: '/Users/rbrandao/Google Drive/PrgC/a.out' (x86_64) > Process 49605 stopped > * thread #1: tid = 0xd01f8, 0x0000000100000f26 a.out`main + 22 at hello.c:5, > queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 > frame #0: 0x0000000100000f26 a.out`main + 22 at hello.c:5 > 2 > 3 int main() > 4 { > -> 5 printf("Hello, world!\n"); > 6 return 0; > 7 } > (lldb) step > Hello, world! > Process 49605 stopped > * thread #1: tid = 0xd01f8, 0x0000000100000f32 a.out`main + 34 at hello.c:6, > queue = 'com.apple.main-thread', stop reason = step in > frame #0: 0x0000000100000f32 a.out`main + 34 at hello.c:6 > 3 int main() > 4 { > 5 printf("Hello, world!\n"); > -> 6 return 0; > 7 } > (lldb) q > > > On Tue, May 20, 2014 at 2:04 PM, Eric Christopher > wrote: >> >> > Type "apropos word" to search for commands related to "word"... >> > Reading symbols from h... >> > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't open >> > to >> > read symbols: No such file or directory. >> > >> >> This seems bad. Does the file exist in that path? >> >> > warning: can't find symbol 'get_num_cpus' in minsymtab >> > >> > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab >> > >> > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab >> > >> > warning: can't find symbol 'je_chunk_dss_postfork_child' in minsymtab >> > >> > warning: can't find symbol 'je_chunk_dss_postfork_parent' in minsymtab >> > >> > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab >> > >> > warning: can't find symbol 'je_rtree_delete' in minsymtab >> > done. >> > (gdb) break main >> > Breakpoint 1 at 0x1000015a0 >> > (gdb) run >> > Starting program: /Users/rbrandao/PrgRust/Tutorial/h >> > Unable to find Mach task port for process-id 34102: (os/kern) failure >> > (0x5). >> > (please check gdb is codesigned - see taskgated(8)) >> > >> >> This is your other real problem. You need to code sign your gdb in >> order for it to work. Can you try lldb and see how that works for you? >> Alternately you'll need to sign the gdb you built. >> >> -eric >> >> (gdb) >> > >> > Regards, >> > >> > Ricardo >> > >> > >> > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery >> > wrote: >> >> >> >> Hi Ricardo, >> >> >> >> Can you provide more information about how it fails? >> >> >> >> OS X 10.9 no longer ships with gdb, instead preferring lldb, (the whole >> >> system has shifted over to LLVM's ecosystem, e.g. clang instead of >> >> gcc). >> >> Have you tried lldb? >> >> >> >> Regards, >> >> Ike >> >> >> >> >> >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o >> >> >> >> wrote: >> >>> >> >>> Hi All, >> >>> >> >>> Today I've tried to use gdb to debug rust programs. >> >>> >> >>> I compiled with -g: rustc -g hello.rs >> >>> >> >>> and ran gdb hello >> >>> >> >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone already >> >>> faced this issue on Mac? >> >>> >> >>> Thanks in advance >> >>> >> >>> -- >> >>> Ricardo Brand?o >> >>> http://www.programonauta.com.br >> >>> >> >>> ........__@ >> >>> ....._ \ >_ >> >>> ....(_) / (_) >> >>> >> >>> _______________________________________________ >> >>> Rust-dev mailing list >> >>> Rust-dev at mozilla.org >> >>> https://mail.mozilla.org/listinfo/rust-dev >> >>> >> >> >> > >> > >> > >> > -- >> > Ricardo Brand?o >> > http://www.programonauta.com.br >> > >> > ........__@ >> > ....._ \ >_ >> > ....(_) / (_) >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > > > > > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) From rbrandao.br at gmail.com Tue May 20 11:42:40 2014 From: rbrandao.br at gmail.com (=?UTF-8?Q?Ricardo_Brand=C3=A3o?=) Date: Tue, 20 May 2014 15:42:40 -0300 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: Yes Eric, Definitely I think Mac OSX is not the better OS to work with. I already faced some issues to build Firefox OS, and now to run debug. And I don't have these kind of problems on Ubuntu. As I am not an expert on gcc, gdb and these stuffs, I think is better continue using Ubuntu, at least I get more experience and get to solve these issues. :) Again, guys, thanks for your patience. Best regards, Ricardo On Tue, May 20, 2014 at 3:32 PM, Eric Christopher wrote: > On Tue, May 20, 2014 at 11:26 AM, Ricardo Brand?o > wrote: > > Eric, > > > > I tried lldb with rust: > > > > You can notice that it runs, but I could not set breakpoint, > > > > Anyway is not a problem work with Ubuntu on my VirtualBox, but could be > nice > > have another option. :) > > > > Thanks > > > > $ lldb ./h > > Current executable set to './h' (x86_64). > > (lldb) b -l 5 > > error: No selected frame to use to find the default file. > > error: No file supplied and no default file available. > > (lldb) run > > Process 49619 launched: './h' (x86_64) > > Hello Ricardo! > > Process 49619 exited with status = 0 (0x00000000) > > (lldb) > > > > Interesting. There's something wrong with how it's finding things. I'm > not sure how the initialization in lldb is working. Might take some > source hacking to get it to work. > > -eric > > > To be sure lldb was working, I tried with a hello world in c, and worked > > fine: > > > > $ lldb a.out > > Current executable set to 'a.out' (x86_64). > > (lldb) break 5 > > invalid command 'breakpoint 5' > > (lldb) b -l 5 > > Breakpoint 1: where = a.out`main + 22 at hello.c:5, address = > > 0x0000000100000f26 > > (lldb) run > > Process 49605 launched: '/Users/rbrandao/Google Drive/PrgC/a.out' > (x86_64) > > Process 49605 stopped > > * thread #1: tid = 0xd01f8, 0x0000000100000f26 a.out`main + 22 at > hello.c:5, > > queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 > > frame #0: 0x0000000100000f26 a.out`main + 22 at hello.c:5 > > 2 > > 3 int main() > > 4 { > > -> 5 printf("Hello, world!\n"); > > 6 return 0; > > 7 } > > (lldb) step > > Hello, world! > > Process 49605 stopped > > * thread #1: tid = 0xd01f8, 0x0000000100000f32 a.out`main + 34 at > hello.c:6, > > queue = 'com.apple.main-thread', stop reason = step in > > frame #0: 0x0000000100000f32 a.out`main + 34 at hello.c:6 > > 3 int main() > > 4 { > > 5 printf("Hello, world!\n"); > > -> 6 return 0; > > 7 } > > (lldb) q > > > > > > On Tue, May 20, 2014 at 2:04 PM, Eric Christopher > > wrote: > >> > >> > Type "apropos word" to search for commands related to "word"... > >> > Reading symbols from h... > >> > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't > open > >> > to > >> > read symbols: No such file or directory. > >> > > >> > >> This seems bad. Does the file exist in that path? > >> > >> > warning: can't find symbol 'get_num_cpus' in minsymtab > >> > > >> > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab > >> > > >> > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab > >> > > >> > warning: can't find symbol 'je_chunk_dss_postfork_child' in minsymtab > >> > > >> > warning: can't find symbol 'je_chunk_dss_postfork_parent' in minsymtab > >> > > >> > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab > >> > > >> > warning: can't find symbol 'je_rtree_delete' in minsymtab > >> > done. > >> > (gdb) break main > >> > Breakpoint 1 at 0x1000015a0 > >> > (gdb) run > >> > Starting program: /Users/rbrandao/PrgRust/Tutorial/h > >> > Unable to find Mach task port for process-id 34102: (os/kern) failure > >> > (0x5). > >> > (please check gdb is codesigned - see taskgated(8)) > >> > > >> > >> This is your other real problem. You need to code sign your gdb in > >> order for it to work. Can you try lldb and see how that works for you? > >> Alternately you'll need to sign the gdb you built. > >> > >> -eric > >> > >> (gdb) > >> > > >> > Regards, > >> > > >> > Ricardo > >> > > >> > > >> > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery > >> > wrote: > >> >> > >> >> Hi Ricardo, > >> >> > >> >> Can you provide more information about how it fails? > >> >> > >> >> OS X 10.9 no longer ships with gdb, instead preferring lldb, (the > whole > >> >> system has shifted over to LLVM's ecosystem, e.g. clang instead of > >> >> gcc). > >> >> Have you tried lldb? > >> >> > >> >> Regards, > >> >> Ike > >> >> > >> >> > >> >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o > >> >> > >> >> wrote: > >> >>> > >> >>> Hi All, > >> >>> > >> >>> Today I've tried to use gdb to debug rust programs. > >> >>> > >> >>> I compiled with -g: rustc -g hello.rs > >> >>> > >> >>> and ran gdb hello > >> >>> > >> >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone > already > >> >>> faced this issue on Mac? > >> >>> > >> >>> Thanks in advance > >> >>> > >> >>> -- > >> >>> Ricardo Brand?o > >> >>> http://www.programonauta.com.br > >> >>> > >> >>> ........__@ > >> >>> ....._ \ >_ > >> >>> ....(_) / (_) > >> >>> > >> >>> _______________________________________________ > >> >>> Rust-dev mailing list > >> >>> Rust-dev at mozilla.org > >> >>> https://mail.mozilla.org/listinfo/rust-dev > >> >>> > >> >> > >> > > >> > > >> > > >> > -- > >> > Ricardo Brand?o > >> > http://www.programonauta.com.br > >> > > >> > ........__@ > >> > ....._ \ >_ > >> > ....(_) / (_) > >> > > >> > _______________________________________________ > >> > Rust-dev mailing list > >> > Rust-dev at mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > >> > > > > > > > > > > > -- > > Ricardo Brand?o > > http://www.programonauta.com.br > > > > ........__@ > > ....._ \ >_ > > ....(_) / (_) > -- Ricardo Brand?o http://www.programonauta.com.br ........__@ ....._ \ >_ ....(_) / (_) -------------- next part -------------- An HTML attachment was scrubbed... URL: From masanori.ogino at gmail.com Tue May 20 15:45:38 2014 From: masanori.ogino at gmail.com (Masanori Ogino) Date: Wed, 21 May 2014 07:45:38 +0900 Subject: [rust-dev] owned pointer vs. owning pointer vs. owned box Message-ID: Hello. I found that the Reference Manual uses the term "owning pointer", the Pointer Guide and liballoc do "owned pointer" and Tutorial does "owned box". Which term is canonical today? -- Masanori Ogino http://twitter.com/omasanori http://gplus.to/omasanori -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue May 20 15:59:23 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 20 May 2014 18:59:23 -0400 Subject: [rust-dev] owned pointer vs. owning pointer vs. owned box In-Reply-To: References: Message-ID: <537BDE4B.80602@gmail.com> On 20/05/14 06:45 PM, Masanori Ogino wrote: > Hello. > > I found that the Reference Manual uses the term "owning pointer", the > Pointer Guide and liballoc do "owned pointer" and Tutorial does "owned box". > > Which term is canonical today? > > -- > Masanori Ogino > > http://twitter.com/omasanori > http://gplus.to/omasanori Either owned box (a dynamic allocation owned by a pointer) or owning pointer (a pointer owning a dynamic allocation) is accurate. On the other hand, the term 'owned pointer' doesn't make sense as even references and `Rc` are an owned *pointer*, but the ownership relationship doesn't pass through them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From corey at octayn.net Tue May 20 16:19:33 2014 From: corey at octayn.net (Corey Richardson) Date: Tue, 20 May 2014 16:19:33 -0700 Subject: [rust-dev] owned pointer vs. owning pointer vs. owned box In-Reply-To: <537BDE4B.80602@gmail.com> References: <537BDE4B.80602@gmail.com> Message-ID: See https://github.com/mozilla/rust/wiki/The-Rusticon for an up-to-date glossary and syntax reference. On Tue, May 20, 2014 at 3:59 PM, Daniel Micay wrote: > On 20/05/14 06:45 PM, Masanori Ogino wrote: >> Hello. >> >> I found that the Reference Manual uses the term "owning pointer", the >> Pointer Guide and liballoc do "owned pointer" and Tutorial does "owned box". >> >> Which term is canonical today? >> >> -- >> Masanori Ogino > >> http://twitter.com/omasanori >> http://gplus.to/omasanori > > Either owned box (a dynamic allocation owned by a pointer) or owning > pointer (a pointer owning a dynamic allocation) is accurate. On the > other hand, the term 'owned pointer' doesn't make sense as even > references and `Rc` are an owned *pointer*, but the ownership > relationship doesn't pass through them. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From com.liigo at gmail.com Tue May 20 16:41:32 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 21 May 2014 07:41:32 +0800 Subject: [rust-dev] owned pointer vs. owning pointer vs. owned box In-Reply-To: <537BDE4B.80602@gmail.com> References: <537BDE4B.80602@gmail.com> Message-ID: Could you show us the memory layout of Box? Thank you! 2014?5?21? ??6:59? "Daniel Micay" ??? > On 20/05/14 06:45 PM, Masanori Ogino wrote: > > Hello. > > > > I found that the Reference Manual uses the term "owning pointer", the > > Pointer Guide and liballoc do "owned pointer" and Tutorial does "owned > box". > > > > Which term is canonical today? > > > > -- > > Masanori Ogino masanori.ogino at gmail.com>> > > http://twitter.com/omasanori > > http://gplus.to/omasanori > > Either owned box (a dynamic allocation owned by a pointer) or owning > pointer (a pointer owning a dynamic allocation) is accurate. On the > other hand, the term 'owned pointer' doesn't make sense as even > references and `Rc` are an owned *pointer*, but the ownership > relationship doesn't pass through them. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue May 20 16:43:50 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 20 May 2014 19:43:50 -0400 Subject: [rust-dev] owned pointer vs. owning pointer vs. owned box In-Reply-To: References: <537BDE4B.80602@gmail.com> Message-ID: <537BE8B6.2090707@gmail.com> On 20/05/14 07:41 PM, Liigo Zhuang wrote: > Could you show us the memory layout of Box? Thank you! The memory layout is just a pointer to a dynamic allocation with the size of the value. Providing the dynamic allocation is up to the default allocator, which is jemalloc right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From masanori.ogino at gmail.com Tue May 20 17:16:43 2014 From: masanori.ogino at gmail.com (Masanori Ogino) Date: Wed, 21 May 2014 09:16:43 +0900 Subject: [rust-dev] owned pointer vs. owning pointer vs. owned box In-Reply-To: <537BE8B6.2090707@gmail.com> References: <537BDE4B.80602@gmail.com> <537BE8B6.2090707@gmail.com> Message-ID: Thank you very much. So, does the Pointer Guide need to be updated? -- Masanori Ogino http://twitter.com/omasanori http://gplus.to/omasanori -------------- next part -------------- An HTML attachment was scrubbed... URL: From zo1980 at gmail.com Wed May 21 06:19:27 2014 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Wed, 21 May 2014 15:19:27 +0200 Subject: [rust-dev] dynamic memory allocations Message-ID: Daniel Micay wrote: > ... the default > allocator, which is jemalloc right now. > > Rust's memory management is still under-documented in the manual. I have a question which have been bothering me for a while. I may have misunderstood something basic. Jemalloc AFAIK synchronizes the allocations, as it is multithread-ready. However does Rust not use task-specific heaps? [I thought that most of the dynamic allocations happen in task-specific heaps.] For those is Jemalloc's synchronization not an unnecessary waste of processor time? -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Wed May 21 07:35:41 2014 From: corey at octayn.net (Corey Richardson) Date: Wed, 21 May 2014 07:35:41 -0700 Subject: [rust-dev] dynamic memory allocations In-Reply-To: References: Message-ID: No, there are no task-specific heaps. An old concept from the manual is the "exchange heap", which is where ~ boxes lived (ie, the normal heap) and that @-boxes were some magic task-local heap. But you can always send Box between tasks. There's been mention of wanting a task-local box in IRC. However, jemalloc uses per-thread caches, and does not always need to synchronize allocation. On Wed, May 21, 2014 at 6:19 AM, Zolt?n T?th wrote: > Daniel Micay wrote: >> >> ... the default >> allocator, which is jemalloc right now. >> > > Rust's memory management is still under-documented in the manual. I have a > question which have been bothering me for a while. I may have misunderstood > something basic. > > Jemalloc AFAIK synchronizes the allocations, as it is multithread-ready. > However does Rust not use task-specific heaps? [I thought that most of the > dynamic allocations happen in task-specific heaps.] For those is Jemalloc's > synchronization not an unnecessary waste of processor time? > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From ihmccreery at gmail.com Wed May 21 08:40:09 2014 From: ihmccreery at gmail.com (Isaac Hollander McCreery) Date: Wed, 21 May 2014 11:40:09 -0400 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: Hi Ricardo, lldb has a different syntax than gdb. Instead of b -l 5 use breakpoint set -f h -l 5 That's why you're getting those errors. More information here: http://lldb.llvm.org/tutorial.html Hope that helps, Ike On Tue, May 20, 2014 at 2:42 PM, Ricardo Brand?o wrote: > Yes Eric, > > Definitely I think Mac OSX is not the better OS to work with. > > I already faced some issues to build Firefox OS, and now to run debug. > > And I don't have these kind of problems on Ubuntu. As I am not an expert > on gcc, gdb and these stuffs, I think is better continue using Ubuntu, at > least I get more experience and get to solve these issues. :) > > Again, guys, thanks for your patience. > > Best regards, > > Ricardo > > > On Tue, May 20, 2014 at 3:32 PM, Eric Christopher wrote: > >> On Tue, May 20, 2014 at 11:26 AM, Ricardo Brand?o >> wrote: >> > Eric, >> > >> > I tried lldb with rust: >> > >> > You can notice that it runs, but I could not set breakpoint, >> > >> > Anyway is not a problem work with Ubuntu on my VirtualBox, but could be >> nice >> > have another option. :) >> > >> > Thanks >> > >> > $ lldb ./h >> > Current executable set to './h' (x86_64). >> > (lldb) b -l 5 >> > error: No selected frame to use to find the default file. >> > error: No file supplied and no default file available. >> > (lldb) run >> > Process 49619 launched: './h' (x86_64) >> > Hello Ricardo! >> > Process 49619 exited with status = 0 (0x00000000) >> > (lldb) >> > >> >> Interesting. There's something wrong with how it's finding things. I'm >> not sure how the initialization in lldb is working. Might take some >> source hacking to get it to work. >> >> -eric >> >> > To be sure lldb was working, I tried with a hello world in c, and worked >> > fine: >> > >> > $ lldb a.out >> > Current executable set to 'a.out' (x86_64). >> > (lldb) break 5 >> > invalid command 'breakpoint 5' >> > (lldb) b -l 5 >> > Breakpoint 1: where = a.out`main + 22 at hello.c:5, address = >> > 0x0000000100000f26 >> > (lldb) run >> > Process 49605 launched: '/Users/rbrandao/Google Drive/PrgC/a.out' >> (x86_64) >> > Process 49605 stopped >> > * thread #1: tid = 0xd01f8, 0x0000000100000f26 a.out`main + 22 at >> hello.c:5, >> > queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 >> > frame #0: 0x0000000100000f26 a.out`main + 22 at hello.c:5 >> > 2 >> > 3 int main() >> > 4 { >> > -> 5 printf("Hello, world!\n"); >> > 6 return 0; >> > 7 } >> > (lldb) step >> > Hello, world! >> > Process 49605 stopped >> > * thread #1: tid = 0xd01f8, 0x0000000100000f32 a.out`main + 34 at >> hello.c:6, >> > queue = 'com.apple.main-thread', stop reason = step in >> > frame #0: 0x0000000100000f32 a.out`main + 34 at hello.c:6 >> > 3 int main() >> > 4 { >> > 5 printf("Hello, world!\n"); >> > -> 6 return 0; >> > 7 } >> > (lldb) q >> > >> > >> > On Tue, May 20, 2014 at 2:04 PM, Eric Christopher >> > wrote: >> >> >> >> > Type "apropos word" to search for commands related to "word"... >> >> > Reading symbols from h... >> >> > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't >> open >> >> > to >> >> > read symbols: No such file or directory. >> >> > >> >> >> >> This seems bad. Does the file exist in that path? >> >> >> >> > warning: can't find symbol 'get_num_cpus' in minsymtab >> >> > >> >> > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab >> >> > >> >> > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab >> >> > >> >> > warning: can't find symbol 'je_chunk_dss_postfork_child' in minsymtab >> >> > >> >> > warning: can't find symbol 'je_chunk_dss_postfork_parent' in >> minsymtab >> >> > >> >> > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab >> >> > >> >> > warning: can't find symbol 'je_rtree_delete' in minsymtab >> >> > done. >> >> > (gdb) break main >> >> > Breakpoint 1 at 0x1000015a0 >> >> > (gdb) run >> >> > Starting program: /Users/rbrandao/PrgRust/Tutorial/h >> >> > Unable to find Mach task port for process-id 34102: (os/kern) failure >> >> > (0x5). >> >> > (please check gdb is codesigned - see taskgated(8)) >> >> > >> >> >> >> This is your other real problem. You need to code sign your gdb in >> >> order for it to work. Can you try lldb and see how that works for you? >> >> Alternately you'll need to sign the gdb you built. >> >> >> >> -eric >> >> >> >> (gdb) >> >> > >> >> > Regards, >> >> > >> >> > Ricardo >> >> > >> >> > >> >> > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery >> >> > wrote: >> >> >> >> >> >> Hi Ricardo, >> >> >> >> >> >> Can you provide more information about how it fails? >> >> >> >> >> >> OS X 10.9 no longer ships with gdb, instead preferring lldb, (the >> whole >> >> >> system has shifted over to LLVM's ecosystem, e.g. clang instead of >> >> >> gcc). >> >> >> Have you tried lldb? >> >> >> >> >> >> Regards, >> >> >> Ike >> >> >> >> >> >> >> >> >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> Hi All, >> >> >>> >> >> >>> Today I've tried to use gdb to debug rust programs. >> >> >>> >> >> >>> I compiled with -g: rustc -g hello.rs >> >> >>> >> >> >>> and ran gdb hello >> >> >>> >> >> >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone >> already >> >> >>> faced this issue on Mac? >> >> >>> >> >> >>> Thanks in advance >> >> >>> >> >> >>> -- >> >> >>> Ricardo Brand?o >> >> >>> http://www.programonauta.com.br >> >> >>> >> >> >>> ........__@ >> >> >>> ....._ \ >_ >> >> >>> ....(_) / (_) >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rust-dev mailing list >> >> >>> Rust-dev at mozilla.org >> >> >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >>> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Ricardo Brand?o >> >> > http://www.programonauta.com.br >> >> > >> >> > ........__@ >> >> > ....._ \ >_ >> >> > ....(_) / (_) >> >> > >> >> > _______________________________________________ >> >> > Rust-dev mailing list >> >> > Rust-dev at mozilla.org >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > >> > >> > >> > >> > >> > -- >> > Ricardo Brand?o >> > http://www.programonauta.com.br >> > >> > ........__@ >> > ....._ \ >_ >> > ....(_) / (_) >> > > > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrandao.br at gmail.com Wed May 21 08:59:44 2014 From: rbrandao.br at gmail.com (=?UTF-8?Q?Ricardo_Brand=C3=A3o?=) Date: Wed, 21 May 2014 12:59:44 -0300 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: Michael and Isaac, Thanks for your replies, Probably there is another kind of problem on lldb installation on my OSX. Now, I'm getting a segmentation fault: $ lldb -f ./h Current executable set to './h' (x86_64). (lldb) breakpoint set -f h -l 5 Segmentation fault: 11 Anyway, using Ubuntu on VirtualBox is working fine. I'm using gdb inside emacs and when split the screen I can show all breakpoints and current line on source code. And as I already using Ubuntu on VB to build my Peak, I'll choose Ubuntu as my dev platform. Regards, Ricardo On Wed, May 21, 2014 at 12:40 PM, Isaac Hollander McCreery < ihmccreery at gmail.com> wrote: > Hi Ricardo, > > lldb has a different syntax than gdb. Instead of > > b -l 5 > > use > > breakpoint set -f h -l 5 > > That's why you're getting those errors. More information here: > > http://lldb.llvm.org/tutorial.html > > Hope that helps, > Ike > > > On Tue, May 20, 2014 at 2:42 PM, Ricardo Brand?o wrote: > >> Yes Eric, >> >> Definitely I think Mac OSX is not the better OS to work with. >> >> I already faced some issues to build Firefox OS, and now to run debug. >> >> And I don't have these kind of problems on Ubuntu. As I am not an expert >> on gcc, gdb and these stuffs, I think is better continue using Ubuntu, at >> least I get more experience and get to solve these issues. :) >> >> Again, guys, thanks for your patience. >> >> Best regards, >> >> Ricardo >> >> >> On Tue, May 20, 2014 at 3:32 PM, Eric Christopher wrote: >> >>> On Tue, May 20, 2014 at 11:26 AM, Ricardo Brand?o >>> wrote: >>> > Eric, >>> > >>> > I tried lldb with rust: >>> > >>> > You can notice that it runs, but I could not set breakpoint, >>> > >>> > Anyway is not a problem work with Ubuntu on my VirtualBox, but could >>> be nice >>> > have another option. :) >>> > >>> > Thanks >>> > >>> > $ lldb ./h >>> > Current executable set to './h' (x86_64). >>> > (lldb) b -l 5 >>> > error: No selected frame to use to find the default file. >>> > error: No file supplied and no default file available. >>> > (lldb) run >>> > Process 49619 launched: './h' (x86_64) >>> > Hello Ricardo! >>> > Process 49619 exited with status = 0 (0x00000000) >>> > (lldb) >>> > >>> >>> Interesting. There's something wrong with how it's finding things. I'm >>> not sure how the initialization in lldb is working. Might take some >>> source hacking to get it to work. >>> >>> -eric >>> >>> > To be sure lldb was working, I tried with a hello world in c, and >>> worked >>> > fine: >>> > >>> > $ lldb a.out >>> > Current executable set to 'a.out' (x86_64). >>> > (lldb) break 5 >>> > invalid command 'breakpoint 5' >>> > (lldb) b -l 5 >>> > Breakpoint 1: where = a.out`main + 22 at hello.c:5, address = >>> > 0x0000000100000f26 >>> > (lldb) run >>> > Process 49605 launched: '/Users/rbrandao/Google Drive/PrgC/a.out' >>> (x86_64) >>> > Process 49605 stopped >>> > * thread #1: tid = 0xd01f8, 0x0000000100000f26 a.out`main + 22 at >>> hello.c:5, >>> > queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 >>> > frame #0: 0x0000000100000f26 a.out`main + 22 at hello.c:5 >>> > 2 >>> > 3 int main() >>> > 4 { >>> > -> 5 printf("Hello, world!\n"); >>> > 6 return 0; >>> > 7 } >>> > (lldb) step >>> > Hello, world! >>> > Process 49605 stopped >>> > * thread #1: tid = 0xd01f8, 0x0000000100000f32 a.out`main + 34 at >>> hello.c:6, >>> > queue = 'com.apple.main-thread', stop reason = step in >>> > frame #0: 0x0000000100000f32 a.out`main + 34 at hello.c:6 >>> > 3 int main() >>> > 4 { >>> > 5 printf("Hello, world!\n"); >>> > -> 6 return 0; >>> > 7 } >>> > (lldb) q >>> > >>> > >>> > On Tue, May 20, 2014 at 2:04 PM, Eric Christopher >>> > wrote: >>> >> >>> >> > Type "apropos word" to search for commands related to "word"... >>> >> > Reading symbols from h... >>> >> > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': can't >>> open >>> >> > to >>> >> > read symbols: No such file or directory. >>> >> > >>> >> >>> >> This seems bad. Does the file exist in that path? >>> >> >>> >> > warning: can't find symbol 'get_num_cpus' in minsymtab >>> >> > >>> >> > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab >>> >> > >>> >> > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab >>> >> > >>> >> > warning: can't find symbol 'je_chunk_dss_postfork_child' in >>> minsymtab >>> >> > >>> >> > warning: can't find symbol 'je_chunk_dss_postfork_parent' in >>> minsymtab >>> >> > >>> >> > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab >>> >> > >>> >> > warning: can't find symbol 'je_rtree_delete' in minsymtab >>> >> > done. >>> >> > (gdb) break main >>> >> > Breakpoint 1 at 0x1000015a0 >>> >> > (gdb) run >>> >> > Starting program: /Users/rbrandao/PrgRust/Tutorial/h >>> >> > Unable to find Mach task port for process-id 34102: (os/kern) >>> failure >>> >> > (0x5). >>> >> > (please check gdb is codesigned - see taskgated(8)) >>> >> > >>> >> >>> >> This is your other real problem. You need to code sign your gdb in >>> >> order for it to work. Can you try lldb and see how that works for you? >>> >> Alternately you'll need to sign the gdb you built. >>> >> >>> >> -eric >>> >> >>> >> (gdb) >>> >> > >>> >> > Regards, >>> >> > >>> >> > Ricardo >>> >> > >>> >> > >>> >> > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery >>> >> > wrote: >>> >> >> >>> >> >> Hi Ricardo, >>> >> >> >>> >> >> Can you provide more information about how it fails? >>> >> >> >>> >> >> OS X 10.9 no longer ships with gdb, instead preferring lldb, (the >>> whole >>> >> >> system has shifted over to LLVM's ecosystem, e.g. clang instead of >>> >> >> gcc). >>> >> >> Have you tried lldb? >>> >> >> >>> >> >> Regards, >>> >> >> Ike >>> >> >> >>> >> >> >>> >> >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o >>> >> >> >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi All, >>> >> >>> >>> >> >>> Today I've tried to use gdb to debug rust programs. >>> >> >>> >>> >> >>> I compiled with -g: rustc -g hello.rs >>> >> >>> >>> >> >>> and ran gdb hello >>> >> >>> >>> >> >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone >>> already >>> >> >>> faced this issue on Mac? >>> >> >>> >>> >> >>> Thanks in advance >>> >> >>> >>> >> >>> -- >>> >> >>> Ricardo Brand?o >>> >> >>> http://www.programonauta.com.br >>> >> >>> >>> >> >>> ........__@ >>> >> >>> ....._ \ >_ >>> >> >>> ....(_) / (_) >>> >> >>> >>> >> >>> _______________________________________________ >>> >> >>> Rust-dev mailing list >>> >> >>> Rust-dev at mozilla.org >>> >> >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >>> >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Ricardo Brand?o >>> >> > http://www.programonauta.com.br >>> >> > >>> >> > ........__@ >>> >> > ....._ \ >_ >>> >> > ....(_) / (_) >>> >> > >>> >> > _______________________________________________ >>> >> > Rust-dev mailing list >>> >> > Rust-dev at mozilla.org >>> >> > https://mail.mozilla.org/listinfo/rust-dev >>> >> > >>> > >>> > >>> > >>> > >>> > -- >>> > Ricardo Brand?o >>> > http://www.programonauta.com.br >>> > >>> > ........__@ >>> > ....._ \ >_ >>> > ....(_) / (_) >>> >> >> >> >> -- >> Ricardo Brand?o >> http://www.programonauta.com.br >> >> ........__@ >> ....._ \ >_ >> ....(_) / (_) >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- Ricardo Brand?o http://www.programonauta.com.br ........__@ ....._ \ >_ ....(_) / (_) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at posteo.net Wed May 21 07:29:14 2014 From: michaelwoerister at posteo.net (Michael Woerister) Date: Wed, 21 May 2014 16:29:14 +0200 Subject: [rust-dev] Using gdb on rust In-Reply-To: References: Message-ID: <537CB83A.7030001@posteo.net> Hi Ricardo, lldb should work OK with Rust executables. The error you mention should be solved by also specifying the file containing the line you want to break in. So instead of writing just `b -l 5`, try `b -l 5 -f main.rs` instead (specifying the correct source filename, of course). The command `b main.rs:5` (i.e. like you would type it in GDB) should also work. Cheers, Michael On 20/05/14 20:26, Ricardo Brand?o wrote: > Eric, > > I tried lldb with rust: > > You can notice that it runs, but I could not set breakpoint, > > Anyway is not a problem work with Ubuntu on my VirtualBox, but could > be nice have another option. :) > > Thanks > > $ lldb ./h > Current executable set to './h' (x86_64). > (lldb) b -l 5 > error: No selected frame to use to find the default file. > error: No file supplied and no default file available. > (lldb) run > Process 49619 launched: './h' (x86_64) > Hello Ricardo! > Process 49619 exited with status = 0 (0x00000000) > (lldb) > > To be sure lldb was working, I tried with a hello world in c, and > worked fine: > > $ lldb a.out > Current executable set to 'a.out' (x86_64). > (lldb) break 5 > invalid command 'breakpoint 5' > (lldb) b -l 5 > Breakpoint 1: where = a.out`main + 22 at hello.c:5, address = > 0x0000000100000f26 > (lldb) run > Process 49605 launched: '/Users/rbrandao/Google Drive/PrgC/a.out' (x86_64) > Process 49605 stopped > * thread #1: tid = 0xd01f8, 0x0000000100000f26 a.out`main + 22 at > hello.c:5, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 > frame #0: 0x0000000100000f26 a.out`main + 22 at hello.c:5 > 2 > 3 int main() > 4 { > -> 5 printf("Hello, world!\n"); > 6 return 0; > 7 } > (lldb) step > Hello, world! > Process 49605 stopped > * thread #1: tid = 0xd01f8, 0x0000000100000f32 a.out`main + 34 at > hello.c:6, queue = 'com.apple.main-thread', stop reason = step in > frame #0: 0x0000000100000f32 a.out`main + 34 at hello.c:6 > 3 int main() > 4 { > 5 printf("Hello, world!\n"); > -> 6 return 0; > 7 } > (lldb) q > > > On Tue, May 20, 2014 at 2:04 PM, Eric Christopher > wrote: > > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from h... > > warning: `/Users/rbrandao/Google Drive/PrgRust/Tutorial/h.o': > can't open to > > read symbols: No such file or directory. > > > > This seems bad. Does the file exist in that path? > > > warning: can't find symbol 'get_num_cpus' in minsymtab > > > > warning: can't find symbol 'je_chunk_alloc_dss' in minsymtab > > > > warning: can't find symbol 'je_chunk_dss_boot' in minsymtab > > > > warning: can't find symbol 'je_chunk_dss_postfork_child' in > minsymtab > > > > warning: can't find symbol 'je_chunk_dss_postfork_parent' in > minsymtab > > > > warning: can't find symbol 'je_extent_tree_ad_first' in minsymtab > > > > warning: can't find symbol 'je_rtree_delete' in minsymtab > > done. > > (gdb) break main > > Breakpoint 1 at 0x1000015a0 > > (gdb) run > > Starting program: /Users/rbrandao/PrgRust/Tutorial/h > > Unable to find Mach task port for process-id 34102: (os/kern) > failure (0x5). > > (please check gdb is codesigned - see taskgated(8)) > > > > This is your other real problem. You need to code sign your gdb in > order for it to work. Can you try lldb and see how that works for you? > Alternately you'll need to sign the gdb you built. > > -eric > > (gdb) > > > > Regards, > > > > Ricardo > > > > > > On Mon, May 19, 2014 at 6:54 PM, Isaac Hollander McCreery > > > wrote: > >> > >> Hi Ricardo, > >> > >> Can you provide more information about how it fails? > >> > >> OS X 10.9 no longer ships with gdb, instead preferring lldb, > (the whole > >> system has shifted over to LLVM's ecosystem, e.g. clang instead > of gcc). > >> Have you tried lldb? > >> > >> Regards, > >> Ike > >> > >> > >> On Mon, May 19, 2014 at 5:43 PM, Ricardo Brand?o > > > >> wrote: > >>> > >>> Hi All, > >>> > >>> Today I've tried to use gdb to debug rust programs. > >>> > >>> I compiled with -g: rustc -g hello.rs > >>> > >>> and ran gdb hello > >>> > >>> On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone > already > >>> faced this issue on Mac? > >>> > >>> Thanks in advance > >>> > >>> -- > >>> Ricardo Brand?o > >>> http://www.programonauta.com.br > >>> > >>> ........__@ > >>> ....._ \ >_ > >>> ....(_) / (_) > >>> > >>> _______________________________________________ > >>> Rust-dev mailing list > >>> Rust-dev at mozilla.org > >>> https://mail.mozilla.org/listinfo/rust-dev > >>> > >> > > > > > > > > -- > > Ricardo Brand?o > > http://www.programonauta.com.br > > > > ........__@ > > ....._ \ >_ > > ....(_) / (_) > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > > -- > Ricardo Brand?o > http://www.programonauta.com.br > > ........__@ > ....._ \ >_ > ....(_) / (_) > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed May 21 12:47:56 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 21 May 2014 15:47:56 -0400 Subject: [rust-dev] dynamic memory allocations In-Reply-To: References: Message-ID: <537D02EC.90303@gmail.com> On 21/05/14 09:19 AM, Zolt?n T?th wrote: > Daniel Micay > wrote: > > ... the default > allocator, which is jemalloc right now. > > > Rust's memory management is still under-documented in the manual. I have > a question which have been bothering me for a while. I may have > misunderstood something basic. > > Jemalloc AFAIK synchronizes the allocations, as it is multithread-ready. > However does Rust not use task-specific heaps? [I thought that most of > the dynamic allocations happen in task-specific heaps.] For those is > Jemalloc's synchronization not an unnecessary waste of processor time? Types like `Vec` and `Box` can be sent between tasks and `Arc` can be shared so there's no task-local heap. It's true that a few types like `Rc` are task-local but there would be no performance gain from an extra layer. It would just create needless memory fragmentation. jemalloc creates 4 arenas for every core (each with a lock) and assigns threads to these arenas. It then has thread local caches on top of those. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From erick.tryzelaar at gmail.com Wed May 21 13:25:58 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 21 May 2014 13:25:58 -0700 Subject: [rust-dev] 3 SF events in June: a Dinner, Game Tech Meetup, and a Spinning Trianglthon Message-ID: Hello Rustangles! I'm pleased to announce *three* SF Bay Area events in June! First up is a dinner at the Tied House in Mountain View on June 10th. Second is a gaming themed meetup on Thursday in San Francisco, June 26th. Third, we'll be having a Spinning Trianglthon hackathon to play around with the tech talked about in the meetup on Saturday June 28th, also in San Francisco. The meetup will be going through all the gaming tech and prototypes the community has been developing. Here's the lineup: ? Brendan Zabarauskas: The Library Ecosystem for Rust Game Development: gl-rs , glfw-rs, cgmath-rs , and possibly rust-graphicsand piston . ? Corey Richardson: Introduction to OpenGL and Rust. ? Chip Collier: how we're structuring Voyager and hoping to use the most of Rust to accomplish our goals. ? Colin Sherratt (Remote): Reducing VR latency with Rust: vr-rsand the Oculus Rift. Matthew McPherrin has graciously offered to bring in his Oculus Rift to demo vr-rs in person. If you want to come to any of the events, follow these links to sign up: 6/10 Dinner: http://www.meetup.com/Rust-Bay-Area/events/181812652/ 6/26 Meetup: http://www.meetup.com/Rust-Bay-Area/events/171111672/ 6/28 Hackathon: http://www.meetup.com/Rust-Bay-Area/events/183377112/ Mozilla will be graciously providing food and drink for the meetup and hackathon, but we'll be splitting the 6/10 dinner bill, so please remember to bring some cash. I hope you can all make it! Thanks, Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.boggiano at seld.be Thu May 22 01:52:41 2014 From: j.boggiano at seld.be (Jordi Boggiano) Date: Thu, 22 May 2014 10:52:41 +0200 Subject: [rust-dev] 3 SF events in June: a Dinner, Game Tech Meetup, and a Spinning Trianglthon In-Reply-To: References: Message-ID: <537DBAD9.7090309@seld.be> Here is a link to watch all past (and upcoming) rust meetups for those that can't be there in person. It took me 5min to dig it up again so I thought I'd share. https://air.mozilla.org/search/?q=rust+meetup Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From michaelwoerister at posteo.net Thu May 22 07:32:28 2014 From: michaelwoerister at posteo.net (Michael Woerister) Date: Thu, 22 May 2014 16:32:28 +0200 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <537A52D8.8010001@mozilla.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <537A52D8.8010001@mozilla.com> Message-ID: <537E0A7C.6010807@posteo.net> On 19/05/14 20:52, Brian Anderson wrote: > On 05/15/2014 09:30 PM, Tommi wrote: >> On 2014-05-16, at 7:14, Daniel Micay wrote: >> >>> On 16/05/14 12:10 AM, Tommi wrote: >>>> I was just wondering, why do we have to explicitly specify the >>>> lifetimes of references returned from functions? Couldn't the >>>> compiler figure those lifetimes out by itself by analyzing the code >>>> in the function? >>> >>> Type inference is local to functions, so it couldn't do that. It would >>> be impossible to have libraries if inference needed to be global across >>> the entire program, and the errors would be *signicantly* harder to >>> understand as they would span across countless functions. >> >> I'm sorry, but for some reason I completely fail to understand your >> explanation. >> >> My thinking of how the compiler would work is that whenever it >> compiles a function, it would analyze it and in some sense "write in" >> the named lifetimes for that function. The named lifetimes would >> still be explicitly part of the signature of the function in the >> compiler's internal representation of the function, but not be >> visible in the source code. >> > > I believe the compiler does this anylisis when the lifetimes in a > signature are wrong - but just for the error message. It tries to > suggest lifetimes that will work, but the analysis is not foolproof > and can't be done automatically generally (idk why, ask niko). Lately I've been thinking that it might be nice if one could omit the lifetimes from the list of generic parameters, as in: fn foo(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) instead of fn foo<'a, 'b, T>(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) Especially for otherwise non-generic functions, having to explicitly list lifetimes seems a bit redundant, as they are unambiguously defined in the function signature anyway (as opposed to type parameters, which don't have the special `'` marker). Maybe this is worth writing up an RFC for... -Michael From pnkfelix at mozilla.com Thu May 22 08:54:46 2014 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Thu, 22 May 2014 17:54:46 +0200 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <537E0A7C.6010807@posteo.net> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <537A52D8.8010001@mozilla.com> <537E0A7C.6010807@posteo.net> Message-ID: <37432076-B241-4957-B9CD-F667429ABAD8@mozilla.com> Michael (cc'ing rust-dev)- On 22 May 2014, at 16:32, Michael Woerister wrote: > Lately I've been thinking that it might be nice if one could omit the lifetimes from the list of generic parameters, as in: > > fn foo(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) > > instead of > > fn foo<'a, 'b, T>(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) > > Especially for otherwise non-generic functions, having to explicitly list lifetimes seems a bit redundant, as they are unambiguously defined in the function signature anyway (as opposed to type parameters, which don't have the special `'` marker). Note that this is not true in the general case. Consider e.g. methods with an type impl or a trait impl: in that scenario, one could bind lifetimes on the method itself, or in the type/trait being implemented. This distinction matters (in terms of what limits it imposes on the clients of those types/traits). (I provide a concrete example after my signature.) There are other changes one could make to still accommodate a change like you suggest in the general case, such as inferring some binding site (e.g. the nearest one) if a lifetime is otherwise found to be unbound. But I personally do not think such changes improve the character of the language (IMHO); I'd rather have a straight-forward rule that one applies in every context. Cheers, -Felix Concrete Example: The variants below are quite different. #[deriving(Show)] struct S<'a> { p: &'a int } impl<'a> S<'a> { #[cfg(variant1)] fn foo(&mut self, arg: &'a int) -> &'a int { let old = self.p; self.p = arg; old } #[cfg(variant2)] fn foo<'a>(&mut self, arg: &'a int) -> &'a int { let old = self.p; self.p = arg; old } #[cfg(variant3)] fn foo<'a>(&mut self, arg: &'a int) -> &'a int { arg } #[cfg(variant4)] fn foo<'a>(&mut self, arg: &'a int) -> &'a int { self.p } #[cfg(variant5)] fn foo<'a>(&self, arg: &'a int) -> &'a int { self.p } #[cfg(variant6)] fn foo<'a>(&'a self, arg: &'a int) -> &'a int { let _ = arg; self.p } } #[allow(unused_mut)] fn main() { let x = 3; let mut s = S{ p: &x }; let y = 4; println!("begin: {:?}", s); let z = s.foo(&y); println!("later: {:?} z: {:?}", s, z); } Half of them do not compile (for differing reasons). Variants 1, 3, and 6 do run (and each produces a different output), but the interesting points come from understanding why the other cases do not compile. (FYI: It is probably easier to talk about the example if you first alpha-rename the method-bound lifetimes to something other than `'a`.) From klesnil at centrum.cz Thu May 22 12:03:40 2014 From: klesnil at centrum.cz (Jan Klesnil) Date: Thu, 22 May 2014 21:03:40 +0200 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <537E0A7C.6010807@posteo.net> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <537A52D8.8010001@mozilla.com> <537E0A7C.6010807@posteo.net> Message-ID: <537E4A0C.1040300@centrum.cz> Hi, On 05/22/2014 04:32 PM, Michael Woerister wrote: > Lately I've been thinking that it might be nice if one could omit the > lifetimes from the list of generic parameters, as in: > > fn foo(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) > > instead of > > fn foo<'a, 'b, T>(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) > I have got this idea when I was reading http://smallcultfollowing.com/babysteps/blog/2013/11/04/intermingled-parameter-lists/ . It should be possible to omit lifetime parameters if there are late-bound as specified in the mentioned article. The early-bound ones can't be omitted. Still, it would be nice. I have this feeling, that parameters not used for monomorphization could and should be omitted. And late-bound lifetime parameters are not used. Jan > > -Michael > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From michaelwoerister at posteo.net Thu May 22 12:04:37 2014 From: michaelwoerister at posteo.net (Michael Woerister) Date: Thu, 22 May 2014 21:04:37 +0200 Subject: [rust-dev] Why explicit named lifetimes? In-Reply-To: <37432076-B241-4957-B9CD-F667429ABAD8@mozilla.com> References: <8CFFBDE5-25F6-4ADB-A3BF-8A48CEEBC478@icloud.com> <537590A9.3040809@gmail.com> <537A52D8.8010001@mozilla.com> <537E0A7C.6010807@posteo.net> <37432076-B241-4957-B9CD-F667429ABAD8@mozilla.com> Message-ID: <537E4A45.7030705@posteo.net> On 22.05.2014 17:54, Felix S. Klock II wrote: > Michael (cc'ing rust-dev)- > > On 22 May 2014, at 16:32, Michael Woerister wrote: > >> Lately I've been thinking that it might be nice if one could omit the lifetimes from the list of generic parameters, as in: >> >> fn foo(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) >> >> instead of >> >> fn foo<'a, 'b, T>(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint) >> >> Especially for otherwise non-generic functions, having to explicitly list lifetimes seems a bit redundant, as they are unambiguously defined in the function signature anyway (as opposed to type parameters, which don't have the special `'` marker). > Note that this is not true in the general case. Consider e.g. methods with an type impl or a trait impl: in that scenario, one could bind lifetimes on the method itself, or in the type/trait being implemented. This distinction matters (in terms of what limits it imposes on the clients of those types/traits). > > (I provide a concrete example after my signature.) > > There are other changes one could make to still accommodate a change like you suggest in the general case, such as inferring some binding site (e.g. the nearest one) if a lifetime is otherwise found to be unbound. But I personally do not think such changes improve the character of the language (IMHO); I'd rather have a straight-forward rule that one applies in every context. > > Cheers, > -Felix > > Concrete Example: > > The variants below are quite different. > > #[deriving(Show)] > struct S<'a> { > p: &'a int > } > > impl<'a> S<'a> { > #[cfg(variant1)] > fn foo(&mut self, arg: &'a int) -> &'a int { > let old = self.p; > self.p = arg; > old > } > > #[cfg(variant2)] > fn foo<'a>(&mut self, arg: &'a int) -> &'a int { > let old = self.p; > self.p = arg; > old > } > > #[cfg(variant3)] > fn foo<'a>(&mut self, arg: &'a int) -> &'a int { > arg > } > > #[cfg(variant4)] > fn foo<'a>(&mut self, arg: &'a int) -> &'a int { > self.p > } > > #[cfg(variant5)] > fn foo<'a>(&self, arg: &'a int) -> &'a int { > self.p > } > > #[cfg(variant6)] > fn foo<'a>(&'a self, arg: &'a int) -> &'a int { > let _ = arg; > self.p > } > } > > #[allow(unused_mut)] > fn main() { > let x = 3; > let mut s = S{ p: &x }; > let y = 4; > println!("begin: {:?}", s); > let z = s.foo(&y); > println!("later: {:?} z: {:?}", s, z); > } > > Half of them do not compile (for differing reasons). Variants 1, 3, and 6 do run (and each produces a different output), but the interesting points come from understanding why the other cases do not compile. > > (FYI: It is probably easier to talk about the example if you first alpha-rename the method-bound lifetimes to something other than `'a`.) > Thanks for the detailed response, Felix. You are right, I didn't think about nested cases. It *would* still be possible to leave the lifetime parameters out of the list, but the proposition loses some of its allure. I'm not sure, though, if the outcome would be that bad. Nesting is not arbitrarily deep in practice and assuming that unbound variables belong to their nearest enclosing scope, as you suggest, seems like a reasonable idea from a program-readability perspective. I find variant #6 from your example rather interesting! At first glance, it seems that it shouldn't be possible to relate the lifetimes of `self` (lets call it 'b) and `self.p` (let's stay with 'a) in this case. Does the borrow checker infer a sub-typing relationship between the two lifetimes (i.e. 'a <: 'b)? It would make sense to say that a reference contained in some aggregate will always live at least as long as any reference to the aggregate, iff it is guaranteed that the contained reference always outlives the aggregate... as in: L(&A) < L(A) && L(A) < L(A.x) ===> L(&A) < L(A.x) I think, I just learned something new here :) Cheers! From pnathan.software at gmail.com Thu May 22 15:30:49 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Thu, 22 May 2014 15:30:49 -0700 Subject: [rust-dev] Seattle Rust Meetup interest? In-Reply-To: References: Message-ID: The meetup is still on. Same time, same place. Please be advised that if we are too big, we'll have to find a bigger place on the fly. I will send out an email in that case for the later arriving people. See you there! On May 19, 2014 1:36 PM, "benjamin adamson" wrote: > I'll be there! I don't have a particular project I am working on at the > moment though! > > > On Thu, May 15, 2014 at 8:36 PM, Eric Reed wrote: > >> I'm down for a meetup. I may be able to bring some others from UW CSE >> with me. >> >> >> On Thu, May 15, 2014 at 1:46 PM, Paul Nathan wrote: >> >>> Hi, >>> >>> It looks like two people have expressed interest in this. I think that's >>> enough to get together and talk. >>> >>> My suggestion for scheduling is next Thursday (May 22nd) at 7-9pm at >>> Remedy Teas[1] on Capitol Hill. >>> >>> Proposed topics: >>> >>> - meet & greet >>> - talk about extant Rust projects (if any) >>> - planned targets for projects. >>> >>> >>> Does this seem convenient & work for everyone interested? >>> >>> >>> [1] http://remedyteas.com >>> Remedy Teas >>> 345 15th Ave E >>> Seattle, WA 98112 >>> >>> >>> On Mon, May 12, 2014 at 5:05 PM, Eli Lindsey wrote: >>> >>>> +1 >>>> >>>> Somewhere around Capitol Hill would be very convenient. >>>> >>>> On May 12, 2014, at 11:31 AM, Paul Nathan >>>> wrote: >>>> >>>> Remedy Teas on Capitol Hill if interest is < 7 people. >>>> >>>> I am open to other alternatives, but don't usually prefer places with >>>> alcohol. I e I like coffee and tea shops. >>>> On May 12, 2014 10:14 AM, "benjamin adamson" < >>>> adamson.benjamin at gmail.com> wrote: >>>> >>>>> +1 where in Seattle are you thinking? >>>>> On May 11, 2014 11:08 PM, "Paul Nathan" >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This email is to gauge interest in doing a Rust meetup in Seattle. >>>>>> If there's interest, I'll coordinate finding a place & time that >>>>>> accomodates people. >>>>>> >>>>>> Regards, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> Rust-dev mailing list >>>>>> Rust-dev at mozilla.org >>>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>>> >>>>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > Adamson, Benjamin > adamson.benjamin at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndl at endl.ch Thu May 22 13:27:42 2014 From: ndl at endl.ch (Alexander Tsvyashchenko) Date: Thu, 22 May 2014 22:27:42 +0200 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback Message-ID: <1be6b7e90decf085737738bc47269ce5@endl.ch> Hi All, Recently I was playing with bindings generator from C++ to Rust. I managed to make things work for Qt5 wrapping, but stumbled into multiple issues along the way. I tried to summarize my "pain points" in the following blog post: http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 I hope that others might benefit from my experience and that some of these "pain points" can be fixed in Rust. I'll try to do my best in answering questions / acting on feedback, if any, but I have very limited amount of free time right now so sorry in advance if answers take some time. Thanks! -- Good luck! Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Thu May 22 21:12:39 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 22 May 2014 21:12:39 -0700 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback In-Reply-To: <1be6b7e90decf085737738bc47269ce5@endl.ch> References: <1be6b7e90decf085737738bc47269ce5@endl.ch> Message-ID: <8b19108a-80ec-4346-96ce-9c9fd0e41f1d@email.android.com> You can use "extern "Rust" fn" (or ||:'static) to achieve something like C++03 member function pointers without the lifetimes. Attacking Rust without asking first how to do this is unappreciated. In the future, unboxed closures will make callbacks easier. I am opposed to function overloading and default parameters. I do not see it as a burden to define meaningful unique function names. On the contrary, this helps greppability in large codebases. Patrick On May 22, 2014 1:27:42 PM PDT, Alexander Tsvyashchenko wrote: > > >Hi All, > >Recently I was playing with bindings generator from C++ to Rust. I >managed to make things work for Qt5 wrapping, but stumbled into >multiple >issues along the way. > >I tried to summarize my "pain points" in the following blog post: >http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 > >I hope that others might benefit from my experience and that some of >these "pain points" can be fixed in Rust. > >I'll try to do my best in answering questions / acting on feedback, if >any, but I have very limited amount of free time right now so sorry in >advance if answers take some time. > >Thanks! > >-- >Good luck! Alexander > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu May 22 21:15:44 2014 From: corey at octayn.net (Corey Richardson) Date: Thu, 22 May 2014 21:15:44 -0700 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback In-Reply-To: <1be6b7e90decf085737738bc47269ce5@endl.ch> References: <1be6b7e90decf085737738bc47269ce5@endl.ch> Message-ID: Given the size of the binaries it looks like you may not have been passing -O, which often gives the best code size. On Thu, May 22, 2014 at 1:27 PM, Alexander Tsvyashchenko wrote: > Hi All, > > Recently I was playing with bindings generator from C++ to Rust. I managed > to make things work for Qt5 wrapping, but stumbled into multiple issues > along the way. > > I tried to summarize my "pain points" in the following blog post: > http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 > > I hope that others might benefit from my experience and that some of these > "pain points" can be fixed in Rust. > > I'll try to do my best in answering questions / acting on feedback, if any, > but I have very limited amount of free time right now so sorry in advance if > answers take some time. > > Thanks! > > -- > Good luck! Alexander > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From dbau.pp at gmail.com Thu May 22 22:35:06 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 23 May 2014 15:35:06 +1000 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback In-Reply-To: <1be6b7e90decf085737738bc47269ce5@endl.ch> References: <1be6b7e90decf085737738bc47269ce5@endl.ch> Message-ID: <537EDE0A.4050002@gmail.com> Hi Alexander, I wrote up some feedback and tried to post it on your blog, but unfortunately submitting a comment was failing with an nginx error, so I posted it on /r/rust instead: http://www.reddit.com/r/rust/comments/269t6i/cxx2rust_the_pains_of_wrapping_c_in_rust_on_the/ (It's good to see people experimenting with GUI frameworks in Rust!) Huon On 23/05/14 06:27, Alexander Tsvyashchenko wrote: > > Hi All, > > Recently I was playing with bindings generator from C++ to Rust. I > managed to make things work for Qt5 wrapping, but stumbled into > multiple issues along the way. > > I tried to summarize my "pain points" in the following blog > post: http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 > > I hope that others might benefit from my experience and that some of > these "pain points" can be fixed in Rust. > > I'll try to do my best in answering questions / acting on feedback, if > any, but I have very limited amount of free time right now so sorry in > advance if answers take some time. > > Thanks! > > -- > Good luck! Alexander > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pssalmeida at gmail.com Fri May 23 06:04:12 2014 From: pssalmeida at gmail.com (=?UTF-8?Q?Paulo_S=C3=A9rgio_Almeida?=) Date: Fri, 23 May 2014 14:04:12 +0100 Subject: [rust-dev] Interaction between private fields and auto-dereferencing Message-ID: Hi all, (resending from different email address; there seems to be a problem with my other address) I don't know if this has been discussed, but I noticed an unpleasant interaction between private fields in the implementation of things like pointer types and auto-dereferencing. The example I noticed is: if I want to store a struct with field "x" inside an Arc, and then auto-dereference it I get the error: error: field `x` of struct `sync::arc::Arc` is private A program showing this, if comments are removed, where the ugly form (*p).x must be used to solve it: --- extern crate sync; use sync::Arc; struct Point { x: int, y: int } fn main() { let p = Arc::new(Point { x: 4, y: 8 }); let p1 = p.clone(); spawn(proc(){ println!("task v1: {}", p1.y); //println!("task v1: {}", p1.x); println!("task v1: {}", (*p1).x); }); println!("v: {}", p.y); //println!("v: {}", p.x); println!("v: {}", (*p).x); } -- The annoying thing is that a user of the pointer-type should not have to know or worry about what private fields the pointer implementation contains. A better user experience would be if, if in a context where there is no corresponding public field and auto-deref is available, auto-deref is attempted, ignoring private-fields of the pointer type. If this is too much of a hack or with complex or unforeseen consequences, a practical almost-solution without changing the compiler would be renaming private fields in pointer implementations, like Arc, so as to minimize the collision probability, e.g., use something like __x__ in arc.rs: pub struct Arc { priv __x__: *mut ArcInner, } Regards, Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at fisher-fleig.org Fri May 23 10:31:10 2014 From: bryce at fisher-fleig.org (Bryce Fisher-Fleig) Date: Fri, 23 May 2014 10:31:10 -0700 Subject: [rust-dev] Cross Platform Compatibility Message-ID: I'm trying to learn Rust by doing a project I call "iron-santa" ( https://github.com/brycefisher/iron-santa) that parses RSS feeds from Craigslist. I work on both a 64 bit Ubuntu 12.04 machine and a MacBook Pro OS 10.8, and I have the latest nightlies installed on both machines. I'm running into what appear to be cross-platform compatibility issues. Here is code that compiles on my OSX machine: struct CLZone { lat: f64, long: f64, name: ~str, url: ~str } fn get_clzones() -> ~[CLZone] { ~[ CLZone{lat:37.79511, long:-122.397235, name:"San Francisco Bay Area".to_owned(), url:"sfbay".to_owned()} ] } However, this same code fails on my Ubuntu machine with this error: "error: mismatched types: expected `~str` but found `std::strbuf::StrBuf` (expected box but found struct std::strbuf::StrBuf) src/iron-santa.rs:21 CLZone{lat:37.79511, long:-122.397235, name:"San Francisco Bay Area".to_owned(), url:"sfbay".to_owned()}" I assumed that string types from the std library would be cross platform compatibility. Is my assumption wrong or did I make some other mistake? Thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Fri May 23 10:34:44 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Fri, 23 May 2014 10:34:44 -0700 Subject: [rust-dev] Cross Platform Compatibility In-Reply-To: References: Message-ID: Are you sure you have the exact same rustc on each machine? Even if it was from a different day, this could happen, because that change is _very_ recent. From ben.striegel at gmail.com Fri May 23 11:26:42 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 23 May 2014 14:26:42 -0400 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback In-Reply-To: <8b19108a-80ec-4346-96ce-9c9fd0e41f1d@email.android.com> References: <1be6b7e90decf085737738bc47269ce5@endl.ch> <8b19108a-80ec-4346-96ce-9c9fd0e41f1d@email.android.com> Message-ID: On Fri, May 23, 2014 at 12:12 AM, Patrick Walton wrote: > You can use "extern "Rust" fn" (or ||:'static) to achieve something like > C++03 member function pointers without the lifetimes. Attacking Rust > without asking first how to do this is unappreciated. > I think that characterizing this as an "attack" is in bad faith. This is a very impressive and insightful post. Alexander is a member of our primary demographic, and it is immensely valuable to get real-world feedback on how C++ users will receive the language when employing it for non-trivial projects. If there is a misunderstanding over some of Rust's features, then it is a documentation deficiency that needs to be addressed. The fact that Alexander took the effort to post this here at all shows that he wants to understand the language, not to bash it. If only every blogger was so considerate! So thank you, Alexander. I hope that you found Rust enjoyable despite its current rough edges! I'd love it if you kept an eye on the language as it develops, and I'd be delighted to read a follow-up post incorporating the feedback from here and from reddit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndl at endl.ch Fri May 23 12:56:22 2014 From: ndl at endl.ch (Alexander Tsvyashchenko) Date: Fri, 23 May 2014 21:56:22 +0200 Subject: [rust-dev] =?utf-8?q?Qt5_Rust_bindings_and_general_C++_to_Rust_bi?= =?utf-8?q?ndings=09feedback?= In-Reply-To: <8b19108a-80ec-4346-96ce-9c9fd0e41f1d@email.android.com> References: <1be6b7e90decf085737738bc47269ce5@endl.ch> <8b19108a-80ec-4346-96ce-9c9fd0e41f1d@email.android.com> Message-ID: <46e5e0b7379c0fe98ff103525194886e@endl.ch> Hi Patrick, Thanks for your answer! See comments below. On 2014-05-23 06:12, Patrick Walton wrote: > You can use "extern "Rust" fn" (or ||:'static) to achieve something like C++03 member function pointers without the lifetimes. Do I understand correctly that by "extern "Rust" fn" you mean taking the pointer to the global function? If yes, then I'm definitely aware of the possibility to do that, but it is not helpful in the context of signals / slots. Please see my Reddit comment for more detailed explanation: http://www.reddit.com/r/rust/comments/269t6i/cxx2rust_the_pains_of_wrapping_c_in_rust_on_the/chpfi1o RE: (||:'static) - as you can see in my initial post, this is what I ended up using - only without the explicit 'static annotation, but with the same restriction of not having any captured state. I agree that from what I've seen so far, ||:'static seems to be the closest thing to member function pointers - but I'd argue it's still not the full replacement as it's more verbose - that is, requires explicitly passing the state + declaring & forwarding all function arguments, e.g. instead of "slot(&obj, &Class::method)" it's "slot(&obj, |obj, arg1, arg2, arg3, arg4, arg5, arg6, arg7| { obj.method(arg1, arg2, arg3, arg4, arg5, arg6, arg7) })". And yes, there are signals with up to 7 arguments in Qt5 ;-) > I am opposed to function overloading and default parameters. I do not see it as a burden to define meaningful unique function names. On the contrary, this helps greppability in large codebases. Yes, I do realize there are quite strong opinions regarding function overloading and default parameters within Rust development community. I hold strong opinions on this subject too, and these happen to be the opposite ones to what you have - which is the perfect background to start flame war, which I have zero interest in ;-) Therefore, I suggest we move from the question "are function overloading and default parameters good or bad?" to the question "Lots of existing C++ libraries use function overloading and default parameters. How Rust should deal with wrapping these?" I believe the answer to this question is important because with all the optimism around Rust adoption, I doubt all existing C++ libraries that were developed over the last decades (Qt including) will be magically re-implemented in Rust within the next year or two. So far I can imagine several possible answers: * "We don't care, your legacy C++ libraries are bad and you should feel bad!" - I think this stance would be bad for Rust and would hinder its adoption, but if that's the ultimate answer - I'd personally prefer it said loud and clear, so that at least nobody has any illusions. * "Define & maintain the mapping between C++ and Rust function names" (I assume this is what you're alluding to with "define meaningful unique function names" above?) While this might be possible for smaller libraries, this is out of the question for large libraries like Qt5 - at least I won't create and maintain this mapping for sure, and I doubt others will: just looking at the stats from 3 Qt5 libraries (QtCore, QtGui and QtWidgets) out of ~30 Qt libraries in total, from the 50745 wrapped methods 9601 were overloads and required renaming. Besides that, this has a disadvantage of throwing away majority of the experience people have with particular library and forcing them to le-learn its API. On top of that, not for every overload it's easy to come up with short, meaningful, memorable and distinctive names - you can try that exercise for http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect ;-) * "Come up with some way to allow overloading / default parameters" - possibly with reduced feature set, i.e. if type inference is difficult in the presence of overloads, as suggested in some overloads discussions (although not unsolvable, as proven by other languages that allow both type inference & overloading?), possibly exclude overloads from the type inference by annotating overloaded methods with special attributes? * Possibly some other options I'm missing? -- Good luck! Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndl at endl.ch Fri May 23 13:06:04 2014 From: ndl at endl.ch (Alexander Tsvyashchenko) Date: Fri, 23 May 2014 22:06:04 +0200 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback In-Reply-To: References: <1be6b7e90decf085737738bc47269ce5@endl.ch> <8b19108a-80ec-4346-96ce-9c9fd0e41f1d@email.android.com> Message-ID: <2079580adf337b0c770006dfea79d708@endl.ch> Hi Benjamin, Thanks for the support and encouragement! After spending days (evenings to be more precise ;-) wrestling with the compiler & trying different workarounds to implement at least some form of Qt5 bindings it's possible there's some frustration present in the post, but as explicitly stated - I definitely didn't have in mind to "attack" / "bash" anyone or anything, so if that was the impression my post creates - I do apologize for that! I've got some great feedback already (especially WRT enums / flags wrapping) that I'm going to incorporate in bindings generation. Also, as soon as Rust has unboxed closures support, I'll definitely try to experiment with these in the bindings to get to the nicer and safer signals / slots implementation. On 2014-05-23 20:26, Benjamin Striegel wrote: > On Fri, May 23, 2014 at 12:12 AM, Patrick Walton wrote: > >> You can use "extern "Rust" fn" (or ||:'static) to achieve something like C++03 member function pointers without the lifetimes. Attacking Rust without asking first how to do this is unappreciated. > > I think that characterizing this as an "attack" is in bad faith. This is a very impressive and insightful post. Alexander is a member of our primary demographic, and it is immensely valuable to get real-world feedback on how C++ users will receive the language when employing it for non-trivial projects. > > If there is a misunderstanding over some of Rust's features, then it is a documentation deficiency that needs to be addressed. The fact that Alexander took the effort to post this here at all shows that he wants to understand the language, not to bash it. If only every blogger was so considerate! > > So thank you, Alexander. I hope that you found Rust enjoyable despite its current rough edges! I'd love it if you kept an eye on the language as it develops, and I'd be delighted to read a follow-up post incorporating the feedback from here and from reddit. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev [1] -- Good luck! Alexander Links: ------ [1] https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Fri May 23 14:06:28 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 23 May 2014 14:06:28 -0700 Subject: [rust-dev] Interaction between private fields and auto-dereferencing In-Reply-To: References: Message-ID: <26736F1B-93CF-4A6F-A36A-15F03675AC59@sb.org> This looks like a legitimate problem. Have you filed an issue on the GitHub issues page? https://github.com/mozilla/rust/issues/new -Kevin On May 23, 2014, at 6:04 AM, Paulo S?rgio Almeida wrote: > Hi all, (resending from different email address; there seems to be a problem with my other address) > > I don't know if this has been discussed, but I noticed an unpleasant interaction between private fields in the implementation of things like pointer types and auto-dereferencing. > > The example I noticed is: if I want to store a struct with field "x" inside an Arc, and then auto-dereference it I get the error: > > error: field `x` of struct `sync::arc::Arc` is private > > A program showing this, if comments are removed, where the ugly form (*p).x must be used to solve it: > > --- > extern crate sync; > use sync::Arc; > > struct Point { x: int, y: int } > > fn main() { > let p = Arc::new(Point { x: 4, y: 8 }); > let p1 = p.clone(); > spawn(proc(){ > println!("task v1: {}", p1.y); > //println!("task v1: {}", p1.x); > println!("task v1: {}", (*p1).x); > }); > println!("v: {}", p.y); > //println!("v: {}", p.x); > println!("v: {}", (*p).x); > } > -- > > The annoying thing is that a user of the pointer-type should not have to know or worry about what private fields the pointer implementation contains. > > A better user experience would be if, if in a context where there is no corresponding public field and auto-deref is available, auto-deref is attempted, ignoring private-fields of the pointer type. > > If this is too much of a hack or with complex or unforeseen consequences, a practical almost-solution without changing the compiler would be renaming private fields in pointer implementations, like Arc, so as to minimize the collision probability, e.g., use something like __x__ in arc.rs: > > pub struct Arc { > priv __x__: *mut ArcInner, > } > > Regards, > Paulo > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From zo1980 at gmail.com Sat May 24 00:06:03 2014 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Sat, 24 May 2014 09:06:03 +0200 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback Message-ID: Alexander, your option 2 could be done automatically. By appending postfixes to the overloaded name depending on the parameter types. Increasing the number of letters used till the ambiguity is fully resolved. What do you think? fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush ) fillRect_I_I_I_I_BS ( int x, int y, int width, int height, Qt::BrushStyle style ) fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style ) fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style ) fillRect_R_B ( const QRect & rectangle, const QBrush & brush ) fillRect_R_C ( const QRect & rectangle, const QColor & color ) fillRect_RF_C ( const QRectF & rectangle, const QColor & color ) fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush & brush ) fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor & color ) fillRect_I_I_I_I_GC ( int x, int y, int width, int height, Qt::GlobalColor color ) fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color ) fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color ) Alexander Tsvyashchenko wrote: > So far I can imagine several possible answers: > > 1. "We don't care, your legacy C++ libraries are bad and you should > feel bad!" - I think this stance would be bad for Rust and would hinder its > adoption, but if that's the ultimate answer - I'd personally prefer it said > loud and clear, so that at least nobody has any illusions. > > 2. "Define & maintain the mapping between C++ and Rust function names" > (I assume this is what you're alluding to with "define meaningful unique > function names" above?) While this might be possible for smaller libraries, > this is out of the question for large libraries like Qt5 - at least I won't > create and maintain this mapping for sure, and I doubt others will: just > looking at the stats from 3 Qt5 libraries (QtCore, QtGui and QtWidgets) out > of ~30 Qt libraries in total, from the 50745 wrapped methods 9601 were > overloads and required renaming. > > Besides that, this has a disadvantage of throwing away majority of the > experience people have with particular library and forcing them to le-learn > its API. > > On top of that, not for every overload it's easy to come up with > short, meaningful, memorable and distinctive names - you can try that > exercise for http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect;-) > > 3. "Come up with some way to allow overloading / default parameters" - > possibly with reduced feature set, i.e. if type inference is difficult in > the presence of overloads, as suggested in some overloads discussions > (although not unsolvable, as proven by other languages that allow both type > inference & overloading?), possibly exclude overloads from the type > inference by annotating overloaded methods with special attributes? > > 4. Possibly some other options I'm missing? > > -- > Good luck! Alexander > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sat May 24 03:45:42 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sat, 24 May 2014 12:45:42 +0200 Subject: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback In-Reply-To: References: Message-ID: On Sat, May 24, 2014 at 9:06 AM, Zolt?n T?th wrote: > Alexander, your option 2 could be done automatically. By appending > postfixes to the overloaded name depending on the parameter types. > Increasing the number of letters used till the ambiguity is fully resolved. > > What do you think? > > > fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush ) > fillRect_I_I_I_I_BS ( int x, int y, int width, int height, Qt::BrushStyle > style ) > fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style ) > fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style ) > fillRect_R_B ( const QRect & rectangle, const QBrush & brush ) > fillRect_R_C ( const QRect & rectangle, const QColor & color ) > fillRect_RF_C ( const QRectF & rectangle, const QColor & color ) > fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush & > brush ) > fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor & > color ) > fillRect_I_I_I_I_GC ( int x, int y, int width, int height, Qt::GlobalColor > color ) > fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color ) > fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color ) > > > I believe this alternative was considered in the original blog post Alexander wrote: this is, in essence, mangling. It makes for ugly function names, although the prefix helps in locating them I guess. Before we talk about generation though, I would start about investigating where those overloads come from. First, there are two different objects being manipulated here: + QRect is a rectangle with integral coordinates + QRectF is a rectangle with floating point coordinates Second, a QRect may already be build from "(int* x*, int* y*, int* width*, int* height*)"; thus all overloads taking 4 hints instead of a QRect are pretty useless in a sense. Third, in a similar vein, QBrush can be build from "(Qt::BrushStyle)", "(Qt::GlobalColor)" or "(QColor const&)". So once again those overloads are pretty useless. This leaves us with: + fillRect(QRect const&, QBrush const&) + fillRect(QRectF const&, QBrush const&) Yep, that's it. Of all those inconsistent overloads (missing 4 taking 4 floats, by the way...) only 2 are ever useful. The other 10 can be safely discarded without impacting the expressiveness. Now, of course, the real question is how well a tool could perform this reduction step. I would note here that the position and names of the "coordinate" arguments of "fillRect" is exactly that of those to "QRect"; maybe a simple exhaustive search would thus suffice (though it does require semantic understanding of what a constructor and default arguments are). It would be interesting checking how many overloads remain *after* this reduction step. Here we got a factor of 6 already (should have been 8 if the interface had been complete). It would also be interesting checking if the distinction int/float often surfaces, there might be an opportunity here. -- Matthieu Alexander Tsvyashchenko wrote: > >> So far I can imagine several possible answers: >> >> 1. "We don't care, your legacy C++ libraries are bad and you should >> feel bad!" - I think this stance would be bad for Rust and would hinder its >> adoption, but if that's the ultimate answer - I'd personally prefer it said >> loud and clear, so that at least nobody has any illusions. >> >> 2. "Define & maintain the mapping between C++ and Rust function >> names" (I assume this is what you're alluding to with "define meaningful >> unique function names" above?) While this might be possible for smaller >> libraries, this is out of the question for large libraries like Qt5 - at >> least I won't create and maintain this mapping for sure, and I doubt others >> will: just looking at the stats from 3 Qt5 libraries (QtCore, QtGui and >> QtWidgets) out of ~30 Qt libraries in total, from the 50745 wrapped >> methods 9601 were overloads and required renaming. >> >> Besides that, this has a disadvantage of throwing away majority of >> the experience people have with particular library and forcing them to >> le-learn its API. >> >> On top of that, not for every overload it's easy to come up with >> short, meaningful, memorable and distinctive names - you can try that >> exercise for http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect;-) >> >> 3. "Come up with some way to allow overloading / default parameters" >> - possibly with reduced feature set, i.e. if type inference is difficult in >> the presence of overloads, as suggested in some overloads discussions >> (although not unsolvable, as proven by other languages that allow both type >> inference & overloading?), possibly exclude overloads from the type >> inference by annotating overloaded methods with special attributes? >> >> 4. Possibly some other options I'm missing? >> >> -- >> Good luck! Alexander >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pssalmeida at gmail.com Sat May 24 03:52:25 2014 From: pssalmeida at gmail.com (=?UTF-8?Q?Paulo_S=C3=A9rgio_Almeida?=) Date: Sat, 24 May 2014 11:52:25 +0100 Subject: [rust-dev] Interaction between private fields and auto-dereferencing In-Reply-To: <26736F1B-93CF-4A6F-A36A-15F03675AC59@sb.org> References: <26736F1B-93CF-4A6F-A36A-15F03675AC59@sb.org> Message-ID: No, I was just getting feedback if this was a problem already considered. I have not been following all Rust progress very closely (trying to catch up now). But I can try to do so later. Regards, Paulo On 23 May 2014 22:06, Kevin Ballard wrote: > This looks like a legitimate problem. Have you filed an issue on the > GitHub issues page? https://github.com/mozilla/rust/issues/new > > -Kevin > > On May 23, 2014, at 6:04 AM, Paulo S?rgio Almeida > wrote: > > Hi all, (resending from different email address; there seems to be a > problem with my other address) > > I don't know if this has been discussed, but I noticed an unpleasant > interaction between private fields in the implementation of things like > pointer types and auto-dereferencing. > > The example I noticed is: if I want to store a struct with field "x" > inside an Arc, and then auto-dereference it I get the error: > > error: field `x` of struct `sync::arc::Arc` is private > > A program showing this, if comments are removed, where the ugly form > (*p).x must be used to solve it: > > --- > extern crate sync; > use sync::Arc; > > struct Point { x: int, y: int } > > fn main() { > let p = Arc::new(Point { x: 4, y: 8 }); > let p1 = p.clone(); > spawn(proc(){ > println!("task v1: {}", p1.y); > //println!("task v1: {}", p1.x); > println!("task v1: {}", (*p1).x); > }); > println!("v: {}", p.y); > //println!("v: {}", p.x); > println!("v: {}", (*p).x); > } > -- > > The annoying thing is that a user of the pointer-type should not have to > know or worry about what private fields the pointer implementation > contains. > > A better user experience would be if, if in a context where there is no > corresponding public field and auto-deref is available, auto-deref is > attempted, ignoring private-fields of the pointer type. > > If this is too much of a hack or with complex or unforeseen consequences, > a practical almost-solution without changing the compiler would be renaming > private fields in pointer implementations, like Arc, so as to minimize the > collision probability, e.g., use something like __x__ in arc.rs: > > pub struct Arc { > priv __x__: *mut ArcInner, > } > > Regards, > Paulo > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Sat May 24 04:42:17 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 24 May 2014 21:42:17 +1000 Subject: [rust-dev] Interaction between private fields and auto-dereferencing In-Reply-To: References: <26736F1B-93CF-4A6F-A36A-15F03675AC59@sb.org> Message-ID: <53808599.5030002@gmail.com> I believe much of the underlying issue is covered by #12808. I have just filed a pull request #14402 to "fix" the immediate symptoms of this bug by making it harder to accidentally have struct fields taht conflict with the private fields of the libstd types. There's also issue #13126 and RFC #25 about general issues with public fields/methods and Deref: Huon https://github.com/mozilla/rust/issues/12808 https://github.com/mozilla/rust/pull/14402 https://github.com/rust-lang/rfcs/pull/25 https://github.com/mozilla/rust/issues/13126 On 24/05/14 20:52, Paulo S?rgio Almeida wrote: > No, I was just getting feedback if this was a problem already > considered. I have not been following all Rust progress very closely > (trying to catch up now). But I can try to do so later. > > Regards, > Paulo > > > On 23 May 2014 22:06, Kevin Ballard > wrote: > > This looks like a legitimate problem. Have you filed an issue on > the GitHub issues page? https://github.com/mozilla/rust/issues/new > > -Kevin > > On May 23, 2014, at 6:04 AM, Paulo S?rgio Almeida > > wrote: > >> Hi all, (resending from different email address; there seems >> to be a problem with my other address) >> >> I don't know if this has been discussed, but I noticed an >> unpleasant interaction between private fields in the >> implementation of things like pointer types and auto-dereferencing. >> >> The example I noticed is: if I want to store a struct with field >> "x" inside an Arc, and then auto-dereference it I get the error: >> >> error: field `x` of struct `sync::arc::Arc` is private >> >> A program showing this, if comments are removed, where the ugly >> form (*p).x must be used to solve it: >> >> --- >> extern crate sync; >> use sync::Arc; >> >> struct Point { x: int, y: int } >> >> fn main() { >> let p = Arc::new(Point { x: 4, y: 8 }); >> let p1 = p.clone(); >> spawn(proc(){ >> println!("task v1: {}", p1.y); >> //println!("task v1: {}", p1.x); >> println!("task v1: {}", (*p1).x); >> }); >> println!("v: {}", p.y); >> //println!("v: {}", p.x); >> println!("v: {}", (*p).x); >> } >> -- >> >> The annoying thing is that a user of the pointer-type should not >> have to know or worry about what private fields the pointer >> implementation contains. >> >> A better user experience would be if, if in a context where there >> is no corresponding public field and auto-deref is available, >> auto-deref is attempted, ignoring private-fields of the pointer >> type. >> >> If this is too much of a hack or with complex or unforeseen >> consequences, a practical almost-solution without changing the >> compiler would be renaming private fields in pointer >> implementations, like Arc, so as to minimize the collision >> probability, e.g., use something like __x__ in arc.rs >> : >> >> pub struct Arc { >> priv __x__: *mut ArcInner, >> } >> >> Regards, >> Paulo >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pssalmeida at gmail.com Sat May 24 07:38:45 2014 From: pssalmeida at gmail.com (=?UTF-8?Q?Paulo_S=C3=A9rgio_Almeida?=) Date: Sat, 24 May 2014 15:38:45 +0100 Subject: [rust-dev] Interaction between private fields and auto-dereferencing In-Reply-To: <53808599.5030002@gmail.com> References: <26736F1B-93CF-4A6F-A36A-15F03675AC59@sb.org> <53808599.5030002@gmail.com> Message-ID: Nice! On 24 May 2014 12:42, Huon Wilson wrote: > I believe much of the underlying issue is covered by #12808. I have just > filed a pull request #14402 to "fix" the immediate symptoms of this bug by > making it harder to accidentally have struct fields taht conflict with the > private fields of the libstd types. > > There's also issue #13126 and RFC #25 about general issues with public > fields/methods and Deref: > > > Huon > > > https://github.com/mozilla/rust/issues/12808 > https://github.com/mozilla/rust/pull/14402 > https://github.com/rust-lang/rfcs/pull/25 > https://github.com/mozilla/rust/issues/13126 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtompark at gmail.com Sat May 24 20:03:59 2014 From: gtompark at gmail.com (Tom Park) Date: Sat, 24 May 2014 20:03:59 -0700 Subject: [rust-dev] 3 SF events in June: a Dinner, Game Tech Meetup, and a Spinning Trianglthon In-Reply-To: <537DBAD9.7090309@seld.be> References: <537DBAD9.7090309@seld.be> Message-ID: > https://air.mozilla.org/search/?q=rust+meetup Removing "meetup" from that search might be a little better: https://air.mozilla.org/search/?q=rust Specifically, it yields the Nov 2013 Rust meetup (which includes Yehuda Katz's talk about calling Rust from Ruby via C FFI): https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ I mention this because about a month ago on #rust IRC, someone was looking for that particular talk but having trouble finding it because he was using the "meetup" keyword. On Thu, May 22, 2014 at 1:52 AM, Jordi Boggiano wrote: > Here is a link to watch all past (and upcoming) rust meetups for those > that can't be there in person. It took me 5min to dig it up again so I > thought I'd share. > > https://air.mozilla.org/search/?q=rust+meetup > > Cheers > > -- > Jordi Boggiano > @seldaek - http://nelm.io/jordi > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at bitpuffin.com Sun May 25 10:25:17 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Sun, 25 May 2014 19:25:17 +0200 Subject: [rust-dev] Something like generics, but with ints Message-ID: Hello! I was asking in IRC if something like this: fn cofactor(m: Matrix, row, col: int) -> Matrix {...} was possible. I quickly got the response that generics doesn't work with integers. So my question is, is there anyway to achieve something similar? Or would it be possible in the future to do generic instantiation based on more than just types. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sun May 25 10:37:12 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 25 May 2014 19:37:12 +0200 Subject: [rust-dev] Something like generics, but with ints In-Reply-To: References: Message-ID: It's been discussed, but there is still discussion on the best way to achieve this. At the moment, you should be able to get around it using Peano numbers [1]: struct Zero; struct Succ; struct Matrix { data: Vec, } fn cofactor( m: Matrix, Succ>, row: int, col: int ) -> Matrix { Matrix::{ data: vec!() } } Of course, I would dread seeing the error message should you need more than a couple rows/columns... [1] http://www.haskell.org/haskellwiki/Peano_numbers On Sun, May 25, 2014 at 7:25 PM, Isak Andersson wrote: > Hello! > > I was asking in IRC if something like this: > > fn cofactor(m: Matrix, row, col: int) -> Matrix {...} > > was possible. I quickly got the response that generics doesn't work with > integers. So my question is, is there anyway to achieve something similar? > > Or would it be possible in the future to do generic instantiation based on > more > than just types. > > Thanks! > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at bitpuffin.com Sun May 25 10:55:11 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Sun, 25 May 2014 19:55:11 +0200 Subject: [rust-dev] Something like generics, but with ints In-Reply-To: References: Message-ID: Hey, thanks for the reply! (minor correction for myself, I meant to say submatrix rather than cofactor) Using Peano numbers is quite an interesting solution.. The point of it would be to make arbitrarily sized matrices that will detect as many errors as possible at compile time.. However. With Peano numbers you can really only add numbers right? Which makes it problematic in the case of submatrix, where you actually end up with a matrix that has one row and one column less than the original. I guess you could work around it somehow by adding a Prev type or something but then you run in to issues when you compare types that got to the same dimension through different ways. So you'd have to like make a complicated macro or something to find what the number represented by the Peano ish number is.. On Sun, May 25, 2014 at 7:37 PM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > It's been discussed, but there is still discussion on the best way to > achieve this. > > At the moment, you should be able to get around it using Peano numbers [1]: > > struct Zero; > > struct Succ; > > struct Matrix { > data: Vec, > } > > fn cofactor( > m: Matrix, Succ>, > row: int, > col: int > ) -> Matrix > { > Matrix::{ data: vec!() } > } > > > Of course, I would dread seeing the error message should you need more > than a couple rows/columns... > > [1] http://www.haskell.org/haskellwiki/Peano_numbers > > > On Sun, May 25, 2014 at 7:25 PM, Isak Andersson wrote: > >> Hello! >> >> I was asking in IRC if something like this: >> >> fn cofactor(m: Matrix, row, col: int) -> Matrix >> {...} >> >> was possible. I quickly got the response that generics doesn't work with >> integers. So my question is, is there anyway to achieve something similar? >> >> Or would it be possible in the future to do generic instantiation based >> on more >> than just types. >> >> Thanks! >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at bitpuffin.com Sun May 25 12:05:28 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Sun, 25 May 2014 21:05:28 +0200 Subject: [rust-dev] Something like generics, but with ints In-Reply-To: <53823DE0.6010102@aepsil0n.de> References: <53823DE0.6010102@aepsil0n.de> Message-ID: Ah cool! I really hope this gets somewhere.. It is a really important thing for linear algebra libraries (which I am writing in Nimrod but have run in to bugs that are holding me back so I was looking around for alternatives). Cheers! On Sun, May 25, 2014 at 9:00 PM, Eduard Bopp wrote: > On 05/25/2014 07:25 PM, Isak Andersson wrote: > > Hello! > > > > I was asking in IRC if something like this: > > > > fn cofactor(m: Matrix, row, col: int) -> Matrix > {...} > > > > was possible. I quickly got the response that generics doesn't work with > > integers. So my question is, is there anyway to achieve something > similar? > > > > Or would it be possible in the future to do generic instantiation based > on > > more > > than just types. > > > > Thanks! > > I actually opened an RFC for that feature a couple of weeks ago: > > https://github.com/rust-lang/rfcs/pull/56 > > There are a couple of technical issues that would need to be resolved > before implementing this, but there's some support to get this feature > into Rust at some point. > > Cheers, > Eduard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Sun May 25 13:21:59 2014 From: kevin at sb.org (Kevin Ballard) Date: Sun, 25 May 2014 13:21:59 -0700 Subject: [rust-dev] Something like generics, but with ints In-Reply-To: References: Message-ID: <7715792E-DF18-401B-916A-5A9823CD6684@sb.org> Matthieu's code shows subtraction. It works via addition by making the input the type that uses addition, and the output the "base" type. -Kevin On May 25, 2014, at 10:55 AM, Isak Andersson wrote: > Hey, thanks for the reply! > > (minor correction for myself, I meant to say submatrix rather than cofactor) > > Using Peano numbers is quite an interesting solution.. > > The point of it would be to make arbitrarily sized matrices that will detect as > many errors as possible at compile time.. > > However. With Peano numbers you can really only add numbers right? Which > makes it problematic in the case of submatrix, where you actually end up with > a matrix that has one row and one column less than the original. > > I guess you could work around it somehow by adding a Prev type or something > but then you run in to issues when you compare types that got to the same dimension > through different ways. So you'd have to like make a complicated macro or something > to find what the number represented by the Peano ish number is.. > > > > On Sun, May 25, 2014 at 7:37 PM, Matthieu Monrocq wrote: > It's been discussed, but there is still discussion on the best way to achieve this. > > At the moment, you should be able to get around it using Peano numbers [1]: > > struct Zero; > > struct Succ; > > struct Matrix { > data: Vec, > } > > fn cofactor( > m: Matrix, Succ>, > row: int, > col: int > ) -> Matrix > { > Matrix::{ data: vec!() } > } > > > Of course, I would dread seeing the error message should you need more than a couple rows/columns... > > [1] http://www.haskell.org/haskellwiki/Peano_numbers > > > On Sun, May 25, 2014 at 7:25 PM, Isak Andersson wrote: > Hello! > > I was asking in IRC if something like this: > > fn cofactor(m: Matrix, row, col: int) -> Matrix {...} > > was possible. I quickly got the response that generics doesn't work with > integers. So my question is, is there anyway to achieve something similar? > > Or would it be possible in the future to do generic instantiation based on more > than just types. > > Thanks! > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at bitpuffin.com Sun May 25 15:39:12 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Mon, 26 May 2014 00:39:12 +0200 Subject: [rust-dev] Something like generics, but with ints In-Reply-To: <7715792E-DF18-401B-916A-5A9823CD6684@sb.org> References: <7715792E-DF18-401B-916A-5A9823CD6684@sb.org> Message-ID: Ohhhh, yeah now I see it actually. Took a while for me to grok :) Thanks! On Sun, May 25, 2014 at 10:21 PM, Kevin Ballard wrote: > Matthieu's code shows subtraction. It works via addition by making the > input the type that uses addition, and the output the "base" type. > > -Kevin > > On May 25, 2014, at 10:55 AM, Isak Andersson > wrote: > > Hey, thanks for the reply! > > (minor correction for myself, I meant to say submatrix rather than > cofactor) > > Using Peano numbers is quite an interesting solution.. > > The point of it would be to make arbitrarily sized matrices that will > detect as > many errors as possible at compile time.. > > However. With Peano numbers you can really only add numbers right? Which > makes it problematic in the case of submatrix, where you actually end up > with > a matrix that has one row and one column less than the original. > > I guess you could work around it somehow by adding a Prev type or something > but then you run in to issues when you compare types that got to the same > dimension > through different ways. So you'd have to like make a complicated macro or > something > to find what the number represented by the Peano ish number is.. > > > > On Sun, May 25, 2014 at 7:37 PM, Matthieu Monrocq < > matthieu.monrocq at gmail.com> wrote: > >> It's been discussed, but there is still discussion on the best way to >> achieve this. >> >> At the moment, you should be able to get around it using Peano numbers >> [1]: >> >> struct Zero; >> >> struct Succ; >> >> struct Matrix { >> data: Vec, >> } >> >> fn cofactor( >> m: Matrix, Succ>, >> row: int, >> col: int >> ) -> Matrix >> { >> Matrix::{ data: vec!() } >> } >> >> >> Of course, I would dread seeing the error message should you need more >> than a couple rows/columns... >> >> [1] http://www.haskell.org/haskellwiki/Peano_numbers >> >> >> On Sun, May 25, 2014 at 7:25 PM, Isak Andersson wrote: >> >>> Hello! >>> >>> I was asking in IRC if something like this: >>> >>> fn cofactor(m: Matrix, row, col: int) -> Matrix >>> {...} >>> >>> was possible. I quickly got the response that generics doesn't work with >>> integers. So my question is, is there anyway to achieve something >>> similar? >>> >>> Or would it be possible in the future to do generic instantiation based >>> on more >>> than just types. >>> >>> Thanks! >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at urbanhafner.com Sun May 25 23:32:28 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Mon, 26 May 2014 08:32:28 +0200 Subject: [rust-dev] StrBuf and regular expressions Message-ID: Hello there, I just updated the compiler (I use the git master branch) and now when I read in a file I get a StrBuf instead of a ~str. That is easy enough to change, but how do I use regular expressions now? I have the following in my code: let re = regex!(r"SZ\[(\d+)\]"); let captures = re.captures(self.sgf).unwrap(); And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I have just a Rust compiler that is somewhere in between (i.e. not everything has been changed to StrBuf) or is this intentional? And if so, what's the best way to use regular expressions now? Urban -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamslam at gmail.com Sun May 25 23:36:45 2014 From: jamslam at gmail.com (Andrew Gallant) Date: Mon, 26 May 2014 02:36:45 -0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: Try using `self.sgf.as_slice()` instead. The change is necessary, AFAIK, because `~str` would automatically be converted to a borrowed reference without having to explicitly call the `as_slice` method. This doesn't happen for the StrBuf (and what is now String, I think) type. My suspicion is that the automatic conversion will come back at some point, but I'm not sure. - Andrew On Mon, May 26, 2014 at 2:32 AM, Urban Hafner wrote: > Hello there, > > I just updated the compiler (I use the git master branch) and now when I > read in a file I get a StrBuf instead of a ~str. That is easy enough to > change, but how do I use regular expressions now? I have the following in my > code: > > let re = regex!(r"SZ\[(\d+)\]"); > let captures = re.captures(self.sgf).unwrap(); > > And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I have > just a Rust compiler that is somewhere in between (i.e. not everything has > been changed to StrBuf) or is this intentional? And if so, what's the best > way to use regular expressions now? > > Urban > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From dpx.infinity at gmail.com Sun May 25 23:58:56 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Mon, 26 May 2014 10:58:56 +0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: > My suspicion is that the automatic conversion will come back at some > point, but I'm not sure. I think it will be possible to make `String` implement `Deref` when DST land. Then it will be possible to convert from `String` to `&str` using explicit reborrowing: let sgf_slice = &*sgf; I'm not sure this will be fully automatic when `String` is an arbitrary actual argument to arbitrary function, however. 2014-05-26 10:36 GMT+04:00 Andrew Gallant : > Try using `self.sgf.as_slice()` instead. > > The change is necessary, AFAIK, because `~str` would automatically be > converted to a borrowed reference without having to explicitly call the > `as_slice` method. This doesn't happen for the StrBuf (and what is now > String, I think) type. > > My suspicion is that the automatic conversion will come back at some > point, but I'm not sure. > > - Andrew > > > On Mon, May 26, 2014 at 2:32 AM, Urban Hafner wrote: >> Hello there, >> >> I just updated the compiler (I use the git master branch) and now when I >> read in a file I get a StrBuf instead of a ~str. That is easy enough to >> change, but how do I use regular expressions now? I have the following in my >> code: >> >> let re = regex!(r"SZ\[(\d+)\]"); >> let captures = re.captures(self.sgf).unwrap(); >> >> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I have >> just a Rust compiler that is somewhere in between (i.e. not everything has >> been changed to StrBuf) or is this intentional? And if so, what's the best >> way to use regular expressions now? >> >> Urban >> -- >> Freelancer >> >> Available for hire for Ruby, Ruby on Rails, and JavaScript projects >> >> More at http://urbanhafner.com >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From contact at urbanhafner.com Mon May 26 00:31:40 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Mon, 26 May 2014 09:31:40 +0200 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: Thanks guys, I now use "as_slice()" when necessary. And hopefully in the future the regular expression library will be updated to work on StrBuf instead of &str as this seems to be the main use case (read in file, run regexp on it). Urban On Mon, May 26, 2014 at 8:58 AM, Vladimir Matveev wrote: > > My suspicion is that the automatic conversion will come back at some > > point, but I'm not sure. > > I think it will be possible to make `String` implement `Deref` > when DST land. Then it will be possible to convert from `String` to > `&str` using explicit reborrowing: > > let sgf_slice = &*sgf; > > I'm not sure this will be fully automatic when `String` is an > arbitrary actual argument to arbitrary function, however. > > 2014-05-26 10:36 GMT+04:00 Andrew Gallant : > > Try using `self.sgf.as_slice()` instead. > > > > The change is necessary, AFAIK, because `~str` would automatically be > > converted to a borrowed reference without having to explicitly call the > > `as_slice` method. This doesn't happen for the StrBuf (and what is now > > String, I think) type. > > > > My suspicion is that the automatic conversion will come back at some > > point, but I'm not sure. > > > > - Andrew > > > > > > On Mon, May 26, 2014 at 2:32 AM, Urban Hafner > wrote: > >> Hello there, > >> > >> I just updated the compiler (I use the git master branch) and now when I > >> read in a file I get a StrBuf instead of a ~str. That is easy enough to > >> change, but how do I use regular expressions now? I have the following > in my > >> code: > >> > >> let re = regex!(r"SZ\[(\d+)\]"); > >> let captures = re.captures(self.sgf).unwrap(); > >> > >> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I > have > >> just a Rust compiler that is somewhere in between (i.e. not everything > has > >> been changed to StrBuf) or is this intentional? And if so, what's the > best > >> way to use regular expressions now? > >> > >> Urban > >> -- > >> Freelancer > >> > >> Available for hire for Ruby, Ruby on Rails, and JavaScript projects > >> > >> More at http://urbanhafner.com > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamslam at gmail.com Mon May 26 00:41:53 2014 From: jamslam at gmail.com (Andrew Gallant) Date: Mon, 26 May 2014 03:41:53 -0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: It should not receive such an update. There's no reason for the library to require a string allocated on the heap. On May 26, 2014 3:31 AM, "Urban Hafner" wrote: > Thanks guys, I now use "as_slice()" when necessary. And hopefully in the > future the regular expression library will be updated to work on StrBuf > instead of &str as this seems to be the main use case (read in file, run > regexp on it). > > Urban > > > On Mon, May 26, 2014 at 8:58 AM, Vladimir Matveev wrote: > >> > My suspicion is that the automatic conversion will come back at some >> > point, but I'm not sure. >> >> I think it will be possible to make `String` implement `Deref` >> when DST land. Then it will be possible to convert from `String` to >> `&str` using explicit reborrowing: >> >> let sgf_slice = &*sgf; >> >> I'm not sure this will be fully automatic when `String` is an >> arbitrary actual argument to arbitrary function, however. >> >> 2014-05-26 10:36 GMT+04:00 Andrew Gallant : >> > Try using `self.sgf.as_slice()` instead. >> > >> > The change is necessary, AFAIK, because `~str` would automatically be >> > converted to a borrowed reference without having to explicitly call the >> > `as_slice` method. This doesn't happen for the StrBuf (and what is now >> > String, I think) type. >> > >> > My suspicion is that the automatic conversion will come back at some >> > point, but I'm not sure. >> > >> > - Andrew >> > >> > >> > On Mon, May 26, 2014 at 2:32 AM, Urban Hafner >> wrote: >> >> Hello there, >> >> >> >> I just updated the compiler (I use the git master branch) and now when >> I >> >> read in a file I get a StrBuf instead of a ~str. That is easy enough to >> >> change, but how do I use regular expressions now? I have the following >> in my >> >> code: >> >> >> >> let re = regex!(r"SZ\[(\d+)\]"); >> >> let captures = re.captures(self.sgf).unwrap(); >> >> >> >> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do >> I have >> >> just a Rust compiler that is somewhere in between (i.e. not everything >> has >> >> been changed to StrBuf) or is this intentional? And if so, what's the >> best >> >> way to use regular expressions now? >> >> >> >> Urban >> >> -- >> >> Freelancer >> >> >> >> Available for hire for Ruby, Ruby on Rails, and JavaScript projects >> >> >> >> More at http://urbanhafner.com >> >> >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Mon May 26 00:41:59 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Mon, 26 May 2014 11:41:59 +0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: > And hopefully in the future the regular expression library will be updated to work on StrBuf instead of &str This is very unlikely. See, you can go from `StrBuf` to `&str` without allocation - `as_slice()` returns a "view" into the `StrBuf`. This is very cheap operation. But you cannot go from `&str` to `StrBuf` without allocation and copying, which are much more expensive than slicing. Hence you should always try to use `&str` where possible, only resorting to `StrBuf` when absolutely necessary (for example, when you need to accumulate a string dynamically). All APIs should also take `&str` when possible. 2014-05-26 11:31 GMT+04:00 Urban Hafner : > Thanks guys, I now use "as_slice()" when necessary. And hopefully in the > future the regular expression library will be updated to work on StrBuf > instead of &str as this seems to be the main use case (read in file, run > regexp on it). > > Urban > > > On Mon, May 26, 2014 at 8:58 AM, Vladimir Matveev > wrote: >> >> > My suspicion is that the automatic conversion will come back at some >> > point, but I'm not sure. >> >> I think it will be possible to make `String` implement `Deref` >> when DST land. Then it will be possible to convert from `String` to >> `&str` using explicit reborrowing: >> >> let sgf_slice = &*sgf; >> >> I'm not sure this will be fully automatic when `String` is an >> arbitrary actual argument to arbitrary function, however. >> >> 2014-05-26 10:36 GMT+04:00 Andrew Gallant : >> > Try using `self.sgf.as_slice()` instead. >> > >> > The change is necessary, AFAIK, because `~str` would automatically be >> > converted to a borrowed reference without having to explicitly call the >> > `as_slice` method. This doesn't happen for the StrBuf (and what is now >> > String, I think) type. >> > >> > My suspicion is that the automatic conversion will come back at some >> > point, but I'm not sure. >> > >> > - Andrew >> > >> > >> > On Mon, May 26, 2014 at 2:32 AM, Urban Hafner >> > wrote: >> >> Hello there, >> >> >> >> I just updated the compiler (I use the git master branch) and now when >> >> I >> >> read in a file I get a StrBuf instead of a ~str. That is easy enough to >> >> change, but how do I use regular expressions now? I have the following >> >> in my >> >> code: >> >> >> >> let re = regex!(r"SZ\[(\d+)\]"); >> >> let captures = re.captures(self.sgf).unwrap(); >> >> >> >> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I >> >> have >> >> just a Rust compiler that is somewhere in between (i.e. not everything >> >> has >> >> been changed to StrBuf) or is this intentional? And if so, what's the >> >> best >> >> way to use regular expressions now? >> >> >> >> Urban >> >> -- >> >> Freelancer >> >> >> >> Available for hire for Ruby, Ruby on Rails, and JavaScript projects >> >> >> >> More at http://urbanhafner.com >> >> >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev > > > > > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com From contact at urbanhafner.com Mon May 26 00:43:37 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Mon, 26 May 2014 09:43:37 +0200 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: Alright. Thank you. There's still a lot to learn for me coming from a dynamic language like Ruby. On Mon, May 26, 2014 at 9:41 AM, Vladimir Matveev wrote: > > And hopefully in the future the regular expression library will be > updated to work on StrBuf instead of &str > This is very unlikely. See, you can go from `StrBuf` to `&str` without > allocation - `as_slice()` returns a "view" into the `StrBuf`. This is > very cheap operation. But you cannot go from `&str` to `StrBuf` > without allocation and copying, which are much more expensive than > slicing. Hence you should always try to use `&str` where possible, > only resorting to `StrBuf` when absolutely necessary (for example, > when you need to accumulate a string dynamically). All APIs should > also take `&str` when possible. > > 2014-05-26 11:31 GMT+04:00 Urban Hafner : > > Thanks guys, I now use "as_slice()" when necessary. And hopefully in the > > future the regular expression library will be updated to work on StrBuf > > instead of &str as this seems to be the main use case (read in file, run > > regexp on it). > > > > Urban > > > > > > On Mon, May 26, 2014 at 8:58 AM, Vladimir Matveev < > dpx.infinity at gmail.com> > > wrote: > >> > >> > My suspicion is that the automatic conversion will come back at some > >> > point, but I'm not sure. > >> > >> I think it will be possible to make `String` implement `Deref` > >> when DST land. Then it will be possible to convert from `String` to > >> `&str` using explicit reborrowing: > >> > >> let sgf_slice = &*sgf; > >> > >> I'm not sure this will be fully automatic when `String` is an > >> arbitrary actual argument to arbitrary function, however. > >> > >> 2014-05-26 10:36 GMT+04:00 Andrew Gallant : > >> > Try using `self.sgf.as_slice()` instead. > >> > > >> > The change is necessary, AFAIK, because `~str` would automatically be > >> > converted to a borrowed reference without having to explicitly call > the > >> > `as_slice` method. This doesn't happen for the StrBuf (and what is now > >> > String, I think) type. > >> > > >> > My suspicion is that the automatic conversion will come back at some > >> > point, but I'm not sure. > >> > > >> > - Andrew > >> > > >> > > >> > On Mon, May 26, 2014 at 2:32 AM, Urban Hafner < > contact at urbanhafner.com> > >> > wrote: > >> >> Hello there, > >> >> > >> >> I just updated the compiler (I use the git master branch) and now > when > >> >> I > >> >> read in a file I get a StrBuf instead of a ~str. That is easy enough > to > >> >> change, but how do I use regular expressions now? I have the > following > >> >> in my > >> >> code: > >> >> > >> >> let re = regex!(r"SZ\[(\d+)\]"); > >> >> let captures = re.captures(self.sgf).unwrap(); > >> >> > >> >> And it fails now because "self.sgf" is a StrBuf instead of a &str. > Do I > >> >> have > >> >> just a Rust compiler that is somewhere in between (i.e. not > everything > >> >> has > >> >> been changed to StrBuf) or is this intentional? And if so, what's the > >> >> best > >> >> way to use regular expressions now? > >> >> > >> >> Urban > >> >> -- > >> >> Freelancer > >> >> > >> >> Available for hire for Ruby, Ruby on Rails, and JavaScript projects > >> >> > >> >> More at http://urbanhafner.com > >> >> > >> >> _______________________________________________ > >> >> Rust-dev mailing list > >> >> Rust-dev at mozilla.org > >> >> https://mail.mozilla.org/listinfo/rust-dev > >> >> > >> > _______________________________________________ > >> > Rust-dev mailing list > >> > Rust-dev at mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > > > > > > > > > > -- > > Freelancer > > > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > > > More at http://urbanhafner.com > -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Mon May 26 00:46:41 2014 From: igor at mir2.org (Igor Bukanov) Date: Mon, 26 May 2014 09:46:41 +0200 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: Perhaps Rust should provide something like BorrowAsStr trait allowing to convert automatically to &str. &* is just too ugly... On 26 May 2014 08:58, Vladimir Matveev wrote: >> My suspicion is that the automatic conversion will come back at some >> point, but I'm not sure. > > I think it will be possible to make `String` implement `Deref` > when DST land. Then it will be possible to convert from `String` to > `&str` using explicit reborrowing: > > let sgf_slice = &*sgf; > > I'm not sure this will be fully automatic when `String` is an > arbitrary actual argument to arbitrary function, however. > > 2014-05-26 10:36 GMT+04:00 Andrew Gallant : >> Try using `self.sgf.as_slice()` instead. >> >> The change is necessary, AFAIK, because `~str` would automatically be >> converted to a borrowed reference without having to explicitly call the >> `as_slice` method. This doesn't happen for the StrBuf (and what is now >> String, I think) type. >> >> My suspicion is that the automatic conversion will come back at some >> point, but I'm not sure. >> >> - Andrew >> >> >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner wrote: >>> Hello there, >>> >>> I just updated the compiler (I use the git master branch) and now when I >>> read in a file I get a StrBuf instead of a ~str. That is easy enough to >>> change, but how do I use regular expressions now? I have the following in my >>> code: >>> >>> let re = regex!(r"SZ\[(\d+)\]"); >>> let captures = re.captures(self.sgf).unwrap(); >>> >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I have >>> just a Rust compiler that is somewhere in between (i.e. not everything has >>> been changed to StrBuf) or is this intentional? And if so, what's the best >>> way to use regular expressions now? >>> >>> Urban >>> -- >>> Freelancer >>> >>> Available for hire for Ruby, Ruby on Rails, and JavaScript projects >>> >>> More at http://urbanhafner.com >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From gsingh_2011 at yahoo.com Mon May 26 11:11:37 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Mon, 26 May 2014 11:11:37 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? Message-ID: Why does getopts::Matches::opts_present() take an array of heap allocated strings? Unless I'm missing something, it doesn't seem like it needs to: https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302 Currently, my code to use it looks like this: if matches.opts_present(["b".to_owned(), "x".to_owned(), "s".to_owned(), "w".to_owned()]) { /* */ } 1. Should the function be converted to take a list of borrowed strings? 2. Regardless of what this function should take as an argument, is the way I'm constructing a list of StrBufs the correct way to do it? It seems a bit verbose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Mon May 26 12:10:31 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Mon, 26 May 2014 15:10:31 -0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: I don't think any of these will be necessary. We already have a trait called `Str` (which is a bad name, btw) in the std::str module. This trait has exactly one method: `as_slice`. This trait is already implemented on both `&str` and `StrBuf` (the former in std::str, the latter in std::strbuf). All that would need to be done is to make the `captures` method generic on any type that implements `Str`, and then have it call the `as_slice` method before doing exactly what it does today. This extra operation would compile to a no-op for slices, and the usual cheap slice operation for heap-allocated strings. Then you would be able to call `re.captures(foo)` regardless of whether `foo` was a `&str` or a `StrBuf`. On Mon, May 26, 2014 at 3:46 AM, Igor Bukanov wrote: > Perhaps Rust should provide something like BorrowAsStr trait allowing > to convert automatically to &str. &* is just too ugly... > > On 26 May 2014 08:58, Vladimir Matveev wrote: > >> My suspicion is that the automatic conversion will come back at some > >> point, but I'm not sure. > > > > I think it will be possible to make `String` implement `Deref` > > when DST land. Then it will be possible to convert from `String` to > > `&str` using explicit reborrowing: > > > > let sgf_slice = &*sgf; > > > > I'm not sure this will be fully automatic when `String` is an > > arbitrary actual argument to arbitrary function, however. > > > > 2014-05-26 10:36 GMT+04:00 Andrew Gallant : > >> Try using `self.sgf.as_slice()` instead. > >> > >> The change is necessary, AFAIK, because `~str` would automatically be > >> converted to a borrowed reference without having to explicitly call the > >> `as_slice` method. This doesn't happen for the StrBuf (and what is now > >> String, I think) type. > >> > >> My suspicion is that the automatic conversion will come back at some > >> point, but I'm not sure. > >> > >> - Andrew > >> > >> > >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner > wrote: > >>> Hello there, > >>> > >>> I just updated the compiler (I use the git master branch) and now when > I > >>> read in a file I get a StrBuf instead of a ~str. That is easy enough to > >>> change, but how do I use regular expressions now? I have the following > in my > >>> code: > >>> > >>> let re = regex!(r"SZ\[(\d+)\]"); > >>> let captures = re.captures(self.sgf).unwrap(); > >>> > >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do > I have > >>> just a Rust compiler that is somewhere in between (i.e. not everything > has > >>> been changed to StrBuf) or is this intentional? And if so, what's the > best > >>> way to use regular expressions now? > >>> > >>> Urban > >>> -- > >>> Freelancer > >>> > >>> Available for hire for Ruby, Ruby on Rails, and JavaScript projects > >>> > >>> More at http://urbanhafner.com > >>> > >>> _______________________________________________ > >>> Rust-dev mailing list > >>> Rust-dev at mozilla.org > >>> https://mail.mozilla.org/listinfo/rust-dev > >>> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Mon May 26 12:16:53 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Mon, 26 May 2014 15:16:53 -0400 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: References: Message-ID: I'm not familiar with the getopts module, but on the surface that behavior sounds wrong to me. As for the verbosity of the repeated `to_owned` calls, this sounds like the perfect application for macros: #![feature(macro_rules)] macro_rules! owned( ($($e:expr),*) => ([$($e.to_owned()),*]) ) fn main() { let x = owned!["b", "c", "d"]; } On Mon, May 26, 2014 at 2:11 PM, Gulshan Singh wrote: > Why does getopts::Matches::opts_present() take an array of heap allocated > strings? Unless I'm missing something, it doesn't seem like it needs to: > https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302 > > Currently, my code to use it looks like this: > > if matches.opts_present(["b".to_owned(), "x".to_owned(), "s".to_owned(), > "w".to_owned()]) { /* */ } > > 1. Should the function be converted to take a list of borrowed strings? > 2. Regardless of what this function should take as an argument, is the way > I'm constructing a list of StrBufs the correct way to do it? It seems a bit > verbose. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon May 26 14:55:17 2014 From: kevin at sb.org (Kevin Ballard) Date: Mon, 26 May 2014 14:55:17 -0700 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: Message-ID: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> captures() should not take . That's unnecessary, it should just take &str as it does now. The use of taking is for taking things like &[S], where you want to take both &str and String (such as in the other post about getops()). For the time being, the answer is to use .as_slice() explicitly. The proposed Deref implementation post-DST has been talked about, and seems reasonably likely (though no decision has been made about it). The remaining bit to this is that, AFAIK, we don't auto-deref function arguments. We had auto-borrow of ~str into &str, but that doesn't apply to String. It has been suggested that maybe we should auto-deref+autoref function arguments such that String could then automatically coerce into &str, but this has had very little discussion so far. My suggestion is to wait until we have DST, then file an RFC suggesting the autoderef behavior for function arguments (and suggesting Deref on String if we haven't already done that). -Kevin On May 26, 2014, at 12:10 PM, Benjamin Striegel wrote: > I don't think any of these will be necessary. > > We already have a trait called `Str` (which is a bad name, btw) in the std::str module. This trait has exactly one method: `as_slice`. This trait is already implemented on both `&str` and `StrBuf` (the former in std::str, the latter in std::strbuf). All that would need to be done is to make the `captures` method generic on any type that implements `Str`, and then have it call the `as_slice` method before doing exactly what it does today. This extra operation would compile to a no-op for slices, and the usual cheap slice operation for heap-allocated strings. Then you would be able to call `re.captures(foo)` regardless of whether `foo` was a `&str` or a `StrBuf`. > > > On Mon, May 26, 2014 at 3:46 AM, Igor Bukanov wrote: > Perhaps Rust should provide something like BorrowAsStr trait allowing > to convert automatically to &str. &* is just too ugly... > > On 26 May 2014 08:58, Vladimir Matveev wrote: > >> My suspicion is that the automatic conversion will come back at some > >> point, but I'm not sure. > > > > I think it will be possible to make `String` implement `Deref` > > when DST land. Then it will be possible to convert from `String` to > > `&str` using explicit reborrowing: > > > > let sgf_slice = &*sgf; > > > > I'm not sure this will be fully automatic when `String` is an > > arbitrary actual argument to arbitrary function, however. > > > > 2014-05-26 10:36 GMT+04:00 Andrew Gallant : > >> Try using `self.sgf.as_slice()` instead. > >> > >> The change is necessary, AFAIK, because `~str` would automatically be > >> converted to a borrowed reference without having to explicitly call the > >> `as_slice` method. This doesn't happen for the StrBuf (and what is now > >> String, I think) type. > >> > >> My suspicion is that the automatic conversion will come back at some > >> point, but I'm not sure. > >> > >> - Andrew > >> > >> > >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner wrote: > >>> Hello there, > >>> > >>> I just updated the compiler (I use the git master branch) and now when I > >>> read in a file I get a StrBuf instead of a ~str. That is easy enough to > >>> change, but how do I use regular expressions now? I have the following in my > >>> code: > >>> > >>> let re = regex!(r"SZ\[(\d+)\]"); > >>> let captures = re.captures(self.sgf).unwrap(); > >>> > >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do I have > >>> just a Rust compiler that is somewhere in between (i.e. not everything has > >>> been changed to StrBuf) or is this intentional? And if so, what's the best > >>> way to use regular expressions now? > >>> > >>> Urban > >>> -- > >>> Freelancer > >>> > >>> Available for hire for Ruby, Ruby on Rails, and JavaScript projects > >>> > >>> More at http://urbanhafner.com > >>> > >>> _______________________________________________ > >>> Rust-dev mailing list > >>> Rust-dev at mozilla.org > >>> https://mail.mozilla.org/listinfo/rust-dev > >>> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon May 26 14:56:01 2014 From: kevin at sb.org (Kevin Ballard) Date: Mon, 26 May 2014 14:56:01 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: References: Message-ID: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> I think getopts has an old API. All the methods that take &[String] should probably be rewritten to be generic with and take &[S] instead, which will allow taking either a slice of Strings or a slice of &str's. -Kevin On May 26, 2014, at 12:16 PM, Benjamin Striegel wrote: > I'm not familiar with the getopts module, but on the surface that behavior sounds wrong to me. > > As for the verbosity of the repeated `to_owned` calls, this sounds like the perfect application for macros: > > #![feature(macro_rules)] > > macro_rules! owned( > ($($e:expr),*) => ([$($e.to_owned()),*]) > ) > > fn main() { > let x = owned!["b", "c", "d"]; > } > > > On Mon, May 26, 2014 at 2:11 PM, Gulshan Singh wrote: > Why does getopts::Matches::opts_present() take an array of heap allocated strings? Unless I'm missing something, it doesn't seem like it needs to: https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302 > > Currently, my code to use it looks like this: > > if matches.opts_present(["b".to_owned(), "x".to_owned(), "s".to_owned(), "w".to_owned()]) { /* */ } > > 1. Should the function be converted to take a list of borrowed strings? > 2. Regardless of what this function should take as an argument, is the way I'm constructing a list of StrBufs the correct way to do it? It seems a bit verbose. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From smcarthur at mozilla.com Mon May 26 16:54:14 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Mon, 26 May 2014 16:54:14 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> References: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> Message-ID: Considering many options would be single characters, it'd seem nice to also be able to pass a slice of chars. It doesn't look like char implements Str. getopts could define a new trait, Text or something, for all 3... On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: > I think getopts has an old API. All the methods that take &[String] should > probably be rewritten to be generic with and take &[S] instead, > which will allow taking either a slice of Strings or a slice of &str's. > > -Kevin > > On May 26, 2014, at 12:16 PM, Benjamin Striegel > wrote: > > I'm not familiar with the getopts module, but on the surface that behavior > sounds wrong to me. > > As for the verbosity of the repeated `to_owned` calls, this sounds like > the perfect application for macros: > > #![feature(macro_rules)] > > macro_rules! owned( > ($($e:expr),*) => ([$($e.to_owned()),*]) > ) > > fn main() { > let x = owned!["b", "c", "d"]; > } > > > On Mon, May 26, 2014 at 2:11 PM, Gulshan Singh wrote: > >> Why does getopts::Matches::opts_present() take an array of heap >> allocated strings? Unless I'm missing something, it doesn't seem like it >> needs to: >> https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302 >> >> Currently, my code to use it looks like this: >> >> if matches.opts_present(["b".to_owned(), "x".to_owned(), "s".to_owned(), >> "w".to_owned()]) { /* */ } >> >> 1. Should the function be converted to take a list of borrowed strings? >> 2. Regardless of what this function should take as an argument, is the >> way I'm constructing a list of StrBufs the correct way to do it? It seems a >> bit verbose. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon May 26 17:03:28 2014 From: kevin at sb.org (Kevin Ballard) Date: Mon, 26 May 2014 17:03:28 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: References: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> Message-ID: How is that any better than just using strings? ["a", "b", "c"] is no more typing than ['a', 'b', 'c'], but it doesn't require defining new traits. -Kevin On May 26, 2014, at 4:54 PM, Sean McArthur wrote: > Considering many options would be single characters, it'd seem nice to also be able to pass a slice of chars. It doesn't look like char implements Str. getopts could define a new trait, Text or something, for all 3... > > > On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: > I think getopts has an old API. All the methods that take &[String] should probably be rewritten to be generic with and take &[S] instead, which will allow taking either a slice of Strings or a slice of &str's. > > -Kevin > > On May 26, 2014, at 12:16 PM, Benjamin Striegel wrote: > >> I'm not familiar with the getopts module, but on the surface that behavior sounds wrong to me. >> >> As for the verbosity of the repeated `to_owned` calls, this sounds like the perfect application for macros: >> >> #![feature(macro_rules)] >> >> macro_rules! owned( >> ($($e:expr),*) => ([$($e.to_owned()),*]) >> ) >> >> fn main() { >> let x = owned!["b", "c", "d"]; >> } >> >> >> On Mon, May 26, 2014 at 2:11 PM, Gulshan Singh wrote: >> Why does getopts::Matches::opts_present() take an array of heap allocated strings? Unless I'm missing something, it doesn't seem like it needs to: https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302 >> >> Currently, my code to use it looks like this: >> >> if matches.opts_present(["b".to_owned(), "x".to_owned(), "s".to_owned(), "w".to_owned()]) { /* */ } >> >> 1. Should the function be converted to take a list of borrowed strings? >> 2. Regardless of what this function should take as an argument, is the way I'm constructing a list of StrBufs the correct way to do it? It seems a bit verbose. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon May 26 18:38:40 2014 From: kevin at sb.org (Kevin Ballard) Date: Mon, 26 May 2014 18:38:40 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: References: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> Message-ID: <94454F95-47F2-4A8B-AFC6-4BDEE87B8469@sb.org> Sure, that seems like a pretty easy job to tackle. You should audit the whole getopts API to see where it uses String inappropriately. Any &[String] parameters should probably be &[S] where , and any bare String parameters (if any) should probably be &str. -Kevin On May 26, 2014, at 6:29 PM, Gulshan Singh wrote: > On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: > All the methods that take &[String] should probably be rewritten to be generic with and take &[S] instead, which will allow taking either a slice of Strings or a slice of &str's. > > I've been wanting to contribute to Rust for a while. This seems like the right thing to do and I don't think it's a hard change. Should I go ahead and make it? > > -- > Gulshan Singh > University of Michigan, Class of 2015 > College of Engineering, Computer Science Major > gulshan at umich.edu | 248.961.6317 > Alternate E-mail: gsingh2011 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnfagnan at gmail.com Mon May 26 18:57:15 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Mon, 26 May 2014 19:57:15 -0600 Subject: [rust-dev] Glob crate? Message-ID: Writing it here to gauge an interest of the community for a glob crate. If it seems people are liking the idea, I'll write an RFC for it and send a PR. I'm guessing the majority of the folks here already know what it is, as it's pretty universal and used heavily in unix-based environments. (One *could* use a simple regex, but the interface wouldn't be the most ideal) Something like: ```rust use glob::Glob; fn main() { let fn globber = Glob::new(r"foo/**/*.rs"); let list = vec!["foo/hello.rs", "foo/foo2/woot.rs"]; match globber.match(list.get(0)) { // ... } // Or you could match all and you would get a Result> where // the contents of the vector are only the matched occurrences. globber.match_all(list); } ``` Thoughts? -- Daniel Fagnan Titan Analytics Inc. www.titananalytics.com M: (780) 983-4997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Mon May 26 19:07:59 2014 From: sfackler at gmail.com (Steven Fackler) Date: Mon, 26 May 2014 19:07:59 -0700 Subject: [rust-dev] Glob crate? In-Reply-To: References: Message-ID: A glob crate like this one? https://github.com/mozilla/rust/blob/master/src/libglob/lib.rs Steven Fackler On Mon, May 26, 2014 at 6:57 PM, Daniel Fagnan wrote: > Writing it here to gauge an interest of the community for a glob crate. If > it seems people are liking the idea, I'll write an RFC for it and send a PR. > > I'm guessing the majority of the folks here already know what it is, as > it's pretty universal and used heavily in unix-based environments. > > (One *could* use a simple regex, but the interface wouldn't be the most > ideal) > > Something like: > > ```rust > use glob::Glob; > > fn main() { > let fn globber = Glob::new(r"foo/**/*.rs"); > > let list = vec!["foo/hello.rs", "foo/foo2/woot.rs"]; > > match globber.match(list.get(0)) { > // ... > } > > // Or you could match all and you would get a Result> where > // the contents of the vector are only the matched occurrences. > globber.match_all(list); > } > ``` > > Thoughts? > > -- > Daniel Fagnan > Titan Analytics Inc. > www.titananalytics.com > M: (780) 983-4997 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at urbanhafner.com Mon May 26 22:21:04 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Tue, 27 May 2014 07:21:04 +0200 Subject: [rust-dev] No stdout in test builds? Message-ID: Hey everyone, still me, the Rust newbie ;) Coming from Ruby I use TDD quite heavily. For my toy rust project I've setup my Makefile in such a way that it first compiles and runs a test build before compiling the real executable. When trying to debug a failing test I tried putting println! statements into the code under test. Apart from the fact that I should probably start using a debugger instead I'd like to know why the output doesn't show up. Does the test runner swallow it? Is there a way to write to stdout or stderr during the test runs? Urban -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Mon May 26 22:23:53 2014 From: alex at crichton.co (Alex Crichton) Date: Mon, 26 May 2014 22:23:53 -0700 Subject: [rust-dev] No stdout in test builds? In-Reply-To: References: Message-ID: The test runner captures stdout by default and prints it at the end of the test run, but only if the test failed. This is intended to turn down the noise of successful tests, especially the failing ones. If you pass the --nocapture option to the test binary, it will disable this behavior and println will print to the terminal by default. On Mon, May 26, 2014 at 10:21 PM, Urban Hafner wrote: > Hey everyone, > > still me, the Rust newbie ;) > > Coming from Ruby I use TDD quite heavily. For my toy rust project I've setup > my Makefile in such a way that it first compiles and runs a test build > before compiling the real executable. When trying to debug a failing test I > tried putting println! statements into the code under test. Apart from the > fact that I should probably start using a debugger instead I'd like to know > why the output doesn't show up. Does the test runner swallow it? Is there a > way to write to stdout or stderr during the test runs? > > Urban > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From contact at urbanhafner.com Mon May 26 22:36:16 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Tue, 27 May 2014 07:36:16 +0200 Subject: [rust-dev] No stdout in test builds? In-Reply-To: References: Message-ID: Thank you Alex! On Tue, May 27, 2014 at 7:23 AM, Alex Crichton wrote: > The test runner captures stdout by default and prints it at the end of > the test run, but only if the test failed. This is intended to turn > down the noise of successful tests, especially the failing ones. > > If you pass the --nocapture option to the test binary, it will disable > this behavior and println will print to the terminal by default. > > On Mon, May 26, 2014 at 10:21 PM, Urban Hafner > wrote: > > Hey everyone, > > > > still me, the Rust newbie ;) > > > > Coming from Ruby I use TDD quite heavily. For my toy rust project I've > setup > > my Makefile in such a way that it first compiles and runs a test build > > before compiling the real executable. When trying to debug a failing > test I > > tried putting println! statements into the code under test. Apart from > the > > fact that I should probably start using a debugger instead I'd like to > know > > why the output doesn't show up. Does the test runner swallow it? Is > there a > > way to write to stdout or stderr during the test runs? > > > > Urban > > -- > > Freelancer > > > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > > > More at http://urbanhafner.com > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Tue May 27 03:24:20 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 27 May 2014 13:24:20 +0300 Subject: [rust-dev] include_sized_bin!(type, "file") Message-ID: Could we add to the standard library a macro, say 'include_sized_bin', that would be similar to std::macros::builtin::include_bin except that you'd also give it a sized type to return (instead of a slice of u8's) and you'd get a compile time error if the size of the file is different from the size of the type you specified. From ben.striegel at gmail.com Tue May 27 06:05:17 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 27 May 2014 09:05:17 -0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> References: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> Message-ID: > The use of taking is for taking things like &[S], where you want to take both &str and String (such as in the other post about getops()). I wouldn't be bothered with leaving the API as-is, but I don't understand where this guideline is coming from. Can you elaborate? On Mon, May 26, 2014 at 5:55 PM, Kevin Ballard wrote: > captures() should not take . That's unnecessary, it should just > take &str as it does now. The use of taking is for taking things > like &[S], where you want to take both &str and String (such as in the > other post about getops()). > > For the time being, the answer is to use .as_slice() explicitly. The > proposed Deref implementation post-DST has been talked about, and seems > reasonably likely (though no decision has been made about it). > > The remaining bit to this is that, AFAIK, we don't auto-deref function > arguments. We had auto-borrow of ~str into &str, but that doesn't apply to > String. It has been suggested that maybe we should auto-deref+autoref > function arguments such that String could then automatically coerce into > &str, but this has had very little discussion so far. > > My suggestion is to wait until we have DST, then file an RFC suggesting > the autoderef behavior for function arguments (and suggesting Deref on > String if we haven't already done that). > > -Kevin > > On May 26, 2014, at 12:10 PM, Benjamin Striegel > wrote: > > I don't think any of these will be necessary. > > We already have a trait called `Str` (which is a bad name, btw) in the > std::str module. This trait has exactly one method: `as_slice`. This trait > is already implemented on both `&str` and `StrBuf` (the former in std::str, > the latter in std::strbuf). All that would need to be done is to make the > `captures` method generic on any type that implements `Str`, and then have > it call the `as_slice` method before doing exactly what it does today. This > extra operation would compile to a no-op for slices, and the usual cheap > slice operation for heap-allocated strings. Then you would be able to call > `re.captures(foo)` regardless of whether `foo` was a `&str` or a `StrBuf`. > > > On Mon, May 26, 2014 at 3:46 AM, Igor Bukanov wrote: > >> Perhaps Rust should provide something like BorrowAsStr trait allowing >> to convert automatically to &str. &* is just too ugly... >> >> On 26 May 2014 08:58, Vladimir Matveev wrote: >> >> My suspicion is that the automatic conversion will come back at some >> >> point, but I'm not sure. >> > >> > I think it will be possible to make `String` implement `Deref` >> > when DST land. Then it will be possible to convert from `String` to >> > `&str` using explicit reborrowing: >> > >> > let sgf_slice = &*sgf; >> > >> > I'm not sure this will be fully automatic when `String` is an >> > arbitrary actual argument to arbitrary function, however. >> > >> > 2014-05-26 10:36 GMT+04:00 Andrew Gallant : >> >> Try using `self.sgf.as_slice()` instead. >> >> >> >> The change is necessary, AFAIK, because `~str` would automatically be >> >> converted to a borrowed reference without having to explicitly call the >> >> `as_slice` method. This doesn't happen for the StrBuf (and what is now >> >> String, I think) type. >> >> >> >> My suspicion is that the automatic conversion will come back at some >> >> point, but I'm not sure. >> >> >> >> - Andrew >> >> >> >> >> >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner >> wrote: >> >>> Hello there, >> >>> >> >>> I just updated the compiler (I use the git master branch) and now >> when I >> >>> read in a file I get a StrBuf instead of a ~str. That is easy enough >> to >> >>> change, but how do I use regular expressions now? I have the >> following in my >> >>> code: >> >>> >> >>> let re = regex!(r"SZ\[(\d+)\]"); >> >>> let captures = re.captures(self.sgf).unwrap(); >> >>> >> >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do >> I have >> >>> just a Rust compiler that is somewhere in between (i.e. not >> everything has >> >>> been changed to StrBuf) or is this intentional? And if so, what's the >> best >> >>> way to use regular expressions now? >> >>> >> >>> Urban >> >>> -- >> >>> Freelancer >> >>> >> >>> Available for hire for Ruby, Ruby on Rails, and JavaScript projects >> >>> >> >>> More at http://urbanhafner.com >> >>> >> >>> _______________________________________________ >> >>> Rust-dev mailing list >> >>> Rust-dev at mozilla.org >> >>> https://mail.mozilla.org/listinfo/rust-dev >> >>> >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Tue May 27 09:50:09 2014 From: kevin at sb.org (Kevin Ballard) Date: Tue, 27 May 2014 09:50:09 -0700 Subject: [rust-dev] include_sized_bin!(type, "file") In-Reply-To: References: Message-ID: <08145357-BC0C-4471-94CA-1F13D83589B1@sb.org> What's the use-case for this? -Kevin On May 27, 2014, at 3:24 AM, Tommi wrote: > Could we add to the standard library a macro, say 'include_sized_bin', that would be similar to std::macros::builtin::include_bin except that you'd also give it a sized type to return (instead of a slice of u8's) and you'd get a compile time error if the size of the file is different from the size of the type you specified. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From kevin at sb.org Tue May 27 10:01:22 2014 From: kevin at sb.org (Kevin Ballard) Date: Tue, 27 May 2014 10:01:22 -0700 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> Message-ID: <87F3C73E-95A4-4838-9C56-A87ED675BA24@sb.org> On May 27, 2014, at 6:05 AM, Benjamin Striegel wrote: > > The use of taking is for taking things like &[S], where you want to take both &str and String (such as in the other post about getops()). > > I wouldn't be bothered with leaving the API as-is, but I don't understand where this guideline is coming from. Can you elaborate? I don't know if there's any authoritative source for this, but it's been suggested in the past for other APIs. The basic issue is that &[String] cannot be freely converted to &[&str]; you need to allocate a new Vec for that. So if you have a &[String] and try to call an API that takes a &[&str] then you're doing extra work just to satisfy the type system. But the function in question doesn't actually need &[&str], it just needs a slice of things it can convert to &str. So if it takes &[S] then you can hand it your &[String] without conversion, or you can hand it a &[&str], and it will work with both. This doesn't necessarily mean you need to use &[S] everywhere. But it's a nice thing to do if you think about it. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Tue May 27 10:11:25 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Tue, 27 May 2014 20:11:25 +0300 Subject: [rust-dev] include_sized_bin!(type, "file") In-Reply-To: <08145357-BC0C-4471-94CA-1F13D83589B1@sb.org> References: <08145357-BC0C-4471-94CA-1F13D83589B1@sb.org> Message-ID: <3E54FCA1-E5F4-435D-A454-D9BA469378A3@icloud.com> I would use it for large, immutable, static lookup tables. I could use 'include_bin' and wrap any use of it in a 'std::mem::transmute', but I'd rather not. Also, I'd appreciate the sanity check for knowing the file size matches the size of the lookup table's type. E.g. static lut: [[MyStruct, ..1000], ..1000] = include_sized_bin!([[MyStruct, ..1000], ..1000], "lut_stuff.bin"); I've tried initializing my large lookup table using the normal fixed size vector literal syntax, but it killed the compilation time and my computer ran out of memory. > On 27 May 2014, at 19:50, Kevin Ballard wrote: > > What's the use-case for this? > > -Kevin > >> On May 27, 2014, at 3:24 AM, Tommi wrote: >> >> Could we add to the standard library a macro, say 'include_sized_bin', that would be similar to std::macros::builtin::include_bin except that you'd also give it a sized type to return (instead of a slice of u8's) and you'd get a compile time error if the size of the file is different from the size of the type you specified. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > From kevin at sb.org Tue May 27 10:19:02 2014 From: kevin at sb.org (Kevin Ballard) Date: Tue, 27 May 2014 10:19:02 -0700 Subject: [rust-dev] include_sized_bin!(type, "file") In-Reply-To: <3E54FCA1-E5F4-435D-A454-D9BA469378A3@icloud.com> References: <08145357-BC0C-4471-94CA-1F13D83589B1@sb.org> <3E54FCA1-E5F4-435D-A454-D9BA469378A3@icloud.com> Message-ID: Apparently include_bin!() returns a "binary" literal, not an actual slice. This eventually gets treated as a &[u8] during type-checking, but it's apparently treated specially by trans. Given this, I think creating an include_sized_bin!() would require changing LitBinary to include an optional size, and changing typeck to treat it as an array instead of a slice when it has a size. Certainly doable, but not quite as trivial as just defining a new syntax extension. I also wonder if perhaps this would be better done as just a variant of include_bin!(), e.g. `include_bin!("lut_stuff.bin", 1000)` or `include_bin!("lut_stuff.bin", size=1000)`. -Kevin On May 27, 2014, at 10:11 AM, Tommi Tissari wrote: > I would use it for large, immutable, static lookup tables. I could use 'include_bin' and wrap any use of it in a 'std::mem::transmute', but I'd rather not. Also, I'd appreciate the sanity check for knowing the file size matches the size of the lookup table's type. E.g. > > static lut: [[MyStruct, ..1000], ..1000] = include_sized_bin!([[MyStruct, ..1000], ..1000], "lut_stuff.bin"); > > I've tried initializing my large lookup table using the normal fixed size vector literal syntax, but it killed the compilation time and my computer ran out of memory. > >> On 27 May 2014, at 19:50, Kevin Ballard wrote: >> >> What's the use-case for this? >> >> -Kevin >> >>> On May 27, 2014, at 3:24 AM, Tommi wrote: >>> >>> Could we add to the standard library a macro, say 'include_sized_bin', that would be similar to std::macros::builtin::include_bin except that you'd also give it a sized type to return (instead of a slice of u8's) and you'd get a compile time error if the size of the file is different from the size of the type you specified. >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> From rusty.gates at icloud.com Tue May 27 10:27:39 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 27 May 2014 20:27:39 +0300 Subject: [rust-dev] box ref foo? Message-ID: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> What is the meaning of this 'box ref foo' syntax found in the tutorial over at __http://doc.rust-lang.org/tutorial.html#references (Sorry for uglifying the link, my posts seem to get flagged as spam if they contain links) In short, it's: enum Shape { Sphere(Box) } let shape = Sphere(box 1.0f32); let r = match shape { Sphere(box ref radius) => *radius }; I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". That doesn't make sense to me in the context of 'box ref radius'. From oleg at eterevsky.com Tue May 27 10:29:46 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Tue, 27 May 2014 10:29:46 -0700 Subject: [rust-dev] box ref foo? In-Reply-To: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> References: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> Message-ID: As far as I understand (I'm a newbie too), it means that 'radius' is the reference to the value in the box. On Tue, May 27, 2014 at 10:27 AM, Tommi wrote: > What is the meaning of this 'box ref foo' syntax found in the tutorial > over at __http://doc.rust-lang.org/tutorial.html#references > > (Sorry for uglifying the link, my posts seem to get flagged as spam if > they contain links) > > In short, it's: > > enum Shape { Sphere(Box) } > > let shape = Sphere(box 1.0f32); > let r = match shape { > Sphere(box ref radius) => *radius > }; > > I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". > That doesn't make sense to me in the context of 'box ref radius'. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Tue May 27 10:31:40 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Tue, 27 May 2014 18:31:40 +0100 Subject: [rust-dev] box ref foo? In-Reply-To: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> References: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> Message-ID: <5384CBFC.1060909@exyr.org> On 27/05/2014 18:27, Tommi wrote: > What is the meaning of this 'box ref foo' syntax found in the tutorial over at __http://doc.rust-lang.org/tutorial.html#references > > (Sorry for uglifying the link, my posts seem to get flagged as spam if they contain links) > > In short, it's: > > enum Shape { Sphere(Box) } > > let shape = Sphere(box 1.0f32); > let r = match shape { > Sphere(box ref radius) => *radius > }; > > I thought the 'box' keyword meant: "allocate on heap and wrap into a > Box". That doesn't make sense to me in the context of 'box ref > radius'. That?s what it means in an expression, but the arms of a 'match' statement start with patterns, not expressions. In a pattern, the 'box' keyword means deconstruct a Box type to access the T inside. The 'ref' keyword (which can be used without 'box') means to take a &T reference rather than move the value. -- Simon Sapin From explodingmind at gmail.com Tue May 27 10:39:48 2014 From: explodingmind at gmail.com (Ian Daniher) Date: Tue, 27 May 2014 13:39:48 -0400 Subject: [rust-dev] flowgraph-to-Rust compiler, written (mostly) in Rust Message-ID: Hey All, Writing to share my project of late, an environment for describing and executing connected networks of processes. I've used it to build discrete-time filters, oscillators, RF modems, and more. Preliminary documentation is up at https://github.com/itdaniher/ratpak/blob/master/readme.mkd, and for the stdlib, https://github.com/ade-ma/LibRedio/blob/master/README.mkd. There are example flowgraphs rendered via graphviz, at https://github.com/itdaniher/ratpak/blob/master/clips/biquaddf2.png and https://github.com/itdaniher/ratpak/blob/master/clips/digitalWaveguide.png. If you've touched Faust, PureData, GNURadio, LabVIEW, or Simulink, the concepts will be familiar - this is just a whole lot lighter and built in Rust! If there's sufficient interest, I'll pose some pointed questions to the list - right now I'm directly using libsyntax to build up an AST, hopefully there's a better way. Best! -- Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Tue May 27 10:42:03 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Tue, 27 May 2014 20:42:03 +0300 Subject: [rust-dev] box ref foo? In-Reply-To: References: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> Message-ID: <83D2C9CB-544A-4A81-9A0B-945F5306BC2C@icloud.com> Thanks. I had failed to realize that 'ref radius' would make 'radius' a &Box value. > On 27 May 2014, at 20:29, Oleg Eterevsky wrote: > > As far as I understand (I'm a newbie too), it means that 'radius' is the reference to the value in the box. > > >> On Tue, May 27, 2014 at 10:27 AM, Tommi wrote: >> What is the meaning of this 'box ref foo' syntax found in the tutorial over at __http://doc.rust-lang.org/tutorial.html#references >> >> (Sorry for uglifying the link, my posts seem to get flagged as spam if they contain links) >> >> In short, it's: >> >> enum Shape { Sphere(Box) } >> >> let shape = Sphere(box 1.0f32); >> let r = match shape { >> Sphere(box ref radius) => *radius >> }; >> >> I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". That doesn't make sense to me in the context of 'box ref radius'. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Tue May 27 10:43:12 2014 From: kevin at sb.org (Kevin Ballard) Date: Tue, 27 May 2014 10:43:12 -0700 Subject: [rust-dev] box ref foo? In-Reply-To: <83D2C9CB-544A-4A81-9A0B-945F5306BC2C@icloud.com> References: <38A2DB42-91F6-443F-871D-580BD53A2385@icloud.com> <83D2C9CB-544A-4A81-9A0B-945F5306BC2C@icloud.com> Message-ID: It actually makes radius a &f32. -Kevin On May 27, 2014, at 10:42 AM, Tommi Tissari wrote: > Thanks. I had failed to realize that 'ref radius' would make 'radius' a &Box value. > > > On 27 May 2014, at 20:29, Oleg Eterevsky wrote: > >> As far as I understand (I'm a newbie too), it means that 'radius' is the reference to the value in the box. >> >> >> On Tue, May 27, 2014 at 10:27 AM, Tommi wrote: >> What is the meaning of this 'box ref foo' syntax found in the tutorial over at __http://doc.rust-lang.org/tutorial.html#references >> >> (Sorry for uglifying the link, my posts seem to get flagged as spam if they contain links) >> >> In short, it's: >> >> enum Shape { Sphere(Box) } >> >> let shape = Sphere(box 1.0f32); >> let r = match shape { >> Sphere(box ref radius) => *radius >> }; >> >> I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". That doesn't make sense to me in the context of 'box ref radius'. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Tue May 27 13:55:31 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 27 May 2014 16:55:31 -0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: <87F3C73E-95A4-4838-9C56-A87ED675BA24@sb.org> References: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> <87F3C73E-95A4-4838-9C56-A87ED675BA24@sb.org> Message-ID: What I was specifically curious about is why you seem to be against the usage of the `Str` trait as a bound on the argument to the `captures` method. On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard wrote: > On May 27, 2014, at 6:05 AM, Benjamin Striegel > wrote: > > > The use of taking is for taking things like &[S], where you > want to take both &str and String (such as in the other post about > getops()). > > I wouldn't be bothered with leaving the API as-is, but I don't understand > where this guideline is coming from. Can you elaborate? > > > I don't know if there's any authoritative source for this, but it's been > suggested in the past for other APIs. The basic issue is that &[String] > cannot be freely converted to &[&str]; you need to allocate a new Vec for > that. So if you have a &[String] and try to call an API that takes a > &[&str] then you're doing extra work just to satisfy the type system. But > the function in question doesn't actually need &[&str], it just needs a > slice of things it can convert to &str. So if it takes &[S] then > you can hand it your &[String] without conversion, or you can hand it a > &[&str], and it will work with both. > > This doesn't necessarily mean you need to use &[S] everywhere. > But it's a nice thing to do if you think about it. > > -Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsingh_2011 at yahoo.com Tue May 27 15:11:37 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Tue, 27 May 2014 15:11:37 -0700 Subject: [rust-dev] 3 SF events in June: a Dinner, Game Tech Meetup, and a Spinning Trianglthon In-Reply-To: References: <537DBAD9.7090309@seld.be> Message-ID: Is there anyone who's going to any of these events that will be passing by Menlo Park and would be willing to give a fellow Rust developer a ride? On Sat, May 24, 2014 at 8:03 PM, Tom Park wrote: > > https://air.mozilla.org/search/?q=rust+meetup > > Removing "meetup" from that search might be a little better: > https://air.mozilla.org/search/?q=rust > > Specifically, it yields the Nov 2013 Rust meetup (which includes Yehuda > Katz's talk about calling Rust from Ruby via C FFI): > https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ > > I mention this because about a month ago on #rust IRC, someone was looking > for that particular talk but having trouble finding it because he was using > the "meetup" keyword. > > > > On Thu, May 22, 2014 at 1:52 AM, Jordi Boggiano wrote: > >> Here is a link to watch all past (and upcoming) rust meetups for those >> that can't be there in person. It took me 5min to dig it up again so I >> thought I'd share. >> >> https://air.mozilla.org/search/?q=rust+meetup >> >> Cheers >> >> -- >> Jordi Boggiano >> @seldaek - http://nelm.io/jordi >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsingh2011 at gmail.com Mon May 26 18:29:48 2014 From: gsingh2011 at gmail.com (Gulshan Singh) Date: Mon, 26 May 2014 18:29:48 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> References: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> Message-ID: On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: > All the methods that take &[String] should probably be rewritten to be > generic with and take &[S] instead, which will allow taking either > a slice of Strings or a slice of &str's. I've been wanting to contribute to Rust for a while. This seems like the right thing to do and I don't think it's a hard change. Should I go ahead and make it? -- Gulshan Singh University of Michigan, Class of 2015 College of Engineering, Computer Science Major gulshan at umich.edu | 248.961.6317 Alternate E-mail: gsingh2011 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Tue May 27 19:17:21 2014 From: kevin at sb.org (Kevin Ballard) Date: Tue, 27 May 2014 19:17:21 -0700 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> <87F3C73E-95A4-4838-9C56-A87ED675BA24@sb.org> Message-ID: On May 27, 2014, at 1:55 PM, Benjamin Striegel wrote: > What I was specifically curious about is why you seem to be against the usage of the `Str` trait as a bound on the argument to the `captures` method. It adds unnecessary complexity, bloats the crate metadata with the function AST, and complicates the type signature, with no real benefit. The only thing that taking `` for an `arg: S` argument does is allowing a String to be passed without calling .as_slice(). But the solution moves the String into the function, rather than slicing it, which means the calling function gives up ownership of the String. This is rarely desired, and is likely to be confusing. We're also almost certainly going to implement Deref on String post-DST, which means slicing a String is a simple as &*foo. And there's a good chance we'll add auto-deref+autoref for function arguments, specifically so String will auto-slice to &str the same way ~str used to (although someone still needs to write up an RFC for this). -Kevin > On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard wrote: > On May 27, 2014, at 6:05 AM, Benjamin Striegel wrote: > >> > The use of taking is for taking things like &[S], where you want to take both &str and String (such as in the other post about getops()). >> >> I wouldn't be bothered with leaving the API as-is, but I don't understand where this guideline is coming from. Can you elaborate? > > I don't know if there's any authoritative source for this, but it's been suggested in the past for other APIs. The basic issue is that &[String] cannot be freely converted to &[&str]; you need to allocate a new Vec for that. So if you have a &[String] and try to call an API that takes a &[&str] then you're doing extra work just to satisfy the type system. But the function in question doesn't actually need &[&str], it just needs a slice of things it can convert to &str. So if it takes &[S] then you can hand it your &[String] without conversion, or you can hand it a &[&str], and it will work with both. > > This doesn't necessarily mean you need to use &[S] everywhere. But it's a nice thing to do if you think about it. > > -Kevin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Tue May 27 09:50:53 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 27 May 2014 19:50:53 +0300 Subject: [rust-dev] The meaning of 'box ref foo' ? Message-ID: What is the meaning of this 'box ref foo' syntax found in the tutorial over at http://doc.rust-lang.org/tutorial.html#references In short, it's: enum Shape { Sphere(Box) } let shape = Sphere(box 1.0f32); let r = match shape { Sphere(box ref radius) => *radius }; I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". That doesn't make sense to me in the context of 'box ref radius'. From corey at octayn.net Tue May 27 21:23:46 2014 From: corey at octayn.net (Corey Richardson) Date: Tue, 27 May 2014 21:23:46 -0700 Subject: [rust-dev] The meaning of 'box ref foo' ? In-Reply-To: References: Message-ID: As with most things in Rust, in a pattern, a keyword means the *opposite* of its normal meaning. So where `box e` in an expression will box up the result of `e`, `box p` in a pattern will unbox `p`. On Tue, May 27, 2014 at 9:50 AM, Tommi wrote: > What is the meaning of this 'box ref foo' syntax found in the tutorial over at http://doc.rust-lang.org/tutorial.html#references > > In short, it's: > > enum Shape { Sphere(Box) } > > let shape = Sphere(box 1.0f32); > let r = match shape { > Sphere(box ref radius) => *radius > }; > > I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". That doesn't make sense to me in the context of 'box ref radius'. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From igor at mir2.org Tue May 27 23:19:31 2014 From: igor at mir2.org (Igor Bukanov) Date: Wed, 28 May 2014 08:19:31 +0200 Subject: [rust-dev] The meaning of 'box ref foo' ? In-Reply-To: References: Message-ID: I wonder if the idea of using ref by default in patterns for Copyless types has being considered? The need to move on pattern match should be infrequent. So it is better to use a special syntax for that case skipping box ref and similar in most of the code. On 28 May 2014 06:23, Corey Richardson wrote: > As with most things in Rust, in a pattern, a keyword means the > *opposite* of its normal meaning. So where `box e` in an expression > will box up the result of `e`, `box p` in a pattern will unbox `p`. > > On Tue, May 27, 2014 at 9:50 AM, Tommi wrote: >> What is the meaning of this 'box ref foo' syntax found in the tutorial over at http://doc.rust-lang.org/tutorial.html#references >> >> In short, it's: >> >> enum Shape { Sphere(Box) } >> >> let shape = Sphere(box 1.0f32); >> let r = match shape { >> Sphere(box ref radius) => *radius >> }; >> >> I thought the 'box' keyword meant: "allocate on heap and wrap into a Box". That doesn't make sense to me in the context of 'box ref radius'. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > -- > http://octayn.net/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From hallimanearavind at gmail.com Wed May 28 02:10:47 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Wed, 28 May 2014 14:40:47 +0530 Subject: [rust-dev] How to find Unicode string length in rustlang Message-ID: Hi, How to find number of characters in a string? Following example returns byte count instead of number of characters. use std::string::String; fn main() { let unicode_str = String::from_str("?"); let ascii_str = String::from_str("a"); println!("unicode str: {}, ascii str: {}", unicode_str.len(), ascii_str.len()); } -- Regards Aravinda | ?????? http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn at masklinn.net Wed May 28 02:27:37 2014 From: masklinn at masklinn.net (Masklinn) Date: Wed, 28 May 2014 11:27:37 +0200 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: Message-ID: On 2014-05-28, at 11:10 , Aravinda VK wrote: > Hi, > > How to find number of characters in a string? Problem 1: define character. Do you mean a glyph? A grapheme cluster? A code point? Composed or decomposed? Problem 2: what use is knowing the length of a string? .len() returns the length of the string in bytes (using its underlying UTF-8 representation), .char_len() returns the number of non-normalized code points. AFAIK there is no way to know the number of grapheme clusters (I don't think there is a Rust implementation of UAX #29) and glyphs make no sense for text which is not rendered. > Following example returns byte count instead of number of characters. > > use std::string::String; > > fn main() { > let unicode_str = String::from_str("?"); > let ascii_str = String::from_str("a"); > println!("unicode str: {}, ascii str: {}", unicode_str.len(), ascii_str.len()); > } > > -- > Regards > Aravinda | ?????? > http://aravindavk.in > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From simon.sapin at exyr.org Wed May 28 02:31:09 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 28 May 2014 10:31:09 +0100 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: Message-ID: <5385ACDD.2000505@exyr.org> On 28/05/2014 10:10, Aravinda VK wrote: > Hi, > > How to find number of characters in a string? > > Following example returns byte count instead of number of characters. > > use std::string::String; > > fn main() { > let unicode_str = String::from_str("?"); > let ascii_str = String::from_str("a"); > println!("unicode str: {}, ascii str: {}", unicode_str.len(), > ascii_str.len()); > } It depends on what you call a "character". As you noted, the .len() method returns the number of UTF-8 bytes. Since strings are represented as UTF-8 internally, .len() takes O(1) time. There is also the .char_len() method, which counts the number of Unicode code points in O(n) time. http://static.rust-lang.org/doc/master/std/str/trait.StrSlice.html#tymethod.char_len However, what users perceive as a single "character" may be more than a single code point. These are sometimes "grapheme clusters". For example, "a?o" (which renders incorrectly in my email client?) is two grapheme clusters, but is made of three code points U+0065, U+0301, and U+006F. Rust?s standard libraries do not currently have a method for counting grapheme clusters, as far as I can tell. However, except for very specific cases (such as handling text selection in an editor), you generally don?t need to deal with grapheme clusters. Twitter also has a very specific idea of what "140 characters" means: https://dev.twitter.com/docs/counting-characters -- Simon Sapin From hallimanearavind at gmail.com Wed May 28 02:46:13 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Wed, 28 May 2014 15:16:13 +0530 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <5385ACDD.2000505@exyr.org> References: <5385ACDD.2000505@exyr.org> Message-ID: Thanks. I didn't know about char_len. `unicode_str.as_slice().char_len()` is giving number of code points. Sorry for the confusion, I was referring codepoint as character in my mail. char_len gives the correct output for my requirement. I have written javascript script to convert from string length to grapheme cluster length for Kannada language. On Wed, May 28, 2014 at 3:01 PM, Simon Sapin wrote: > On 28/05/2014 10:10, Aravinda VK wrote: > >> Hi, >> >> How to find number of characters in a string? >> >> Following example returns byte count instead of number of characters. >> >> use std::string::String; >> >> fn main() { >> let unicode_str = String::from_str("?"); >> let ascii_str = String::from_str("a"); >> println!("unicode str: {}, ascii str: {}", unicode_str.len(), >> ascii_str.len()); >> } >> > > It depends on what you call a "character". As you noted, the .len() method > returns the number of UTF-8 bytes. Since strings are represented as UTF-8 > internally, .len() takes O(1) time. > > There is also the .char_len() method, which counts the number of Unicode > code points in O(n) time. > > http://static.rust-lang.org/doc/master/std/str/trait. > StrSlice.html#tymethod.char_len > > However, what users perceive as a single "character" may be more than a > single code point. These are sometimes "grapheme clusters". For example, > "a?o" (which renders incorrectly in my email client?) is two grapheme > clusters, but is made of three code points U+0065, U+0301, and U+006F. > > Rust?s standard libraries do not currently have a method for counting > grapheme clusters, as far as I can tell. However, except for very specific > cases (such as handling text selection in an editor), you generally don?t > need to deal with grapheme clusters. Twitter also has a very specific idea > of what "140 characters" means: > > https://dev.twitter.com/docs/counting-characters > > -- > Simon Sapin > -- Regards Aravinda | ?????? http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Wed May 28 02:55:27 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 28 May 2014 10:55:27 +0100 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> Message-ID: <5385B28F.4040708@exyr.org> On 28/05/2014 10:46, Aravinda VK wrote: > Thanks. I didn't know about char_len. > `unicode_str.as_slice().char_len()` is giving number of code points. > > Sorry for the confusion, I was referring codepoint as character in my > mail. char_len gives the correct output for my requirement. I have > written javascript script to convert from string length to grapheme > cluster length for Kannada language. Be careful, JavaScript?s String.length counts UCS-2 code units, not code points? -- Simon Sapin From explodingmind at gmail.com Wed May 28 06:58:32 2014 From: explodingmind at gmail.com (Ian Daniher) Date: Wed, 28 May 2014 09:58:32 -0400 Subject: [rust-dev] Graphviz Deserialization? Message-ID: pnkfelix et al, Thanks for your work on the graphviz module! It's a great asset to my flowgraph DSL work. I'm wondering if any consideration has been given to Decodable/Encodable-style bidirectional serialization and deserialization. It'd be great to be able to use existing apps (like graphviz's dotty) as UIs for describing flowgraphs usable by Rust. Thanks! -- Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 07:04:04 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 10:04:04 -0400 Subject: [rust-dev] StrBuf and regular expressions In-Reply-To: References: <123F8E05-C474-4C77-89DA-43EDE650A40A@sb.org> <87F3C73E-95A4-4838-9C56-A87ED675BA24@sb.org> Message-ID: > And there's a good chance we'll add auto-deref+autoref for function arguments, specifically so String will auto-slice to &str the same way ~str used to (although someone still needs to write up an RFC for this). I would like the devs to clarify their support for this proposal, since I have seen little discussion regarding it. On Tue, May 27, 2014 at 10:17 PM, Kevin Ballard wrote: > On May 27, 2014, at 1:55 PM, Benjamin Striegel > wrote: > > What I was specifically curious about is why you seem to be against the > usage of the `Str` trait as a bound on the argument to the `captures` > method. > > > It adds unnecessary complexity, bloats the crate metadata with the > function AST, and complicates the type signature, with no real benefit. The > only thing that taking `` for an `arg: S` argument does is allowing > a String to be passed without calling .as_slice(). But the > solution moves the String into the function, rather than slicing it, which > means the calling function gives up ownership of the String. This is rarely > desired, and is likely to be confusing. > > We're also almost certainly going to implement Deref on String > post-DST, which means slicing a String is a simple as &*foo. And there's a > good chance we'll add auto-deref+autoref for function arguments, > specifically so String will auto-slice to &str the same way ~str used to > (although someone still needs to write up an RFC for this). > > -Kevin > > On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard wrote: > >> On May 27, 2014, at 6:05 AM, Benjamin Striegel >> wrote: >> >> > The use of taking is for taking things like &[S], where you >> want to take both &str and String (such as in the other post about >> getops()). >> >> I wouldn't be bothered with leaving the API as-is, but I don't understand >> where this guideline is coming from. Can you elaborate? >> >> >> I don't know if there's any authoritative source for this, but it's been >> suggested in the past for other APIs. The basic issue is that &[String] >> cannot be freely converted to &[&str]; you need to allocate a new Vec for >> that. So if you have a &[String] and try to call an API that takes a >> &[&str] then you're doing extra work just to satisfy the type system. But >> the function in question doesn't actually need &[&str], it just needs a >> slice of things it can convert to &str. So if it takes &[S] then >> you can hand it your &[String] without conversion, or you can hand it a >> &[&str], and it will work with both. >> >> This doesn't necessarily mean you need to use &[S] everywhere. >> But it's a nice thing to do if you think about it. >> >> -Kevin >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 07:07:23 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 10:07:23 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <5385B28F.4040708@exyr.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> Message-ID: I think that the naming of `len` here is dangerously misleading. Naive ASCII-users will be free to assume that this is counting codepoints rather than bytes. I'd prefer the name `byte_len` in order to make the behavior here explicit. On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: > On 28/05/2014 10:46, Aravinda VK wrote: > >> Thanks. I didn't know about char_len. >> `unicode_str.as_slice().char_len()` is giving number of code points. >> >> Sorry for the confusion, I was referring codepoint as character in my >> mail. char_len gives the correct output for my requirement. I have >> written javascript script to convert from string length to grapheme >> cluster length for Kannada language. >> > > Be careful, JavaScript?s String.length counts UCS-2 code units, not code > points? > > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed May 28 07:13:30 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 28 May 2014 10:13:30 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> Message-ID: <5385EF0A.7030702@gmail.com> On 28/05/14 10:07 AM, Benjamin Striegel wrote: > I think that the naming of `len` here is dangerously misleading. Naive > ASCII-users will be free to assume that this is counting codepoints > rather than bytes. I'd prefer the name `byte_len` in order to make the > behavior here explicit. It doesn't need to exist at all, because `as_bytes().len()` is available. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From simon.sapin at exyr.org Wed May 28 07:24:28 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 28 May 2014 15:24:28 +0100 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <5385EF0A.7030702@gmail.com> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <5385EF0A.7030702@gmail.com> Message-ID: <5385F19C.5070404@exyr.org> On 28/05/2014 15:13, Daniel Micay wrote: > On 28/05/14 10:07 AM, Benjamin Striegel wrote: >> I think that the naming of `len` here is dangerously misleading. Naive >> ASCII-users will be free to assume that this is counting codepoints >> rather than bytes. I'd prefer the name `byte_len` in order to make the >> behavior here explicit. > > It doesn't need to exist at all, because `as_bytes().len()` is available. Sure, but in that case many other things in libstd do not need to exist either, they?re just there for convenience. +1 to rename to .byte_len() or .utf8_len(). (See https://github.com/mozilla/rust/issues/14131 ) -- Simon Sapin From kevin at sb.org Wed May 28 10:12:22 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 10:12:22 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> Message-ID: <76020AD1-872A-4740-84CA-8D052A028866@sb.org> It's .len() because slicing and other related functions work on byte indexes. We've had this discussion before in the past. People expect there to be a .len(), and the only sensible .len() is byte length (because char length is not O(1) and not appropriate for use with most string-manipulation functions). Since Rust strings are UTF-8 encoded text, it makes sense for .len() to be the number of UTF-8 code units. Which happens to be the number of bytes. -Kevin On May 28, 2014, at 7:07 AM, Benjamin Striegel wrote: > I think that the naming of `len` here is dangerously misleading. Naive ASCII-users will be free to assume that this is counting codepoints rather than bytes. I'd prefer the name `byte_len` in order to make the behavior here explicit. > > > On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: > On 28/05/2014 10:46, Aravinda VK wrote: > Thanks. I didn't know about char_len. > `unicode_str.as_slice().char_len()` is giving number of code points. > > Sorry for the confusion, I was referring codepoint as character in my > mail. char_len gives the correct output for my requirement. I have > written javascript script to convert from string length to grapheme > cluster length for Kannada language. > > Be careful, JavaScript?s String.length counts UCS-2 code units, not code points? > > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 10:54:06 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 13:54:06 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <76020AD1-872A-4740-84CA-8D052A028866@sb.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> Message-ID: > People expect there to be a .len() This is the assumption that I object to. People expect there to be a .len() because strings have been fundamentally broken since time immemorial. Make people type .byte_len() and be explicit about their desire to index via code units. On Wed, May 28, 2014 at 1:12 PM, Kevin Ballard wrote: > It's .len() because slicing and other related functions work on byte > indexes. > > We've had this discussion before in the past. People expect there to be a > .len(), and the only sensible .len() is byte length (because char length is > not O(1) and not appropriate for use with most string-manipulation > functions). > > Since Rust strings are UTF-8 encoded text, it makes sense for .len() to be > the number of UTF-8 code units. Which happens to be the number of bytes. > > -Kevin > > On May 28, 2014, at 7:07 AM, Benjamin Striegel > wrote: > > I think that the naming of `len` here is dangerously misleading. Naive > ASCII-users will be free to assume that this is counting codepoints rather > than bytes. I'd prefer the name `byte_len` in order to make the behavior > here explicit. > > > On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: > >> On 28/05/2014 10:46, Aravinda VK wrote: >> >>> Thanks. I didn't know about char_len. >>> `unicode_str.as_slice().char_len()` is giving number of code points. >>> >>> Sorry for the confusion, I was referring codepoint as character in my >>> mail. char_len gives the correct output for my requirement. I have >>> written javascript script to convert from string length to grapheme >>> cluster length for Kannada language. >>> >> >> Be careful, JavaScript?s String.length counts UCS-2 code units, not code >> points? >> >> >> -- >> Simon Sapin >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Wed May 28 11:42:50 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 11:42:50 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> Message-ID: <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Breaking with established convention is a dangerous thing to do. Being too opinionated (regarding opinions that deviate from the norm) tends to put people off the language unless there's a clear benefit to forcing the alternative behavior. In this case, there's no compelling benefit to naming the thing .byte_len() over merely documenting that .len() is in code units. Everything else that doesn't explicitly say "char" on strings is in code units too, so it's sensible that .len() is too. But having strings that don't have an inherent "length" is confusing to anyone who hasn't already memorized this difference. Today we only need to teach the simple concept that strings are utf-8 encoded, and the corresponding notion that all of the accessor methods on strings (including indexing using []) use code units unless they specify otherwise (e.g. unless they contain the word "char"). -Kevin On May 28, 2014, at 10:54 AM, Benjamin Striegel wrote: > > People expect there to be a .len() > > This is the assumption that I object to. People expect there to be a .len() because strings have been fundamentally broken since time immemorial. Make people type .byte_len() and be explicit about their desire to index via code units. > > > On Wed, May 28, 2014 at 1:12 PM, Kevin Ballard wrote: > It's .len() because slicing and other related functions work on byte indexes. > > We've had this discussion before in the past. People expect there to be a .len(), and the only sensible .len() is byte length (because char length is not O(1) and not appropriate for use with most string-manipulation functions). > > Since Rust strings are UTF-8 encoded text, it makes sense for .len() to be the number of UTF-8 code units. Which happens to be the number of bytes. > > -Kevin > > On May 28, 2014, at 7:07 AM, Benjamin Striegel wrote: > >> I think that the naming of `len` here is dangerously misleading. Naive ASCII-users will be free to assume that this is counting codepoints rather than bytes. I'd prefer the name `byte_len` in order to make the behavior here explicit. >> >> >> On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: >> On 28/05/2014 10:46, Aravinda VK wrote: >> Thanks. I didn't know about char_len. >> `unicode_str.as_slice().char_len()` is giving number of code points. >> >> Sorry for the confusion, I was referring codepoint as character in my >> mail. char_len gives the correct output for my requirement. I have >> written javascript script to convert from string length to grapheme >> cluster length for Kannada language. >> >> Be careful, JavaScript?s String.length counts UCS-2 code units, not code points? >> >> >> -- >> Simon Sapin >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 11:55:34 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 14:55:34 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: > Being too opinionated (regarding opinions that deviate from the norm) tends to put people off the language unless there's a clear benefit to forcing the alternative behavior. We have already chosen to be opinionated by enforcing UTF-8 in our strings. This is an extension of that break with tradition. > Today we only need to teach the simple concept that strings are utf-8 encoded History has shown that understanding Unicode is not a simple concept. Asking for the "length" of a Unicode string is not a well-formed question, and we must express this in our API. I also don't agree with accessor functions that work on code units without warning, and for this reason I strongly disagree with supporting the [] operator on strings. On Wed, May 28, 2014 at 2:42 PM, Kevin Ballard wrote: > Breaking with established convention is a dangerous thing to do. Being too > opinionated (regarding opinions that deviate from the norm) tends to put > people off the language unless there's a clear benefit to forcing the > alternative behavior. > > In this case, there's no compelling benefit to naming the thing > .byte_len() over merely documenting that .len() is in code units. > Everything else that doesn't explicitly say "char" on strings is in code > units too, so it's sensible that .len() is too. But having strings that > don't have an inherent "length" is confusing to anyone who hasn't already > memorized this difference. > > Today we only need to teach the simple concept that strings are utf-8 > encoded, and the corresponding notion that all of the accessor methods on > strings (including indexing using []) use code units unless they specify > otherwise (e.g. unless they contain the word "char"). > > -Kevin > > On May 28, 2014, at 10:54 AM, Benjamin Striegel > wrote: > > > People expect there to be a .len() > > This is the assumption that I object to. People expect there to be a > .len() because strings have been fundamentally broken since time > immemorial. Make people type .byte_len() and be explicit about their desire > to index via code units. > > > On Wed, May 28, 2014 at 1:12 PM, Kevin Ballard wrote: > >> It's .len() because slicing and other related functions work on byte >> indexes. >> >> We've had this discussion before in the past. People expect there to be a >> .len(), and the only sensible .len() is byte length (because char length is >> not O(1) and not appropriate for use with most string-manipulation >> functions). >> >> Since Rust strings are UTF-8 encoded text, it makes sense for .len() to >> be the number of UTF-8 code units. Which happens to be the number of bytes. >> >> -Kevin >> >> On May 28, 2014, at 7:07 AM, Benjamin Striegel >> wrote: >> >> I think that the naming of `len` here is dangerously misleading. Naive >> ASCII-users will be free to assume that this is counting codepoints rather >> than bytes. I'd prefer the name `byte_len` in order to make the behavior >> here explicit. >> >> >> On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: >> >>> On 28/05/2014 10:46, Aravinda VK wrote: >>> >>>> Thanks. I didn't know about char_len. >>>> `unicode_str.as_slice().char_len()` is giving number of code points. >>>> >>>> Sorry for the confusion, I was referring codepoint as character in my >>>> mail. char_len gives the correct output for my requirement. I have >>>> written javascript script to convert from string length to grapheme >>>> cluster length for Kannada language. >>>> >>> >>> Be careful, JavaScript?s String.length counts UCS-2 code units, not code >>> points? >>> >>> >>> -- >>> Simon Sapin >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Wed May 28 12:24:02 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Wed, 28 May 2014 14:24:02 -0500 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: Benjamin seems to say that folks won't read the docs and we need to make the syntax more helpful.. Kevin seems to say that we need to keep the syntax simple and just teach folks to read the docs. I think I would agree with both of them overall for a language design goal that Rust wants to meet.... ...and in that light... I would first and foremost improve the docs which probably caused Aravinda's original confusion...there's no mention of u8 in this doc search, for instance, for the method that Aravinda used in his example : http://doc.rust-lang.org/0.10/std/index.html?search=from_str -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Wed May 28 12:48:02 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 12:48:02 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: On May 28, 2014, at 11:55 AM, Benjamin Striegel wrote: > > Being too opinionated (regarding opinions that deviate from the norm) tends to put people off the language unless there's a clear benefit to forcing the alternative behavior. > > We have already chosen to be opinionated by enforcing UTF-8 in our strings. This is an extension of that break with tradition. There's no clear tradition regarding strings. Some languages treat strings as just blobs of binary data with no associated encoding (and obviously, operate on bytes). Some languages use an associated encoding with every string, but those are pretty rare. Some languages, such as JavaScript and Obj-C, use UCS-2 (well, Obj-C tries to be UTF-16 but all of its accessors that operate on characters actually operate on UTF-16 code units, which is effectively equivalent to UCS-2). > > Today we only need to teach the simple concept that strings are utf-8 encoded > > History has shown that understanding Unicode is not a simple concept. Asking for the "length" of a Unicode string is not a well-formed question, and we must express this in our API. I also don't agree with accessor functions that work on code units without warning, and for this reason I strongly disagree with supporting the [] operator on strings. Unicode is not a simple concept. UTF-8 on the other hand is a pretty simple concept. And string accessors that operate at the code unit level are very common (in fact, I can't think of a single language that doesn't operate on code units by default[1][2]). Pretty much the only odd part about Rust's behavior here is that the slicing methods (with the exception of slice_chars()) will fail if the byte index isn't on a character boundary, but that's a natural extension of the fact that Rust strings are guaranteed to be valid utf-8. And it's unrelated to the naming (even if it were called .byte_slice() it would still fail with the same input; and honestly, .byte_slice() looks like it will return a &[u8]). Of course, we haven't mentioned .byte_slice() before, but if you're going to rename .len() to .byte_len() you're going to have to add .byte_ prefixes to all of the other methods that take byte indexes. In any case, the core idea here is that .len() returns "the length" of the string. And "the length" is the number of code units. This matches the behavior of other languages. -Kevin [1]: Even Haskell can be said to operate on code units, as its built-in string is a linked list of UTF-32 characters, which means the code unit is the character. Although I don't know offhand how Data.Text or Data.ByteString work. [2]: Python 2.7 operates on bytes, but I just did some poking around in Python3 and it seems to use characters for length and indexing. I don't know what the internal representation of a Python3 string is, though, so I don't know if they're using O(n) operations, or if they're using UTF-16/UTF-32 internally as necessary. > On Wed, May 28, 2014 at 2:42 PM, Kevin Ballard wrote: > Breaking with established convention is a dangerous thing to do. Being too opinionated (regarding opinions that deviate from the norm) tends to put people off the language unless there's a clear benefit to forcing the alternative behavior. > > In this case, there's no compelling benefit to naming the thing .byte_len() over merely documenting that .len() is in code units. Everything else that doesn't explicitly say "char" on strings is in code units too, so it's sensible that .len() is too. But having strings that don't have an inherent "length" is confusing to anyone who hasn't already memorized this difference. > > Today we only need to teach the simple concept that strings are utf-8 encoded, and the corresponding notion that all of the accessor methods on strings (including indexing using []) use code units unless they specify otherwise (e.g. unless they contain the word "char"). > > -Kevin > > On May 28, 2014, at 10:54 AM, Benjamin Striegel wrote: > >> > People expect there to be a .len() >> >> This is the assumption that I object to. People expect there to be a .len() because strings have been fundamentally broken since time immemorial. Make people type .byte_len() and be explicit about their desire to index via code units. >> >> >> On Wed, May 28, 2014 at 1:12 PM, Kevin Ballard wrote: >> It's .len() because slicing and other related functions work on byte indexes. >> >> We've had this discussion before in the past. People expect there to be a .len(), and the only sensible .len() is byte length (because char length is not O(1) and not appropriate for use with most string-manipulation functions). >> >> Since Rust strings are UTF-8 encoded text, it makes sense for .len() to be the number of UTF-8 code units. Which happens to be the number of bytes. >> >> -Kevin >> >> On May 28, 2014, at 7:07 AM, Benjamin Striegel wrote: >> >>> I think that the naming of `len` here is dangerously misleading. Naive ASCII-users will be free to assume that this is counting codepoints rather than bytes. I'd prefer the name `byte_len` in order to make the behavior here explicit. >>> >>> >>> On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: >>> On 28/05/2014 10:46, Aravinda VK wrote: >>> Thanks. I didn't know about char_len. >>> `unicode_str.as_slice().char_len()` is giving number of code points. >>> >>> Sorry for the confusion, I was referring codepoint as character in my >>> mail. char_len gives the correct output for my requirement. I have >>> written javascript script to convert from string length to grapheme >>> cluster length for Kannada language. >>> >>> Be careful, JavaScript?s String.length counts UCS-2 code units, not code points? >>> >>> >>> -- >>> Simon Sapin >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 13:26:09 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 16:26:09 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: > There's no clear tradition regarding strings. Excellent, then surely nobody has any right to expect a method named .len() :) > Unicode is not a simple concept. UTF-8 on the other hand is a pretty simple concept. I don't think we can fully divorce these two ideas. Understanding UTF-8 still implies understanding the difference between code points, code units, and grapheme clusters. If we have a single unadorned `len` function, that implies the existence of a "default" length to a UTF-8 string, which is a lie. It also *fails* to suggest the existence of alternative measures of length of a UTF-8 string. Finally, the choice of byte length as the default length metric encourages the horrid status quo, which is the perpetuation of code that is tested and works in ASCII environments but barfs as soon as anyone from a sufficiently-foreign culture tries to use it. Dedicating ourselves to Unicode support does us no good if the remainder of our API encourages the depressingly-typical ASCII-ism that pervades nearly every other language. On Wed, May 28, 2014 at 3:48 PM, Kevin Ballard wrote: > On May 28, 2014, at 11:55 AM, Benjamin Striegel > wrote: > > > Being too opinionated (regarding opinions that deviate from the norm) > tends to put people off the language unless there's a clear benefit to > forcing the alternative behavior. > > We have already chosen to be opinionated by enforcing UTF-8 in our > strings. This is an extension of that break with tradition. > > > There's no clear tradition regarding strings. Some languages treat strings > as just blobs of binary data with no associated encoding (and obviously, > operate on bytes). Some languages use an associated encoding with every > string, but those are pretty rare. Some languages, such as JavaScript and > Obj-C, use UCS-2 (well, Obj-C tries to be UTF-16 but all of its accessors > that operate on characters actually operate on UTF-16 code units, which is > effectively equivalent to UCS-2). > > > Today we only need to teach the simple concept that strings are utf-8 > encoded > > History has shown that understanding Unicode is not a simple concept. > Asking for the "length" of a Unicode string is not a well-formed question, > and we must express this in our API. I also don't agree with accessor > functions that work on code units without warning, and for this reason I > strongly disagree with supporting the [] operator on strings. > > > Unicode is not a simple concept. UTF-8 on the other hand is a pretty > simple concept. And string accessors that operate at the code unit level > are *very* common (in fact, I can't think of a single language that > doesn't operate on code units by default[1][2]). Pretty much the only odd > part about Rust's behavior here is that the slicing methods (with the > exception of slice_chars()) will fail if the byte index isn't on a > character boundary, but that's a natural extension of the fact that Rust > strings are guaranteed to be valid utf-8. And it's unrelated to the naming > (even if it were called .byte_slice() it would still fail with the same > input; and honestly, .byte_slice() looks like it will return a &[u8]). > > Of course, we haven't mentioned .byte_slice() before, but if you're going > to rename .len() to .byte_len() you're going to have to add .byte_ prefixes > to all of the other methods that take byte indexes. > > In any case, the core idea here is that .len() returns "the length" of the > string. And "the length" is the number of code units. This matches the > behavior of other languages. > > -Kevin > > [1]: Even Haskell can be said to operate on code units, as its built-in > string is a linked list of UTF-32 characters, which means the code unit is > the character. Although I don't know offhand how Data.Text or > Data.ByteString work. > > [2]: Python 2.7 operates on bytes, but I just did some poking around in > Python3 and it seems to use characters for length and indexing. I don't > know what the internal representation of a Python3 string is, though, so I > don't know if they're using O(n) operations, or if they're using > UTF-16/UTF-32 internally as necessary. > > On Wed, May 28, 2014 at 2:42 PM, Kevin Ballard wrote: > >> Breaking with established convention is a dangerous thing to do. Being >> too opinionated (regarding opinions that deviate from the norm) tends to >> put people off the language unless there's a clear benefit to forcing the >> alternative behavior. >> >> In this case, there's no compelling benefit to naming the thing >> .byte_len() over merely documenting that .len() is in code units. >> Everything else that doesn't explicitly say "char" on strings is in code >> units too, so it's sensible that .len() is too. But having strings that >> don't have an inherent "length" is confusing to anyone who hasn't already >> memorized this difference. >> >> Today we only need to teach the simple concept that strings are utf-8 >> encoded, and the corresponding notion that all of the accessor methods on >> strings (including indexing using []) use code units unless they specify >> otherwise (e.g. unless they contain the word "char"). >> >> -Kevin >> >> On May 28, 2014, at 10:54 AM, Benjamin Striegel >> wrote: >> >> > People expect there to be a .len() >> >> This is the assumption that I object to. People expect there to be a >> .len() because strings have been fundamentally broken since time >> immemorial. Make people type .byte_len() and be explicit about their desire >> to index via code units. >> >> >> On Wed, May 28, 2014 at 1:12 PM, Kevin Ballard wrote: >> >>> It's .len() because slicing and other related functions work on byte >>> indexes. >>> >>> We've had this discussion before in the past. People expect there to be >>> a .len(), and the only sensible .len() is byte length (because char length >>> is not O(1) and not appropriate for use with most string-manipulation >>> functions). >>> >>> Since Rust strings are UTF-8 encoded text, it makes sense for .len() to >>> be the number of UTF-8 code units. Which happens to be the number of bytes. >>> >>> -Kevin >>> >>> On May 28, 2014, at 7:07 AM, Benjamin Striegel >>> wrote: >>> >>> I think that the naming of `len` here is dangerously misleading. Naive >>> ASCII-users will be free to assume that this is counting codepoints rather >>> than bytes. I'd prefer the name `byte_len` in order to make the behavior >>> here explicit. >>> >>> >>> On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote: >>> >>>> On 28/05/2014 10:46, Aravinda VK wrote: >>>> >>>>> Thanks. I didn't know about char_len. >>>>> `unicode_str.as_slice().char_len()` is giving number of code points. >>>>> >>>>> Sorry for the confusion, I was referring codepoint as character in my >>>>> mail. char_len gives the correct output for my requirement. I have >>>>> written javascript script to convert from string length to grapheme >>>>> cluster length for Kannada language. >>>>> >>>> >>>> Be careful, JavaScript?s String.length counts UCS-2 code units, not >>>> code points? >>>> >>>> >>>> -- >>>> Simon Sapin >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Wed May 28 13:38:33 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 13:38:33 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: On May 28, 2014, at 1:26 PM, Benjamin Striegel wrote: > > Unicode is not a simple concept. UTF-8 on the other hand is a pretty simple concept. > > I don't think we can fully divorce these two ideas. Understanding UTF-8 still implies understanding the difference between code points, code units, and grapheme clusters. If we have a single unadorned `len` function, that implies the existence of a "default" length to a UTF-8 string, which is a lie. It also *fails* to suggest the existence of alternative measures of length of a UTF-8 string. Finally, the choice of byte length as the default length metric encourages the horrid status quo, which is the perpetuation of code that is tested and works in ASCII environments but barfs as soon as anyone from a sufficiently-foreign culture tries to use it. Dedicating ourselves to Unicode support does us no good if the remainder of our API encourages the depressingly-typical ASCII-ism that pervades nearly every other language. Do you honestly believe that calling it .byte_len() will do anything besides confusing anyone who expects .len() to work, and resulting in code that looks any different than just using .byte_len() everywhere people use .len() today? Forcing more verbose, annoying, unconventional names on people won't actually change how they process strings. It will just confuse and annoy them. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 14:17:37 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 17:17:37 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: > Do you honestly believe Yes. Anyone who comes to Rust expecting there to be a .len() method on strings has demonstrated that they fundamentally misunderstand what strings are. Correcting them will be a learning experience, to their benefit. > more verbose, annoying, unconventional names I prefer to think of them as "more explicit, clear, self-documenting names". Code readers will also benefit from the reduced ambiguity, even if the code authors are burdened with typing an onerous five additional keystrokes. On Wed, May 28, 2014 at 4:38 PM, Kevin Ballard wrote: > On May 28, 2014, at 1:26 PM, Benjamin Striegel > wrote: > > > Unicode is not a simple concept. UTF-8 on the other hand is a pretty > simple concept. > > I don't think we can fully divorce these two ideas. Understanding UTF-8 > still implies understanding the difference between code points, code units, > and grapheme clusters. If we have a single unadorned `len` function, that > implies the existence of a "default" length to a UTF-8 string, which is a > lie. It also *fails* to suggest the existence of alternative measures of > length of a UTF-8 string. Finally, the choice of byte length as the default > length metric encourages the horrid status quo, which is the perpetuation > of code that is tested and works in ASCII environments but barfs as soon as > anyone from a sufficiently-foreign culture tries to use it. Dedicating > ourselves to Unicode support does us no good if the remainder of our API > encourages the depressingly-typical ASCII-ism that pervades nearly every > other language. > > > Do you honestly believe that calling it .byte_len() will do anything > besides confusing anyone who expects .len() to work, and resulting in code > that looks any different than just using .byte_len() everywhere people use > .len() today? > > Forcing more verbose, annoying, unconventional names on people won't > actually change how they process strings. It will just confuse and annoy > them. > > -Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Wed May 28 15:24:46 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Thu, 29 May 2014 08:24:46 +1000 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> Message-ID: <5386622E.8050308@gmail.com> On 29/05/14 06:38, Kevin Ballard wrote: > On May 28, 2014, at 1:26 PM, Benjamin Striegel > wrote: > >> > Unicode is not a simple concept. UTF-8 on the other hand is a >> pretty simple concept. >> >> I don't think we can fully divorce these two ideas. Understanding >> UTF-8 still implies understanding the difference between code points, >> code units, and grapheme clusters. If we have a single unadorned >> `len` function, that implies the existence of a "default" length to a >> UTF-8 string, which is a lie. It also *fails* to suggest the >> existence of alternative measures of length of a UTF-8 string. >> Finally, the choice of byte length as the default length metric >> encourages the horrid status quo, which is the perpetuation of code >> that is tested and works in ASCII environments but barfs as soon as >> anyone from a sufficiently-foreign culture tries to use it. >> Dedicating ourselves to Unicode support does us no good if the >> remainder of our API encourages the depressingly-typical ASCII-ism >> that pervades nearly every other language. > > Do you honestly believe that calling it .byte_len() will do anything > besides confusing anyone who expects .len() to work, and resulting in > code that looks any different than just using .byte_len() everywhere > people use .len() today? > > Forcing more verbose, annoying, unconventional names on people won't > actually change how they process strings. It will just confuse and > annoy them. > > -Kevin > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev Changing the names of methods on strings seems very similar how Path does not implement Show (except with even stronger motivation, because strings have at least 3 sensible interpretations of what the length could be). Huon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Wed May 28 16:00:55 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 16:00:55 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <5386622E.8050308@gmail.com> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> Message-ID: <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> On May 28, 2014, at 3:24 PM, Huon Wilson wrote: > Changing the names of methods on strings seems very similar how Path does not implement Show (except with even stronger motivation, because strings have at least 3 sensible interpretations of what the length could be). I disagree completely. Path does not implement Show, because of ToStr (and just generally, because Show can be used to convert to a string representation). This isn't a problem for most types, but paths are special in that a lot of people think that they can be represented with strings, and therefore will try to do that. Because Path does not implement Show it's difficult to incorrectly convert it to a string (it exposes methods for getting an Option<&str> which is the correct way to do it). This is about preventing the user from doing something incorrectly, and forcing them to use the correct method. Meanwhile, renaming .len() to .byte_len() doesn't actually prevent anything. It will just confuse people (and cause a lot of unnecessary typing of "byte_"), but people will still end up calling the exact same method. They did the same operation, they just got annoyed in the process. It's important to note here that in most cases .len() actually is the correct method to call. This has been discussed before, but basically, string manipulation needs to use byte indexes (well, code unit indexes) to be at all efficient, and that's why the character-based methods have special names. This means that the byte-based methods are the ones we're expecting people to use. Renaming them doesn't change that fact. If someone doesn't give any thought to non-ASCII text, putting "byte" in the method name isn't going to change that. And if they do give thought to non-ASCII text, leaving "byte" out of the name doesn't cause any issues. Don't forget that renaming .byte_len() only makes sense if we rename .slice()/.slice_from()/.slice_to() to .byte_slice()/.byte_slice_from()/.byte_slice_to(). And besides being extremely verbose, these methods imply that they return a "byte slice", or a &[u8]. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at eterevsky.com Wed May 28 17:38:14 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Wed, 28 May 2014 17:38:14 -0700 Subject: [rust-dev] A few random questions Message-ID: Hi! I've just recently started learning Rust. Here's a few questions that I have after writing about a hundred lines of code: 1. Why neither overloaded function, nor default values for arguments are supported? In statically typed language overloaded functions are quite safe and convenient. Also, from what I see, overloaded functions could be used in various use cases instead of macros. 2. What about exceptions? Is it a design decision not to support them, or are they planned for some future version? I understand, that exceptions make memory management more difficult, but maybe there are ways to restrict their usage to avoid problems (like making it impossible to pass references as exception parameters?) 3. It seems like almost any string operation requires as_slice(). Can't various string methods be also implemented for String? 4. It looks like vectors can be concatenated with + operations, but strings can't. Is it deliberate? 5. Simple indexing doesn't work for vectors: let a = vec![1, 2, 3]; println!("{}", a[0]); It's a bit surprising... 6. impl ToStr for custom struct fails: error: conflicting implementations for trait `std::to_str::ToStr` note: conflicting implementation in crate `std` Is it a bug? Is Show implicitly assumed for all struct's? 7. The usage of mut is a bit confusing. It is supposed to be used as a qualifier for a variable, but it quickly becomes a part of the type, when you define functions like fn test(something: &mut Something) Maybe it makes sense move mut their? Or distinguish mut as a variable qualifier vs const as a propery of type? -- Thanks, Oleg Eterevsky. From steve at steveklabnik.com Wed May 28 17:47:43 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 28 May 2014 17:47:43 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: A few quick intro answers. Just the high level, not comprehensive. 1. Not everyone prefers overloaded functions, or default arguments. I know pcwalton has strong feelings about the first, so I'll leave him to that :) 2. Design decision. Basically, we take Erlang's philosophy: recovering from errors is tricky and error-prone. Better to let a task fail and start a new one rather than to try to re-start one in the middle of whatever it's doing. 3. No opinions, but know that all of this has been changing a _lot_ recently, this may even be planned. 4. I believe so, yes. We try not to be overload-heavy. 5. This is being worked on. Vec is a new construct anyway. 6. I believe there is a default implementation, yes. 7. I'm not even getting into this one. There's been a toooooon of discussion about this lately. https://github.com/rust-lang/rfcs/search?q=mutability&ref=cmdform&type=Issues Hope that starts to kick off some good discussion. :) From pcwalton at mozilla.com Wed May 28 17:48:31 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 28 May 2014 17:48:31 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: <538683DF.6010703@mozilla.com> On 5/28/14 5:38 PM, Oleg Eterevsky wrote: > 7. The usage of mut is a bit confusing. It is supposed to be used as a > qualifier for a variable, but it quickly becomes a part of the type, > when you define functions like > fn test(something: &mut Something) > Maybe it makes sense move mut their? Or distinguish mut as a variable > qualifier vs const as a propery of type? The way it is implemented in Rust is necessary for memory safety. Patrick From ben.striegel at gmail.com Wed May 28 18:00:40 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 21:00:40 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: > but people will still end up calling the *exact same method* ...Except when they actually intended to call any other method of determining the length of a string, but were stymied by poor naming and inadequate understanding. But if your argument is "people will only call the method that tells them how many bytes are in the string when they want to know how many bytes are in the string", then yes, I should hope so. Let's help them understand which method is appropriate. To reiterate, it simply doesn't make sense to ask what the length of a string is. You may as well ask what color the string is, or where the string went to high school, or how many times the string rode the roller coaster that one year on the first day of summer vacation when the string's parents took the string to that amusement park and the weather said that it was going to rain so there were almost no crowds that day but then it didn't rain and all the rides were open with absolutely no lines whatsoever. As Daniel has mentioned above, if you want to perform byte operations on a String without being forced to type "byte" every time, then call .as_bytes() on it once and run wild. Though at this point I think at this we're just arguing in circles, and will have to simply agree to disagree. On Wed, May 28, 2014 at 7:00 PM, Kevin Ballard wrote: > On May 28, 2014, at 3:24 PM, Huon Wilson wrote: > > Changing the names of methods on strings seems very similar how Path does > not implement Show (except with even stronger motivation, because strings > have at least 3 sensible interpretations of what the length could be). > > > I disagree completely. > > Path does not implement Show, because of ToStr (and just generally, > because Show can be used to convert to a string representation). This isn't > a problem for most types, but paths are special in that a lot of people > think that they can be represented with strings, and therefore will try to > do that. Because Path does not implement Show it's difficult to incorrectly > convert it to a string (it exposes methods for getting an Option<&str> > which is the correct way to do it). > > This is about preventing the user from doing something incorrectly, and > forcing them to use the correct method. > > Meanwhile, renaming .len() to .byte_len() doesn't actually prevent > anything. It will just confuse people (and cause a lot of unnecessary > typing of "byte_"), but people will still end up calling the *exact same > method*. They did the same operation, they just got annoyed in the > process. > > It's important to note here that in most cases .len() actually is the > correct method to call. This has been discussed before, but basically, > string manipulation needs to use byte indexes (well, code unit indexes) to > be at all efficient, and that's why the character-based methods have > special names. This means that the byte-based methods are the ones we're > expecting people to use. Renaming them doesn't change that fact. > > If someone doesn't give any thought to non-ASCII text, putting "byte" in > the method name isn't going to change that. And if they do give thought to > non-ASCII text, leaving "byte" out of the name doesn't cause any issues. > > Don't forget that renaming .byte_len() only makes sense if we rename > .slice()/.slice_from()/.slice_to() to > .byte_slice()/.byte_slice_from()/.byte_slice_to(). And besides being > extremely verbose, these methods imply that they return a "byte slice", or > a &[u8]. > > -Kevin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed May 28 18:11:22 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 28 May 2014 21:11:22 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: Oh and while we're belligerently bikeshedding, we should rename `to_str` to `to_string` once we rename `StrBuf` to `String`. :) On Wed, May 28, 2014 at 9:00 PM, Benjamin Striegel wrote: > > but people will still end up calling the > > *exact same method* > ...Except when they actually intended to call any other method of > determining the length of a string, but were stymied by poor naming and > inadequate understanding. But if your argument is "people will only call > the method that tells them how many bytes are in the string when they want > to know how many bytes are in the string", then yes, I should hope so. > Let's help them understand which method is appropriate. > > To reiterate, it simply doesn't make sense to ask what the length of a > string is. You may as well ask what color the string is, or where the > string went to high school, or how many times the string rode the roller > coaster that one year on the first day of summer vacation when the string's > parents took the string to that amusement park and the weather said that it > was going to rain so there were almost no crowds that day but then it > didn't rain and all the rides were open with absolutely no lines whatsoever. > > As Daniel has mentioned above, if you want to perform byte operations on a > String without being forced to type "byte" every time, then call > .as_bytes() on it once and run wild. Though at this point I think at this > we're just arguing in circles, and will have to simply agree to disagree. > > > On Wed, May 28, 2014 at 7:00 PM, Kevin Ballard wrote: > >> On May 28, 2014, at 3:24 PM, Huon Wilson wrote: >> >> Changing the names of methods on strings seems very similar how Path does >> not implement Show (except with even stronger motivation, because strings >> have at least 3 sensible interpretations of what the length could be). >> >> >> I disagree completely. >> >> Path does not implement Show, because of ToStr (and just generally, >> because Show can be used to convert to a string representation). This isn't >> a problem for most types, but paths are special in that a lot of people >> think that they can be represented with strings, and therefore will try to >> do that. Because Path does not implement Show it's difficult to incorrectly >> convert it to a string (it exposes methods for getting an Option<&str> >> which is the correct way to do it). >> >> This is about preventing the user from doing something incorrectly, and >> forcing them to use the correct method. >> >> Meanwhile, renaming .len() to .byte_len() doesn't actually prevent >> anything. It will just confuse people (and cause a lot of unnecessary >> typing of "byte_"), but people will still end up calling the *exact same >> method*. They did the same operation, they just got annoyed in the >> process. >> >> It's important to note here that in most cases .len() actually is the >> correct method to call. This has been discussed before, but basically, >> string manipulation needs to use byte indexes (well, code unit indexes) to >> be at all efficient, and that's why the character-based methods have >> special names. This means that the byte-based methods are the ones we're >> expecting people to use. Renaming them doesn't change that fact. >> >> If someone doesn't give any thought to non-ASCII text, putting "byte" in >> the method name isn't going to change that. And if they do give thought to >> non-ASCII text, leaving "byte" out of the name doesn't cause any issues. >> >> Don't forget that renaming .byte_len() only makes sense if we rename >> .slice()/.slice_from()/.slice_to() to >> .byte_slice()/.byte_slice_from()/.byte_slice_to(). And besides being >> extremely verbose, these methods imply that they return a "byte slice", or >> a &[u8]. >> >> -Kevin >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smcarthur at mozilla.com Wed May 28 18:23:26 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Wed, 28 May 2014 18:23:26 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky wrote: > 3. It seems like almost any string operation requires as_slice(). > Can't various string methods be also implemented for String? > When writing functions for others to use, you don't want to require them to have a String, since that requires a heap allocation. It's free to go from String to a slice, but not vice-versa. That said, there's been whispers of making String implement Deref, as well passing as arguments to autoderef, so you could pass a String and rustc would convert to a slice for you. > 5. Simple indexing doesn't work for vectors: > let a = vec![1, 2, 3]; > println!("{}", a[0]); > It's a bit surprising... > Known issue: https://github.com/mozilla/rust/issues/11875 > > 6. impl ToStr for custom struct fails: > error: conflicting implementations for trait `std::to_str::ToStr` > note: conflicting implementation in crate `std` > Is it a bug? Is Show implicitly assumed for all struct's? > This is because ToStr is implemented for all Show implementations. You can't implement ToStr, because if you then implemented Show, you'd have conflicting implementations. #[deriving(Show)] on your structs is probably all you want. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Wed May 28 19:17:40 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Wed, 28 May 2014 21:17:40 -0500 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: You can also read and search the docs and easily see the Implementors (and even click on them to get more detailed documentation AND even have 1 click access to the [src] ) : http://doc.rust-lang.org/0.10/std/to_str/trait.ToStr.html If you find the docs are lacking a bit, then let the maintainers know (there is ongoing effort to improve the docs by the way...even a few newly hired folks at Mozilla). On Wed, May 28, 2014 at 8:23 PM, Sean McArthur wrote: > > > > On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky wrote: > >> 3. It seems like almost any string operation requires as_slice(). >> Can't various string methods be also implemented for String? >> > > When writing functions for others to use, you don't want to require them > to have a String, since that requires a heap allocation. It's free to go > from String to a slice, but not vice-versa. That said, there's been > whispers of making String implement Deref, as well passing as arguments to > autoderef, so you could pass a String and rustc would convert to a slice > for you. > > >> 5. Simple indexing doesn't work for vectors: >> let a = vec![1, 2, 3]; >> println!("{}", a[0]); >> It's a bit surprising... >> > > Known issue: https://github.com/mozilla/rust/issues/11875 > > >> >> 6. impl ToStr for custom struct fails: >> error: conflicting implementations for trait `std::to_str::ToStr` >> note: conflicting implementation in crate `std` >> Is it a bug? Is Show implicitly assumed for all struct's? >> > > This is because ToStr is implemented for all Show implementations. You > can't implement ToStr, because if you then implemented Show, you'd have > conflicting implementations. #[deriving(Show)] on your structs is probably > all you want. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at eterevsky.com Wed May 28 19:17:56 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Wed, 28 May 2014 19:17:56 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: Thanks for your answers. Can't say I understand or agree with all the decisions. > 1. Not everyone prefers overloaded functions, or default arguments. Suppose, I want to add a new argument to a function in a backwards-compatible way. In Python I provide a default and everything works fine. In C++ or Java I write something like fn test(old_arg: int, new_arg: int) { ... } fn test(old_arg: int) { test(old_arg, 0) } and everything is still good. What should I do in Rust? > 2. Design decision. Basically, we take Erlang's philosophy: recovering from errors is tricky and error-prone. So basically this mean that you could emulate exceptions by running a co-routing and catching its state? It makes sense, though it sounds like it overcomplicates things a bit from programmer's perspective. Also I'm a bit worried about the number of unwrap's. >> 4. It looks like vectors can be concatenated with + operations, but strings can't. Is it deliberate? > 4. I believe so, yes. We try not to be overload-heavy. In my experience + is much more often used for strings than for vectors. Is it not? > 6. I believe there is a default implementation, yes. It happens even for this: struct Test { a: int } impl ToStr for Test { fn to_str(&self) -> String { self.a.to_str() } } As you can see, Test is not implementing Show, so I assumed that I could implement ToStr instead. I suspect that there is somewhere an implementation impl Show for T and after I implemented ToStr, Test automatically became an implementation of Show, which in turn led to conflict. I might be wrong though. I'd like to note that if there was a sane implementation of overloaded functions, this could be resolved. On Wed, May 28, 2014 at 5:47 PM, Steve Klabnik wrote: > A few quick intro answers. Just the high level, not comprehensive. > > 1. Not everyone prefers overloaded functions, or default arguments. I > know pcwalton has strong feelings about the first, so I'll leave him > to that :) > > 2. Design decision. Basically, we take Erlang's philosophy: recovering > from errors is tricky and error-prone. Better to let a task fail and > start a new one rather than to try to re-start one in the middle of > whatever it's doing. > > 3. No opinions, but know that all of this has been changing a _lot_ > recently, this may even be planned. > > 4. I believe so, yes. We try not to be overload-heavy. > > 5. This is being worked on. Vec is a new construct anyway. > > 6. I believe there is a default implementation, yes. > > 7. I'm not even getting into this one. There's been a toooooon of > discussion about this lately. > https://github.com/rust-lang/rfcs/search?q=mutability&ref=cmdform&type=Issues > > Hope that starts to kick off some good discussion. :) From oleg at eterevsky.com Wed May 28 19:18:56 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Wed, 28 May 2014 19:18:56 -0700 Subject: [rust-dev] A few random questions In-Reply-To: <538683DF.6010703@mozilla.com> References: <538683DF.6010703@mozilla.com> Message-ID: >> Maybe it makes sense move mut their? Or distinguish mut as a variable >> qualifier vs const as a propery of type? > The way it is implemented in Rust is necessary for memory safety. Are there any articles on this? I'd like to know more. :) On Wed, May 28, 2014 at 5:48 PM, Patrick Walton wrote: > On 5/28/14 5:38 PM, Oleg Eterevsky wrote: >> >> 7. The usage of mut is a bit confusing. It is supposed to be used as a >> qualifier for a variable, but it quickly becomes a part of the type, >> when you define functions like >> fn test(something: &mut Something) >> Maybe it makes sense move mut their? Or distinguish mut as a variable >> qualifier vs const as a propery of type? > > > The way it is implemented in Rust is necessary for memory safety. > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From oleg at eterevsky.com Wed May 28 19:21:19 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Wed, 28 May 2014 19:21:19 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: > When writing functions for others to use, you don't want to require them to have a String, since that requires a heap allocation. By no means. I'd prefer the same functions to work both on str and String. It should be possible to achieve it via traits. > This is because ToStr is implemented for all Show implementations. You can't implement ToStr, because if you then implemented Show, you'd have conflicting implementations. As I already wrote in the previous answer, I didn't have an explicit Show implementation. On Wed, May 28, 2014 at 6:23 PM, Sean McArthur wrote: > > > > On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky wrote: >> >> 3. It seems like almost any string operation requires as_slice(). >> Can't various string methods be also implemented for String? > > > When writing functions for others to use, you don't want to require them to > have a String, since that requires a heap allocation. It's free to go from > String to a slice, but not vice-versa. That said, there's been whispers of > making String implement Deref, as well passing as arguments to autoderef, so > you could pass a String and rustc would convert to a slice for you. > >> >> 5. Simple indexing doesn't work for vectors: >> let a = vec![1, 2, 3]; >> println!("{}", a[0]); >> It's a bit surprising... > > > Known issue: https://github.com/mozilla/rust/issues/11875 > >> >> >> 6. impl ToStr for custom struct fails: >> error: conflicting implementations for trait `std::to_str::ToStr` >> note: conflicting implementation in crate `std` >> Is it a bug? Is Show implicitly assumed for all struct's? > > > This is because ToStr is implemented for all Show implementations. You can't > implement ToStr, because if you then implemented Show, you'd have > conflicting implementations. #[deriving(Show)] on your structs is probably > all you want. > From oleg at eterevsky.com Wed May 28 19:28:36 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Wed, 28 May 2014 19:28:36 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: Thanks, I already read some parts of documentation. It is good, though I found the navigation a bit confusing. I also looked at the sources for libcore and libstd on GitHub, they are very readable. (Compared to, for instance, STL.) By the way, I remembered one more question that I had: I am a bit confused about the relationship between core and std. Some of the things defined in core are re-exported in std. For example, std::fmt (https://github.com/mozilla/rust/blob/master/src/libstd/fmt.rs) contains almost only the documentation, while the main implementation is in core::fmt. Would it make sense to have a more defined division between core and std? On Wed, May 28, 2014 at 7:17 PM, Thad Guidry wrote: > You can also read and search the docs and easily see the Implementors (and > even click on them to get more detailed documentation AND even have 1 click > access to the [src] ) : > > http://doc.rust-lang.org/0.10/std/to_str/trait.ToStr.html > > If you find the docs are lacking a bit, then let the maintainers know (there > is ongoing effort to improve the docs by the way...even a few newly hired > folks at Mozilla). > > > > On Wed, May 28, 2014 at 8:23 PM, Sean McArthur > wrote: >> >> >> >> >> On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky >> wrote: >>> >>> 3. It seems like almost any string operation requires as_slice(). >>> Can't various string methods be also implemented for String? >> >> >> When writing functions for others to use, you don't want to require them >> to have a String, since that requires a heap allocation. It's free to go >> from String to a slice, but not vice-versa. That said, there's been whispers >> of making String implement Deref, as well passing as arguments to autoderef, >> so you could pass a String and rustc would convert to a slice for you. >> >>> >>> 5. Simple indexing doesn't work for vectors: >>> let a = vec![1, 2, 3]; >>> println!("{}", a[0]); >>> It's a bit surprising... >> >> >> Known issue: https://github.com/mozilla/rust/issues/11875 >> >>> >>> >>> 6. impl ToStr for custom struct fails: >>> error: conflicting implementations for trait `std::to_str::ToStr` >>> note: conflicting implementation in crate `std` >>> Is it a bug? Is Show implicitly assumed for all struct's? >> >> >> This is because ToStr is implemented for all Show implementations. You >> can't implement ToStr, because if you then implemented Show, you'd have >> conflicting implementations. #[deriving(Show)] on your structs is probably >> all you want. >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > -Thad > +ThadGuidry > Thad on LinkedIn From comexk at gmail.com Wed May 28 20:10:57 2014 From: comexk at gmail.com (comex) Date: Wed, 28 May 2014 23:10:57 -0400 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: On Wed, May 28, 2014 at 10:17 PM, Oleg Eterevsky wrote: > Suppose, I want to add a new argument to a function in a > backwards-compatible way. In Python I provide a default and everything > works fine. In C++ or Java I write something like This came up a few days ago in the discussion about Qt bindings. I associate function overloading with pitfalls like: - Methods which do different things depending on the number or types of arguments. Very very bad, since it's difficult to tell which overload is being used by skimming, and differences in functionality deserve names - but from my memory, rather common in practice. - Not being able to tell which overload is being used, even looking relatively closely, because of conversion wonkiness. Admittedly wouldn't really be a problem in Rust the way it is in C++, but if the alternatives depend on traits, you might have to figure out which trait the object you passed is actually using. - Excessive number of overloads for convenience, which are all specific to that method, requiring a bunch of boilerplate to implement and not generalizing for the API user to others. For example, from that discussion, http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect - where, e.g., just asking the user to write QRect(x, y, w, h) instead of passing x, y, w, h as arguments would save several overloads. Though this doesn't apply to your example, many convenience types of overloads can be emulated using traits. On the other hand, I generally like keyword and default arguments. However, from my experience in Python it's often necessary when function A wraps function B to have the same default value in both declarations, which is problematic if the default needs to change. (Not *necessary* exactly, since passing around *args, **kwargs works too, but I'm not sure what that would look like in Rust, and I avoid it in Python because it makes it less clear from the declaration what arguments the method accepts.) Thus I think it might be better to make argument presence or absence somehow syntactic sugar for passing an Option rather than the usual behavior of specifying a default. But I don't know what the contributors think about it. From kevin at sb.org Wed May 28 20:36:48 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 20:36:48 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: On May 28, 2014, at 6:00 PM, Benjamin Striegel wrote: > To reiterate, it simply doesn't make sense to ask what the length of a string is. You may as well ask what color the string is, or where the string went to high school, or how many times the string rode the roller coaster that one year on the first day of summer vacation when the string's parents took the string to that amusement park and the weather said that it was going to rain so there were almost no crowds that day but then it didn't rain and all the rides were open with absolutely no lines whatsoever. As amusing as this imagery is, you're still arguing from faulty premise, which is that the concept of a "string" has not been well-defined. The nebulous "string", as it applies to the general category of programming languages, does indeed not have a well-defined length. But Rust's strings (both String and str) are very explicitly defined as a utf-8 encoded sequence. And when dealing with a sequence in a precise encoding, the natural unit to work with is the code unit (and this has precedence in other languages, such as JavaScript, Obj-C, and Go). --- My interpretation of your arguments is that your real objection is that you think that calling it len() will mean people won't even think about the fact that there's a difference between byte length and character length, because they'll be too used to working with ASCII data, and that they'll write code that breaks when forced to confront the difference. This is true regardless of how len() is defined (whether it's in bytes, in UTF-16 characters, in unicode scalar values, etc). My assertion is that calling the method .byte_len() will not force anyone to deal with non-ASCII data if they don't want to, it will only annoy everyone by being overly verbose, even more so when you rename .slice() to .byte_slice(), etc. I also believe that renaming .slice() to .byte_slice() is unambiguously wrong, as the name implies that it returns &[u8] when it doesn't. And similarly, that renaming just .len() to .byte_len() without renaming .slice() to .byte_slice() is also wrong. This means you cannot rename .len() to .byte_len() without introducing unambiguously wrong naming elsewhere. --- Does this accurately represent your argument? And do you have any rebuttal to my argument that hasn't already been said? If the answers are "yes" and "no" respectively, then I agree, we will have to simply live with being in disagreement. > Oh and while we're belligerently bikeshedding, we should rename `to_str` to `to_string` once we rename `StrBuf` to `String`. :) We've already renamed StrBuf to String, but I agree that .to_str() makes more sense as .to_string(). I was assuming that would eventually get renamed, although I just realized that it would then conflict with StrAllocating's .to_string() method, which is rather unfortunate. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From kevin at sb.org Wed May 28 21:02:47 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 21:02:47 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: On May 28, 2014, at 5:38 PM, Oleg Eterevsky wrote: > 4. It looks like vectors can be concatenated with + operations, but > strings can't. Is it deliberate? Partially. It's fallout of all the changes that strings have been going through lately. And [PR #14482][] reintroduces + for strings, but it hasn't been accepted yet. [PR #14482]: https://github.com/mozilla/rust/pull/14482 -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From spam at scientician.net Wed May 28 21:16:27 2014 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 29 May 2014 06:16:27 +0200 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: On 2014-05-29 05:36, Kevin Ballard wrote: [--snip--] > And when dealing with a sequence in a precise encoding, the natural unit to work > with is the code unit (and this has precedence in other languages, such as JavaScript, Obj-C, and Go). > JavaScript: $ node > var s = "h?"; // Note the accent undefined > s.length; 2 Rust: $ cat fn main() { let l = "h?".len(); // Note the accent println!("{:u}", l); } $ rustc hello.rs $ ./hello 3 No matter how defective the notion of "length" may be, personally I think that people will expect the former, but will be very surprised by the latter. There are certainly cases where the JavaScript version is wrong, but I conjecture that it "works" for the vast majority of cases that people and programs are likely to encounter. IMO expecting people to read docs is a poor substitute for being explicit in a method name about what the method does, especially when it costs only 5 characters. The Principle of Least Astonishment and all that. As a rule people don't read docs until they've encountered a "bug" in their expectations vs. what the language/library actually does -- at which point they're already annoyed and don't need to be further annoyed by the realization that "it does something completely non-intuitive" (for their perspective). Thankfully the programming world has become more aware of i18n issues, but for people who still predominantly use ASCII such bugs may lay dormant for a long time before anyone discovers them. Just my ?0.02. Regards, From oleg at eterevsky.com Wed May 28 21:26:49 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Wed, 28 May 2014 21:26:49 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: Thanks for the detailed reply. I agree that overloaded functions can be used to shoot yourself in the foot. Fortunately, I haven't yet seen any code that I would care to read, designed so badly that overloaded functions would do essentially different things depending on the number or type of arguments. The problem with too many versions of a function in C++ is quite real, but they are there for a reason: they are usually required to deal with different combinations of references and const parameters. As to the last objection, it is very much dependent on the API in question. Those overloads may sometimes be beneficial. In any case, I do not think that a feature of the language that has legitimate uses should be banned just to prevent bad programmers from abusing it. On Wed, May 28, 2014 at 8:10 PM, comex wrote: > On Wed, May 28, 2014 at 10:17 PM, Oleg Eterevsky wrote: >> Suppose, I want to add a new argument to a function in a >> backwards-compatible way. In Python I provide a default and everything >> works fine. In C++ or Java I write something like > > This came up a few days ago in the discussion about Qt bindings. > > I associate function overloading with pitfalls like: > - Methods which do different things depending on the number or types > of arguments. Very very bad, since it's difficult to tell which > overload is being used by skimming, and differences in functionality > deserve names - but from my memory, rather common in practice. > - Not being able to tell which overload is being used, even looking > relatively closely, because of conversion wonkiness. Admittedly > wouldn't really be a problem in Rust the way it is in C++, but if the > alternatives depend on traits, you might have to figure out which > trait the object you passed is actually using. > - Excessive number of overloads for convenience, which are all > specific to that method, requiring a bunch of boilerplate to implement > and not generalizing for the API user to others. For example, from > that discussion, > http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect - where, e.g., > just asking the user to write QRect(x, y, w, h) instead of passing x, > y, w, h as arguments would save several overloads. > > Though this doesn't apply to your example, many convenience types of > overloads can be emulated using traits. > > On the other hand, I generally like keyword and default arguments. > However, from my experience in Python it's often necessary when > function A wraps function B to have the same default value in both > declarations, which is problematic if the default needs to change. > (Not *necessary* exactly, since passing around *args, **kwargs works > too, but I'm not sure what that would look like in Rust, and I avoid > it in Python because it makes it less clear from the declaration what > arguments the method accepts.) Thus I think it might be better to > make argument presence or absence somehow syntactic sugar for passing > an Option rather than the usual behavior of specifying a default. But > I don't know what the contributors think about it. From comexk at gmail.com Wed May 28 21:49:01 2014 From: comexk at gmail.com (comex) Date: Thu, 29 May 2014 00:49:01 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: On Thu, May 29, 2014 at 12:16 AM, Bardur Arantsson wrote: > No matter how defective the notion of "length" may be, personally I > think that people will expect the former, but will be very surprised by > the latter. There are certainly cases where the JavaScript version is > wrong, but I conjecture that it "works" for the vast majority of cases > that people and programs are likely to encounter. Why would they expect the former? What use is the codepoint count? It shouldn't be blindly used in conjunction with slicing up the string, because you need to respect grapheme clusters. It shouldn't be used to remember the positions of substrings, because seeking to a codepoint index in a UTF-8 string is slow, so byte offsets should be used instead. Of course, this could be seen as an argument in favor of naming clarity. Also, I hope nobody uses JavaScript .length for any purpose other than what in Rust would be a byte length, since it doesn't actually count codepoints... '?'.length 2 From ml at isaac.cedarswampstudios.org Wed May 28 21:51:02 2014 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu, 29 May 2014 00:51:02 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: <5386BCB6.4060103@isaac.cedarswampstudios.org> Hi all, I don't suggest seeing Javascript as a great example for Rust. It uses UTF-16, but was created back when UTF-16 was UCS-2, so two-code-unit codepoints are poorly supported in Javascript (e.g. you can't use them in regex character classes). On 05/29/2014 12:16 AM, Bardur Arantsson wrote: > JavaScript: > > $ node > > var s = "h?"; // Note the accent > undefined > > s.length; > 2 If you put that into NFD instead of NFC you get a different answer. $ node > "h?".length 2 > "hi?".length 3 ("h?" and "hi?"'s length also differ in UTF-8: 3 bytes for NFC, 4 for NFD.) -Isaac (No opinion on the Rust question at hand.) From spam at scientician.net Wed May 28 22:16:26 2014 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 29 May 2014 07:16:26 +0200 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: On 2014-05-29 06:49, comex wrote: > On Thu, May 29, 2014 at 12:16 AM, Bardur Arantsson wrote: >> No matter how defective the notion of "length" may be, personally I >> think that people will expect the former, but will be very surprised by >> the latter. There are certainly cases where the JavaScript version is >> wrong, but I conjecture that it "works" for the vast majority of cases >> that people and programs are likely to encounter. > > Why would they expect the former? [--snip--] It's behavior that people are used to. My point isn't really whether it's correct or not -- my point is more about adherence to the Principle of Least Astonishment. Which being *explicit* here would do by naming it "byte_len" or "code_point_count" or some such. > > Of course, this could be seen as an argument in favor of naming clarity. Exactly, and that's really my point. > > Also, I hope nobody uses JavaScript .length for any purpose other than > what in Rust would be a byte length, since it doesn't actually count > codepoints... > > '?'.length > 2 They do. For e.g. client-side form validation and such. Or course when you do that you usually also restrict the string content to letters, so YMMV. Regards, From kevin at sb.org Wed May 28 22:47:28 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 28 May 2014 22:47:28 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> Message-ID: <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> On May 28, 2014, at 9:16 PM, Bardur Arantsson wrote: > Rust: > > $ cat > fn main() { > let l = "h?".len(); // Note the accent > println!("{:u}", l); > } > $ rustc hello.rs > $ ./hello > 3 > > No matter how defective the notion of "length" may be, personally I > think that people will expect the former, but will be very surprised by > the latter. There are certainly cases where the JavaScript version is > wrong, but I conjecture that it "works" for the vast majority of cases > that people and programs are likely to encounter. The JavaScript version is quite wrong. Isaac points out that NFC vs NFD can change the result, although that's really an issue with grapheme clusters vs codepoints. More interestingly, JavaScript's idea of string length is wrong for anything outside of the BMP: $ node > "?".length 2 This is because it was designed for UCS-2 instead of UTF-16, so .length actually returns the number of UCS-2 code units in the string. Incidentally, that means that JavaScript and Rust do have the same fundamental definition of length (which is to say, number of code units). They just have a different code unit. In JavaScript it's confusing because you can learn to use JavaScript quite well without ever realizing that it's UCS-2 code units (i.e. that it's not codepoints). In Rust, we're very clear that our strings are utf-8 sequences, so it should surprise nobody when the length turns out to be the number of utf-8 code units. FWIW, Go uses utf-8 code units as well, and nobody seems to be confused about that. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From spam at scientician.net Wed May 28 23:27:24 2014 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 29 May 2014 08:27:24 +0200 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> Message-ID: On 2014-05-29 07:47, Kevin Ballard wrote: > > The JavaScript version is quite wrong. Isaac points out that NFC vs NFD can change the result, > although that's really an issue with grapheme clusters vs codepoints. More interestingly, > JavaScript's idea of string length is wrong for anything outside of the BMP: > My point wasn't about JavaScript specifically; it's really that using such an overloaded term (length) for a very specific operation seems like a bad idea. [--snip--] > FWIW, Go uses utf-8 code units as well, and nobody seems to be confused about that. "Nobody" seems a bit hyperbolic, but I guess we'll see :). Anyway, I have no horse in this race, so I'll just leave it at that. Regards, From dpx.infinity at gmail.com Wed May 28 23:32:15 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Thu, 29 May 2014 10:32:15 +0400 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: > It happens even for this: > > struct Test { > a: int > } > > impl ToStr for Test { > fn to_str(&self) -> String { > self.a.to_str() > } > } > > As you can see, Test is not implementing Show, so I assumed that I > could implement ToStr instead. I suspect that there is somewhere an > implementation > impl Show for T > and after I implemented ToStr, Test automatically became an > implementation of Show, which in turn led to conflict. I might be > wrong though. I'd like to note that if there was a sane implementation > of overloaded functions, this could be resolved. Yes, that's how trait resolution currently works. There is an RFC on that which turns traits into something resembling type classes in Haskell, with proper resolution of overlapping instances: https://github.com/rust-lang/rfcs/pull/48, however, I'm not sure if it will help in this case. Currently if you want to implement `ToStr` manually, you should implement `std::fmt::Show` instead: use std::fmt; impl fmt::Show for Test { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "{}", self.a) } } Now you can use `to_str()`: let t = Test { a: 10 } println!("{}", t.to_str()); // 10 2014-05-29 6:17 GMT+04:00 Oleg Eterevsky : > Thanks for your answers. Can't say I understand or agree with all the decisions. > >> 1. Not everyone prefers overloaded functions, or default arguments. > > Suppose, I want to add a new argument to a function in a > backwards-compatible way. In Python I provide a default and everything > works fine. In C++ or Java I write something like > > fn test(old_arg: int, new_arg: int) { > ... > } > > fn test(old_arg: int) { > test(old_arg, 0) > } > > and everything is still good. What should I do in Rust? > >> 2. Design decision. Basically, we take Erlang's philosophy: recovering > from errors is tricky and error-prone. > > So basically this mean that you could emulate exceptions by running a > co-routing and catching its state? It makes sense, though it sounds > like it overcomplicates things a bit from programmer's perspective. > Also I'm a bit worried about the number of unwrap's. > >>> 4. It looks like vectors can be concatenated with + operations, but > strings can't. Is it deliberate? >> 4. I believe so, yes. We try not to be overload-heavy. > > In my experience + is much more often used for strings than for > vectors. Is it not? > >> 6. I believe there is a default implementation, yes. > > It happens even for this: > > struct Test { > a: int > } > > impl ToStr for Test { > fn to_str(&self) -> String { > self.a.to_str() > } > } > > As you can see, Test is not implementing Show, so I assumed that I > could implement ToStr instead. I suspect that there is somewhere an > implementation > impl Show for T > and after I implemented ToStr, Test automatically became an > implementation of Show, which in turn led to conflict. I might be > wrong though. I'd like to note that if there was a sane implementation > of overloaded functions, this could be resolved. > > On Wed, May 28, 2014 at 5:47 PM, Steve Klabnik wrote: >> A few quick intro answers. Just the high level, not comprehensive. >> >> 1. Not everyone prefers overloaded functions, or default arguments. I >> know pcwalton has strong feelings about the first, so I'll leave him >> to that :) >> >> 2. Design decision. Basically, we take Erlang's philosophy: recovering >> from errors is tricky and error-prone. Better to let a task fail and >> start a new one rather than to try to re-start one in the middle of >> whatever it's doing. >> >> 3. No opinions, but know that all of this has been changing a _lot_ >> recently, this may even be planned. >> >> 4. I believe so, yes. We try not to be overload-heavy. >> >> 5. This is being worked on. Vec is a new construct anyway. >> >> 6. I believe there is a default implementation, yes. >> >> 7. I'm not even getting into this one. There's been a toooooon of >> discussion about this lately. >> https://github.com/rust-lang/rfcs/search?q=mutability&ref=cmdform&type=Issues >> >> Hope that starts to kick off some good discussion. :) > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From hallimanearavind at gmail.com Wed May 28 23:37:32 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Thu, 29 May 2014 12:07:32 +0530 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> Message-ID: I think returning length of string in bytes is just fine. Since I didn't know about the availability of char_len in rust caused this confusion. python 2.7/Perl/PHP - Returns length of string in bytes, Python 3/JS returns number of codepoints. As long as we can iterate through chars without worrying about bytes length/codepoint length, then it should be fine. let unicode_str = String::from_str("??????"); let v: Vec = unicode_str.as_slice().chars().collect(); for c in v.iter(){ println!("{}", c); } I wonder if chars() available for String itself, so that we can avoid running as_slice().chars() -- Regards Aravinda | ?????? http://aravindavk.in On Thu, May 29, 2014 at 11:17 AM, Kevin Ballard wrote: > On May 28, 2014, at 9:16 PM, Bardur Arantsson > wrote: > > > Rust: > > > > $ cat > > fn main() { > > let l = "h?".len(); // Note the accent > > println!("{:u}", l); > > } > > $ rustc hello.rs > > $ ./hello > > 3 > > > > No matter how defective the notion of "length" may be, personally I > > think that people will expect the former, but will be very surprised by > > the latter. There are certainly cases where the JavaScript version is > > wrong, but I conjecture that it "works" for the vast majority of cases > > that people and programs are likely to encounter. > > The JavaScript version is quite wrong. Isaac points out that NFC vs NFD > can change the result, although that's really an issue with grapheme > clusters vs codepoints. More interestingly, JavaScript's idea of string > length is wrong for anything outside of the BMP: > > $ node > > "?".length > 2 > > This is because it was designed for UCS-2 instead of UTF-16, so .length > actually returns the number of UCS-2 code units in the string. > > Incidentally, that means that JavaScript and Rust do have the same > fundamental definition of length (which is to say, number of code units). > They just have a different code unit. In JavaScript it's confusing because > you can learn to use JavaScript quite well without ever realizing that it's > UCS-2 code units (i.e. that it's not codepoints). In Rust, we're very clear > that our strings are utf-8 sequences, so it should surprise nobody when the > length turns out to be the number of utf-8 code units. > > FWIW, Go uses utf-8 code units as well, and nobody seems to be confused > about that. > > -Kevin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Thu May 29 00:25:24 2014 From: kevin at sb.org (Kevin Ballard) Date: Thu, 29 May 2014 00:25:24 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> Message-ID: <50804E59-BEA9-4D19-8D18-B1B331191BA3@sb.org> On May 28, 2014, at 11:37 PM, Aravinda VK wrote: > I wonder if chars() available for String itself, so that we can avoid running as_slice().chars() This is a temporary issue. Once DST lands we will likely implement Deref for String, which will make all &str methods work transparently on String. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From simon.sapin at exyr.org Thu May 29 00:33:52 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 29 May 2014 08:33:52 +0100 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <50804E59-BEA9-4D19-8D18-B1B331191BA3@sb.org> References: <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> <50804E59-BEA9-4D19-8D18-B1B331191BA3@sb.org> Message-ID: <5386E2E0.7060301@exyr.org> On 29/05/2014 08:25, Kevin Ballard wrote: > This is a temporary issue. Once DST lands we will likely implement > Deref for String, which will make all &str methods work > transparently on String. Until then, is there a reason not to have String implement the StrSlice trait? -- Simon Sapin From masklinn at masklinn.net Thu May 29 00:39:49 2014 From: masklinn at masklinn.net (Masklinn) Date: Thu, 29 May 2014 09:39:49 +0200 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> Message-ID: <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> On 2014-05-29, at 08:37 , Aravinda VK wrote: > I think returning length of string in bytes is just fine. Since I didn't know about the availability of char_len in rust caused this confusion. > > python 2.7 - Returns length of string in bytes, Python 3 returns number of codepoints. Nope, depends on the string type *and* on compilation options. * Python 2's `str` and Python 3's `bytes` are byte sequences, their len() returns their byte counts. * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code units count which may be UCS2 or UCS4 (depending whether the interpreter was compiled with `?enable-unicode=ucs2` ? the default ? or `?enable-unicode=ucs4`. Only the latter case is a true code points count. * Python 3.3's `str` switched to the Flexible String Representation, the build-time option disappeared and len() always returns the number of codepoints. Note that in no case to len() operations take normalisation or visual composition in account. > JS returns number of codepoints. JS returns the number of UCS2 code units, which is twice the number of code points for those in astral planes. From klesnil at centrum.cz Thu May 29 00:24:39 2014 From: klesnil at centrum.cz (Jan Klesnil) Date: Thu, 29 May 2014 09:24:39 +0200 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: <5386E0B7.90404@centrum.cz> Hi, On 29.5.2014 02:38, Oleg Eterevsky wrote: > 2. What about exceptions? Is it a design decision not to support them, > or are they planned for some future version? I understand, that > exceptions make memory management more difficult, but maybe there are > ways to restrict their usage to avoid problems (like making it > impossible to pass references as exception parameters?) I had the same question once. The answer was that exception-safe code is difficult to write and maintain. Under the closer investigation the problem is that shared data between inner and outside code of the try block is a problem and it is similar problem to concurrent programming. Therefore tasks are building blocks for concurrent code as well for exception-like error handling. The only thing that Rust current lacks is a way to run task synchronously on the stack of the caller just for the case when recovery from fail is needed but concurrency is not. > > -- > Thanks, > Oleg Eterevsky. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From christophe.pedretti at gmail.com Thu May 29 08:38:13 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Thu, 29 May 2014 17:38:13 +0200 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time Message-ID: Hello all, i know that this issue is already covered by issues #9113 #6393 and #9113 but actually i have no solution. My code is a library for accessing databases. In my example, the database represented by db containes a table t with columns i:integer, f:float, t:text, b:blob. Everything works fine except the following code used to test my library match db.prepare_statement("SELECT i,f,t,b FROM t where t like ?;") { Ok(mut st) => { st.set_string(1, "%o%"); for i in st.execute_query() { match i { Ok(s) => println!("{}:{}:{}:{}", s.get_long(0), s.get_double(1), s.get_string(2), s.get_blob(3) ), Err(e) => match e.detail { Some(s) => println!("{}", s), None => () } } } st.set_string(1, "%e%"); * <- PROBLEM HERE* for i in st.execute_query() {* <- PROBLEM HERE* ... } }, Err(e) => match e.detail { None => (), Some(s) => println!("{}", s) } } The compilation error says test-db.rs:71:8: 71:10 error: cannot borrow `st` as mutable more than once at a time test-db.rs:71 st.set_string(1, "%e%"); ^~ test-db.rs:61:17: 61:19 note: previous borrow of `st` occurs here; the mutable borrow prevents subse quent moves, borrows, or modification of `st` until the borrow ends test-db.rs:61 for i in st.execute_query() { ^~ test-db.rs:88:7: 88:7 note: previous borrow ends here test-db.rs:58 match db.prepare_statement("SELECT i,f,t,b FROM t wh ere t like ?;") { ... test-db.rs:88 } ^ error: aborting due to previous error do we have a solution for #6393 ? Thanks -- Christophe http://chris-pe.github.io/Rustic/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Thu May 29 11:22:21 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Thu, 29 May 2014 22:22:21 +0400 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: Hi, Christophe, Won't wrapping the first `for` loop into curly braces help? I suspect this happens because of `for` loop desugaring, which kind of "leaves" the iterator created by `execute_query()` "in scope" (not really, but only for borrow checker). 2014-05-29 19:38 GMT+04:00 Christophe Pedretti : > Hello all, > > i know that this issue is already covered by issues #9113 #6393 and #9113 > but actually i have no solution. My code is a library for accessing > databases. In my example, the database represented by db containes a table t > with columns i:integer, f:float, t:text, b:blob. > > Everything works fine except the following code used to test my library > > match db.prepare_statement("SELECT i,f,t,b FROM t where t like ?;") { > > Ok(mut st) => { > > st.set_string(1, "%o%"); > > for i in st.execute_query() { > > match i { > > Ok(s) => println!("{}:{}:{}:{}", s.get_long(0), s.get_double(1), > s.get_string(2), s.get_blob(3) ), > > Err(e) => match e.detail { > > Some(s) => println!("{}", s), > > None => () > > } > > } > > } > > st.set_string(1, "%e%"); <- PROBLEM HERE > for i in st.execute_query() { <- PROBLEM HERE > > ... > } > > }, > Err(e) => match e.detail { > > None => (), > > Some(s) => println!("{}", s) > > } > > } > > The compilation error says > > test-db.rs:71:8: 71:10 error: cannot borrow `st` as mutable more than once > at a time > test-db.rs:71 > st.set_string(1, "%e%"); > ^~ > test-db.rs:61:17: 61:19 note: previous borrow of `st` occurs here; the > mutable borrow prevents subse > quent moves, borrows, or modification of `st` until the borrow ends > test-db.rs:61 for i in > st.execute_query() { > ^~ > test-db.rs:88:7: 88:7 note: previous borrow ends here > test-db.rs:58 match > db.prepare_statement("SELECT i,f,t,b FROM t wh > ere t like ?;") { > ... > test-db.rs:88 } > ^ > error: aborting due to previous error > > do we have a solution for #6393 ? > > Thanks > > -- > Christophe > http://chris-pe.github.io/Rustic/ > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From oleg at eterevsky.com Thu May 29 11:32:39 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 11:32:39 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: > Overloaded functions are unnecessary in Rust. In C++ they are heavily used because of templates use duck-typing, but Rust uses explicit interfaces (typeclass-like) which makes it unnecessary. I agree. This is one of the main use cases for overloaded functions in C++, and it is irrelevant to Rust. Considering this, I'd say, that introducing optional named parameters might be a better solution. > let mut result = vec!(); // type of "result" is "Vec<...>" which is only partially known > for x in some_range.iter() { > doit(result, *x); // there is a single "doit" in scope, whose arguments is "Vec" thus this is the type of "result" > } To be honest, such a non-local type inference creeps me out. It might be an unending source of errors. While it probably can be used in some quick and dirty code snippets, I would never commit such code to a repository of any self-respecting project. > Named parameters and default values are just syntactic sugar; they might feel handy, indeed, but in general they can be emulated => Rust already has named parameters for "struct" initialization, and it also has functional update for those "struct" thus as long as you are willing to add one more symbol: While it is indeed a syntactic sugar, I believe that it's an important one. (You may argue that all of Python is just syntactic sugar over some dictionary operations and all of Haskell is syntactic sugar over linked lists.) I can't imagine anyone adding an explicit struct type for each and every function that might be expanded in future, or just has optional arguments. >> 2. What about exceptions? > As mentioned, the issue is about recovery: you modified a lot of stuff in your "try" that is still accessible afterward, is it in a safe state ? is it in sensible state ? No one knows, and your compiler does not care. Tasks enforce explicitness about what is modified, which helps in auditing. Just to make sure I understand how it all should work. Suppose I have a parser, that raises ParseError. I might use it like this: let something = Something::new(); try { something.parse_str("..."); } catch ParseError as e { println!("ParseError at {}:{}", e.row, e.col); return; } What would be Rust alternative, except passing the errors all around parser? Doesn't it grow parser code by at least 50%? >> 3. It seems like almost any string operation requires as_slice(). >> Can't various string methods be also implemented for String? > It's the lowest common denominator approach, a slice is cheap (no memory allocation) and universal (may refer either to heap allocated buffer or static buffer). Why not make a trait BaseString and apply all the operations to it? On Thu, May 29, 2014 at 3:44 AM, Matthieu Monrocq wrote: > > > > On Thu, May 29, 2014 at 2:38 AM, Oleg Eterevsky wrote: >> >> Hi! >> >> I've just recently started learning Rust. Here's a few questions that >> I have after writing about a hundred lines of code: >> >> 1. Why neither overloaded function, nor default values for arguments >> are supported? In statically typed language overloaded functions are >> quite safe and convenient. Also, from what I see, overloaded functions >> could be used in various use cases instead of macros. >> > > Overloaded functions are unnecessary in Rust. In C++ they are heavily used > because of templates use duck-typing, but Rust uses explicit interfaces > (typeclass-like) which makes it unnecessary. > > Overloaded functions also don't play too well with type inference. C++ works > around this by having a very simple type inference (ie, it only deduces the > return type), but Rust's type inference is more advanced: > > let mut result = vec!(); // type of "result" is "Vec<...>" which is only > partially known > > for x in some_range.iter() { > doit(result, *x); // there is a single "doit" in scope, whose > arguments is "Vec" thus this is the type of "result" > } > > If you were able to overload "doit" though, suddenly things would get hairy, > and you would have to start explicitly typing your variables left and right. > > Thus, even besides the confusion a human being experiences (which overload > is called ?) and the over-abuse of overloads in the first place (Qt seems to > be doing nicely in that domain), there is a technical trade-off: better type > inference or function overload ? > > Note: it also means that compiler error-messages are generally more > explicit; tried forgetting to implementation "operator<<" for a type and see > what your favorite C++ compiler reports ;) > > > Named parameters and default values are just syntactic sugar; they might > feel handy, indeed, but in general they can be emulated => Rust already has > named parameters for "struct" initialization, and it also has functional > update for those "struct" thus as long as you are willing to add one more > symbol: > > struct FooArgs { x: int, y: int, } > > static DEFAULT_FOO: FooArgs = FooArgs { x: 4, y: 5, } > > fn foo(args: FooArgs) {} > > fn main() { > foo(FooArgs{x: 3, .. DEFAULT_FOO}) > } > > I personally feel that the name "FooArgs" could be inferred in the call > (since there is no overload of "foo" there is no ambiguity) which would > assist in this pattern. There is also the issue that static cannot be build > from arbitrary functions, but that may be lifted with Compilation Time > Function Evaluation one day, and in the mean time you can have a > FooArgs::default() that computes the defaults. > > >> >> 2. What about exceptions? Is it a design decision not to support them, >> or are they planned for some future version? I understand, that >> exceptions make memory management more difficult, but maybe there are >> ways to restrict their usage to avoid problems (like making it >> impossible to pass references as exception parameters?) >> > As mentioned, the issue is about recovery: you modified a lot of stuff in > your "try" that is still accessible afterward, is it in a safe state ? is it > in sensible state ? No one knows, and your compiler does not care. Tasks > enforce explicitness about what is modified, which helps in auditing. > >> >> 3. It seems like almost any string operation requires as_slice(). >> Can't various string methods be also implemented for String? >> > It's the lowest common denominator approach, a slice is cheap (no memory > allocation) and universal (may refer either to heap allocated buffer or > static buffer). > > Rust is working on DST (Dynamically Sized Types) and once this lands String > will be able to implement Deref, which will ease things. There is also been > talk about auto-deref to make it even painless. > >> >> 4. It looks like vectors can be concatenated with + operations, but >> strings can't. Is it deliberate? > > > As someone else answered, it could be done. > > Personally though I've never liked that. '+' is mathematically a commutative > operation and catenation is not a commutative operation. Also, in the > absence of overloading this means to catenate you have to implement the Add > trait. This is just weird. I would prefer infix function calls (`cat`) for > example, or another dedicated operator (++ ?) > >> >> >> 5. Simple indexing doesn't work for vectors: >> let a = vec![1, 2, 3]; >> println!("{}", a[0]); >> It's a bit surprising... >> > Could probably be implemented, may have to wait for DST though. > >> >> 6. impl ToStr for custom struct fails: >> error: conflicting implementations for trait `std::to_str::ToStr` >> note: conflicting implementation in crate `std` >> Is it a bug? Is Show implicitly assumed for all struct's? >> >> 7. The usage of mut is a bit confusing. It is supposed to be used as a >> qualifier for a variable, but it quickly becomes a part of the type, >> when you define functions like >> fn test(something: &mut Something) >> Maybe it makes sense move mut their? Or distinguish mut as a variable >> qualifier vs const as a propery of type? >> > > There has been an extended discussion about it, and I am also slightly > confused by the use of `mut`. It reads "mutability" but in the case of > references also implies exclusivity... > > At the end of the day though, there's already a number of high-profiles > changes going on (such as the above DST), so for now it's wait and see. Once > those are implemented and the core developers have a bit more time on their > plate, the issue might be revisited. > >> >> -- >> Thanks, >> Oleg Eterevsky. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > From comexk at gmail.com Thu May 29 11:45:03 2014 From: comexk at gmail.com (comex) Date: Thu, 29 May 2014 14:45:03 -0400 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: On Thu, May 29, 2014 at 2:32 PM, Oleg Eterevsky wrote: > What would be Rust alternative, except passing the errors all around > parser? Doesn't it grow parser code by at least 50%? With things like try! and the various helper methods on Result/Option, passing errors around is supposed to be easier than in other languages. I haven't done much with it, so I don't know how well it works. You can also spawn a task for the parser, since the internal parser data structures don't need to be kept around after failure or anything; as mentioned in a previous post, a better way to do this synchronously on the same thread might be added. Of course, depending on what you're parsing, you may want to continue after errors to report further problems, in which case the exception version wouldn't work anyway. From dnfagnan at gmail.com Thu May 29 11:53:54 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Thu, 29 May 2014 12:53:54 -0600 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: ?> With things like try! and the various helper methods on Result/Option, passing errors around is supposed to be easier than in other languages. I haven't done much with it, so I don't know how well it works. I can attest to it working quite well. > What would be Rust alternative, except passing the errors all around parser? Doesn't it grow parser code by at least 50%? I'm actually writing the next version of "Practicality With Rust" covering error handling, as that's a popular request for new comers coming from exception-based, or -1 based languages. The `try!` macro, along with functions like `map_err()` allow you to implement custom error and result types similar to `IoError` and `IoResult`, respectively. [Cargo currently does this, too.]( https://github.com/carlhuda/cargo/blob/master/src/cargo/util/result.rs) -- Daniel Fagnan @TheHydroImpulse http://hydrocodedesign.com M: (780) 983-4997 On Thu, May 29, 2014 at 12:45 PM, comex wrote: > On Thu, May 29, 2014 at 2:32 PM, Oleg Eterevsky > wrote: > > What would be Rust alternative, except passing the errors all around > > parser? Doesn't it grow parser code by at least 50%? > > With things like try! and the various helper methods on Result/Option, > passing errors around is supposed to be easier than in other > languages. I haven't done much with it, so I don't know how well it > works. > > You can also spawn a task for the parser, since the internal parser > data structures don't need to be kept around after failure or > anything; as mentioned in a previous post, a better way to do this > synchronously on the same thread might be added. > > Of course, depending on what you're parsing, you may want to continue > after errors to report further problems, in which case the exception > version wouldn't work anyway. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at eterevsky.com Thu May 29 12:20:33 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 12:20:33 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: I'm looking forward to read this article. Thanks for the link to CargoResult. I am still not sure how this error is pass from the failing task... On Thu, May 29, 2014 at 11:53 AM, Daniel Fagnan wrote: >> With things like try! and the various helper methods on Result/Option, > passing errors around is supposed to be easier than in other > languages. I haven't done much with it, so I don't know how well it > works. > > I can attest to it working quite well. > >> What would be Rust alternative, except passing the errors all around > parser? Doesn't it grow parser code by at least 50%? > > I'm actually writing the next version of "Practicality With Rust" covering > error handling, as that's a popular request for new comers coming from > exception-based, or -1 based languages. > > The `try!` macro, along with functions like `map_err()` allow you to > implement custom error and result types similar to `IoError` and `IoResult`, > respectively. [Cargo currently does this, > too.](https://github.com/carlhuda/cargo/blob/master/src/cargo/util/result.rs) > > > -- > Daniel Fagnan > @TheHydroImpulse > http://hydrocodedesign.com > M: (780) 983-4997 > > > On Thu, May 29, 2014 at 12:45 PM, comex wrote: >> >> On Thu, May 29, 2014 at 2:32 PM, Oleg Eterevsky >> wrote: >> > What would be Rust alternative, except passing the errors all around >> > parser? Doesn't it grow parser code by at least 50%? >> >> With things like try! and the various helper methods on Result/Option, >> passing errors around is supposed to be easier than in other >> languages. I haven't done much with it, so I don't know how well it >> works. >> >> You can also spawn a task for the parser, since the internal parser >> data structures don't need to be kept around after failure or >> anything; as mentioned in a previous post, a better way to do this >> synchronously on the same thread might be added. >> >> Of course, depending on what you're parsing, you may want to continue >> after errors to report further problems, in which case the exception >> version wouldn't work anyway. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > From matthieu.monrocq at gmail.com Thu May 29 13:17:23 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 29 May 2014 22:17:23 +0200 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: Does this mean that the desugaring of the for loop is incorrect ? Or at least, could be improved. On Thu, May 29, 2014 at 8:22 PM, Vladimir Matveev wrote: > Hi, Christophe, > > Won't wrapping the first `for` loop into curly braces help? I suspect > this happens because of `for` loop desugaring, which kind of "leaves" > the iterator created by `execute_query()` "in scope" (not really, but > only for borrow checker). > > 2014-05-29 19:38 GMT+04:00 Christophe Pedretti < > christophe.pedretti at gmail.com>: > > Hello all, > > > > i know that this issue is already covered by issues #9113 #6393 and #9113 > > but actually i have no solution. My code is a library for accessing > > databases. In my example, the database represented by db containes a > table t > > with columns i:integer, f:float, t:text, b:blob. > > > > Everything works fine except the following code used to test my library > > > > match db.prepare_statement("SELECT i,f,t,b FROM t where t like ?;") { > > > > Ok(mut st) => { > > > > st.set_string(1, "%o%"); > > > > for i in st.execute_query() { > > > > match i { > > > > Ok(s) => println!("{}:{}:{}:{}", s.get_long(0), s.get_double(1), > > s.get_string(2), s.get_blob(3) ), > > > > Err(e) => match e.detail { > > > > Some(s) => println!("{}", s), > > > > None => () > > > > } > > > > } > > > > } > > > > st.set_string(1, "%e%"); <- PROBLEM HERE > > for i in st.execute_query() { <- PROBLEM HERE > > > > ... > > } > > > > }, > > Err(e) => match e.detail { > > > > None => (), > > > > Some(s) => println!("{}", s) > > > > } > > > > } > > > > The compilation error says > > > > test-db.rs:71:8: 71:10 error: cannot borrow `st` as mutable more than > once > > at a time > > test-db.rs:71 > > st.set_string(1, "%e%"); > > ^~ > > test-db.rs:61:17: 61:19 note: previous borrow of `st` occurs here; the > > mutable borrow prevents subse > > quent moves, borrows, or modification of `st` until the borrow ends > > test-db.rs:61 for i in > > st.execute_query() { > > > ^~ > > test-db.rs:88:7: 88:7 note: previous borrow ends here > > test-db.rs:58 match > > db.prepare_statement("SELECT i,f,t,b FROM t wh > > ere t like ?;") { > > ... > > test-db.rs:88 } > > ^ > > error: aborting due to previous error > > > > do we have a solution for #6393 ? > > > > Thanks > > > > -- > > Christophe > > http://chris-pe.github.io/Rustic/ > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at eterevsky.com Thu May 29 14:22:17 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 14:22:17 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: >> What would be Rust alternative, except passing the errors all around >> parser? Doesn't it grow parser code by at least 50%? > Haskell has no exception, it has Monads instead. Rust reuses Option and Result (Maybe and Either in Haskell) with great success. For all my love to Haskell, I wouldn't consider it an example of a practical programming language. I mean, there aren't many projects written in Haskell of a size larger than GHC. >> Why not make a trait BaseString and apply all the operations to it? > It's "heavier", in several ways. > [...] > In short, Slice is just a superior alternative. I agree that it is conceptually simpler. But compare code, required to read one integer from a file in Python, C++ and Rust: a = int(f.read_line()) int a; f >> a; let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap(); Two unwrap's are caused by the lack of exceptions, as_slice is to convert String -> str, trim is because from_str doesn't skip whitespace (I suppose, the last one is non-essential). On Thu, May 29, 2014 at 1:27 PM, Matthieu Monrocq wrote: > > > > On Thu, May 29, 2014 at 8:32 PM, Oleg Eterevsky wrote: >> >> > Overloaded functions are unnecessary in Rust. In C++ they are heavily >> > used because of templates use duck-typing, but Rust uses explicit interfaces >> > (typeclass-like) which makes it unnecessary. >> >> I agree. This is one of the main use cases for overloaded functions in >> C++, and it is irrelevant to Rust. Considering this, I'd say, that >> introducing optional named parameters might be a better solution. >> >> > let mut result = vec!(); // type of "result" is "Vec<...>" which is only >> > partially known >> >> > for x in some_range.iter() { >> > doit(result, *x); // there is a single "doit" in scope, whose >> > arguments is "Vec" thus this is the type of "result" >> > } >> >> To be honest, such a non-local type inference creeps me out. It might >> be an unending source of errors. While it probably can be used in some >> quick and dirty code snippets, I would never commit such code to a >> repository of any self-respecting project. > > > Well, I don't find it creepy. I suppose it's just a matter of habit. It > seems a bit weird, at first, but even after just a couple of days it just > feels normal again (at least it did for me). > > Remark that it is local: local to the method. It's not at the level of > Haskell where the very signature of a method can be inferred (which gives > rise to infuriating error messages). > > All in all, it seems to strike a good balance. > >> >> >> > Named parameters and default values are just syntactic sugar; they might >> > feel handy, indeed, but in general they can be emulated => Rust already has >> > named parameters for "struct" initialization, and it also has functional >> > update for those "struct" thus as long as you are willing to add one more >> > symbol: >> >> While it is indeed a syntactic sugar, I believe that it's an important >> one. (You may argue that all of Python is just syntactic sugar over >> some dictionary operations and all of Haskell is syntactic sugar over >> linked lists.) I can't imagine anyone adding an explicit struct type >> for each and every function that might be expanded in future, or just >> has optional arguments. >> >> >> 2. What about exceptions? >> > As mentioned, the issue is about recovery: you modified a lot of stuff >> > in your "try" that is still accessible afterward, is it in a safe state ? is >> > it in sensible state ? No one knows, and your compiler does not care. Tasks >> > enforce explicitness about what is modified, which helps in auditing. >> >> Just to make sure I understand how it all should work. Suppose I have >> a parser, that raises ParseError. I might use it like this: >> >> let something = Something::new(); >> >> try { >> something.parse_str("..."); >> } catch ParseError as e { >> println!("ParseError at {}:{}", e.row, e.col); >> return; >> } >> >> What would be Rust alternative, except passing the errors all around >> parser? Doesn't it grow parser code by at least 50%? > > > Haskell has no exception, it has Monads instead. Rust reuses Option and > Result (Maybe and Either in Haskell) with great success. > >> >> >> >> 3. It seems like almost any string operation requires as_slice(). >> >> Can't various string methods be also implemented for String? >> >> > It's the lowest common denominator approach, a slice is cheap (no memory >> > allocation) and universal (may refer either to heap allocated buffer or >> > static buffer). >> >> Why not make a trait BaseString and apply all the operations to it? > > > It's "heavier", in several ways. > > For the client: the Slice is written once, with all its operations, so where > in an "interface" setting you would need to provide a lot of operations > yourself, here you just provide ONE operation => the conversion so slice. > > For the user: a Slice is a concrete type, all functions/methods are thus > statically known and can be inlined at call site. The alternative with a > trait is either: > - paying a virtual call at each method, which is slower and inhibit constant > propagation a whole host of potential optimizations > - mono-morphizing the code for each implementer of BaseString, which is > generally referred to a "template bloat" in C++ (much more code is > generated, thus bigger binaries, clogging of the CPU caches, ...) > > In short, Slice is just a superior alternative. > > > >> >> >> On Thu, May 29, 2014 at 3:44 AM, Matthieu Monrocq >> wrote: >> > >> > >> > >> > On Thu, May 29, 2014 at 2:38 AM, Oleg Eterevsky >> > wrote: >> >> >> >> Hi! >> >> >> >> I've just recently started learning Rust. Here's a few questions that >> >> I have after writing about a hundred lines of code: >> >> >> >> 1. Why neither overloaded function, nor default values for arguments >> >> are supported? In statically typed language overloaded functions are >> >> quite safe and convenient. Also, from what I see, overloaded functions >> >> could be used in various use cases instead of macros. >> >> >> > >> > Overloaded functions are unnecessary in Rust. In C++ they are heavily >> > used >> > because of templates use duck-typing, but Rust uses explicit interfaces >> > (typeclass-like) which makes it unnecessary. >> > >> > Overloaded functions also don't play too well with type inference. C++ >> > works >> > around this by having a very simple type inference (ie, it only deduces >> > the >> > return type), but Rust's type inference is more advanced: >> > >> > let mut result = vec!(); // type of "result" is "Vec<...>" which is >> > only >> > partially known >> > >> > for x in some_range.iter() { >> > doit(result, *x); // there is a single "doit" in scope, whose >> > arguments is "Vec" thus this is the type of "result" >> > } >> > >> > If you were able to overload "doit" though, suddenly things would get >> > hairy, >> > and you would have to start explicitly typing your variables left and >> > right. >> > >> > Thus, even besides the confusion a human being experiences (which >> > overload >> > is called ?) and the over-abuse of overloads in the first place (Qt >> > seems to >> > be doing nicely in that domain), there is a technical trade-off: better >> > type >> > inference or function overload ? >> > >> > Note: it also means that compiler error-messages are generally more >> > explicit; tried forgetting to implementation "operator<<" for a type and >> > see >> > what your favorite C++ compiler reports ;) >> > >> > >> > Named parameters and default values are just syntactic sugar; they might >> > feel handy, indeed, but in general they can be emulated => Rust already >> > has >> > named parameters for "struct" initialization, and it also has functional >> > update for those "struct" thus as long as you are willing to add one >> > more >> > symbol: >> > >> > struct FooArgs { x: int, y: int, } >> > >> > static DEFAULT_FOO: FooArgs = FooArgs { x: 4, y: 5, } >> > >> > fn foo(args: FooArgs) {} >> > >> > fn main() { >> > foo(FooArgs{x: 3, .. DEFAULT_FOO}) >> > } >> > >> > I personally feel that the name "FooArgs" could be inferred in the call >> > (since there is no overload of "foo" there is no ambiguity) which would >> > assist in this pattern. There is also the issue that static cannot be >> > build >> > from arbitrary functions, but that may be lifted with Compilation Time >> > Function Evaluation one day, and in the mean time you can have a >> > FooArgs::default() that computes the defaults. >> > >> > >> >> >> >> 2. What about exceptions? Is it a design decision not to support them, >> >> or are they planned for some future version? I understand, that >> >> exceptions make memory management more difficult, but maybe there are >> >> ways to restrict their usage to avoid problems (like making it >> >> impossible to pass references as exception parameters?) >> >> >> > As mentioned, the issue is about recovery: you modified a lot of stuff >> > in >> > your "try" that is still accessible afterward, is it in a safe state ? >> > is it >> > in sensible state ? No one knows, and your compiler does not care. Tasks >> > enforce explicitness about what is modified, which helps in auditing. >> > >> >> >> >> 3. It seems like almost any string operation requires as_slice(). >> >> Can't various string methods be also implemented for String? >> >> >> > It's the lowest common denominator approach, a slice is cheap (no memory >> > allocation) and universal (may refer either to heap allocated buffer or >> > static buffer). >> > >> > Rust is working on DST (Dynamically Sized Types) and once this lands >> > String >> > will be able to implement Deref, which will ease things. There is also >> > been >> > talk about auto-deref to make it even painless. >> > >> >> >> >> 4. It looks like vectors can be concatenated with + operations, but >> >> strings can't. Is it deliberate? >> > >> > >> > As someone else answered, it could be done. >> > >> > Personally though I've never liked that. '+' is mathematically a >> > commutative >> > operation and catenation is not a commutative operation. Also, in the >> > absence of overloading this means to catenate you have to implement the >> > Add >> > trait. This is just weird. I would prefer infix function calls (`cat`) >> > for >> > example, or another dedicated operator (++ ?) >> > >> >> >> >> >> >> 5. Simple indexing doesn't work for vectors: >> >> let a = vec![1, 2, 3]; >> >> println!("{}", a[0]); >> >> It's a bit surprising... >> >> >> > Could probably be implemented, may have to wait for DST though. >> > >> >> >> >> 6. impl ToStr for custom struct fails: >> >> error: conflicting implementations for trait `std::to_str::ToStr` >> >> note: conflicting implementation in crate `std` >> >> Is it a bug? Is Show implicitly assumed for all struct's? >> >> >> >> 7. The usage of mut is a bit confusing. It is supposed to be used as a >> >> qualifier for a variable, but it quickly becomes a part of the type, >> >> when you define functions like >> >> fn test(something: &mut Something) >> >> Maybe it makes sense move mut their? Or distinguish mut as a variable >> >> qualifier vs const as a propery of type? >> >> >> > >> > There has been an extended discussion about it, and I am also slightly >> > confused by the use of `mut`. It reads "mutability" but in the case of >> > references also implies exclusivity... >> > >> > At the end of the day though, there's already a number of high-profiles >> > changes going on (such as the above DST), so for now it's wait and see. >> > Once >> > those are implemented and the core developers have a bit more time on >> > their >> > plate, the issue might be revisited. >> > >> >> >> >> -- >> >> Thanks, >> >> Oleg Eterevsky. >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > From simon.sapin at exyr.org Thu May 29 14:28:33 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 29 May 2014 22:28:33 +0100 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: <5387A681.3070201@exyr.org> On 29/05/2014 19:22, Vladimir Matveev wrote: > Hi, Christophe, > > Won't wrapping the first `for` loop into curly braces help? I suspect > this happens because of `for` loop desugaring, which kind of "leaves" > the iterator created by `execute_query()` "in scope" (not really, but > only for borrow checker). If that?s the case, it sounds like a bug with an easy fix. -- Simon Sapin From pcwalton at mozilla.com Thu May 29 14:32:26 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 29 May 2014 14:32:26 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: <5387A76A.2090901@mozilla.com> Exceptions, and stack unwinding in general, are not acceptable in many systems projects. Many, perhaps most, C++ projects turn off exceptions. This is true of all browser engines I know of, as well as games and OS kernels--essentially the niches where C++ is the strongest. The primary reason is that the unwind tables are large, and unwinding can inhibit optimizations. If we made the standard library require exceptions, then it would be harder to use Rust in those niches, and it would compromise the goals of Rust as a systems language. Therefore, we have to design our APIs to not require exceptions. Patrick From danielmicay at gmail.com Thu May 29 14:50:54 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 29 May 2014 17:50:54 -0400 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: <5387ABBE.2070603@gmail.com> On 29/05/14 05:22 PM, Oleg Eterevsky wrote: >>> What would be Rust alternative, except passing the errors all around >>> parser? Doesn't it grow parser code by at least 50%? > >> Haskell has no exception, it has Monads instead. Rust reuses Option and Result (Maybe and Either in Haskell) with great success. > > For all my love to Haskell, I wouldn't consider it an example of a > practical programming language. I mean, there aren't many projects > written in Haskell of a size larger than GHC. > >>> Why not make a trait BaseString and apply all the operations to it? >> It's "heavier", in several ways. >> [...] >> In short, Slice is just a superior alternative. > > I agree that it is conceptually simpler. But compare code, required to > read one integer from a file in Python, C++ and Rust: > > a = int(f.read_line()) > > int a; > f >> a; Your C++ example isn't checking for an I/O error and isn't even checking that it succeeded at parsing an integer. > let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap(); This isn't doing the same thing as the C++ code. The C++ code is reading an integer from the stream, while this is allocating a string and then converting. An apples to apples comparison would read a string from the C++ API and convert with std::stoi, or use a similar input API in Rust for streams to avoid needless string conversions and noise. The trim would also be unnecessary if you were using an API comparable to the one the C++ code is using. > Two unwrap's are caused by the lack of exceptions, as_slice is to > convert String -> str, trim is because from_str doesn't skip > whitespace (I suppose, the last one is non-essential). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From comexk at gmail.com Thu May 29 14:59:55 2014 From: comexk at gmail.com (comex) Date: Thu, 29 May 2014 17:59:55 -0400 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: On Thu, May 29, 2014 at 5:22 PM, Oleg Eterevsky wrote: > a = int(f.read_line()) > let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap(); It depends what you mean by 'required.' For a production project, I think it would be a good idea to have separate error messages for EOF and invalid numbers, which would not be more verbose in Rust than C++ or Python. For the type of short personal-use-only script I write a lot in Python, where it isn't worth it to deal with error conditions, I agree that is very noisy. I personally think the trait should be implemented so as_slice() isn't required, and considering the vast amount of .unwrap() even in standard library code, I think it might do well to have an operator for it. Again, I am not a contributor so it's just my two cents. From rusty.gates at icloud.com Thu May 29 16:01:07 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 30 May 2014 02:01:07 +0300 Subject: [rust-dev] Function overloading is necessary Message-ID: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> Function overloading is a language feature that is necessary in order to prevent implementation details from becoming a part of an interface. Example: // Assuming function overloading exists... trait A { // Basic functionality: ... } trait B : A { // Extended functionality: ... } fn foo(T t) { // Algorithm 1: ... } fn foo(T t) { // Algorithm 2: ... } The fundamental requirement for the Algorithm 1 is that the type of the argument `t` must implement trait `A`. But, if the argument `t`implements trait `B` (as well as `A`), then the extended functionality in `B` makes possible an optimization that the Algorithm 2 is able to use. Whether the optimized algorithm is used or not is an implementation detail that the caller of `foo` shouldn't need to be bothered with. The lack of function overloading forces us to have two differently named functions, say `foo_a` and `foo_b`, and the programmer has to keep in mind that if he wants the optimized algorithm, then he needs to call `foo_b` (instead of `foo_a`) if his argument implements `B`. With function overloading, the programmer gets the optimization for free (no extra mental burden and no chance of calling the "wrong" function). From oleg at eterevsky.com Thu May 29 16:10:25 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 16:10:25 -0700 Subject: [rust-dev] A few random questions In-Reply-To: <5387A76A.2090901@mozilla.com> References: <5387A76A.2090901@mozilla.com> Message-ID: The projects in C++ that forbid exceptions are doing so not because of some prejudice, but because exceptions in C++ are unsafe. In Java standard library exceptions are ubiquitous. On Thu, May 29, 2014 at 2:32 PM, Patrick Walton wrote: > Exceptions, and stack unwinding in general, are not acceptable in many > systems projects. Many, perhaps most, C++ projects turn off exceptions. This > is true of all browser engines I know of, as well as games and OS > kernels--essentially the niches where C++ is the strongest. The primary > reason is that the unwind tables are large, and unwinding can inhibit > optimizations. > > If we made the standard library require exceptions, then it would be harder > to use Rust in those niches, and it would compromise the goals of Rust as a > systems language. Therefore, we have to design our APIs to not require > exceptions. > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From oleg at eterevsky.com Thu May 29 16:18:17 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 16:18:17 -0700 Subject: [rust-dev] A few random questions In-Reply-To: <5387ABBE.2070603@gmail.com> References: <5387ABBE.2070603@gmail.com> Message-ID: >> let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap(); > This isn't doing the same thing as the C++ code. Is there a shorter code to read an integer? On Thu, May 29, 2014 at 2:50 PM, Daniel Micay wrote: > On 29/05/14 05:22 PM, Oleg Eterevsky wrote: >>>> What would be Rust alternative, except passing the errors all around >>>> parser? Doesn't it grow parser code by at least 50%? >> >>> Haskell has no exception, it has Monads instead. Rust reuses Option and Result (Maybe and Either in Haskell) with great success. >> >> For all my love to Haskell, I wouldn't consider it an example of a >> practical programming language. I mean, there aren't many projects >> written in Haskell of a size larger than GHC. >> >>>> Why not make a trait BaseString and apply all the operations to it? >>> It's "heavier", in several ways. >>> [...] >>> In short, Slice is just a superior alternative. >> >> I agree that it is conceptually simpler. But compare code, required to >> read one integer from a file in Python, C++ and Rust: >> >> a = int(f.read_line()) >> >> int a; >> f >> a; > > Your C++ example isn't checking for an I/O error and isn't even checking > that it succeeded at parsing an integer. > >> let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap(); > > This isn't doing the same thing as the C++ code. The C++ code is reading > an integer from the stream, while this is allocating a string and then > converting. > > An apples to apples comparison would read a string from the C++ API and > convert with std::stoi, or use a similar input API in Rust for streams > to avoid needless string conversions and noise. > > The trim would also be unnecessary if you were using an API comparable > to the one the C++ code is using. > >> Two unwrap's are caused by the lack of exceptions, as_slice is to >> convert String -> str, trim is because from_str doesn't skip >> whitespace (I suppose, the last one is non-essential). > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From oleg at eterevsky.com Thu May 29 16:22:34 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 16:22:34 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: Message-ID: There are lots of cases even in production code where you just read something without error checking each and every IO call and just catch an exception on the higher level. On Thu, May 29, 2014 at 2:59 PM, comex wrote: > On Thu, May 29, 2014 at 5:22 PM, Oleg Eterevsky wrote: >> a = int(f.read_line()) >> let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap(); > > It depends what you mean by 'required.' > > For a production project, I think it would be a good idea to have > separate error messages for EOF and invalid numbers, which would not > be more verbose in Rust than C++ or Python. > > For the type of short personal-use-only script I write a lot in > Python, where it isn't worth it to deal with error conditions, I agree > that is very noisy. I personally think the trait should be > implemented so as_slice() isn't required, and considering the vast > amount of .unwrap() even in standard library code, I think it might do > well to have an operator for it. Again, I am not a contributor so > it's just my two cents. From comexk at gmail.com Thu May 29 16:39:57 2014 From: comexk at gmail.com (comex) Date: Thu, 29 May 2014 19:39:57 -0400 Subject: [rust-dev] A few random questions In-Reply-To: References: <5387A76A.2090901@mozilla.com> Message-ID: On Thu, May 29, 2014 at 7:10 PM, Oleg Eterevsky wrote: > The projects in C++ that forbid exceptions are doing so not because of > some prejudice, but because exceptions in C++ are unsafe. In Java > standard library exceptions are ubiquitous. If you mean checked exceptions, I hear that they're quite unpopular, although I don't use Java. Since browsers were brought up, here is the Google C++ style guide on exceptions: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions It bans them due to a variety of downsides which would only be partially addressed by checked-exception-like safety systems. I think Google Java code does use exceptions, but that's language culture for you. As a related data point, Go eschews exceptions entirely due to prejudice: http://golang.org/doc/faq#exceptions Not that I agree with most of Go's design decisions... still, I think these examples are enough to demonstrate that there are legitimate reasons to prefer a language designed without exceptions. I think it may be good for you to get more experience with Rust, although as I mentioned, I also lack experience. From comexk at gmail.com Thu May 29 16:48:03 2014 From: comexk at gmail.com (comex) Date: Thu, 29 May 2014 19:48:03 -0400 Subject: [rust-dev] Function overloading is necessary In-Reply-To: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> Message-ID: On Thu, May 29, 2014 at 7:01 PM, Tommi wrote: > The lack of function overloading forces us to have two differently named functions, say `foo_a` and `foo_b`, and the programmer has to keep in mind that if he wants the optimized algorithm, then he needs to call `foo_b` (instead of `foo_a`) if his argument implements `B`. I would consider this usually an upside, because this way the programmer knows whether the fast or slow version is being used, and that calling the slow version may be a hazard to be improved by refactoring the code to implement B. It may occasionally be a downside. From oleg at eterevsky.com Thu May 29 17:01:38 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 17:01:38 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: <5387A76A.2090901@mozilla.com> Message-ID: > Since browsers were brought up, here is the Google C++ style guide on exceptions: > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions As someone who works for Google, I can attest, that exceptions are encouraged in Google style guides for Python and Java and the main reason they are forbidden in C++ is their memory safety. Google has a big amount of pre-exceptions C++ code, and it will break in unexpected places if exceptions are allowed. Go is a different story. It deliberately refuses to support exceptions even though it has GC and hence has no problems with exception memory safety whatsoever. The lack of exception might be one of the main reasons (if not the main reason), why Go is not so popular even within Google. On Thu, May 29, 2014 at 4:39 PM, comex wrote: > On Thu, May 29, 2014 at 7:10 PM, Oleg Eterevsky wrote: >> The projects in C++ that forbid exceptions are doing so not because of >> some prejudice, but because exceptions in C++ are unsafe. In Java >> standard library exceptions are ubiquitous. > > If you mean checked exceptions, I hear that they're quite unpopular, > although I don't use Java. > > Since browsers were brought up, here is the Google C++ style guide on > exceptions: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions > > It bans them due to a variety of downsides which would only be > partially addressed by checked-exception-like safety systems. I think > Google Java code does use exceptions, but that's language culture for > you. > > As a related data point, Go eschews exceptions entirely due to prejudice: > > http://golang.org/doc/faq#exceptions > > Not that I agree with most of Go's design decisions... still, I think > these examples are enough to demonstrate that there are legitimate > reasons to prefer a language designed without exceptions. > > I think it may be good for you to get more experience with Rust, > although as I mentioned, I also lack experience. From rusty.gates at icloud.com Thu May 29 17:21:17 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 30 May 2014 03:21:17 +0300 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> Message-ID: <7BC68D89-5262-4274-88BB-CC5F248EC9D7@icloud.com> On 2014-05-30, at 2:48, comex wrote: > On Thu, May 29, 2014 at 7:01 PM, Tommi wrote: >> The lack of function overloading forces us to have two differently named functions, say `foo_a` and `foo_b`, and the programmer has to keep in mind that if he wants the optimized algorithm, then he needs to call `foo_b` (instead of `foo_a`) if his argument implements `B`. > > I would consider this usually an upside, because this way the > programmer knows whether the fast or slow version is being used, and > that calling the slow version may be a hazard to be improved by > refactoring the code to implement B. It may occasionally be a > downside. Assuming the programmer knows both the type of the argument and the manner in which the type of the argument determines which algorithm ends up being used, then the programmer knows whether the regular or the optimized version of the algorithm is being used also in the case of `foo` being overloaded. And if the programmer doesn't know the type of the argument (the type is a template parameter for example), then he *really* needs the overloaded `foo`. From comexk at gmail.com Thu May 29 17:28:42 2014 From: comexk at gmail.com (comex) Date: Thu, 29 May 2014 20:28:42 -0400 Subject: [rust-dev] Function overloading is necessary In-Reply-To: <7BC68D89-5262-4274-88BB-CC5F248EC9D7@icloud.com> References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <7BC68D89-5262-4274-88BB-CC5F248EC9D7@icloud.com> Message-ID: On Thu, May 29, 2014 at 8:21 PM, Tommi wrote: > Assuming the programmer knows both the type of the argument and the manner in which the type of the argument determines which algorithm ends up being used, then the programmer knows whether the regular or the optimized version of the algorithm is being used also in the case of `foo` being overloaded. If they know that then it should be no problem to be explicit! But even if the programmer who wrote the code knew it at the time, the programmer trying to figure out what it actually does may be someone else, or the same person much later on, which is basically the same thing. :) From oleg at eterevsky.com Thu May 29 17:31:21 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 17:31:21 -0700 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> Message-ID: Suppose you have some general algorithm working on all the numeric types. And suppose there's an optimized version of it particularly for 32-bit integers, that works say 20% faster. It is a substantial optimization, but do you believe that every programmer using it should know whether it is applied? On Thu, May 29, 2014 at 4:48 PM, comex wrote: > On Thu, May 29, 2014 at 7:01 PM, Tommi wrote: >> The lack of function overloading forces us to have two differently named functions, say `foo_a` and `foo_b`, and the programmer has to keep in mind that if he wants the optimized algorithm, then he needs to call `foo_b` (instead of `foo_a`) if his argument implements `B`. > > I would consider this usually an upside, because this way the > programmer knows whether the fast or slow version is being used, and > that calling the slow version may be a hazard to be improved by > refactoring the code to implement B. It may occasionally be a > downside. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From ecreed at cs.washington.edu Thu May 29 17:42:09 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Thu, 29 May 2014 17:42:09 -0700 Subject: [rust-dev] Function overloading is necessary In-Reply-To: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> Message-ID: Rust *does* have function overloading. That's *exactly* what traits are for. If you want to overload a function, then make it a trait and impl the trait for all the types you want to overload it with. On Thu, May 29, 2014 at 4:01 PM, Tommi wrote: > Function overloading is a language feature that is necessary in order to > prevent implementation details from becoming a part of an interface. > > Example: > > // Assuming function overloading exists... > > trait A { > // Basic functionality: > ... > } > > trait B : A { > // Extended functionality: > ... > } > > fn foo(T t) { > // Algorithm 1: > ... > } > > fn foo(T t) { > // Algorithm 2: > ... > } > > The fundamental requirement for the Algorithm 1 is that the type of the > argument `t` must implement trait `A`. But, if the argument `t`implements > trait `B` (as well as `A`), then the extended functionality in `B` makes > possible an optimization that the Algorithm 2 is able to use. Whether the > optimized algorithm is used or not is an implementation detail that the > caller of `foo` shouldn't need to be bothered with. > > The lack of function overloading forces us to have two differently named > functions, say `foo_a` and `foo_b`, and the programmer has to keep in mind > that if he wants the optimized algorithm, then he needs to call `foo_b` > (instead of `foo_a`) if his argument implements `B`. With function > overloading, the programmer gets the optimization for free (no extra mental > burden and no chance of calling the "wrong" function). > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Thu May 29 17:52:28 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 30 May 2014 03:52:28 +0300 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> Message-ID: <042E8283-DD63-45FE-8855-86F284897351@icloud.com> On 2014-05-30, at 3:42, Eric Reed wrote: > Rust *does* have function overloading. That's *exactly* what traits are for. > If you want to overload a function, then make it a trait and impl the trait for all the types you want to overload it with. I've been trying to figure out how exactly to do this. How would I write a function that's overloaded based on whether its argument's type implements Iterator or RandomAccessIterator? From ecreed at cs.washington.edu Thu May 29 18:02:15 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Thu, 29 May 2014 18:02:15 -0700 Subject: [rust-dev] Function overloading is necessary In-Reply-To: <042E8283-DD63-45FE-8855-86F284897351@icloud.com> References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> Message-ID: You have to make the varying type the type implementing the trait. trait Foo { fn foo(arg: Self, some_int: int); } impl Foo for T { fn foo(arg: T, some_int: int) { ... /* arg implements Iterator */ } } impl Foo for T { fn foo(arg: T, some_int: int) { ... /* arg implements RandomAccessIterator */ } } Although traits are the tool you're supposed to use to do this, there are a couple issues at the moment: - The compiler can sometimes get scared and confused when you start mixing generic impls and concrete impls (or multiple generic impls). This should be fixed eventually. - You can only vary on one type. Long term, this can be fixed by making our traits MultiParameterTypeClasses instead of just regular Type Classes. Short term, you can avoid this by impl'ing on a tuple of the varying types. On Thu, May 29, 2014 at 5:52 PM, Tommi wrote: > On 2014-05-30, at 3:42, Eric Reed wrote: > > > Rust *does* have function overloading. That's *exactly* what traits are > for. > > If you want to overload a function, then make it a trait and impl the > trait for all the types you want to overload it with. > > I've been trying to figure out how exactly to do this. How would I write a > function that's overloaded based on whether its argument's type implements > Iterator or RandomAccessIterator? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Thu May 29 18:03:54 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 30 May 2014 04:03:54 +0300 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <7BC68D89-5262-4274-88BB-CC5F248EC9D7@icloud.com> Message-ID: On 2014-05-30, at 3:28, comex wrote: > On Thu, May 29, 2014 at 8:21 PM, Tommi wrote: >> Assuming the programmer knows both the type of the argument and the manner in which the type of the argument determines which algorithm ends up being used, then the programmer knows whether the regular or the optimized version of the algorithm is being used also in the case of `foo` being overloaded. > > If they know that then it should be no problem to be explicit! If it's explicit, then we're forcing the caller of the function to know that different algorithms (with different performance characteristics) exist for getting the job done. Plus, like I said, having no function overloading hinders generic programming. From danielmicay at gmail.com Thu May 29 18:05:53 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 29 May 2014 21:05:53 -0400 Subject: [rust-dev] Function overloading is necessary In-Reply-To: <042E8283-DD63-45FE-8855-86F284897351@icloud.com> References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> Message-ID: <5387D971.4050407@gmail.com> On 29/05/14 08:52 PM, Tommi wrote: > On 2014-05-30, at 3:42, Eric Reed wrote: > >> Rust *does* have function overloading. That's *exactly* what traits are for. >> If you want to overload a function, then make it a trait and impl the trait for all the types you want to overload it with. > > I've been trying to figure out how exactly to do this. How would I write a function that's overloaded based on whether its argument's type implements Iterator or RandomAccessIterator? Maybe by implementing the function in a trait as a default method and doing an override for types implementing RandomAccessIterator. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From oleg at eterevsky.com Thu May 29 18:05:56 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Thu, 29 May 2014 18:05:56 -0700 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> Message-ID: If a type implements both Iterator and RandomAccessIterator, wouldn't it lead to a conflict? On Thu, May 29, 2014 at 6:02 PM, Eric Reed wrote: > You have to make the varying type the type implementing the trait. > > trait Foo { > fn foo(arg: Self, some_int: int); > } > > impl Foo for T { > fn foo(arg: T, some_int: int) { ... /* arg implements Iterator */ } > } > > impl Foo for T { > fn foo(arg: T, some_int: int) { ... /* arg implements > RandomAccessIterator */ } > } > > Although traits are the tool you're supposed to use to do this, there are a > couple issues at the moment: > - The compiler can sometimes get scared and confused when you start mixing > generic impls and concrete impls (or multiple generic impls). This should be > fixed eventually. > - You can only vary on one type. Long term, this can be fixed by making our > traits MultiParameterTypeClasses instead of just regular Type Classes. Short > term, you can avoid this by impl'ing on a tuple of the varying types. > > > On Thu, May 29, 2014 at 5:52 PM, Tommi wrote: >> >> On 2014-05-30, at 3:42, Eric Reed wrote: >> >> > Rust *does* have function overloading. That's *exactly* what traits are >> > for. >> > If you want to overload a function, then make it a trait and impl the >> > trait for all the types you want to overload it with. >> >> I've been trying to figure out how exactly to do this. How would I write a >> function that's overloaded based on whether its argument's type implements >> Iterator or RandomAccessIterator? >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From ecreed at cs.washington.edu Thu May 29 18:16:43 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Thu, 29 May 2014 18:16:43 -0700 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> Message-ID: That was what I was referencing in my comment about the compiler getting scared and confused. Theoretically, it should be allowed and the compiler would just require you to specify, but rustc may not be there yet. Note that this problem is present in either formulation of function overloading. If we had the style of function overloading Tommi used in the first post, rustc still wouldn't know which function to call for a type that implements both A and B. On Thu, May 29, 2014 at 6:05 PM, Oleg Eterevsky wrote: > If a type implements both Iterator and RandomAccessIterator, wouldn't > it lead to a conflict? > > On Thu, May 29, 2014 at 6:02 PM, Eric Reed > wrote: > > You have to make the varying type the type implementing the trait. > > > > trait Foo { > > fn foo(arg: Self, some_int: int); > > } > > > > impl Foo for T { > > fn foo(arg: T, some_int: int) { ... /* arg implements Iterator */ } > > } > > > > impl Foo for T { > > fn foo(arg: T, some_int: int) { ... /* arg implements > > RandomAccessIterator */ } > > } > > > > Although traits are the tool you're supposed to use to do this, there > are a > > couple issues at the moment: > > - The compiler can sometimes get scared and confused when you start > mixing > > generic impls and concrete impls (or multiple generic impls). This > should be > > fixed eventually. > > - You can only vary on one type. Long term, this can be fixed by making > our > > traits MultiParameterTypeClasses instead of just regular Type Classes. > Short > > term, you can avoid this by impl'ing on a tuple of the varying types. > > > > > > On Thu, May 29, 2014 at 5:52 PM, Tommi wrote: > >> > >> On 2014-05-30, at 3:42, Eric Reed wrote: > >> > >> > Rust *does* have function overloading. That's *exactly* what traits > are > >> > for. > >> > If you want to overload a function, then make it a trait and impl the > >> > trait for all the types you want to overload it with. > >> > >> I've been trying to figure out how exactly to do this. How would I > write a > >> function that's overloaded based on whether its argument's type > implements > >> Iterator or RandomAccessIterator? > >> > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Thu May 29 18:37:33 2014 From: kevin at sb.org (Kevin Ballard) Date: Thu, 29 May 2014 18:37:33 -0700 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: On May 29, 2014, at 11:22 AM, Vladimir Matveev wrote: > Hi, Christophe, > > Won't wrapping the first `for` loop into curly braces help? I suspect > this happens because of `for` loop desugaring, which kind of "leaves" > the iterator created by `execute_query()` "in scope" (not really, but > only for borrow checker). It shouldn't. The for-loop desugaring looks like match &mut st.execute_query() { __i => loop { match __i.next() { None => break, Some(mut __value) => { let i = __value; { // for loop body goes here } } } } } It's done with a match statement like this specifically to make the &mut binding of the iterator end after the for loop. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From danielmicay at gmail.com Thu May 29 18:46:54 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 29 May 2014 21:46:54 -0400 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> Message-ID: <5387E30E.7040504@gmail.com> On 29/05/14 09:05 PM, Oleg Eterevsky wrote: > If a type implements both Iterator and RandomAccessIterator, wouldn't > it lead to a conflict? No, it won't. There's a default implementation for types implementing the Iterator trait, and only a single explicit implementation. There are other more flexible ways to do this, but this happens to be enough for this use case. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu May 29 18:49:22 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 29 May 2014 21:49:22 -0400 Subject: [rust-dev] Function overloading is necessary In-Reply-To: <5387E30E.7040504@gmail.com> References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> <5387E30E.7040504@gmail.com> Message-ID: <5387E3A2.7080405@gmail.com> On 29/05/14 09:46 PM, Daniel Micay wrote: > On 29/05/14 09:05 PM, Oleg Eterevsky wrote: >> If a type implements both Iterator and RandomAccessIterator, wouldn't >> it lead to a conflict? > > No, it won't. There's a default implementation for types implementing > the Iterator trait, and only a single explicit implementation. > > There are other more flexible ways to do this, but this happens to be > enough for this use case. Ah, I missed the point of the example. It's supposed to be implemented for *all* types implementing both traits, not specific ones. I'll post a new solution. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From palmercox at gmail.com Thu May 29 19:55:29 2014 From: palmercox at gmail.com (Palmer Cox) Date: Thu, 29 May 2014 22:55:29 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> Message-ID: What about renaming len() to units()? I don't see len() as a problem, but maybe as a potential source of confusion. I also strongly believe that no one reads documentation if they *think* they understand what the code is doing. Different people will see len(), assume that it does whatever they want to do at the moment, and for a significant portion of strings that they encounter it will seem like their interpretation, whatever it is, is correct. So, why not rename len() to something like units()? Its more explicit with the value that its actually producing than len() and its not all that much longer to type. As stated, exactly what a string is varies greatly between languages, so, I don't think that lacking a function named len() is bad. Granted, I would expect that many people expect that a string will have method named len() (or length()) and when they don't find one, they will go to the documentation and find units(). I think this is a good thing since the documentation can then explain exactly what it does. I much prefer len() to byte_len(), though. byte_len() seems like a bit much to type and it seems like all the other methods on strings should then be renamed with the byte_ prefix which seems unpleasant. -Palmer Cox On Thu, May 29, 2014 at 3:39 AM, Masklinn wrote: > > On 2014-05-29, at 08:37 , Aravinda VK wrote: > > > I think returning length of string in bytes is just fine. Since I didn't > know about the availability of char_len in rust caused this confusion. > > > > python 2.7 - Returns length of string in bytes, Python 3 returns number > of codepoints. > > Nope, depends on the string type *and* on compilation options. > > * Python 2's `str` and Python 3's `bytes` are byte sequences, their > len() returns their byte counts. > * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code > units count which may be UCS2 or UCS4 (depending whether the > interpreter was compiled with `?enable-unicode=ucs2` ? the default ? > or `?enable-unicode=ucs4`. Only the latter case is a true code points > count. > * Python 3.3's `str` switched to the Flexible String Representation, > the build-time option disappeared and len() always returns the number > of codepoints. > > Note that in no case to len() operations take normalisation or visual > composition in account. > > > JS returns number of codepoints. > > JS returns the number of UCS2 code units, which is twice the number of > code points for those in astral planes. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From platt.nicholas at gmail.com Thu May 29 19:48:49 2014 From: platt.nicholas at gmail.com (Nicholas Platt) Date: Thu, 29 May 2014 22:48:49 -0400 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: <94454F95-47F2-4A8B-AFC6-4BDEE87B8469@sb.org> References: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> <94454F95-47F2-4A8B-AFC6-4BDEE87B8469@sb.org> Message-ID: I encountered inconsistencies like this quite a bit while coding up my first program in Rust[0]. Glad to see this addressed; the current API forces some really awkward syntax, I think. As shown in that file, the time crate also requires strange syntax, in my opinion. Ideally arguments are always "plain-old-strings", ie: this_should("always", "work"); this_should_not(&"be".to_string(), ["required".to_string()]); But there may be more to the story than I'm aware of. -- Nick [0]: https://github.com/uutils/coreutils/blob/master/touch/touch.rs#L111 On Mon, May 26, 2014 at 9:38 PM, Kevin Ballard wrote: > Sure, that seems like a pretty easy job to tackle. You should audit the > whole getopts API to see where it uses String inappropriately. Any &[String] > parameters should probably be &[S] where , and any bare String > parameters (if any) should probably be &str. > > -Kevin > > On May 26, 2014, at 6:29 PM, Gulshan Singh wrote: > > On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: >> >> All the methods that take &[String] should probably be rewritten to be >> generic with and take &[S] instead, which will allow taking either >> a slice of Strings or a slice of &str's. > > > I've been wanting to contribute to Rust for a while. This seems like the > right thing to do and I don't think it's a hard change. Should I go ahead > and make it? > > -- > Gulshan Singh > University of Michigan, Class of 2015 > College of Engineering, Computer Science Major > gulshan at umich.edu | 248.961.6317 > Alternate E-mail: gsingh2011 at gmail.com > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From palmercox at gmail.com Thu May 29 20:11:44 2014 From: palmercox at gmail.com (Palmer Cox) Date: Thu, 29 May 2014 23:11:44 -0400 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> Message-ID: Thinking about it more, units() is a bad name. I think a renaming could make sense, but only if something better than len() can be found. -Palmer Cox On Thu, May 29, 2014 at 10:55 PM, Palmer Cox wrote: > What about renaming len() to units()? > > I don't see len() as a problem, but maybe as a potential source of > confusion. I also strongly believe that no one reads documentation if they > *think* they understand what the code is doing. Different people will see > len(), assume that it does whatever they want to do at the moment, and for > a significant portion of strings that they encounter it will seem like > their interpretation, whatever it is, is correct. So, why not rename len() > to something like units()? Its more explicit with the value that its > actually producing than len() and its not all that much longer to type. As > stated, exactly what a string is varies greatly between languages, so, I > don't think that lacking a function named len() is bad. Granted, I would > expect that many people expect that a string will have method named len() > (or length()) and when they don't find one, they will go to the > documentation and find units(). I think this is a good thing since the > documentation can then explain exactly what it does. > > I much prefer len() to byte_len(), though. byte_len() seems like a bit > much to type and it seems like all the other methods on strings should then > be renamed with the byte_ prefix which seems unpleasant. > > -Palmer Cox > > > On Thu, May 29, 2014 at 3:39 AM, Masklinn wrote: > >> >> On 2014-05-29, at 08:37 , Aravinda VK wrote: >> >> > I think returning length of string in bytes is just fine. Since I >> didn't know about the availability of char_len in rust caused this >> confusion. >> > >> > python 2.7 - Returns length of string in bytes, Python 3 returns number >> of codepoints. >> >> Nope, depends on the string type *and* on compilation options. >> >> * Python 2's `str` and Python 3's `bytes` are byte sequences, their >> len() returns their byte counts. >> * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code >> units count which may be UCS2 or UCS4 (depending whether the >> interpreter was compiled with `?enable-unicode=ucs2` ? the default ? >> or `?enable-unicode=ucs4`. Only the latter case is a true code points >> count. >> * Python 3.3's `str` switched to the Flexible String Representation, >> the build-time option disappeared and len() always returns the number >> of codepoints. >> >> Note that in no case to len() operations take normalisation or visual >> composition in account. >> >> > JS returns number of codepoints. >> >> JS returns the number of UCS2 code units, which is twice the number of >> code points for those in astral planes. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsingh_2011 at yahoo.com Thu May 29 21:48:26 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Thu, 29 May 2014 21:48:26 -0700 Subject: [rust-dev] Array of heap allocated strings for opts_present? In-Reply-To: References: <0A30704A-3656-4B54-9C4B-4C12AEA1EA89@sb.org> <94454F95-47F2-4A8B-AFC6-4BDEE87B8469@sb.org> Message-ID: I'm waiting for my pull request to be accepted, but it should be noted that since the new version of the function takes both &str and String, all of that strange syntax will still compile and will still be there until someone changes it. On Thu, May 29, 2014 at 7:48 PM, Nicholas Platt wrote: > I encountered inconsistencies like this quite a bit while coding up my > first program in Rust[0]. Glad to see this addressed; the current API > forces some really awkward syntax, I think. > > As shown in that file, the time crate also requires strange syntax, in > my opinion. Ideally arguments are always "plain-old-strings", ie: > > this_should("always", "work"); > this_should_not(&"be".to_string(), ["required".to_string()]); > > But there may be more to the story than I'm aware of. > > -- Nick > > [0]: https://github.com/uutils/coreutils/blob/master/touch/touch.rs#L111 > > On Mon, May 26, 2014 at 9:38 PM, Kevin Ballard wrote: > > Sure, that seems like a pretty easy job to tackle. You should audit the > > whole getopts API to see where it uses String inappropriately. Any > &[String] > > parameters should probably be &[S] where , and any bare String > > parameters (if any) should probably be &str. > > > > -Kevin > > > > On May 26, 2014, at 6:29 PM, Gulshan Singh wrote: > > > > On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: > >> > >> All the methods that take &[String] should probably be rewritten to be > >> generic with and take &[S] instead, which will allow taking > either > >> a slice of Strings or a slice of &str's. > > > > > > I've been wanting to contribute to Rust for a while. This seems like the > > right thing to do and I don't think it's a hard change. Should I go ahead > > and make it? > > > > -- > > Gulshan Singh > > University of Michigan, Class of 2015 > > College of Engineering, Computer Science Major > > gulshan at umich.edu | 248.961.6317 > > Alternate E-mail: gsingh2011 at gmail.com > > > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Fri May 30 00:12:49 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Fri, 30 May 2014 11:12:49 +0400 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: 2014-05-30 5:37 GMT+04:00 Kevin Ballard : > > It shouldn't. > > The for-loop desugaring looks like > > match &mut st.execute_query() { > __i => loop { > match __i.next() { > None => break, > Some(mut __value) => { > let i = __value; > { > // for loop body goes here > } > } > } > } > } > > It's done with a match statement like this specifically to make the &mut binding of the iterator end after the for loop. Great, didn't know it. Last time I asked (on StackOverflow, I think; that was some time ago though) there were no `match`. Then from that code alone it does look like a bug to me. Note that it refers to `st.set_string("%e%")` and `for` loop ten lines above, that is, the first one. If mutable borrow of the iterator aren't escaping the loop, then this error should not appear, right? From kevin at sb.org Fri May 30 00:17:08 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 30 May 2014 00:17:08 -0700 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: On May 30, 2014, at 12:12 AM, Vladimir Matveev wrote: > 2014-05-30 5:37 GMT+04:00 Kevin Ballard : >> >> It shouldn't. >> >> The for-loop desugaring looks like >> >> match &mut st.execute_query() { >> __i => loop { >> match __i.next() { >> None => break, >> Some(mut __value) => { >> let i = __value; >> { >> // for loop body goes here >> } >> } >> } >> } >> } >> >> It's done with a match statement like this specifically to make the &mut binding of the iterator end after the for loop. > > Great, didn't know it. Last time I asked (on StackOverflow, I think; > that was some time ago though) there were no `match`. Then from that > code alone it does look like a bug to me. Note that it refers to > `st.set_string("%e%")` and `for` loop ten lines above, that is, the > first one. If mutable borrow of the iterator aren't escaping the loop, > then this error should not appear, right? The errors you printed are slightly malformed, and you only listed some of your code. Is this a database library you're writing yourself? My best guess here is that you've accidentally used the wrong lifetime on your `execute_query()` method, tying the lifetime of the `self` reference to a lifetime on the value itself. Something like this: impl<'a> Statement<'a> { pub fn execute_query(&'a mut self) { ... } } By using 'a on &'a mut self here, you've explicitly tied the reference to the lifetime of the value. This causes the mutable reference to live much longer than you expected it to, which means it's still alive when you try to subsequently borrow it on your call to .set_string(). -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From christophe.pedretti at gmail.com Fri May 30 01:54:10 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Fri, 30 May 2014 10:54:10 +0200 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: Hi All, sorry for my late replay, i am UTC+2 > Won't wrapping the first `for` loop into curly braces help? no > is this a database library you're writing yourself? yes > My best guess here is that you've accidentally used the wrong lifetime on > your `execute_query()` method, tying the lifetime of the `self` reference to > a lifetime on the value itself yes, but removing the lifetime reference on the self, compiling my library gives sql\connection.rs:57:2: 64:3 note: consider using an explicit lifetime parameter as shown: fn execute_query(&'a mut self) -> ResultSet<'a> sql\connection.rs:57 pub fn execute_query(&mut self) -> ResultSet<'a> { sql\connection.rs:58 match self.pCon.dbType { sql\connection.rs:59 SQLITE3 => { sql\connection.rs:60 if self.exec { unsafe { sqlite3_reset(self.pStmt) }; } else {self.exec=true; } sql\connection.rs:61 ResultSet { pStmt : self, error : false } sql\connection.rs:62 } ... sql\connection.rs:61:23: 61:27 error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements sql\connection.rs:61 ResultSet { pStmt : self, error : false } ^~~~ execute_query can be used only for the loop body, and if there is no variable referencing it there is no reason for the execute-query to live outside the loop (as is my example) or, with code like this : let query_result = st.execute_query() for i in query_result { ... and in this case, the query_result lives outside the loop the compiler can not distinguish these two usages ? Thanks 2014-05-30 9:17 GMT+02:00 Kevin Ballard : > On May 30, 2014, at 12:12 AM, Vladimir Matveev > wrote: > > > 2014-05-30 5:37 GMT+04:00 Kevin Ballard : > >> > >> It shouldn't. > >> > >> The for-loop desugaring looks like > >> > >> match &mut st.execute_query() { > >> __i => loop { > >> match __i.next() { > >> None => break, > >> Some(mut __value) => { > >> let i = __value; > >> { > >> // for loop body goes here > >> } > >> } > >> } > >> } > >> } > >> > >> It's done with a match statement like this specifically to make the > &mut binding of the iterator end after the for loop. > > > > Great, didn't know it. Last time I asked (on StackOverflow, I think; > > that was some time ago though) there were no `match`. Then from that > > code alone it does look like a bug to me. Note that it refers to > > `st.set_string("%e%")` and `for` loop ten lines above, that is, the > > first one. If mutable borrow of the iterator aren't escaping the loop, > > then this error should not appear, right? > > The errors you printed are slightly malformed, and you only listed some of > your code. Is this a database library you're writing yourself? My best > guess here is that you've accidentally used the wrong lifetime on your > `execute_query()` method, tying the lifetime of the `self` reference to a > lifetime on the value itself. Something like this: > > impl<'a> Statement<'a> { > pub fn execute_query(&'a mut self) { ... } > } > > By using 'a on &'a mut self here, you've explicitly tied the reference to > the lifetime of the value. This causes the mutable reference to live much > longer than you expected it to, which means it's still alive when you try > to subsequently borrow it on your call to .set_string(). > > -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Fri May 30 02:23:12 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 30 May 2014 12:23:12 +0300 Subject: [rust-dev] Function overloading is necessary In-Reply-To: References: <9654C9AB-1DBE-4D2A-89A5-1320EE5B782A@icloud.com> <042E8283-DD63-45FE-8855-86F284897351@icloud.com> Message-ID: On 2014-05-30, at 4:16, Eric Reed wrote: > That was what I was referencing in my comment about the compiler getting scared and confused. Theoretically, it should be allowed and the compiler would just require you to specify, but rustc may not be there yet. Are you saying that the compiler should be able to handle the following snippet in the future? (currently it says "error: conflicting implementations for trait `Foo`") trait Foo { fn foo(&self); } impl> Foo for T { fn foo(&self) { /* arg implements Iterator */ } } impl> Foo for T { fn foo(&self) { /* arg implements RandomAccessIterator */ } } I guess this could be called trait implementation overloading and it accomplishes the same goal as function overloading; if there is some overlap between two or more impl's, then the compiler should always use the "most specialized one" of the ones that could be used. D language has, I think, a nice and simple way of specifying how function overloading works: Given two functions foo1 and foo2... 1) If foo1 can be called with arguments that have the parameter types of foo2 and if foo2 cannot be called with the parameter types of foo1, then foo2 is "more specialized" than foo1. 2) If foo1 can be called with arguments that have the parameter types of foo2 and if foo2 can be called with the parameter types of foo1, then foo1 and foo2 are "equally specialized". This way the "most specialized" function is determined and the function call should resolve to that one. Function overloading is not allowed among functions that are defined in different modules (to prevent what they call "function hijacking"). And obviously, if there are multiple "most specialized" functions that are "equally specialized", then that's an ambiguity error. I remember seeing an edge case that showed that this way in which D specifies function overloading is in some way inferior to the way C++ specifies it. But the D way is a lot simpler to reason about. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Fri May 30 05:12:49 2014 From: ncm at cantrip.org (Nathan Myers) Date: Fri, 30 May 2014 05:12:49 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <1464ccffa88.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> <1464ccffa88.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> Message-ID: <1464d0bf600.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> A good name would be size(). That would avoid any confusion over various length definitions, and just indicate how much address space it occupies. Nathan Myers On May 29, 2014 8:11:47 PM Palmer Cox wrote: > Thinking about it more, units() is a bad name. I think a renaming could > make sense, but only if something better than len() can be found. > > -Palmer Cox > > > On Thu, May 29, 2014 at 10:55 PM, Palmer Cox wrote: > > > What about renaming len() to units()? > > > > I don't see len() as a problem, but maybe as a potential source of > > confusion. I also strongly believe that no one reads documentation if they > > *think* they understand what the code is doing. Different people will see > > len(), assume that it does whatever they want to do at the moment, and for > > a significant portion of strings that they encounter it will seem like > > their interpretation, whatever it is, is correct. So, why not rename len() > > to something like units()? Its more explicit with the value that its > > actually producing than len() and its not all that much longer to type. As > > stated, exactly what a string is varies greatly between languages, so, I > > don't think that lacking a function named len() is bad. Granted, I would > > expect that many people expect that a string will have method named len() > > (or length()) and when they don't find one, they will go to the > > documentation and find units(). I think this is a good thing since the > > documentation can then explain exactly what it does. > > > > I much prefer len() to byte_len(), though. byte_len() seems like a bit > > much to type and it seems like all the other methods on strings should then > > be renamed with the byte_ prefix which seems unpleasant. > > > > -Palmer Cox > > > > > > On Thu, May 29, 2014 at 3:39 AM, Masklinn wrote: > > > >> > >> On 2014-05-29, at 08:37 , Aravinda VK wrote: > >> > >> > I think returning length of string in bytes is just fine. Since I > >> didn't know about the availability of char_len in rust caused this > >> confusion. > >> > > >> > python 2.7 - Returns length of string in bytes, Python 3 returns number > >> of codepoints. > >> > >> Nope, depends on the string type *and* on compilation options. > >> > >> * Python 2's `str` and Python 3's `bytes` are byte sequences, their > >> len() returns their byte counts. > >> * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code > >> units count which may be UCS2 or UCS4 (depending whether the > >> interpreter was compiled with `?enable-unicode=ucs2` ? the default ? > >> or `?enable-unicode=ucs4`. Only the latter case is a true code points > >> count. > >> * Python 3.3's `str` switched to the Flexible String Representation, > >> the build-time option disappeared and len() always returns the number > >> of codepoints. > >> > >> Note that in no case to len() operations take normalisation or visual > >> composition in account. > >> > >> > JS returns number of codepoints. > >> > >> JS returns the number of UCS2 code units, which is twice the number of > >> code points for those in astral planes. > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > > > From emmanuel.surleau at gmail.com Fri May 30 06:56:17 2014 From: emmanuel.surleau at gmail.com (Emmanuel Surleau) Date: Fri, 30 May 2014 15:56:17 +0200 Subject: [rust-dev] The meaning of 'box ref foo' ? In-Reply-To: References: Message-ID: I think the 'ref' keyword removal is a very good idea. It has bitten me several times, and the idea that pattern matching something essentially performs a side effect (moving the value) leaves me uncomfortable. Cheers, Emm From rusty.gates at icloud.com Fri May 30 08:02:51 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 30 May 2014 18:02:51 +0300 Subject: [rust-dev] Confused about the precedence of 'as' operator Message-ID: The manual says that the precedence of `as` operator is lower than that of the binary `*` operator. Thus I would not expect the following to compile (but it does): let a: u16 = 1; let b: u32 = 2; let r = a * b as u16; Since multiplication is supposed to have precedence over casting, I would expect the last line to be equivalent to: let r = (a * b) as u16; ...which doesn't compile because `a` and `b` have different types. Here the compiler clearly first converts `b` to u16 and then multiplies `a` with the result of that conversion: let r = a * b as u16; ...but that should happen only if the `as` operator has a higher precedence than the binary `*` operator. From ben.striegel at gmail.com Fri May 30 09:05:26 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 30 May 2014 12:05:26 -0400 Subject: [rust-dev] The meaning of 'box ref foo' ? In-Reply-To: References: Message-ID: What you're overlooking is that patterns are used for more than just `match` expressions. They can also be used in both assignment statements and in function/closure signatures. For example, note that `x` and `y` are the same type in the following program: fn main() { let ref x = 3; let y = &3; foo(x); foo(y); } fn foo(x: &int) { println!("{:i}", *x); } Removing the `ref` keyword and making patterns reference by default would make `let x = 3;` declare a reference to an integer. Then you'd need a new keyword to express when you don't want this, and you're back at square one. On Fri, May 30, 2014 at 9:56 AM, Emmanuel Surleau < emmanuel.surleau at gmail.com> wrote: > I think the 'ref' keyword removal is a very good idea. It has bitten > me several times, and the idea that pattern matching something > essentially performs a side effect (moving the value) leaves me > uncomfortable. > > Cheers, > > Emm > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Fri May 30 09:08:32 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 30 May 2014 12:08:32 -0400 Subject: [rust-dev] Confused about the precedence of 'as' operator In-Reply-To: References: Message-ID: The manual also says that `as` somehow has a lower precedence than `*` and yet a higher precedence than `+`, which would be hilarious madness. Don't trust the manual. On Fri, May 30, 2014 at 11:02 AM, Tommi wrote: > The manual says that the precedence of `as` operator is lower than that of > the binary `*` operator. Thus I would not expect the following to compile > (but it does): > > let a: u16 = 1; > let b: u32 = 2; > > let r = a * b as u16; > > > Since multiplication is supposed to have precedence over casting, I would > expect the last line to be equivalent to: > > let r = (a * b) as u16; > > ...which doesn't compile because `a` and `b` have different types. > > > Here the compiler clearly first converts `b` to u16 and then multiplies > `a` with the result of that conversion: > > let r = a * b as u16; > > ...but that should happen only if the `as` operator has a higher > precedence than the binary `*` operator. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoelstra at wpsoftware.net Fri May 30 09:22:01 2014 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Fri, 30 May 2014 09:22:01 -0700 Subject: [rust-dev] Confused about the precedence of 'as' operator In-Reply-To: References: Message-ID: <20140530162201.GE17550@shavo.dd-wrt> I did not know that the manual agrees with me, but I've noticed the existing behaviour and find it very unintuitive. Andrew On Fri, May 30, 2014 at 06:02:51PM +0300, Tommi wrote: > The manual says that the precedence of `as` operator is lower than that of the binary `*` operator. Thus I would not expect the following to compile (but it does): > > let a: u16 = 1; > let b: u32 = 2; > > let r = a * b as u16; > > > Since multiplication is supposed to have precedence over casting, I would expect the last line to be equivalent to: > > let r = (a * b) as u16; > > ...which doesn't compile because `a` and `b` have different types. > > > Here the compiler clearly first converts `b` to u16 and then multiplies `a` with the result of that conversion: > > let r = a * b as u16; > > ...but that should happen only if the `as` operator has a higher precedence than the binary `*` operator. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school." --Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From pcwalton at mozilla.com Fri May 30 09:26:35 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 30 May 2014 09:26:35 -0700 Subject: [rust-dev] Confused about the precedence of 'as' operator In-Reply-To: References: Message-ID: <5388B13B.2080909@mozilla.com> On 5/30/14 8:02 AM, Tommi wrote: > The manual says that the precedence of `as` operator is lower than > that of the binary `*` operator. Thus I would not expect the > following to compile (but it does): > > let a: u16 = 1; let b: u32 = 2; > > let r = a * b as u16; > > > Since multiplication is supposed to have precedence over casting, I > would expect the last line to be equivalent to: > > let r = (a * b) as u16; > > ...which doesn't compile because `a` and `b` have different types. > > > Here the compiler clearly first converts `b` to u16 and then > multiplies `a` with the result of that conversion: > > let r = a * b as u16; > > ...but that should happen only if the `as` operator has a higher > precedence than the binary `*` operator. The precedence of "as" was that way in earlier versions of the language, but the manual was not updated when the language was changed. This should be considered a bug in the docs. Patrick From apoelstra at wpsoftware.net Fri May 30 09:31:38 2014 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Fri, 30 May 2014 09:31:38 -0700 Subject: [rust-dev] Detection of early end for Take Message-ID: <20140530163137.GF17550@shavo.dd-wrt> Hi guys, Take is an iterator adaptor which cuts off the contained iterator after some number of elements, always returning None. I find that I need to detect whether I'm getting None from a Take iterator because I've read all of the elements I expected or because the underlying iterator ran dry unexpectedly. (Specifically, I'm parsing some data from the network and want to detect an early EOM.) This seems like it might be only me, so I'm posing this to the list: if there was a function Take::is_done(&self) -> bool, which returned whether or not the Take had returned as many elements as it could, would that be generally useful? I'm happy to submit a PR but want to check that this is appropriate for the standard library. Thanks Andrew -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school." --Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From matthieu.monrocq at gmail.com Fri May 30 09:32:19 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 30 May 2014 18:32:19 +0200 Subject: [rust-dev] A few random questions In-Reply-To: References: <5387A76A.2090901@mozilla.com> Message-ID: On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky wrote: > > Since browsers were brought up, here is the Google C++ style guide on > exceptions: > > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions > > As someone who works for Google, I can attest, that exceptions are > encouraged in Google style guides for Python and Java and the main > reason they are forbidden in C++ is their memory safety. Google has a > big amount of pre-exceptions C++ code, and it will break in unexpected > places if exceptions are allowed. > > Yes, which is a common issue. Exception usage requires exception-safe code. But then, exception-safe code is also code resilient in the face of introducing other return paths so it's just overall better whether in the presence of exceptions or not... > Go is a different story. It deliberately refuses to support exceptions > even though it has GC and hence has no problems with exception memory > safety whatsoever. The lack of exception might be one of the main > reasons (if not the main reason), why Go is not so popular even within > Google. > > Personally, I've found exceptions too unwieldy. As I mentioned, the issue of catching an exception is "now, how do I recover ?". Note that Rust and Go do have exceptions (and unwinding), it's just that you have to create a dedicated task instead of a try/catch block. Indeed, it's more verbose (which is mostly a matter of libraries/macros) and it's also less efficient (which could be addressed, though at compiler level); however it's just plain safer: now that shared-state/updates to the external world are explicit, you can much more easily evaluate what it takes to recover. > On Thu, May 29, 2014 at 4:39 PM, comex wrote: > > On Thu, May 29, 2014 at 7:10 PM, Oleg Eterevsky > wrote: > >> The projects in C++ that forbid exceptions are doing so not because of > >> some prejudice, but because exceptions in C++ are unsafe. In Java > >> standard library exceptions are ubiquitous. > > > > If you mean checked exceptions, I hear that they're quite unpopular, > > although I don't use Java. > > > > Since browsers were brought up, here is the Google C++ style guide on > > exceptions: > > > > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions > > > > It bans them due to a variety of downsides which would only be > > partially addressed by checked-exception-like safety systems. I think > > Google Java code does use exceptions, but that's language culture for > > you. > > > > As a related data point, Go eschews exceptions entirely due to prejudice: > > > > http://golang.org/doc/faq#exceptions > > > > Not that I agree with most of Go's design decisions... still, I think > > these examples are enough to demonstrate that there are legitimate > > reasons to prefer a language designed without exceptions. > > > > I think it may be good for you to get more experience with Rust, > > although as I mentioned, I also lack experience. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Fri May 30 09:43:43 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 30 May 2014 18:43:43 +0200 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: <1464d0bf600.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> <1464ccffa88.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> <1464d0bf600.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> Message-ID: Except that in C++ std::basic_string::size and std::basic_string:length are synonymous (both return the number of CharTs, which in std::string is also the number of bytes). Thus I am unsure whether this would end up helping C++ developers. Might help others though. On Fri, May 30, 2014 at 2:12 PM, Nathan Myers wrote: > A good name would be size(). That would avoid any confusion over various > length definitions, and just indicate how much address space it occupies. > > Nathan Myers > > > On May 29, 2014 8:11:47 PM Palmer Cox wrote: > > Thinking about it more, units() is a bad name. I think a renaming could >> make sense, but only if something better than len() can be found. >> >> -Palmer Cox >> >> >> On Thu, May 29, 2014 at 10:55 PM, Palmer Cox wrote: >> >> > What about renaming len() to units()? >> > >> > I don't see len() as a problem, but maybe as a potential source of >> > confusion. I also strongly believe that no one reads documentation if >> they >> > *think* they understand what the code is doing. Different people will >> see >> > len(), assume that it does whatever they want to do at the moment, and >> for >> > a significant portion of strings that they encounter it will seem like >> > their interpretation, whatever it is, is correct. So, why not rename >> len() >> > to something like units()? Its more explicit with the value that its >> > actually producing than len() and its not all that much longer to type. >> As >> > stated, exactly what a string is varies greatly between languages, so, I >> > don't think that lacking a function named len() is bad. Granted, I would >> > expect that many people expect that a string will have method named >> len() >> > (or length()) and when they don't find one, they will go to the >> > documentation and find units(). I think this is a good thing since the >> > documentation can then explain exactly what it does. >> > >> > I much prefer len() to byte_len(), though. byte_len() seems like a bit >> > much to type and it seems like all the other methods on strings should >> then >> > be renamed with the byte_ prefix which seems unpleasant. >> > >> > -Palmer Cox >> > >> > >> > On Thu, May 29, 2014 at 3:39 AM, Masklinn >> wrote: >> > >> >> >> >> On 2014-05-29, at 08:37 , Aravinda VK >> wrote: >> >> >> >> > I think returning length of string in bytes is just fine. Since I >> >> didn't know about the availability of char_len in rust caused this >> >> confusion. >> >> > >> >> > python 2.7 - Returns length of string in bytes, Python 3 returns >> number >> >> of codepoints. >> >> >> >> Nope, depends on the string type *and* on compilation options. >> >> >> >> * Python 2's `str` and Python 3's `bytes` are byte sequences, their >> >> len() returns their byte counts. >> >> * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code >> >> units count which may be UCS2 or UCS4 (depending whether the >> >> interpreter was compiled with `?enable-unicode=ucs2` ? the default ? >> >> or `?enable-unicode=ucs4`. Only the latter case is a true code points >> >> count. >> >> * Python 3.3's `str` switched to the Flexible String Representation, >> >> the build-time option disappeared and len() always returns the number >> >> of codepoints. >> >> >> >> Note that in no case to len() operations take normalisation or visual >> >> composition in account. >> >> >> >> > JS returns number of codepoints. >> >> >> >> JS returns the number of UCS2 code units, which is twice the number of >> >> code points for those in astral planes. >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> > >> > >> > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eg1290 at gmail.com Fri May 30 09:51:10 2014 From: eg1290 at gmail.com (Evan G) Date: Fri, 30 May 2014 11:51:10 -0500 Subject: [rust-dev] Detection of early end for Take In-Reply-To: <20140530163137.GF17550@shavo.dd-wrt> References: <20140530163137.GF17550@shavo.dd-wrt> Message-ID: Instead of using a for statement, try looping over a custom iterator that returns an Enum. On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra wrote: > Hi guys, > > > Take is an iterator adaptor which cuts off the contained iterator after > some number of elements, always returning None. > > I find that I need to detect whether I'm getting None from a Take > iterator because I've read all of the elements I expected or because the > underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > some data from the network and want to detect an early EOM.) > > > This seems like it might be only me, so I'm posing this to the list: if > there was a function Take::is_done(&self) -> bool, which returned whether > or not the Take had returned as many elements as it could, would that be > generally useful? > > I'm happy to submit a PR but want to check that this is appropriate for > the standard library. > > > > Thanks > > Andrew > > > > -- > Andrew Poelstra > Mathematics Department, University of Texas at Austin > Email: apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew > > "If they had taught a class on how to be the kind of citizen Dick Cheney > worries about, I would have finished high school." --Edward Snowden > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Fri May 30 09:57:50 2014 From: sfackler at gmail.com (Steven Fackler) Date: Fri, 30 May 2014 09:57:50 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: References: <20140530163137.GF17550@shavo.dd-wrt> Message-ID: It may not fulfill your exact use case, but you can get this in a way: let mut foo = bar.iter().peekable(); { let mut limit_foo = foo.by_ref().limit(50); for baz in limit_foo { ... } } if foo.is_empty() { ... } Steven Fackler On Fri, May 30, 2014 at 9:51 AM, Evan G wrote: > Instead of using a for statement, try looping over a custom iterator that > returns an Enum. > > > On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra < > apoelstra at wpsoftware.net> wrote: > >> Hi guys, >> >> >> Take is an iterator adaptor which cuts off the contained iterator after >> some number of elements, always returning None. >> >> I find that I need to detect whether I'm getting None from a Take >> iterator because I've read all of the elements I expected or because the >> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing >> some data from the network and want to detect an early EOM.) >> >> >> This seems like it might be only me, so I'm posing this to the list: if >> there was a function Take::is_done(&self) -> bool, which returned whether >> or not the Take had returned as many elements as it could, would that be >> generally useful? >> >> I'm happy to submit a PR but want to check that this is appropriate for >> the standard library. >> >> >> >> Thanks >> >> Andrew >> >> >> >> -- >> Andrew Poelstra >> Mathematics Department, University of Texas at Austin >> Email: apoelstra at wpsoftware.net >> Web: http://www.wpsoftware.net/andrew >> >> "If they had taught a class on how to be the kind of citizen Dick Cheney >> worries about, I would have finished high school." --Edward Snowden >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoelstra at wpsoftware.net Fri May 30 10:09:46 2014 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Fri, 30 May 2014 10:09:46 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: References: <20140530163137.GF17550@shavo.dd-wrt> Message-ID: <20140530170946.GM17550@shavo.dd-wrt> Hi, thanks, this works well for me. I think you mean .take() rather than .limit(). On Fri, May 30, 2014 at 09:57:50AM -0700, Steven Fackler wrote: > It may not fulfill your exact use case, but you can get this in a way: > > let mut foo = bar.iter().peekable(); > { > let mut limit_foo = foo.by_ref().limit(50); > for baz in limit_foo { > ... > } > } > if foo.is_empty() { > ... > } > > Steven Fackler > > > On Fri, May 30, 2014 at 9:51 AM, Evan G wrote: > > > Instead of using a for statement, try looping over a custom iterator that > > returns an Enum. > > > > > > On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra < > > apoelstra at wpsoftware.net> wrote: > > > >> Hi guys, > >> > >> > >> Take is an iterator adaptor which cuts off the contained iterator after > >> some number of elements, always returning None. > >> > >> I find that I need to detect whether I'm getting None from a Take > >> iterator because I've read all of the elements I expected or because the > >> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > >> some data from the network and want to detect an early EOM.) > >> > >> > >> This seems like it might be only me, so I'm posing this to the list: if > >> there was a function Take::is_done(&self) -> bool, which returned whether > >> or not the Take had returned as many elements as it could, would that be > >> generally useful? > >> > >> I'm happy to submit a PR but want to check that this is appropriate for > >> the standard library. > >> > >> > >> > >> Thanks > >> > >> Andrew > >> > >> > >> > >> -- > >> Andrew Poelstra > >> Mathematics Department, University of Texas at Austin > >> Email: apoelstra at wpsoftware.net > >> Web: http://www.wpsoftware.net/andrew > >> > >> "If they had taught a class on how to be the kind of citizen Dick Cheney > >> worries about, I would have finished high school." --Edward Snowden > >> > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > >> > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school." --Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From apoelstra at wpsoftware.net Fri May 30 10:18:48 2014 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Fri, 30 May 2014 10:18:48 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: References: <20140530163137.GF17550@shavo.dd-wrt> Message-ID: <20140530171847.GN17550@shavo.dd-wrt> Oh, I sent my earlier message prematurely. The problem here is that I want to move the original iterator forward by the appropriate amount (not one further), since I'm passing a iter.by_ref() to each of my deserialization routines in turn. It seems that if I use .peekable() I either move the original iterator one position too far, or not at all, depending on how exactly I do it. I could refactor to make my deserialization techniques require a Peekable, but this isn't logically necessary because I can accomplish my goal by manually counting iterations, so it would be an abstraction leak. Andrew On Fri, May 30, 2014 at 09:57:50AM -0700, Steven Fackler wrote: > It may not fulfill your exact use case, but you can get this in a way: > > let mut foo = bar.iter().peekable(); > { > let mut limit_foo = foo.by_ref().limit(50); > for baz in limit_foo { > ... > } > } > if foo.is_empty() { > ... > } > > Steven Fackler > > > On Fri, May 30, 2014 at 9:51 AM, Evan G wrote: > > > Instead of using a for statement, try looping over a custom iterator that > > returns an Enum. > > > > > > On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra < > > apoelstra at wpsoftware.net> wrote: > > > >> Hi guys, > >> > >> > >> Take is an iterator adaptor which cuts off the contained iterator after > >> some number of elements, always returning None. > >> > >> I find that I need to detect whether I'm getting None from a Take > >> iterator because I've read all of the elements I expected or because the > >> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > >> some data from the network and want to detect an early EOM.) > >> > >> > >> This seems like it might be only me, so I'm posing this to the list: if > >> there was a function Take::is_done(&self) -> bool, which returned whether > >> or not the Take had returned as many elements as it could, would that be > >> generally useful? > >> > >> I'm happy to submit a PR but want to check that this is appropriate for > >> the standard library. > >> > >> > >> > >> Thanks > >> > >> Andrew > >> > >> > >> > >> -- > >> Andrew Poelstra > >> Mathematics Department, University of Texas at Austin > >> Email: apoelstra at wpsoftware.net > >> Web: http://www.wpsoftware.net/andrew > >> > >> "If they had taught a class on how to be the kind of citizen Dick Cheney > >> worries about, I would have finished high school." --Edward Snowden > >> > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > >> > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school." --Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From oleg at eterevsky.com Fri May 30 11:35:17 2014 From: oleg at eterevsky.com (Oleg Eterevsky) Date: Fri, 30 May 2014 11:35:17 -0700 Subject: [rust-dev] A few random questions In-Reply-To: References: <5387A76A.2090901@mozilla.com> Message-ID: > Personally, I've found exceptions too unwieldy. As I mentioned, the issue of catching an exception is "now, how do I recover ?". In my experience it's not really a problem. Usually you just gracefully report an error and either exit the program, or write error to log and stop the operation. > Note that Rust and Go do have exceptions (and unwinding), it's just that you have to create a dedicated task instead of a try/catch block. I can see the advantages of this solution. The only thing I don't see is how to pass any meaningful state with an error. On Fri, May 30, 2014 at 9:32 AM, Matthieu Monrocq wrote: > > > > On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky wrote: >> >> > Since browsers were brought up, here is the Google C++ style guide on >> exceptions: >> > >> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions >> >> As someone who works for Google, I can attest, that exceptions are >> encouraged in Google style guides for Python and Java and the main >> reason they are forbidden in C++ is their memory safety. Google has a >> big amount of pre-exceptions C++ code, and it will break in unexpected >> places if exceptions are allowed. >> > > Yes, which is a common issue. Exception usage requires exception-safe code. > But then, exception-safe code is also code resilient in the face of > introducing other return paths so it's just overall better whether in the > presence of exceptions or not... > >> >> Go is a different story. It deliberately refuses to support exceptions >> even though it has GC and hence has no problems with exception memory >> safety whatsoever. The lack of exception might be one of the main >> reasons (if not the main reason), why Go is not so popular even within >> Google. >> > > Personally, I've found exceptions too unwieldy. As I mentioned, the issue of > catching an exception is "now, how do I recover ?". > > Note that Rust and Go do have exceptions (and unwinding), it's just that you > have to create a dedicated task instead of a try/catch block. Indeed, it's > more verbose (which is mostly a matter of libraries/macros) and it's also > less efficient (which could be addressed, though at compiler level); however > it's just plain safer: now that shared-state/updates to the external world > are explicit, you can much more easily evaluate what it takes to recover. > > >> >> On Thu, May 29, 2014 at 4:39 PM, comex wrote: >> > On Thu, May 29, 2014 at 7:10 PM, Oleg Eterevsky >> > wrote: >> >> The projects in C++ that forbid exceptions are doing so not because of >> >> some prejudice, but because exceptions in C++ are unsafe. In Java >> >> standard library exceptions are ubiquitous. >> > >> > If you mean checked exceptions, I hear that they're quite unpopular, >> > although I don't use Java. >> > >> > Since browsers were brought up, here is the Google C++ style guide on >> > exceptions: >> > >> > >> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions >> > >> > It bans them due to a variety of downsides which would only be >> > partially addressed by checked-exception-like safety systems. I think >> > Google Java code does use exceptions, but that's language culture for >> > you. >> > >> > As a related data point, Go eschews exceptions entirely due to >> > prejudice: >> > >> > http://golang.org/doc/faq#exceptions >> > >> > Not that I agree with most of Go's design decisions... still, I think >> > these examples are enough to demonstrate that there are legitimate >> > reasons to prefer a language designed without exceptions. >> > >> > I think it may be good for you to get more experience with Rust, >> > although as I mentioned, I also lack experience. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > From igor at mir2.org Fri May 30 11:41:46 2014 From: igor at mir2.org (Igor Bukanov) Date: Fri, 30 May 2014 20:41:46 +0200 Subject: [rust-dev] EnumSet, CLike and enums Message-ID: Is it possible to somehow automatically derive collections::enum_set::CLike for a enum? The idea of writing impl CLike for MyEnum { fn to_uint(&self) -> uint { return *self as uint; } fn from_uint(n: uint) -> Flag { match n { 0 => EnumConst1, ... _ => fail!("{} does not match any enum case, n) } } } just to get a type safe bit set EnumSet is rather discouraging. On a related note I see that EnumSet never checks that CLike::to_int result stays below the word size. Is it a bug? From comexk at gmail.com Fri May 30 11:44:40 2014 From: comexk at gmail.com (comex) Date: Fri, 30 May 2014 14:44:40 -0400 Subject: [rust-dev] A few random questions In-Reply-To: References: <5387A76A.2090901@mozilla.com> Message-ID: On Fri, May 30, 2014 at 2:35 PM, Oleg Eterevsky wrote: > I can see the advantages of this solution. The only thing I don't see > is how to pass any meaningful state with an error. Not sure if you know this, but you can pass any object to the single-argument version of fail!: http://doc.rust-lang.org/std/macros/macro.fail!.html From matthieu.monrocq at gmail.com Fri May 30 12:02:23 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 30 May 2014 21:02:23 +0200 Subject: [rust-dev] EnumSet, CLike and enums In-Reply-To: References: Message-ID: I advise you to check the tests accompanying EnumSet (in the source code): http://static.rust-lang.org/doc/master/src/collections/home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcollections/enum_set.rs.html#144-158 They show a simple implementation: impl CLike for Foo { fn to_uint(&self) -> uint { *self as uint } fn from_uint(v: uint) -> Foo { unsafe { mem::transmute(v) } } } which uses transmute to avoid that manual maintenance. Note though that in general if you wanted to add new enum values while maintaining it sorted alphabetically and still be backward-compatible you would need to handle the values manually. On Fri, May 30, 2014 at 8:41 PM, Igor Bukanov wrote: > Is it possible to somehow automatically derive > collections::enum_set::CLike for a enum? The idea of writing > > impl CLike for MyEnum { > fn to_uint(&self) -> uint { > return *self as uint; > } > > fn from_uint(n: uint) -> Flag { > match n { > 0 => EnumConst1, > ... > _ => fail!("{} does not match any enum case, n) > } > } > } > > just to get a type safe bit set EnumSet is rather discouraging. > > On a related note I see that EnumSet never checks that CLike::to_int > result stays below the word size. Is it a bug? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Fri May 30 12:56:59 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Fri, 30 May 2014 12:56:59 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: <20140530171847.GN17550@shavo.dd-wrt> References: <20140530163137.GF17550@shavo.dd-wrt> <20140530171847.GN17550@shavo.dd-wrt> Message-ID: Slightly off topic, what kind of deserialization are you working on? If it's a generic deserializer, I'm putting together a prototype for https://github.com/rust-lang/rfcs/pull/22 in my https://github.com/erickt/rust-serde repository. Maybe we can collaborate. On Friday, May 30, 2014, Andrew Poelstra wrote: > > Oh, I sent my earlier message prematurely. The problem here is that I > want to move the original iterator forward by the appropriate amount > (not one further), since I'm passing a iter.by_ref() to each of my > deserialization routines in turn. > > It seems that if I use .peekable() I either move the original iterator > one position too far, or not at all, depending on how exactly I do it. > > I could refactor to make my deserialization techniques require a > Peekable, but this isn't logically necessary because I can accomplish my > goal by manually counting iterations, so it would be an abstraction > leak. > > > > Andrew > > > > On Fri, May 30, 2014 at 09:57:50AM -0700, Steven Fackler wrote: > > It may not fulfill your exact use case, but you can get this in a way: > > > > let mut foo = bar.iter().peekable(); > > { > > let mut limit_foo = foo.by_ref().limit(50); > > for baz in limit_foo { > > ... > > } > > } > > if foo.is_empty() { > > ... > > } > > > > Steven Fackler > > > > > > On Fri, May 30, 2014 at 9:51 AM, Evan G > > wrote: > > > > > Instead of using a for statement, try looping over a custom iterator > that > > > returns an Enum. > > > > > > > > > On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra < > > > apoelstra at wpsoftware.net > wrote: > > > > > >> Hi guys, > > >> > > >> > > >> Take is an iterator adaptor which cuts off the contained iterator > after > > >> some number of elements, always returning None. > > >> > > >> I find that I need to detect whether I'm getting None from a Take > > >> iterator because I've read all of the elements I expected or because > the > > >> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > > >> some data from the network and want to detect an early EOM.) > > >> > > >> > > >> This seems like it might be only me, so I'm posing this to the list: > if > > >> there was a function Take::is_done(&self) -> bool, which returned > whether > > >> or not the Take had returned as many elements as it could, would that > be > > >> generally useful? > > >> > > >> I'm happy to submit a PR but want to check that this is appropriate > for > > >> the standard library. > > >> > > >> > > >> > > >> Thanks > > >> > > >> Andrew > > >> > > >> > > >> > > >> -- > > >> Andrew Poelstra > > >> Mathematics Department, University of Texas at Austin > > >> Email: apoelstra at wpsoftware.net > > >> Web: http://www.wpsoftware.net/andrew > > >> > > >> "If they had taught a class on how to be the kind of citizen Dick > Cheney > > >> worries about, I would have finished high school." --Edward Snowden > > >> > > >> > > >> _______________________________________________ > > >> Rust-dev mailing list > > >> Rust-dev at mozilla.org > > >> https://mail.mozilla.org/listinfo/rust-dev > > >> > > >> > > > > > > _______________________________________________ > > > Rust-dev mailing list > > > Rust-dev at mozilla.org > > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > > > -- > Andrew Poelstra > Mathematics Department, University of Texas at Austin > Email: apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew > > "If they had taught a class on how to be the kind of citizen Dick Cheney > worries about, I would have finished high school." --Edward Snowden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoelstra at wpsoftware.net Fri May 30 13:36:58 2014 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Fri, 30 May 2014 13:36:58 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: References: <20140530163137.GF17550@shavo.dd-wrt> <20140530171847.GN17550@shavo.dd-wrt> Message-ID: <20140530203657.GC17550@shavo.dd-wrt> Sorry, no, I'm deserializing data from the Bitcoin p2p network. There's a lot of odd quirks (mostly, the integer widths are fairly arbitrary and sometimes variable-width) which wouldn't be suitable for a general purpose [de]serializing routine. Andrew On Fri, May 30, 2014 at 12:56:59PM -0700, Erick Tryzelaar wrote: > Slightly off topic, what kind of deserialization are you working on? If > it's a generic deserializer, I'm putting together a prototype for > https://github.com/rust-lang/rfcs/pull/22 in my > https://github.com/erickt/rust-serde repository. Maybe we can collaborate. > > On Friday, May 30, 2014, Andrew Poelstra wrote: > > > > > Oh, I sent my earlier message prematurely. The problem here is that I > > want to move the original iterator forward by the appropriate amount > > (not one further), since I'm passing a iter.by_ref() to each of my > > deserialization routines in turn. > > > > It seems that if I use .peekable() I either move the original iterator > > one position too far, or not at all, depending on how exactly I do it. > > > > I could refactor to make my deserialization techniques require a > > Peekable, but this isn't logically necessary because I can accomplish my > > goal by manually counting iterations, so it would be an abstraction > > leak. > > > > > > > > Andrew > > > > > > > > On Fri, May 30, 2014 at 09:57:50AM -0700, Steven Fackler wrote: > > > It may not fulfill your exact use case, but you can get this in a way: > > > > > > let mut foo = bar.iter().peekable(); > > > { > > > let mut limit_foo = foo.by_ref().limit(50); > > > for baz in limit_foo { > > > ... > > > } > > > } > > > if foo.is_empty() { > > > ... > > > } > > > > > > Steven Fackler > > > > > > > > > On Fri, May 30, 2014 at 9:51 AM, Evan G > > > wrote: > > > > > > > Instead of using a for statement, try looping over a custom iterator > > that > > > > returns an Enum. > > > > > > > > > > > > On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra < > > > > apoelstra at wpsoftware.net > wrote: > > > > > > > >> Hi guys, > > > >> > > > >> > > > >> Take is an iterator adaptor which cuts off the contained iterator > > after > > > >> some number of elements, always returning None. > > > >> > > > >> I find that I need to detect whether I'm getting None from a Take > > > >> iterator because I've read all of the elements I expected or because > > the > > > >> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > > > >> some data from the network and want to detect an early EOM.) > > > >> > > > >> > > > >> This seems like it might be only me, so I'm posing this to the list: > > if > > > >> there was a function Take::is_done(&self) -> bool, which returned > > whether > > > >> or not the Take had returned as many elements as it could, would that > > be > > > >> generally useful? > > > >> > > > >> I'm happy to submit a PR but want to check that this is appropriate > > for > > > >> the standard library. > > > >> > > > >> > > > >> > > > >> Thanks > > > >> > > > >> Andrew > > > >> > > > >> > > > >> > > > >> -- > > > >> Andrew Poelstra > > > >> Mathematics Department, University of Texas at Austin > > > >> Email: apoelstra at wpsoftware.net > > > >> Web: http://www.wpsoftware.net/andrew > > > >> > > > >> "If they had taught a class on how to be the kind of citizen Dick > > Cheney > > > >> worries about, I would have finished high school." --Edward Snowden > > > >> > > > >> > > > >> _______________________________________________ > > > >> Rust-dev mailing list > > > >> Rust-dev at mozilla.org > > > >> https://mail.mozilla.org/listinfo/rust-dev > > > >> > > > >> > > > > > > > > _______________________________________________ > > > > Rust-dev mailing list > > > > Rust-dev at mozilla.org > > > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > > > > > > > -- > > Andrew Poelstra > > Mathematics Department, University of Texas at Austin > > Email: apoelstra at wpsoftware.net > > Web: http://www.wpsoftware.net/andrew > > > > "If they had taught a class on how to be the kind of citizen Dick Cheney > > worries about, I would have finished high school." --Edward Snowden > > > > -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school." --Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From steve at steveklabnik.com Fri May 30 13:59:10 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Fri, 30 May 2014 13:59:10 -0700 Subject: [rust-dev] Confused about the precedence of 'as' operator In-Reply-To: <5388B13B.2080909@mozilla.com> References: <5388B13B.2080909@mozilla.com> Message-ID: Yup. The manual should not be trusted. We'll fix it! From kevin at sb.org Fri May 30 15:12:01 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 30 May 2014 15:12:01 -0700 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: I'm assuming that Statement has its own lifetime parameter? And that's the 'a you're using here? Try using a new lifetime. pub fn execute_query<'b>(&'b mut self) -> ResultSelf<'b>; -Kevin On May 30, 2014, at 1:54 AM, Christophe Pedretti wrote: > Hi All, > > sorry for my late replay, i am UTC+2 > > > Won't wrapping the first `for` loop into curly braces help? > no > > > is this a database library you're writing yourself? > yes > > > My best guess here is that you've accidentally used the wrong lifetime on > > your `execute_query()` method, tying the lifetime of the `self` reference to > > a lifetime on the value itself > > yes, but removing the lifetime reference on the self, compiling my library gives > > sql\connection.rs:57:2: 64:3 note: consider using an explicit lifetime parameter as shown: fn execute_query(&'a mut self) -> ResultSet<'a> > sql\connection.rs:57 pub fn execute_query(&mut self) -> ResultSet<'a> { > sql\connection.rs:58 match self.pCon.dbType { > sql\connection.rs:59 SQLITE3 => { > sql\connection.rs:60 if self.exec { unsafe { sqlite3_reset(self.pStmt) }; } else {self.exec=true; } > sql\connection.rs:61 ResultSet { pStmt : self, error : false } > sql\connection.rs:62 } > ... > sql\connection.rs:61:23: 61:27 error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements > sql\connection.rs:61 ResultSet { pStmt : self, error : false } > ^~~~ > > execute_query can be used only for the loop body, and if there is no variable referencing it there is no reason for the execute-query to live outside the loop (as is my example) > > or, with code like this : > > let query_result = st.execute_query() > for i in query_result { > ... > > and in this case, the query_result lives outside the loop > > the compiler can not distinguish these two usages ? > > Thanks > > 2014-05-30 9:17 GMT+02:00 Kevin Ballard : > On May 30, 2014, at 12:12 AM, Vladimir Matveev wrote: > > > 2014-05-30 5:37 GMT+04:00 Kevin Ballard : > >> > >> It shouldn't. > >> > >> The for-loop desugaring looks like > >> > >> match &mut st.execute_query() { > >> __i => loop { > >> match __i.next() { > >> None => break, > >> Some(mut __value) => { > >> let i = __value; > >> { > >> // for loop body goes here > >> } > >> } > >> } > >> } > >> } > >> > >> It's done with a match statement like this specifically to make the &mut binding of the iterator end after the for loop. > > > > Great, didn't know it. Last time I asked (on StackOverflow, I think; > > that was some time ago though) there were no `match`. Then from that > > code alone it does look like a bug to me. Note that it refers to > > `st.set_string("%e%")` and `for` loop ten lines above, that is, the > > first one. If mutable borrow of the iterator aren't escaping the loop, > > then this error should not appear, right? > > The errors you printed are slightly malformed, and you only listed some of your code. Is this a database library you're writing yourself? My best guess here is that you've accidentally used the wrong lifetime on your `execute_query()` method, tying the lifetime of the `self` reference to a lifetime on the value itself. Something like this: > > impl<'a> Statement<'a> { > pub fn execute_query(&'a mut self) { ... } > } > > By using 'a on &'a mut self here, you've explicitly tied the reference to the lifetime of the value. This causes the mutable reference to live much longer than you expected it to, which means it's still alive when you try to subsequently borrow it on your call to .set_string(). > > -Kevin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From kevin at sb.org Fri May 30 15:21:08 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 30 May 2014 15:21:08 -0700 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: References: Message-ID: <900D896B-7D62-4E75-93B1-776B5619BF1E@sb.org> If I'm interpreting this right, you also need to add a second lifetime parameter to your ResultSet object. This way the lifetime used for its reference to the Statement can be different than the lifetime on the Statement type itself (I assume Statement has a lifetime to refer to the database). I whipped up an equivalent bit of code. The following reproduces your error: struct Root { s: String } struct One<'a> { root: &'a mut Root } struct Two<'a> { one: &'a mut One<'a> } impl Root { pub fn make_one<'a>(&'a mut self) -> One<'a> { One { root: self } } } impl<'a> One<'a> { pub fn make_two(&'a mut self) -> Two<'a> { Two { one: self } } pub fn foo(&mut self) { println!("foo"); } } fn main() { let mut r = Root { s: "root".to_string() }; let mut one = r.make_one(); match one.make_two() { x => { println!("root: {}", x.one.root.s); } } one.foo(); } The equivalent change here that I'm proposing is updating Two to struct Two<'a, 'b> { one: &'b mut One<'a> } and the definition of make_two() to pub fn make_two<'b>(&'b mut self) -> Two<'a, 'b> { Two { one: self } } -Kevin On May 30, 2014, at 3:12 PM, Kevin Ballard wrote: > I'm assuming that Statement has its own lifetime parameter? And that's the 'a you're using here? > > Try using a new lifetime. > > pub fn execute_query<'b>(&'b mut self) -> ResultSelf<'b>; > > -Kevin > > On May 30, 2014, at 1:54 AM, Christophe Pedretti wrote: > >> Hi All, >> >> sorry for my late replay, i am UTC+2 >> >> > Won't wrapping the first `for` loop into curly braces help? >> no >> >> > is this a database library you're writing yourself? >> yes >> >> > My best guess here is that you've accidentally used the wrong lifetime on >> > your `execute_query()` method, tying the lifetime of the `self` reference to >> > a lifetime on the value itself >> >> yes, but removing the lifetime reference on the self, compiling my library gives >> >> sql\connection.rs:57:2: 64:3 note: consider using an explicit lifetime parameter as shown: fn execute_query(&'a mut self) -> ResultSet<'a> >> sql\connection.rs:57 pub fn execute_query(&mut self) -> ResultSet<'a> { >> sql\connection.rs:58 match self.pCon.dbType { >> sql\connection.rs:59 SQLITE3 => { >> sql\connection.rs:60 if self.exec { unsafe { sqlite3_reset(self.pStmt) }; } else {self.exec=true; } >> sql\connection.rs:61 ResultSet { pStmt : self, error : false } >> sql\connection.rs:62 } >> ... >> sql\connection.rs:61:23: 61:27 error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements >> sql\connection.rs:61 ResultSet { pStmt : self, error : false } >> ^~~~ >> >> execute_query can be used only for the loop body, and if there is no variable referencing it there is no reason for the execute-query to live outside the loop (as is my example) >> >> or, with code like this : >> >> let query_result = st.execute_query() >> for i in query_result { >> ... >> >> and in this case, the query_result lives outside the loop >> >> the compiler can not distinguish these two usages ? >> >> Thanks >> >> 2014-05-30 9:17 GMT+02:00 Kevin Ballard : >> On May 30, 2014, at 12:12 AM, Vladimir Matveev wrote: >> >> > 2014-05-30 5:37 GMT+04:00 Kevin Ballard : >> >> >> >> It shouldn't. >> >> >> >> The for-loop desugaring looks like >> >> >> >> match &mut st.execute_query() { >> >> __i => loop { >> >> match __i.next() { >> >> None => break, >> >> Some(mut __value) => { >> >> let i = __value; >> >> { >> >> // for loop body goes here >> >> } >> >> } >> >> } >> >> } >> >> } >> >> >> >> It's done with a match statement like this specifically to make the &mut binding of the iterator end after the for loop. >> > >> > Great, didn't know it. Last time I asked (on StackOverflow, I think; >> > that was some time ago though) there were no `match`. Then from that >> > code alone it does look like a bug to me. Note that it refers to >> > `st.set_string("%e%")` and `for` loop ten lines above, that is, the >> > first one. If mutable borrow of the iterator aren't escaping the loop, >> > then this error should not appear, right? >> >> The errors you printed are slightly malformed, and you only listed some of your code. Is this a database library you're writing yourself? My best guess here is that you've accidentally used the wrong lifetime on your `execute_query()` method, tying the lifetime of the `self` reference to a lifetime on the value itself. Something like this: >> >> impl<'a> Statement<'a> { >> pub fn execute_query(&'a mut self) { ... } >> } >> >> By using 'a on &'a mut self here, you've explicitly tied the reference to the lifetime of the value. This causes the mutable reference to live much longer than you expected it to, which means it's still alive when you try to subsequently borrow it on your call to .set_string(). >> >> -Kevin >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From kevin at sb.org Fri May 30 18:54:45 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 30 May 2014 18:54:45 -0700 Subject: [rust-dev] The meaning of 'box ref foo' ? In-Reply-To: References: Message-ID: Not only this, but match patterns are also extremely often used intentionally to move values. The trivial example is something like match some_opt_val { Some(x) => do_something_with(x), None => default_behavior() } By-ref matching is actually the more infrequent type of matching in my experience. -Kevin On May 30, 2014, at 9:05 AM, Benjamin Striegel wrote: > What you're overlooking is that patterns are used for more than just `match` expressions. They can also be used in both assignment statements and in function/closure signatures. For example, note that `x` and `y` are the same type in the following program: > > fn main() { > let ref x = 3; > let y = &3; > foo(x); > foo(y); > } > > fn foo(x: &int) { > println!("{:i}", *x); > } > > > Removing the `ref` keyword and making patterns reference by default would make `let x = 3;` declare a reference to an integer. Then you'd need a new keyword to express when you don't want this, and you're back at square one. > > > On Fri, May 30, 2014 at 9:56 AM, Emmanuel Surleau wrote: > I think the 'ref' keyword removal is a very good idea. It has bitten > me several times, and the idea that pattern matching something > essentially performs a side effect (moving the value) leaves me > uncomfortable. > > Cheers, > > Emm > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From kevin at sb.org Fri May 30 18:56:46 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 30 May 2014 18:56:46 -0700 Subject: [rust-dev] How to find Unicode string length in rustlang In-Reply-To: References: <5385ACDD.2000505@exyr.org> <5385B28F.4040708@exyr.org> <76020AD1-872A-4740-84CA-8D052A028866@sb.org> <81C58402-C2CA-45BA-97FD-72B9822F50A6@sb.org> <5386622E.8050308@gmail.com> <18D1D7BA-027F-460B-98EE-B5014E1E84E2@sb.org> <87B410CA-2B15-44ED-BDE6-54DB0D03015B@sb.org> <65DDC8E9-FC66-42A9-8010-03BB104A2643@masklinn.net> <1464ccffa88.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> <1464d0bf600.276e.335f4863ad3e7c521d63e242ab2886e0@cantrip.org> Message-ID: <7315AAE3-9BE3-4899-BC21-AFD7B2A45002@sb.org> This is a very long bikeshed for something which there's no evidence is even a problem. I propose that we terminate this thread now. If you believe that .len() needs to be renamed, please go gather evidence that's compelling enough to warrant breaking tradition with practically every programming language out there (e.g. that strings have a defined "length" that can be queried using that term). Until then, this thread is serving no purpose. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From kevin at sb.org Fri May 30 19:02:48 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 30 May 2014 19:02:48 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: <20140530163137.GF17550@shavo.dd-wrt> References: <20140530163137.GF17550@shavo.dd-wrt> Message-ID: <7FB20D3B-4B69-417E-A411-D48B267A7E97@sb.org> I suspect a more generally interesting solution would be a Counted iterator adaptor that keeps track of how many non-None values it's returned from next(). You could use this to validate that your Take iterator returned the expected number of values. pub struct Counted { iter: T, /// Incremented by 1 every time `next()` returns a non-`None` value pub count: uint } impl> Iterator for Counted { fn next(&mut self) -> Option { match self.iter.next() { x at Some(_) => { self.count += 1; x } None => None } } fn size_hint(&self) -> (uint, Option) { self.iter.size_hint() } } // plus various associated traits like DoubleEndedIterator -Kevin On May 30, 2014, at 9:31 AM, Andrew Poelstra wrote: > Hi guys, > > > Take is an iterator adaptor which cuts off the contained iterator after > some number of elements, always returning None. > > I find that I need to detect whether I'm getting None from a Take > iterator because I've read all of the elements I expected or because the > underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > some data from the network and want to detect an early EOM.) > > > This seems like it might be only me, so I'm posing this to the list: if > there was a function Take::is_done(&self) -> bool, which returned whether > or not the Take had returned as many elements as it could, would that be > generally useful? > > I'm happy to submit a PR but want to check that this is appropriate for > the standard library. > > > > Thanks > > Andrew > > > > -- > Andrew Poelstra > Mathematics Department, University of Texas at Austin > Email: apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew > > "If they had taught a class on how to be the kind of citizen Dick Cheney > worries about, I would have finished high school." --Edward Snowden > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From raphael.catolino at gmail.com Sat May 31 00:16:05 2014 From: raphael.catolino at gmail.com (raphael catolino) Date: Sat, 31 May 2014 09:16:05 +0200 Subject: [rust-dev] Detection of early end for Take In-Reply-To: <7FB20D3B-4B69-417E-A411-D48B267A7E97@sb.org> References: <20140530163137.GF17550@shavo.dd-wrt> <7FB20D3B-4B69-417E-A411-D48B267A7E97@sb.org> Message-ID: In this case I think it would be simpler to just zip the iterator with range(0, n) than implement a whole Counted iterator. On May 31, 2014 4:02 AM, "Kevin Ballard" wrote: > I suspect a more generally interesting solution would be a Counted > iterator adaptor that keeps track of how many non-None values it's returned > from next(). You could use this to validate that your Take iterator > returned the expected number of values. > > pub struct Counted { > iter: T, > /// Incremented by 1 every time `next()` returns a non-`None` value > pub count: uint > } > > impl> Iterator for Counted { > fn next(&mut self) -> Option { > match self.iter.next() { > x at Some(_) => { > self.count += 1; > x > } > None => None > } > } > > fn size_hint(&self) -> (uint, Option) { > self.iter.size_hint() > } > } > > // plus various associated traits like DoubleEndedIterator > > -Kevin > > On May 30, 2014, at 9:31 AM, Andrew Poelstra > wrote: > > > Hi guys, > > > > > > Take is an iterator adaptor which cuts off the contained iterator after > > some number of elements, always returning None. > > > > I find that I need to detect whether I'm getting None from a Take > > iterator because I've read all of the elements I expected or because the > > underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > > some data from the network and want to detect an early EOM.) > > > > > > This seems like it might be only me, so I'm posing this to the list: if > > there was a function Take::is_done(&self) -> bool, which returned whether > > or not the Take had returned as many elements as it could, would that be > > generally useful? > > > > I'm happy to submit a PR but want to check that this is appropriate for > > the standard library. > > > > > > > > Thanks > > > > Andrew > > > > > > > > -- > > Andrew Poelstra > > Mathematics Department, University of Texas at Austin > > Email: apoelstra at wpsoftware.net > > Web: http://www.wpsoftware.net/andrew > > > > "If they had taught a class on how to be the kind of citizen Dick Cheney > > worries about, I would have finished high school." --Edward Snowden > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Sat May 31 00:28:27 2014 From: kevin at sb.org (Kevin Ballard) Date: Sat, 31 May 2014 00:28:27 -0700 Subject: [rust-dev] Detection of early end for Take In-Reply-To: References: <20140530163137.GF17550@shavo.dd-wrt> <7FB20D3B-4B69-417E-A411-D48B267A7E97@sb.org> Message-ID: <6A0F0F5B-DE85-4A2C-A6FD-0859B7A58C97@sb.org> That?s called .enumerate(). The reason I didn?t suggest that is you need to keep track of the last iteration you saw. If you?re checking after your for loop is done, then you?ve already lost that info. -Kevin On May 31, 2014, at 12:16 AM, raphael catolino wrote: > In this case I think it would be simpler to just zip the iterator with range(0, n) than implement a whole Counted iterator. > > On May 31, 2014 4:02 AM, "Kevin Ballard" wrote: > I suspect a more generally interesting solution would be a Counted iterator adaptor that keeps track of how many non-None values it's returned from next(). You could use this to validate that your Take iterator returned the expected number of values. > > pub struct Counted { > iter: T, > /// Incremented by 1 every time `next()` returns a non-`None` value > pub count: uint > } > > impl> Iterator for Counted { > fn next(&mut self) -> Option { > match self.iter.next() { > x at Some(_) => { > self.count += 1; > x > } > None => None > } > } > > fn size_hint(&self) -> (uint, Option) { > self.iter.size_hint() > } > } > > // plus various associated traits like DoubleEndedIterator > > -Kevin > > On May 30, 2014, at 9:31 AM, Andrew Poelstra wrote: > > > Hi guys, > > > > > > Take is an iterator adaptor which cuts off the contained iterator after > > some number of elements, always returning None. > > > > I find that I need to detect whether I'm getting None from a Take > > iterator because I've read all of the elements I expected or because the > > underlying iterator ran dry unexpectedly. (Specifically, I'm parsing > > some data from the network and want to detect an early EOM.) > > > > > > This seems like it might be only me, so I'm posing this to the list: if > > there was a function Take::is_done(&self) -> bool, which returned whether > > or not the Take had returned as many elements as it could, would that be > > generally useful? > > > > I'm happy to submit a PR but want to check that this is appropriate for > > the standard library. > > > > > > > > Thanks > > > > Andrew > > > > > > > > -- > > Andrew Poelstra > > Mathematics Department, University of Texas at Austin > > Email: apoelstra at wpsoftware.net > > Web: http://www.wpsoftware.net/andrew > > > > "If they had taught a class on how to be the kind of citizen Dick Cheney > > worries about, I would have finished high school." --Edward Snowden > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Sat May 31 00:42:57 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 31 May 2014 17:42:57 +1000 Subject: [rust-dev] Detection of early end for Take In-Reply-To: <7FB20D3B-4B69-417E-A411-D48B267A7E97@sb.org> References: <20140530163137.GF17550@shavo.dd-wrt> <7FB20D3B-4B69-417E-A411-D48B267A7E97@sb.org> Message-ID: <53898801.8080002@gmail.com> I believe this can be done with something like let mut counted = iter.scan(0, |count, x| { *count += 1; Some(x) }); for x in counted { ... } println!("I saw {} elements", counted.state) or even just let mut count = 0; { // scope to restrict the closure's borrow of `count`. let mut counted = iter.inspect(|_| count += 1); for x in counted { ... } } println!("I saw {} elements", count); Huon On 31/05/14 12:02, Kevin Ballard wrote: > I suspect a more generally interesting solution would be a Counted iterator adaptor that keeps track of how many non-None values it's returned from next(). You could use this to validate that your Take iterator returned the expected number of values. > > pub struct Counted { > iter: T, > /// Incremented by 1 every time `next()` returns a non-`None` value > pub count: uint > } > > impl> Iterator for Counted { > fn next(&mut self) -> Option { > match self.iter.next() { > x at Some(_) => { > self.count += 1; > x > } > None => None > } > } > > fn size_hint(&self) -> (uint, Option) { > self.iter.size_hint() > } > } > > // plus various associated traits like DoubleEndedIterator > > -Kevin > > On May 30, 2014, at 9:31 AM, Andrew Poelstra wrote: > >> Hi guys, >> >> >> Take is an iterator adaptor which cuts off the contained iterator after >> some number of elements, always returning None. >> >> I find that I need to detect whether I'm getting None from a Take >> iterator because I've read all of the elements I expected or because the >> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing >> some data from the network and want to detect an early EOM.) >> >> >> This seems like it might be only me, so I'm posing this to the list: if >> there was a function Take::is_done(&self) -> bool, which returned whether >> or not the Take had returned as many elements as it could, would that be >> generally useful? >> >> I'm happy to submit a PR but want to check that this is appropriate for >> the standard library. >> >> >> >> Thanks >> >> Andrew >> >> >> >> -- >> Andrew Poelstra >> Mathematics Department, University of Texas at Austin >> Email: apoelstra at wpsoftware.net >> Web: http://www.wpsoftware.net/andrew >> >> "If they had taught a class on how to be the kind of citizen Dick Cheney >> worries about, I would have finished high school." --Edward Snowden >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Sat May 31 06:21:17 2014 From: rusty.gates at icloud.com (Tommi) Date: Sat, 31 May 2014 16:21:17 +0300 Subject: [rust-dev] Enabling internal iteration with for-loops Message-ID: Disclaimer: I understand that Rust used to use internal iteration in for-loops, but that was before I became interested in this language, so my perspective on this matter may not match yours. I suppose internal iteration support in for-loops should be preferably implemented through the use of resumable functions. But since it may take a long time until we get resumable functions, I wonder if we should add the support for internal iteration in for-loops through the old fashion way: // in std::iter pub enum LoopControl { Continue, Break, Return(T) } pub trait InternalIterator { fn iter(&self, func: |&Elem| -> LoopControl) -> LoopControl; } // in std::prelude pub use std::iter::{LoopControl, Continue, Break, Return, InternalIterator}; // in user code struct Tree { data: int, left: Option>, right: Option> } impl InternalIterator for Tree { fn iter(&self, func: |&int| -> LoopControl) -> LoopControl { match func(&self.data) { Continue => { match self.left { Some(box ref left_branch) => { match left_branch.iter(|n| func(n)) { Continue => {} Break => { return Break; } Return(x) => { return Return(x); } } } None => {} } match self.right { Some(box ref right_branch) => { match right_branch.iter(|n| func(n)) { Continue => {} Break => { return Break; } Return(x) => { return Return(x); } } } None => {} } } Break => { return Break; } Return(x) => { return Return(x); } } return Continue; } } fn foo() -> char { let mut tree = Tree { data: 0, left: None, right: None }; tree.left = Some(box Tree { data: 1, left: None, right: None }); tree.right = Some(box Tree { data: 2, left: None, right: None }); tree.right.get_mut_ref().left = Some(box Tree { data: 3, left: None, right: None }); for e in tree { print!("{} ", e); if *e == 11 { continue; } if *e == 22 { break; } if *e == 3 { return 'D'; } } // Since `tree` doesn't implement `Iterator`, the compiler // checks if it implements `InternalIterator`, and uses that. // The for-loop above would be lowered by the compiler // to the following match expression: match tree.iter(|e: &int| -> LoopControl { print!("{} ", e); if *e == 11 { return Continue; } if *e == 22 { return Break; } if *e == 3 { return Return('D'); } return Continue; }) { Continue => {} Break => {} Return(x) => { return x; } } return '?'; } fn main() { print!("- {}", foo()); } // The program output: 0 1 2 3 - D -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.pedretti at gmail.com Sat May 31 09:27:50 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Sat, 31 May 2014 18:27:50 +0200 Subject: [rust-dev] cannot borrow `st` as mutable more than once at a time In-Reply-To: <900D896B-7D62-4E75-93B1-776B5619BF1E@sb.org> References: <900D896B-7D62-4E75-93B1-776B5619BF1E@sb.org> Message-ID: Yes, thanks, it's THE solution to my problem 2014-05-31 0:21 GMT+02:00 Kevin Ballard : > If I'm interpreting this right, you also need to add a second lifetime > parameter to your ResultSet object. This way the lifetime used for its > reference to the Statement can be different than the lifetime on the > Statement type itself (I assume Statement has a lifetime to refer to the > database). > > I whipped up an equivalent bit of code. The following reproduces your > error: > > struct Root { > s: String > } > > struct One<'a> { > root: &'a mut Root > } > > struct Two<'a> { > one: &'a mut One<'a> > } > > impl Root { > pub fn make_one<'a>(&'a mut self) -> One<'a> { > One { root: self } > } > } > > impl<'a> One<'a> { > pub fn make_two(&'a mut self) -> Two<'a> { > Two { one: self } > } > > pub fn foo(&mut self) { > println!("foo"); > } > } > > fn main() { > let mut r = Root { s: "root".to_string() }; > let mut one = r.make_one(); > match one.make_two() { > x => { > println!("root: {}", x.one.root.s); > } > } > > one.foo(); > } > > The equivalent change here that I'm proposing is updating Two to > > struct Two<'a, 'b> { > one: &'b mut One<'a> > } > > and the definition of make_two() to > > pub fn make_two<'b>(&'b mut self) -> Two<'a, 'b> { > Two { one: self } > } > > > -Kevin > > On May 30, 2014, at 3:12 PM, Kevin Ballard wrote: > > I'm assuming that Statement has its own lifetime parameter? And that's the > 'a you're using here? > > Try using a new lifetime. > > pub fn execute_query<'b>(&'b mut self) -> ResultSelf<'b>; > > -Kevin > > On May 30, 2014, at 1:54 AM, Christophe Pedretti < > christophe.pedretti at gmail.com> wrote: > > Hi All, > > sorry for my late replay, i am UTC+2 > > > Won't wrapping the first `for` loop into curly braces help? > no > > > is this a database library you're writing yourself? > yes > > > My best guess here is that you've accidentally used the wrong lifetime on > > your `execute_query()` method, tying the lifetime of the `self` > reference to > > a lifetime on the value itself > > yes, but removing the lifetime reference on the self, compiling my > library gives > > sql\connection.rs:57:2: 64:3 note: consider using an explicit lifetime > parameter as shown: fn execute_query(&'a mut self) -> ResultSet<'a> > sql\connection.rs:57 pub fn execute_query(&mut self) -> ResultSet<'a> { > sql\connection.rs:58 match self.pCon.dbType { > sql\connection.rs:59 SQLITE3 => { > sql\connection.rs:60 if self.exec { unsafe { > sqlite3_reset(self.pStmt) }; } else {self.exec=true; } > sql\connection.rs:61 ResultSet { pStmt : self, error : false } > sql\connection.rs:62 } > ... > sql\connection.rs:61:23: 61:27 error: cannot infer an appropriate > lifetime for automatic coercion due to conflicting requirements > sql\connection.rs:61 ResultSet { pStmt : self, error : false } > ^~~~ > > execute_query can be used only for the loop body, and if there is no > variable referencing it there is no reason for the execute-query to live > outside the loop (as is my example) > > or, with code like this : > > let query_result = st.execute_query() > for i in query_result { > ... > > and in this case, the query_result lives outside the loop > > the compiler can not distinguish these two usages ? > > Thanks > > 2014-05-30 9:17 GMT+02:00 Kevin Ballard : > >> On May 30, 2014, at 12:12 AM, Vladimir Matveev >> wrote: >> >> > 2014-05-30 5:37 GMT+04:00 Kevin Ballard : >> >> >> >> It shouldn't. >> >> >> >> The for-loop desugaring looks like >> >> >> >> match &mut st.execute_query() { >> >> __i => loop { >> >> match __i.next() { >> >> None => break, >> >> Some(mut __value) => { >> >> let i = __value; >> >> { >> >> // for loop body goes here >> >> } >> >> } >> >> } >> >> } >> >> } >> >> >> >> It's done with a match statement like this specifically to make the >> &mut binding of the iterator end after the for loop. >> > >> > Great, didn't know it. Last time I asked (on StackOverflow, I think; >> > that was some time ago though) there were no `match`. Then from that >> > code alone it does look like a bug to me. Note that it refers to >> > `st.set_string("%e%")` and `for` loop ten lines above, that is, the >> > first one. If mutable borrow of the iterator aren't escaping the loop, >> > then this error should not appear, right? >> >> The errors you printed are slightly malformed, and you only listed some >> of your code. Is this a database library you're writing yourself? My best >> guess here is that you've accidentally used the wrong lifetime on your >> `execute_query()` method, tying the lifetime of the `self` reference to a >> lifetime on the value itself. Something like this: >> >> impl<'a> Statement<'a> { >> pub fn execute_query(&'a mut self) { ... } >> } >> >> By using 'a on &'a mut self here, you've explicitly tied the reference to >> the lifetime of the value. This causes the mutable reference to live much >> longer than you expected it to, which means it's still alive when you try >> to subsequently borrow it on your call to .set_string(). >> >> -Kevin > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsingh_2011 at yahoo.com Sat May 31 09:59:16 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Sat, 31 May 2014 09:59:16 -0700 Subject: [rust-dev] Macro for creating hashmaps in libstd? Message-ID: Since there's a vec! in the standard library, should we also include some macro for HashMaps/Dictionaries? Here's an example of it's implementation and usage: #![feature(macro_rules)] extern crate collections; macro_rules! dict( ($($key:expr => $val:expr),*) => ({ let mut h = collections::HashMap::new(); $( h.insert($key, $val); )* h }) ) fn main() { let d = dict!["key1" => "value1", "key2" => "value2"]; for (k, v) in d.iter() { println!("{}: {}", k, v); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Sat May 31 10:36:59 2014 From: rusty.gates at icloud.com (Tommi) Date: Sat, 31 May 2014 20:36:59 +0300 Subject: [rust-dev] A better type system Message-ID: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> It certainly feels like a failure of the Rust type system that you cannot have multiple mutating references to the same variable when the variable is accessed only from a single thread. I know the reason for this is to prevent iterator invalidation, but this is too blunt of an instrument. Iterator invalidation (as it's known in C++) is a risk to memory safety only when some of the memory that is accessible through an iterator (or a reference) is deallocated. A better type system would make a distinction between those expressions that may deallocate and those that cannot. Then, when multiple mutating references pointed to the same variable, the compiler would disallow only the use of the potentially deallocating expressions through those references. If a variable may be accessed concurrently from multiple threads, only then would the current "no mutating references allowed to that variable" -rule be enforced. Sorry for the brevity, I'm writing this from a phone and I haven't thought of this issue very thoroughly. From pcwalton at mozilla.com Sat May 31 10:44:05 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 31 May 2014 10:44:05 -0700 Subject: [rust-dev] A better type system In-Reply-To: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> Message-ID: <538A14E5.7070009@mozilla.com> On 5/31/14 10:36 AM, Tommi wrote: > It certainly feels like a failure of the Rust type system that you > cannot have multiple mutating references to the same variable when > the variable is accessed only from a single thread. I know the reason > for this is to prevent iterator invalidation, but this is too blunt > of an instrument. No. Iterator invalidation is not the only reason. > Iterator invalidation (as it's known in C++) is a risk to memory > safety only when some of the memory that is accessible through an > iterator (or a reference) is deallocated. A better type system would > make a distinction between those expressions that may deallocate and > those that cannot. Then, when multiple mutating references pointed to > the same variable, the compiler would disallow only the use of the > potentially deallocating expressions through those references. Again, this is wrong. Iterator invalidation is the way I like to explain the rule, but it is by no means the only thing that can go wrong if you have two &mut references to the same location. If you have two &mut pointers to the same memory address, it is quite easy to write cast::transmute in safe code without any iterators or memory being deallocated at all. Patrick From acrichton at mozilla.com Sat May 31 10:54:05 2014 From: acrichton at mozilla.com (Alex Crichton) Date: Sat, 31 May 2014 10:54:05 -0700 Subject: [rust-dev] A better type system In-Reply-To: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> Message-ID: > Sorry for the brevity, I'm writing this from a phone and I haven't thought of this issue very thoroughly. You appear to dislike one of the most fundamental features of Rust, so I would encourage you to think through ideas such as this before hastily posting to the mailing list. The current iteration of Rust has had a great deal of thought and design poured into it, as well as having at least thousands of man hours of effort being put behind it. Casually stating, with little prior thought, that large chunks of this effort are flatly wrong is disrespectful to those who have put so much time and effort into the project. We always welcome and encourage thoughtful reconsiderations of the design decisions of Rust, but these must be performed in a constructive and well-thought-out manner. There have been many times in the past where the design decisions of Rust have been reversed or redone, but these were always accompanied with a large amount of research to fuel the changes. If you have concrete suggestions, we have an RFC process in place for proposing new changes to the language while gathering feedback at the same time. From christophe.pedretti at gmail.com Sat May 31 11:21:48 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Sat, 31 May 2014 20:21:48 +0200 Subject: [rust-dev] failed to find an implementation of trait core::cmp::TotalEq for ~str Message-ID: Hi all, i have updated my rust compiler, i have several compilations errors on my project 1. StrBuf does not exist any more, no problem, i now use String 2. ~"" is obsolete, no problem, i use box "" 3. The last isssue is " failed to find an implementation of trait core::cmp::TotalEq for ~str" util\properties.rs:12 self.props.find(key) ^~~~~~~~~~~~~~~~~~~~ My code is very simple and was compiling before ///Contains a list of properties. A property is a key-value pair. pub struct Properties { props : HashMap<~str, ~str> } impl Map<~str, ~str> for Properties { ///Get a property value giving its name. Return None if property does not exist. fn find<'a>(&'a self, key : &~str) -> Option<&'a ~str> { self.props.find(key) } ///Return true if a property value exists for the specified key fn contains_key(&self, key: &~str) -> bool { self.props.contains_key(key) } } what i am doing wrong ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sat May 31 12:13:03 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sat, 31 May 2014 21:13:03 +0200 Subject: [rust-dev] A better type system In-Reply-To: References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> Message-ID: Iterator invalidation is a sweet example, which strikes at the heart of C++ developer (those who never ran into it, please raise your hands). However it is just an example, anytime you have aliasing + mutability, you may have either memory issues or logical bugs. Another example of memory issue: foo(left: &Option>, right: &mut Option>) { let ptr: &str = *left.unwrap(); right = None; match ptr.len() { // Watch out! if left and right alias, then ptr is no a dangling reference! // ... } } The issue can actually occur in other ways: replace Box by enum Point { Integral(int, int), Floating(f64, f64) } and you could manage to write integral into floats or vice-versa, which is memory-corruption, not segmentation fault. The Rust type system allows, at the moment, to ensure that you never have both aliasing and mutability. Mostly at compile-time, and at run-time through a couple unsafe hatches (Cell, RefCell, Mutex, ...). I admit it is jarring, and constraining. However the guarantee you get in exchange (memory-safe & thread-safe) is extremely important. > I'm writing this from a phone and I haven't thought of this issue very thoroughly. Well, think a bit more. If you manage to produce a more refined type-system, I'd love to hear about it. In the mean time though, I advise caution in criticizing the existing: it has the incredible advantage of working. On Sat, May 31, 2014 at 7:54 PM, Alex Crichton wrote: > > Sorry for the brevity, I'm writing this from a phone and I haven't > thought of this issue very thoroughly. > > You appear to dislike one of the most fundamental features of Rust, so > I would encourage you to think through ideas such as this before > hastily posting to the mailing list. > > The current iteration of Rust has had a great deal of thought and > design poured into it, as well as having at least thousands of man > hours of effort being put behind it. Casually stating, with little > prior thought, that large chunks of this effort are flatly wrong is > disrespectful to those who have put so much time and effort into the > project. > > We always welcome and encourage thoughtful reconsiderations of the > design decisions of Rust, but these must be performed in a > constructive and well-thought-out manner. There have been many times > in the past where the design decisions of Rust have been reversed or > redone, but these were always accompanied with a large amount of > research to fuel the changes. > > If you have concrete suggestions, we have an RFC process in place for > proposing new changes to the language while gathering feedback at the > same time. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From someone at mearie.org Sat May 31 12:29:11 2014 From: someone at mearie.org (Kang Seonghoon) Date: Sun, 1 Jun 2014 04:29:11 +0900 Subject: [rust-dev] failed to find an implementation of trait core::cmp::TotalEq for ~str In-Reply-To: References: Message-ID: `String` is a complete substitute of the old `~str` (or `Box` or whatever) in such that `~str` should not be used now. Replace all occurrence of `~str` with `String`, and `~"foo"` with `"foo".to_string()`. Almost every function in the standard library, including those in `std::str`, now returns `String` in place of `~str`, so the remaining conversion is trivial. 2014-06-01 3:21 GMT+09:00 Christophe Pedretti : > Hi all, > > i have updated my rust compiler, i have several compilations errors on my > project > > StrBuf does not exist any more, no problem, i now use String > ~"" is obsolete, no problem, i use box "" > The last isssue is " failed to find an implementation of trait > core::cmp::TotalEq for ~str" > util\properties.rs:12 self.props.find(key) > ^~~~~~~~~~~~~~~~~~~~ > > My code is very simple and was compiling before > > ///Contains a list of properties. A property is a key-value pair. > pub struct Properties { > props : HashMap<~str, ~str> > } > > impl Map<~str, ~str> for Properties { > ///Get a property value giving its name. Return None if property does not > exist. > fn find<'a>(&'a self, key : &~str) -> Option<&'a ~str> { > self.props.find(key) > } > ///Return true if a property value exists for the specified key > fn contains_key(&self, key: &~str) -> bool { > self.props.contains_key(key) > } > } > > what i am doing wrong ? > > Thanks > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. -- From dpx.infinity at gmail.com Sat May 31 13:17:46 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Sun, 1 Jun 2014 00:17:46 +0400 Subject: [rust-dev] failed to find an implementation of trait core::cmp::TotalEq for ~str In-Reply-To: References: Message-ID: Hi, Christophe, You shouldn't be using `~str` at all, you should use `String`. Also, `box ""` is not a replacement for `~""`, they have different types. The proper replacement is `String::new()` or `"".to_string()". Your code in modern Rust will look like this: /// Contains a list of properties. A property is a key-value pair. pub struct Properties { props: HashMap } impl Map for Properties { /// Get a property value giving its name. Return None if property does not exist. fn find<'a>(&'a self, key: &String) -> Option<&'a String> { self.props.find(key) } /// Return true if a property value exists for the specified key fn contains_key(&self, key: &String) -> bool { self.props.contains_key(key) } } 2014-05-31 22:21 GMT+04:00 Christophe Pedretti : > Hi all, > > i have updated my rust compiler, i have several compilations errors on my > project > > StrBuf does not exist any more, no problem, i now use String > ~"" is obsolete, no problem, i use box "" > The last isssue is " failed to find an implementation of trait > core::cmp::TotalEq for ~str" > util\properties.rs:12 self.props.find(key) > ^~~~~~~~~~~~~~~~~~~~ > > My code is very simple and was compiling before > > ///Contains a list of properties. A property is a key-value pair. > pub struct Properties { > props : HashMap<~str, ~str> > } > > impl Map<~str, ~str> for Properties { > ///Get a property value giving its name. Return None if property does not > exist. > fn find<'a>(&'a self, key : &~str) -> Option<&'a ~str> { > self.props.find(key) > } > ///Return true if a property value exists for the specified key > fn contains_key(&self, key: &~str) -> bool { > self.props.contains_key(key) > } > } > > what i am doing wrong ? > > Thanks > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From rusty.gates at icloud.com Sat May 31 14:22:38 2014 From: rusty.gates at icloud.com (Tommi) Date: Sun, 01 Jun 2014 00:22:38 +0300 Subject: [rust-dev] A better type system In-Reply-To: References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> Message-ID: <3A8AEE73-ACAF-477C-8877-C4306F1C8AD3@icloud.com> On 2014-05-31, at 22:13, Matthieu Monrocq wrote: > Another example of memory issue: > > foo(left: &Option>, right: &mut Option>) { > let ptr: &str = *left.unwrap(); > > right = None; > > match ptr.len() { // Watch out! if left and right alias, then ptr is no a dangling reference! > // ... > } > } But the reason why there could be a dangling reference there is the (assumed) deallocation of Box caused by the assignment to `right`. The type system should prevent assignment to a variable of type Option> if multiple mutable references could point to that variable. > The issue can actually occur in other ways: replace Box by enum Point { Integral(int, int), Floating(f64, f64) } and you could manage to write integral into floats or vice-versa, which is memory-corruption, not segmentation fault. I don't think that counts as memory-corruption (according to http://en.wikipedia.org/wiki/Memory_corruption). That may be a bug in program logic, but then again, there might be a valid use for having two different pointers interpret the same of partly overlapping memory region as different types and mutating and using their memory according to their interpretation of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Sat May 31 14:44:11 2014 From: rusty.gates at icloud.com (Tommi) Date: Sun, 01 Jun 2014 00:44:11 +0300 Subject: [rust-dev] A better type system In-Reply-To: <538A14E5.7070009@mozilla.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> Message-ID: <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> On 2014-05-31, at 20:44, Patrick Walton wrote: > On 5/31/14 10:36 AM, Tommi wrote: >> Iterator invalidation (as it's known in C++) is a risk to memory >> safety only when some of the memory that is accessible through an >> iterator (or a reference) is deallocated. A better type system would >> make a distinction between those expressions that may deallocate and >> those that cannot. Then, when multiple mutating references pointed to >> the same variable, the compiler would disallow only the use of the >> potentially deallocating expressions through those references. > > Again, this is wrong. Iterator invalidation is the way I like to explain the rule, but it is by no means the only thing that can go wrong if you have two &mut references to the same location. If you have two &mut pointers to the same memory address, it is quite easy to write cast::transmute in safe code without any iterators or memory being deallocated at all. I don't understand that last sentence. How could you use `transmute` in safe code given that it's an `unsafe` function? By the way, I said previously that: >> Then, when multiple mutating references pointed to >> the same variable, the compiler would disallow only the use of the >> potentially deallocating expressions through those references. ...but I'd like to rephrase that: The compiler should make sure that you can't deallocate memory that could potentially be accessible through multiple different variables (be they references or owning variables). But all other kind of mutation through different variables in a single-threaded code should be memory-safe at least in some definition of that word. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.pedretti at gmail.com Sat May 31 14:46:31 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Sat, 31 May 2014 23:46:31 +0200 Subject: [rust-dev] failed to find an implementation of trait core::cmp::TotalEq for ~str In-Reply-To: References: Message-ID: chars_rev iterator does not exist anymore (std::str::StrSlice) ? 2014-05-31 22:17 GMT+02:00 Vladimir Matveev : > Hi, Christophe, > > You shouldn't be using `~str` at all, you should use `String`. Also, > `box ""` is not a replacement for `~""`, they have different types. > The proper replacement is `String::new()` or `"".to_string()". > > Your code in modern Rust will look like this: > > /// Contains a list of properties. A property is a key-value pair. > pub struct Properties { > props: HashMap > } > > impl Map for Properties { > /// Get a property value giving its name. Return None if property > does not exist. > fn find<'a>(&'a self, key: &String) -> Option<&'a String> { > self.props.find(key) > } > > /// Return true if a property value exists for the specified key > fn contains_key(&self, key: &String) -> bool { > self.props.contains_key(key) > } > } > > > > 2014-05-31 22:21 GMT+04:00 Christophe Pedretti < > christophe.pedretti at gmail.com>: > > Hi all, > > > > i have updated my rust compiler, i have several compilations errors on my > > project > > > > StrBuf does not exist any more, no problem, i now use String > > ~"" is obsolete, no problem, i use box "" > > The last isssue is " failed to find an implementation of trait > > core::cmp::TotalEq for ~str" > > util\properties.rs:12 self.props.find(key) > > ^~~~~~~~~~~~~~~~~~~~ > > > > My code is very simple and was compiling before > > > > ///Contains a list of properties. A property is a key-value pair. > > pub struct Properties { > > props : HashMap<~str, ~str> > > } > > > > impl Map<~str, ~str> for Properties { > > ///Get a property value giving its name. Return None if property does not > > exist. > > fn find<'a>(&'a self, key : &~str) -> Option<&'a ~str> { > > self.props.find(key) > > } > > ///Return true if a property value exists for the specified key > > fn contains_key(&self, key: &~str) -> bool { > > self.props.contains_key(key) > > } > > } > > > > what i am doing wrong ? > > > > Thanks > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zwarich at mozilla.com Sat May 31 14:48:06 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Sat, 31 May 2014 14:48:06 -0700 Subject: [rust-dev] A better type system In-Reply-To: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> Message-ID: <507A6E9A-DDD5-4FFF-BBC5-54B51F921113@mozilla.com> When writing an email stating ?your programming language isn?t expressive enough?, it?s a good idea to include an example program that you would like to write that is rejected by the current type system. Then people replying to your email can give you some suggestions on how to best achieve your goals in Rust. The usual solution to the problem of safely mutating data is to use Cell, but we can?t be sure unless you give an example. You are correct that mutation is only a risk to memory safety after deallocation occurs, but in a language with actual sum types this can occur when mutating a variable of a sum type to hold a different variant, since the storage is reused for a new variant after mutation, invalidating any references into the previous data. However, this doesn?t require preventing the mutation of things like integer fields of a struct. The current guarantee (or the projected guarantee, since this isn?t actually implemented in all cases) for &mut references is that all accesses (both reads and writes) to &mut data occur through access paths derived from the &mut reference. This is helpful because the same guarantee holds regardless of type, and the guarantee is strong enough to provide race-free accesses to shared data. Rust used to have an &const pointer type, which was similar to C++?s const in that it guaranteed that modifications didn?t occur through access paths derived from the &const pointer, but still allowed them to occur through other access paths. From what I understand, it was removed to simplify the type system, since most of its uses could be replaced with Cell. In full generality, you could imagine Rust pointers allowing the specification of the following information: 1) Specific derived access paths that are unique, similar to the guarantee provided by &mut or the internal &uniq today. 2) Specific derived access paths that may be read through this pointer. 3) Specific derived access paths that may be mutated through this pointer. 4) Specific derived access paths that may observe mutations through access paths that do not involve this pointer. Obviously, not all combinations would be sound or even coherent. This system would still permit reborrowing and would allow some interesting situations that are forbidden today. For example, you could have a vector v of struct A { a: int, b: Box } and have an unrestricted number of mutable/const borrows of the path v[].a but a unique mutable borrow of v[].b and all derived paths. You could also pass partially initialized structs to other functions, knowing that they don?t read any of the uninitialized fields. Would this be a better type system? Well, it would definitely be more expressive than the current system, and it wouldn?t even be extremely difficult to modify the borrow checker to implement it. However, it would be a dramatic increase in user-facing complexity, since shorthand would only take you so far. These complex pointer types would have to appear in every function signature. They would also leak implementation details of functions and types even moreso than Rust already does. Cameron On May 31, 2014, at 10:36 AM, Tommi wrote: > It certainly feels like a failure of the Rust type system that you cannot have multiple mutating references to the same variable when the variable is accessed only from a single thread. I know the reason for this is to prevent iterator invalidation, but this is too blunt of an instrument. > > Iterator invalidation (as it's known in C++) is a risk to memory safety only when some of the memory that is accessible through an iterator (or a reference) is deallocated. A better type system would make a distinction between those expressions that may deallocate and those that cannot. Then, when multiple mutating references pointed to the same variable, the compiler would disallow only the use of the potentially deallocating expressions through those references. > > If a variable may be accessed concurrently from multiple threads, only then would the current "no mutating references allowed to that variable" -rule be enforced. > > Sorry for the brevity, I'm writing this from a phone and I haven't thought of this issue very thoroughly. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From erick.tryzelaar at gmail.com Sat May 31 14:50:54 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sat, 31 May 2014 14:50:54 -0700 Subject: [rust-dev] failed to find an implementation of trait core::cmp::TotalEq for ~str In-Reply-To: References: Message-ID: Try this out: ``` fn main() { let s = "abc".to_string(); for c in s.as_slice().chars().rev() { println!("{}", c); } } ``` produces: ``` c b a ``` On Sat, May 31, 2014 at 2:46 PM, Christophe Pedretti < christophe.pedretti at gmail.com> wrote: > chars_rev iterator does not exist anymore (std::str::StrSlice) ? > > > 2014-05-31 22:17 GMT+02:00 Vladimir Matveev : > > Hi, Christophe, >> >> You shouldn't be using `~str` at all, you should use `String`. Also, >> `box ""` is not a replacement for `~""`, they have different types. >> The proper replacement is `String::new()` or `"".to_string()". >> >> Your code in modern Rust will look like this: >> >> /// Contains a list of properties. A property is a key-value pair. >> pub struct Properties { >> props: HashMap >> } >> >> impl Map for Properties { >> /// Get a property value giving its name. Return None if property >> does not exist. >> fn find<'a>(&'a self, key: &String) -> Option<&'a String> { >> self.props.find(key) >> } >> >> /// Return true if a property value exists for the specified key >> fn contains_key(&self, key: &String) -> bool { >> self.props.contains_key(key) >> } >> } >> >> >> >> 2014-05-31 22:21 GMT+04:00 Christophe Pedretti < >> christophe.pedretti at gmail.com>: >> > Hi all, >> > >> > i have updated my rust compiler, i have several compilations errors on >> my >> > project >> > >> > StrBuf does not exist any more, no problem, i now use String >> > ~"" is obsolete, no problem, i use box "" >> > The last isssue is " failed to find an implementation of trait >> > core::cmp::TotalEq for ~str" >> > util\properties.rs:12 self.props.find(key) >> > ^~~~~~~~~~~~~~~~~~~~ >> > >> > My code is very simple and was compiling before >> > >> > ///Contains a list of properties. A property is a key-value pair. >> > pub struct Properties { >> > props : HashMap<~str, ~str> >> > } >> > >> > impl Map<~str, ~str> for Properties { >> > ///Get a property value giving its name. Return None if property does >> not >> > exist. >> > fn find<'a>(&'a self, key : &~str) -> Option<&'a ~str> { >> > self.props.find(key) >> > } >> > ///Return true if a property value exists for the specified key >> > fn contains_key(&self, key: &~str) -> bool { >> > self.props.contains_key(key) >> > } >> > } >> > >> > what i am doing wrong ? >> > >> > Thanks >> > >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sat May 31 15:02:54 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 31 May 2014 15:02:54 -0700 Subject: [rust-dev] A better type system In-Reply-To: <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> Message-ID: <538A518E.90706@mozilla.com> On 5/31/14 2:44 PM, Tommi wrote: > I don't understand that last sentence. How could you use `transmute` in > safe code given that it's an `unsafe` function? I mean you could *write* transmute in safe code. Look: fn my_transmute(value: T, other: U) -> U { let mut x = Left(other); let y = match x { Left(ref mut y) => y, Right(_) => fail!() }; *x = Right(value); (*y).clone() } Just by using two mutable references to the same location, I have created a function that can cast any clonable type to any other type, given at least one instance of the two. I didn't use any memory allocation at all. This was discussed quite a bit on the mailing list years ago. > The compiler should make sure that you can't deallocate memory that > could potentially be accessible through multiple different variables (be > they references or owning variables). But all other kind of mutation > through different variables in a single-threaded code should be > memory-safe at least in some definition of that word. No, it is not memory safe. See above. Patrick From rusty.gates at icloud.com Sat May 31 16:42:10 2014 From: rusty.gates at icloud.com (Tommi) Date: Sun, 01 Jun 2014 02:42:10 +0300 Subject: [rust-dev] A better type system In-Reply-To: <538A518E.90706@mozilla.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> <538A518E.90706@mozilla.com> Message-ID: <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> On 2014-06-01, at 1:02, Patrick Walton wrote: > fn my_transmute(value: T, other: U) -> U { > let mut x = Left(other); > let y = match x { > Left(ref mut y) => y, > Right(_) => fail!() > }; > *x = Right(value); > (*y).clone() > } If `U` implements `Copy`, then I don't see a (memory-safety) issue here. And if `U` doesn't implement `Copy`, then it's same situation as it was in the earlier example given by Matthieu, where there was an assignment to an `Option>` variable while a different reference pointing to that variable existed. The compiler shouldn't allow that assignment just as in your example the compiler shouldn't allow the assignment `x = Right(value);` (after a separate reference pointing to the contents of `x` has been created) if `U` is not a `Copy` type. But, like I said in an earlier post, even though I don't see this (transmuting a `Copy` type in safe code) as a memory-safety issue, it is a code correctness issue. So it's a compromise between preventing logic bugs (in safe code) and the convenience of more liberal mutation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Sat May 31 16:45:24 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sun, 01 Jun 2014 09:45:24 +1000 Subject: [rust-dev] A better type system In-Reply-To: <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> <538A518E.90706@mozilla.com> <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> Message-ID: <538A6994.2070700@gmail.com> References (&T) are Copy. Huon On 01/06/14 09:42, Tommi wrote: > On 2014-06-01, at 1:02, Patrick Walton > wrote: > >> fn my_transmute(value: T, other: U) -> U { >> let mut x = Left(other); >> let y = match x { >> Left(ref mut y) => y, >> Right(_) => fail!() >> }; >> *x = Right(value); >> (*y).clone() >> } > > If `U` implements `Copy`, then I don't see a (memory-safety) issue > here. And if `U` doesn't implement `Copy`, then it's same situation as > it was in the earlier example given by Matthieu, where there was an > assignment to an `Option>` variable while a different > reference pointing to that variable existed. The compiler shouldn't > allow that assignment just as in your example the compiler shouldn't > allow the assignment `x = Right(value);` (after a separate reference > pointing to the contents of `x` has been created) if `U` is not a > `Copy` type. > > But, like I said in an earlier post, even though I don't see this > (transmuting a `Copy` type in safe code) as a memory-safety issue, it > is a code correctness issue. So it's a compromise between preventing > logic bugs (in safe code) and the convenience of more liberal mutation. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Sat May 31 16:57:20 2014 From: rusty.gates at icloud.com (Tommi) Date: Sun, 01 Jun 2014 02:57:20 +0300 Subject: [rust-dev] A better type system In-Reply-To: <538A6994.2070700@gmail.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> <538A518E.90706@mozilla.com> <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> <538A6994.2070700@gmail.com> Message-ID: On 2014-06-01, at 2:45, Huon Wilson wrote: > References (&T) are Copy. That didn't occur to me. Okay, I can see how that would be a problem. From pwalton at mozilla.com Sat May 31 17:01:12 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 31 May 2014 17:01:12 -0700 Subject: [rust-dev] A better type system In-Reply-To: <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> <538A518E.90706@mozilla.com> <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> Message-ID: <3acefe6c-bfa2-491e-bf36-40d921efa332@email.android.com> I assume what you're trying to say is that we should allow multiple mutable references to pointer-free data. (Note that, as Huon pointed out, this is not the same thing as the Copy bound.) That is potentially plausible, but (a) it adds more complexity to the borrow checker; (b) it's a fairly narrow use case, since it'd only be safe for pointer-free data; (c) it admits casts like 3u8 -> bool, casts to out-of-range enum values, denormal floats, and the like, all of which would have various annoying consequences; (d) it complicates or defeats optimizations based on pointer aliasing of &mut; (e) it allows uninitialized data to be read, introducing undefined behavior into the language. I don't think it's worth it. Patrick On May 31, 2014 4:42:10 PM PDT, Tommi wrote: >On 2014-06-01, at 1:02, Patrick Walton wrote: > >> fn my_transmute(value: T, other: U) -> U { >> let mut x = Left(other); >> let y = match x { >> Left(ref mut y) => y, >> Right(_) => fail!() >> }; >> *x = Right(value); >> (*y).clone() >> } > >If `U` implements `Copy`, then I don't see a (memory-safety) issue >here. And if `U` doesn't implement `Copy`, then it's same situation as >it was in the earlier example given by Matthieu, where there was an >assignment to an `Option>` variable while a different >reference pointing to that variable existed. The compiler shouldn't >allow that assignment just as in your example the compiler shouldn't >allow the assignment `x = Right(value);` (after a separate reference >pointing to the contents of `x` has been created) if `U` is not a >`Copy` type. > >But, like I said in an earlier post, even though I don't see this >(transmuting a `Copy` type in safe code) as a memory-safety issue, it >is a code correctness issue. So it's a compromise between preventing >logic bugs (in safe code) and the convenience of more liberal mutation. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zwarich at mozilla.com Sat May 31 17:26:39 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Sat, 31 May 2014 17:26:39 -0700 Subject: [rust-dev] A better type system In-Reply-To: <3acefe6c-bfa2-491e-bf36-40d921efa332@email.android.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> <538A518E.90706@mozilla.com> <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> <3acefe6c-bfa2-491e-bf36-40d921efa332@email.android.com> Message-ID: <770D9752-D9A0-4A02-B2F6-AFA0A853DDF7@mozilla.com> FWIW, I think you could eliminate (c) by prohibiting mutation of sum types. What case are you thinking of for (e)? For (d), this would probably have to be distinguished from the current &mut somehow, to allow for truly unique access paths to sum types or shared data, so you could preserve any aliasing optimizations for the current &mut. Of course, more functions might take the less restrictive version, eliminating the optimization that way. Not that I think that this is a great idea; I?m just wondering whether there are any caveats that have escaped my mental model of the borrow checker. Cameron On May 31, 2014, at 5:01 PM, Patrick Walton wrote: > I assume what you're trying to say is that we should allow multiple mutable references to pointer-free data. (Note that, as Huon pointed out, this is not the same thing as the Copy bound.) > > That is potentially plausible, but (a) it adds more complexity to the borrow checker; (b) it's a fairly narrow use case, since it'd only be safe for pointer-free data; (c) it admits casts like 3u8 -> bool, casts to out-of-range enum values, denormal floats, and the like, all of which would have various annoying consequences; (d) it complicates or defeats optimizations based on pointer aliasing of &mut; (e) it allows uninitialized data to be read, introducing undefined behavior into the language. I don't think it's worth it. > > Patrick > > On May 31, 2014 4:42:10 PM PDT, Tommi wrote: > On 2014-06-01, at 1:02, Patrick Walton wrote: > >> fn my_transmute(value: T, other: U) -> U { >> let mut x = Left(other); >> let y = match x { >> Left(ref mut y) => y, >> Right(_) => fail!() >> }; >> *x = Right(value); >> (*y).clone() >> } > > If `U` implements `Copy`, then I don't see a (memory-safety) issue here. And if `U` doesn't implement `Copy`, then it's same situation as it was in the earlier example given by Matthieu, where there was an assignment to an `Option>` variable while a different reference pointing to that variable existed. The compiler shouldn't allow that assignment just as in your example the compiler shouldn't allow the assignment `x = Right(value);` (after a separate reference pointing to the contents of `x` has been created) if `U` is not a `Copy` type. > > But, like I said in an earlier post, even though I don't see this (transmuting a `Copy` type in safe code) as a memory-safety issue, it is a code correctness issue. So it's a compromise between preventing logic bugs (in safe code) and the convenience of more liberal mutation. > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sat May 31 17:32:21 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 31 May 2014 17:32:21 -0700 Subject: [rust-dev] A better type system In-Reply-To: <770D9752-D9A0-4A02-B2F6-AFA0A853DDF7@mozilla.com> References: <7BB08DE7-7315-4F38-85AF-78BC633141CE@icloud.com> <538A14E5.7070009@mozilla.com> <5CFCDE64-BDEB-483E-BA92-424CA15F4529@icloud.com> <538A518E.90706@mozilla.com> <7D76B3E2-06C9-4382-8E68-F4F2E9003E26@icloud.com> <3acefe6c-bfa2-491e-bf36-40d921efa332@email.android.com> <770D9752-D9A0-4A02-B2F6-AFA0A853DDF7@mozilla.com> Message-ID: <88b869f3-52b7-489c-a197-3a2cff60deb8@email.android.com> Yes, you could eliminate (c) by prohibiting taking references to the inside of sum types (really, any existential type). This is what Cyclone did. For (e) I'm thinking of sum types in which the two variants have different sizes (although maybe that doesn't work). We'd basically have to bring back the old &mut as a separate type of pointer to make it work. Note that Niko was considering a system like this in older blog posts pre-INHTWAMA. (Search for "restrict pointers" on his blog.) Patrick On May 31, 2014 5:26:39 PM PDT, Cameron Zwarich wrote: >FWIW, I think you could eliminate (c) by prohibiting mutation of sum >types. What case are you thinking of for (e)? > >For (d), this would probably have to be distinguished from the current >&mut somehow, to allow for truly unique access paths to sum types or >shared data, so you could preserve any aliasing optimizations for the >current &mut. Of course, more functions might take the less restrictive >version, eliminating the optimization that way. > >Not that I think that this is a great idea; I?m just wondering whether >there are any caveats that have escaped my mental model of the borrow >checker. > >Cameron > >On May 31, 2014, at 5:01 PM, Patrick Walton >wrote: > >> I assume what you're trying to say is that we should allow multiple >mutable references to pointer-free data. (Note that, as Huon pointed >out, this is not the same thing as the Copy bound.) >> >> That is potentially plausible, but (a) it adds more complexity to the >borrow checker; (b) it's a fairly narrow use case, since it'd only be >safe for pointer-free data; (c) it admits casts like 3u8 -> bool, casts >to out-of-range enum values, denormal floats, and the like, all of >which would have various annoying consequences; (d) it complicates or >defeats optimizations based on pointer aliasing of &mut; (e) it allows >uninitialized data to be read, introducing undefined behavior into the >language. I don't think it's worth it. >> >> Patrick >> >> On May 31, 2014 4:42:10 PM PDT, Tommi wrote: >> On 2014-06-01, at 1:02, Patrick Walton wrote: >> >>> fn my_transmute(value: T, other: U) -> U { >>> let mut x = Left(other); >>> let y = match x { >>> Left(ref mut y) => y, >>> Right(_) => fail!() >>> }; >>> *x = Right(value); >>> (*y).clone() >>> } >> >> If `U` implements `Copy`, then I don't see a (memory-safety) issue >here. And if `U` doesn't implement `Copy`, then it's same situation as >it was in the earlier example given by Matthieu, where there was an >assignment to an `Option>` variable while a different >reference pointing to that variable existed. The compiler shouldn't >allow that assignment just as in your example the compiler shouldn't >allow the assignment `x = Right(value);` (after a separate reference >pointing to the contents of `x` has been created) if `U` is not a >`Copy` type. >> >> But, like I said in an earlier post, even though I don't see this >(transmuting a `Copy` type in safe code) as a memory-safety issue, it >is a code correctness issue. So it's a compromise between preventing >logic bugs (in safe code) and the convenience of more liberal mutation. >> >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mozilla at mcpherrin.ca Sat May 31 18:35:11 2014 From: mozilla at mcpherrin.ca (Matthew McPherrin) Date: Sat, 31 May 2014 18:35:11 -0700 Subject: [rust-dev] Macro for creating hashmaps in libstd? In-Reply-To: References: Message-ID: We ought to have something like this for sure. I wonder if we can do something a little more generic though, perhaps using FromIterator. Not quite as pretty, but let x: HashMap = from_iter![(key, val), (key2, val2), (key2, val2)] A dict! macro could do the same thing but allow for the more pleasing expr => expr, On Sat, May 31, 2014 at 9:59 AM, Gulshan Singh wrote: > Since there's a vec! in the standard library, should we also include some > macro for HashMaps/Dictionaries? Here's an example of it's implementation > and usage: > > #![feature(macro_rules)] > > extern crate collections; > > macro_rules! dict( > ($($key:expr => $val:expr),*) => ({ > let mut h = collections::HashMap::new(); > $( > h.insert($key, $val); > )* > h > }) > ) > > fn main() { > let d = dict!["key1" => "value1", "key2" => "value2"]; > for (k, v) in d.iter() { > println!("{}: {}", k, v); > } > } > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From gsingh_2011 at yahoo.com Sat May 31 21:41:03 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Sat, 31 May 2014 21:41:03 -0700 Subject: [rust-dev] Macro for creating hashmaps in libstd? In-Reply-To: References: Message-ID: I'm still new to Rust (and even newer to writing macros), but I don't see how `from_iter!` would be able to figure out what type to return. I think a `dict!` macro would be worth it for the `=>` syntax, even if `from_iter!` gets implemented. I'm not sure if it could somehow use `from_iter!` though. On Sat, May 31, 2014 at 6:35 PM, Matthew McPherrin wrote: > We ought to have something like this for sure. > > I wonder if we can do something a little more generic though, perhaps > using FromIterator. Not quite as pretty, but > > let x: HashMap = from_iter![(key, val), (key2, val2), (key2, val2)] > > A dict! macro could do the same thing but allow for the more pleasing > expr => expr, > > On Sat, May 31, 2014 at 9:59 AM, Gulshan Singh > wrote: > > Since there's a vec! in the standard library, should we also include some > > macro for HashMaps/Dictionaries? Here's an example of it's implementation > > and usage: > > > > #![feature(macro_rules)] > > > > extern crate collections; > > > > macro_rules! dict( > > ($($key:expr => $val:expr),*) => ({ > > let mut h = collections::HashMap::new(); > > $( > > h.insert($key, $val); > > )* > > h > > }) > > ) > > > > fn main() { > > let d = dict!["key1" => "value1", "key2" => "value2"]; > > for (k, v) in d.iter() { > > println!("{}: {}", k, v); > > } > > } > > > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: