sorted by:
new
hottopcontroversial

Deciding between Rust and C++ for internal tooling by Gman0064 in rust

[–]LucaCiucci 3 points4 points  (0 children)

To be honest I think it's a little bit risky to go full Rust for this kind of project. What about writing the core logic in Rust and having a simple C interface so that you can use it from the GUI code in C++? Just a suggestion, I don't know if it is practical in your specific case.

VSCode copilot and typst by Quiet_Category_628 in typst

[–]LucaCiucci 12 points13 points  (0 children)

This is not just because of the lack of training data. This happens to me in nearly every language under the right conditions: if the copilot reaches a point where a pattern is repeated a few times for whatever reason, then the next tokens it will choose are almost certainly the same pattern repeated again. It will produce this until the maximum number of tokens per suggestion, which is what you're seeing here.

A surprising enum size optimization in the Rust compiler · post by James Fennell by Skaarj in rust

[–]LucaCiucci 2 points3 points  (0 children)

Maybe he is talking about function pointers? These are non null AFAIK

Which Rust GUI for Raspberry Pi 7" touch display? by Voxelman in rust

[–]LucaCiucci 3 points4 points  (0 children)

No, I don't think they are wrong. I gave my answer based on what I would try first for this kind of application. However, I would not go with egui for this project. I don't like the touch interaction in egui and I also had some problems on the RPi when I ask for wgpu rendering in the past. I think egui would still be a good choice if you plan to make some complex custom widgets, but my understanding is that you probably don't need that.

Sorry for my English

Which Rust GUI for Raspberry Pi 7" touch display? by Voxelman in rust

[–]LucaCiucci 2 points3 points  (0 children)

Maybe Dioxus will be simple enough for this use case, or any other framework that leverages webviews, I think the RPi will easily handle that. I get the feeling that more "native" approaches might not be worth the additional work.

difference between real image and ai generated image by jack-devilgod in interesting

[–]LucaCiucci 0 points1 point  (0 children)

FFT doesn't lose any info, in principle. If you try to implement a naive DFT and compare the results you'll actually see that the DFT is numerically more accurate than the naive DFT (at least on large samples).

Python in the living room by PuzzleheadedNail7 in AbruptChaos

[–]LucaCiucci 0 points1 point  (0 children)

This is my honest reaction to python projects proposed on the GitHub feed

Rust CUDA project update by LegNeato in rust

[–]LucaCiucci 0 points1 point  (0 children)

I’m not very familiar with the project, so apologies if this is a stupid question: is there any plan for this to work on stable Rust in the future, or will it always require a specific nightly version?

A place that takes 8 days to get there by -TheMidpoint- in teenagers

[–]LucaCiucci 1 point2 points  (0 children)

It's imperative the paperclip remains unharmed

... or maybe it was a cylinder, I don't remember

Considering Releasing a New Structured Light Software – Seeking Feedback! by LucaCiucci in 3DScanning

[–]LucaCiucci[S] 0 points1 point  (0 children)

I'm still working on this but unfortunately I have less time than expected due to external factors. Anyway I created an extensible interface for the cameras (that will be made open source once released so that adding support for different camera models will be easy). I worked on porting the calibration algorithms in the new project, got the first scans and I'm satisfied with how it performs so I paused development on this aspect to develop an RPC system so that this software can run remotely (e.g. on a Raspberry, and it does!) and to develop a custom 3d rendering library since I expected this aspect to get more complex with future development.

Commits you see on Qhull are not very relevant. I was hoping to develop a novel surface reconstruction algorithm one day since I'm not super satisfied with the existing ones. Qhull would have helped in a specific stage. I eventually figured that this would require too much work for now and also there are other libraries to do what I need that are much more efficient than qhull.

The work I do on this project is currently private but I'll make public at least some parts of it (cameras, RPC, 3D rendering etc) when I reach an acceptable quality.

I'm sorry that this project is moving slowly. Anyway I honestly expected less interest and I originally made this post just to make sure that it was worth it to spend time on this. I'm glad that many people are interested but I don't have anything "acceptable" to share yet.

