Re: [rust-dev] RFC: Future of the Build System

[Martin DeMello]

This would probably be a useful thing to have even if the rust project
doesn't officially end up adopting it as the One True Solution.

martin


On Tue, Jan 14, 2014 at 3:09 PM, Gaetan  wrote:

> i read the ninja documentation, and this integrates well with cmake, and
> do the majority of the graph stuff required to compile file. i kind of like
> it. and i wonder why rust-pkg cannot be extended, for simple project to
> generate ninja files...
>
> -
> Gaetan
>
>
>
> 2014/1/15 Lee Braiden 
>
>> On 14/01/14 22:51, Gaetan wrote:
>>
>>> you cannot stick build environment with one system. apt is now on every
>>> system, you cannot use it under windows or mac.
>>>
>>
>> I think you're misunderstanding me.  I don't favor debian in any way.  I
>> would like debian people (and windows people, and mac people, and BSD
>> people, and cloud deployment people, etc.) to be able to use Rust packages
>> in whatever why they choose, though.
>>
>>
>>
>>  and apt source simply checkout the source zip from repository, this is
>>> not a proper build system.
>>>
>>
>> This is getting off topic, but no, apt-get source builds source code
>> that's already been patched with package information. It's exactly how
>> debian builds its packages for general use.
>>
>>
>>
>>  package management is one job and build is another one. you will use
>>> another package management on another system, while you expect to use the
>>> same build system on another system.
>>>
>>
>> That's true IF your package manager only supports third-party binaries.
>>  However, if your package manager includes some build process, as most
>> emphatically DO, then I believe that's incorrect.
>>
>> However, I understand that you're saying we shouldn't rely on particular
>> package managers.  That is NOT my intention -- just the opposite :)
>>
>>
>>
>>  in my experience, i ended up quite often with some bash script for unix
>>> like systems that generates some makefiles or trigs cmake/cpack, visual
>>> studio or eclipse projects for windows.
>>> the only portable build system i used was cmake, which exists under
>>> windows mac and unit, with ctest and cpack, even if there are quite
>>> limited. And there were a lot of "if windows..."
>>>
>>
>> Yes, this is what I'm saying :)
>>
>>
>>
>>  But, i tend to NOT recommend cmake if the final goal is to be integrated
>>> into systems like debian.
>>>
>>
>> The final goal would be to allow every distro, every operating system,
>> every continuous integration system, every shell script, every cloud image
>> builder, every mobile phone developer, and custom OS writer,  do work with
>> Rust packages in whatever way suits them best.
>>
>>
>>
>> --
>> Lee
>>
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Emscripten for Rust?

[Martin DeMello]

I think it would be more useful to extend rust-bindgen to support c++,
and work from there. dobkeratops has done some work on this already:
https://github.com/dobkeratops/rust-bindgen/tree/cpptemplate

martin

On Mon, Jan 6, 2014 at 9:21 AM, Greg  wrote:
> Hmm. I don't think that's quite what I'm looking for. I'm not interested in
> converting C++ to JS, but C++ to Rust.
>
> I think the skepticism expressed in other replies is unwarranted. Between
> the sort of static analysis that LLVM & Xcode do, along with feedback from a
> human developer, something could definitely be done to greatly speed up the
> porting of C++ programs to Rust, and I think many people would love to have
> that, including the wonderful folks at Mozilla. :-)
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jan 5, 2014, at 11:07 PM, Tony Arcieri  wrote:
>
> Just wait until they write RustMonkey for Servo, then you can run your
> Emscriptened C++ inside of that
>
>
> On Sun, Jan 5, 2014 at 6:11 PM, Greg  wrote:
>>
>> I'd happy chip in for a Kickstarter-type project to automatically convert
>> C/C++ to Rust.
>>
>> Anything like this exists or anyone planning on making this type of
>> announcement?
>>
>> - Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing
>> with the NSA.
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
>
> --
> Tony Arcieri
>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust forum

[Martin DeMello]

In practice this has worked out well for the ocaml community - there's an
ocaml-beginners mailing list that gets a small amount of traffic, but very
quick responses from a lot of the more experienced people on the list.

martin


On Tue, Dec 3, 2013 at 2:20 PM, Gaetan  wrote:

> I also agree to split in rust-user for newbee question, but i hope good
> programmers will go a bit on this ml...
> Le 3 déc. 2013 21:42, "Martin DeMello"  a écrit :
>
>> On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry wrote:
>>
>>> Users benefit from the developers list and vice-versa... splitting us
>>> apart would not be a wise choice.
>>>
>>
>> the only downside is that people are reluctant to ask newbie user
>> questions on a list where people are talking about hacking on the compiler.
>>
>> martin
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust forum

[Martin DeMello]

keeping up with email is a lot easier than pretty much everything else,
though. the solution to keeping old messages around is mirroring the
mailing list to a searchable archive, not moving to a forum en masse and
sacrificing ease-of-conversation for ease-of-recall.

martin


On Tue, Dec 3, 2013 at 1:58 PM, Gaetan  wrote:

> Sorry but that is a pretty bad answer. You cannot tell people to change
> their favorite email client just for rust-dev.
>
> You cannot do the same with you client, just because each one will have to
> set its own set of rules to tag, ...
>
> Gmail is a pretty good client, but you have to remember the golden rules
> of email: email is forgotten once it is read. And you cannot search on
> emails you havent received...
>
> Self hosted forum is good, a good rust management in stack overflow is
> much better. If you know better sites, why not making some experiment and
> then vote for the better one.
>
> G.
> Le 3 déc. 2013 21:32, "Thad Guidry"  a écrit :
>
>> Kevin is correct.
>>
>> Where the real issue is that of knowing the capabilities of your
>> particular mail client and maximizing it to gain forum-like features.
>>
>> Many folks use or prefer an online mail client that offers threading,
>> labels, archival search, etc.  Which are all the same features of a forum
>> that is proposed.
>>
>> My suggestion would be instead of jumping to a forum... simply learn
>> about or find a more full featured mail client if you can.
>> If you cannot, then perhaps Gmane could benefit you in the same way.
>>
>> Users benefit from the developers list and vice-versa... splitting us
>> apart would not be a wise choice.
>> --
>> -Thad
>> +ThadGuidry 
>> Thad on LinkedIn 
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust forum

[Martin DeMello]

On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry  wrote:

> Users benefit from the developers list and vice-versa... splitting us
> apart would not be a wise choice.
>

the only downside is that people are reluctant to ask newbie user questions
on a list where people are talking about hacking on the compiler.

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

Re: [rust-dev] typing in rust

[Martin DeMello]

What ML does differently is having the syntax of let bindings
explicitly introduce a new scope by being terminated with 'in' - e.g.
you'd say

let test = test () in
println (format! ("{}", test));

which would make the behaviour unsurprising.

martin

On Wed, Nov 13, 2013 at 10:13 AM, Brendan Zabarauskas
 wrote:
