Hacker News new | past | comments | ask | show | jobs | submit | merksoftworks's comments login

pde5 inhibitors have some dangerous interactions other medications. They also give some people headaches, up to and including migraines. I agree, they will probably end up in some techies nootropic stacks in the near future, I would use them for that. But they can cause blood pressure issues.

Already is, see: https://old.reddit.com/r/Nootropics/search?q=Cialis&restrict...

Partial doses of cialis use is also a thing in the bodybuilding world

For those curious, be mindful that an all too common side effect of pde5 inhibitors like cialis is eventual tinnitus (even at low doses), which is not worth whatever you are hoping gain.


That's how ye' get yerself Tzeench'd


ffmpeg has always felt like a gui application crammed into tui format. I've had the displeasure of using the C api a few times, while it's straight forward in many respects, it makes invalid states extremely easy to represent. I would love a realtime AV1 encoding framework that "just works".


> ffmpeg has always felt like a gui application crammed into tui format.

It’s one of the only tools where I reach for a GUI equivalent (Handbrake) by default, unless I’m doing batch processing. There are a few pure ffmpeg GUIs out there as well. There’s just something about working with video that CLI doesn’t work right with my brain for.


I can vouch for GStreamer as an API. I was using the Rust bindings so not super familiar with the C API but it looks good. GObject makes some things verbose but once you understand it you can interact with every object in the API consistently. There is a ton of necessary complexity (video is hard) but it’s really well designed and pretty well implemented and documented.

If you have a pretty normal use case the Bins (decodebin, transcodebin, playbin) make that pretty easy. If you have a more complex use case the flexibility of the design makes it possible.


ffmpeg API is somewhat clunky but it works fine. I dread working with gstreamer, sea of leaky abstractions, inexplicable workarounds and mysterious bugs.


I like this insight, but TUI is something graphical while ffmpeg is just CLI.

It would be cool to see if a TUI tool existed. Something like https://github.com/Twinklebear/fbed but more feature complete.


Technical art is definitely my first love in software. I'm excited for godot to add an easier compute shader pipeline for post processing effects - their current compositor plugin set up is a bit boiler plate intensive.

this repo is a great example of post processing in godot: https://github.com/sphynx-owner/JFA_driven_motion_blur_demo


I have a use case for slang, I want to use it to transpile user provided shaders to WGSL and then use it's custom user attributes to provide metadata for setting up composable image processing shaders with minimal developer intervention, like shader toy or compute toy. The thing that is making this annoying is that the tooling is very bound to C++. Has anyone found a good rust wrapper for slang?


It's not just a spir-v frontend, it also transpiles to other shader languages.


Rusts current pretty printers in lldb and gdb are just not good enough for a fluid step debugging experience. I've had luck with intellij IDE's but it's very sad that the best we can do in a language with such good devex tooling is print debugging.

Theoretically you could generate debug scripts with a macro and embed them with

  #![debugger_visualizer(gdb_script_file = "../foo.py")]
but I haven't seen anyone go through the trouble.


The pretty printers seem to break from time to time as well with compiler updates: https://www.reddit.com/r/rust/comments/1f28akn/invalid_value...


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: