sagax has quit [Remote host closed the connection]
leavengood has joined #crystal-lang
ur5us has quit [Ping timeout: 240 seconds]
alex`` has quit [Quit: WeeChat 2.7]
alex` has joined #crystal-lang
alex` is now known as Guest66641
Guest66641 is now known as alex``
_ht has quit [Ping timeout: 246 seconds]
_ht has joined #crystal-lang
alex`` has quit [Quit: WeeChat 2.7]
alex` has joined #crystal-lang
alex` is now known as Guest2560
Guest2560 is now known as alex``
alex`` has quit [Client Quit]
alex`` has joined #crystal-lang
ancorgs has joined #crystal-lang
baweaver has joined #crystal-lang
<FromGitter>
<oren> how to open my vim editor from a crystal program. I wasn't sure what to google for so I googled for doing it in Ruby. The first result was a stackoverflow - `system("#{ENV['EDITOR']} 'yourfile.txt")`
alex`` has quit [Ping timeout: 268 seconds]
alex`` has joined #crystal-lang
sagax has joined #crystal-lang
<FromGitter>
<oren> i downloaded the crystal repo itself and trying to grep for various keywords. ..
<FromGitter>
<oren> so now that we got this working, what does all those line mean and how could I figure this out without your help?
<FromGitter>
<oren> I am asking this because I assume that other people will face this issue and we need to document it if we think this is important for future users
<FromGitter>
<Blacksmoke16> im not super familiar with the c binding stuff, but your block has too many arguments
<FromGitter>
<halfdan> The C function I'm trying to bind is ⏎ ⏎ > fun scan = hs_scan(db : HsDatabaseT, data : LibC::Char*, length : LibC::UInt, flags : LibC::UInt, scratch : HsScratchT, on_event : MatchEventHandler, context : Void*) : HsErrorT ⏎ ⏎ with MatchEventHandler defined as ... [https://gitter.im/crystal-lang/crystal?at=5e417ca8d4daaa26c195322f]
<FromGitter>
<Blacksmoke16> like normally you would have to yield each arg, like `yield id, from, to`
<FromGitter>
<kndt> does it have a builtin runtime scheduler or event loop like go or node?
<FromGitter>
<Blacksmoke16> id read that blog post, it goes into detail on the implementation and stuff
<FromGitter>
<kndt> in the post it seems you have to specify the amount of cores
<FromGitter>
<Blacksmoke16> the default is 4
<FromGitter>
<Blacksmoke16> > (Optionally specify the amount of workers thread as in CRYSTAL_WORKERS=4, by default is 4)
<FromGitter>
<kndt> for example the goruntime does multiplexes the async on several cores if needed
<FromGitter>
<Nicolab> @kndt ⏎ ⏎ > so it should be faster than go? ⏎ ⏎ I tested only multi-threaded channels, I observed better performance than Go. A significant difference in mono thread -> multi-threads gain, compared to Go mono thread -> multi-threads gain [https://gitter.im/crystal-lang/crystal?at=5e4180b3df1153705e280b75]
<FromGitter>
<Nicolab> Like Go, sometimes there's no point in putting in all the CPUs. I have better perfs with 3 threads than 8 (probably a contention with the mutex).
<FromGitter>
<kndt> @Nicolab many thanks from what you mention it seems crystal overall is more performant than go
<leavengood>
@halfdan: I looked more at your code and I believe the issue is because of the parenthesis Crystal thinks your block takes one parameter (the entire callback), not the 5 parameters of the callback.
<FromGitter>
<Daniel-Worrall> Seems the alpine docker isn't working with libxml
DTZUZU has joined #crystal-lang
<FromGitter>
<Nicolab> @kndt I didn't go into the details, but that's what I observe. Better multi-threads gain, better JSON serialization, better request processing (with Kemal compared to echo and Gin)
<FromGitter>
<Blacksmoke16> @Daniel-Worrall you can pass the flags manually
<FromGitter>
<Nicolab> @kndt Also the lack of generics or inheritance in Go forces to do freestyle (reflect, serialization, deserialization). With Crystal no need, it's well equipped out of the box. ⏎ ⏎ After all is not better, the compilation of Crystal is longer, the lack of support in VS code (no auto-completion, go to def, mouse-over doc, ...), forced to dig deep into projects in Github to understand how to do some basics
<FromGitter>
<j8r> @Blacksmoke16 I suppose it was not easy to implement handlers to be executed on a set of paths, for example an authentication handler to execute before all `/mypath` requests?
<FromGitter>
<Blacksmoke16> for athena?
<FromGitter>
<j8r> yes
<FromGitter>
<Blacksmoke16> mm cant say i thought about it
<FromGitter>
<Blacksmoke16> would be pretty easy to do, but nothing built in atm
<FromGitter>
<Blacksmoke16> like
<FromGitter>
<j8r> I think (for me) the only solution it to directly bind a Proc to the Node
<FromGitter>
<Blacksmoke16> each listener itself is responsible for knowing if it should act on a given event
blackbeard420 has joined #crystal-lang
<FromGitter>
<Blacksmoke16> another way would be to do something similar, but base it off a module you include in the controllers you want it to execute on
<sorcus>
Hi :-)
<FromGitter>
<Blacksmoke16> or even define an abstract controller that includes it that can then be inherited from
hpyc9 has joined #crystal-lang
<FromGitter>
<Blacksmoke16> im not familiar enough with your code to have a suggestion :/
<FromGitter>
<Blacksmoke16> whoa, not sure what im looking it
Human_G33k has quit [Ping timeout: 240 seconds]
<sorcus>
Blacksmoke16: He-he, it's a binary, opened in vim :-D
<FromGitter>
<mavu> did you compile with --release?
<FromGitter>
<mavu> I assume this is debug info?
<sorcus>
Blacksmoke16: I'm build a package for Archlinux and get warning "Package contains reference to $srcdir". This is because binary referenced to user directory...
<FromGitter>
<Blacksmoke16> what in code reference references the user dir?
<FromGitter>
<j8r> @Blacksmoke16 I was just wondering how you have done, thanks!
<FromGitter>
<HCLarsen> Hey folks, haven't been here in a while, I was just wondering if there's anything new about installing Crystal on a Raspberry Pi.
<FromGitter>
<Blacksmoke16> rgr, tl;dr i guess i didnt do it? kinda just leave it up to the user
<sorcus>
Blacksmoke16: Nothing. This path from YAML Mapping exception.
<FromGitter>
<HCLarsen> Last time I tried, there was an unofficial package, but I don't know if that's up to date.
<FromGitter>
<Blacksmoke16> i eventually want to implement some security related stuff, but TBD
* FromGitter
* tenebrousedge does not know anything about RPis
<sorcus>
Blacksmoke16: Exception rescued and show `Ooops`, but still referenced to user directory.
<FromGitter>
<Blacksmoke16> yea i dont have any ideas :/
<sorcus>
Blacksmoke16: I think it's a dead code, because rescue used at top level (if i understand correctly) and `Missing yaml attribute: foo` will never be called...
<sorcus>
Blacksmoke16: And this means that binaries, builded with crystal, can't be reproduceble.
<sorcus>
Blacksmoke16: Maybe it should be configured via compile-time flag?
<FromGitter>
<Blacksmoke16> no idea mate, maybe make an issue/forum post?
<sorcus>
Blacksmoke16: Yeah, maybe yes.
sagax has quit [Read error: Connection reset by peer]
<sorcus>
Blacksmoke16: Thank you for discussion. :-)
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<j8r> that's really too bad not to have interfaces for class methods :(
<FromGitter>
<Blacksmoke16> bump the issue 😉
<FromGitter>
<j8r> I'm finding alternatives
<FromGitter>
<Blacksmoke16> i mean couldnt you do like
<FromGitter>
<Blacksmoke16> raise an exception unless the child overrides it?
<FromGitter>
<j8r> maybe, but it will kind of already
<FromGitter>
<HCLarsen> @mavu that's almost 3 years old, does it still work?
<FromGitter>
<j8r> I'll just document it then
<FromGitter>
<Blacksmoke16> yea true, id just define them on the interface and document them there
sagax has joined #crystal-lang
<FromGitter>
<mavu> @HCLarsen I think so. you might need to change llvm versions or something, I don't remember. just try it. I think it will work.
<FromGitter>
<mavu> @HCLarsen you can skip the part about installing llvm3.9 or sth. unless you are building for a very old version, just use whatever you have on the PI. ⏎ (i think :) )
<FromGitter>
<HCLarsen> @mavu seems very complicated. Even Julien commented there about the difficulty of doing this.
<FromGitter>
<HCLarsen> I wonder if it may just be simpler to write my code on one machine, and cross compile for the Pi.
return0e_ has quit [Remote host closed the connection]
Human_G33k has quit [Ping timeout: 265 seconds]
return0e has joined #crystal-lang
_ht has quit [Remote host closed the connection]
<FromGitter>
<straight-shoota> Memory size can also be an issue on Raspberry Pi. Even for relatively small programs. Cross compilation is a good option as it works and when you set up a multistage build workflow once, there's not much hassle with it.
<sorcus>
straight-shoota: And what with my issue? Bur or feature? :-D
<sorcus>
*bug
<FromGitter>
<tenebrousedge> it's a featured bug! :D
<FromGitter>
<jwoertink> but what I was wondering is, aside from using `GC.stats`, is there a good way to track memory usage?
<FromGitter>
<jwoertink> My thought was we throw something at the start of a web request to log out how much memory is being used, then log out that thing at the end, and may track if there's a memory leak or something.
<FromGitter>
<jwoertink> I've never actually done anything like that, so not sure where to start in crystal
<sorcus>
Good night :-)
<FromGitter>
<Blacksmoke16> @jwoertink make it a http handler as the first one?
<FromGitter>
<jwoertink> Yeah, I can use a handler to wrap my stats logging, but how do I get the stats? (aside from GC.stats)
<FromGitter>
<jwoertink> or is using the GC like that the best way?
<FromGitter>
<636f7374> @jwoertink You can free memory manually.
<FromGitter>
<jwoertink> In my case, this page only takes about 160 requests to tank the app completely. If I spin up 160 requests and say hit this page at the same time, then it goes down
<FromGitter>
<jwoertink> Do I just tell the GC to run to free it manually?
<FromGitter>
<636f7374> @jwoertink Not using finalizer
<FromGitter>
<636f7374> Override finalizer, but can be dangerous but effective.
<FromGitter>
<jwoertink> I'm not sure what you mean. Is `finalizer` a method on something?
<FromGitter>
<636f7374> @jwoertink I use manual free memory in MITM server.
<FromGitter>
<636f7374> @jwoertink However, if you mishandled (improperly used) there may be hidden leaks, you must test your code multiple times.
<FromGitter>
<jwoertink> Yeah, I think there might be a leak, and I'm just trying to figure out how to confirm that
<FromGitter>
<Blacksmoke16> Htop?
<FromGitter>
<Blacksmoke16> And just watch usage of it as you make requests
<FromGitter>
<636f7374> Just like rust-lang
<FromGitter>
<636f7374> @jwoertink ```
<FromGitter>
<636f7374> @jwoertink ⏎ ⏎ *<RX14>* at least show me the composition of the heap by object type ⏎ *<RX14>* hopefully show me what's keeping each object alive ⏎ *<RX14>* and ideally show me where objects are being allocated in the source ... [https://gitter.im/crystal-lang/crystal?at=5e41ddb2cd2d737bb06d570f]
<FromGitter>
<jwoertink> well, giving up isn't an option here lol
<FromGitter>
<jwoertink> looks like htop isn't on these containers, but we have top. I ran that and see the memory used increases like you'd expect
<FromGitter>
<jwoertink> but then the app just becomes unresponsive
<FromGitter>
<watzon> You can always use valgrind to find memory leaks
<FromGitter>
<watzon> Not the easiest to figure out, but it works
<FromGitter>
<636f7374> @watzon ```
<FromGitter>
<jwoertink> I hadn't heard of that. Sounds neat though
<FromGitter>
<636f7374> @watzon ⏎ *<RX14>* but valgrind isn't a leak debugger ⏎ *<RX14>* to debug a memory leak you really need to know what objects are on the heap and where they come from ⏎ *<RX14>* no non-crystal-specific tool will be able to know what crystal type an allocation is ⏎ *<RX14>* even then surely all your tool would tell you was that all the memory was allocated by __crystal_malloc ...
<FromGitter>
<jwoertink> Ok, so it looks like we either have 2 major issues, or one issue is leading to the other. But the other one doesn't seem to be memory related
<FromGitter>
<jwoertink> We hit the app enough times and docker is like "yeah, your app is good", but the app doesn't take any request. It just sits there frozen
<FromGitter>
<636f7374> @jwoertink socket leak?
<FromGitter>
<636f7374> @jwoertink Most likely a socket leak, E.g. Too many open files
<FromGitter>
<636f7374> lsof -p pid
<FromGitter>
<watzon> Ahh yeah that could do it. If you're not closing files after you're finished with them.
<FromGitter>
<636f7374> sample pid -wait 10
<FromGitter>
<636f7374> I encountered multiple socket leaks while making a MITM server.
ur5us has joined #crystal-lang
<FromGitter>
<636f7374> So I think you should test / check it.
<FromGitter>
<jwoertink> ah. Actually a socket leak does sound familiar
<FromGitter>
<j8r> RX14 strange, it says on Wikipedia (https://en.wikipedia.org/wiki/Valgrind) ⏎ ⏎ > Valgrind (/ˈvælɡrɪnd/) is a programming tool for memory debugging, memory leak detection, and profiling.
<FromGitter>
<j8r> @jwoertink what does happen if the database closes the socket?
<FromGitter>
<j8r> also, does your other apps use TLS too?
<FromGitter>
<jwoertink> Not sure if it's the database socket, or like the web server sockets, but interesting thing is if we do a count on lsof for these PIDs, before the app tanks it's like 21
<FromGitter>
<jwoertink> but after the app tanks, it's like 333
<FromGitter>
<636f7374> The easiest way: lsof -p pid
<FromGitter>
<636f7374> ps ax | grep something
<FromGitter>
<j8r> what odes this app have that others don't?
<FromGitter>
<jwoertink> They all connect to the same database. The new one doesn't get as much traffic as the old one
<FromGitter>
<jwoertink> They all run on docker Ubuntu 18 whatever
<FromGitter>
<jwoertink> The old one is on crystal 0.29, and new one on 0.31.1
<FromGitter>
<jwoertink> all of them are Lucky apps. But the old one uses the clear shard, and the new one uses the avram shard. Though, both of those just wrap PG and crystal-db shards
<FromGitter>
<636f7374> Maybe some exception is thrown in some places, causing the socket to leak.
<FromGitter>
<jwoertink> DB is hosted on RDS, and apps are hosted on elasticbeanstalk with cloudfront in front of them. Nothing really crazy or overly complicated
<FromGitter>
<jwoertink> We were actually seeing `Errno Error reading socket: Bad file descriptor` quite a bit
<FromGitter>
<jwoertink> and `Errno Error writing to socket: Broken pipe `
<FromGitter>
<jwoertink> those are some of the larger count errors we get in bugsnag
<FromGitter>
<jwoertink> The older apps get the broken pipe all the time too, but that app never goes down