bcardiff has joined #crystal-lang
asterite has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
waj has joined #crystal-lang
e_dub has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff1 has joined #crystal-lang
<nuisanceofcats> Prep☃ but wouldn't it be fair to say that this is undesirable behaviour?
<nuisanceofcats> no, packing is good, aligned memory access is faster
<nuisanceofcats> i mean alignment
<nuisanceofcats> in C++11 you can turn it on or off though as needed
<nuisanceofcats> "gcc gets scared about unaligned accesses and generates six times as much code (96 bytes vs. 16 bytes)! sparc64 goes similarly crazy, bloating from 12 bytes to 52 bytes:"
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
<Prep> nuisanceofcats: interesting link, thanks
bcardiff has joined #crystal-lang
<nuisanceofcats> a lot of stuff about optimising code can be very counter intuitive
<nuisanceofcats> and techniques that are good for some CPUs are terrible for others
<Prep> yeah, I shouldn't have made that comment about undesirable behaviour before knowing what I was talking about :-)
<Prep> in my specific case, I'm using a struct to read binary data so the size of the struct _in that particular case_ matters
<Prep> I noticed the LLVM#struct_type method does have a parameter for making it packed, but there is no way to control that via the compiler right now
<Prep> I might look into adding something like "pack struct" in the same way you can say "abstract class" to signal a packed structure
<nuisanceofcats> american idol this season is great, they have an intelligent judge for once
<nuisanceofcats> and he's just decided he doesn't give a damn anymore and started criticising all the contestents and the other judges
<nuisanceofcats> it is wonderful chaos
<nuisanceofcats> but yeah packed structs do have their uses
<nuisanceofcats> at least for (de)serialisation, can't think of anything else right now
waj has joined #crystal-lang
bcardiff has joined #crystal-lang
asterite has joined #crystal-lang
asterite has joined #crystal-lang
<Prep> good morning, Ary
<asterite> Hi Prep
<asterite> I just read about the struct packing
<asterite> The real reason why structs are packed is for the GC, because boehm scans pointers in aligned memory
<asterite> We should support packed structs, but via attributes
<asterite> (and maybe the keyword "abstract" should also be replaced with an attribute)
<asterite> Something like what Java, C# and Rust have
<asterite> but we haven't thought much about that, so...
<asterite> What are you programming that you need packed structs?
<Prep> you remember that pull request with my changes to the Time class that I had to take back due to timezone trouble?
asterite has joined #crystal-lang
<Prep> I figured I'd try a different route and start with a Timezone class to give Time some context. I want to do this by reading the timezone info (/usr/share/zoneinfo/)
asterite has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
asterite has joined #crystal-lang
<asterite> @Prep sorry, got disconected
<asterite> So you need a packed struct to read those timezones?
asterite1 has joined #crystal-lang
<Prep> yeah, that's what it comes down to
<Prep> File.open(...) do |fd| ... fd.read(mystruct, sizeof(mystruct)) ...
<Prep> something like that (don't have the code lying around atm)
<asterite> I see...
<asterite> For now you can read each field separately into a buffer, then cast the buffer to your struct
<asterite> If what nuisanceofcats says is true, then it's not good to mark a struct as packed... maybe it would be better to read field by field
waj has joined #crystal-lang
<Prep> well, it would be nice to have the option
<Prep> what I got from nuisanceofcats' comments is that normally you don't want a packed struct, except for when you do :-)
<asterite> :D
<asterite> So we'll probably add it
<asterite> Are you using a C struct for this?
<Prep> yeah
<Prep> you mentioned you'd probably want to add it as an attribute. what would that look like?
<Prep> struct Foobar(packed=true)
<Prep> something like that?
<asterite> No, something like #@packed \n struct Foobar
<asterite> Or #[@packed]
<asterite> Something on top of the struct
<asterite> Or @{packed}
<asterite> Nimrod uses {. attr .}
<Prep> that's .. odd
<asterite> Java use @Foo
<asterite> C# uses [Foo(...)], I think
<asterite> Why odd?
<Prep> I'm not sure if I'm missing something, but #[@packed] above a struct definition seems odd in the sense that then code comments also get meaning
<asterite> Ah, well, it's just a proposal... maybe # as a leading character is not good
<Prep> taking Ruby as reference, the only thing I can think of where this is used is the #encoding comment
<asterite> Another idea is to just use @Foo, and disallow uppercase instance variables
<asterite> which comment?
<Prep> so: struct @Foo ?
<asterite> No: @Packed struct Foo
<Prep> I was refering to Ruby's so called "magic comment"
<asterite> Ah! I understand
<asterite> Yes, except that it won't be a magic comment in this case, #@ would start an attribute, # (without @ following it) would start a comment
<asterite> But, again, maybe using # as a leading character is not a great idea
<Prep> to be honest, I wouldn't mind a syntax of "struct @Foo" :-)
<asterite> But what if you want to specify an alignment?
<asterite> Attributes are like attaching metadata to your code
<asterite> Ruby doesn't need that because you can do it at runtime... but there's no standard way to do it so everyone reinvents it in a different way
<Prep> what alignment? there is either packed or unpacked, right?
<Prep> so either "struct Foo" or "struct @Foo" would do to cover the options
<Prep> so the @ is just another way of triggering LLVM.struct_type(..., packed=true)
<asterite> But, for example, right now we do fun foo = Foo
<asterite> if the function's name is capitalized, or we want to provide an alias
<asterite> We think it would be better to also use an attribute here
<asterite> like @Name("Foo") fun foo
<asterite> In the same way, we can attach attributes to "lib" to say "this is external C++"
<asterite> So it's a generic mechanism to add metadata to the code (types, methods, fields, etc.)
<Prep> but that's a different context, isn't it? the name of a function and the name of a struct are two different things
<Prep> to be fair, I have no deep understanding of your parser
<asterite> Are you familiar with C# or Java's attributes? Or D user defined attributes?
<Prep> I am in Java's case. You mean as in a class variable?
<asterite> Ah, no, sorry, in Java they are called Attributes
<asterite> Sorry, annotation :s
<asterite> One such example is @Deprecated
<Prep> oh yeah, annotations. I know of them, but never used them myself
<asterite> so you could mark a method as deprecated
<asterite> instead of adding new syntax, like "deprecated def foo..."
asterite1 has left #crystal-lang [#crystal-lang]
<Prep> sure, but I'm not defending "pack struct Foo" here
<nuisanceofcats> depending on the language you can query annotations either at compile time using metaprograms or at runtime using reflection
CraigBuchek has joined #crystal-lang
bcardiff has joined #crystal-lang
<asterite> Yes, for now the compiler will query the annotations at compile time, for example to know if a struct must be packed or not
asterite has joined #crystal-lang
waj has joined #crystal-lang
asterite has joined #crystal-lang
Excureo has joined #crystal-lang
waj has joined #crystal-lang
Excureo has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff1 has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff1 has joined #crystal-lang
CraigBuchek has joined #crystal-lang
waj has joined #crystal-lang
<nuisanceofcats> got sidetracked adding the ability to store playlists to mopidy, back to splat arguments
waj has joined #crystal-lang