Re: [rust-dev] Rustaceans - Rust User Groups
users.rust-lang.org is usually good enough for this. You can also email rust-commun...@googlegroups.com if you want to contact the community team (we may set up a separate forum for event organizers c) Thanks, -Manish Goregaokar On Tue, Aug 11, 2015 at 7:52 PM, Douglas Campos q...@qmx.me wrote: and where is this place you mention? On Tue, Aug 11, 2015 at 11:12 AM, Simon Flynn simon.fl...@financejobs.co wrote: Hi Rustaceans, With the rust-dev mailing list in a semi-abanandonded state, we have decided to create a new place where people can gather to talk all thing Rust, but in particular to help organize local meetups and other gatherings (e.g. conferences, open days etc). Rust on, Simon -- Simon Flynn https://www.financejobs.co ___ 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-dev will be shut down soon
Should be simple as an IFTT recipe.. -Manish Goregaokar On Wed, May 20, 2015 at 1:35 PM, techabc tech...@gmail.com wrote: Is there a way(i.e. a robot) to mirror the contents in read only mode of reddit/r/rust to this mailling lists? 2015-01-24 4:39 GMT+08:00 Brian Anderson bander...@mozilla.com: Tomi, Once the new discourse instance is set up it will be publicized on the home page, and we may also decide then to put the internals forum there as well, since it's purpose will be less easily confused. On Thu, Jan 22, 2015 at 10:33 PM, Tomi Pieviläinen tomi.pievilai...@iki.fi wrote: My last comment about visibility of the discourse pretty much immediately side-tracked into the merits and flaws of mailing lists... But nobody really answered whether the absence of links from the Rust homepage to the discourse was intentional. Does internal use then mean that it is meant only for those in the know, and only the future general discourse will be put on the home page? At least I'm interested in following the dev discussion, even if I'm not an insider, and I heard of it purely by accident. -- Tomi Pieviläinen, +358 400 487 504 A: Because it disrupts the natural way of thinking. Q: Why is top posting frowned upon? ___ 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] rust-dev will be shut down soon
internals means compiler internals and all usually. (cf #rust-internals on IRC, the internals tag on Discourse, etc) AFAICT it will still be completely open for all to comment on -Manish Goregaokar On Fri, Jan 23, 2015 at 12:03 PM, Tomi Pieviläinen tomi.pievilai...@iki.fi wrote: My last comment about visibility of the discourse pretty much immediately side-tracked into the merits and flaws of mailing lists... But nobody really answered whether the absence of links from the Rust homepage to the discourse was intentional. Does internal use then mean that it is meant only for those in the know, and only the future general discourse will be put on the home page? At least I'm interested in following the dev discussion, even if I'm not an insider, and I heard of it purely by accident. -- Tomi Pieviläinen, +358 400 487 504 A: Because it disrupts the natural way of thinking. Q: Why is top posting frowned upon? ___ 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 const
We have two types of floats, there is a Pi of both precision levels. I don't think it's anything more than that. You should be able to cast between the two, but that's it I guess. Rust tries to give explicit control over such things. There is a Float trait (might have been renamed) if you want to use generics. -Manish Goregaokar On Sun, Jan 4, 2015 at 3:07 PM, Pim Schellart p.schell...@gmail.com wrote: Dear Rust Developers, here is another ignorant question so feel free to ignore. When reading the guide I came across std::f64::consts::PI” for pi. Now I was wondering why there are separate constants defined for 32 and 64 bit floats and how this will work with generics. Do you always have to define two functions to work on f32 and f64 or is std::f64::consts::PI cast down to f32 in an equation with 32 bit variables? Is there also a general `typeless’ PI (or other fundamental constants), as in Go for example? Kind Regards, Pim ___ 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] Overflow when benchmarking
C++/C has a lot of features which seem tantalizing at first; but end up
being against the point of a systems language.
Putting large arrays on the heap (not sure if C++ does this, but it sounds
like something C++ would do) is one -- there are plenty of cases where you
explicitly want stack-based arrays in systems programming.
Another is the alloca-like behavior of dynamically sized stack-based arrays
(just learned about this recently).
You always want to be clear of what the compiler is doing. Such
optimizations can easily be implemented as a library :)
-Manish Goregaokar
On Thu, Nov 27, 2014 at 10:20 PM, Diggory Hardy li...@dhardy.name wrote:
Shouldn't the compiler automatically put large arrays on the heap? I
thought this was a common thing to do beyond a certain memory size.
On Thursday 27 November 2014 04:28:03 Steven Fackler wrote:
The `nums` array is allocated on the stack and is 8 MB (assuming you're on
a 64 bit platform).
On Wed Nov 26 2014 at 8:23:08 PM Ben Wilson benwilson...@gmail.com
wrote:
Hey folks, I've started writing some rust code lately and run into weird
behavior when benchmarking. When running
https://gist.github.com/benwilson512/56f84d4625f11feb
#[bench]
fn test_overflow(b: mut Bencher) {
let nums = [0i, ..100];
b.iter(|| {
let mut x = 0i;
for i in range(0, nums.len()) {
x = nums[i];
}
});
}
I get task 'main' has overflowed its stack pretty much immediately when
running cargo bench. Ordinarily I'd expect to see that error when doing
recursion, but I can't quite figure out why it's showing up here. What am I
missing?
Thanks!
- Ben
___
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] Programmaticaly accessing compiler warnings
I'm interested, though rather busy right now (free after the second week of November) -Manish Goregaokar On Mon, Nov 3, 2014 at 1:56 AM, Nick Cameron li...@ncameron.org wrote: There currently isn't, but I'd like to add API for this as part of the rustc::middle::save module. If anyone is interested in implementing that, it shouldn't be too hard and I'd be happy to help out. Cheers, Nick On Sun, Nov 2, 2014 at 11:32 AM, Andreas Tolfsen a...@mozilla.com wrote: On Sat, Nov 1, 2014 at 3:08 PM, Vladimir Pouzanov farcal...@gmail.com wrote: Is there any way to access compiler warnings and errors other than parsing stdout? I'd prefer a bit more structured approach. Most editors such will understand the output format from the compiler: /home/ato/Code/wires/src/response.rs:30:17: 30:20 warning: unused variable: `msg`, #[warn(unused_variables)] on by default In Emacs there are a number of built-in functions to deal with the output in the compilation mode buffer: https://www.gnu.org/software/emacs/manual/html_node/emacs/Compilation-Mode.html In vi you can type :cwindow to access the compile window. And in Acme you can simply right-click somefile.rs:42:12 to go to column 12 in line 42 in somefile.rs. So the output the compiler gives is machine readable, and there are many more tools that understand it. ___ 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] Programmaticaly accessing compiler warnings
IIRC there aren't, we came across this while trying to fix a Cargo bug. Structured logging would be nice to have, though. -Manish Goregaokar On Sun, Nov 2, 2014 at 3:38 AM, Vladimir Pouzanov farcal...@gmail.com wrote: Hi all. Is there any way to access compiler warnings and errors other than parsing stdout? I'd prefer a bit more structured approach. -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ 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 Research Project Query
Servo has a bunch of student projects https://github.com/servo/servo/wiki/Student-projects that you might be interested in. -Manish Goregaokar On Thu, Oct 9, 2014 at 6:50 AM, Corey Richardson co...@octayn.net wrote: LLVM already has support for instrumenting code to generate gcov data, I believe Luqman and Huon have looked into this, at least slightly. On Wed, Oct 8, 2014 at 9:09 PM, Sean McArthur smcart...@mozilla.com wrote: A project I'd love to see (either separate, or eventually baked into the test harness), is test coverage data. Something like how Go's cover[1] works, by adding counters to the source code, seems simplest. I've thought about this, and it could either be a CLI tool, like `rustc --cover --test`, or a plugin. Perhaps including a `#![cover]` attribute in the crate or something. With a plugin, the Plugin Registrar would need to add the ability to register a Visitor that can modify the AST. [1] http://blog.golang.org/cover ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ 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] On the use of unsafe
This had to do with XSS-proofing templates, which is a bit different and requires compile time magic. I've seen people concatenate strings while using prepared PDO queries in PHP -- nonnegotiable safety built in to the library is much better. This can't be handled with a type system. -Manish Goregaokar On Mon, Sep 22, 2014 at 10:10 PM, Matthieu Monrocq matthieu.monr...@gmail.com wrote: It's completely unnecessary actually. If a method requires a XSS-safe string, then it should take the XssSafeString parameter, which would implement DerefString and would be built from a String by a method performing the necessary escaping. If a method requires a SQL-safe string... ah no, don't do that, use bind-parameters and you are guaranteed to be sql-injection safe. In each case, the attributes so defined can be perfectly replaced with appropriate types... so why not use types ? On Mon, Sep 22, 2014 at 4:50 AM, Manish Goregaokar manishsm...@gmail.com wrote: That's not how Rust defines `unsafe`. It's open to misuse, and the compiler will happily point out that it's not being used correctly via the unnecessary unsafe lint. If that's the case, do you think there's some worth in allowing the programmer to define arbitrary generic safety types? E.g have an `#[unsafe(strings)]` attribute that can be placed on methods that break String guarantees (and placed on blocks where we wish to allow such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If something like this slide https://www.youtube.com/watch?feature=player_detailpagev=jVoFws7rp88#t=1664 was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities can have `#[unsafe(xss)]`. Rust does a bunch of compile time checking to achieve memory safety. It also provides a syntax extension/lint system that allows for programmers to define further compile time checks, which open up the gate for many more possible safety guarantees (instead of relying on separate static analysis tools), and not just memory safety. Perhaps we should start recognizing and leveraging that ability more :) -Manish Goregaokar ___ 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] On the use of unsafe
As Chris mentioned, it's not about using the type system to create safety. We're assuming that exists, the idea is to gate unchecked access to the data (which *is* required for libraries created for generic use) with the `unsafe` keyword. However, many seem to be of the opinion that `unsafe` is just for memory safety, in which case it would be nice to have a wider range of `unsafe` attributes (or something) which allow us to gate methods that are prone to SQL injection (etc etc). -Manish Goregaokar On Tue, Sep 23, 2014 at 3:01 AM, Tony Arcieri basc...@gmail.com wrote: On Mon, Sep 22, 2014 at 2:15 PM, Daniel Micay danielmi...@gmail.com wrote: I think it can be solved by using visibility, along with providing a way to override the visibility rules and call private functions. That means replacing the current usage of visibility for memory safety with unsafe fields though, but I think that's important to make the memory safety boundary work properly anyway. Just to clarify what I see going on here and how other (type) systems have solved this: For things like XSS and SQLi, the problem is untrusted off-the-wire data being used in what is more or less a secure context. Some might refer to this sort of untrusted off-the-wire data as tainted and try to use some sort of taint analysis to solve the problem. The TS* dependent type system refers to it as Un (i.e. untrusted) and relies on its dependent type system to prove Un data isn't used in a secure context. Very fancy and possibly overkill, but that said, a pretty awesome solution to the problem. There is a *generic* problem here of using such untrusted data in any sort of templating or metalinguistic context. The general problem is OWASP #1: failure to sanitize input, affecting vulnerabilities like XSS, SQLi, and LDAP injection. I am absolutely certain this affects systems like Servo as well ;) Preventing untrusted data from penetrating the secure contexts of the program using the type system has the potential to mitigate the most common security vulnerabilities if done correctly. -- 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] On the use of unsafe
I'm not talking about unsafe fields. (maybe I gave that impression? Sorry.) That's how it is defined in the manual, sure, but the language is changing :) Anyway, as mentioned before we don't need to use `unsafe` for non-memory safety guarantees, if we define anothe attribute that genericises it. -Manish Goregaokar On Tue, Sep 23, 2014 at 5:01 AM, Daniel Micay danielmi...@gmail.com wrote: On 22/09/14 06:45 PM, Manish Goregaokar wrote: As Chris mentioned, it's not about using the type system to create safety. We're assuming that exists, the idea is to gate unchecked access to the data (which /is/ required for libraries created for generic use) with the `unsafe` keyword. However, many seem to be of the opinion that `unsafe` is just for memory safety, in which case it would be nice to have a wider range of `unsafe` attributes (or something) which allow us to gate methods that are prone to SQL injection (etc etc). -Manish Goregaokar It's not an opinion, it's how it's defined in the documentation (see the Rust manual) and the compiler warns about unnecessary usage of `unsafe` - which could be finished if there were `unsafe` fields. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On the use of unsafe
That's not how Rust defines `unsafe`. It's open to misuse, and the compiler will happily point out that it's not being used correctly via the unnecessary unsafe lint. If that's the case, do you think there's some worth in allowing the programmer to define arbitrary generic safety types? E.g have an `#[unsafe(strings)]` attribute that can be placed on methods that break String guarantees (and placed on blocks where we wish to allow such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If something like this slide https://www.youtube.com/watch?feature=player_detailpagev=jVoFws7rp88#t=1664 was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities can have `#[unsafe(xss)]`. Rust does a bunch of compile time checking to achieve memory safety. It also provides a syntax extension/lint system that allows for programmers to define further compile time checks, which open up the gate for many more possible safety guarantees (instead of relying on separate static analysis tools), and not just memory safety. Perhaps we should start recognizing and leveraging that ability more :) -Manish Goregaokar ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Cleaner and more visible llvm options?
A few days ago I was setting up a clean Rust build, and I wanted to avoid the llvm build. For some reason, the apt-get install from the Travis file didn't work -- there were gpg issues. Eventually I ended up using Servo's llvm snapshot. Which was fine with me. However, the only reason I knew that we could do this was because I've worked with Rust's travis file before and knew that llvm could be apt-get'ed with some gpg jugglery. Today, a friend of mine was trying to build Rust, and he had no clue about this -- so went to build LLVM. LLVM takes *very* long to compile -- perhaps we should make the apt-get alternative more visible somehow? Compile times can be a put off to newbies. Even better, provide our own llvm snapshot on rust-lang.org that gets downloaded with the right configure flag, perhaps even making this the default option. Servo does this for Rust, and it's a rather smooth experience. -Manishearth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Dynamic format template
Why not create a trait Localizer , and make BoxLocalizer fmt!able? -Manish Goregaokar On Mon, Aug 25, 2014 at 9:59 PM, Matthieu Monrocq matthieu.monr...@gmail.com wrote: While not possible today, there is actually nothing preventing you to create a safe alternative (or even improving format so it works in this way). In a sense, a formatting function has two set of inputs: - the format itself, from which you extract a set of constraints (expected type-signature) - the arguments to format, which can be seen as a single tuple (provided type-signature) And as long as you can ensure at compile time that you never attempt to apply an expected type-signature to an incompatible provided type-signature, then you are safe. I would suppose that as far as having runtime formats go, you would need to introduce an intermediary step: the expected type-signature. You could have a Format object, generic over the expected type-signature, and a new constructor method taking a str and returning an OptionFormat Now, you have two phases: - the new constructor checks, at runtime, that the specified format matches the expected type-signature - the compiler checks, at compile-time, that the provided type-signature (arguments) match the expected type-signature (or it can be coerced to) It might require variadic generics and subtle massaging of the type system, however I do think it would be possible. It might not be the best way to attack the issue though. On Mon, Aug 25, 2014 at 1:33 AM, Kevin Ballard ke...@sb.org wrote: It’s technically possible, but horribly unsafe. The only thing that makes it safe to do normally is the syntax extension that implements `format!()` ensures all the types match. If you really think you need this, you can look at the implementation of core::fmt. But it’s certainly not appropriate for localization, or template engines. -Kevin Ballard On Aug 24, 2014, at 2:48 PM, Vadim Chugunov vadi...@gmail.com wrote: Hi, Is there any way to make Rust's fmt module to consume format template specified at runtime? This might be useful for localization of format!'ed strings, or, if one wants to use format! as a rudimentary template engine. ___ 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] Qt5 Rust bindings and general C++ to Rust bindings feedback
FWIW you can achieve overloading by means of a parameter enum that captures
all the various ways of entering data. Usually an overloaded function is
just that -- each variant does the same thing, just that the initial data
is in a different format.
So you drive down to the essence of the overloading -- here the overloading
boils down to give me a rectangle, in some format, and a color, in some
format -- so do just that, give it enum parameters. One that is a
rectangle, in some format, and the other is a color, in some format.
This is actually cleaner, IMO, and as an added bonus you only have to
define the function once with a match statement inside to normalize the
data. This also lets one bubble the overloading out, you can call this
from within a similar rust-overloaded function that needs, say, a
rectangle, a circle, and a color, without having to tweak the parameters
for every overloaded instance
True, in some cases overloaded functions have different behavior based on
which one is used, but that can be handled here too, and for that matter if
they behave differently it might be best to give them different names :)
For example, the two ways of specifying a rect can be managed via:
enum Rectangle {
Rect(Qrect),
Coord(int, int, int, int)
}
and for the colors
enum ColorProvider {
Brush(QBrush),
Color(QColor),
GColor(GlobalColor)
}
-Manish Goregaokar
On Fri, Jun 6, 2014 at 3:24 PM, Kevin Cantu m...@kevincantu.org wrote:
Apologies for the accidentally sent email. Not sure what GMail just did
for me there. Anyways, with a macro it should be possible to use the types
given to choose between mangled names, for example, at compile time.
Kevin
On Fri, Jun 6, 2014 at 2:44 AM, Kevin Cantu m...@kevincantu.org wrote:
I imagine a macro like the following, which is NOT a macro, because I
don't know how to write macros yet:
macro fillRect(args...) {
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 )
On Fri, Jun 6, 2014 at 2:35 AM, Kevin Cantu m...@kevincantu.org wrote:
Since C# allows overloaded methods, but F# doesn't want them, what F#
does is somewhat interesting: overloaded methods are permitted in the
language, provided that the arguments are in tuple form, not curried form.
[http://msdn.microsoft.com/en-us/library/dd483468.aspx]
In practice, this means that all the calls to C# (tupled arguments) can
be resolved, but idiomatic F# doesn't have overloaded methods.
// tuple calling convention: looks like C#
let aa = csharp_library.mx(1, 2)
let bb = csharp_library.mx(1)
// curried calling convention: makes dd, below, a function not a value
let cc = fsharp_library.m2 1 2
let dd = fsharp_library.m2 1
Would it be useful to use pattern matching over some generic sort of
tuples to implement something similar in Rust?
Kevin
On Sat, May 24, 2014 at 3:45 AM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Sat, May 24, 2014 at 9:06 AM, Zoltán Tóth zo1...@gmail.com 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
