Re: [rust-dev] Recommendations for a GUI toolkit for rust
However, my primary concern is that the toolkit I use would stop active development - I don't want to have to port everything to another toolkit later on. So, if any project shows promise of continuing, please suggest it to me. Both Qt and GTK+ have been around for a long time and are actively used in a lot of software. GTK+ has had lulls in its development in the past and Qt's development focus is dependent on who the majority of Digia's customers are, so neither is risk free but both are probably reasonably safe. Another alternative would be to use a browser as the UI and implement the bulk of the logic in Rust. On 25 November 2014 at 17:53, Gaetan gae...@xeberon.net wrote: To my opinion qt is far better, more portable, more easy to work with, but binding qt on rust is quite a challenge. I think binding gtk3 is much easier, however I don't think there is any project ready for production yet. Le mardi 25 novembre 2014, Prasoon Shukla prasoon92.i...@gmail.com a écrit : Hey all I have been thinking of making a small text editor, with emacs-like fundamentals, as a way learning rust this winter break. I need a GUI toolkit for this, of course. So, I searched for it and found this page: https://github.com/kud1ing/awesome-rust This page gives a few choices to me and since everything is alpha right now (both the language and the toolkits), I don't know which one to choose. As a reference, I have used GTK+ before and so, I could probably use it again https://github.com/JeremyLetang/rgtk. However, my primary concern is that the toolkit I use would stop active development - I don't want to have to port everything to another toolkit later on. So, if any project shows promise of continuing, please suggest it to me. Thank you. ᐧ -- - Gaetan ___ 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] Compiling Rust apps with Meson v2
Hi Jussi,
Thanks. meson looks like CMake with a somewhat more sane build config
language. Not directly related to Rust, but what is the tooling story
like with Qt Creator - eg. has any work been done on teaching Qt
Creator to understand meson projects?
On 23 June 2014 21:00, Jussi Pakkanen jpakk...@gmail.com wrote:
Hi
I finished basic Rust support for the Meson build system. It now supports
shared and static libraries with full install support and all that. Here's
the entire build definition for a library and two executables that use it.
project('libproject', 'rust')
corelib = shared_library('core', 'core.rs')
executable('someapp', 'someapp.rs', link_with : corelib)
executable('otherapp', 'otherapp.rs', link_with : corelib)
To try it get Meson trunk: https://github.com/jpakkane/meson
If you try to run the Rust unit tests, note that dependency tracking fails
because rustc creates invalid dependency files. I filed a bug on that:
https://github.com/rust-lang/rust/issues/15124
Other random tidbits and questions I was asked:
Could Meson build Rust itself? Possibly, though it probably needs some help
from Rust specialists. If someone wants to try this, I'll be glad to help.
Can Meson handle complex setups? The most complex thus far has been Qt
Creator:
http://sourceforge.net/p/meson/mailman/message/32335155/
Enjoy,
___
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: Future of the Build System
Probably 100 lines of python, plus templates; a bit more to make it highly usable. Not sure what the equivalent would be in Rust code, as I'm still fairly new to it. Maybe the initial version - then you add logic to deal with different versions of Xcode/Visual Studio etc, then some more logic to find different packages that rust requires to build on a multitude of systems etc. etc. Sometimes you can get away writing something new and simple that just deals with your use case (building Rust here). The problem is if you end up with lots of feature creep re-discovering all the knowledge that is encoded in existing tools - eg. the many modules for config checks, locating packages etc. that come with CMake, automake, SCons etc. By all means, have a go at writing that initial version and see how well it serves you - but be prepared to switch if it looks like you are re-inventing something that already exists. On 21 October 2013 12:43, George Makrydakis irrequie...@gmail.com wrote: This is why I am reserving commentation right now and have been consistently asking about Rust providing a build system in all other emails. Can the other commenters refocus with the rest of us back to the original question? Corey Richardson co...@octayn.net wrote: On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden leebr...@gmail.com wrote: Another point is that we don't really need a massively complicated build system right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. ___ 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: Future of the Build System
Hello, CMake does have a few things going for it: - It is a popular choice for C++ projects, including LLVM, WebKit and others, so this would provide familiarity from developers coming from C++ - As mentioned, it is a meta-build system which can generate project files for Xcode, Visual Studio, Ninja and others. This is very useful for cross-platform development - It has a good and sizable ecosystem (full time active maintainers, documentation, user questions on StackOverflow etc.) - It has a large collection of modules to find packages, detect compiler versions etc. Downsides for CMake include: - The built script language is primitive and not a familiar language like Python. It is easy enough to use for writing a build project file but for more complex logic, I've found it easier to write separate commands in Python/Ruby which CMake then invokes. - CMakeLists.txt files are not declarative documents that can be easily parsed by other tools for eg. IDE integration. Having said that, the CMake developers are aware of the benefits of more declarative ways of specifying things and there is a general trend in that direction. - Adds a non-rusty dependency to rust. Regards, Rob. On 10 January 2014 10:06, Gaetan gae...@xeberon.net wrote: See this page that compares scons to other build system: http://www.scons.org/wiki/SconsVsOtherBuildTools I still personally recommend CMake. One of the major feature is that it is NOT a build system, it a script factory that generates system dependant build file: Makefile for GNU, Visual Studio for Windows, Eclipse projects,... It actually replaces all bash scripts we usually write on large projects to trigger the builds. - Gaetan 2014/1/10 Jan Niklas Hasse jha...@gmail.com Have you heart about waf? http://code.google.com/p/waf/ It only depends on Python so this would not result in another dependency. The python script ( 200 kB) can be included in the repository. I am all for using rustpkg though. And I'm strongly against cmake, because I don't know its language and don't like a build system which doesn't use an already existing one (like scons is using Python). Also cmake still depends on make (or even worse Visual Studio / Xcode). 2014/1/10 Corey Richardson co...@octayn.net Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does
Re: [rust-dev] RFC: Future of the Build System
- CMakeLists.txt often look ugly [2] and don't follow any particular style (lower case vs. upper case, etc.). A fair point, though a number of projects do have coding conventions for CMakeLists.txt files, one of which could be adopted - eg. http://techbase.kde.org/Policies/CMake_Coding_Style Regards, Rob. On 10 January 2014 17:38, Thad Guidry thadgui...@gmail.com wrote: Best Reason ever for a Rust Build System = You Prove Rust Itself. So get hacking on a Rust Build System. -- -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
Re: [rust-dev] About owned pointer
Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? ~ does allocate on the heap. Without ~ you allocate on the stack. Regards, Rob. On 7 November 2013 10:03, Gaetan gae...@xeberon.net wrote: Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ 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?
Is it possible to use stuff from libextra within libstd? It seems to me that it would set up a circular dependency Even if it was possible technically, probably not a good idea from a maintenance perspective to have such dependencies. On 4 November 2013 07:10, Martin DeMello martindeme...@gmail.com 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? 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] implicit vs explicit generic bounds
(It may also be the case that I'm ignorant of what the best C++ tools today
do, though I'm pretty sure that these drawbacks are consequences of core C++
design.)
Recent versions of Clang and GCC have much better diagnostics for
template issues than compilers from a couple of years ago
but you're right - C++ templates are fundamentally compile-time
duck-typing and consequently the error
messages are basically a stack trace.
The recent 'Concepts Lite' proposal for C++1y addresses this by
allowing template arguments
to be allowing template args to be constrained [1].
Regards,
Rob.
[1]
http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s
On 17 September 2013 14:29, Felix S. Klock II pnkfe...@mozilla.com wrote:
Gokcehan (cc'ing rust-dev)-
Correct, rust generics are not Turing-complete. (To my knowledge; I don't
think we've written the termination proof for the type-checker yet. :)
Cheers,
-Felix
On 17/09/2013 15:25, Gokcehan Kara wrote:
Felix, C++ template errors are indeed a joy(!) to deal with. I guess I also
would rather be explicit than to have cryptic error messages that are pages
long. You're also right about the absence of errors without the client code
which makes sense in a context of safety.
It was the first time I heard about SFINAE. It reminds me of
turing-completeness proofs of C++ templates. Does that mean rust generics
are not turing complete?
Gokcehan
On Tue, Sep 17, 2013 at 3:28 PM, Felix S. Klock II pnkfe...@mozilla.com
wrote:
Gokcehan-
My understanding is that C++, due to its policy of SFINAE [1], usually
provides error feedback after the template has been fully instantiated and
the fully instantiated version fails to compile. This can lead to hard to
debug compile-time failures.
Good compilers can help with dissecting the output you get in this case,
but it is still a real pain to decode in my experience, especially when you
have nests of template code written in terms of other template code. Since
the template parameters do not have bounds, it is not possible for a
compiler to provide any error feedback given a template definition alone
(with no client code), and its difficult for the compiler to provide good
error feedback that is described solely in terms of the definition: you are
doomed to thinking about the intermingling of the definition with the
particular instantiation.
Requiring explicit bounds means that the compiler can provide good error
messages at the point where the parameterized class is *defined* (even in
the absence of client code!) rather than delaying to the point where the
parmeterized class is fully instantiated. This provides me with more
confidence that the parametric code I write is actually going to compose
properly with other implementations of the trait-bounds in terms of which I
have written my code.
That advantage alone is enough to justify this choice for *me*. There may
be other justifications that I am overlooking.
(It may also be the case that I'm ignorant of what the best C++ tools
today do, though I'm pretty sure that these drawbacks are consequences of
core C++ design.)
Cheers,
-Felix
[1] SFINAE:
http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error
On 17/09/2013 13:34, Gokcehan Kara wrote:
Hello,
I have met rust a few days ago and let me pay my respects first for making
such a powerful language. I really hope to succeed making some contribution
in the upcoming days.
I was reading the tutorial (http://static.rust-lang.org/doc/tutorial.html)
specifically the section 16.3 and I was wondering if there's a rationale
behind making generic bounds explicit. For example in C++ I can do:
// clang++ asd.cc -std=c++11 -Weverything -Wno-c++98-compat -g
./a.out
#include iostream
#include vector
using namespace std;
class Klass {
public:
void print() { cout printing the thing endl; }
};
template typename T void print_all(vectorT things) {
for (auto thing : things) {
thing.print();
}
}
int main() {
vectorKlass v1;
v1.push_back(Klass());
v1.push_back(Klass());
v1.push_back(Klass());
print_all(v1); // no errors
vectorint v2;
v2.push_back(1);
v2.push_back(2);
v2.push_back(3);
print_all(v2); // /tmp/asd.cc:18:10: error: member reference base
type 'int'
// is not a structure or union/tmp/asd.cc:37:3: note:
in
// instantiation of function template specialization
// 'draw_allint' requested here
return 0;
}
and it gives me the necessary error at compile time. To my limited
knowledge, this is also statically dispatched so should not cause any
overhead.
I haven't used Haskell much but I know a little bit of Scala. In Scala you
need to be explicit because generics are
Re: [rust-dev] Rust compiler bootstrapped
People seem to reimplement C++ compilers, despite there being an enormous amount of complex just parsing it Realistically though, how many implementations are libre and complete enough to actually build a C++ compiler? On 13 September 2013 10:51, Niko Matsakis n...@alum.mit.edu wrote: People seem to reimplement C++ compilers, despite there being an enormous amount of complex just parsing it... that said, the trickiest and least specified part of the type checker right now is probably the type inferencing algorithm, which I hope we can overhaul for something that is clearer or more easily specified. Niko On Wed, Sep 11, 2013 at 08:50:39AM -0400, Corey Richardson wrote: On Wed, Sep 11, 2013 at 3:27 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Presumably before rust reaches a point of earth-shaking importance there will be an second implementation which can compile the first compiler, thus permitting this solution. :) I wouldn't be so sure of that. There's a ton of trickiness around the type and borrow checker and everything else, and I'm not sure anyone would *want* to reimplement it. What gain would there be? ___ 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] rustdoc_ng: 95% done
Hello Corey, Thanks for your work on this. The live search is especially welcome. The relative weights of fonts on the page don't correspond to their importance. That is, the TUTORIAL | MANUAL bit is the largest, boldest, most whitespaced piece of the page but they're only links you're really looking for when you first open the docs, not something you need at the forefront when you're digging into the details of some random function. That was my first impression as well, possibly because of the contrast with the manual and Github interfaces. I'd suggest lightening the font weights and sizes in general. Regards, Rob. On 12 August 2013 17:20, Corey Richardson co...@octayn.net wrote: On Mon, Aug 12, 2013 at 12:15 PM, Evan Martin mart...@danga.com wrote: I love that there are cross-references within the code snippets. It's great to be able to quickly look up what a trait means. I noticed that prelude in the discussion on http://seld.be/rustdoc/master/std/index.html isn't a link, is that easy to make work or is it too Javadoc-y to need to mark up cross references in free text like that? Sure, a plugin could implement this. It would not be very easy, though, it'd need to hook into `resolve`, which I don't know how to do. Speaking of the prelude, I noticed that these docs, like the old rust docs, don't say anything in the prelude. Is that possible to fix? That was one of the first places I wanted to skim when I was trying to get a handle on the language. As I said, documentation of `pub use` (which is all the prelude consists of) is the last missing piece of functionality. ___ 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
