<FromGitter>
<j8r> on macros I find `\` also useful
<RX14>
@fgimian you probably want read_fully
<hmans>
<3 Crystal <3
<hmans>
I've spent the last couple of days diving into both Rust (because everybody is loving it), Go (well...) and Pony (yeeaaahhh... it's nice)
<hmans>
It's been interesting and fun
<hmans>
but even now, I prefer Crystal to all those.
<hmans>
Pony is really really interesting, but it hasn't been as _nice_ to work with as Crystal's Rubyisms.
<hmans>
Rust is pretty great, but also... well... not as fun. I do understand why everybody is raving about it, though.
<hmans>
Go surprised me by evoking similar emotions in me to, say, Java, which is not what I expected.
<hmans>
ie. it's largely okay, but also kind of boring. It's just there, and it works, and it has no real surprises (neither good nor bad.) It's just... there.
<FromGitter>
<Grabli66> Nim? :)
<hmans>
Oh yeah, Nim!
wontruefree has joined #crystal-lang
<hmans>
It's been a while since I last checked that one out, but I remember it clicking with me quite well.
<hmans>
This time I wanted to focus on languages that have, let's say, opinions on parallelism... Nim is similar to Crystal in that regard, right?
<hmans>
Either way, I'm a sucker for indentation-based languages, so syntax-wise, I was enjoying Nim a lot
wontruefree has quit [Client Quit]
<hmans>
If Ruby and/or Crystal dropped `end` and went indentation-based, I'd be cool with that, but that's just how I roll. I know many people feel the opposite
<FromGitter>
<drujensen> yup, I donβt roll that way. ;-)
<hmans>
I'm weird, I know.
<FromGitter>
<drujensen> no, just different
<FromGitter>
<fgimian> Hey guys, suppose I have the my type defined in a variable and I wish to use that in my array declaration β β e.g. β β ```type = Int8 β stuff = Array(<type??>).new(10)``` [https://gitter.im/crystal-lang/crystal?at=5b0d576bb6eece791dc0b561]
wontruefree has joined #crystal-lang
<hmans>
I'm that one guy who, when forced to build a JS app, uses CoffeeScript for everything because haters gonna hate. It's become a bit of a running gag in my team, where I keep getting mocked for this, but one day I shall have my revenge, the rivers will flow red with the blood of my enemies, etc.
<FromGitter>
<fgimian> is this possible?
<FromGitter>
<fgimian> and if so, what's the best way to approach it
<hmans>
fgimian, I would bet against it since it wouldn't be known at compile time, right?
<FromGitter>
<drujensen> haha
<FromGitter>
<fgimian> that's correct yeah, it is during the reading of a binary file, where this can vary based on the file
<FromGitter>
<fgimian> can you suggest a better approach?
<hmans>
fgimian, not really, but I'm also just still starting out with the Crystals.
<FromGitter>
<fgimian> no problem, me too π
<FromGitter>
<fgimian> thanks a lot for the reply
<hmans>
I have been wondering if there is some sort of root type (similar to Ruby's Object) that could serve as a catch-all type in generics?
<FromGitter>
<fgimian> I'm trying to write a parser for mac plist files (property lists), which are often in binary format
<FromGitter>
<fgimian> I'm making progress, but just hit this one π
<FromGitter>
<fgimian> yeah not sure
<hmans>
Could you cheat and maybe deal with all of the stuff you're parsing as Strings?
<FromGitter>
<fgimian> I'm afraid not bud, they are all UInts
<hmans>
And then -- at a later stage -- run those strings through parsers that emit the intended type? (I'm just guessing, I know too little of the context of what you're doing)
<RX14>
@fgimian what code are you trying to do with a type in a variable?
<RX14>
i mean whats your usecase
<hmans>
drujensen, oh, TIL! So far I had assumed Value and Reference were root types. Please don't ask why I thought that.
<FromGitter>
<fgimian> sure, I'm parsing mac property lists which are in binary format
<FromGitter>
<fgimian> let me share a little snippet of my code to put it into context
<FromGitter>
<fgimian> sorry it's a big longer than I expected lol
<FromGitter>
<fgimian> this is what I'm up to π
<FromGitter>
<faultyserver> why does `object_offsets` need to be of a variable type?
<FromGitter>
<faultyserver> why not just make some `Offset` class that has a `size` property or something
<FromGitter>
<faultyserver> or just use the largest denominator and use Int64
<RX14>
yeah
<RX14>
one option is to just read them all in as U64s
<FromGitter>
<faultyserver> well, read the appropriate number of bytes, but then store it in a U64
<RX14>
well yeah thats what I meant
<FromGitter>
<fgimian> thanks guys, yeah I did consider that too
<FromGitter>
<fgimian> not a bad idea
<RX14>
and you don't need to do the IO::Memory stuff at all
<FromGitter>
<fgimian> worst case, I can just have an if statement there
<FromGitter>
<fgimian> which simply constructs one of the 4 types of arrays
<RX14>
you can just use buffer.read_bytes directly
<FromGitter>
<fgimian> or a case statement .etc
<RX14>
you'd still end up with a union of all those types
<FromGitter>
<fgimian> valid point RX14
<FromGitter>
<fgimian> you're right
<RX14>
which would be ugly to work with
<FromGitter>
<fgimian> thanks
<FromGitter>
<faultyserver> unrelated, but is there any roadmap for when 0.24.3 (or 0.25.0 or whatever) might get released?
hmans has left #crystal-lang [#crystal-lang]
<FromGitter>
<fgimian> I'm porting this over from the Python code, and so it's easy to be influenced by the original implementation
<FromGitter>
<faultyserver> really looking forward to the automatic casts
<FromGitter>
<hmans> @faultyserver There's a milestone on Github which is almost at 100%. I understand the changelog is already being written?
<FromGitter>
<faultyserver> awesome
wontruefree has quit [Quit: bye]
<FromGitter>
<fgimian> I think I'll try a case statement for now π
<FromGitter>
<fgimian> that won't be so bad
<FromGitter>
<fgimian> p.s. I'm excited about the next release too!!! I'm running the master branch on my Mac atm π
<RX14>
@fgimian But then you'll get an (Array(UInt8) | Array(UInt16) | Array(UInt32) | Array(UInt64))
<FromGitter>
<fgimian> oh
<FromGitter>
<fgimian> good point
<RX14>
and it's be much easier to just use u64's everywhere
<FromGitter>
<fgimian> with unions, each item will use up the memory required for each item right?
<FromGitter>
<fgimian> e.g. in that union, i would need 15 bytes per item?
<RX14>
no
<FromGitter>
<fgimian> oh cool
<RX14>
unions have a type tag and then follow the value
<RX14>
if it was Array(UInt8 | ... | UInt64) you'd have a 32-bit tag and then the data
<RX14>
which must be 64 bits because thats the largest size
<FromGitter>
<fgimian> aaaaaaaaaah gotcha
<RX14>
and then you'd have an array of those
<FromGitter>
<fgimian> I see your point
<FromGitter>
<fgimian> thanks so much for the explanation and help π
<RX14>
for Array(UInt8) | Array(...) | Array(UInt64) you waste a lot less space
That_Guy_Anon has quit [Ping timeout: 252 seconds]
<RX14>
because each array is optimally layed out
<RX14>
and the only overhead is in the original dereference
wontruefree has joined #crystal-lang
<RX14>
but it's still hearder to deal with than just an Array(UInt64)
<RX14>
in code
<RX14>
you'll have to cast around when using it
<RX14>
and most code will just end up casting to UInt64 anyway
<RX14>
so
<RX14>
idk
<FromGitter>
<fgimian> yeah I know what you mean
<RX14>
I don't know enough about plist files to know what the best typed API for them is
<RX14>
how does C do it?
<FromGitter>
<fgimian> same here; honestly not sure
<FromGitter>
<fgimian> I might look at the Ruby implementation to see what they do too
<RX14>
ruby isn't typed
<RX14>
it'll just return numbers
<FromGitter>
<fgimian> true
<RX14>
which i guess is eqwuivalent to always returning a U64
<FromGitter>
<fgimian> well actually
<FromGitter>
<fgimian> what you said is true
<FromGitter>
<fgimian> because the only place those numbers are used is when seeking in the file
<FromGitter>
<00dani> plists are approximately the same structure as JSON, so whatever Crystal already does for JSON is probably about right.
<FromGitter>
<fgimian> I think I'm going to go with the option you mentioned, UInt64 everywhere
<RX14>
oh yeah
<FromGitter>
<fgimian> @00dani cool, I wasn't aware of that. This is my first time ever dealing with binary parsing π
<FromGitter>
<fgimian> RX14: your suggestion worked perfectly
<RX14>
this is just the offset table
<FromGitter>
<fgimian> thanks!
<RX14>
so U64 is definitely the way to go
<RX14>
it's just compression
<FromGitter>
<fgimian> yeah
<FromGitter>
<fgimian> totally makes sense
<FromGitter>
<fgimian> thanks again, I'll get there slowly, sorry for all the questions
<FromGitter>
<00dani> Yeah, there's a few different plist formats (binary, XML, an ASCII one which is way better than the XML one but deprecated) but the data model's the same between them and it's basically just JSON, so the appropriate typed API for it is JSON. :P
<RX14>
for parsing it you'll probably want to implement a pull parser first
<RX14>
all the JSON and YAML stuff in crystal is built off pull parsers because they are by far the most flexible and low-level interface to arbitrarily typed datastructures like json
<RX14>
i suggest you look them up becfore trying to parse it like you would in a dynamic language
<RX14>
because in crystal it will get very messy very fast
<FromGitter>
<fgimian> gotcha
<FromGitter>
<fgimian> will definitely check out the JSON parser
<RX14>
definitely check out JSON::PullParser
<FromGitter>
<fgimian> indeed the final output should match the JSON parser as plist formats are indeed similar
<FromGitter>
<fgimian> thanks a lot
<RX14>
then check out how from_json and JSON.mapping are built on top of the pull parser
<RX14>
because it's much easier to do it that way then the other way around
<FromGitter>
<fgimian> gotcha
<FromGitter>
<fgimian> will definitely do
<FromGitter>
<fgimian> thanks heaps!
greengriminal has quit [Quit: Leaving]
greengriminal has joined #crystal-lang
Nathanaelle has quit [Read error: Connection reset by peer]
greengriminal has quit [Quit: Leaving]
<FromGitter>
<Willamin> does `crystal run` get cached in `$HOME/.cache/crystal` to speed things up?
<RX14>
yeah
That_Guy_Anon has joined #crystal-lang
That_Guy_Anon has quit [Remote host closed the connection]
<FromGitter>
<Willamin> Has there been discussion for further caching for `crystal run`? One thing I've tried (with decent success) is a small program that I can use in place of `crystal run`. It computes a digest of the contents of the crystal script, runs `crystal build` against the script, renames the binary based on the digest, and runs the binary. The next time the I run it, the `crystal build` step is skipped in favor of simply
<FromGitter>
... executing the binary. If the crystal script's contents ever change, the digest changes, which indicates that it needs to run `crystal build`. β I just did a quick benchmark and it seems like this technique could be useful if included in `crystal run`itself, with some tweaking. The way I've done it doesn't take into accou ... [https://gitter.im/crystal-lang/crystal?at=5b0d76bdedd06f7d15f21843]
<FromGitter>
<Willamin> I didn't see one, but if there's a github issue or PR or a forum thread that's specifically about this type of improvement, definitely let me know and I'll read up on previous discussion.
<FromGitter>
<Willamin> they mention how luajit is faster than C
<FromGitter>
<Willamin> > The benchmark was run on Linux, so the performance penalty weβre seeing comes the Procedure Linkage Table (PLT)
<RX14>
thanks for the link
csk157 has quit [Ping timeout: 260 seconds]
alex`` has joined #crystal-lang
alex`` has quit [Quit: WeeChat 2.1]
Raimondii has joined #crystal-lang
Nathanaelle has joined #crystal-lang
Raimondi has quit [Ping timeout: 264 seconds]
Nathanaelle has quit [Read error: Connection reset by peer]
Raimondii is now known as Raimondi
Nathanaelle has joined #crystal-lang
alex`` has joined #crystal-lang
bmcginty has quit [Ping timeout: 264 seconds]
bmcginty has joined #crystal-lang
Nathanaelle has quit [Ping timeout: 260 seconds]
Nathanaelle has joined #crystal-lang
Nathanaelle has quit [Read error: Connection reset by peer]
<FromGitter>
<r00ster91> So i'm getting JSON from an API with `HTTP::Client.get(API_URL).body` and if theres for example the character `β` in the JSON then when I print it, it prints `Γ’ΒΒ`. Even if my terminal can actually display the character `β` and when I print `β` directly then it also works. How do I make that it gives me valid, expected characters instead of weird, wrong characters?
<oprypin>
r00ster91, please provide a sample of the json (preferably the whole server response with headers) and your source code
<oprypin>
uh that's python, dont worry about it, DeBot
<oprypin>
if you're on windows cmd, it's quite probable that it does not expect utf-8
<oprypin>
but you said printintg it works
Nathanaelle has joined #crystal-lang
<FromGitter>
<r00ster91> well i noticed that its a problem of the API. Not of the data translation or something. The character β for example becomes Γ’ β but im not sure how I can convert that back again to the correct character
<FromGitter>
<r00ster91> oh it looks like everything becomes an Γ’ when its not in the char range of 0-255. So this isnt really solvable. Thanks anyway
Nathanaelle has quit [Read error: Connection reset by peer]
Nathanaelle has joined #crystal-lang
Nathanaelle has quit [Read error: Connection reset by peer]
yaewa has quit [Quit: Leaving...]
moei has joined #crystal-lang
Marrow16180 has joined #crystal-lang
Marrow16180 has left #crystal-lang [#crystal-lang]
Marrow16180 has joined #crystal-lang
Marrow16180 has quit [Client Quit]
Marrow16180 has joined #crystal-lang
<Marrow16180>
Hi
Marrow16180 has quit [Quit: Leaving]
Nathanaelle has joined #crystal-lang
Marrow16180 has joined #crystal-lang
<FromGitter>
<epergo> does anyone know why asterite is no more a core team member? :(
<FromGitter>
<r00ster91> for real? he leaved?? :( β i thought hes just on a vacation or something..