The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
#gets on the stdout pipe. however, as soon as this fiber is part of my multi-fiber application, the other fibers seem to be blocked too
crystal-posix started when @chris-huxtable and I had design differences with the core team. Sometimes we need native types exposed rather than Int32 everywhere. The largest disagreement was on compile time vs runtime safety. @astterite wants everything to compile cross platform without macros or if respond_to? checks. An acceptable workaround to him is platform_specific_method may raise an error on an unsupported platform (but it still compiles - I haven't figured out why that matters if it doesn't work). We've chosen
{% if supported_platform %}
def platform_specific_method
{% end %}Then letting the code break when compiling if you don't check with respond_to. This let's you know something will or won't work when compiling rather than having random breakage you may or may not test for.
sid. Process.sid should work on windows only. With the official crystal way it's a runtime error when called. With our if you call it on a non windows system the program won't compile. I think that fits better with the crystal philosophy of "Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime." (taken from crystals web page).
respond_to allows for future proofing. Example: Linux supports open45, later FreeBSD adds support, and finally Mac/OS 15 years later. The shard wrapping open45 can add os support incrementally while every crystal program using the shard can keep the same feature check without changing their code, just update to a new shard for new os support.
It’s currently in working condition on Linux, but breaking on Mac because I didn’t link opengl properly in the imgui backends package https://github.com/mattrberry/crystal-imgui-backends
shards build because I set the rpath in the link flags in the backends library :p
It currently builds on Linux with just a
shards buildbecause I set the rpath in the link flags in the backends library :p
ow.. that's what i said shouldn't be done. it's really hostile.
self.new in SDLOpenGLImGuiFrontend to be called
What makes that really hostile? Isn't that just adding an extra path for it to check at link time? If it doesn't find it in that path, then you can always just pass the link flags directly to shards build still, right?
Matthew Berry how can you say that that flag is supposed to check something at link time, if exactly that is already the job of the -L flag?
writing -rpath . has a very simple effect: append the value . to the "rpath" field of the final ELF executable (empty by default). so you're saying: "if you use my library, you must accept a custom and rare value of rpath for your executable." then, what is done at run time with that field is to check those paths for libraries that were linked against and use them. I'd (strongly) say that it should be up to the developer of the executable to decide that allowing overrides of any referenced lib from current directory is ok. it works only for particular models of deployment and is a question of security as well.
