<sorcus>
@grkek don't know. Maybe because `grip` not in an awesome list? :-D
<FromGitter>
<grkek> oh my thank you for that, it will be soon ;)
alex`` has joined #crystal-lang
alex`` has quit [Ping timeout: 240 seconds]
alex`` has joined #crystal-lang
flaviodesousa has quit [Ping timeout: 258 seconds]
duane has joined #crystal-lang
<FromGitter>
<yxhuvud> When working with C extensions, what is the normal way to deal with flags that are OR-ed together? Enum doesn't feel right as the eventual value ends up a composite value of several.
<oprypin>
Yxhuvud, we have @[Flags] enums for ORing specifically
<FromGitter>
<yxhuvud> Oh, nice.
Human_G33k has joined #crystal-lang
HumanG33k has quit [Ping timeout: 260 seconds]
sagax has quit [Ping timeout: 268 seconds]
sagax has joined #crystal-lang
Nicolab has joined #crystal-lang
<oprypin>
straight-shoota, has anyone done a 100% automated CI for Windows, or is it all local? maybe it's possible to achieve with CircleCI by alternating the OS choice per job?
<FromGitter>
<straight-shoota> I'm not aware that anyone tried running specs for windows on CI
<oprypin>
straight-shoota, thanks. is there any place to track the latest status? i.e. *some person* ran CI on windows at *this date* and it required *these* workarounds and *these* specs still failed
<FromGitter>
<straight-shoota> Since I'm not sure anyone has ever tried this, I also don't think it's tracked anywhere
<oprypin>
straight-shoota, um sorry i made a mistake. i did not mean to mention CI this time. just trying out Crystal + specs
<FromGitter>
<straight-shoota> Ah, okay. Makes more sense =)
<FromGitter>
<straight-shoota> Still don't think there's a tracker for that
<FromGitter>
<straight-shoota> But it could be time for opening an issue for that
<FromGitter>
<straight-shoota> Until now I've only run win32 specs manually
<FromGitter>
<straight-shoota> And isolated, not the entire suite
<FromGitter>
<straight-shoota> Many parts don't work yet anyway and won't compile
<oprypin>
straight-shoota, oh i'm not sure what you mean by win32 specs
<FromGitter>
<Nicolab> Hello, ⏎ ⏎ Is there a way in Crystal to know all the variables defined in the current scope? ⏎ ⏎ Like `get_defined_vars ();` in PHP or to another measure `global` in JS. ... [https://gitter.im/crystal-lang/crystal?at=5e15f49404adee486b51f95a]
<oprypin>
i dont think so
<FromGitter>
<tenebrousedge> there should be a way to do that in macro land. why?
<FromGitter>
<Nicolab> @tenebrousedge Just to check the variables defined in the scope, to avoid pollution (for example when adding a shard).
<FromGitter>
<Nicolab> I found `local_variables` in Ruby but undefined in Crystal
<FromGitter>
<kinxer> Isn't that what namespaces (one of the uses for `module`s) are for?
<FromGitter>
<tenebrousedge> ^
<FromGitter>
<straight-shoota> oprypin, I just meant specs running on win32
<FromGitter>
<Nicolab> @kinxer Yes but in fact: require('kemal') and lots of shards, add definitions to the current scope.
<oprypin>
oof well that's kemal
<FromGitter>
<Nicolab> There is the solution of going to search each code on Github and with each update redo the same routine. So I prefer to ask in case
<FromGitter>
<kinxer> Will it add the definitions to that `module`?
<FromGitter>
<tenebrousedge> no
<FromGitter>
<tenebrousedge> whatever kemal does, your code should be namespaced, unless you have a really good reason not to do so
<FromGitter>
<tenebrousedge> but one of the features of the language is open classes and methods
<FromGitter>
<tenebrousedge> there isn't any way of turning that off, so conflicts will always be possible, so it's up to all people writing Crystal to do so safely
<FromGitter>
<tenebrousedge> this is also true of Ruby, but Ruby can usually hack around badly behaved libraries
<FromGitter>
<tenebrousedge> I don't recall ever having an issue with this in practice, in either language
<FromGitter>
<tenebrousedge> @Blacksmoke16 do you know offhand how to get local vars in scope in a macro?
<FromGitter>
<Blacksmoke16> idt you can
<FromGitter>
<Nicolab> It's been a week that I do Crystal and I don't know Ruby, so there are maybe a few things that I don't do correctly in import?
<FromGitter>
<Blacksmoke16> is just how crystal works, when you require something it makes all the stuff available, versus using like `import ...` in TS or `use ...` in PHP
<FromGitter>
<Blacksmoke16> namespacing your stuff is the way to go, also helps with making the docs more organized
<FromGitter>
<Nicolab> @Blacksmoke16 I do not criticize, I try to understand to do well.
<FromGitter>
<Blacksmoke16> yea, the type exists but there isnt like `@type.local_vars` to get them
<FromGitter>
<Blacksmoke16> all good bud
<FromGitter>
<tenebrousedge> right, but could you get all vars and then filter by type?
<FromGitter>
<Nicolab> @Blacksmoke16 thanks for the example (`::`)
<repo>
Nicolab: basically `require` works exactly like you would just insert the file contents at that location. (it will take care not to duplicate anything though and also takes care of circular dependencies)
<repo>
if you require a shard, it will require the file src/<shard_name>.cr from the shard repo
<FromGitter>
<Nicolab> Ok
<FromGitter>
<Nicolab> This is exactly why it can be practical to know what is available in the scope
<repo>
shards should never expose anything to global scope except for a module named after the shard
<FromGitter>
<tenebrousedge> should
<FromGitter>
<Nicolab> should but ... :)
<repo>
yes
<repo>
should
<FromGitter>
<Nicolab> get, post, put, before_all, etc etc
<repo>
yeah imho that's bad practice
<repo>
no reason why you couldn't just `include Kemal`
<repo>
one line more
<repo>
and a clean global scope
<FromGitter>
<tenebrousedge> like how e.g. RSpec does it
<repo>
yeah
<repo>
Nicolab: (include will pull everything from the given module (kind of like namespace) into the current one
<FromGitter>
<Nicolab> ah yes!
<FromGitter>
<Nicolab> The reason is that I have to read again this part of the doc because I didn't know that I could import kemal this way.
<FromGitter>
<Nicolab> :D
<FromGitter>
<Nicolab> thanks
<repo>
ternarysolo: but rspec used to pollute namespaces way more before.
<repo>
also monkeypatching everything with `should` methods
<FromGitter>
<Nicolab> ok
<repo>
i like the `expect(...)` syntax way more
<repo>
Nicolab: i think you can't
<FromGitter>
<tenebrousedge> ternarysolo is probably what my username would have been if I had been doing programming instead of art at age 15
<repo>
Nicolab: that was just me saying how it (in my opinion) _should_ be
<repo>
lol did i write that? :D
<repo>
oh no tab completion
<FromGitter>
<grkek> Guys, I added some documentation to the framework !
<oprypin>
it was part of `sudo apt-get install -qy`
<FromGitter>
<tenebrousedge> apt > apt-get
<oprypin>
apt is explicitly not for automation
<FromGitter>
<tenebrousedge> are you an automated script?
<FromGitter>
<tenebrousedge> is sudo a good idea for automation?
<FromGitter>
<tenebrousedge> I think I've done it, with some editing of sudoers
<FromGitter>
<Blacksmoke16> > right, but could you get all vars and then filter by type? ⏎ ⏎ I can't speak for if its possible or not, but currently it's not possible
<FromGitter>
<Blacksmoke16> possible to implement*
<FromGitter>
<tenebrousedge> hmmm
<FromGitter>
<Blacksmoke16> only way to get vars is `instance_vars` or `class_vars` and both of those only work in a method context
<FromGitter>
<Nicolab> @tenebrousedge for automation this allows a Linux user to have the right only for a command (apt), rather than leaving the root right
<FromGitter>
<Nicolab> @Blacksmoke16 ok thanks for the confirmation
<FromGitter>
<tenebrousedge> @Nicolab there are other ways to install things that don't involve using `sudo apt`
<ancorgs>
repo: I didn't get the full conversation. But if you miss the expect syntax in crystal, Spectator is here to save us https://gitlab.com/arctic-fox/spectator
<FromGitter>
<Nicolab> @tenebrousedge like?
<FromGitter>
<Nicolab> give apt rights (or via a group)
<FromGitter>
<tenebrousedge> like puppet, ansible, docker, vagrant, etc. If you're writing scripts that use `sudo apt-get` to install software you should probably find a better solution
<FromGitter>
<Nicolab> indeed, he didn't say it was in Docker or whatever. I answered `sudo` in general (on the host)
<FromGitter>
<Nicolab> otherwise yes a `USER root` and` USER myUser` at the end...
<FromGitter>
<Nicolab> etc
repo has joined #crystal-lang
<oprypin>
jesus christ
<FromGitter>
<ilourt> I don
<repo>
hmm
<repo>
doesn't seem to be working
<repo>
can someone from gitter say something?
<FromGitter>
<tenebrousedge> no
<FromGitter>
<tenebrousedge> chatting is not allowed in the chat
<FromGitter>
<straight-shoota> oprypin, nice! That time limitation is not good, obviously. But it's a start
<FromGitter>
<straight-shoota> I think it's probably best to extract all the steps for preparing the workspace into a separate script. Or maybe a Dockerfile?
<FromGitter>
<straight-shoota> Anyway, I have been progressing with putting together a `std_spec.cr` which includes all specs that compile on win32.
<FromGitter>
<tenebrousedge> docker and circleci play well together
return0__ has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
<FromGitter>
<tenebrousedge> yeesh. Microsoft has Windows docker images, that can only be hosted on the same version of windows 🙄 what useless gits
<FromGitter>
<kinxer> I mean, that's obviously not ideal, but it's still more lightweight than a VM when you need a bunch of small instances or a safe sandbox environment.
<FromGitter>
<tenebrousedge> what?
<FromGitter>
<tenebrousedge> I suppose
<FromGitter>
<tenebrousedge> but as a Linux developer it's pretty useless for me
<FromGitter>
<kinxer> Yeah, that makes sense. I don't think I've ever used Docker on Windows.
<FromGitter>
<kinxer> But I think it's just impossible to make Docker allow a Windows container on Linux without making it not actually Docker.
<FromGitter>
<kinxer> That's what VMs are for.
<FromGitter>
<straight-shoota> > Microsoft has Windows docker images, that can only be hosted on the same version of windows ⏎ ⏎ That's technically not different on linux. Containers run on the same kernel as the host. It's just that releases of linux distributions usually work with a wider amount of kernel versions.
ur5us has joined #crystal-lang
sagax has quit [Ping timeout: 265 seconds]
<oprypin>
i dont understand how the topic of Docker was brought up; that's still a technology exclusive to Linux
<oprypin>
oh wait maybe my information is outdated 😂
<FromGitter>
<tenebrousedge> docker runs on Mac OS and Windows as well as Linux
<FromGitter>
<tenebrousedge> not as well, granted
ht_ has joined #crystal-lang
sagax has joined #crystal-lang
<FromGitter>
<j8r> sure if you use a VM
<FromGitter>
<j8r> I see "native on Windows", I don't know to what extent it is - full Linux kernel emulation, syscalls translation, HyperV, truly native?
<FromGitter>
<straight-shoota> Docker is simply a containerization model, not specifically a linux thing.
<FromGitter>
<straight-shoota> It can work with different backends, one being linux kernel containers (that's how it began, with lxc later libcontainer etc.). But it can also work with virtual machines and even windows kernel backend.
sagax has quit [Ping timeout: 240 seconds]
Nicolab has joined #crystal-lang
ht_ has quit [Remote host closed the connection]
ht_ has joined #crystal-lang
sagax has joined #crystal-lang
<FromGitter>
<ImAHopelessDev_gitlab> seems like, whenever i accidentally pause the building process, i get https://paste.ee/p/S4FoI
<FromGitter>
<ImAHopelessDev_gitlab> and try to build/compile again, i get that. is there a way to clear the cached compiler files or something
<FromGitter>
<Blacksmoke16> what are your thoughts on how to handle HEAD requests?
<FromGitter>
<Blacksmoke16> mainly the `Content-Length` header
<FromGitter>
<tenebrousedge> what does the spec say about Content-Length in HEAD requests? it seems like it shouldn't apply
<FromGitter>
<Blacksmoke16> since the length of the content isnt written if you dont actually execute the action thus the length cant be determined and crystal currently returns 0
<FromGitter>
<Blacksmoke16> > The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request