> SML also shares these semantics when it comes to bindings. That is, a 
> subsequent binding to the same identifier can ‘mask’ those that proceed it, 
> even if they are in the same scope and the bound values are of different 
> types. Once a value has had its identifier masked, it can no longer be 
> accessed.
>
> I assume this behaviour was passed on to Ocaml, and Rust inherited it from 
> there. Rust was originally written in Ocaml, and has drawn many influences 
> from there. I personally find it useful from time to time.
>
> ~Brendan
>
> On 14 Nov 2013, at 3:25 am, Joshua Rodgers  wrote:
>
>> I'm curious as to why this is valid, though?  This makes sense if you're 
>> inside a new or nested scope, but why is it valid inside the same scope as 
>> illustrated in the code example?
>>
>> I can understand it from the perspective that I need to mask a function name 
>> (but that's a nested scope to me, at that point).
>>
>>
>> On Wed, Nov 13, 2013 at 8:54 AM, Scott Lawrence  wrote:
>> I would think that `test()` (the function) is in scope for the duration of 
>> `let test =`, and then the new definition masks the old one. Similarly,
>>
>> let x = 2;
>> let x = x + 2;
>>
>> If you change the last line to /call/ test(), you should get an error.
>>
>>
>> On Wed, 13 Nov 2013, Philip Herron wrote:
>>
>> Hey all
>>
>> I am still learning but i just tried something which i expected to give an
>> error but works:
>>
>> fn test () -> int {
>>  1
>> }
>>
>> fn main () {
>>  let test = test ();
>>  println (format! ("{}", test));
>> }
>>
>> I guess on compilation the names are mangled against their types or
>> something so you can differentiate between test the function and test the
>> variable. Not sure would be nice to get some clarification what this
>> behavior is.
>>
>> Thanks
>>
>> --Phil
>>
>>
>> --
>> Scott Lawrence
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Using libextra within libstd?

[Martin DeMello]

okay, i figure niko might want to do this himself, but i've marked my
interest on the bug if he doesn't.

martin

On Mon, Nov 4, 2013 at 4:42 PM, Brian Anderson  wrote:
> On 11/04/2013 03:09 PM, Gaetan wrote:
>
> ok I  understand, it will be like python which I really like the modularity.
> I'm beginning to play a little with std::os as my first rust programming,
> trying to add missing methods, etc, and I think this should quite strategic
> to move to libextra and then to be splitted appart, this would solve this
> cyclic dependency. What do you think about it?
>
>
> Things like 'mkdir' are pretty important and are increasingly tied to our
> I/O subsystem (it just moved into std::rt::io::fs), so I don't think it
> should move out of standard. Since this issue of how to represent OR-able
> flags is pretty common, the consensus seems to be to clean up EnumSet and
> move it to std. If you're interested in tackling it I opened an issue
> specifically about the move https://github.com/mozilla/rust/issues/10272.
>
>
>
> -
> Gaetan
>
>
>
> 2013/11/4 Martin DeMello 
>>
>> How does this work without getting into a dependency loop at build time?
>>
>> martin
>>
>> On Mon, Nov 4, 2013 at 10:55 AM, Brian Anderson 
>> wrote:
>> > On 11/03/2013 11:10 PM, Martin DeMello wrote:
>> >>
>> >> I've been looking at https://github.com/mozilla/rust/issues/6085 which
>> >> seems like it should be fairly simple to fix, however, the proposed
>> >> solution involves EnumSet from libextra.
>> >>
>> >> Is it possible to use stuff from libextra within libstd? It seems to
>> >> me that it would set up a circular dependency, though that could just
>> >> be my misunderstanding the rust compilation model. If it is possible,
>> >> how would I do it? If not, what would be the proper fix for issue
>> >> #6085?
>> >>
>> >
>> > As others mentioned it's not generally possible, but just for
>> > curiosity's
>> > sake I'll point out that when running tests std *does* link to and use
>> > features from libextra. It's mind-bending and bad.
>> >
>> > When we decide that std absolutely can't live without features from
>> > extra,
>> > then those features get promoted to std. The bar is pretty high though.
>> >
>> > ___
>> > Rust-dev mailing list
>> > Rust-dev@mozilla.org
>> > https://mail.mozilla.org/listinfo/rust-dev
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Using libextra within libstd?

[Martin DeMello]

How does this work without getting into a dependency loop at build time?

martin

On Mon, Nov 4, 2013 at 10:55 AM, Brian Anderson  wrote:
> On 11/03/2013 11:10 PM, Martin DeMello wrote:
>>
>> I've been looking at https://github.com/mozilla/rust/issues/6085 which
>> seems like it should be fairly simple to fix, however, the proposed
>> solution involves EnumSet from libextra.
>>
>> Is it possible to use stuff from libextra within libstd? It seems to
>> me that it would set up a circular dependency, though that could just
>> be my misunderstanding the rust compilation model. If it is possible,
>> how would I do it? If not, what would be the proper fix for issue
>> #6085?
>>
>
> As others mentioned it's not generally possible, but just for curiosity's
> sake I'll point out that when running tests std *does* link to and use
> features from libextra. It's mind-bending and bad.
>
> When we decide that std absolutely can't live without features from extra,
> then those features get promoted to std. The bar is pretty high though.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Using libextra within libstd?

[Martin DeMello]

I've been looking at https://github.com/mozilla/rust/issues/6085 which
seems like it should be fairly simple to fix, however, the proposed
solution involves EnumSet from libextra.

Is it possible to use stuff from libextra within libstd? It seems to
me that it would set up a circular dependency, though that could just
be my misunderstanding the rust compilation model. If it is possible,
how would I do it? If not, what would be the proper fix for issue
#6085?

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

Re: [rust-dev] Introducing wxRust

[Martin DeMello]

After thinking about it some more, I realised that bindgen works
perfectly for generating the low-level C layer, and that the custom
codegen can then just handle the OOP layer on top of it.

I did a quick hack here, and after a few signature changes it all just
worked: https://github.com/martindemello/wxRust/commits/bindgen

martin

On Sat, Oct 5, 2013 at 9:54 PM, Martin DeMello  wrote:
> I took a closer look, and now think bindgen may not be the way to go
> for this. The wxc layer uses a bunch of custom C macros to provide
> extra information to binding generators, and generating bindings from
> the preprocessed C source throws all that information away. Might be
> worth taking a closer look at what the Haskell bindings are doing with
> the wxc headers and trying to reproduce that in wxRust.
>
> martin
>
> On Fri, Sep 27, 2013 at 8:51 PM, KENZ gelsoft  wrote:
>> I tried rust-bindgen finally, and it worked excellently. Great work!!
>>
>> Since it requires Clang 3.3 which doesn't exist on OS X 10.8 setup,
>> I tried commit 3d49d7bcc0cf63b43a16a6cf52480fa9b752 and some tweak.
>>
>> And some arguments are needed, for my project:
>>
>> $ ./bindgen -x c++ ../wxRust/wxHaskell/wxc/src/include/wxc.h
>> `wx-config --cflags` --include stdint.h --include time.h >
>> ../wxRust/generated.rs
>>
>> bindgen is C mode as default like clang or gcc are, so I understand it
>> requires `-x c++` option,
>> but I don't know why I have to explicitly include stdint.h and time.h
>> for size_t and uint8_t.
>> Do you have another recommended options?
>>
>> My codegen.py just handles functions, so handling for other
>> definitions benefits.
>> So I want adopt rust-bindgen to generate extern fn part of my binding
>> for long-term plan.
>>
>> Despite I know its Clang requirement changed for bitwidth support, but
>> as a Mac developer, I don't want to install the Clang 3.3 only for 
>> rust-bindgen,
>> especially I don't want add a new prerequisite to my library.
>> Are there a posibility of optional Clang 3.1 support (without bitwidth 
>> support)?
>>
>>
>>
>> 2013/9/26 Martin DeMello :
>>> no, but it might be feasible to add. not sure if it'd fall within the
>>> scope of bindgen or not, but at least bindgen could emit some sort of
>>> serialised data structure that would make generating the next level
>>> binding easier.
>>>
>>> martin
>>>
>>> On Wed, Sep 25, 2013 at 4:49 PM, KENZ gelsoft  
>>> wrote:
>>>> Oh, I didn't know that project, thank you for information. I'll try it.
>>>> BTW, I chose to make own parser and generator to generate not only extern 
>>>> fn
>>>> decls but also next-level wrapper such as:
>>>>
>>>> trait Frame {
>>>>   pub fn show(&self) {
>>>> unsafe {
>>>>   wxFrame_Show(self.handle());
>>>> }
>>>>   }
>>>> }
>>>>
>>>> or so, would bindgen helps this use case? (c.f. parsed data accessible or
>>>> so.)
>>>>
>>>> Did you try using bindgen on the wxc header file? If there were bits
>>>> it couldn't handle, I'd be interested in helping fix that.
>>>>
>>>> martin
>>>>
>>>> On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft 
>>>> wrote:
>>>>> Hello, everyone.
>>>>>
>>>>> I would like to introduce my experimental project, wxRust.
>>>>> Which is a wxWidgets binding for Rust.
>>>>>
>>>>>   https://github.com/kenz-gelsoft/wxRust
>>>>>
>>>>> This binding is based on the wxHaskell especially its "wxc"*1
>>>>> C-Language wxWidgets binding part.
>>>>>
>>>>> Currently, it just converts wxc's header file to `extern fn`s and
>>>>> export them as a rust library.
>>>>>
>>>>> Test program has just started working which opens a wxFrame
>>>>> by calling wxc's C interface from extern fn.
>>>>>
>>>>> Current state is pre-alpha experimental state, there's no stable API,
>>>>> hard to use, but announced here for someone planning similar project.
>>>>>
>>>>> I'm planning for next generating simple OOP style wrapper as rust
>>>>> traits for each classes from wxc's header.
>>>>>
>>>>> There is many problems to tackle, for example how it can work
>>>>> with multitask or, library users can write wx GUI programs easier.
>>>>> Any helps or feedbacks are welcome.
>>>>>
>>>>>  *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]
>>>>>
>>>>>
>>>>> Thanks,
>>>>> --
>>>>> KENZ 
>>>>>
>>>>>
>>>>> ___
>>>>> Rust-dev mailing list
>>>>> Rust-dev@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Introducing wxRust

