<DeBot>
asterite: in line 3: undefined local variable or method '“hey”'
<asterite>
def foo; $~ = "hey"; end; foo; $~
<asterite>
>> def foo; $~ = "hey"; end; foo; $~
<DeBot>
asterite: "hey"
<asterite>
:)
<asterite>
jhass: do you want to be an op here, so you can change the subject?
<jhass>
asterite: I'll accept a PR that replaces those quotes :P
waj has joined #crystal-lang
<asterite>
i’ll accept suggestions for a decent irc client in mac :(
<jhass>
asterite: if you're talking about general access right, I'd be honored, however I count to the people that consider having the operator flag permanently visible bad IRC etiquette ;)
<jhass>
also maybe you should learn to set the topic, it's easy :P
<jhass>
which client do you use?
<asterite>
You mean because it could somehow be interpreted as “these are more important”?
<jhass>
it shows authority and people unfortunately are influenced by that
<asterite>
I see… so how can I login with being an op and still change the subject?
<jhass>
you have the +O flag set in ChanServ, that's why you get them on login
<jhass>
if you remove that flag and have just +o, you can manually obtain op by doing /msg ChanServ OP #crystal-lang asterite
<jhass>
I have such a thing on a command alias ;)
<jhass>
ChanServ also provides commands to do operator actions such as changing the topic and kicking someone, see /msg ChanServ HELP
<asterite>
Thanks. I’ll de-op myself later and change the subject :)
<jhass>
though, while not critical for changing the topic, I wouldn't proxy it through ChanServ, a user should be able to see who removed them from the channel for example
<jhass>
asterite: you currently only have +Oo, so only waj can change the channel access controls, you probably should get +f and maybe +F from waj ;)
<jhass>
/msg ChanServ HELP FLAGS has some explanations
<asterite>
We are both irc newbies :)
<jhass>
we all start somewhere ;)
<jhass>
also as said, if you want me to manage the channel, I'd be honored to do so ;)
<jhass>
I hear that colloquy is the recommended GUI client on OS X
<asterite>
I think I wouldn't recommend it :)
<asterite>
I now switch to adium… but sometimes it doesn't connect
<epitron>
Quassel or wee chat are my faves
leafybasil has quit [Remote host closed the connection]
<asterite>
epitron: which one you prefer most?
<jhass>
I'm on weechat too, though it requires some customization to be pleasant to look at and you still need to like the look of CLI apps
weskinner_ has quit [Ping timeout: 264 seconds]
weskinner_ has joined #crystal-lang
weskinner_ has quit [Quit: Leaving]
asterite has quit [Quit: Leaving.]
asterite1 has joined #crystal-lang
<jhass>
asterite1: can I get the numeric value of an enum?
<jhass>
>> enum Foo; A; end; Foo::A.to_i
<DeBot>
jhass: Error in line 3: undefined method 'to_i' for Foo (did you mean 'to_s'?)
<asterite1>
.value
<jhass>
ah, ty
ismaelga has quit [Remote host closed the connection]
<jhass>
okay, that was dumb. Fixed the -fPIC problem, long time ago in fact, forget to purge the cache when testing
ismaelga has joined #crystal-lang
<crystal-gh>
[crystal] jhass opened pull request #417: Switch default relocation mode to PIC (master...build_relocatable) http://git.io/N21r
<epitron>
asterite1: depends on you. I like weechat the most because it has a great android client that can connect to the running weechat insurance
<epitron>
*instance
<asterite1>
jhass: does that PIC flag mean something else?
<jhass>
what do you mean?
waj1 has joined #crystal-lang
waj has quit [Ping timeout: 265 seconds]
<asterite1>
Mmm… why llvm provides an option to not set that flag? Does it affect performance?
<asterite1>
Or, why the default is not PIC?
<jhass>
it seems to be a tiny bit slower, yes
<jhass>
although for example shared libraries already have to be compiled with -fPIC
<jhass>
so you already have tons of code running that way
<jhass>
also I didn't change the linker to link with -fPIE by default
<asterite1>
Wouldn't it be better to allow to set the mode with a flag?
<jhass>
so I didn't verify, but I guess the resulting binary won't change in the process, it just allows to use a wrapper around ld that sets the flag
<jhass>
it makes the .o files produced relocatable, I see no reason why we wouldn't want that
<jhass>
I actually guess it's not the default for producing object files in LLVM for compatibility reasons with GCC, and it's not the default in GCC for backwards compatibility
<jhass>
I don't know if that's true, but I wouldn't be surprised