ndl@home - Commentshttp://endl.ch
CommentsenDownload and test cxx2rusthttp://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5#comment-1341
<p>In reply to <a href="http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5">cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5</a>:</p>
<p>Is there any links ? from where I can download cxx2rust on some other libraries and templates</p>
Thu, 01 Oct 2015 17:01:24 +0000Neel Basucomment 1341 at http://endl.chDownload and test cxx2rusthttp://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5#comment-1340
<p>In reply to <a href="http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5">cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5</a>:</p>
<p>Is there any links ? from where I can download cxx2rust on some other libraries and templates</p>
Thu, 01 Oct 2015 16:58:45 +0000Neel Basucomment 1340 at http://endl.chDo you think things would gohttp://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5#comment-1288
<p>In reply to <a href="http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5">cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5</a>:</p>
<p>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?</p>
Fri, 12 Jun 2015 21:11:00 +0000Gulshancomment 1288 at http://endl.chAny suggestions for ejabberd v14.05http://endl.ch/content/modarchiveodbc-release#comment-1281
<p>In reply to <a href="http://endl.ch/content/modarchiveodbc-release">mod_archive_odbc release</a>:</p>
<p>No, I&#8217;m not aware of any <span class="caps">XEP</span>-136 implementations for ejabberd >&nbsp;2.x</p>
Thu, 10 Jul 2014 19:11:52 +0000NDLcomment 1281 at http://endl.chAny suggestions for ejabberd v14.05http://endl.ch/content/modarchiveodbc-release#comment-1279
<p>In reply to <a href="http://endl.ch/content/modarchiveodbc-release">mod_archive_odbc release</a>:</p>
<p>Just got to know that mod_archive_odbc is not for v14.05 . Any suggestions what to do for this version.</p>
Thu, 10 Jul 2014 15:38:16 +0000Shobhit Singhalcomment 1279 at http://endl.chIdentical messageshttp://endl.ch/content/modarchiveodbc-release#comment-1276
<p>In reply to <a href="http://endl.ch/content/modarchiveodbc-release">mod_archive_odbc release</a>:</p>
<p>Ну да, должны появляться: если контакту пришло N сообщений (неважно, на тот же ресурс или разные) то N сообщений и сохранится, а одинаковый текст или разный - это уже не модуля&nbsp;дело.</p>
Tue, 17 Jun 2014 20:40:40 +0000NDLcomment 1276 at http://endl.chпользуюсь mod_archive_odbc наhttp://endl.ch/content/modarchiveodbc-release#comment-1275
<p>In reply to <a href="http://endl.ch/content/modarchiveodbc-release">mod_archive_odbc release</a>:</p>
пользуюсь mod_archive_odbc на локалхосте, заметил проблему: когда пользователь залогинен с нескольких ресурсов, и оба эти ресурса получают одинаковое сообщение (так рассылает, например, google talk) -- то в БД, соответственно, появляются идентичные записи от разных ресурсов.
Как я понял из исходников, никаких средств контроля доступа к таблице archive_messages не предусмотрено?Tue, 17 Jun 2014 16:40:24 +0000Дмитрийcomment 1275 at http://endl.ch> as hitting the mark “worsehttp://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5#comment-1269
<p>In reply to <a href="http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5">cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5</a>:</p>
<p>&gt; as hitting the mark “worse functional programming capabilities than in C++” is quite an “achievement” …</p>
<p>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.</p>
Fri, 23 May 2014 08:02:58 +0000Anonymouscomment 1269 at http://endl.chOptimisations and closureshttp://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5#comment-1268
<p>In reply to <a href="http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5">cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5</a>:</p>
<p>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.</p>
<p>Also, the problems with closures are known, and it's being progressively improved (e.g. <a href="https://github.com/rust-lang/rfcs/pull/77" title="https://github.com/rust-lang/rfcs/pull/77" rel="nofollow">https://github.com/rust-lang/rfcs/pull/77</a> ).</p>
<p>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 <span class="geshifilter"><code class="text geshifilter-text">&amp;</code></span> is because all mutations of aliased data need to go via the <a href="http://doc.rust-lang.org/master/core/ty/struct.Unsafe.html" rel="nofollow"><span class="geshifilter"><code class="text geshifilter-text">Unsafe</code></span> type</a> (or one of the wrappers, like <a href="http://doc.rust-lang.org/master/core/cell/struct.RefCell.html" rel="nofollow"><span class="geshifilter"><code class="text geshifilter-text">RefCell</code></span></a> or <a href="http://doc.rust-lang.org/master/core/cell/struct.Cell.html" rel="nofollow"><span class="geshifilter"><code class="text geshifilter-text">Cell</code></span></a>). Mutating via <span class="geshifilter"><code class="text geshifilter-text">&amp;</code></span> without using <span class="geshifilter"><code class="text geshifilter-text">Unsafe</code></span> is undefined behaviour (in the sense of C/C++) and the compiler may "break" your program.</p>
<p>A closure can mutate its environment, hence calling one via <span class="geshifilter"><code class="text geshifilter-text">&amp;</code></span> risks invoking undefined behaviour. However, it should be safe if you enforce that there are no captures (by giving the closure the <span class="geshifilter"><code class="text geshifilter-text">'static</code></span> lifetime, e.g. <span class="geshifilter"><code class="text geshifilter-text">|...|:'static -&gt; ...</code></span>).</p>
<p>It's worth mentioning that this does mean that implementing</p>
<blockquote><p>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&lt;&gt; for any mutable state that is accessed in slots.</p></blockquote>
<p>requires special care.</p>
<blockquote><p>The state is limited to only one variable. Multiple variables would complicate things even further by requiring to select the appropriate Callable struct implementation.</p></blockquote>
<p>Rust has tuples (e.g. <span class="geshifilter"><code class="text geshifilter-text">(int, f64)</code></span>) so you can have a state being multiple variables by capturing a tuple.</p>
<blockquote><p>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.</p></blockquote>
<p>A bare function pointer is writen <span class="geshifilter"><code class="text geshifilter-text">fn(...) -&gt; ...</code></span>. E.g.</p>
<p><div class="geshifilter"><pre class="text geshifilter-text" style="font-family:monospace;">struct Foo { f: fn(int) -&gt; int }
&nbsp;
fn increment(x: int) -&gt; int { x + 1 }
&nbsp;
fn main() {
let foo = Foo { f: increment };
&nbsp;
println!(&quot;{}&quot;, (foo.f)(2));
}</pre></div></p>
<p>There is some subtlety there, in that writing <span class="geshifilter"><code class="text geshifilter-text">foo.f(2)</code></span> is always interpreted as a method call, so the parentheses are required to disambiguate.</p>
<blockquote><p>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.</p></blockquote>
<p>At a guess, this is probably due to the <span class="geshifilter"><code class="text geshifilter-text">&amp;'a self</code></span> annotation on <span class="geshifilter"><code class="text geshifilter-text">init</code></span>. This forces the <span class="geshifilter"><code class="text geshifilter-text">'a</code></span> lifetime of the <span class="geshifilter"><code class="text geshifilter-text">ImageViewer</code></span> to be the stack frame of <span class="geshifilter"><code class="text geshifilter-text">new</code></span>, since that's where the <span class="geshifilter"><code class="text geshifilter-text">ImageViewer</code></span> struct is placed when you call <span class="geshifilter"><code class="text geshifilter-text">init</code></span> (and hence the maximum time that the <span class="geshifilter"><code class="text geshifilter-text">&amp;self</code></span> reference passed to <span class="geshifilter"><code class="text geshifilter-text">init</code></span> can last).</p>
<p>Theoretically the correct fix would be removing the <span class="geshifilter"><code class="text geshifilter-text">'a</code></span> 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 (<span class="geshifilter"><code class="text geshifilter-text">Rc</code></span>) 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 <span class="geshifilter"><code class="text geshifilter-text">ImageViewer</code></span> type, which then passed a reference to itself into the action handler automatically (rather than "manually" capturing <span class="geshifilter"><code class="text geshifilter-text">self</code></span> for each one). However, I imagine this last one is very hard when using a library that's not been designed for it.</p>
<p>(BTW, I'm having a lot of troubling getting past your captcha; it's very hard even for a human!)</p>
Fri, 23 May 2014 05:25:36 +0000Huoncomment 1268 at http://endl.chOptimisations and closureshttp://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5#comment-1267
<p>In reply to <a href="http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5">cxx2rust: the pains of wrapping C++ in Rust on the example of Qt5</a>:</p>
<p>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.</p>
<p>Also, the problems with closures are known, and it's being progressively improved (e.g. <a href="https://github.com/rust-lang/rfcs/pull/77" title="https://github.com/rust-lang/rfcs/pull/77" rel="nofollow">https://github.com/rust-lang/rfcs/pull/77</a> ).</p>
<p>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 <span class="geshifilter"><code class="text geshifilter-text">&amp;</code></span> is because all mutations of aliased data need to go via the <a href="http://doc.rust-lang.org/master/core/ty/struct.Unsafe.html" rel="nofollow"><span class="geshifilter"><code class="text geshifilter-text">Unsafe</code></span> type</a> (or one of the wrappers, like <a href="http://doc.rust-lang.org/master/core/cell/struct.RefCell.html" rel="nofollow"><span class="geshifilter"><code class="text geshifilter-text">RefCell</code></span></a> or <a href="http://doc.rust-lang.org/master/core/cell/struct.Cell.html" rel="nofollow"><span class="geshifilter"><code class="text geshifilter-text">Cell</code></span></a>). Mutating via <span class="geshifilter"><code class="text geshifilter-text">&amp;</code></span> without using <span class="geshifilter"><code class="text geshifilter-text">Unsafe</code></span> is undefined behaviour (in the sense of C/C++) and the compiler may "break" your program.</p>
<p>A closure can mutate its environment, hence calling one via <span class="geshifilter"><code class="text geshifilter-text">&amp;</code></span> risks invoking undefined behaviour. However, it should be safe if you enforce that there are no captures (by giving the closure the <span class="geshifilter"><code class="text geshifilter-text">'static</code></span> lifetime, e.g. <span class="geshifilter"><code class="text geshifilter-text">|...|:'static -&gt; ...</code></span>).</p>
<p>It's worth mentioning that this does mean that implementing</p>
<blockquote><p>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&lt;&gt; for any mutable state that is accessed in slots.</p></blockquote>
<p>requires special care.</p>
<blockquote><p>The state is limited to only one variable. Multiple variables would complicate things even further by requiring to select the appropriate Callable struct implementation.</p></blockquote>
<p>Rust has tuples (e.g. <span class="geshifilter"><code class="text geshifilter-text">(int, f64)</code></span>) so you can have a state being multiple variables by capturing a tuple.</p>
<blockquote><p>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.</p></blockquote>
<p>A bare function pointer is writen <span class="geshifilter"><code class="text geshifilter-text">fn(...) -&gt; ...</code></span>. E.g.</p>
<p><div class="geshifilter"><pre class="text geshifilter-text" style="font-family:monospace;">struct Foo { f: fn(int) -&gt; int }
&nbsp;
fn increment(x: int) -&gt; int { x + 1 }
&nbsp;
fn main() {
let foo = Foo { f: increment };
&nbsp;
println!(&quot;{}&quot;, (foo.f)(2));
}</pre></div></p>
<p>There is some subtlety there, in that writing <span class="geshifilter"><code class="text geshifilter-text">foo.f(2)</code></span> is always interpreted as a method call, so the parentheses are required to disambiguate.</p>
<blockquote><p>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.</p></blockquote>
<p>At a guess, this is probably due to the <span class="geshifilter"><code class="text geshifilter-text">&amp;'a self</code></span> annotation on <span class="geshifilter"><code class="text geshifilter-text">init</code></span>. This forces the <span class="geshifilter"><code class="text geshifilter-text">'a</code></span> lifetime of the <span class="geshifilter"><code class="text geshifilter-text">ImageViewer</code></span> to be the stack frame of <span class="geshifilter"><code class="text geshifilter-text">new</code></span>, since that's where the <span class="geshifilter"><code class="text geshifilter-text">ImageViewer</code></span> struct is placed when you call <span class="geshifilter"><code class="text geshifilter-text">init</code></span> (and hence the maximum time that the <span class="geshifilter"><code class="text geshifilter-text">&amp;self</code></span> reference passed to <span class="geshifilter"><code class="text geshifilter-text">init</code></span> can last).</p>
<p>Theoretically the correct fix would be removing the <span class="geshifilter"><code class="text geshifilter-text">'a</code></span> 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 (<span class="geshifilter"><code class="text geshifilter-text">Rc</code></span>) 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 <span class="geshifilter"><code class="text geshifilter-text">ImageViewer</code></span> type, which then passed a reference to itself into the action handler automatically (rather than "manually" capturing <span class="geshifilter"><code class="text geshifilter-text">self</code></span> for each one). However, I imagine this last one is very hard when using a library that's not been designed for it.</p>
<p>(BTW, I'm having a lot of troubling getting past your captcha; it's very hard even for a human!)</p>
Fri, 23 May 2014 05:24:15 +0000Huoncomment 1267 at http://endl.ch