ndl@home - Comments

Download and test cxx2rust

Neel Basu — Thu, 01 Oct 2015 17:01:24 +0000

In reply to cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5:

Is there any links ? from where I can download cxx2rust on some other libraries and templates

Download and test cxx2rust

Neel Basu — Thu, 01 Oct 2015 16:58:45 +0000

In reply to cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5:

Is there any links ? from where I can download cxx2rust on some other libraries and templates

Do you think things would go

Gulshan — Fri, 12 Jun 2015 21:11:00 +0000

In reply to cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5:

Do you think things would go better with modern Rust? I've been wanting to use Qt in Rust for a while. Also, is the code for your bindings generator online somewhere?

Any suggestions for ejabberd v14.05

NDL — Thu, 10 Jul 2014 19:11:52 +0000

In reply to mod_archive_odbc release:

No, I’m not aware of any XEP-136 implementations for ejabberd > 2.x

Any suggestions for ejabberd v14.05

Shobhit Singhal — Thu, 10 Jul 2014 15:38:16 +0000

In reply to mod_archive_odbc release:

Just got to know that mod_archive_odbc is not for v14.05 . Any suggestions what to do for this version.

Identical messages

NDL — Tue, 17 Jun 2014 20:40:40 +0000

In reply to mod_archive_odbc release:

Ну да, должны появляться: если контакту пришло N сообщений (неважно, на тот же ресурс или разные) то N сообщений и сохранится, а одинаковый текст или разный - это уже не модуля дело.

пользуюсь mod_archive_odbc на

Дмитрий — Tue, 17 Jun 2014 16:40:24 +0000

In reply to mod_archive_odbc release:

пользуюсь mod_archive_odbc на локалхосте, заметил проблему: когда пользователь залогинен с нескольких ресурсов, и оба эти ресурса получают одинаковое сообщение (так рассылает, например, google talk) -- то в БД, соответственно, появляются идентичные записи от разных ресурсов. Как я понял из исходников, никаких средств контроля доступа к таблице archive_messages не предусмотрено?

> as hitting the mark “worse

Anonymous — Fri, 23 May 2014 08:02:58 +0000

In reply to cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5:

> as hitting the mark “worse functional programming capabilities than in C++” is quite an “achievement” …

Yes, Rust is pretty much dead. It started out pretty nice but then the people behind it got carried away by some "beautiful type system" nonsense and forgot about pragmatism. Now you have a bunch of type system enthusiasts being paid for playing in a chocolate factory.

Optimisations and closures

Huon — Fri, 23 May 2014 05:25:36 +0000

In reply to cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5:

Are you compiling with optimisations (the -O flag or --opt-level=)? That should cause dead functions to be eliminated and so reduce the binary size.

Also, the problems with closures are known, and it's being progressively improved (e.g. https://github.com/rust-lang/rfcs/pull/77 ).

By the way, your work-around has a very high risk of invoking undefined behaviour. The reason the compiler doesn't let you call a closure through & is because all mutations of aliased data need to go via the Unsafe type (or one of the wrappers, like RefCell or Cell). Mutating via & without using Unsafe is undefined behaviour (in the sense of C/C++) and the compiler may "break" your program.

A closure can mutate its environment, hence calling one via & risks invoking undefined behaviour. However, it should be safe if you enforce that there are no captures (by giving the closure the 'static lifetime, e.g. |...|:'static -> ...).

It's worth mentioning that this does mean that implementing

Things are getting even more complex if “mut” state for slots is allowed - up to the point I had to always use only non-mut and use RefCell<> for any mutable state that is accessed in slots.

requires special care.

The state is limited to only one variable. Multiple variables would complicate things even further by requiring to select the appropriate Callable struct implementation.

Rust has tuples (e.g. (int, f64)) so you can have a state being multiple variables by capturing a tuple.

Surprisingly, the answer is “no”! Rust doesn’t even have member functions pointers! This means there’s no way to implement generic “callable” trait that would forward calls to the member function of your choice.

A bare function pointer is writen fn(...) -> .... E.g.

struct Foo { f: fn(int) -> int }
 
fn increment(x: int) -> int { x + 1 }
 
fn main() {
    let foo = Foo { f: increment };
 
    println!("{}", (foo.f)(2));
}

There is some subtlety there, in that writing foo.f(2) is always interpreted as a method call, so the parentheses are required to disambiguate.

I didn’t manage to find the way to use lifetimes properly in “::new” functions. That is, in the examples above I have to construct the struct in two steps: calling “new” first and then “init” from the code that actually instantiates “DigitalClock” or “ImageViewer” structs, see lines 67 and 333 respectively.

At a guess, this is probably due to the &'a self annotation on init. This forces the 'a lifetime of the ImageViewer to be the stack frame of new, since that's where the ImageViewer struct is placed when you call init (and hence the maximum time that the &self reference passed to init can last).

Theoretically the correct fix would be removing the 'a reference on the self reference, but I imagine that this would cause the captures of each slot to not last long enough. Another possible fix would be using a shared pointer equivalent (Rc) so that the captures do not need to have lifetimes like they have there... A third possible fix would be having some sort of action dispatcher on the ImageViewer type, which then passed a reference to itself into the action handler automatically (rather than "manually" capturing self for each one). However, I imagine this last one is very hard when using a library that's not been designed for it.

(BTW, I'm having a lot of troubling getting past your captcha; it's very hard even for a human!)

Optimisations and closures

Huon — Fri, 23 May 2014 05:24:15 +0000

In reply to cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5:

Are you compiling with optimisations (the -O flag or --opt-level=)? That should cause dead functions to be eliminated and so reduce the binary size.

Also, the problems with closures are known, and it's being progressively improved (e.g. https://github.com/rust-lang/rfcs/pull/77 ).

It's worth mentioning that this does mean that implementing

Things are getting even more complex if “mut” state for slots is allowed - up to the point I had to always use only non-mut and use RefCell<> for any mutable state that is accessed in slots.

requires special care.

The state is limited to only one variable. Multiple variables would complicate things even further by requiring to select the appropriate Callable struct implementation.

Rust has tuples (e.g. (int, f64)) so you can have a state being multiple variables by capturing a tuple.

Surprisingly, the answer is “no”! Rust doesn’t even have member functions pointers! This means there’s no way to implement generic “callable” trait that would forward calls to the member function of your choice.

A bare function pointer is writen fn(...) -> .... E.g.

struct Foo { f: fn(int) -> int }
 
fn increment(x: int) -> int { x + 1 }
 
fn main() {
    let foo = Foo { f: increment };
 
    println!("{}", (foo.f)(2));
}

There is some subtlety there, in that writing foo.f(2) is always interpreted as a method call, so the parentheses are required to disambiguate.

I didn’t manage to find the way to use lifetimes properly in “::new” functions. That is, in the examples above I have to construct the struct in two steps: calling “new” first and then “init” from the code that actually instantiates “DigitalClock” or “ImageViewer” structs, see lines 67 and 333 respectively.

(BTW, I'm having a lot of troubling getting past your captcha; it's very hard even for a human!)