<FromGitter>
<MaxLap> There is a vagrantfile in the crystal repo, is it possible to simply use that when trying to work on crystal's repo? (Like, for example, how rails does it with rails-dev-box)
soveran has joined #crystal-lang
soveran has quit [Ping timeout: 256 seconds]
<FromGitter>
<mverzilli> it used to work and the last commit on that file is relatively new (June this year). from what I see in the Vagrantfile it installs the development deps. so give it a try and open an issue if you find any problem.
<FromGitter>
<mverzilli> oops, June last year. my brain's cache invalidation algorithm could use some tweaking :P
<FromGitter>
<mverzilli> It's the same as in a gemfile: "Most of the version specifiers, like >= 1.0, are self-explanatory. The specifier ~> has a special meaning, best shown by example. ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12." (http://bundler.io/v1.5/gemfile.html)
<FromGitter>
<mverzilli> we could add a little reference to the README
<FromGitter>
<sdogruyol> @mverzilli that'd be future proof for anyone
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
<FromGitter>
<sdogruyol> @mverzilli :+1:
<FromGitter>
<exts> @mverzilli I haven't come from the ruby world, so gem's aren't in my vocab :worried: , but thanks for the explanation :)
<FromGitter>
<spalladino> That's something we need to look into: we sometimes (incorrectly) assume some people coming into the language have a Ruby background, so we miss some explanations :-(
<FromGitter>
<exts> i love the language though :)
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Kug3lis has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Kug3lis has joined #crystal-lang
<FromGitter>
<spalladino> Glad to hear that :-)
<FromGitter>
<mverzilli> yeah, sorry, I didn't mean that you should have known it because it is just like in gems. it was more of a "it is just like in gems, when in doubt, if there's no docs and nobody here to reply, check them out". anyway, docs will get better :)
<FromGitter>
<jacksonrayhamilton> Language question: I see that it is possible to redefine methods of an existing class: https://crystal-lang.org/docs/syntax_and_semantics/methods_and_instance_variables.html Is it also possible remove a definition of a method from an existing class? (Use case: A class I am using, which I am not in control of, is "broken," in that it has overloaded a method with a return type that it is not supposed to return, and that
<FromGitter>
... return type is causing my program's compilation to fail, because my program is not supposed to handle this return type.)
Kug3lis has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Kug3lis has joined #crystal-lang
<RX14>
@jacksonrayhamilton can you give an example? Can you override the incorrect method to make it return the correct type?
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
mark_66 has quit [Remote host closed the connection]
<FromGitter>
<jacksonrayhamilton> I would like to create the same functional effect that this diff would have, but in code: http://pastebin.com/pCanSsMG I don't imagine I can override that method, since it is explicitly claiming to return a type.
<RX14>
if you define a method with the same arguments you should be able to cghange the return type
<RX14>
@spalladino you could fit a bunch of raspis into not much space, so I would tend to wards that direction for ARM hosting
<RX14>
obviously I don't know your office layout
<FromGitter>
<mjago> @RX14 I put my libsndfile library on github if you wouldn’t mind having a quick browse some time https://github.com/mjago/soundfile
<FromGitter>
<jacksonrayhamilton> Although, still not quite as elegant as removing the definition IMO
<FromGitter>
<Sija> any1 knows if there’s a reason not to implement `String#sub!`?
soveran has quit [Remote host closed the connection]
<RX14>
Strings are immutable?
unshadow has joined #crystal-lang
<FromGitter>
<spalladino> @RX14 you're right, I think that'll be the best way to go, with in-house raspis. Any suggestions on particular models to purchase and set up? I don't have much experience playing around with them, honestly.
<RX14>
ideally we would have one of each version
<RX14>
possibly 2 raspi 3's because it can be 32 and 64 bit
<RX14>
but i don't know of any 64bit distro for it
<RX14>
and you can just connect raspis in a stack using holdoffs
<RX14>
so they stack nicely
<RX14>
although that's a topic you might want to research more on
<FromGitter>
<spalladino> Will do. We'll probably have them by the end of the month or beginnings of the next, but I don't think that ARM slaves are a blocker for working on the CI.
soveran has joined #crystal-lang
<RX14>
you'll probably want a decent memory stick as well, as I hear the write durability on SD cards is a bit off
soveran has joined #crystal-lang
soveran has quit [Changing host]
<RX14>
so something to put the build slave workdirs on which isn't the root sdcard
<FromGitter>
<spalladino> Makes sense
<RX14>
you might want to do research on what i've said though
<RX14>
because i havent looked at the situation in a while
<RX14>
@spalladino The next step is to set up the build master, right?
Kug3lis has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Kug3lis has joined #crystal-lang
<crystal-gh>
[crystal] bcardiff closed pull request #3861: StringScanner should work with small strings (master...fix-stringscanner-inspect) https://git.io/vMWRU
Kug3lis has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Kug3lis has joined #crystal-lang
DeBot has quit [Read error: Connection reset by peer]
DeBot has joined #crystal-lang
<bmcginty_>
I've got a struct full of function pointers (thus procs) being sent to c. I can store and fetch custom data any time a function is returned to crystal. However, the crystal object that is being referred to could be one of a bunch of different custom classes. I can use boxing and just unbox everything to my common parent class, but that's getting ugly in terms of types and methods. I can store the c
<bmcginty_>
rystal objects in a hash, ...
<bmcginty_>
... and just box/unbox the key for a particular object. WOuld this be the recommended way to do things?
Kug3lis has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<spalladino> @RX14 I think so: a master with at least a slave mode should be the first thing to do
<RX14>
yup
<FromGitter>
<spalladino> I'll set up an EC2 node early next week and give you access. Any preferred OS?
<RX14>
I have experience with the debian side of linux
<RX14>
so i would prefer debian 8
<RX14>
it's going in docker either way so it doesn't *really* matter
<FromGitter>
<spalladino> Would an ubuntu server 16.04 be ok for you as well? We have been working for quite some time with ubuntu server (for running docker containers as well), and have no plain debians up.
<RX14>
yes that's fine
A124 has quit [Read error: No route to host]
A124 has joined #crystal-lang
<RX14>
Both distros are pretty similar
<FromGitter>
<spalladino> Great
gloscombe has quit [Quit: Lost terminal]
<RX14>
@spalladino it seems we can make alpine linux AMIs
<RX14>
which means we can run alpine directly on AWS
<FromGitter>
<sdogruyol> are you guys building CI infra?
<RX14>
jenkins cloud plugins means we can spin up slaves dynamically
<RX14>
with various AMIs i assume
<RX14>
then iirc there's a freebsd and openbsd AMI
<RX14>
i think that covers everything actually
<RX14>
2/3 of our architectures should be runnable on raw EC2, unless we hit a problem
<RX14>
i don't particularly want to run docker on the build slaves if possible
<RX14>
@sdogruyol we're talking about it
<FromGitter>
<spalladino> The main reason I'd consider Docker if it makes it easier to switch llvm versions
<RX14>
hmm
<RX14>
we can create AMIs with packer for various LLVM versions
<RX14>
and we would need to create docker images specifically for each target for each llvm version
<RX14>
so we're either going to have m*n docker images of m*n AMIs
<RX14>
and we're going to need custom AMIs regardless
<RX14>
so I think it's better just to build the AMIs directly without docker
<RX14>
but i might be wrong
<FromGitter>
<spalladino> That would imply that we spin up new nodes on-demand using jcloud. Though it seems to work, I'd like to check the cost of continuously starting new machines (based on custom AMIs) and terminating them, vs having a few nodes constantly running, that rely on docker to switch between LLVM versions.
<FromGitter>
<spalladino> I think the latter would be easier to configure, as we don't need to mess with jcloud
<RX14>
hmm
<RX14>
ideally the machines would be quite fast though
<RX14>
and if the minimum billing period is 1h
<RX14>
i assume jclouds is smart enough to keep them around and reuse them
<RX14>
but i might be wrong
<FromGitter>
<spalladino> What would be the use case against Docker here?
<RX14>
i'm just saying that dealing with aws AND docker seems more work
<RX14>
if we just used packager, we could make the LLVM version a build variable
<RX14>
packer*
<RX14>
and then just run the same buildfile for each llvm version
<RX14>
whereas with docker we'd make a packerfile for each target to install docker
<RX14>
and then create a docker image for each llvm version for each target
<RX14>
I would think the former will be simpler and easier
<FromGitter>
<spalladino> Quick question: generating an AMI from a packerfile and spinning it via jcloud is a relatively easy process?
<RX14>
well i've used packer before
<RX14>
and it seems that it's reasonably easy to use
<RX14>
you would just choose a "base" AMI, then a set of scripts to run, then save the AMI again
<RX14>
then you can pass the llvm version in to the scripts as env, and include it in the egenrated AMI name
<RX14>
but i've never done anything like this before
<RX14>
so i'm not sure!
DeBot has quit [Remote host closed the connection]
pduncan has joined #crystal-lang
DeBot has joined #crystal-lang
<RX14>
yup
<RX14>
looks like jclouds does keep the slaves around
soveran has quit [Remote host closed the connection]
<FromGitter>
<spalladino> Nice
<RX14>
i think we're just going to have to try something and evaluate what we actually get
<FromGitter>
<spalladino> But it does it kill them eventually, right...? I'm not sure I'd like to keep n \times m nodes running continuously
<RX14>
i think so...
<RX14>
i think a small-scale trial for x86 will be needed first
<RX14>
to see how it all fits together
<FromGitter>
<spalladino> Yeah
<FromGitter>
<spalladino> Let me know if you can make use of the aws free tier for testing it
<RX14>
i'll have a look at the weekend
<FromGitter>
<spalladino> Cool
<FromGitter>
<spalladino> Thanks a lot Chris, I really appreciate your effort with this :-)