338 karma · joined March 18, 2014
One of the big wins for Nix is its declarative nature (especially for reproducibility) and installing packages in an imperative manner like this just seems to put folks back in the same position as using pacman or apt-get. Please correct me if I'm wrong Nix-ers.
Having used NixOS as the main OS on my personal laptop for the past year or two (and loving it), I've only used `nix-env -i` to install a package once, and immediately regretted it after trying to add a different version of the same package to my main configuration files. This resulted in a conflict, which from memory required me to force reinstall the package again via `nix-env` but specify a lower priority so that it could be replaced automatically when enabling the package via my configuration files... A really strange experience that re-affirmed that nix-env is at least not for me.
For testing packages, I would always recommend `nix-shell -p <package>` as a preferred option. Just type `exit` and then you've left the shell, it's no longer in your PATH and there's no risk of conflicts.
It sucks that you ran into this, but also totally understandable. I think generally the community would consider the nix-env approach of installing and updating packakges an anti-pattern these days, but this certainly isn't obvious when reading through the docs.
At mindbuffer[1] we've started using it for our recent art installations. The big benefits for us are reproducibility, ease of deployment, and the ability to collaborate on the composition of the whole system. I.e. rather than sharing a README of how to install things one by one and hoping each of us has followed it correctly, we just work on the same set of config files via a git repo (like we would any other code) and can be sure we're all on the same page as a result.
Very much looking forward to Nix 3.0 landing with all its UI improvements and flake support. It seems like these changes will go a long way to making Nix more accessible, and provide a smoother on-ramp to learning the language itself.
As a keen NixOS user, I love the idea of configuring my site with nix and embedding nix exprs in markdown. However, I'm unsure whether the project is still active, or if the whole thing was more of an experiment. The repo[2] seems a little quiet, but the documentation is extensive and great considering! I wonder if the author just considers it complete? Curious to here experiences from anyone who has had a play.
[1]: https://styx-static.github.io/styx-site/ [2]: https://github.com/styx-static/styx/
As someone who does a lot of creative-coding contracts with lots of video, graphics and real-time requirements, RLSL has long been one of the Rust projects that excites me the most. The idea of writing graphics and compute shaders in Rust, a modern language with a decent type system, standard package manager, module system, etc, is very exciting. It makes a lot of sense that Embark see the potential in this for game dev too.
The ability to share Rust code between the CPU and GPU alone will be so useful. The number of times I've had to port some pre-existing Rust function to GLSL or vice versa is silly.
Obviously the Rust that compiles to SPIR-V will be a subset of the Rust that compiles to LLVM or WASM, but this still opens up so many doors for improved ergonomics when interacting with the GPU from a Rust program.
I've long dreamed of an API that allows me to casually send a closure of almost arbitrary Rust code (with the necessary 'lifetime + Send + Sync + SpirvCompatible compile-time checks) off to the GPU for execution and get back a GPU Future of the result. It looks like this may well become possible in the future :)
Just fyi, we are closely watching both wgpu-rs and rendy and will continue to do so over the next couple of months. Vulkano has been a mission to use to say the least, maintainership is dwindling (most of the recent PRs are from us), and the Rust graphics landscape has changed quite a bit since we made the decision to use it almost a year ago. Both wgpu and rendy seem like strong contenders for the future of nannou's graphics, but we probably won't go down that road for a couple more nannou releases at least while we focus on some other areas.
We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
Also, I realise that wgpu is web-first, but I'd be curious to get your thoughts on its potential for use in native applications for installations and projection mapping - e.g. will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Anyway, we'll do another post soon about our thoughts on the future of graphics in nannou, just wanted to let you know you're on our minds :)
I know you're busy with language design these days (and I would never stop you, I think what you are doing is some of the most important work there is right now!), but if you ever get the itch for some creative coding it'd be an honour to see you give nannou a shot and get your thoughts on what's missing, could be improved, etc :)
As lovers of the bullet-proof Rust vest and creative coding frameworks like OpenFrameworks and Processing we felt it was about time to merge the benefits of the two while attempting to apply some of the lessons learned by these predecessors.
While the library is certainly still in its youth we have been using it with great success in our recent commercial work and feel it is finally time to share it with fellow hackers and artists who might like to have a play or perhaps even join the project!
I'll be around to answer any questions for the next hour or two and then will try to make it back on tomorrow before we give the presentation at Protopixel in Barcelona.
I'd like to apologise in advance for the lack of HTTPS - the site is still fresh and we are in the process of getting it working ASAP.
If you would like to skip the announcement post and jump straight to the git repo see here[1]. If you are more curious about the API and would like to jump to the Rust reference, see here[2].
Happy creating!
[1]: https://github.com/nannou-org/nannou [2]: https://docs.rs/nannou
Perhaps the permanence of executing solidity contracts will at least motivate some safer, more secure practises, in the same way that the permanence of death does when programming vehicles that carry human lives.
It would be cool to see APIs for compiling Solidity contracts from safer languages with more concise type systems like Idris[1]. That said, I haven't had a proper dig into Solidity myself yet so it could very well offer some of these features. I'd love to hear some experiences from devs who have written a significant amount of code in it.
edit: This is not counting FFI though.
1. check if PA is already installed 2. if not, will download and install PA.
The pull request is open and is here if you(/anyone) want to check it out / comment / contribute:
I've talked with the author of the PortAudio bindings and we're planning on including a static lib with the repo instead (along with a cargo build script), so that should hopefully make it as easy to use as any other crate.
Re pixel positions: Tooling is planned for easier widget placement... As I mentioned in the article, the project has barely had three weeks worth of work poured into it - perhaps it's best not to try and declare the project as useless when it's barely even out of the womb ;-)
A handy breakthrough in my case was to use Rust's algebraic data type to store each individual widget state within a single container in the UIContext. This is akin to "caching" the state of every widget in one place with a process that is invisible to the user, rather than requiring the user to instantiate large number of objects and work out where they will store widgets, canvases, etc. This approach also makes it really simple to only access certain parts of the state depending on what is needed via Rust's pattern matching and destructuring. I'm yet to come across any kind of widget that is more difficult to store state for than it is in a retained UI (it's even easier for the user of the lib as they don't have to think about it) though perhaps I'm naive in my early days!
All of the widget examples that you have given are already in the plans, I might as well just implement them and do another Show HN instead of rambling in the comments :)
https://github.com/PistonDevelopers/rust-dsp
It only has a basic DSP-chain atm on top of a PortAudio IO callback, but hoping to contribute some synthesis, sampling and effects work soon! Especially now I have some widgets to design instruments with :)
Edit: This was on the latest Chrome, on MacOS10.9.2 btw.
I don't remember any great futurist referring to the "exponential rate of progress in science", but rather the accelerating advances in regards to information processing technology specifically.
Unofficial Google Music API in Python, quite well documented. http://unofficial-google-music-api.readthedocs.org/en/latest...
About to get started writing a little script that will take care of synchronising my library with my google music one, and automatically uploading those that it can't find a match for. A few of my friends also use it, so I was also thinking of making a little tool that would allow us to compare our libraries and show us what each other are missing etc.