<FromGitter>
<asterite> Yes, but ruby works the same way
<FromGitter>
<asterite> it would be a bit strange if every Enumerable was flattened
<FromGitter>
<asterite> For example a Dir is Enumerable, but you probably don't want to flatten that
<FromGitter>
<asterite> Http headers are also Enumerable. Apparently uri params too
<FromGitter>
<asterite> Also flatten is defined on Array, that's why it only flattens arrays
<FromGitter>
<asterite> Flatten is usually used in conjuncion with map, which returns array in most cases, so thats another reason... Well
<FromGitter>
<franciscoadasme> @straight-shoota thanks but it's not that same I'm talking about
teardown_ has joined #crystal-lang
<FromGitter>
<franciscoadasme> @asterite I understand what you say, but I don't entirely agree... Flattening is supposed to be used on a collection of collections, so sure, using flatten on Dir or any "one-dimensional" collection is kind of odd, but flattening an array of Dir's may make sense
teardown has quit [Ping timeout: 268 seconds]
teardown_ has quit [Remote host closed the connection]
<FromGitter>
<franciscoadasme> anyways, I stumble upon this issue by returning a tuple in the block, and it was surprising to get `Array(Tuple(...))` but perhaps it was a misunderstanding on my part
teardown has joined #crystal-lang
teardown has quit [Remote host closed the connection]
teardown has joined #crystal-lang
teardown_ has joined #crystal-lang
teardown has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has quit [Ping timeout: 268 seconds]
teardown_ has joined #crystal-lang
hightower3 has quit [Ping timeout: 246 seconds]
teardown has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has quit [Ping timeout: 268 seconds]
teardown_ has joined #crystal-lang
teardown has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has quit [Ping timeout: 268 seconds]
deavmi has quit [Read error: Connection reset by peer]
teardown has quit [Remote host closed the connection]
teardown_ has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has joined #crystal-lang
teardown has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has quit [Ping timeout: 268 seconds]
_whitelogger has joined #crystal-lang
teardown_ has joined #crystal-lang
teardown has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has quit [Ping timeout: 268 seconds]
teardown_ has joined #crystal-lang
teardown has quit [Ping timeout: 268 seconds]
teardown has joined #crystal-lang
teardown_ has quit [Ping timeout: 268 seconds]
teardown has quit [Ping timeout: 268 seconds]
_ht has joined #crystal-lang
f1reflyylmao is now known as f1refly
alexherbo2 has joined #crystal-lang
yxhuvud has quit [Ping timeout: 268 seconds]
yxhuvud has joined #crystal-lang
<FromGitter>
<asterite> Oh, I see
<FromGitter>
<asterite> I think the issue is that we copied the functionality from Ruby, but in Ruby the only collection type is Array. In Crystal we also have Tuple, StaticArray, etc.
<FromGitter>
<asterite> So maybe we should also do it for more collections... But for example tuples are sometimes used to represent a pair of related objects, to be considered a single object. So flattenning that would sometimes be confusing. In the end, I think we should document this and say that only Arrays get flattened
<yxhuvud>
in general flatten(1) is more common than flatten(all the levels), so I doubt that is a problem in practice.
<yxhuvud>
(at least for me. YMMV)
<FromGitter>
<HertzDevil> the doc change in 10329 makes it clear only arrays and iterators are flattened
<FromGitter>
<HertzDevil> (previously `Iterator` didn't even appear on `Enumerable#flat_map`)
<FromGitter>
<HertzDevil> ('s doc)
<FromGitter>
<HertzDevil> every enumerable of enumerables can be flattened by calling `.map(&.each)` first even if that's not very efficient
<FromGitter>
<HertzDevil> or by calling `.each` after everything else in the block
<Andriamanitra>
that's cool, i had no idea flatten worked on iterators too
<FromGitter>
<asterite> To be honest I'm not sure flatten should work on iterators
<FromGitter>
<asterite> maybe since it's a call on Iterator it makes sense, I don't know
<straight-shoota>
an iterator type is mainly a collection
<straight-shoota>
so I guess it would make sense.
<straight-shoota>
There are types that can either be a collection of items or an individual entity as a whole. But those usually implement Iterable, not Iterator
<FromGitter>
<Blacksmoke16> yea thats prob the only frame, as there are no method calls etc
<FromGitter>
<Blacksmoke16> because the error doesnt happen in a method call, as its on the top leve*
<FromGitter>
<Blacksmoke16> level
<FromGitter>
<djberg96> maybe it changed between 0.2.x and 0.3.x, or maybe the book just has a bad example
<FromGitter>
<djberg96> (the book was written during 0.2.x i believe)
<FromGitter>
<djberg96> any, no worries, soldiering on
<FromGitter>
<Blacksmoke16> 👍 and i assume you understand why the error is happening? :p
<FromGitter>
<djberg96> yes
<FromGitter>
<Blacksmoke16> perfect
<FromGitter>
<djberg96> really i just wanted to see how a backtrace looked :)
hightower3 has joined #crystal-lang
<yxhuvud>
djberg96: wow, yet another oldie from #ruby-lang before rails :)
<FromGitter>
<djberg96> :)
<FromGitter>
<asterite> no
<FromGitter>
<asterite> crystal run --error-trace mineral.cr
<FromGitter>
<asterite> run that, you'll see more frames
<FromGitter>
<asterite> @djberg96 ^
<FromGitter>
<asterite> when you do `crystal foo.cr --error-trace`, `--error-trace` is passed as an argument to the program, not the compiler
<FromGitter>
<Blacksmoke16> :0
<FromGitter>
<Blacksmoke16> good to know
<FromGitter>
<asterite> unfortunately someone thought that was a good idea and everyone else except me liked that
<FromGitter>
<erdnaxeli:cervoi.se> oh, I always thought you pass params too the program using `--`
<FromGitter>
<erdnaxeli:cervoi.se> so `crystal foo.cr -- --error-trace`
<FromGitter>
<naqvis> this behavior is different from common cli arg passing, technically speaking any arguments passed should be considered to be passed to command which is being invoked
<FromGitter>
<asterite> yes, that was in the past... it changed a few versions before
<FromGitter>
<asterite> @erdnaxeli:cervoi.se nope, that would still not work
<FromGitter>
<asterite> oh, nevermind
<FromGitter>
<naqvis> i remember previously one had to use `--` to pass the arguments to program being invoked via `crystal run`
<FromGitter>
<naqvis> don't know why that get changed
<FromGitter>
<asterite> it's so you can use shebang with crystal
<FromGitter>
<asterite> like if crystal were a scripting language (which is not)
<FromGitter>
<erdnaxeli:cervoi.se> ah, kind of make sens
<FromGitter>
<erdnaxeli:cervoi.se> supposing you want to use it like that
<FromGitter>
<asterite> if I want a tool I want to execute multiple times, I compile it once
<FromGitter>
<asterite> then it runs faster
<FromGitter>
<asterite> shebang for crystal is useless for me
<FromGitter>
<naqvis> true, crystal ain't scripting language and it shouldn't be treated that way
<FromGitter>
<djberg96> @asterite aha, thanks!
<FromGitter>
<naqvis> @djberg96 also you needn't to use separate arguments to assign values to ivars. you can simplify your sample initialize method by ⏎ ⏎ ```def initialize(@name, @hardness, @crystal_struct) ⏎ end``` [https://gitter.im/crystal-lang/crystal?at=601c2dbe9238c531ad2449e0]
<FromGitter>
<jrei:matrix.org> any reason not to use for quick scripts
<FromGitter>
<naqvis> no one is against that, but against treating it as interpreted language. as no matter you do `crystal run` its still going to compile the code before that get executed
<FromGitter>
<naqvis> so giving this illusion of interpreted doesn't make sense
<FromGitter>
<asterite> j8r what do you mean, where's the shebang there?
<FromGitter>
<jrei:matrix.org> no shebang, but it is used as a script
<FromGitter>
<jrei:matrix.org> a shebang would perfectly fit there, `crystal collect_keys.cr` vs `./collect_keys.cr`
<FromGitter>
<asterite> how do you know it's used as a script? did you see jhass running it? maybe he compiles it first
<FromGitter>
<jrei:matrix.org> my point is: performance does not matter at all for such scripts, really
<FromGitter>
<jrei:matrix.org> it could execute in 10 seconds it won't change anything
<FromGitter>
<asterite> how do you know?
<FromGitter>
<jrei:matrix.org> because it collect keys only once. After you have it, no need to run again
<FromGitter>
<asterite> also, that's your preference, not mine
<FromGitter>
<jrei:matrix.org> there are danger, like becoming out of sync with the actual code
<FromGitter>
<djberg96> @naqvis yep, that's a very handy shortcut, thanks
<FromGitter>
<oprypin:matrix.org> how can i create a regex literal from a macro?
<FromGitter>
<oprypin:matrix.org> i have its source as a string, i just worry about messing up the escapes
<FromGitter>
<Blacksmoke16> pass the string to `Regex.new`?
<FromGitter>
<oprypin:matrix.org> i want a cached one
<oprypin>
erdnaxeli:cervoi.se, it's accessing a variable of an instance of the same type
<oprypin>
such accesses are the only ones that are not frowned upon. no better alternative was found so this syntax was kept.
<FromGitter>
<erdnaxeli:cervoi.se> which is weird too
<FromGitter>
<erdnaxeli:cervoi.se> so actually ivars are public, wow :D
<FromGitter>
<Blacksmoke16> please dont go using this everywhere in your code tho
<FromGitter>
<oprypin:matrix.org> erdnaxeli (https://matrix.to/#/@erdnaxeli:cervoi.se): i don't know what you'd say if you were using Python
<FromGitter>
<erdnaxeli:cervoi.se> I won't ^^
<FromGitter>
<oprypin:matrix.org> ahhahaha i can access everything zomg
<FromGitter>
<erdnaxeli:cervoi.se> oprypin (https://matrix.to/#/@oprypin:matrix.org): I am actually payed to be a python dev :p
<oprypin>
then you see my point :>
_ht has quit [Remote host closed the connection]
<FromGitter>
<jrei:matrix.org> in essence a program is mutable at runtime, so...
<FromGitter>
<jrei:matrix.org> In most languages we can do this kind of unsafe things
<FromGitter>
<jrei:matrix.org> please tell me those we can't, I only know a bunch of them
<FromGitter>
<asterite> if ivars weren't publics, you can reopen a type and add a getter for them. So there's really no way to prevent someone from accessing ivars. The same is true in Ruby and you can do `instance_var_get(...)`, so in Crystal we have the same but embedded in the syntax
<FromGitter>
<asterite> also, there's no need to use `\` after `&&` or `||`, just write a newline and let the formatter format it. It aligns things pretty nicely (I think)
<FromGitter>
<mattrberry> Is there a nice way to accomplish something like this? https://carc.in/#/r/acwh
<FromGitter>
<mattrberry> Is the only way to enforce types in macros to put a check at the top of the macro?
<FromGitter>
<Blacksmoke16> pretty much yea
<FromGitter>
<Blacksmoke16> or just let the compiler yell at you
<FromGitter>
<mattrberry> Pretty much all of my cases will be just checking equality with `==`, so the compiler wouldn't yell. I'll definitely put some guards at the top of the macros to make sure I don't waste tons of time finding some stupid bug haha
<FromGitter>
<Blacksmoke16> its also possible to unit test macro code somewhat
<FromGitter>
<Blacksmoke16> as im ignoring the rest of the path
<FromGitter>
<mattrberry> I'd want the compiler to catch the `table[4] =` so that I don't shoot myself in the foot with a stupid copy-paste mistake at some point down the road https://carc.in/#/r/acyd
<FromGitter>
<mattrberry> But since the only things I use those for is to check `==`, the compiler won't complain unless I specifically add guards for those types
<FromGitter>
<mattrberry> Ideally I’d be able to specify types on the macro as I would on any function, but I’m guessing that since that doesn’t exist already, it’s probably a challenging problem to solve
<FromGitter>
<Blacksmoke16> not sure i entirely follow but 👍
<FromGitter>
<mattrberry> I just want to limit the types of the args that I’m calling the macro with. Since the macro only emits code that calls `==` on its args, the compiler won’t complain. If I want a macro to only work on integers, for example, I’d want it to throw an exception if I try to call the macro with “1” instead of 1, which it currently won’t do. I’m just trying to find a way to guard the types since we
<FromGitter>
... don’t have syntax like `macro foo(num : Int32)`