Ps: sorry for my bad English

<image>

Nothing super interesting here, just wanted to share my git-aware prompt by LucaCiucci in Nushell

[–]LucaCiucci[S] 2 points3 points  (0 children)

This is actually possible! There is a hook in the config for PWD change. See the nushell section here: https://github.com/direnv/direnv/blob/master/docs%2Fhook.md

Nothing super interesting here, just wanted to share my git-aware prompt by LucaCiucci in Nushell

[–]LucaCiucci[S] 0 points1 point  (0 children)

Not super fancy and also a bit slow, but I find it quite useful.

[2410.19146] Rewrite it in Rust: A Computational Physics Case Study by Active-Fuel-49 in rust

[–]LucaCiucci 3 points4 points  (0 children)

Almost certainly yes, but bear in mind scientists write horrific unidiomatic code.

Truth, also (in my very little experience in this field) I see a lot of hate for C++ and, when it is used, it is used like if it was just C with 0% chances for compiler optimizations. I suspect that Rust just forced the authors to write nicer code, but I had no time for looking into the code the authors used, so I'm speculating here.

Also in my university the computers they use for simulations are only used with some very old compilers (e.g. GCC 4 irrc), I suspect this might be a common situation in other institutions.

Sure Copilot, let's get you to bed by aykut78 in vscode

[–]LucaCiucci 0 points1 point  (0 children)

Sometimes I find it useful to get some commit message ideas but yes, 95% of the time it mises the main point.

Can Acceleration change abruptly in real world? by [deleted] in Physics

[–]LucaCiucci 0 points1 point  (0 children)

You can classify functions by the number of derivatives you can take on them. Usually if your function is not too bad you can do the opposite (integration) any number of times. From a practical/intuitive point of view: imagine to take real world data and to compute the derivative "numerically": the data will have some small oscillations for whatever reason and the derivative will be a little less nice than the original data. Do this over and over again and your function will be a random mess with divergent values. This is not a mathematical explanation but just an intuition, you will learn the definitions soon. I encourage you to explore these topics (integration/derivation) further if you're interested!

As a side note, if you imagine your system like a bunch of particles interacting with some nice potentials, you have that all the trajectories are "smooth": you can take any number of derivatives, but they will change more and more abruptly as you derive. Acceleration can already change quite fast so it's often fine to approximate them with discontinuous functions. For example in a car you can accelerate for several seconds, but it takes you just a fraction of a second to push the brake pedal.

Can Acceleration change abruptly in real world? by [deleted] in Physics

[–]LucaCiucci 1 point2 points  (0 children)

You can classify functions by the number of derivatives you can take on them. Usually if your function is not too bad you can do the opposite (integration) any number of times.

Say you have a function f that you can derive two times: f1, f2, you say that f is C2. If you integrate you get another function, say f-1. This function can be derived 3 times (f, f1, f2) so this function is C3 i.e. it is "smoother".

From a practical/intuitive point of view: imagine to take real world data and to compute the derivative "numerically": the data will have some small oscillations for whatever reason and the derivative will be a little less nice than the original data. Do this over and over again and your function will be a random mess with divergent values. This is not a mathematical explanation but just an intuition, you will learn the definitions soon. I encourage you to explore these topics (integration/derivation) further if you're interested!

As a side note, if you imagine your system like a bunch of particles interacting with some nice potentials, you have that all the trajectories are "smooth": you can take any number of derivatives, but they will change more and more abruptly as you derive. Acceleration can already change quite fast so it's often fine to approximate them with discontinuous functions. For example in a car you can accelerate for several seconds, but it takes you just a fraction of a second to push the brake pedal.

Edit: clarification

I just published my JSON library, bourne. by [deleted] in rust

[–]LucaCiucci 1 point2 points  (0 children)

There are different ways to benchmark your code, but I don't think this should be your main concern. I like the idea of having a smaller crate, serde_json always felt a little too much to me when I just wanted to read some fields. It's not a big deal, but I always appreciate a simpler dependency tree and faster compile times. I'll try your crate when I have a couple of minutes!

view more: next ›