<FromGitter>
<drosehn> when people here mention `sth`, what does that refer to? I hope it isn't some Sith overlord.
Raimondi has quit [Write error: Broken pipe]
Raimondi has joined #crystal-lang
balduin has joined #crystal-lang
balduin has quit [Client Quit]
zipR4ND1 has quit [Ping timeout: 260 seconds]
balduin has joined #crystal-lang
balduin has quit [Client Quit]
_whitelogger has joined #crystal-lang
unshadow_ has joined #crystal-lang
unshadow has quit [Ping timeout: 240 seconds]
go|dfish has quit [Ping timeout: 260 seconds]
yogg-saron has joined #crystal-lang
go|dfish has joined #crystal-lang
<FromGitter>
<ravernkohdev> Hi
<FromGitter>
<ravernkohdev> Is there currently a Crystal binding to the Curses library?
Yxhuvud has joined #crystal-lang
<FromGitter>
<crisward> I'm listing the files in a directory with `Dir.entries(path)`, on a mac this seems to be in alphabetical order, on linux it isn't. Anyone know the reason for this and work around? I could sort the array, but if their is just some setting I'm missing that may be preferable. Thanks.
<Yxhuvud>
Do you get the same behaviour in other languages? If so, the workaround is to sort manually
<FromGitter>
<crisward> <Yxhuvud> Don't think so, bash certainly orders them, as does node.
<FromGitter>
<drosehn> I'd prefer that `Dir.entries` never sorted. If I want the directory sorted, I can sort them easy enough. Shells do sort them if you use a pattern on a command-line, but they aren't stored in a sorted order.
<FromGitter>
<drosehn> They may happen to be sorted, depending on how the files were put in the directory.
<Yxhuvud>
I also wouldn't put it past the mac people to have OS api's that give sorted entries back.
<FromGitter>
<drosehn> I just checked on macOS 10.10 with `Crystal 0.22.0 (2017-04-23) LLVM 4.0.0`, and the entries were not automatically sorted. They're also not automatically sorted in ruby, and I'm pretty sure they're not automatically sorted in perl either.
<FromGitter>
<drosehn> they're certainly not automatically sorted in C.
<FromGitter>
<drosehn> If you find yourself dealing with large directories, an automatic-sort step could be pretty noticeable overhead that you may want to avoid. If you want them sorted, just do `Dir.entries(somepath).sort`
<FromGitter>
<crisward> @drosehn thanks... I run my crystal app in a docker container with a directory exposed to my host os
<FromGitter>
<crisward> I'm finding the only inconsistencies are with this part of it
<FromGitter>
<crisward> Can't ever envisage going full linux for dev though...
<FromGitter>
<drosehn> I don't know about docker containers, or what order files were placed in the directory (or directories) that you're looking at. I just wrote a 5-line program using `Dir.entries()` as an array, and the files were not processed in alphabetical order.
<FromGitter>
<drosehn> I'm going to test a slightly different program though. give me a minute here...
<FromGitter>
<drosehn> yeah, it's the same with `Dir.foreach() {block}` on macOS. They are not processed in sorted order.
<FromGitter>
<careo> It's worth sorting them explicitly yourself, even if the underlying call returns them sorted. I've hit cases in ruby where directory listings would be sorted differently between OS X and Linux.
<FromGitter>
<careo> Was good for hours of "worked fine in dev, must be ops' fault" :smile:
<FromGitter>
<drosehn> If you're using `Dir.entries()`, is it all that much work to type 5 extra characters to sort the array?
<FromGitter>
<crisward> @drosehn not at all, just wanted to know if I was missing something.
<FromGitter>
<drosehn> aside: I happened to use `Dir.foreach()` on a directory just a few days ago, and the filenames came out sorted. I just now realized that in the directory I was working on, the files had been added into that directory in sorted-order...
DeBot has joined #crystal-lang
<FromGitter>
<crisward> BTW was wrong about node... @drosehn I think you may be right, I think I've rsynced my folder from the server which may have done the ordering
<FromGitter>
<drosehn> I should admit that I've never used node directly, so I don't know about that one. I do know that shells will sort the filenames matched by a pattern, such a `echo *`.
<FromGitter>
<drosehn> (although in some platforms the filenames are sorted into case-insensitive order, and other platforms may use case-sensitive order).
wuehlmaus has quit [Quit: Lost terminal]
<unshadow_>
Why is there such a differece between debug and release mode ?, it seems that programs which runs great in debug crash terrebly when compiling in release
DissonantGuile has quit [Ping timeout: 240 seconds]
<FromGitter>
<crisward> <unshadow_> are you short on memory? I've found releases can use more memory after an uncaught exception.
<unshadow_>
crisward: Ill check it out, but I would think that 16Gb is enough ;)
<FromGitter>
<crisward> when I see increase, I mean < 100mb. So yeah, 16gb will be fine.
<Yxhuvud>
You probably need to post a complete runnable example.
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
bjz has joined #crystal-lang
<FromGitter>
<KCreate> Didn't know you can use lldb with crystal binaries
<FromGitter>
<KCreate> how good is it supported?
zipR4ND has joined #crystal-lang
wuehlmaus has joined #crystal-lang
DissonantGuile has joined #crystal-lang
splitty__ has joined #crystal-lang
splitty_ has quit [Ping timeout: 252 seconds]
bjz has quit [Ping timeout: 240 seconds]
bjz_ has joined #crystal-lang
<FromGitter>
<mverzilli> @KCreate very basic support. you can step through the code and inspect very low level things as the stack frame or registers, but not do things like "watch variable x"
<FromGitter>
<KCreate> cool, i'll check it out once i'm home :smile:
<FromGitter>
<erunks> Wow. I'm surprised that needing an additional package like that wasn't stated in the readMe. I though mtools was what I needed for the longest times after searching around
<FromGitter>
<erunks> But I got it now. Thanks guys
<FromGitter>
<MatthewBennington> It's a common package, so the creators probably assumed it would already be installed. You should probably open an issue about this.
<FromGitter>
<erunks> Good point. I'll do that
<FromGitter>
<l3kn> This surprises me, too. stumpy_png is just using the zlib stuff from the stdlib
unshadow has quit [Ping timeout: 255 seconds]
zipR4ND1 has joined #crystal-lang
zipR4ND has quit [Ping timeout: 240 seconds]
unshadow has joined #crystal-lang
<FromGitter>
<mverzilli> but the stdlib in turn uses zlib
<BlaXpirit>
crystal does not guarantee that all stdlib will have its matching dependencies
<BlaXpirit>
especially depending on installation method
<FromGitter>
<mverzilli> @elthariel thanks! I'll check it out when I have a minute
<BlaXpirit>
libxml comes to mind as the most frequent offender
zipR4ND has joined #crystal-lang
zipR4ND1 has quit [Ping timeout: 252 seconds]
sz0 has joined #crystal-lang
zipR4ND has quit [Ping timeout: 260 seconds]
<FromGitter>
<l3kn> Interesting, I'll add a note to the readme
zipR4ND has joined #crystal-lang
unshadow_ has joined #crystal-lang
unshadow has quit [Ping timeout: 260 seconds]
<FromGitter>
<MatthewBennington> I'm worried that I'm spamming this channel with questions, so if it gets to be too much, please let me know. That being said, I am hoping someone can help me with an issue I'm having binding the ncurses c lib.
<FromGitter>
<bew> there is already an ncurses shard, why not use it?
<FromGitter>
<MatthewBennington> There are 4 ncurses shards, all with different amounts of features. I personally like the way crt.cr binds to ncurses, but it doesn't support colors yet.
<BlaXpirit>
MatthewBennington, not sure if that's part of the problem but @[Link is not a standalone thing, it attaches to the lib that follows it, so you better change that
zipR4ND has quit [Ping timeout: 268 seconds]
<BlaXpirit>
i cannot reproduce, runs fine for me
<FromGitter>
<MatthewBennington> Interesting
mounibec has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<BlaXpirit>
uhh though i isolated it to just has_colors, instead of running your actual example, that could be important
<FromGitter>
<MatthewBennington> Nah, I tried just has colors, and it crashed on me.
<FromGitter>
<MatthewBennington> Must be something about my machine. I'll try it in C and see it it fails still
<FromGitter>
<MatthewBennington> Also can you explain what you mean about @[link ?
<BlaXpirit>
MatthewBennington, your code currently says that to use setlocale you need to link to ncurses, while all the rest functions don't need any library
<FromGitter>
<MatthewBennington> Huh, then how the heck is it working?
<BlaXpirit>
well because linking in practice is not that granular
<BlaXpirit>
but there may be some edge case where it does break
<FromGitter>
<MatthewBennington> Well this is not my code, you (or I) could open an issue in the actual repo. https://github.com/maiha/crt.cr
<BlaXpirit>
oh huh
dannyAAM has quit [Quit: znc.saru.moe : ZNC 1.6.2 - http://znc.in]
<unshadow_>
read wont raise , even on closed sockets
Aytan72 has joined #crystal-lang
<Aytan72>
Howdy
<BlaXpirit>
unshadow_, but that's totally normal
<Aytan72>
I'm considering using crystal as a micro-service to a RoR project because of the performance increase. Is crystal production ready?
<unshadow_>
BlaXpirit: Is it ? It should raise an Exception no ? the end point is disconnected
<Papierkorb>
Aytan72: Mission critical stuff? No.
<unshadow_>
BlaXpirit: How else would I know if the socket is even alive ? I could just try to read from it forever
<BlaXpirit>
unshadow_, i dont know what it should but i know that in C and Python (which uses exceptions very often), a normally closed socket just returns 0 when there's nothing more to read
<Papierkorb>
Aytan72: The stdlib API isn't stable, some syntax changes could still arise (Though are becoming less likely). No threading support *yet* either.
<BlaXpirit>
and that's how you know - you check for 0
<Aytan72>
Papierkorb: Yeah, I need something faster than ruby for incoming data streams and calculations
<Papierkorb>
Aytan72: However, for something non-mission critical? Give it a try. I wouldn't base a company around it yet, but for something less important-ish, at least try it.
<unshadow_>
BlaXpirit: 0 = nothing to read (makes sense) , 0 != other socket is dead, this should raise, how else would you know if the other socket is connected or not ? what if the server just don't have anything to send right now ?
<BlaXpirit>
unshadow_, then the call blocks
<unshadow_>
BlaXpirit: It wont, we use non_blocking sockets
<Papierkorb>
Aytan72: Even if you don't end up liking it, you can easily port the code back to ruby for now. Not much lost in this worst-case scenario.
<Aytan72>
I should wait for 1.0 then?
<BlaXpirit>
unshadow_ pls
<Papierkorb>
Aytan72: is that micro service mission critical?
<Aytan72>
Papierkorb: That's why I'm really interested in crystal. Ruby syntax and amazing performance
<Aytan72>
Papierkorb: Yes it is
<unshadow_>
pls ?
<BlaXpirit>
unshadow_, I would like to see an example that checks whether socket.read will block when nothing is being sent
<Papierkorb>
Aytan72: *I* would think about it, but to be fair, I wouldn't recommend it for every case. Is it a one-time thing, or a service that is expected to run for years to come?
<Aytan72>
Papierkorb: The application relies 100% on the incoming data streams after they are processed (run through calculations too), and then served to a RoR application in near-realtime
<BlaXpirit>
and i'm about 99% sure that it will block
<BlaXpirit>
unshadow_, it's another question that crystal probably does use nonblocking sockets under the hood, but presents them as blocking
<unshadow_>
BlaXpirit: you can see my github issue, even though the socket is closed on the client, it will keep reading Bytes[] forever, it wont block
<BlaXpirit>
unshadow_, why would it block if the socket is closed
<BlaXpirit>
it returns 0 indicating there is no more data to be read
<Aytan72>
Papierkorb: I'm on the fence. I will probably try it anyways, because of the syntax compatibility
<Papierkorb>
Aytan72: I want to suggest to you giving crystal a try (Maybe you can port the slow ruby code to crystal as a try out), but I won't recommend you to use it just yet without a backup plan. I'm just trying to be honest, I like Crystal, but it still has its flaws
<unshadow_>
BlaXpirit: wait ... you said the call will block if the socket is closed ... did I misunderstood you ?
<Aytan72>
Papierkorb: I really appreciate your honest advice. All I know is that Crystal looks really promising and I'm excited about the future releases
<BlaXpirit>
> what if the server just don't have anything to send right now ? > unshadow_, then the call blocks
<BlaXpirit>
probably misunderstood me
<Papierkorb>
Aytan72: a backup plan might be keeping the slow ruby codebase in sync, so if the crystal daemon were to fail, you can switch to it quite easily. Don't expect it to fail, if it compiles and runs for an hour, it will run for the next days too, etc. - The issue might also arise later when a stdlib API changes (There is a CHANGELOG for this though) and you didn't do proper testing (or it's hard-to-test), it might fail on a later crystal
<Papierkorb>
compiler version "silently"
<unshadow_>
BlaXpirit: Oh, ok, in that case it will read 0, because the Crystal socket is 100% non_blocking, you can take my github example and just dont close the client socket, You will see it returns imidiatlly with 0 read
<unshadow_>
And that's my issue, as both closed socket and server has nothing to say returns 0 which means I can't handle a closed socket :\
<Aytan72>
Papierkorb: I'll proceed with caution. Mostly when switching between versions.
<Papierkorb>
Aytan72: That sounds perfectly reasonable
<BlaXpirit>
unshadow_, your example is just doing something weird, i'll post a better one
<unshadow_>
K
<Aytan72>
Papierkorb: Thanks a bunch for your help
<unshadow_>
This one is better ? google.com wont respond before you send a GET / request, in my example, you will get back the Bytes[] and not the "socket is dead"
<BlaXpirit>
closed? probably tells you whether you have closed it on your end, it will never be true
<BlaXpirit>
i've seen like 5 posts just like this already
<FromGitter>
<jwoertink> It's a cool post; however, the SQL calls are different, and it's not really fair to compare kemal to rails since rails has so much more going on. But from a learning standpoint, it's great!
<FromGitter>
<elorest> Everyone loves saying ruby is slow at this point. I’d love to see it benchmarked against phoenix or something.
<FromGitter>
<elorest> Problem is that 20 µs won’t look that different from 400 µ when db requests take 8ms.
<FromGitter>
<mverzilli> agree. I would love to see more blogposts comparing the experience of refactoring code as opposed to just comparing performance
<FromGitter>
<mverzilli> of course, there's still not many people out there maintaining a live Crystal app for months, so that perspective is more difficult to find that simply running small benchmarks
<FromGitter>
<elorest> yeah that too. I think that’s why rails is still a thing. It’s fast enough for a lot of applications and still has more developer happiness than elixir and node.
<FromGitter>
<elorest> I think that crystal apps have the potential to be more stable since we have compiler checks and won’t run into issues like something magicly being nil the first time the client tests it.
<FromGitter>
<mverzilli> right, I think that aspect of Crystal is generally underestimated, but again, it's a matter exposure
<FromGitter>
<mverzilli> we built good relationships with many clients thanks to how fast it was for us to prototype things they didn't know they wanted with Rails
<FromGitter>
<elorest> I had a pretty interesting conversation with DHH yesterday about ruby values and other communities that they exist in now too.
<FromGitter>
<mverzilli> nice!
<FromGitter>
<elorest> he seemed far less opinionated this year than in years past.
<FromGitter>
<bew> in which direction?
<FromGitter>
<elorest> he appologized for saying tdd was dead. He admitted that other communities have good idea’s too and that rails isn’t the one true framework.
<FromGitter>
<sdogruyol> he's definitely having an enlightment or smth
<FromGitter>
<ltran> getting older ;)
<FromGitter>
<elorest> yeah
<FromGitter>
<sdogruyol> :D
<FromGitter>
<sdogruyol> kids are growing older maybe
<FromGitter>
<sdogruyol> lol
<FromGitter>
<bew> nice improvment
<FromGitter>
<bew> !
<FromGitter>
<ltran> wisdom comes with age
<FromGitter>
<elorest> Either that or you become even more stuck in your ways.
<FromGitter>
<bew> (and experiences)
zipR4ND has quit [Ping timeout: 255 seconds]
<FromGitter>
<elorest> We were in Phoenix so @tenderlove made the joke. “If Rails is so great why isn’t there a city named after it?"
<Yxhuvud>
:D
mounibec has joined #crystal-lang
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
<FromGitter>
<bew> Is there a way to get the last enum value in a lib declaration?
<oprypin>
or are you actually dealing with 32-bit unsigned integers?
<FromGitter>
<bew> oooh ok I just understood why there where `Char` in the `LibC` I looked, I was thinking there where some magic about `Char` in lib declaration....
<oprypin>
bew, i think there is indeed magic - types inside `lib` come from LibC by default
<FromGitter>
<bew> wut?? what do you mean?
<RX14>
lol, BlaXpirit and oprypin hash to the same colour on hexchat
<oprypin>
nevermind. but i ish it was like that
<FromGitter>
<Sija> @bew maybe u mean `String#to_unsafe` which returns `LibC::Char*`?
<oprypin>
Sija, nah it's about correctly binding a `lib` - writing Char vs LibC::Char
<FromGitter>
<Sija> allrighty, nvm then
<FromGitter>
<bew> issue resolved for me, nvm Sija
<FromGitter>
<bew> yep
Aytan72 has quit [Remote host closed the connection]
<FromGitter>
<elthariel> @mverzilli @sdogruyol You're welcome, my pleasure