<FromGitter>
<mixflame> my scalablepress/paypal/gbaldraw integration is live
<FromGitter>
<mixflame> another store
<FromGitter>
<mixflame> you can order the collab canvas prints on shirts and other products now
<FromGitter>
<mixflame> https://gbaldraw.fun/ please bear in mind the content on the global/empty string room is user generated by anonymous users, apologies if you see anything triggering, if that's the case, please click the link on the right instead and create your own (infinitely lasting) private room
<FromGitter>
<mixflame> the global room is popular with free speech exhibitionists, please excuse me for that
<FromGitter>
<mixflame> running Amber on Crystal 1.0.0
<FromGitter>
<mixflame> ported from Rails 6/Ruby 3
<FromGitter>
<mixflame> (code is original and by me)
<FromGitter>
<mixflame> except in places where it's not
<postmodern>
didactic-drunk , cool i didn't know there was a crystal-posix project. I had to create https://github.com/postmodern/ioctl.cr to get access to the Linux kernel's specialized ioctls (v4l2).
<FromGitter>
<didactic-drunk> `crystal-posix` started when @chris-huxtable and I 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
<FromGitter>
... 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 somethin ... [https://gitter.im/crystal-lang/crystal?at=60c41ec3d855766185d1fc81]
<postmodern>
didactic-drunk, couldn't you do the standard {% if supported %} .. {% else %} {% error(...) %} pattern that C/C++ uses for compile time compatibility checks
<FromGitter>
<didactic-drunk> My message describes one example. I think we tried 3 or more different solutions but crystal would only accept "compiles everywhere, runs uncertainly". An example would be the windows `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
<FromGitter>
... 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).
<FromGitter>
<didactic-drunk> Also, how do you know what a supported platform is and should you need to know for every API. Feature checking with `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 shard can keep the same feature check without changing
<FromGitter>
... their code, just update to a new shard for new os support.
<postmodern>
hmm yeah, handling platform-specific code vs. platform agnostic code will eventually become a problem
<postmodern>
i guess shards may need to add a feature to specify that a shard only works on a certain platform
<FromGitter>
<didactic-drunk> The mutual conclusion is platform specific code will go in shards. They won't take platform specific code and we can't make certain types of programs without them. Like `ioctl`
<postmodern>
once windows support get's finalized, i wouldn't be surprised if we see a cyrstal-windows github org, for crystal shards that access private Windows APIs and libraries.
postmodern has quit [Quit: Leaving]
dom96 has quit [Ping timeout: 252 seconds]
dom96 has joined #crystal-lang
<FromGitter>
<oprypin:matrix.org> @mattrberry: could you point out to me that project that I wanted to add Windows support to? and is it in a good working shape as is?
<FromGitter>
<mattrb:matrix.org> It currently builds on Linux with just a `shards build` because I set the rpath in the link flags in the backends library :p
<FromGitter>
<didactic-drunk> @oprypin:matrix.org Are you testing windows gh actions integration?
<FromGitter>
<oprypin:matrix.org> @didactic-drunk: well not really testing, i know it works
<FromGitter>
<didactic-drunk> @oprypin:matrix.org I'd like to get sodium (https://github.com/didactic-drunk/sodium.cr) on windows, but it uses shell scripts to download & build libsodium. If you have recommendations I'll take them
<FromGitter>
<didactic-drunk> Downloading on windows? How to handle multiple platforms in `shard.yaml - postinstall`?
<FromGitter>
<tenebrousedge> sup y'all
deavmi has quit [Ping timeout: 268 seconds]
deavmi has joined #crystal-lang
postmodern has joined #crystal-lang
<FromGitter>
<oprypin:matrix.org> > It currently builds on Linux with just a `shards build` because 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.
<FromGitter>
<oprypin:matrix.org> anyway.. I'll get around to this tomorrow. today i kinda disappeared