[Martin DeMello]

I took a closer look, and now think bindgen may not be the way to go
for this. The wxc layer uses a bunch of custom C macros to provide
extra information to binding generators, and generating bindings from
the preprocessed C source throws all that information away. Might be
worth taking a closer look at what the Haskell bindings are doing with
the wxc headers and trying to reproduce that in wxRust.

martin

On Fri, Sep 27, 2013 at 8:51 PM, KENZ gelsoft  wrote:
> I tried rust-bindgen finally, and it worked excellently. Great work!!
>
> Since it requires Clang 3.3 which doesn't exist on OS X 10.8 setup,
> I tried commit 3d49d7bcc0cf63b43a16a6cf52480fa9b752 and some tweak.
>
> And some arguments are needed, for my project:
>
> $ ./bindgen -x c++ ../wxRust/wxHaskell/wxc/src/include/wxc.h
> `wx-config --cflags` --include stdint.h --include time.h >
> ../wxRust/generated.rs
>
> bindgen is C mode as default like clang or gcc are, so I understand it
> requires `-x c++` option,
> but I don't know why I have to explicitly include stdint.h and time.h
> for size_t and uint8_t.
> Do you have another recommended options?
>
> My codegen.py just handles functions, so handling for other
> definitions benefits.
> So I want adopt rust-bindgen to generate extern fn part of my binding
> for long-term plan.
>
> Despite I know its Clang requirement changed for bitwidth support, but
> as a Mac developer, I don't want to install the Clang 3.3 only for 
> rust-bindgen,
> especially I don't want add a new prerequisite to my library.
> Are there a posibility of optional Clang 3.1 support (without bitwidth 
> support)?
>
>
>
> 2013/9/26 Martin DeMello :
>> no, but it might be feasible to add. not sure if it'd fall within the
>> scope of bindgen or not, but at least bindgen could emit some sort of
>> serialised data structure that would make generating the next level
>> binding easier.
>>
>> martin
>>
>> On Wed, Sep 25, 2013 at 4:49 PM, KENZ gelsoft  wrote:
>>> Oh, I didn't know that project, thank you for information. I'll try it.
>>> BTW, I chose to make own parser and generator to generate not only extern fn
>>> decls but also next-level wrapper such as:
>>>
>>> trait Frame {
>>>   pub fn show(&self) {
>>> unsafe {
>>>   wxFrame_Show(self.handle());
>>> }
>>>   }
>>> }
>>>
>>> or so, would bindgen helps this use case? (c.f. parsed data accessible or
>>> so.)
>>>
>>> Did you try using bindgen on the wxc header file? If there were bits
>>> it couldn't handle, I'd be interested in helping fix that.
>>>
>>> martin
>>>
>>> On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft 
>>> wrote:
>>>> Hello, everyone.
>>>>
>>>> I would like to introduce my experimental project, wxRust.
>>>> Which is a wxWidgets binding for Rust.
>>>>
>>>>   https://github.com/kenz-gelsoft/wxRust
>>>>
>>>> This binding is based on the wxHaskell especially its "wxc"*1
>>>> C-Language wxWidgets binding part.
>>>>
>>>> Currently, it just converts wxc's header file to `extern fn`s and
>>>> export them as a rust library.
>>>>
>>>> Test program has just started working which opens a wxFrame
>>>> by calling wxc's C interface from extern fn.
>>>>
>>>> Current state is pre-alpha experimental state, there's no stable API,
>>>> hard to use, but announced here for someone planning similar project.
>>>>
>>>> I'm planning for next generating simple OOP style wrapper as rust
>>>> traits for each classes from wxc's header.
>>>>
>>>> There is many problems to tackle, for example how it can work
>>>> with multitask or, library users can write wx GUI programs easier.
>>>> Any helps or feedbacks are welcome.
>>>>
>>>>  *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]
>>>>
>>>>
>>>> Thanks,
>>>> --
>>>> KENZ 
>>>>
>>>>
>>>> ___
>>>> Rust-dev mailing list
>>>> Rust-dev@mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Introducing wxRust

[Martin DeMello]

I can't take any credit for rust-bindgen :) I can't even answer your
questions right now, since I just started contributing to the project.
But it is indeed a great piece of work, and the author is responsive
to patches, so I'd be happy to work on it to make it meet your needs.

martin

