<astronavt>
@Blacksmoke16 yeah ideally i'd use UTC for everything, but sometimes you gotta ingest data by other means. its also not that much of a big deal since it's exactly 1 hour out of the entire year (and only in areas that observe DST) but im still curious about it
DeBot has quit [Quit: Crystal IRC]
straight-shoota has quit [Quit: ZNC 1.8.2 - https://znc.in]
jhass has quit [Quit: Bye]
asterite has quit [Quit: Bye]
DeBot has joined #crystal-lang
asterite has joined #crystal-lang
straight-shoota has joined #crystal-lang
jhass has joined #crystal-lang
raz has quit [Ping timeout: 260 seconds]
raz has joined #crystal-lang
sz0 has joined #crystal-lang
vasanth has joined #crystal-lang
vasanth has quit [Ping timeout: 252 seconds]
vasanth has joined #crystal-lang
_ht has joined #crystal-lang
hendursa1 has joined #crystal-lang
hendursaga has quit [Ping timeout: 240 seconds]
vasanth has quit [Ping timeout: 246 seconds]
vasanth has joined #crystal-lang
f1refly has quit [Ping timeout: 265 seconds]
f1refly has joined #crystal-lang
vasanth has quit [Ping timeout: 240 seconds]
vasanth has joined #crystal-lang
vasanth has quit [Ping timeout: 252 seconds]
ua has quit [Ping timeout: 252 seconds]
vasanth has joined #crystal-lang
vasanth has quit [Ping timeout: 252 seconds]
vasanth has joined #crystal-lang
vasanth has quit [Ping timeout: 240 seconds]
vasanth has joined #crystal-lang
ua has joined #crystal-lang
vasanth has quit [Ping timeout: 260 seconds]
vasanth has joined #crystal-lang
vasanth has quit [Ping timeout: 252 seconds]
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #crystal-lang
<jhass>
straight-shoota: ^4
<jhass>
eh, high-five :D
<jhass>
exactly the same answers :D
<straight-shoota>
xD
<straight-shoota>
so it's redundant proof
<jhass>
Idk why people try to use Crystal like C -.-
<jhass>
maybe "fast as C" is misleading them or so :D
<straight-shoota>
well, I think it's interesting to explore
<straight-shoota>
and there may be some actual value, when interfacing with a weird library for example
<straight-shoota>
or maybe embedded stuff
<straight-shoota>
... and I suppose a surprising aspect is that Crystal even actively applies type information at this low level
<straight-shoota>
plus bcardiff's forum answer may have been misleading
<jhass>
hehe, well yeah, I could easily answer this because I've been down all that rabbit hole trying to get stuff play nice with GObject stuff
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
<FromGitter>
<y8> Hi! What is the most optimal way to handle platform-dependent int sizes? Im working with files both on armhf and amd64 and File#size doesn't match on this platforms.
<FromGitter>
<oprypin:matrix.org> @y8: that is a bug then
<FromGitter>
<oprypin:matrix.org> @y8: which sizes are you getting?
<FromGitter>
<oprypin:matrix.org> let's say just as an example it's UInt32 in one case and Int64 in another. then just call `.to_i64` on the result, or so. and report a bug on crystal repo
<FromGitter>
<y8> Opps, its x86_64. But anyway: x86_64 == UInt64, armv6 == Int32
<FromGitter>
<oprypin:matrix.org> @y8: i dont understand what you want to do
<jhass>
mmh, perhaps a multi writer where one end is an fd and the other is an IO::Memory?
<jhass>
keeps the entire thing in memory though
<jhass>
it's hard to tell without context, perhaps something that could be solved with a different application design
<yxhuvud>
y8: I assume you have found IO#read_fully? That could be relevant for you , possibly coupled with an unbuffered file.
<FromGitter>
<y8> I have a process that constantly writes to binary append-only journals. I need to read from this journals when they are changed and bridge full journal entries to different system ⏎ ⏎ I'm using inotify to get modification events on journal files. And there is no guarantee that consumer will see the entry that is fully written. ⏎ ⏎ Entries are encoded in Size/Value format, so I kinda know how much data I