ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
Guest33 has joined #crystal-lang
Guest3 has joined #crystal-lang
Guest3 has quit [Client Quit]
Guest33 has quit [Ping timeout: 250 seconds]
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 ⏎
hholst6543 has quit [Quit: Ping timeout (120 seconds)]
<FromGitter> <> There's the news category in the forum: There's the subreddit: and there's
<FromGitter> <rishavs> Thanks !
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> <rishavs> Is there a shorter and cleaner way to write ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ where result1[:banned_till] can be a String or Nil? []
<FromGitter> <naqvis> `result1[:banned_till].try &.< Time.utc`
<FromGitter> <rishavs> ❤️
<FromGitter> <naqvis> but above assume `result1` contain that `:banned_till`
<FromGitter> <rishavs> thats fine. I always return that key
<FromGitter> <naqvis> 👍
dostoyevsky2 has quit [Ping timeout: 264 seconds]
dostoyevsky2 has joined #crystal-lang
dostoyevsky2 has quit [Ping timeout: 258 seconds]
dostoyevsky2 has joined #crystal-lang
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arestifo has joined #crystal-lang
arestifo has quit [Client Quit]
arestifo has joined #crystal-lang
hholst6543 has quit [Quit: Client closed]
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<straight-shoota> yxhuvud even with just adding a couple print_error, the socket specs mysteriously start to pass:
<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,message:String|Regex|Nil=nil
<FromGitter> ... ,file=__FILE__,line=__LINE__,&)forallT-instance-method []
Guest33 has joined #crystal-lang
Guest33 has quit [Client Quit]
arestifo has joined #crystal-lang
hholst6543 has joined #crystal-lang
<yxhuvud> straight-shoota: hah. yeah, event loops is kinda like heisenbergs uncertainty principle, observing what happens changes stuff.
<straight-shoota> but... it's still not about the event loop
<hholst6543> jhass I see that the build system for Crystal on Travis does not work
<straight-shoota> it's probably best to forget travis
<hholst6543> why?
<hholst6543> its still included in the template app / lib
<jhass[m]> hholst6543: unfortunately they're ignoring us / Travis is a sinking ship, best to migrate off of it
<jhass[m]> they got bought a while back and >80% of the original staff left
<hholst6543> I recommend that v1.0.1 removes the .travis template stuff
<jhass[m]> yeah, we need to desperately get rid of that
<yxhuvud> straight-shoota: close enough.
<hholst6543> same thing happened with Docker
<hholst6543> its a hollow ship these days
jhass[m] has quit [Remote host closed the connection]
jhass[m] has joined #crystal-lang
hholst6543 has quit [Quit: Ping timeout (120 seconds)]
<FromGitter> <> I didn't know that. They still have a huge foothold in software distribution. 🤔
wmoxam has quit [*.net *.split]
wmoxam has joined #crystal-lang
<riza> the staff was _laid off_
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arestifo has joined #crystal-lang
arestifo has quit [Client Quit]
hholst6543 has joined #crystal-lang
<hholst6543> Is it possible to define a handler for HEAD HTTP verbs in Kemal?
<FromGitter> <Blacksmoke16> does it not create one for you?
<FromGitter> <Blacksmoke16> or do you want to do custom logic in it?
<hholst6543> it creates a meta head handler
<hholst6543> which always returns 200
<hholst6543> but I want to return the same code as the underlying GET method
<hholst6543> and that only returns 200 if a rest call works (to docker)
<FromGitter> <Blacksmoke16> ⏎ ⏎ Might be able to just manually define the method that macro does tho
<FromGitter> <renich_gitlab> Hello! o/ ⏎ ⏎ I'm trying to do this: ⏎ ⏎ I'd appreciate some guidance. ... []
<FromGitter> <Blacksmoke16> do you just want to count the occurrences of each char?
<FromGitter> <renich_gitlab> @Blacksmoke16 yes.
<FromGitter> <renich_gitlab> Trying to learn the crystal dialect.
<FromGitter> <Blacksmoke16>
<FromGitter> <renich_gitlab> hah!
<FromGitter> <renich_gitlab> Awesome!
<FromGitter> <renich_gitlab> Thank you, @Blacksmoke16
<FromGitter> <Blacksmoke16> np
<hholst6543> this looked quite promising
<hholst6543> but no,
<hholst6543> Unhandled exception: Duplicate trail found 'head/:id' (Radix::Tree::DuplicateError)
<FromGitter> <Blacksmoke16> ahh yea, need a way to override the default one
<hholst6543> thats an evil line
<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
krma has quit [Quit: Lost terminal]
<FromGitter> <naqvis> Just published ( Crystal bindings to *libmagic*
hholst6543 has quit [Ping timeout: 250 seconds]
<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: yes
hholst6543 has joined #crystal-lang
<FromGitter> <RespiteSage> Cool!
avane has quit [Ping timeout: 244 seconds]
<hholst6543> "Private method" STRIKES AGAIN. OOP is the bane of all sensible things
<FromGitter> <Blacksmoke16> heh
<FromGitter> <Blacksmoke16> fun fact, in crystal land you can just reopen the method to make it public 🙈
<hholst6543> mm, the idea to call to the low level did obviously not work then
<hholst6543> reopen?
<FromGitter> <Blacksmoke16> not that i would suggest that tho
<hholst6543> I'd like to glue one method on the base class that does the special logic, can I do that without having to vendor upstream lib?
<FromGitter> <Blacksmoke16> ```class SomeClassDefinedSomewhereElse ⏎ def foo ⏎ "foo ⏎ end ⏎ end``` []
<hholst6543> ohh. this is so evil. I like it thanks :)
<FromGitter> <Blacksmoke16> yea..try not to abuse it...
greenbigfrog has joined #crystal-lang
avane has joined #crystal-lang
hholst6543 has quit [Quit: Client closed]
<FromGitter> <RespiteSage> That's "monkey patching", right?
<FromGitter> <Blacksmoke16> yea
<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> <> 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> <> @mattrberry: oh sorry i remember you had tagged me about this. for compile time this is the solution: ⏎ 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> ... modification to the library search path - either a shell script or by modifying the executable with rpath $ORIGIN
<greenbigfrog> Have you looked at ? Not sure it's of any help
<FromGitter> <mattrberry> 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? []
<FromGitter> <> @mattrberry: yes running it doesn't work and I'm saying that that is the right behavior
<FromGitter> <> 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> <> 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> <> 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> <> ah. i think it would work just fine. haven't given it much attention though
<FromGitter> <> 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> <> you can solve it on the emulator's side. make a makefile that plucks the library into the same folder as the executable
<FromGitter> <> 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> <> `-Wl,-rpath .` as linker flag might just make it work
<FromGitter> <> 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> <> i have not tried this though
<FromGitter> <> 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 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> <> @mattrberry: yeah there's a good chance t that Windows will just work out of the box
<FromGitter> <> I have zero experience with windows dev. I imagine it’d run in wsl, but would the graphical part work?
<FromGitter> <> Or is there some way to run it outside of wsl?
<FromGitter> <> why wsl? no, it just works
<FromGitter> <> assuming u can build a lib of cimgui first
<FromGitter> <> 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> <> 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> <> 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> <> That’s awesome
<FromGitter> <> not cross compile even :D ⏎ it's 100% native Windows
<FromGitter> <> Crystal compiler runs on Windows fully
<FromGitter> <> 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> <> 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> <> 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> <> Matthew Berry ( 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> <> So in order to build on windows, the best option would still be to cross-compile then, right?
<FromGitter> <> puts together a working env from several different parts. that's the only automatic way but it's specific to GitHub Actions
<FromGitter> <> is the manual setup
<FromGitter> <> cross-compile doesn't win you much because you still need all those dependency libraries and you need to link on Windows
<FromGitter> <> so might as well also compile on Windows
<FromGitter> <> Awesome, that’s a nice YouTube video
<FromGitter> <> I think I’ll mess around with it a bit more this evening then once I get some of the imgui frontend working
<FromGitter> <> 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> <> Matthew Berry ( windows has .lib files that are like object files. and it had .dll files which are like shared libs
<FromGitter> <> with a nice difference that it can implicitly pick up .lib files and link them without needing custom flags
<FromGitter> <> Matthew Berry ( i would like to help, so you don't need to waste time on all those pitfalls
<FromGitter> <> Oh nice, that’s convenient
<FromGitter> <> regarding the final result it's the same or even better than on Linux. just the exe and your dlls if any.
<FromGitter> <> Thanks so much, I appreciate all the help. I imagine I’ll have lots of questions about windows too haha
<FromGitter> <> 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> <> yeah a PR it will be. ⏎ and poke me if I forget
<FromGitter> <> Thanks so much :)