On Fri, Sep 27, 2013 at 8:51 PM, KENZ gelsoft  wrote:
> I tried rust-bindgen finally, and it worked excellently. Great work!!
>
> Since it requires Clang 3.3 which doesn't exist on OS X 10.8 setup,
> I tried commit 3d49d7bcc0cf63b43a16a6cf52480fa9b752 and some tweak.
>
> And some arguments are needed, for my project:
>
> $ ./bindgen -x c++ ../wxRust/wxHaskell/wxc/src/include/wxc.h
> `wx-config --cflags` --include stdint.h --include time.h >
> ../wxRust/generated.rs
>
> bindgen is C mode as default like clang or gcc are, so I understand it
> requires `-x c++` option,
> but I don't know why I have to explicitly include stdint.h and time.h
> for size_t and uint8_t.
> Do you have another recommended options?
>
> My codegen.py just handles functions, so handling for other
> definitions benefits.
> So I want adopt rust-bindgen to generate extern fn part of my binding
> for long-term plan.
>
> Despite I know its Clang requirement changed for bitwidth support, but
> as a Mac developer, I don't want to install the Clang 3.3 only for 
> rust-bindgen,
> especially I don't want add a new prerequisite to my library.
> Are there a posibility of optional Clang 3.1 support (without bitwidth 
> support)?
>
>
>
> 2013/9/26 Martin DeMello :
>> no, but it might be feasible to add. not sure if it'd fall within the
>> scope of bindgen or not, but at least bindgen could emit some sort of
>> serialised data structure that would make generating the next level
>> binding easier.
>>
>> martin
>>
>> On Wed, Sep 25, 2013 at 4:49 PM, KENZ gelsoft  wrote:
>>> Oh, I didn't know that project, thank you for information. I'll try it.
>>> BTW, I chose to make own parser and generator to generate not only extern fn
>>> decls but also next-level wrapper such as:
>>>
>>> trait Frame {
>>>   pub fn show(&self) {
>>> unsafe {
>>>   wxFrame_Show(self.handle());
>>> }
>>>   }
>>> }
>>>
>>> or so, would bindgen helps this use case? (c.f. parsed data accessible or
>>> so.)
>>>
>>> Did you try using bindgen on the wxc header file? If there were bits
>>> it couldn't handle, I'd be interested in helping fix that.
>>>
>>> martin
>>>
>>> On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft 
>>> wrote:
>>>> Hello, everyone.
>>>>
>>>> I would like to introduce my experimental project, wxRust.
>>>> Which is a wxWidgets binding for Rust.
>>>>
>>>>   https://github.com/kenz-gelsoft/wxRust
>>>>
>>>> This binding is based on the wxHaskell especially its "wxc"*1
>>>> C-Language wxWidgets binding part.
>>>>
>>>> Currently, it just converts wxc's header file to `extern fn`s and
>>>> export them as a rust library.
>>>>
>>>> Test program has just started working which opens a wxFrame
>>>> by calling wxc's C interface from extern fn.
>>>>
>>>> Current state is pre-alpha experimental state, there's no stable API,
>>>> hard to use, but announced here for someone planning similar project.
>>>>
>>>> I'm planning for next generating simple OOP style wrapper as rust
>>>> traits for each classes from wxc's header.
>>>>
>>>> There is many problems to tackle, for example how it can work
>>>> with multitask or, library users can write wx GUI programs easier.
>>>> Any helps or feedbacks are welcome.
>>>>
>>>>  *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]
>>>>
>>>>
>>>> Thanks,
>>>> --
>>>> KENZ 
>>>>
>>>>
>>>> ___
>>>> Rust-dev mailing list
>>>> Rust-dev@mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Introducing wxRust

[Martin DeMello]

Did you try using bindgen on the wxc header file? If there were bits
it couldn't handle, I'd be interested in helping fix that.

martin

On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft  wrote:
> Hello, everyone.
>
> I would like to introduce my experimental project, wxRust.
> Which is a wxWidgets binding for Rust.
>
>   https://github.com/kenz-gelsoft/wxRust
>
> This binding is based on the wxHaskell especially its "wxc"*1
> C-Language wxWidgets binding part.
>
> Currently, it just converts wxc's header file to `extern fn`s and
> export them as a rust library.
>
> Test program has just started working which opens a wxFrame
> by calling wxc's C interface from extern fn.
>
> Current state is pre-alpha experimental state, there's no stable API,
> hard to use, but announced here for someone planning similar project.
>
> I'm planning for next generating simple OOP style wrapper as rust
> traits for each classes from wxc's header.
>
> There is many problems to tackle, for example how it can work
> with multitask or, library users can write wx GUI programs easier.
> Any helps or feedbacks are welcome.
>
>  *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]
>
>
> Thanks,
> --
> KENZ 
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Martin DeMello]

Ah, good point. You could fix it by having a very small whitelist of
acceptable delimiters, but that probably takes it into overcomplex
territory.

martin

