<FromGitter>
<mjfiano:matrix.org> I find myself explicitly typing the return value of each method, so it shows up in docs, and also to help catch silly logical mistakes causing the compiler to deduce something i wasn't intending. am i alone?
<FromGitter>
<mjfiano:matrix.org> and also, I noticed that some people use `{{ ... }}` in place of `{% ... %}` to splice in compile-time evaluations. Are they always interchangeable, or only for certain things?
<FromGitter>
<mjfiano:matrix.org> Also back to being afk, no rush
<FromGitter>
<Blacksmoke16> no, its a good idea to add type restrictions
<FromGitter>
<Blacksmoke16> normally the practice is to use `{{ ... }}` for things that should "paste" something into the program, while `{% ... %}` are used for meta level stuff. Like defining variables, loops, conditional logic etc
<FromGitter>
<mjfiano:matrix.org> For matrix accessors, instead of names like x, y, z, etc, they are supposed to be accessed by row/column indices. That leaves: ⏎ ⏎ 1) Continue using named accessors prefixed with for example `m`, as in `matrix.m23`. ⏎ 2) Override the underlying storage from 1-dimensional and or the `[]` method to be able to use `matrix[2][3]`. ⏎ 3) Use the array-like literal syntax of `matrix{2, 3}`. ...
<FromGitter>
<mjfiano:matrix.org> Does the compiler or LLVM ever try to inline normal methods (ones that don't yield, etc)? I'm just wondering if I can save some time benchmarking and manually marking functions with the `AlwaysInlined` annotation, which would be a lot of work on all my target hardware, and instead just leave it up to the compiler.
sagax has quit [*.net *.split]
sagax has joined #crystal-lang
Welog has quit [Remote host closed the connection]
Welog has joined #crystal-lang
<postmodern>
naqvis, thanks!
<FromGitter>
<pyrsmk> > @mjfiano:matrix.org `[]=` is an expression, it returns the value ⏎ ⏎ Does it depend on how `[]=` is implemented? It would make sense to have it written like `def []=(value) : Nil`, so maybe it just depends on the implementation
<FromGitter>
<pyrsmk> but yeah, it returns a value ^^
jrayhawk has quit [Quit: seuoia upgrades]
jrayhawk has joined #crystal-lang
Nik- has quit [Read error: Connection reset by peer]
<FromGitter>
<oprypin:matrix.org> mfiano (https://matrix.to/#/@mjfiano:matrix.org): yes in release mode there's some inlining happening. don't know the details
<FromGitter>
<oprypin:matrix.org> well i do know that only the llvm side of compilation can do the inlining
hightower2 has joined #crystal-lang
jrayhawk has quit [Quit: leaving]
jrayhawk has joined #crystal-lang
jrayhawk has quit [Quit: leaving]
jrayhawk has joined #crystal-lang
jrayhawk has quit [Quit: leaving]
jrayhawk has joined #crystal-lang
szutt has joined #crystal-lang
Nik- has joined #crystal-lang
szutt has quit [Quit: Client closed]
<FromGitter>
<mjfiano:matrix.org> Thanks
<FromGitter>
<mjfiano:matrix.org> How can I restrict an argument to be an integer from 0 to 3?
<FromGitter>
<Blacksmoke16> `raise ArgumentError.new "Value must be between 0 and 3" if value.negative? || value > 3`
<FromGitter>
<mjfiano:matrix.org> Ah so no type like Nim
<hightower2>
maybe even ... unless 0 <= value <= 3
<FromGitter>
<mjfiano:matrix.org> Thanks
<FromGitter>
<mjfiano:matrix.org> I think I need to go back to using a class instead of a struct
iskra has quit [Read error: Connection reset by peer]
<FromGitter>
<Blacksmoke16> oh?
<FromGitter>
<mjfiano:matrix.org> I am going to need an allocating and mutating API for each method like my existing Lisp library. The amount of copying done for intermediate matrix calculations is pretty insane.
<FromGitter>
<mjfiano:matrix.org> wanted to see if they were all unambiguous
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<mjfiano:matrix.org> wait...
<FromGitter>
<mjfiano:matrix.org> on my machine i get 1, 2, 3, 4 printed
<FromGitter>
<mjfiano:matrix.org> 1,1,3,3 on carc
<FromGitter>
<Blacksmoke16> carc is still using `1.0`, might have something to do with it
<FromGitter>
<mjfiano:matrix.org> interesting. that is quite the bug fix
<FromGitter>
<mjfiano:matrix.org> But seems you need `v.+` when using the named argument like in your example above
<FromGitter>
<mjfiano:matrix.org> your example also fails to parse without that
<FromGitter>
<Blacksmoke16> makes sense i guess
<FromGitter>
<Blacksmoke16> maybe that can be improved, idk
<FromGitter>
<Blacksmoke16> but when you do like `1 + 2` the compiler turns that into like `1.+(2)`
<FromGitter>
<Blacksmoke16> as it's just a method call
<FromGitter>
<mjfiano:matrix.org> i'll add it to my list of issues/feature requests to file
<FromGitter>
<mjfiano:matrix.org> I see these both used in instance methods, which one is more idiomatic? `typeof(self).new`, `self.class.new`
<FromGitter>
<Blacksmoke16> pretty sure they mean slightly diff things. `typeof` returns the compile time type, while `self.class` is the runtime type
<FromGitter>
<Blacksmoke16> so might depend on exact context what they return
<FromGitter>
<mjfiano:matrix.org> I see, thanks
<FromGitter>
<mjfiano:matrix.org> would that be like `{{@type}}.new`?
<FromGitter>
<Blacksmoke16> depends on exactly what you want i think
<FromGitter>
<Blacksmoke16> like `self.class.new` would support child types when defined on a parent, but `{{@type}}` prob would return the type that it's called in
postmodern has quit [Remote host closed the connection]
<FromGitter>
<mjfiano:matrix.org> Oh yeah I assumed that. I was wondering how `{{@type}}` is different from `typeof(self)`
<FromGitter>
<mjfiano:matrix.org> i guess the latter is the function invocation of the literal
<FromGitter>
<Blacksmoke16> actually from what i can tell they all seem equivalent
<FromGitter>
<Blacksmoke16> i.e. instead of using the `each_with_index`?
<FromGitter>
<mjfiano:matrix.org> I mean instead of calling each_with_index at runtime, just call all required `result[...]`, given a sizing type parameter and a known memory layout
<FromGitter>
<Blacksmoke16> i will say using the method is equivilent to just doing `result[0] = {{op}}` etc
<FromGitter>
<Blacksmoke16> as they're always inlined
<FromGitter>
<mjfiano:matrix.org> the block is inlined, but there are several blocks through an iterator
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<mjfiano:matrix.org> This is bizarre
<FromGitter>
<mjfiano:matrix.org> maybe a generics issue you were speaking of...
<FromGitter>
<mjfiano:matrix.org> dunno what i am missing. guess it's break time...
<FromGitter>
<Blacksmoke16> i mean the 2nd overload is being called
<FromGitter>
<Blacksmoke16> which should then use the first overload
<FromGitter>
<mjfiano:matrix.org> but the first isn't a listed choice of overloads available
<FromGitter>
<mjfiano:matrix.org> This seems to be a bug in the compiler, but I'm not certain. It works if you remove the default values from the first overload
<FromGitter>
<Blacksmoke16> let me try from master
<FromGitter>
<mjfiano:matrix.org> i built from master 2 days ago
<FromGitter>
<Blacksmoke16> yea same error
<FromGitter>
<mjfiano:matrix.org> odd thing is it works without the default values on the first
<FromGitter>
<Blacksmoke16> @HertzDevil would prob have an idea
<FromGitter>
<mjfiano:matrix.org> Ok I'll take a break and see if he replies later
<FromGitter>
<alexherbo2> I'm not sure, but, instead of `after_initialize`, couldn't avoid logic if the json/yaml serializable use the setters instead of setting the properties directly?
<FromGitter>
<Blacksmoke16> possibly, but idt there's a way to have it use the setters
<FromGitter>
<jwaldrip> Familiar with the split arch alternatives. But we need true m1 builds. So I will continue to wait.
<FromGitter>
<jwaldrip> Or does this actually give me an m1 build of crystal?
<jhass[m]>
it's a universal build, a single executable containing code for both architectures as far as I understood it
<FromGitter>
<mjfiano:matrix.org> I still haven't been able to continue around this problem that might be a bug in Crystal.
<FromGitter>
<mjfiano:matrix.org> I'm not sure if maybe I should file the bug report and come back to Crystal when it is more mature.
<FromGitter>
<mjfiano:matrix.org> But I would like to confirm it's not my fault and actually is a bug before I end up doing that.
<riza>
@mjfiano have you posted your code sample anywhere?
<FromGitter>
<mjfiano:matrix.org> Yeah, @Blacksmoke16 was helping earlier today
<riza>
I'd make a github issue -- if it's a bug and it's unreported that's the best way to get some real eyes on it.
<riza>
I've run into issues doing operations "Size" generics like that as well, but have always just found a way around them
<FromGitter>
<mjfiano:matrix.org> I just figured out the problem
<FromGitter>
<Blacksmoke16> oh?
<riza>
semantically it didn't make much difference to to me say Klass(T).new(4) instead of Klass(T,4).new
<FromGitter>
<mjfiano:matrix.org> I'm setting the default value of the T-restricted arguments to be a Float64 value. The compiler is very confused about that, and it doesn't make sense anyway
<FromGitter>
<mjfiano:matrix.org> I still think it's a bug, but one that makes sense now at least
<FromGitter>
<mjfiano:matrix.org> and easily workaroundable
<FromGitter>
<Blacksmoke16> but you were passing in `Float64` as the value of `T` tho?
<FromGitter>
<mjfiano:matrix.org> I was for the instance being created, not for the method call
<FromGitter>
<Blacksmoke16> so? `T` is inherited from the generic
<FromGitter>
<mjfiano:matrix.org> Maybe the fact that there is also an overload for min and max = self, means that it could be recursive I think
<FromGitter>
<mjfiano:matrix.org> Infact the issue goes away if the self versions are removed, even though they are not in the call graph anywhere
<FromGitter>
<mjfiano:matrix.org> Seems like some elusive compiler bug that probably deserves me fooling around to come up with a more minimal test case, since there are multiple ways that contribute to the problem in the current example
<FromGitter>
<mjfiano:matrix.org> Before reporting it anyway
<FromGitter>
<mjfiano:matrix.org> It's not immediately clear to me how anything in that draft should fix this particular example, but hey if it does, cool...I'll work around the problem until it is finalized.
<FromGitter>
<asterite> Ah, I see. Sorry, too complex to understand on a Phone, but it seems there's a PR that fixes ir so it's probably a bug
<FromGitter>
<mjfiano:matrix.org> Are Carcin examples permanent links? I'm guessing not with such a small id
<FromGitter>
<Blacksmoke16> long enough
<FromGitter>
<mjfiano:matrix.org> Nice detective work finding that PR
<FromGitter>
<Blacksmoke16> it helps when you read every issue/pr 🙃
<FromGitter>
<mjfiano:matrix.org> Haha. Well I can easily work around this, as there is no reason I absolutely need a "type" type parameter for these codes, only size.
<FromGitter>
<mjfiano:matrix.org> Thanks
<FromGitter>
<Blacksmoke16> np
<FromGitter>
<mjfiano:matrix.org> and to confirm, this issue also goes away if the `T` type parameter goes away and uses concrete types in place, which is why that PR fix doesn't make a whole lot of sense to me