paulcsmith_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
soveran has quit [Ping timeout: 276 seconds]
paulcsmith_ has joined #crystal-lang
kulelu88 has quit [Quit: Leaving]
Oliphaunte has quit [Remote host closed the connection]
ome has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Ping timeout: 276 seconds]
paulcsmith_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
snsei has joined #crystal-lang
trapped has quit [Read error: Connection reset by peer]
Oliphaunte has joined #crystal-lang
Oliphaunte has quit [Remote host closed the connection]
Oliphaunte has joined #crystal-lang
Oliphaunte has quit [Remote host closed the connection]
slash_ni1k has quit [Changing host]
slash_ni1k has joined #crystal-lang
slash_ni1k is now known as slash_nick
Oliphaunte has joined #crystal-lang
Oliphaunte has quit [Remote host closed the connection]
qard has joined #crystal-lang
datanoise has joined #crystal-lang
soveran has joined #crystal-lang
<FromGitter>
<jwoertink> I'm running in to this compile error which confuses me a little. I understand why I get the error, and how to fix it, but I'm more curious as to how others handle this
<FromGitter>
<jwoertink> The error I get is `Couldn't find overloads for these types: ⏎ - Array(String)#<<(value : Nil)`
<FromGitter>
<jmoriau> add an else clause
<FromGitter>
<jwoertink> Yeah, I noticed that fixes the issue, but in my case, the code will never hit an else clause, so I don't see a reason to have it
<FromGitter>
<jwoertink> but is that the normal way people would handle that?
<FromGitter>
<jwoertink> Also just doing a `raise "fail" if x.nil?` fixes it too.
FromGitter has quit [Quit: Shutting down]
soveran has quit [Ping timeout: 244 seconds]
<FromGitter>
<jmoriau> well you tell the compiler @things are all of type String but with no else clause it can't know that x won't sometimes be nil. So when you add x to things it will tell you that it can't do that because x might be nil.
<FromGitter>
<jwoertink> so doing something like `else ""` wouldn't be weird?
ome has quit [Quit: Connection closed for inactivity]
<FromGitter>
<jmoriau> (the hash being a constant you define elsewhere)
<FromGitter>
<jwoertink> Thanks. I'll mess around with other ways of doing it.
soveran has joined #crystal-lang
Dreamer3 has quit [Ping timeout: 246 seconds]
Dreamer3 has joined #crystal-lang
snsei has quit [Remote host closed the connection]
matp has quit [Ping timeout: 264 seconds]
qard has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
snsei has joined #crystal-lang
qard has joined #crystal-lang
qard has quit [Client Quit]
snsei has quit [Ping timeout: 272 seconds]
datanoise has quit [Ping timeout: 264 seconds]
badeball_ is now known as badeball
Guest__ has joined #crystal-lang
coderobe has quit [Ping timeout: 250 seconds]
datanoise has joined #crystal-lang
<Davy_CC>
In http://crystal-lang.org/docs/syntax_and_semantics/assignment.html, it says: "Each of the above kinds of variables will be explained later on." But the section of "Local variables"(4.3) and "Global variables"(4.4) are before "Assignment"(4.5), should we changes the order make this more fluent? (Assignment then Local/Global variable)
datanoise has quit [Ping timeout: 244 seconds]
<BlaXpirit>
how can I make a union type at compile time based on a value? for example,
soveran has quit [Remote host closed the connection]
datanoise has joined #crystal-lang
datanoise has quit [Ping timeout: 250 seconds]
ruslux has joined #crystal-lang
dhk has joined #crystal-lang
soveran has joined #crystal-lang
FromGitter has joined #crystal-lang
snsei has joined #crystal-lang
coderobe has joined #crystal-lang
snsei has quit [Ping timeout: 264 seconds]
A124 has quit [Read error: No route to host]
A124 has joined #crystal-lang
ruslux has quit [Ping timeout: 250 seconds]
DeBot has quit [Quit: Crystal IRC]
DeBot has joined #crystal-lang
<coderobe>
Is DeBot written in Crystal?
soveran has quit [Remote host closed the connection]
<jhass>
coderobe: yes
get_durnk has joined #crystal-lang
Raimondi has joined #crystal-lang
<coderobe>
Nice. I'm guessing the code execution bit isn't part of the bot but instead just an api-call to carc, right?
<jhass>
yes
dhk_ has joined #crystal-lang
<jhass>
it used to be initially in fact, but then I extracted that into its own service
dhk has quit [Ping timeout: 240 seconds]
soveran has joined #crystal-lang
soveran has quit [Changing host]
soveran has joined #crystal-lang
<get_durnk>
asterite has me rolling with that "still no windoze" in the comments of the newest blog post
datanoise has joined #crystal-lang
Oliphaunte has joined #crystal-lang
<FromGitter>
<zcassini> next month microsoft is supposed to release the whole ubunutu on windows thing. that might support the crysal stdlib
<get_durnk>
windows is a shit platform, who cares
<get_durnk>
they should regroup and just ship windows 11 as a fork of debian or something
<get_durnk>
that'd be neat
<FromGitter>
<zcassini> theyd mess it up still
<coderobe>
they opensourced .net right? so that'd actually work. I dont think it'd be feasible for them (yet) though
<jhass>
@zcassini people got it running in the preview already. but it's still an entirely different thing than native windows support
<get_durnk>
i mean, xamarin forced their hand to open .net
soveran has quit [Remote host closed the connection]
<get_durnk>
dont kid yourself into thinking ms gives half a shit whether .net is foss or not, because they dont
datanoise has quit [Ping timeout: 272 seconds]
<get_durnk>
these are metastrategies that they're using purely for market share
<txdv>
i think xamarin gives a shit
<get_durnk>
well yeah
<get_durnk>
obv
Oliphaunte has quit [Ping timeout: 244 seconds]
<get_durnk>
but xamarin isnt microsoft. they were acquired, but only because the terms were favorable
<get_durnk>
the last time ms tried to acquire xamarin, they had shitty terms and xamarin told them to fuck off
<txdv>
u durnk go gome
<get_durnk>
they've tried to acquire xamarin mulitple times already
<FromGitter>
<zcassini> theyr're holding out for 26 billion
<get_durnk>
that does not sound right
<get_durnk>
are you thinking of the linkedin acquisition?
<FromGitter>
<zcassini> yeah im just saying that want that money
<get_durnk>
the number I heard was <500m
<coderobe>
off topic but why did m$ aquire linkedin anyway?
<get_durnk>
the social graph implications, I'd assume
<FromGitter>
<zcassini> so they can hide developer resumes from the competition
<FromGitter>
<zcassini> obiously
<coderobe>
zcassini: lol
<get_durnk>
and also to try and get people dogfooding into the MCP program
<get_durnk>
for certs and stuff
<get_durnk>
I've heard that some companies will pay more for the same experience if you have a MCP cert, and in some cases, MS even gets a cut from the hire if the candidate has a good enough cert
<get_durnk>
like the MS MVP people, those guys are making fat $$$, but MS also makes money when those guys get hired
dhk has joined #crystal-lang
dhk_ has quit [Ping timeout: 240 seconds]
swav has joined #crystal-lang
soveran has joined #crystal-lang
<crystal-gh>
[crystal] david50407 opened pull request #2850: Re-order the section, Assignment, to make more fluent (gh-pages...docs/reorder_assignment) https://git.io/vo0jr
<crystal-gh>
[crystal] jhass closed pull request #2850: Re-order the section, Assignment, to make more fluent (gh-pages...docs/reorder_assignment) https://git.io/vo0jr
bjz has joined #crystal-lang
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dgaff has quit [Ping timeout: 276 seconds]
fryguy9 has joined #crystal-lang
matp has quit [Ping timeout: 240 seconds]
bjz has joined #crystal-lang
matp has joined #crystal-lang
datanoise has joined #crystal-lang
wmoxam_ is now known as wmoxam
wmoxam has quit [Changing host]
wmoxam has joined #crystal-lang
<get_durnk>
jhass, is crystal going to get .extend?
<get_durnk>
I was thinking about classes where arguments are generic, and then having mixins with typed arguments
pawnbox has quit [Remote host closed the connection]
<jhass>
very unlikely
<jhass>
and you can already very easily solve it with composition
paulcsmith_ has joined #crystal-lang
<jhass>
practically runtime free if you use a struct
Raimondi has quit [Quit: All hail WeeChat 1.5-dev!]
<get_durnk>
thank u
Raimondi has joined #crystal-lang
matp has quit [Remote host closed the connection]
matp has joined #crystal-lang
xaxes` has joined #crystal-lang
paulcsmith_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
paulcsmith_ has joined #crystal-lang
<Davy_CC>
jhass: in Multiple Assignment it says that if the right-value is only one expression, it is considered an indexed type and the syntax sugar will applied. e.g.: `one, two = "1,2".split(",")` But what will happend if the right-value is not an indexed type?
dom96 has quit [Changing host]
dom96 has joined #crystal-lang
<jhass>
Davy_CC: undefined method [] for Foo, I imagine
<FromGitter>
<taylorfinnell> Is `@{{field_name.id}} : Array({{ field_type.id }})` not the correct way?
<FromGitter>
<taylorfinnell> `instance variable '@int32_arr' of AssignClass1 was not initialized in all of the 'initialize' methods, rendering it nilable`
<FromGitter>
<taylorfinnell> The old syntax that worked in previous versions was
<FromGitter>
<taylorfinnell> ` @{{field_name.id}} = [] of {{ field_type.id }}`
<jhass>
that should still work
<jhass>
the latter that is
<jhass>
the former is "correct" too, depending on what you want
<FromGitter>
<taylorfinnell> Hrmmm, does the `#Nil` denote something? I can't find it in the docs
<FromGitter>
<taylorfinnell> ``` ⏎ instantiating 'AssignClass1#int32_arr()' ⏎ in macro 'repeated' /Users/tfinnell/Development/protokol/src/protokol/message.cr:48, line 3: ⏎ ⏎ 1. @int32_arr = [] of Int32 ⏎ 2. ⏎ 3. def int32_arr : Array(Int32)#|Nil ⏎ 4. val = @int32_arr ⏎ 5. if val != nil ⏎ 6. val ⏎ 7. else ⏎ 8. [] of Int32 ⏎ 9. end ⏎ 10.
<asterite>
I set CRYSTAL_CONFIG_VERSION to 0.18.1 in travis
<asterite>
so compiling and running that spec will work
<asterite>
I think maybe CRYSTAL_CONFIG_VERSION=ci was set because otherwise the `git` command would fail?
<jhass>
perhaps
<asterite>
Let me try remove it :)
<jhass>
either doesn't feel like the right solution
<jhass>
we can't expect anybody to set CRYSTAL_CONFIG_VERSION when working with head
<jhass>
*everybody, even
<asterite>
I'm doing that now... maybe we should set it in the Makefile
<jhass>
0.18.0dev or so?
<jhass>
sigh
<crystal-gh>
[crystal] jhass pushed 2 new commits to master: https://git.io/voE7S
<crystal-gh>
crystal/master 8a67433 Jonne Haß: Fix printf call for LibSSL/LibCrypto
<crystal-gh>
crystal/master 4a754e9 Jonne Haß: Merge branch 'release/0.18'
<jhass>
now how did that happen
<jhass>
asterite: please always push master and release/... together
<crystal-gh>
[crystal] jhass pushed 1 new commit to master: https://git.io/voE5e
<crystal-gh>
crystal/master 781bbe3 Jonne Haß: Merge branch 'release/0.18'
<asterite>
jhass: why?
<jhass>
because if you don't somebody can push master while they can't push release/...because you pushed release/... in between them committing to release/..., merging to master and trying to push both
<jhass>
which just happened for me
<asterite>
I see
<asterite>
I still don't understand why travis fails :(
<asterite>
I do the same on my machine and it works
<jhass>
I'll eat something and then I'll try to come up with a nice solution
<crystal-gh>
[crystal] mperham opened pull request #2855: Add elapsed runtime tracking for verbose spec output, fixes #2854 (master...master) https://git.io/voEdl
<jhass>
asterite: would you be open to having development versions such as 0.18.0dev or 0.18.0-50?
<jhass>
where 50 is 50 commits since 0.18.0
<asterite>
Mmm... why would we need that?
<asterite>
Ideally I'd like to release 0.18.1 today, all important issues were fixed :)
<jhass>
to differentiate in the stdlib specs between last release and HEAD
<asterite>
shouldn't HEAD always be "next version"?
<asterite>
it's not only specs, it's also code that changes according to the version
<asterite>
I have to do some other things too, will probably be back in a couple of hours or more... the build seems to be failing only for arch now, don't know why
<jhass>
asterite: I don't get why you think Crystal::VERSION can be 0.18.1 anywhere atm, it's set nowhere to that and no command can possibly output it yet
<jhass>
asterite: so you want to keep release/0.18 compilable with 0.17.4 or what?
coderobe has joined #crystal-lang
<coderobe>
holy shit, i just got a bluescreen on linux
<jhass>
sounds like someone playing a joke at you :P
<coderobe>
jhass: i have absolutely no idea what happened tbh, i was doing the usual stuff and then my framebuffer corrupted and refreshed with the typical windows-bsod-colored background
<coderobe>
weird
<jhass>
using wayland already?
<coderobe>
nah, x11
<jhass>
interestingly meanwhile latest gnome feels more stable on wayland for me
<jhass>
less memory bloat by it or Xorg
<jhass>
most stuff still runs through XWayland of course
<coderobe>
last time i tried wayland the cursor selection wouldn't work and desktop icons weren't implemented yet
<asterite>
jhass: yes, because I though about compiling 0.18.1 with 0.17.4... we can probably start working with 0.18.0 and remove those checks
<asterite>
it'll also be easier when merging things back to master
<jhass>
I think that would simplify things greatly :)
<asterite>
I'll do that now
<jhass>
commitments like every patch release of a minor version should compile with the latest patch release of the previous minor version are great once we hit a stable version, but I think for now they're a bigger burden than possible benefits
<jhass>
and even then I would probably only commit to something like every release of a major version should compile with the last release of the previous major version, disregarding incompatibilities within the major version itself
<jpittis>
Hey folks. Messing around with Crystal and noticed that String methods don't specify a return type. Is this intentional or is the plan to add types in the future? I'll open up an issue if so.
Philpax has quit [Ping timeout: 252 seconds]
<BlaXpirit>
jpittis, it's like that all throughout the standard lib
<jpittis>
The only reason I noticed was that my objects instance variable assigned to a YAML method was inferred and the instance variable assigned to a String method failed to infer.
<jpittis>
That seems like unwanted behaviour.
<BlaXpirit>
jpittis, I don't think that would help for that case
<BlaXpirit>
the instance
<BlaXpirit>
oops. the instance variable inferring seems like a bit of a sore spot to me.
<BlaXpirit>
jpittis, it has multiple different specific cases where it's automatic, and a method call is not one of them, whether the return type is specified or not
<jpittis>
hrmm. Is there an issue open to change that, is it intentional behaviour or should I open one?
<jhass>
for the moment it's intentional
<jpittis>
jhass: for what reason?
<jhass>
to keep the algorithm simple and thus fast
<BlaXpirit>
if the return type is specified, I don't think it would violate those conditions
<jpittis>
jhass: should I open an issue for the future?
<jhass>
jpittis: oh I hoped you present it a bit more clearly
<jhass>
it won't work generally
<jhass>
just won't happen anymore
<BlaXpirit>
jpittis, yeah... that's not gonna convince anyone
<BlaXpirit>
especially if the code is broken
<jhass>
it might happen for stuff that has explicit return type annotations
<jhass>
but we decided against it for consistency
<BlaXpirit>
that's what I thought was worth bringing up
<jhass>
it'd be weird if it worked for some stuff but not for others
<BlaXpirit>
that's the way it is now - "works for some stuff but not for others"
<BlaXpirit>
and after this change it would be works for stuff with a clearly specified type
<jhass>
the issue is you don't see on the call side whether it has
<jpittis>
I'm sorry I didn't realize that wasn't clear. I'll close the issue. I'm not sure I feel comfortable creating a "better" issue as I have yet to be an active member of the Crystal community.
<jhass>
@foo = a.b; @bar = a.c; first works, second not? why? because b has a return type annotation but c has not
<BlaXpirit>
jhass, I know, yeah. still don't like this
<jhass>
jpittis: well I'm sure BlaXpirit would like to assist you to rework it into something more clear :)
<jpittis>
I'd be pleased to rework it with a bit of help. I know BlaXpirit might not thing it's worth their time. :)
fryguy9 has quit [Quit: Leaving.]
<BlaXpirit>
I already see jhass's arguments and I feel they're more convincing already
<jhass>
well nvm then :P
<asterite>
there's also the thing I say in the end: everyone will want to put return type annotations, and we'll become Java
<BlaXpirit>
asterite, sigh, nothing bad about annotations. I strongly feel that standard library documentation should have them everywhere
<BlaXpirit>
whether it's specified in the code or automatically determined
<Yxhuvud>
I like specifying types that ends up as memory layout but totally hate speciying call signatures.
<Yxhuvud>
data matters. signatures doesn't.
jpittis has quit [Ping timeout: 250 seconds]
<asterite>
BlaXpirit: the problem is that sometimes you can't express the return type
<asterite>
`def foo(x, y); condition ? x : y; end`. So in the end it will always "sometimes" work
<BlaXpirit>
asterite, then this problem should be solved
<asterite>
it can be solved, look at languages like Rust or Scala
<asterite>
def foo[T : Equatable, U : Equatable](x : T, y : T) where blah blah blah
<asterite>
I'd like to keep the language simple to read/write :-)
<asterite>
so there's always a tradeoff
<BlaXpirit>
asterite, fine, don't specify return type when it's a pain. but otherwise why not?
<BlaXpirit>
reading a method and having to manually figure out what it does is not something I enjoy
<asterite>
we can do that, and we could probably make it work for simple cases, but it'll be very hard to do for the general case
<asterite>
right in that example there was str[0..str.size], so we'd need to type that range literal
<asterite>
we could make it work for simple cases, like x.to_i, foo.tap, etc.
<BlaXpirit>
this is very interesting to think about
<BlaXpirit>
what differentiates the situations where the type is known for sure, directly, and when it is not
<jpittis>
My naive worry about the "don't want people specifying return types everywhere" argument is that my only solution to this issue is specifying the type of my instance variable at the top of my class.
<jpittis>
For consistency reasons, I'll want to specify ALL my instance variable types at the top of my class.
<jpittis>
How is that also not "becoming like Java"
<jhass>
in java you need to do both ;)
<jpittis>
Yup. So if I have to choose between doing it for return types or doing it for instance variables, personally I'd rather do it for return types. Grumbllbbl I don't know...
<BlaXpirit>
jpittis, honestly I'd prefer to specify both because it's free documentation for the future me
<jpittis>
tbh BlaXpirit me too... which solves my personal problem... just specify everything a screw the inconsistencies! :)
sp4rrow has joined #crystal-lang
<BlaXpirit>
and I don't see how in the standard library this free and essential documentation is disregarded in favor of what... less writing?
<asterite>
BlaXpirit: we can do it for the standard library, and I think all libraries should do this for public APIs. Forcing that is a different thing
<BlaXpirit>
I didn't mean forcing... well I did say "standard library documentation should have them everywhere" but ..
soveran has quit [Remote host closed the connection]
<crystal-gh>
[crystal] jhass pushed 1 new commit to master: https://git.io/vouMz
<crystal-gh>
crystal/master a6cc655 Jonne Haß: Merge branch 'release/0.18'
<asterite>
jhass: we could merge #2855 to 0.18.1, just tried it and it works well and it's pretty useful
<asterite>
what do you think?
<jhass>
lgtm
<jhass>
asterite: shall I do the magic?
<asterite>
of course :-P
<asterite>
once travis gives the ok
<jhass>
cool
<asterite>
and then I guess I'll update the changelog and start the release process :)
<jpittis>
Also, being new: The documentation / APIs are quite awesome! <3
<jhass>
asterite: cool, I guess I'll try to get some sleep ;)
<jhass>
then
<jhass>
asterite: oh while I have you, I wondered about the homebrew formula, you say you want to use the previous compiler as bootstrap in it, but won't that quickly break the build for the head variant/build?
<jhass>
I've been using the latest release as bootstrap in the arch packages always and without issues so far
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
<jhass>
asterite: mmh, should I just format the code in the merge for #2855? :P
<asterite>
jhass: sounds good
<asterite>
jhass: I mean, use 0.18.0 to use 0.18.1
<asterite>
would that work?
sp4rrow has joined #crystal-lang
<jhass>
asterite: am I'm understanding correctly that the homebrew formula has a mode to build/install master?
<asterite>
yes, you pass `--head` to it
<asterite>
and 0.18.0 should compile head, because that's what we are using. I think it's fine
<jhass>
asterite: so, am I also understanding correctly that we only ensure that master can be build by the latest release, I mean generally, we don't guarantee it for any prior version?
<asterite>
(though I'd personally remove that option from the formula)
<asterite>
exactly
<jhass>
so, if we then don't use the latest release in the formula, the --head version will quickly break
<asterite>
Ah, I see what you mean. So you want to use 0.18.1 to build 0.18.1?
<jhass>
yes
<asterite>
The problem with that is that the binary will be different from the one compiled using 0.18.0 and that might be problematic
<asterite>
I personally wouldn't worry about the `--head` option, I'd like to remove it
<jhass>
I see that point, but as said we've been doing it for the archlinux package since forever
<jhass>
and in practice there wasn't a single bug related to it
<jhass>
damn, now I forgot the formatting over squashing it and rebasing it --
<jhass>
-.-
<asterite>
Don't worry, it's one commit more :)
<asterite>
Let's do this, let's use 0.18.0 as the boot for now, and I'll check with waj what he thinks. Compiling head with the latest is fine, compiling the next version with that same version, I don't know
<crystal-gh>
[crystal] jhass pushed 1 new commit to master: https://git.io/vouSw
<crystal-gh>
crystal/master e67cbb0 Jonne Haß: Merge branch 'release/0.18'
<jhass>
asterite: sure your decision in the end, just wanted to make sure you're aware of the issue because tbh I wasn't quite sure you got it until now :)
<asterite>
maybe there's a way to choose a different boot version for head, I'll check
<asterite>
(later)
<jhass>
that'd be ideal I guess, yeah
<jpittis>
Currently there's no way to render a String with ECR in it right?
<asterite>
Right, that's missing, though it would be nice to have
<jhass>
perhaps a flag to ecr/process so we don't need to have two
<jhass>
or even have the parent read the file at compile time
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vouHn