<FromGitter>
<mgarciaisaia> (of course, in your code you'd do the `some_string = gets(...)` instead of my `.odd?` thing)
<FromGitter>
<mgarciaisaia> You see - my `some_string` variable, just like yours, is of type `String|Nil` - it's a union between the String class and the Nil class
<duckqlz>
ok I get it I was just a little borked with the equivalancy test thanks for the help
<FromGitter>
<mgarciaisaia> The `if` tests *at runtime* if the value is nil or not. If it's not nil, it goes to the first branch - which, at compile time, knows that it means `some_string` is *not* `nil`. So `some_class` drops it's `Nil` class from the union in that branch - it's now a `String` for sure.
<FromGitter>
<mgarciaisaia> The other way happens on the else branch - if code went that way, the variable is 100% a `Nil` instance
<FromGitter>
<mgarciaisaia> BTW, the method you were trying to use is `to_s`, not `as_s`. You could use it to "break" your union type in your example (both `Nil` and `String` have a `to_s` defined), but that's probably *not* the way to go.
_whitelogger has joined #crystal-lang
Dreamer3 has quit [Quit: Leaving...]
LastWhisper____ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<FromGitter>
<schoening> test
Ven has joined #crystal-lang
Ven is now known as Guest76515
Guest76515 has quit [Ping timeout: 240 seconds]
statikowsky has joined #crystal-lang
mark_66 has joined #crystal-lang
<Yxhuvud>
@Frank: Where do you need them?
<FromGitter>
<arc512> Hi all I was wondering if Crystal has solved the issue with multithreading and using multiple cores
<FromGitter>
<bararchy> Not yet, but a workaround using RESUSE_PORT is avilable @arc512
<FromGitter>
<crisward> I've read through the source and tests and can't find any reference to password...
<FromGitter>
<akzhan> I have seen cipher.key=
<FromGitter>
<crisward> @akzhan me too, tried that. I think the key needs to be generated from a salted password. Trying to get compatibility with node version, but I've checked their source too and it's not clear how the password is being generated. The cli version of open ssl is - `openssl enc -aes-256-cbc -salt -in file.txt -out file.txt.enc -k PASS` just not sure how to achieve that from crystal, without resorting to calling out
<FromGitter>
... to the shell.
<FromGitter>
<akzhan> and of course you have limits to key length, so usually you need to hash password by appropriated algorithm.
<FromGitter>
<sdogruyol> have you tried that with ruby
<FromGitter>
<sdogruyol> also what's the padding
<FromGitter>
<crisward> It needs a 32byte key, which I can generate easy enough with OpenSSL::MD5.hash(password) but MD5 isn't secure. Just not sure what node is doing...
early has quit [Read error: Connection reset by peer]
early has joined #crystal-lang
<FromGitter>
<straight-shoota> Unfortunately I can't reproduce it in a simplified environment, there are a few complex things involved.
daemonwrangler has joined #crystal-lang
<FromGitter>
<akzhan> Nothing. But why not if is_a?(String)
<Papierkorb>
Because that's harder to read than a `case` statement built for this
<FromGitter>
<straight-shoota> And it's semantically equal.
balduin has joined #crystal-lang
<FromGitter>
<straight-shoota> With an explicit type restriction on the return value of `object.first.as(Type)` it comes to: `Codegen (crystal): Nil assertion failed`
<FromGitter>
<straight-shoota> I've tried `Enumerable` and `Enumerable` for the when matcher
<FromGitter>
<bew> @straight-shoota what is the type of `@raw` ?
<FromGitter>
<straight-shoota> Replacing `Enumerable` with `Array` works fine...
<FromGitter>
<sdogruyol> Probably a bug related with Union types
<FromGitter>
<sdogruyol> Mostly for modules
<FromGitter>
<straight-shoota> Enumerable itself is not explicitly in the union type. But some types are also Enumerable (including Array)
<Papierkorb>
Ah
<Papierkorb>
Or not.
<FromGitter>
<bew> I've done some minimal tests on `case` with Enumerable, based on an union of other types (to match the kind of type hierarchy @straight-shoota has, with values & container), and it works quite well..
<FromGitter>
<straight-shoota> For my original case I've isolated the problem to `Hash#first` - which returns a tuple. If theres an additional branch for `Hash`, the one for `Enumerable` is fine.
<FromGitter>
<straight-shoota> For the Hash I've resorted to manually create the key-value-tuple: `Value.new({object.first_key.as(Type), object[object.first_key].as(Type)})`
<Papierkorb>
Feel free to reply to my issues straight-shoota
<FromGitter>
<akzhan> found it. b.size is not 65536, looks like read string skip some bytes.
<jokke>
hi
<jokke>
has something changed for macros? i tried to loop through a constant array in a method with {% for foo, in BAR %} but i get unexpected token {%
<crystal-gh>
[crystal] asterite closed pull request #2477: File::Stat: return local time for atime, ctime and mtime (master...feature/file_stat_local_time) https://git.io/vwYfl
snsei has joined #crystal-lang
<RX14>
oprypin, that was going to be my exact reply lol
statikow_ has quit [Remote host closed the connection]
statikowsky has joined #crystal-lang
statikowsky has quit [Remote host closed the connection]
<FromGitter>
<KCreate> Does the `Hash` class have any limitations on how many key - value pairs it could contain?
<Papierkorb>
in theory or practice?
<FromGitter>
<KCreate> practice
<FromGitter>
<KCreate> Like, at what point would stuff just begin to break
<Papierkorb>
Until your memory runs out
<FromGitter>
<KCreate> And in theory?
<Papierkorb>
It's basically a huge linked list, so same
<FromGitter>
<KCreate> Okay
<oprypin>
yeah these hash tables make me crazy, i can never understand how a linked list can ever perform well
<FromGitter>
<KCreate> How would you go about implementing a hash?
<FromGitter>
<KCreate> I only know the approach of having a list of buckets that contain a linked list
sp4rrow has joined #crystal-lang
<oprypin>
well a real hash table is just an array but it uses hashes as indices
<RX14>
oprypin, the idea is to keep the linked lists small
<FromGitter>
<yxhuvud> I have an implementation that so far is way faster for big hashes but slower for small. Which is pretty strange, gotta dig into that
<FromGitter>
<yxhuvud> but the first step before that is proper automated benchmarks
greengriminal has quit [Quit: This computer has gone to sleep]
<sp4rrow>
just curious it seems like other testing frameworks have moved away from extending other objects to test `should` and have moved to `expect_to` I think
<sp4rrow>
Did crystal start before that ?
<sp4rrow>
or is that an intentional choice to work that way
<Papierkorb>
sp4rrow: it's `expect(x).to y`, but yeah
<sp4rrow>
I seem to remember something like that
<sp4rrow>
but yeah
<sp4rrow>
so the main repo it is intentional to patch into objects to test them ?
<Papierkorb>
yeah, I'd also prefer the `expect` syntax
greengriminal has joined #crystal-lang
<sp4rrow>
Ok
<sp4rrow>
yeah I like the assert syntax myself but I think most of the industry does not
<sp4rrow>
lol
<sp4rrow>
but yeah I was curious if it was just a history thing
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
<oprypin>
dang it, i was gonna plug my assert macro but they're gone
<oprypin>
anyway, about hash tables, i thought python switched to using the same implementation as ruby, but apparently not, they're still keeping it as one array but it also remembers insertion order now
<oprypin>
im really curious how they compare
<oprypin>
so why don't i search for it
<RX14>
i don't see why people dislike assert
<RX14>
i simply don't get it, it's 1 keyword before an expression
<oprypin>
they're pre-conditioned
<RX14>
it's clean and easy to read and doesn't add new syntax
<oprypin>
we went through this already, there's no good way to have it outside of the compiler
<oprypin>
so it would not be a fair fight
<Papierkorb>
matrix written verbatim in code?
<Papierkorb>
That'll look funky
<oprypin>
if only there was an easy way to gain followers
<oprypin>
Papierkorb, are u serious right now
<oprypin>
i don't think that was the point
<Papierkorb>
RX14: C++/Qts QtTest also has data driven testing. pretty good stuff.
<RX14>
the matrix i can understand
<RX14>
not liking the matrix hacked together I can understand
<RX14>
but assertions?
<Papierkorb>
assertions as in `assertTrue(foo)`?
<RX14>
no...
<oprypin>
Papierkorb, are u serious right now
<Papierkorb>
oprypin: Are u even contributing right nau
<RX14>
assertions as in `assert < arbitrary expression>`
<RX14>
and it just works
<Papierkorb>
RX14: ..Pass
<RX14>
why
<Papierkorb>
That's not a spec
<oprypin>
see, preconditioned
<RX14>
what lol
<Papierkorb>
there's a reason the testing library, and the test directory, is called `spec`, not `tests`
<RX14>
w h a t
<RX14>
why does it matter when they perform the same darned tests
<RX14>
test the same things
<Papierkorb>
RX14: Are we again in that state where you can't accept others having a different opinion?
<RX14>
just use a different syntax
<Papierkorb>
A spec, or specification, specifies a certain behaviour. You *expect* what's under test to adhere to these.
<oprypin>
basically a BS way to justify a DSL
<RX14>
so if you renamed assert to expect
<RX14>
with the same syntax otherwise
<RX14>
why not?
<oprypin>
it still wouldn't be a DSL so that's stupid lol
<Papierkorb>
RX14: Because I don't like it. If you now say "that's stupid lolololol", think again how you don't like the "expect" stuff.
TheLemonMan has joined #crystal-lang
<RX14>
but i'm just saying I don't understand the advantage of it
<RX14>
and i don't beleive you've given me an answer
<Papierkorb>
Far easier to read to me
<RX14>
foo.should eq(bar) is easter than foo == bar?
<Papierkorb>
You may think it's a break to normal code. This is true, and that is the point: It is not normal code
<RX14>
thats what the assert keyword is for
<RX14>
so you can pick out the assertions
<Papierkorb>
Yes, because that `==` quickly gets hard to find if you have e.g. 5 lines with those, and one is `!=`
greengriminal has quit [Quit: Leaving]
<RX14>
isn't it the same with eq and not_eq ?
<Papierkorb>
`.to` and `.to_not`are of different lengths
<RX14>
isn't this true outside specs?
<oprypin>
so basically `!` is a mistake and should've been `not`
<RX14>
why not make == and != different lengths
<oprypin>
not=
<Papierkorb>
No?
<oprypin>
genius!
<RX14>
i just can't understand it, why we need 2 dsls for producing a boolean value
<RX14>
one for everywhere 8but* specs and one for specs
<RX14>
it seems arbitrary
<Papierkorb>
I foremost can't understand oprypin shitposting here right now
<RX14>
does everything have to be serious?
<Papierkorb>
If you think it's funny to be made fun of, Yes.
<Papierkorb>
I have other things to do than reading that garbage oprypin is producing the last minutes
<FromGitter>
<molovo> I much prefer readable operators. Like `or` instead of `||`, `and` instead of `&&` and `is` instead of `==`. In code and in specs
<RX14>
and *that*'s not offensive?
<oprypin>
<Papierkorb> That's not a spec
<RX14>
if that's the way this discussion is going we should stop now
<oprypin>
that offended my intelligence more
<FromGitter>
<mgarciaisaia> Flamewars.. You never get rid of them :)
<Papierkorb>
RX14: Sadly it is. My point was that in normal code, you have some if, then == or whatever, then comes code, and then another if. There's just much space between those operators. In a test with asserts, you have many asserts right under each other without that space
<RX14>
i spent the last 3 years on small IRC channels having "flamewars" on a massive scale
<RX14>
so yes, i find it hard to know when to stop sometimes
<oprypin>
Papierkorb, you're making things up right now
<FromGitter>
<molovo> Papierkorb: Chainable assertions could alleviate some of that buildup of code
<Papierkorb>
RX14: I totally see why you may like an assert syntax more. But to me, *that* is a personal taste thing. The data-driven stuff however is a useful feature in any case
<oprypin>
oh no, you're comparing to normal code, i guess that makes sense
<RX14>
well i guess i'll just have to build it
<oprypin>
but "specs" and "tests" are the same thing, can't we agree? to me it's just the DSL that makes the difference
<RX14>
i naver had an issue with == vs !=
<RX14>
it seems to be like a very minor nitpick vs the advantages
<RX14>
oprypin, i agree
<Papierkorb>
RX14: You should in fact build it. I'd like to see it in a real world scenario how it plays out.
<RX14>
it's all the same concept: run a function and check if it raises
<oprypin>
Papierkorb, we had demonstrated that already
<RX14>
and you *usually* provide some way of raising
<oprypin>
or, well, you can see all those Python projects that don't invent a silly DSL
<RX14>
we did it with macros but it slowed down the compiler
<RX14>
which is find for a PoC
<RX14>
fine*
<RX14>
but ary didn't like it for whatever reason
<oprypin>
Papierkorb, the "real world scenario" thing is made impossible without accepting it into the compiler, so no can do
<FromGitter>
<akzhan> Anyway Crystal doesn’t limit you to one assertion/xDD design. Take a look at minutest.cr, for example.
<oprypin>
it's just a much worse DSL
<RX14>
this is why we should have compiler plugins
<RX14>
but no they're impossible
<oprypin>
yeah....
<Papierkorb>
impossible due to technical reasons or because "don't want them" reasons?
<RX14>
technical so far
<Papierkorb>
you mean because Crystal can't produce and later use shared libs?
<RX14>
that's the first roadblock
<oprypin>
Papierkorb, without compiler support there are hurdles that actively hurt adoption by making installation harder
<RX14>
hmm
<RX14>
oprypin, we could try writing a spec runner which imported the crystal compiler and ran an additional pass for it
<oprypin>
RX14, im thinking that this should be done in the same way as if it had compiler support but outside of the compiler
<RX14>
and was basically a crystal compiler with 1 extra pass
<FromGitter>
<akzhan> Some of "Data Driven Testing» (as referred) may be implemented just like yet another shard.
<RX14>
it'd be a pain
<oprypin>
yeah hehe i think we're pointing at the same solution
<RX14>
but hopefully we could streamline it
<oprypin>
it could just be a preprocessor that produces a new Crystal source file even
<RX14>
ehh
<RX14>
it'd still need to parse it
<RX14>
and that'd require the compiler
<RX14>
and at that point you've got an ast
<oprypin>
yeah that's not really different
<RX14>
why not just pass it to the codegen visitor
<oprypin>
RX14, I mean that if we have an actual crystal source file, you can directly `require` it so it seems "real". not sure about how the "additional pass" would be integrated
<oprypin>
it would need to be a "wrapper" rather than a "plugin"
<RX14>
by using the same method def to produce 2 behaviours
<oprypin>
yep
<oprypin>
when there's something bad in Crystal, it can almost always be attributed to Ruby
<RX14>
well
<RX14>
ary added it quite late
<RX14>
and i argued against it
<RX14>
so i don't really think we can blame ruby here
hako has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sp4rrow has joined #crystal-lang
<FromGitter>
<mgarciaisaia> If Crystal does something wrong, we can't blame Ruby that much - it was us deciding to keep Ruby's wrongdoing, in any case
<FromGitter>
<bigtunacan> Besides that; Ruby is pretty freaking amazing. So there is that.
<FromGitter>
<mgarciaisaia> I see Crystal as a child growing up. It all started looking like Ruby, but as time flows, Crystal grows, and it wants to learn from it's parent's mistakes more and more
<RX14>
ruby's great but crystal i feel removes all the bad bits
<FromGitter>
<molovo> As an aside, being able to google Ruby syntax when I can’t find documentation for something in Crystal is really helpful
<RX14>
@mgarciaisaia i agree
<FromGitter>
<mgarciaisaia> Last ~year we started to feel we should talk a bit less about Ruby each time
<TheGillies>
what is ruby?
<Papierkorb>
molovo, when you don't find something, feel free to speak up. You won't be the last one who's asking that question, if we can improve the docs to not only mention it, but also makes it easy to search for, that'd be a huge thing
<FromGitter>
<mgarciaisaia> It also happened because we at Manas a couple of new languages which we love full or in parts (Elixir, Swift, Rust, Go, ...), and so we don't "want a compiled Ruby" anymore - it wasn't the idea at any point of time, but it started much closer to that than we are now
hako has joined #crystal-lang
<TheGillies>
I see crystal as something more related to go than ruby
<FromGitter>
<molovo> I’m not a Go fan at all, but Go’s multi-value return would be an awesome feature in Crystal
<TheGillies>
syntax is superficial
<oprypin>
molovo, that's a tuple
<RX14>
i believe that ruby's syntax is the best
<FromGitter>
<redcodefinal> @mgarciaisaia I like that. I think there are really good parts of other ;anguages we can use here. I like the ruby like syntax personally, so I hope that stays.
<RX14>
and that crystal gets confused with ruby so much because there is so *little* to change
<Papierkorb>
molovo, `return {1,2}`, and then just do `a, b = my_awesome_method` to set a to 1 and b to 2
<FromGitter>
<molovo> Holy shit. *runs off to refactor code*
<FromGitter>
<akzhan> this type of assignment, +parameters + return should be documented
<oprypin>
i bet they are
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<FromGitter>
<redcodefinal> I thnk where crystal really shines is more stable metaprogramming than ruby. Ruby has nice metaprgramming but there is a degree of black magic and issues with the order things are run in. Crystal macros are the worlds best compromise to what ruby can do meta wise, and generally any sane ruby metaprogramming is able to be ported here.
<FromGitter>
<akzhan> Macros are too limited yet. I want to manipulate AST more and more. But I’m crazy
<oprypin>
akzhan, that's Nim
<FromGitter>
<bigtunacan> @redcodefinal Where is the black magic you see in Ruby's metaprogramming run order?
<FromGitter>
<akzhan> Yes, Nim already on the my way to learn :)
<TheGillies>
I played with nim a little
<TheGillies>
back when it was still nimrod
<oprypin>
using the actual code at compile time is better than a whole new macro language that has to be limited for some reason and also needs a completely separate implementation for every method
baweaver has joined #crystal-lang
<TheGillies>
yeah
<oprypin>
but none of that matters when the rest is not even close
<TheGillies>
macro specific methods took me awhile to grok
<oprypin>
what other programming languages have on-the-fly union types and duck typing?
<oprypin>
(only languages with fast execution please)
<FromGitter>
<akzhan> None. But price is slower compilation. I suppose that it is good swap.
<FromGitter>
<redcodefinal> @bigtunacan I'm looking through some old code to find a good example but the order you require things when you are doing things at the top level can matter a little too much, especially when you are taking a snapshot of a the current state of all the classes loaded in ruby at a given time. If the snapshot is not done after everything is loaded you will have an incomplete snapshot.
<FromGitter>
<bigtunacan> I don't see the require order being problematic.
<RX14>
on the other hand crystal's macros being limited makes them easy to use but hard to abuse
<FromGitter>
<bigtunacan> I would be more concerned if it didn't matter as it needs to be deterministic.
<RX14>
unfortunately, oprypin and I now want to bause them :/
<FromGitter>
<redcodefinal> @bigtunacan All I'm saying is that there are some issues with the way things can be done at the top level. Crystal macros are safer in the sense that you can only use constants, literals, or variables defined in the macro, and it makes metaprogramming a little more "defined", you generally have an idea of what something will be at any given time.
<FromGitter>
<redcodefinal> @bigtunacan Stuff like `send `transfers over easily depending on how you used it.
sz0 has joined #crystal-lang
* baweaver
should probably bother to learn Crystal already
<oprypin>
that's a pretty good idea
<baweaver>
havenwood is trying to corrupt people again
<baweaver>
I hail from Ruby land over yonder
* Papierkorb
looks up yonder
<Papierkorb>
Not even marked as being an old word. durr
<Papierkorb>
baweaver: Thou shalt be welcome here in this place, where many rubyists found their second home already (*conditions apply)
<RX14>
Papierkorb, is is on google
<RX14>
it's marched "archaic dialect"
<Papierkorb>
RX14: I used dict.leo.org, usually only google words as auto-correct mechanism lul
<baweaver>
word
<RX14>
yay a segfault
<RX14>
this is going to be *fun*
sp4rrow has quit [Ping timeout: 260 seconds]
<RX14>
TIL db.setup_connection
pduncan has quit [Ping timeout: 246 seconds]
snsei has joined #crystal-lang
hako has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sp4rrow has joined #crystal-lang
sp4rrow has quit [Client Quit]
hako has joined #crystal-lang
bjz has joined #crystal-lang
statikowsky has joined #crystal-lang
statikowsky has quit [Remote host closed the connection]
statikowsky has joined #crystal-lang
statikowsky has quit [Remote host closed the connection]
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sp4rrow has joined #crystal-lang
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
hako has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hako has joined #crystal-lang
sp4rrow has joined #crystal-lang
hako has quit [Read error: Connection reset by peer]