<FromGitter>
<mattrberry> 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?
<FromGitter>
<mattrberry> Maybe I'm missing something, but I don't see a harm in setting it?
<FromGitter>
<tenebrousedge> the second one overwrites the first
<FromGitter>
<mattrberry> Yeah that makes sense, that was my suspicion. I don't know how I'd actually expect it to work if not like this tbh haha
<FromGitter>
<oprypin:matrix.org> > 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
<FromGitter>
... 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 agai ... [https://gitter.im/crystal-lang/crystal?at=60c56c7c3169e2349861fd8a]
<FromGitter>
<oprypin:matrix.org> mattrberry (Matthew Berry)(looks like I didn't properly tag you, trying it again)
<FromGitter>
<oprypin> agh tagging you didn't work properly. trying again. @mattrberry
postmodern has quit [Remote host closed the connection]
<FromGitter>
<oprypin:matrix.org> if you still want to hardcode this addition in source code, that's ok, but it should be done in the main executable's source code. can be done as such, I'm pretty sure: ⏎ ⏎ ```@[Link(ldflags: "-Wl,-rpath .")] ⏎ lib Garbage ⏎ end``` [https://gitter.im/crystal-lang/crystal?at=60c56e838681550d4ee8f16e]
<FromGitter>
<oprypin:matrix.org> and that can't be applied on Windows, of course
postmodern has joined #crystal-lang
postmodern has quit [Quit: Leaving]
<FromGitter>
<oprypin:matrix.org> @didactic-drunk: well, building a whole C library in your postinstall *is* the problem
<FromGitter>
<oprypin:matrix.org> i don't know really... I don't have a verdict on what's "wrong" to do in postinstall, but indeed a cross-platform postinstall is near-impossible to achieve at the moment
<FromGitter>
<mattrberry> @oprypin Maybe I’m just being naive? I figure since they’re already building my code, they’re trusting that the code I’ve written isn’t malicious. What makes me setting the rpath any more dangerous since they’re already building my code anyway?
<FromGitter>
<oprypin:matrix.org> @mattrberry: that wasn't really my point. let's say i want to use your "crystal-imgui-backends". i don't want my executable to have a tweaked rpath. i have no options to solve that.
<FromGitter>
<mattrberry> What’s the harm in the tweaked rpath though? And couldn’t they set it in their own application as well to override, in theory if they really wanted to? I’m not trying to argue btw, maybe I’m just missing something?
<FromGitter>
<oprypin:matrix.org> @mattrberry: awh the external libs are too numerous, i couldn't handle it :( i think i'm giving up on the Windows stuff
<FromGitter>
<oprypin:matrix.org> ultimately the problem here is that for my Windows usages I did not rely on Makefile at all, but here it would be way too much work to rework it to a separate script ⏎ compared to https://github.com/oprypin/crystal-imgui-sfml/blob/master/make.cmd
<FromGitter>
<mattrberry> @oprypin Ahh no worries, well thank you tons for starting on it at least!!
<FromGitter>
<mattrb:matrix.org> Ah now we’re getting even further into the realm that I know absolutely nothing about :/ Are those just two different c++ compilers for windows? I’ll be able to grab my laptop in a couple hours to look a little deeper too, although I don’t have windows there either :/
<FromGitter>
<oprypin:matrix.org> Matthew Berry (https://matrix.to/#/@mattrb:matrix.org): yeah they are. cl.exe is by Microsoft, where as MinGW is a collection of ports of POSIX tools to Windows; they end up being partly in an emulated environment or something weird
<FromGitter>
<oprypin:matrix.org> so yeah this is quite ugly and way harder than i made it seem
<FromGitter>
<mattrb:matrix.org> Ah, well again thank you tons for taking a look!! Maybe someday it’ll be easier to port :) Appreciate you trying :)
<FromGitter>
<didactic-drunk> @oprypin:matrix.org Attempting to improve UX (developer experience DX, is that thing?). There are 3 unix use cases. 1) Building a rpm/deb package (or personal executable) that relies on the distribution packaged libraries. 2) Building a run on any distro binary that can't rely on a system installed libsodium. 3) Same as 1 but the system libsodium is ancient and can't be used (This is very common).
<FromGitter>
... The build scripts check the system version (but allow overrides) and them by default if new enough otherwise download and build the version tested with sodium.cr. None of this is a concern for windows which never has a packaged libsodium
<FromGitter>
<didactic-drunk> @oprypin:matrix.org `shards install` takes care of everything unless you want to override a value provides the best DX even if the build script is more complex. I doubt I'd have half as many users if it required: manually check your distro version. If it's >= x `install` else download and build it yourself.
<FromGitter>
<oprypin:matrix.org> i see. well, maybe my main dissatisfaction comes from how rigid postinstall is. any tiniest problem and everything just bails out
<FromGitter>
<oprypin:matrix.org> and you're basically taking on a task of maintaining a fully universal build of a lib.
<FromGitter>
<didactic-drunk> Yes. If only `postinstall` allowed ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ And tried keys in order of most specific to less specific arch trying `posix-default` or `windows-default` last. [https://gitter.im/crystal-lang/crystal?at=60c64470b346e9618bcc919c]
<FromGitter>
<oprypin:matrix.org> @didactic-drunk: well it looks like you're already miles ahead of the rest in terms of thinking this through. I'd support this
<yxhuvud>
i could see platform dependent dependencies too.
<FromGitter>
<grkek> I am a bit inactive here sorry guys
<FromGitter>
<grkek> How have you all been?
<FromGitter>
<tenebrousedge> this "life" thing is pretty weird, imo
<FromGitter>
<grkek> What life thing?
<FromGitter>
<tenebrousedge> all of it, but particularly the bits that concern me
<FromGitter>
<tenebrousedge> so if I fail to get a dev role, but the CEO wants me to interview for a data engineer role because they "think I can pick it up quickly", how should I prepare for an interview for that?
<FromGitter>
<jrei:matrix.org> for a internal promotion? Or CEO suppose you'll interview someone for free?
<FromGitter>
<tenebrousedge> neither? I think you misread
<yxhuvud>
i have never in my life prepared for an interview except for a quick browse of the company web pages. *shrug*
<FromGitter>
<jrei:matrix.org> I didn't understood then
<FromGitter>
<grkek> Life doesn't really matter, be good to everyone and do what you like to do and just pass away in peace
<FromGitter>
<grkek> Thats all of it
<FromGitter>
<grkek> Other things are useless distractions which were forced upon you for torture
<FromGitter>
<grkek> @yxhuvud Same!
<FromGitter>
<jrei:matrix.org> by preparing, you also mean some exercises they want you to do before the interview?
<FromGitter>
<grkek> Nah, just an interview
<FromGitter>
<grkek> If they plan on doing some exercises I just say
<FromGitter>
<tenebrousedge> I mean I have only a loose idea of what a "data engineer" does, and don't know what I'm going to be expected to know
<FromGitter>
<grkek> Send it over the E-Mail and Ill send it over to you once done
<FromGitter>
<jrei:matrix.org> Pretty sure they have an even looser idea of why they want a "data engineer"
<FromGitter>
<jrei:matrix.org> the solution can just be to have a precise job sheet
<yxhuvud>
jrei: no, if they want me to solve a reasonably sized problem that is fine. that is different
<FromGitter>
<didactic-drunk> @oprypin:matrix.org I have a few shards (example (https://github.com/crystal-posix/mmap.cr)) that run on limited platforms. Some are POSIX only. One is OpenBSD only. Future ones may be window only. What say you of 2 additional options for shard.yaml ⏎ ⏎ A platform flag. If it matches the shard is included. If not the shard is automatically pruned. ⏎ ⏎ ```code paste, see link``` ...
<FromGitter>
<oprypin:matrix.org> @didactic-drunk: it's funny that you're against specifying crystal <2.0 but for specifying unsupported platforms. i guess the difference is that in most cases the author *does* actually know it won't work on those platforms. however, consider a large number of shards that exist now, -- how often would people be tempted to specify "nope doesnt work on Windows" and then eventually that specification
<FromGitter>
... will be the only actual reason why it doesn't work on Windows
<FromGitter>
<didactic-drunk> @oprypin:matrix.org I'd be against specifying !any_platform_unless_the_api_is_broken_or_doesn't_exist
<FromGitter>
<oprypin:matrix.org> uh sorry I didn't understand that. there are like 4 negations there
<FromGitter>
<didactic-drunk> @oprypin:matrix.org Here's what I have planned (yes a real example). 1) Create mmap (done) which can be used for anonymous memory or mapping a file or a few other uses with `platform: posix`. Create a windows anonymous memory shard (No mmap equivalent that handles all functions) with `platform: windows`. Create a generic anon memory wrapper shard that includes both. Create a guard page key holding
<FromGitter>
... shard similar to `sodium_malloc` using the anon memory shard.
<FromGitter>
<oprypin:matrix.org> well the first three could be just one shard. but that's only for your particular example
<FromGitter>
<oprypin:matrix.org> there are very many missing features but it seems that for most of the parts of the specification you can't just go adding features onto the existing spec, perhaps a greater overall look at the design would be better
<FromGitter>
<didactic-drunk> I'm against < crystal 2 because it's a guess, probably false and breaks applications for no apparent reason when 2.0.0 is released or forces them to upgrade which may involve API changes or other unpleasantries
<FromGitter>
<oprypin:matrix.org> I am not convinced of any particular approach at the moment and sorry I won't dive into that topic
<FromGitter>
<oprypin:matrix.org> I just felt that the postinstall thing in particular would be not controversial
<FromGitter>
<didactic-drunk> The platform flag would be limited use. See the inotify example. Btw this is also based on a real example from ruby gems.
<FromGitter>
<didactic-drunk> While I *could* make one shard I'd prefer not to. I don't want to maintain the windows version. I *may* make a windows version if no one else does. Also, platform specific features are sometimes needed (mmap in particular). The anon memory wrapper and guard pages need simple functionality that both platforms support. If I were doing something else with `mmap` like mapping a file, I can't do that on
<FromGitter>
... windows as it uses a completely different API
<FromGitter>
<didactic-drunk> Which I don't intend to wrap
<FromGitter>
<didactic-drunk> @oprypin:matrix.org Shortened answer. `platform` as a restriction wouldn't be used with pure portable crystal shards, only platform specific shards. `platform` as a dependency may be specified to override. See the inotify example. Generic file polling may work everywhere but on linux you may prefer `inotify`. On BSD eventually `kqueue`. Although technically those should have their own platform
<FromGitter>
... limitations so the dependency limit should only be placed on generic file polling.
<FromGitter>
<didactic-drunk> I guess that wasn't a shortened answer
fifr[m] has joined #crystal-lang
jhass[m] has quit [Remote host closed the connection]
fifr[m] has quit [Remote host closed the connection]
jhass[m] has joined #crystal-lang
dom96 has quit [Ping timeout: 252 seconds]
Vexatos has joined #crystal-lang
fifr[m] has joined #crystal-lang
[RMS] has joined #crystal-lang
dom96 has joined #crystal-lang
jcs_ has joined #crystal-lang
^raz^ has joined #crystal-lang
Vexatos_ has quit [Quit: Client Quit]
jcs has quit [Ping timeout: 264 seconds]
raz has quit [Ping timeout: 264 seconds]
[R] has quit [Read error: Connection reset by peer]