<FromGitter>
<watzon> Most recent call is last right?
<FromGitter>
<Blacksmoke16> prob
<FromGitter>
<watzon> Must've been a cache issue. I found where the problem was, commented out the code, it compiled, added the code back, still compiles.
<FromGitter>
<watzon> Wtf
<FromGitter>
<Blacksmoke16> nice
<FromGitter>
<watzon> Would there be a way to get the
<FromGitter>
<watzon> For instance
<FromGitter>
<watzon> I have a `subscribe` macro that adds event listeners for a class and is meant to be used in the initializer, and I want to get the class that the macro is being called inside of
<FromGitter>
<watzon> Ideally without passing the class to the macro
<FromGitter>
<watzon> I thought `@def.receiver` might work, but it doesn't
<FromGitter>
<Blacksmoke16> You try the type one?
<FromGitter>
<watzon> Yeah `@type` just returns the class the macro is defined in
deavmi has quit [Read error: Connection reset by peer]
<FromGitter>
<watzon> The reason is, right now I have to do this
<FromGitter>
<watzon> But it doesn't work well for subclasses. I'm doing `has_method?` calls and the subclass might have methods that the parent doesn't.
<FromGitter>
<Blacksmoke16> Does the user call the macro manually
<FromGitter>
<watzon> Yeah, it has to be called from within a method in the class. I tried just using a module with `macro included` at first, but at that point the compiler doesn't know anything about the methods the class has.
<FromGitter>
<watzon> I guess a workaround would be to just have the user specify the methods manually rather than checking the class to see if certain methods exist
<FromGitter>
<Blacksmoke16> Try a nested macro finished
<FromGitter>
<watzon> Within the `macro included`?
<FromGitter>
<Blacksmoke16> Yea
<FromGitter>
<watzon> Didn't think about that. Let's try.
<FromGitter>
<watzon> Yeah seems like even `finished` doesn't know anything about a classes methods
<FromGitter>
<Whaxion> Hello, I got this "strange" error with my code, what can be the cause ? (nextGameId is a String? but it's casted so I don't understand)
<FromGitter>
<Whaxion> (And #to_s doesn't work either)
<FromGitter>
<Blacksmoke16> its not casted tho
<FromGitter>
<Blacksmoke16> you would need to do like
<raz>
which is absurdly useful for building cli apps
<FromGitter>
<watzon> That's what I used as a base
<raz>
awesome to get that on crystal!
<FromGitter>
<watzon> I'm working on getting some other pieces up as well. I want to do `TTY::File`, but before I do that I want a pure crystal impl of the Myers diffing algorithm.
<raz>
all shards welcome, crystal gets awesomer every day
<raz>
poor ruby is gonna have a hard time to compete pretty soon
<raz>
people will be like "yea, it's like crystal, only in slow and impossible to debug"
<livcd>
raz: sorry to break it for you but that's a pipe dream
<FromGitter>
<watzon> 😂
<raz>
livcd: oh, what's stopping us?
<livcd>
raz: $$$
<raz>
i don't see where $$$ comes in ¯\_(ツ)_/¯
<FromGitter>
<watzon> It certainly helps for development and marketing
<FromGitter>
<watzon> Even with a shitty ass language like Go
<FromGitter>
<watzon> Look at its adoption
<livcd>
No? Then look at those companies investing millions in Ruby.
<livcd>
raz: The Sorbet team surely was not cheap.
<FromGitter>
<watzon> Go is a massive pain in the ass. It over hyped and under delivered. A language has definitely *never* done that before.
<livcd>
raz: Go is big because it's good and solves people's issues.
<FromGitter>
<watzon> *cough cough* java
<raz>
for very small and specific values of "good'
<raz>
writing a webapp in go is a horror show
<livcd>
watzon: DHH does not like types.
<raz>
in crystal it's fun
<livcd>
He will not migrate to Crystal.
<FromGitter>
<watzon> Well DHH can suck my eggplant
<livcd>
He sort of mentioned already Crystal is meh.
<FromGitter>
<watzon> Lol oh well
<raz>
DHH is old and long past his heyday
<raz>
we'll have our own DHH
<livcd>
And if he would have cared about performance at all he would make sure Rails works with Graal
<raz>
he doesn't need another ferrari, he already got ten
<livcd>
Well Go is great because it excels at what it was designed to do.
<livcd>
We will see Go's demise if people find out writing Rust is not significantly harder than writing Go.
<raz>
it was designed to serve google's needs. which doesn't overlap all that much with the needs outside google.
<livcd>
And if they manage to push this Cranelift that should help with compile times during dev process...
<raz>
i don't think rust will come out of its niche much. unless they add a GC which they won't do
<livcd>
At the end of the day it's not about the tool (the language) but what can you do with the tool.
<raz>
yup and that's where crystal excels
<livcd>
At what? backend services on linux?
<raz>
yup, cli and infra stuff. high perf servers. etc. but the thing is, crystal is fast enough to even cover many of these use-cases with much more concise and fun codebase.
<raz>
there's not many companies and use-cases that really care about 100k vs 200k requests per second
<raz>
and even in them there's usually only a chosen few bottlenecks that can be done in a faster language while keeping the rest in pretty crystal
_whitelogger has joined #crystal-lang
<livcd>
raz: most of the "infra stuff" is Go stuff that works also on Windows. high perf servers are irrelevant for most people.
<raz>
i hear people are working on it. and serious dev happens on mac/linux anyway.
<livcd>
raz: sorry but no
<raz>
wintendo support is nice, but games will continue to be written in c++
<livcd>
You are thinking AAA games. Plenty of other games can be written in a slower language like this.
<raz>
i don't think being good at games or windows is a barrier to success
<FromGitter>
<watzon> Still really wish you could return from a block sometimes
<raz>
ruby can't do games either and is doing pretty well
<FromGitter>
<Blacksmoke16> @watzon you can?
<FromGitter>
<watzon> You can?
<FromGitter>
<watzon> Using `return`?
<livcd>
Ruby reached the momentum before that was a problem.
<raz>
next!
<FromGitter>
<Blacksmoke16> `next` i think
<FromGitter>
<watzon> Doesn't next just go to the next iteration?
<FromGitter>
<Blacksmoke16> `break`
<FromGitter>
<watzon> And break just breaks out of the block?
<FromGitter>
<Blacksmoke16> i think so?
<livcd>
Ruby lost a lot of momentum due to being particularly good only at 1 thing that does not matter that much anymore.
<FromGitter>
<watzon> In ruby you have break and next, but you can also return directly from the block.
<raz>
livcd: you seem pretty pessimistic ¯\_(ツ)_/¯ - ruby is still plenty relevant. and i see no reason why crystal shouldn't surpass it in a few years.
<livcd>
raz: well Ruby is too big to fail
<livcd>
There will always be some Ruby code somewhere.
<raz>
oh, you mean like COBOL was? :p
<livcd>
Yup
<FromGitter>
<watzon> Hmm interesting. I thought this would fail.
<raz>
i dunno, you seem to think crystal is somehow doomed to never be successful. all the while it grows steadily with shards and mindshare growing every day.
<livcd>
raz: I think Ruby was hit heavily by competition and did not really recover from it. I think the main mistake was the fragmented efforts and multiple runtimes that spawned over time.
<FromGitter>
<watzon> Eh, python has a similar thing going on. But they've still managed to pull ahead.
<livcd>
raz: Look at it from a different perspective. Swift had it all. A newer language, aot compiled, fast. A support from a gargantuan corporation.
<FromGitter>
<watzon> Even with the terrible 2 to 3 transition
<livcd>
And yet it failed to gain the momentum apart from its main platform.
<raz>
watzon: hey, don't be mean. i'm sure they will finish their transition this decade the latest!
<raz>
livcd: swift was never meant to leave its platform. apple doesn't allow it.
<FromGitter>
<watzon> Well at least v2 is finally dead
<livcd>
python is different. It was declared as the defacto entry level language
<livcd>
raz: it was
<livcd>
Apple just did not care about it and here we are.
<raz>
not sure what point you're even trying to make tbh. crystal isn't from apple. :)
<livcd>
raz: Swift is releasing official support on Windows this june
<raz>
yea, so apple can port their stuff to windows. butt apple engineers aren't allowed to have OSS projects, so it's not gonna see much use outside apple. that's what apple wants.
<raz>
apple & swift is a pretty specific case, not really a good comparison to an OSS language like crystal
<livcd>
raz: well the port was done by an engineer at google that is doing swift on tensorflow
<livcd>
Anyway we will see how it develops further.
<raz>
sure, neither swift nor go are gonna way anytime soon. and neither will crystal, unless all the core devs lose interest.
<livcd>
raz: i just wanted to say that it's a combination of factors not a single feature that makes something successful
<FromGitter>
<watzon> Anyone know a good way to reverse an iterator? Unfortunately `Iterator` doesn't have `#reverse_each`
<FromGitter>
<Blacksmoke16> `.to_a.reverse`?
<FromGitter>
<Blacksmoke16> defeats the purpose of an iterator tho
<FromGitter>
<watzon> I guess I'll have to
<FromGitter>
<watzon> Damn
<FromGitter>
<naqvis> @watzon your use-case already beats the purpose of iterator
<FromGitter>
<naqvis> as you want to start from the end
<FromGitter>
<naqvis> that means, you need to consume all
<FromGitter>
<naqvis> why not have the source provide you input in reverse form?
<FromGitter>
<j8r> An iterator doesn't know its size
<FromGitter>
<watzon> True enough. I don't really care so much about the iterator itself, it's just the fact that you cant do `arr.each_with_index.reverse_each`
<FromGitter>
<naqvis> true, that's the main purpose of iterator
<FromGitter>
<watzon> Throwing `to_a` in there works though
<FromGitter>
<j8r> From where this iterator comes from?
<FromGitter>
<naqvis> that's because you are treating Iterator as Enumerator :)
<FromGitter>
<watzon> @j8r `each_with_index` returns an iterator
<FromGitter>
<watzon> If you don't give it a block
<FromGitter>
<j8r> Yep, you don't use it with a block?
<FromGitter>
<Blacksmoke16> prob should close the files in your readme example?
<FromGitter>
<watzon> Lol probably, though they do get closed automatically on exit do they not?
rocx has quit [Read error: Connection reset by peer]
<FromGitter>
<Blacksmoke16> i think so? not sure
<FromGitter>
<watzon> Pretty sure they do
<FromGitter>
<watzon> I'm planning on implementing the diff3 algorithm too for merging
<FromGitter>
<kinxer> I don't think they're automatically closed unless you use the block-based class method (instead of instantiating them).
<FromGitter>
<Blacksmoke16> not via crystal, but the OS might?
<FromGitter>
<kinxer> Yeah, that's fair.
yxhuvud has quit [Remote host closed the connection]
<FromGitter>
<kinxer> I guess it's only an issue if you have a long-running application that's opening different files (you'll get the "too many files open" exception, though, iirc).
<FromGitter>
<kinxer> Oh, also, FYI, the filename for myers linear is misspelled.
<FromGitter>
<kinxer> Otherwise, that looks really cool.
<FromGitter>
<watzon> Lol whoops
<FromGitter>
<watzon> Fixed
<FromGitter>
<watzon> But yes, I'm pretty sure the OS closes files when it cleans up resources
<FromGitter>
<wontruefree> I might be a little behind the times but is ysbaddaden no longer on the core team?
<FromGitter>
<watzon> Is he not? I might be behind too.
<FromGitter>
<watzon> Or was he ever? I know he developed shards, but idk about Crystal itself.
<FromGitter>
<wontruefree> maybe I am wrong
<FromGitter>
<wontruefree> his twitter says former
<FromGitter>
<watzon> Ahh must've been then
<FromGitter>
<watzon> I always assumed he was, but I've never confirmed
rocx has joined #crystal-lang
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
HumanGeek has quit [Remote host closed the connection]
HumanGeek has joined #crystal-lang
yxhuvud has joined #crystal-lang
renich has joined #crystal-lang
<FromGitter>
<didactic-drunk> If not closed by crystal would buffered data be discarded?
<FromGitter>
<watzon> I think `.crystal/shards` is much better than lib
<FromGitter>
<watzon> That's just personally since dotfiles tend to be ignored by default, and there have been times when I've wished I could use the `lib` namespace for library code and `src` for client code
<oprypin>
i don't think ysbaddaden did very many separate contributions but those that he did were usually very big and requiring deep expertise
<oprypin>
welli like the "garbage" not to hide from me tho. really liked my interaction with node_modules, however big it may be that's a separate issue
<oprypin>
source files that are actually being put into your program should not be hidden or implicit in any way
zorp has quit [Ping timeout: 260 seconds]
<FromGitter>
<watzon> I agree somewhat, but dotfiles aren't really hidden in most editors. They are automatically added to most gitignore files though, and don't conflict with public namespaces as easily.
<oprypin>
yea i was just thinking, it's probably time to give up on their "hidden" feature, it doesnt mean anything anymore
<FromGitter>
<Blacksmoke16> @watzon i like to think i had an effect on that decision :p
<jhass>
heh, I need to take a break from that. The whole function pointer mess gave me a headache
<oprypin>
haha
<oprypin>
> On x86 plaftorms, all arguments are widened to 32 bits when they are passed. Return values are also widened to 32 bits and returned in the EAX register, except for 8-byte structures, which are returned in the EDX:EAX register pair. Larger structures are returned in the EAX register as pointers to hidden return structures. Parameters are pushed onto the stack from right to left. Structures that are not PODs will not be returned in registers.
<jhass>
does it explain what a "hidden return structure" is at least?
<FromGitter>
<wontruefree> oprypin: I was not following that issue too closely and I am sorry to see him go
<jhass>
it also still baffels me that calling conventions is nothing LLVM fully abstracts
<oprypin>
jhass, hey it doesnt even say what "Larger structures" means. this is more like a novel than documentation :D
<oprypin>
jhass, yes........
<jhass>
oh, I kinda read that as "larger than 8 bytes" I guess
<oprypin>
well i have a struct that is 2x double and that one breaks, so probably
<oprypin>
oh yeah. wow i need to learn to read
<oprypin>
also this whole part is exclusive to return values...
<jhass>
really, then why does it talk abbout "parameters"?
<oprypin>
ok i mean just the whole middle part. aaa i should stop talking :D
<jhass>
<3
<jhass>
I'll go to sleep now anyways
<oprypin>
good night
<jhass>
thanks!
<FromGitter>
<watzon> I know `File#expand_path` will make an absolute path from a relative one, but I can't remember how to get a relative path from an two other paths
<FromGitter>
<Blacksmoke16> going to be quite the large release
<FromGitter>
<Blacksmoke16> some good stuff in there too (and some stuff waiting to be merged)
<oprypin>
wow i'm getting so annoyed by macOS not propagating LD_LIBRARY_PATH
<oprypin>
`::set-env` in github actions doesn't work for it, while specifying it directly does. but any subprocess loses access to it
<oprypin>
the main issue with that being that I can't even run `env LD_LIBRARY_PATH=foo crystal spec` because, while crystal process gets the variable, the crystal-run-spec.tmp process does not!
<oprypin>
and then there's Ubuntu. just doesn't have /usr/local/lib in its default library path.
<oprypin>
theres just no good way to be cross-platform
<oprypin>
to clarify: `LD_LIBRARY_PATH=foo bash -c 'echo $LD_LIBRARY_PATH'` works, while `LD_LIBRARY_PATH=foo bash -c 'bash -c "echo \$LD_LIBRARY_PATH"'` is empty
<oprypin>
on latest mac
<oprypin>
anyhow, is there any good alternative to `crystal spec`? otherwise i have to add _spec/spec.cr_ and `crystal build spec/spec.cr` followed by running it
<FromGitter>
<Blacksmoke16> Alternative for what reason?
<oprypin>
<oprypin> the main issue with that being that I can't even run `env LD_LIBRARY_PATH=foo crystal spec` because, while crystal process gets the variable, the crystal-run-spec.tmp process does not!
<FromGitter>
<watzon> This is my preferred library for when I need something more robust
<FromGitter>
<Blacksmoke16> think he means for running specs
<oprypin>
wait what that's not wat i mean
<FromGitter>
<watzon> Ohh for running
<oprypin>
also i dont like this at all :>
<FromGitter>
<Blacksmoke16> cant just export the env var versus applying it to the command?
<FromGitter>
<watzon> I've always liked rspec alright. I find the built in spec runner too light.
<oprypin>
Blacksmoke16, same result
<FromGitter>
<Blacksmoke16> hm
<oprypin>
btw export is not some global magic, it's just a shell-specific construct - whether this particular variable will also be passed on as an env variable to subprocesses of this particular shell
<FromGitter>
<Blacksmoke16> or even workflow/job level
<oprypin>
Blacksmoke16, oh ok. well that's what i tried first and it is indeed the exact same effect again
<FromGitter>
<Blacksmoke16> ah gotcha
<oprypin>
in fact, it doesn't even penetrate the first shell process that each step in the workflow executes
<FromGitter>
<Blacksmoke16> > Any new environment variables you set that point to a location on the filesystem should have a *PATH suffix. The HOME and GITHUB*WORKSPACE default variables are exceptions to this convention because the words "home" and "workspace" already imply a location.
<oprypin>
the line `echo "::set-env name=LD_LIBRARY_PATH::/usr/local/lib"` doesnt do anything on mac *in two ways* 1) it's already used as path and 2) the library path variable is not propagated to subprocesses. and on linux it normally also doesnt make sense but ubuntu is special.
<oprypin>
let me try `env:` actually, maybe it'll work
<FromGitter>
<Blacksmoke16> prob be best bet
<oprypin>
nah
<FromGitter>
<Blacksmoke16> rip
<oprypin>
well it's true that it's the most likely to work out of all options