On Thu, Sep 19, 2013 at 2:46 PM, Kevin Ballard  wrote:
> As I just responded to Masklinn, this is ambiguous. How do you lex `do 
> R{foo()}`?
>
> -Kevin
>
> On Sep 19, 2013, at 2:41 PM, Martin DeMello  wrote:
>
>> Yes, I figured R followed by a non-alphabetical character could serve
>> the same purpose as ruby's %.
>>
>> martin
>>
>> On Thu, Sep 19, 2013 at 2:37 PM, Kevin Ballard  wrote:
>>> I didn't look at Ruby's syntax, but what you just described sounds a little 
>>> too free-form to me. I believe Ruby at least requires a % as part of the 
>>> syntax, e.g. %q{test}. But I don't think %R{test} is a good idea for rust, 
>>> as it would conflict with the % operator. I don't think other punctuation 
>>> would work well either.
>>>
>>> -Kevin
>>>
>>> On Sep 19, 2013, at 2:10 PM, Martin DeMello  wrote:
>>>
>>>> How complicated would it be to use R"" but with arbitrary paired
>>>> delimiters (the way, for instance, ruby does it)? It's very handy to
>>>> pick a delimiter you know does not appear in the string, e.g. if you
>>>> had a string containing ')' you could use R{this is a string with a )
>>>> in it} or R|this is a string with a ) in it|.
>>>>
>>>> martin
>>>>
>>>> On Thu, Sep 19, 2013 at 1:36 PM, Kevin Ballard  wrote:
>>>>> One feature common to many programming languages that Rust lacks is "raw" 
>>>>> string literals. Specifically, these are string literals that don't 
>>>>> interpret backslash-escapes. There are three obvious applications at the 
>>>>> moment: regular expressions, windows file paths, and format!() strings 
>>>>> that want to embed { and } chars. I'm sure there are more as well, such 
>>>>> as large string literals that contain things like HTML text.
>>>>>
>>>>> I took a look at 3 programming languages to see what solutions they had: 
>>>>> D, C++11, and Python. I've reproduced their syntax below, plus one more 
>>>>> custom syntax, along with pros & cons. I'm hoping we can come up with a 
>>>>> syntax that makes sense for Rust.
>>>>>
>>>>> ## Python syntax:
>>>>>
>>>>> Python supports an "r" or "R" prefix on any string literal (both "short" 
>>>>> strings, delimited with a single quote, or "long" strings, delimited with 
>>>>> 3 quotes). The "r" or "R" prefix denotes a "raw string", and has the 
>>>>> effect of disabling backslash-escapes within the string. For the most 
>>>>> part. It actually gets a bit weird: if a sequence of backslashes of an 
>>>>> odd length occurs prior to a quote (of the appropriate quote type for the 
>>>>> string), then the quote is considered to be escaped, but the backslashes 
>>>>> are left in the string. This means r"foo\"" evaluates to the string 
>>>>> `foo\"`, and similarly r"foo\\\"" is `foo\\\"`, but r"foo\\" is merely 
>>>>> the string `foo\\`.
>>>>>
>>>>> Pros:
>>>>> * Simple syntax
>>>>> * Allows for embedding the closing quote character in the raw string
>>>>>
>>>>> Cons:
>>>>> * Handling of backslashes is very bizarre, and the closing quote 
>>>>> character can only be embedded if you want to have a backslash before it.
>>>>>
>>>>> ## C++11 syntax:
>>>>>
>>>>> C++11 allows for raw strings using a sequence of the form R"seq(raw 
>>>>> text)seq". In this construct, `seq` is any sequence of (zero or more) 
>>>>> characters except for: space, (, ), \, \t, \v, \n, \r. The simplest form 
>>>>> looks like R"(raw text)", which allows for anything in the raw text 
>>>>> except for the sequence `)"`. The addition of the delimiter sequence 
>>>>> allows for constructing a raw string containing any sequence at all (as 
>>>>> the delimiter sequence can be adjusted based on the represented text).
>>>>>
>>>>> Pros:
>>>>> * Allows for embedding any character at all (r

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

[Martin DeMello]

Yes, I figured R followed by a non-alphabetical character could serve
the same purpose as ruby's %.

martin

On Thu, Sep 19, 2013 at 2:37 PM, Kevin Ballard  wrote:
> I didn't look at Ruby's syntax, but what you just described sounds a little 
> too free-form to me. I believe Ruby at least requires a % as part of the 
> syntax, e.g. %q{test}. But I don't think %R{test} is a good idea for rust, as 
> it would conflict with the % operator. I don't think other punctuation would 
> work well either.
>
> -Kevin
>
> On Sep 19, 2013, at 2:10 PM, Martin DeMello  wrote:
>
>> How complicated would it be to use R"" but with arbitrary paired
>> delimiters (the way, for instance, ruby does it)? It's very handy to
>> pick a delimiter you know does not appear in the string, e.g. if you
>> had a string containing ')' you could use R{this is a string with a )
>> in it} or R|this is a string with a ) in it|.
>>
>> martin
>>
>> On Thu, Sep 19, 2013 at 1:36 PM, Kevin Ballard  wrote:
>>> One feature common to many programming languages that Rust lacks is "raw" 
>>> string literals. Specifically, these are string literals that don't 
>>> interpret backslash-escapes. There are three obvious applications at the 
>>> moment: regular expressions, windows file paths, and format!() strings that 
>>> want to embed { and } chars. I'm sure there are more as well, such as large 
>>> string literals that contain things like HTML text.
>>>
>>> I took a look at 3 programming languages to see what solutions they had: D, 
>>> C++11, and Python. I've reproduced their syntax below, plus one more custom 
>>> syntax, along with pros & cons. I'm hoping we can come up with a syntax 
>>> that makes sense for Rust.
>>>
>>> ## Python syntax:
>>>
>>> Python supports an "r" or "R" prefix on any string literal (both "short" 
>>> strings, delimited with a single quote, or "long" strings, delimited with 3 
>>> quotes). The "r" or "R" prefix denotes a "raw string", and has the effect 
>>> of disabling backslash-escapes within the string. For the most part. It 
>>> actually gets a bit weird: if a sequence of backslashes of an odd length 
>>> occurs prior to a quote (of the appropriate quote type for the string), 
>>> then the quote is considered to be escaped, but the backslashes are left in 
>>> the string. This means r"foo\"" evaluates to the string `foo\"`, and 
>>> similarly r"foo\\\"" is `foo\\\"`, but r"foo\\" is merely the string 
>>> `foo\\`.
>>>
>>> Pros:
>>> * Simple syntax
>>> * Allows for embedding the closing quote character in the raw string
>>>
>>> Cons:
>>> * Handling of backslashes is very bizarre, and the closing quote character 
>>> can only be embedded if you want to have a backslash before it.
>>>
>>> ## C++11 syntax:
>>>
>>> C++11 allows for raw strings using a sequence of the form R"seq(raw 
>>> text)seq". In this construct, `seq` is any sequence of (zero or more) 
>>> characters except for: space, (, ), \, \t, \v, \n, \r. The simplest form 
>>> looks like R"(raw text)", which allows for anything in the raw text except 
>>> for the sequence `)"`. The addition of the delimiter sequence allows for 
>>> constructing a raw string containing any sequence at all (as the delimiter 
>>> sequence can be adjusted based on the represented text).
>>>
>>> Pros:
>>> * Allows for embedding any character at all (representable in the source 
>>> file encoding), including the closing quote.
>>> * Reasonably straightforward
>>>
>>> Cons:
>>> * Syntax is slightly complicated
>>>
>>> ## D syntax:
>>>
>>> D supports three different forms of raw strings. The first two are similar, 
>>> being r"raw text" and `raw text`. Besides the choice of delimiters, they 
>>> behave identically, in that the raw text may contain anything except for 
>>> the appropriate quote character. The third syntax is a slightly more 
>>> complicated form of C++11's syntax, and is called a delimited string. It 
>>> takes two forms.
>>>
>>> The first looks like q"(raw text)" where the ( may be any non-identifier 
>>> non-whitespace character. If the character is one of [(<{ then it is a 
>>&g

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

[Martin DeMello]

How complicated would it be to use R"" but with arbitrary paired
delimiters (the way, for instance, ruby does it)? It's very handy to
pick a delimiter you know does not appear in the string, e.g. if you
had a string containing ')' you could use R{this is a string with a )
in it} or R|this is a string with a ) in it|.

martin

On Thu, Sep 19, 2013 at 1:36 PM, Kevin Ballard  wrote:
> One feature common to many programming languages that Rust lacks is "raw" 
> string literals. Specifically, these are string literals that don't interpret 
> backslash-escapes. There are three obvious applications at the moment: 
> regular expressions, windows file paths, and format!() strings that want to 
> embed { and } chars. I'm sure there are more as well, such as large string 
> literals that contain things like HTML text.
>
> I took a look at 3 programming languages to see what solutions they had: D, 
> C++11, and Python. I've reproduced their syntax below, plus one more custom 
> syntax, along with pros & cons. I'm hoping we can come up with a syntax that 
> makes sense for Rust.
>
> ## Python syntax:
>
> Python supports an "r" or "R" prefix on any string literal (both "short" 
> strings, delimited with a single quote, or "long" strings, delimited with 3 
> quotes). The "r" or "R" prefix denotes a "raw string", and has the effect of 
> disabling backslash-escapes within the string. For the most part. It actually 
> gets a bit weird: if a sequence of backslashes of an odd length occurs prior 
> to a quote (of the appropriate quote type for the string), then the quote is 
> considered to be escaped, but the backslashes are left in the string. This 
> means r"foo\"" evaluates to the string `foo\"`, and similarly r"foo\\\"" is 
> `foo\\\"`, but r"foo\\" is merely the string `foo\\`.
>
> Pros:
> * Simple syntax
> * Allows for embedding the closing quote character in the raw string
>
> Cons:
> * Handling of backslashes is very bizarre, and the closing quote character 
> can only be embedded if you want to have a backslash before it.
>
> ## C++11 syntax:
>
> C++11 allows for raw strings using a sequence of the form R"seq(raw 
> text)seq". In this construct, `seq` is any sequence of (zero or more) 
> characters except for: space, (, ), \, \t, \v, \n, \r. The simplest form 
> looks like R"(raw text)", which allows for anything in the raw text except 
> for the sequence `)"`. The addition of the delimiter sequence allows for 
> constructing a raw string containing any sequence at all (as the delimiter 
> sequence can be adjusted based on the represented text).
>
> Pros:
> * Allows for embedding any character at all (representable in the source file 
> encoding), including the closing quote.
> * Reasonably straightforward
>
> Cons:
> * Syntax is slightly complicated
>
> ## D syntax:
>
> D supports three different forms of raw strings. The first two are similar, 
> being r"raw text" and `raw text`. Besides the choice of delimiters, they 
> behave identically, in that the raw text may contain anything except for the 
> appropriate quote character. The third syntax is a slightly more complicated 
> form of C++11's syntax, and is called a delimited string. It takes two forms.
>
> The first looks like q"(raw text)" where the ( may be any non-identifier 
> non-whitespace character. If the character is one of [(<{ then it is a 
> "nesting delimiter", and the close delimiter must be the matching ])>} 
> character, otherwise the close delimiter is the same as the open. 
> Furthermore, nesting delimiters do exactly what their name says: they nest. 
> If the nesting delimiter is (), then any ( in the raw text must be balanced 
> with a ) in the raw text. In other words, q"(foo(bar))" evaluates to 
> "foo(bar)", but q"(foo(bar)" and q"(foobar))" are both illegal.
>
> The second uses any identifier as the delimiter. In this case, the identifier 
> must immediately be followed by a newline, and in order to close the string, 
> the close delimiter must be preceded by a newline. This looks like
>
> q"delim
> this is some raw text
> delim"
>
> It's essentially a heredoc. Note that the first newline is not part of the 
> string, but the final newline is, so this evaluates to "this is some raw 
> text\n".
>
> Pros:
> * Flexible
> * Allows for constructing a raw string that contains any desired sequence of 
> characters (representable in the source file's encoding)
>
> Cons:
> * Overly complicated
>
> ## Custom syntax
>
> There's another approach that none of these three languages take, which is to 
> merely allow for doubling up the quote character in order to embed a quote. 
> This would look like R"raw string literal ""with embedded quotes"".", which 
> becomes `raw string literal "with embedded quotes"`.
>
> Pros:
> * Very simple
> * Allows for embedding the close quote character, and therefore, any 
> character (representable in the source file encoding)
>
> Cons:
> * Slightly odd to read
>
> ## Conclusion
>
> Of the three existing syntaxes exam

Re: [rust-dev] c structs with bitfields

[Martin DeMello]

I've gone ahead and added the code to fail on bitfields, but I note
that the original bug report referenced servo/rust-azure, which has
the following

// FIXME: rust-bindgen can't handle bitfields

[https://github.com/mozilla-servo/rust-azure/blob/master/azure-c.h#L235]

So I'd still like to find a better way of handling this case.

martin

On Mon, Sep 9, 2013 at 11:47 AM, Martin DeMello  wrote:
> That seems less than ideal - I mean, there are definitely c libraries
> out there with bitfield widths in their header files, and we should be
> able to use them from rust. And if we do, there should be a way to
> generate the bindings that is systematic enough to be captured within
> bindgen (possibly with a flag specifying the ABI).
>
> martin
>
> On Sun, Sep 8, 2013 at 7:37 PM, Corey Richardson  wrote:
>> Emit an error and fail, I'd say, unless you can tell it which ABI it's
>> targetting so it knows how to handle it.
>>
>> On Sun, Sep 8, 2013 at 8:20 PM, Martin DeMello  
>> wrote:
>>> On Sun, Sep 8, 2013 at 5:14 PM, Corey Richardson  wrote:
>>>> On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello  
>>>> wrote:
>>>>> So am I right that bitfield widths would first need to be added to the
>>>>> rust struct definition and code generator before they can be added to
>>>>> bindgen? I poked around the AST and middle code a bit but couldn't
>>>>> find it if it was there.
>>>>>
>>>>
>>>> Rust doesn't have bitfields and neither does LLVM, nor do I think we 
>>>> should:
>>>>
>>>> 1. bitfield members aren't addressable.
>>>> 2. It would be near impossible to replicate the exact behavior of
>>>> every C compiler for every platform and ABI it supports.
>>>> 3. They add significant additional complexity.
>>>
>>> Which returns me to the higher-level question, then - what is the
>>> correct thing for bindgen to do if handed a C struct with them?
>>>
>>> martin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] c structs with bitfields

[Martin DeMello]

That seems less than ideal - I mean, there are definitely c libraries
out there with bitfield widths in their header files, and we should be
able to use them from rust. And if we do, there should be a way to
generate the bindings that is systematic enough to be captured within
bindgen (possibly with a flag specifying the ABI).

martin

On Sun, Sep 8, 2013 at 7:37 PM, Corey Richardson  wrote:
> Emit an error and fail, I'd say, unless you can tell it which ABI it's
> targetting so it knows how to handle it.
>
> On Sun, Sep 8, 2013 at 8:20 PM, Martin DeMello  
> wrote:
>> On Sun, Sep 8, 2013 at 5:14 PM, Corey Richardson  wrote:
>>> On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello  
>>> wrote:
>>>> So am I right that bitfield widths would first need to be added to the
>>>> rust struct definition and code generator before they can be added to
>>>> bindgen? I poked around the AST and middle code a bit but couldn't
>>>> find it if it was there.
>>>>
>>>
>>> Rust doesn't have bitfields and neither does LLVM, nor do I think we should:
>>>
>>> 1. bitfield members aren't addressable.
>>> 2. It would be near impossible to replicate the exact behavior of
>>> every C compiler for every platform and ABI it supports.
>>> 3. They add significant additional complexity.
>>
>> Which returns me to the higher-level question, then - what is the
>> correct thing for bindgen to do if handed a C struct with them?
>>
>> martin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] c structs with bitfields

[Martin DeMello]

On Sun, Sep 8, 2013 at 5:14 PM, Corey Richardson  wrote:
> On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello  
> wrote:
>> So am I right that bitfield widths would first need to be added to the
>> rust struct definition and code generator before they can be added to
>> bindgen? I poked around the AST and middle code a bit but couldn't
>> find it if it was there.
>>
>
> Rust doesn't have bitfields and neither does LLVM, nor do I think we should:
>
> 1. bitfield members aren't addressable.
> 2. It would be near impossible to replicate the exact behavior of
> every C compiler for every platform and ABI it supports.
> 3. They add significant additional complexity.

Which returns me to the higher-level question, then - what is the
correct thing for bindgen to do if handed a C struct with them?

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

Re: [rust-dev] c structs with bitfields

[Martin DeMello]

So am I right that bitfield widths would first need to be added to the
rust struct definition and code generator before they can be added to
bindgen? I poked around the AST and middle code a bit but couldn't
find it if it was there.

martin

On Sun, Sep 8, 2013 at 12:36 PM, Matthieu Monrocq
 wrote:
> I was using the C++11 Standard actually, but I spoke from memory. Consulting
> n3485 9.6 [class.bit] it is indeed less clear-cut than I thought.
>
> 1/ [...] The value of the integral constant expression may be larger than
> the number of bits in the
> object representation (3.9) of the bit-field’s type; in such cases the extra
> bits are used as padding bits and
> do not participate in the value representation (3.9) of the bit-field. [...]
>
> Seems to indicate that the type used for the bit-field does matter. That is
> if the underlying type is too narrow, then the representable range of values
> is cropped.
>
> However it continue thusly:
>
> 1/ [...] Bit-fields are packed into some addressable allocation unit. [
> Note: Bit-fields straddle allocation units on some machines and not on
> others. [...]
>
> Unfortunately it is unclear, now that I read back, what "allocation unit"
> truly means. I searched in gcc documentation and even them defer the
> decision to the ABI [1]
>
>
> In any case, given that:
>
> 1/ [...] Allocation of bit-fields within a class object is
> implementation-defined. Alignment of bit-fields is implementation-defined.
> [...]
>
> and
>
> 1/ [...] Bit-fields are assigned right-to-left on some machines,
> left-to-right on others. [...]
>
> So it appears that one would really need to check the ABI even for the least
> properties of bit-fields.
>
>
> -- Matthieu
>
> [1]:
> http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html
>
>
>
> On Sun, Sep 8, 2013 at 7:50 PM, Corey Richardson  wrote:
>>
>> On Sun, Sep 8, 2013 at 1:49 PM, Matthieu Monrocq
>>  wrote:
>>>
>>> Actually, for bitfields the types into which the bits are packed are not
>>> left to the compiler. If you said "int c : 4", then it will use a "int".
>>>
>>> If you have:
>>>
>>> int a : 24;
>>> int b : 24;
>>> int c : 16;
>>>
>>> and int is 32 bits on your platform, then a will be 24 somewhere in 32
>>> bits, same thing for b, and c will be 16 bits somewhere in 32 bits; for a
>>> single bit field cannot be split among several underlying integers.
>>>
>>
>> I didn't get that understanding from my reading of the C11 standard; which
>> standard and section says this? I could have misunderstood.
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] c structs with bitfields

[Martin DeMello]

I was looking at the bindgen bug for incorrect bitfield handling

https://github.com/crabtw/rust-bindgen/issues/8

but from a quick pass through the rust manual I can't figure out what
the correct behaviour would be.

What, for example, would the correct bindgen output for the following be:

struct bit {
  int alpha : 12;
  int beta : 6;
  int gamma : 2;
};

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

Re: [rust-dev] PSA: ~"string" is probably not what you want

[Martin DeMello]

In which case, would special-casing == and !=, as you mentioned
earlier, be a bad thing to do? (Sincere question; from a user pov it
would make sense, but I don't know whether it would make operator
overloading conceptually more ugly to have that special case in there)

martin

On Sun, Apr 28, 2013 at 12:49 PM, Patrick Walton  wrote:
> On 4/28/13 12:45 PM, her...@gmail.com wrote:
>>
>> It is very easy to create a language that is unwieldy, but hard to
>> create something KISS simple that can be adopted, and that will be
>> praised for its cleanliness and elegance.
>>
>> If the basic things are not simple, a language will be relegated to
>> academia, and will not be as popular as hoped.
>>
>> We really need to take a look into this one, and come up with something
>> workable. That won't be easy considering what Patrick has mentioned.
>
>
> As Daniel pointed out, it isn't so bad. I didn't realize that we already
> borrow on the left hand side, so you can write:
>
> fn main() {
> let x = ~"foo";
> if "foo" == x {
> println("yep");
> }
> }
>
> We just need to borrow on the right hand side too, so that `x == "foo"`
> works. I can think of ways to do it; none are particularly pretty, but I
> suspect we could make it work. But the situation is not so dire now.
>
> Patrick
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Renaming of core and std

[Martin DeMello]

I like "platform"; a few other languages seem to have converged on it
to describe a blessed set of third-party packages. Of the others
"common" and "base" sound too much like they are a part of core.

martin

On Wed, Apr 24, 2013 at 3:58 PM, Graydon Hoare  wrote:
> On 13-04-24 01:05 PM, Benjamin Striegel wrote:
>> It's important to keep in mind that much of the value of calling
>> something the "standard" library is so that users *know* that the
>> libraries within are blessed by the language developers themselves, and
>> therefore gives them the peace of mind that the code within is
>> featureful, reliable, supported in the long-term, and well-known by the
>> community. Please select a name that adequately expresses the authority
>> of such a library.
>
> Agreed. This packaging will be of a sort that _does_ represent a level
> of support from the language maintainers, version-to-version. So ...
> absent other suggestions I will return to my preferred passtime of
> thesaurus hunting:
>
>   - Common
>   - Platform
>   - Staple
>   - Stock
>   - Supported
>   - Base
>   - Basis
>   - Usual
>   - Normal
>   - Favored
>   - Selected
>   - Endorsed
>   - Chosen
>   - Prime
>
> Any of these sound pleasant to the hear?
>
> -Graydon
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Namespace enum variants under the enum

[Martin DeMello]

Since this is breaking everything anyway, how about syntax to let the
match run inside the enum namespace? e.g.

 enum Color { Red, Green, Blue }
fn main() {
let x = Color::Red;
match Color::{x} {
Red => ...
Green => ...
Blue => ...
}
}

Or even infer that x is of type Color and let the compiler
transparently allow omitting the prefix within the match.

That would remove the primary source of "noisy boilerplate".

martin

On Fri, Mar 22, 2013 at 4:51 PM, Patrick Walton  wrote:
> Hi everyone,
>
> It's been proposed that we place enum variants under the enum itself. That
> is:
>
> enum Option {
> None,
> Some,
> }
>
> Would be accessed as:
>
> fn main() {
> let x = Option::None;
> }
>
> The advantages of this are:
>
> * Rust programmers very frequently generate ad-hoc prefixes to group
> variants under their namespaces. Prefixes seem to me to be the sincerest
> form of feature request for namespaces. (See Objective-C or Gecko `NSFoo`,
> GLib `g_`, etc.)
>
> * You can get the old behavior with `use` or `pub use`.
>
> * Other modules can import all variants belonging to an enum by simply
> writing (say) `use option::Option::*;`. This is a common thing to want and
> would, for example, eliminate all the `use obsolete::{ObsoleteFoo,
> ObsoleteBar, ...}` cruft in `parser.rs`. Note that Haskell introduced
> special notation for this into their `import` statements.
>
> * C++11 went the direction of enum variant namespacing with `enum class`. I
> worry we may be making the same mistake that led them to introduce two
> incompatible versions of enums.
>
> * This may clean up the `use core::option::Option` stuttering in the
> `option` module (and in a few related cases, like `std::list::List`).
> Instead of having types like `std::option::Option`, variants like
> `std::option::None`, and methods like `std::option::Option::is_none`, we
> could have simply `std::Option`, `std::Option::None`, and
> `std::Option::is_none` respectively. This seems to read nicer.
>
> The disadvantages are:
>
> * `::` will show up for many casual uses of enums. e.g.
>
> enum Color { Red, Green, Blue }
> fn main() {
> let x = Color::Red;
> match x {
> Color::Red => ...
> Color::Green => ...
> Color::Blue => ...
> }
> }
>
> Thoughts? This would be a very late-stage change that will break pretty much
> all Rust code in existence, and it has disadvantages, but the advantages
> seem compelling enough to consider it...
>
> Patrick
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Merge Cell and Mut?

[Martin DeMello]

On Thu, Feb 21, 2013 at 10:54 PM, Patrick Walton  wrote:
>
> (4) `with_mut_ref(&self, &fn(&mut T) -> R) -> R`: yields a mutable
> reference to the interior of the cell, failing if the cell is empty or is
> borrowed immutably;

Does this mean you can borrow two mutable references to a cell's contents?

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

Re: [rust-dev] rustpkg, package identifiers, filename conventions

[Martin DeMello]

If you're going to support go-style importing of external packages in
git repos, it's worth reading kana's ideas concerning version tags.
Pasting the relevant bit in:

Plugins must follow the versioning pocilies of RubyGems and have
"version" tags in their repositories. For example, if there is the
version 1.2.3 of a plugin, its repository must have the tag 1.2.3, and
the files of the version 1.2.3 can be checked out via the tag 1.2.3.
In other words, plugins which do not have proper tags are not
installable. This is an intentional design. Because:
It's not possible to determine whether two versions are compatible or
not without "version" tags. Compatibility is a big problem to resolve
dependencies of plugins. For example, if plugin A requires plugin X
1.2.3 or later while plugin B requires plugin X 2.0 or later, it's not
possible to use A and B at the same time. Such problems should be
detected before installing plugins.
Git mirrors by vim-scripts.org are tagged with version numbers.
Some Git repositories might not have "version" tags. Such plugins are
not ready to use for everyone. So that it should not be installable.

https://www.relishapp.com/kana/vim-flavor/docs/philosophy

martin

On Tue, Feb 19, 2013 at 5:05 PM, Graydon Hoare  wrote:
> Hi,
>
> We've recently replaced the cargo package manager with a new (very
> young) tool called rustpkg; in the process it's (temporarily) broken
> most of the packages installable through cargo, but we'll be fixing this
> up before the next release.
>
> The main new feature of rustpkg is that it permits writing custom build
> logic (and custom build tasks) in rust itself, as an escape hatch: if
> there's a file called pkg.rs in a package repository it is compiled,
> linked against rustpkg itself and run for various tasks.
>
> That's a nice feature and all, but we don't want to force (or even
> _suggest_) use of the escape hatch by default. We'd like rustpkg to do
> most things by inferring-sensible-defaults when looking at a repository.
> In particular, building all the most obvious / findable binary and
> library crates contained therein, based on simple rules. Preferably
> rules that don't require parsing all the files in the repo and sorting
> them into a module-graph just to figure out the targets. There might be
> a lot of files (cf. src/test/run-pass/*.rs)
>
> The simplest rule I've come up with is based on a convention for chosen
> filenames and their immediately-containing dir names. Specifically the
> names "lib.rs" for libraries and "bin.rs" for binaries:
>
>   foo/lib.rs ==> build libfoo-.so / .dll, a library
>   foo/bin.rs ==> build foo / foo.exe, an executable
>
> This is a convention that'll require a certain amount of reorganization
> to existing code, but it permits multi-library / multi-binary packages
> in a single source repo, which is an important use-case. Lots of time
> people want >1 crate in the same git tree. Moreover it makes for a
> pretty simple naming heuristic that can be derived directly from
> URL-path-fragment package identifiers, such that:
>
>extern mod foo (id = "github.com/graydon/foo");
>
> will pick up a single-library package, assuming there's a single file
> lib.rs in that repo, and give it the name libfoo-.so, because
> 'foo' is the immediate parent-dir of the lib.rs file. Whereas:
>
>extern mod foo (id = "github.com/graydon/foo/thing");
>
> will look for a thing/lib.rs dir-and-stem inside the
> github.com/graydon/foo repo, and build-and-link _that_ into
> libthing-.so.
>
> This should also permit mapping such identifiers to filesystem paths in
> GOPATH-like workspaces, permitting local workspaces overlaid on global
> ones and branching (via your VCS -- it does versions!) inside local
> workspaces and whatnot. In case it's not clear from the sketch here,
> it's very similar to what Go does -- I think they did a very tidy job
> and I'm interested in copying its good parts. It feels like we didn't
> quite hit the mark with cargo and this is an important thing to get right.
>
> That said, I'm interested in some feedback before we get too far into
> it, to make sure we aren't making serious mistakes or missing issues
> that people feel are unpleasant about URL-centric schemes.
>
> Any thoughts? Notes on other failure modes in package managers? Requests
> for ponies? I'd prefer specificity in response, if you can manage it. We
> all know package management is "generally miserable", but if you can
> describe _exactly_ how things go wrong in other systems and what we
> should be trying to avoid, or aiming for, that'd be good.
>
> Thanks,
>
> -Graydon
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Lifetime notation

[Martin DeMello]

Personally, Foo<'lt, 'xy, X, Y, Z> is perfectly readable, and far less
noisy-looking than having two delimited lists one after another. It
will be even more readable with syntax highlighting.

If multiple lifetime parameters were really a common thing I might
have liked a second separator, maybe Foo<'lt, 'xy | X, Y Z> or
Foo<'lt, 'xy / X, Y, Z>, but that's a very minor issue.

martin

On Thu, Jan 31, 2013 at 1:37 PM, Malte Schütze  wrote:
> On 01/31/2013 09:58 PM, Dean Thompson wrote:
>>
>> On 1/31/13 12:56 PM, "Malte Schütze"  wrote:
>>>
>>> I really prefer Foo{'lt} over Foo'lt - the former makes it
>>> visually clearer to me where each section of the declaration starts and
>>> ends.
>>
>> The non-curly choice is Foo<'lt,X,Y>.  How does that grab you?
>>
>> Dean
>
>
> I'm worried that it might be confusing to read when it becomes longer.
> Foo<'lt,X,Y> still is readable, but Foo<'lt,'xy,X,Y,Z> isn't anymore. Having
> it in curly braces (Foo{'lt,'xy}) breaks it down in smaller parts and
> makes it easier to understand in my opinion.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Compiling without interference from the system LLVM

[Martin DeMello]

How do I configure and make rust (from incoming) so that it doesn't
try to link against my system LLVM and die?

The main problem seems to be that the configure script picks up
/usr/bin/llvm-config

configure: CFG_LLVM_CONFIG  := /usr/bin/llvm-config (3.2)

but I couldn't find anything in the configure options to stop it doing
that. Leaving llvm-root unset was in theory supposed to do the right
thing, but it fails.

I filed a bug about it here:
https://github.com/mozilla/rust/issues/4607 but I figured I'd check
that it wasn't just something I was doing wrong.

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