deavmi has quit [Remote host closed the connection]
deavmi has joined #crystal-lang
Guest33 has joined #crystal-lang
Guest55 has joined #crystal-lang
Guest55 has quit [Client Quit]
Guest33 has quit [Ping timeout: 250 seconds]
Guest74 has joined #crystal-lang
Guest74 has quit [Client Quit]
Guest4825 has joined #crystal-lang
Guest4825 has quit [Client Quit]
arestifo has joined #crystal-lang
jhass[m] has quit [Quit: Reconnecting]
jhass[m] has joined #crystal-lang
postmodern has quit [Quit: Leaving]
Guest80 has joined #crystal-lang
Guest80 has quit [Client Quit]
hholst6543 has joined #crystal-lang
<FromGitter>
<rishavs> Do we have any blog/site where all the top Crystal news for the week are displayed? I remember there used to be one years ago, but cannot find it now. ⏎ Here's something that F# folks do ⏎ https://sergeytihon.com/category/f-weekly/
hholst6543 has quit [Quit: Ping timeout (120 seconds)]
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arestifo has joined #crystal-lang
hholst6543 has joined #crystal-lang
<hholst6543>
I am looking for some more advanced Spec test suites that uses say exceptions, before/after, context. Can you recommend a repo that features those?
<FromGitter>
<Blacksmoke16> hholst6543: what do you need examples of? Aren't they kinda straight forward? `context` is the same as `describe`. before/after hooks are just like ⏎ ⏎ ```before_each do ⏎ puts "foo" ⏎ end``` ⏎ ⏎ and exception handling can be done via https://crystal-lang.org/api/master/Spec/Expectations.html#expect_raises(klass:T.class,message:String|Regex|Nil=nil
<hholst6543>
I guess I have to call add_to_radix_tree directly
<FromGitter>
<Blacksmoke16> depending on your use case are other frameworks you could use :shrug: Or maybe at the least create a feature request for kemal
<hholst6543>
and file an Issue ;-)
<hholst6543>
using HEAD just to fetch the HTTP status code is common for monitoring
<hholst6543>
the monitor dont care abou the payload only the status
<hholst6543>
but also, the GET can return any kind of status code, so its a weird assumption that the HEAD call always returns a 200
<hholst6543>
at least it should return the same headers as the exact same GET call would
<hholst6543>
without the payload (and content* headers)
<FromGitter>
<Blacksmoke16> rfc says it should be identical, just w/o the payload
<FromGitter>
<RespiteSage> I'm not familiar with libmagic, and I'm not entirely clear after some web searching, but does it guess file types from the contents?
<FromGitter>
<RespiteSage> Yeah. I'm not I Ruby dev, so I first heard of that when I started using Crystal, and the term always helped me remember to avoid it.
<FromGitter>
<RespiteSage> Still, it's very useful in specific situations.
<FromGitter>
<me:ky.rs> Monkey Patching is awesome and I love its inclusion, you can do some wild stuff with it. But as it was pointed out, it gives headroom to lots of, say, unwanted paradigms. Like when I included macros in `Object` for my project :P
Guest89 has joined #crystal-lang
Guest89 has quit [Client Quit]
greenbigfrog has quit [Quit: Connection closed]
Guest60 has joined #crystal-lang
Guest60 has quit [Client Quit]
greenbigfrog has joined #crystal-lang
<FromGitter>
<mattrberry> Currently my library requires the use of the LD_LIBRARY_FLAGS environment variable to link a shared library at runtime. However, this shared library is always at the same place. Is there a way to tell Crystal where to look for that so that I don’t have to have the user set the environment variable or add it to their libs?
<FromGitter>
<oprypin:matrix.org> @mattrberry: oh sorry i remember you had tagged me about this. for compile time this is the solution: https://github.com/oprypin/crystal-imgui-sfml/blob/c9c1791318801f00ce1a83d68e9edd14d473d504/src/lib.cr#L3 ⏎ for run time i believe this *shouldn't* be solved. (although some trick specific to `crystal run` would be nice but i don't know one). developers should deploy the resulting binary with a
<FromGitter>
<mattrberry> @oprypin:matrix.org No worries, thanks for remembering! That was what I thought and I *feel* like it was working before, but I'm having a little trouble now. For example: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Any idea what I'm doing wrong here? [https://gitter.im/crystal-lang/crystal?at=60bfe8e19cc69444a02a17bd]
<FromGitter>
<oprypin:matrix.org> @mattrberry: yes running it doesn't work and I'm saying that that is the right behavior
<FromGitter>
<oprypin:matrix.org> how would people ship the executable to anyone if you hardcoded the absolute path to it into the executable
<FromGitter>
<mattrberry> Oh gotcha, I misunderstood your message
<FromGitter>
<mattrberry> So the expectation is that as long as cimgui is building as a shared object, we'll need to explicitly do something like set LD_LIBRARY_PATH
<FromGitter>
<oprypin:matrix.org> yes i think so
<FromGitter>
<mattrberry> I see that cimgui has an option to just build to a normal object file. Maybe I'll give that a shot for now. Either way I look at it atm, people are still going to have to build from source. I'm not distributing the executable beyond that, at least for now
<FromGitter>
<mattrberry> Did you look at that at all?
<FromGitter>
<oprypin:matrix.org> wait-- look at what?
<FromGitter>
<mattrberry> Building cimgui just as an object rather than a shared object, then linking it directly at compile-time
<FromGitter>
<oprypin:matrix.org> ah. i think it would work just fine. haven't given it much attention though
<FromGitter>
<oprypin:matrix.org> my preference is to deploy with shared library files
<FromGitter>
<mattrberry> Ah no worries, just figured I'd ask in case you'd already tried that and had trouble. Maybe I'll give that a shot this evening then. Key reason is just that when people build/run my emulator, I don't want them to have to set any environment variables or anything. I'd really like it to just be a `shards build` and run with nothing further
<FromGitter>
<oprypin:matrix.org> you can solve it on the emulator's side. make a makefile that plucks the library into the same folder as the executable
<FromGitter>
<oprypin:matrix.org> and, despite me saying that this shouldn't be solved in the library, it can certainly be solved on the side of the final binary's build
<FromGitter>
<oprypin:matrix.org> `-Wl,-rpath .` as linker flag might just make it work
<FromGitter>
<oprypin:matrix.org> depending on how hacky it can be, maybe you can do `-Wl,-rpath $ORIGIN/../lib/stuff` and then no extra build step is required
<FromGitter>
<oprypin:matrix.org> i have not tried this though
<FromGitter>
<oprypin:matrix.org> 1) regarding Windows: it really just wants you to put the DLL into the same directory as the executable. and that always works by default
<FromGitter>
<mattrberry> Building the emulator with `shards build --progress --link-flags='-Wl,-rpath .'` and the experimentation branch of crystal-imgui-backends seems to work without setting LD_LIBRARY_PATH since `make shard` in the lib also adds a symlink to cimgui.so in the project root
<FromGitter>
<mattrberry> Is there a way to configure link flags in the shard.yml so that they don't need to be passed as args? Doesn't seem like it looking at the spec
<FromGitter>
<mattrberry> As for windows, I haven't really put thought into windows yet. I know absolutely nothing about dev on windows, so I've pushed that off until crystal gets solid support on windows at least. Do you think it'd be possible to get this running on windows? I know you've mentioned something about that in the past
<FromGitter>
<oprypin:matrix.org> @mattrberry: yeah there's a good chance t that Windows will just work out of the box
<FromGitter>
<mattrb:matrix.org> I have zero experience with windows dev. I imagine it’d run in wsl, but would the graphical part work?
<FromGitter>
<mattrb:matrix.org> Or is there some way to run it outside of wsl?
<FromGitter>
<oprypin:matrix.org> why wsl? no, it just works
<FromGitter>
<oprypin:matrix.org> anyway when you're ready i can hook you up. i have a full Windows build of a game already but it's not public
<FromGitter>
<oprypin:matrix.org> it can build on GitHub Actions so you don't actually need Windows. that is if there are no crazy crashes out of nowhere
<FromGitter>
<mattrb:matrix.org> Oh so do you just cross compile for windows then, and as long as I can have it link properly then it should be good to go?
<FromGitter>
<mattrb:matrix.org> That’s awesome
<FromGitter>
<oprypin:matrix.org> not cross compile even :D ⏎ it's 100% native Windows
<FromGitter>
<oprypin:matrix.org> Crystal compiler runs on Windows fully
<FromGitter>
<mattrb:matrix.org> I still need to put in a couple more hours of work this afternoon, but I’d definitely be interested in getting it building for windows. I have a couple friends who would be able to test some games in my emulator but they only use windows
<FromGitter>
<mattrb:matrix.org> Oh wow I hadn’t realized that. Where would I pick up a copy of the crystal compiler for windows? I didn’t see it on the installation page
<FromGitter>
<oprypin:matrix.org> you can put link flags before a `lib` definition in source code (well, you're already doing it in one place) but it's not a very clean approach
<FromGitter>
<oprypin:matrix.org> Matthew Berry (https://matrix.to/#/@mattrb:matrix.org): there's no build because 1) despite the compiler working, only a tiny subset of programs can work 2) when I wanted to work on publishing a build, i got kinda ignored
greenbigfrog has quit [Ping timeout: 250 seconds]
<FromGitter>
<mattrb:matrix.org> So in order to build on windows, the best option would still be to cross-compile then, right?
<FromGitter>
<oprypin:matrix.org> https://github.com/oprypin/install-crystal puts together a working env from several different parts. that's the only automatic way but it's specific to GitHub Actions
<FromGitter>
<oprypin:matrix.org> cross-compile doesn't win you much because you still need all those dependency libraries and you need to link on Windows
<FromGitter>
<oprypin:matrix.org> so might as well also compile on Windows
<FromGitter>
<mattrb:matrix.org> Awesome, that’s a nice YouTube video
<FromGitter>
<mattrb:matrix.org> I think I’ll mess around with it a bit more this evening then once I get some of the imgui frontend working
<FromGitter>
<mattrb:matrix.org> I don’t know the structure of windows exe files. Once that’s built, is everything packaged in there and statically linked, or will I need to install the dependencies wherever I bring the exe? I assume the latter?
<FromGitter>
<oprypin:matrix.org> Matthew Berry (https://matrix.to/#/@mattrb:matrix.org): windows has .lib files that are like object files. and it had .dll files which are like shared libs
<FromGitter>
<oprypin:matrix.org> with a nice difference that it can implicitly pick up .lib files and link them without needing custom flags
<FromGitter>
<oprypin:matrix.org> Matthew Berry (https://matrix.to/#/@mattrb:matrix.org): i would like to help, so you don't need to waste time on all those pitfalls
<FromGitter>
<oprypin:matrix.org> regarding the final result it's the same or even better than on Linux. just the exe and your dlls if any.
<FromGitter>
<mattrb:matrix.org> Thanks so much, I appreciate all the help. I imagine I’ll have lots of questions about windows too haha
<FromGitter>
<mattrb:matrix.org> Also PRs are 100% welcome too if you’d like to help in that way as well. I eventually want to make a post about this emulator so that it gets more users, since that’ll hopefully be a good way to get more bug reports. There are a couple things I want to add first to make it more useable (like an ImGui frontend), and windows support would definitely help with that too
<FromGitter>
<oprypin:matrix.org> yeah a PR it will be. ⏎ and poke me if I forget
<FromGitter>
<mattrb:matrix.org> Thanks so much :)