01:09 <dukeleto> hola

01:12 <johnmuhl> dukeleto: hey. nice nick

01:21 <dukeleto> johnmuhl: thanks :)

01:35 <* dukeleto> is trying to get some cloud foundry unit tests to run on travis

03:16 <dukeleto> i've been trolled by the travis ci!

03:16 <dukeleto> before_install: Execution of 'bash < <(curl -s -k -B https://raw.github.com/cloudfoundry/vcap/master/setup/install)' took longer than 300 seconds and was terminated. Consider rewriting your stuff in AssemblyScript, we've heard it handles Web Scale™

03:20 <dukeleto> antares_zzzz: if you get this message, i would like a larger timeout for the cloud foundry tests :)

03:20 <* dukeleto> .sleep()

03:20 <dukeleto> antares_zzzz: http://travis-ci.org/#!/leto/vcap/jobs/583551

05:24 <antares_> dukeleto: bumping that timeout is possible

05:24 <antares_> good morning svenfuchs

05:24 <svenfuchs> hey

05:28 <antares_> svenfuchs: do you think people at soundcloud in general are aware of travis? or I should introduce them in my pull request for their Java client?

05:34 <svenfuchs> antares_: they are

05:34 <svenfuchs> they actually want us to drop by for a week and setup a local instance for them :)

05:35 <svenfuchs> not sure that will happen though

05:35 <svenfuchs> it's a huge team, but i wouldn't waste time introducing travis ci

05:38 <antares_> svenfuchs: ok. headius agreed to move smaller jruby/* projects on travis as soon as we want. First step: http://travis-ci.org/#!/michaelklishin/joni

05:39 <svenfuchs> hah, nice

06:12 <cesario> morning guys

06:13 <cesario> If one of you guys attended Ruby Lugdunum last year, you might be interested by that http://bit.ly/AlXsLv

06:17 <antares_> hi cesario

06:24 <cesario> hi antares_

07:40 <benofsky> Hi, is there a guide anywhere for installing travis locally?

07:53 <benofsky> found this on the github README "Travis CI is not currently a good fit for closed in-house installations: there are multiple applications that evolve rapidly and workers need VMs running on the same host. Ask on the IRC channel for more information." — why so?

09:06 <GitHub103> [travis-cookbooks] michaelklishin pushed 1 new commit to master: http://git.io/4kKE7Q

09:06 <GitHub103> [travis-cookbooks/master] Make sure we don't have obscure issues with SSL certificates - Michael S. Klishin

10:15 <gildegoma> antares: Hi!

10:16 <antares_> gildegoma: hi

10:16 <gildegoma> how are you ? (so long time away from travis channel)

10:16 <antares_> I am good

10:19 <gildegoma> :-) Thanx for going further with Scala stuff. As you may have seen in github notications, I opened one more PR for the VM cookbook

10:23 <GitHub14> [travis-cookbooks] michaelklishin pushed 1 new commit to master: http://git.io/MEk2vw

10:23 <GitHub14> [travis-cookbooks/master] Merge pull request #24 from gildegoma/sbt-fix-jvm-parameters - Michael Klishin

10:23 <antares_> gildegoma: we actually are about to ship this whole thing

10:23 <antares_> just need to get a new machine and write doc guides

10:24 <antares_> gildegoma: so if you have scala projects to add to travis, do it

10:24 <antares_> language: scala

10:24 <antares_> make sure project authors do not get email notifications until you agree with them to put their stuff on travis

10:24 <antares_> gildegoma: same with Java and Groovy projects

10:25 <gildegoma> antares_: nice! (I agree with your comment about JVM_OPTS env-var. Actually I was about to implement something like that, but I preferred to keep it simple and check with you first :-)

10:25 <gildegoma> langauge: scala :-)

10:26 <gildegoma> sure, for other projects (scalatra, salat,…): I may open PR on master project to propose them. But we can do that later, when the doc guidelines are ready and scala support officialized

10:26 <gildegoma> for now, I'll just use it for my upcoming project

10:26 <gildegoma> (hoping reserve enough time for that)

10:27 <gildegoma> antares_: sure, I am prudent with my testing forks (to avoid bother people)

10:32 <antares_> gildegoma: ok, just add any java, scala or groovy projects you want now

10:32 <antares_> with language: java and so on

10:32 <antares_> they will land on ruby workers right now but as soon as we have a new machine for those languages, we will use a separate queue

10:32 <antares_> hey josh-k

10:33 <josh-k> hey antares_

10:33 <antares_> josh-k: we have JRuby regexp implementation and Riak Java client on travis, using language: java and default commands

10:34 <josh-k> wow, very cool!

10:34 <antares_> so it works and I am slowly writing docs and submitting PRs for real projects

10:42 <josh-k> antares_: fantastic!

10:43 <josh-k> i see big growth today, i suspect from a lot of forks you are sending PRs from? :)

10:43 <antares_> josh-k: I only added like 4 or 5 forks :)

10:44 <josh-k> haha, well, great work

11:06 <gildegoma> antares_: bad luck I could not test it so far, because github is facing errors on push… (http://status.github.com/, https://gist.github.com/1689404)

11:08 <gildegoma> antares_: anyway: hats off! I'm looking forward to see Java, Groovy and Scala projects coming to Travis!

11:15 <antares_> gildegoma: after some initial skepticism about "this Ruby toy", I am sure there will be plenty :)

11:16 <gildegoma> antares_: sure, do you want some help for PR propaganda ?

11:17 <gildegoma> github is back, and travis is again working hard :-)

11:18 <antares_> gildegoma: we need to see what real world Java and Scala projects will want (besides multiple JDK versions)

11:18 <antares_> simply sending pull requests w/o explaining what we do best won't make any difference

11:19 <antares_> gildegoma: I see that your fork of salat is falling back to mvn test. I guess sbt detector does not work for it

11:19 <gildegoma> antares_:

11:19 <gildegoma> yep, @uses_sbt ||= (shell.file_exists?('project') || shell.file_exists?('build.sbt'))

11:19 <gildegoma> there is a folder 'project'

11:20 <gildegoma> is it possible that shell.file_exists? does not catch folder ?

11:21 <antares_> def file_exists?(filename)

11:21 <antares_> execute("test -f #{filename}", :echo => false)

11:21 <antares_> end

11:21 <antares_> yes, it only checks files

11:22 <gildegoma> :-/ I thought that in UNIX world folder are at end of the day 'file'… is there a folder tester ?

11:22 <gildegoma> ¨

11:22 <antares_> they are not files

11:23 <antares_> they are inodes

11:23 <gildegoma> yep :-)

11:23 <antares_> and it does not matter, we are using -f

11:23 <antares_> test -d checks for directories

11:24 <gildegoma> have you a direct link to shell ruby class ? do you need to enhance it ?

11:26 <GitHub66> [travis-worker] michaelklishin pushed 1 new commit to master: http://git.io/P9ubMg

11:26 <GitHub66> [travis-worker/master] Introduce #directory_exists? to accompany #file_exists? - Michael S. Klishin

11:27 <antares_> gildegoma: so project and build.sbt are both directories?

11:27 <antares_> no, build.sbt is a file

11:27 <gildegoma> antares_: thanx for the worker fix. No build.sbt is a file

11:27 <gildegoma> but 'project' folder is enough

11:29 <gildegoma> antares_: when do you think that #directory_exists? will be available on the workers ?

11:30 <antares_> I need to update Scala builder first

11:30 <antares_> I see there is also build.scala

11:31 <antares_> ah, no

11:31 <antares_> it is build.sbt + project/*.scala files

11:36 <gildegoma> antares_: of course for the scala builder change.

11:39 <GitHub18> [travis-build] michaelklishin pushed 1 new commit to master: http://git.io/QG1uGQ

11:39 <GitHub18> [travis-build/master] Scala builder should check for ./project directory, not file - Michael S. Klishin

11:41 <GitHub39> [travis-build] michaelklishin pushed 1 new commit to master: http://git.io/6U-Ofw

11:41 <GitHub39> [travis-build/master] Spam - Michael S. Klishin

11:44 <antares_> gildegoma: it will be live in maybe 15 minutes

11:45 <GitHub183> [travis-worker] michaelklishin pushed 1 new commit to master: http://git.io/0iT9Ew

11:45 <GitHub183> [travis-worker/master] Update travis-build - Michael S. Klishin

11:46 <gildegoma> antares_: wow! you're coding in a flash

11:46 <antares_> new VM images will only be live tomorrow

11:47 <antares_> so permanent gen space issues won't go away

11:47 <* dukeleto> waves

11:47 <dukeleto> antares_: parrot has a test to make sure no files have multiple dots (.) in them because some OS's puke on them (like VMS and others)

11:48 <dukeleto> antares_: so I ask: I can call .travis.yml something else? Perhaps .travisyml ?

11:48 <antares_> dukeleto: no

11:48 <dukeleto> antares_: trying to make everybody happy sucks

11:48 <antares_> we fetch .travis.yml

11:49 <antares_> dukeleto: you can make that test conditional using ENV["CI"]

11:49 <antares_> dukeleto: which isn't the best option but the test itself is really weird

11:50 <gildegoma> antares_: ok for VM images. When the new builder is deployed, I gonna test matrix build.

11:50 <antares_> in addition, why would you run this test on relatively sane platforms like Linux

11:51 <dukeleto> antares_: yes, parrot has some very odd tests :) Mostly because we try to support some odd platforms (like Solaris and such)

11:52 <gildegoma> antares_: again 'bravo' and Thanx a lot for all! I leave now… I'll try to run some Scala tests during the week-end, bye!

11:52 <dukeleto> antares_: https://github.com/parrot/parrot/commit/42997bcca663a7cd1262be7f0846052aab20b88a

11:52 <antares_> gildegoma: live

11:53 <gildegoma> :-)

11:53 <dukeleto> antares_: what just went live?

11:53 <antares_> dukeleto: a worker update that fixes an issue with the Scala builder

11:54 <antares_> dukeleto: I find that hack reasonable for this VMS-specific test

11:54 <dukeleto> antares_: cool. yep, me too :)

11:54 <dukeleto> antares_: http://travis-ci.org/#!/leto/vcap/jobs/583551 <-- the troll at the very bottom made me laugh hard last night

11:55 <dukeleto> antares_: do you see the crazy stuff our installer is doing? We compile 5 rubies ourselves, just in case :)

11:56 <dukeleto> antares_: it is hard to split up that installer stage to make it come in under the timeout

11:56 <antares_> dukeleto: I don't think that you need to compile rubies on travis

11:56 <antares_> what rubies are those?

11:56 <antares_> well, compiling 5 rubies is 15 minutes or so

11:56 <dukeleto> antares_: our installer script installs very specific rubies (down to the patchlevel) for our code

11:56 <dukeleto> antares_: and our platform supports multiple ruby versions, so it gets them all ready

11:57 <antares_> but we already have a dozen or even more rubies install

11:57 <antares_> *installed

11:57 <dukeleto> antares_: supporting choosing between multiple ruby versions at runtime, i should say

11:57 <dukeleto> antares_: do you have 1.9.2-p180 ? that is the one we really need

11:57 <antares_> I believe we are at 1.9.2-p290 now

11:58 <dukeleto> antares_: yeah, that is why we compile our own in our installer. We depend on very specific versions due to bugs in Eventmachine and crap like that

11:58 <antares_> is this done in before_script?

11:58 <dukeleto> antares_: yep

11:59 <dukeleto> antares_: https://github.com/parrot/parrot/blob/master/.travis.yml

11:59 <dukeleto> antares_: oops, wrong one

11:59 <dukeleto> antares_: https://github.com/leto/vcap/blob/travis-ci/.travis.yml

11:59 <dukeleto> antares_: it is actually before_install:

12:00 <dukeleto> antares_: also (not sure if it is a bug) i had to comment out: gem install bundler --pre

12:00 <antares_> why?

12:00 <dukeleto> antares_: or that command would run "rake" in my project and then fail because there is no default rake task

12:00 <antares_> it is not a bug but this also cannot be a travis issue

12:01 <antares_> gem install runs rake?

12:01 <antares_> that's impossible

12:01 <antares_> well, you can use bundler 1.0.x, that's fine

12:01 <dukeleto> antares_: when I don't comment out that gem installer bundler line, my build fails at "rake"

12:01 <dukeleto> antares_: and that "rake" command is not coming from anything that I do

12:02 <dukeleto> antares_: so it is being invoked by "gem installer bundler --pre" or something travis is doing

12:03 <gildegoma> antares_: sorry, I locked 3 salat builds while trying some temporary workaround -> they'll have to be killed by timeout

12:04 <GitHub54> [travis-worker] michaelklishin pushed 1 new commit to master: http://git.io/O7XMVA

12:04 <GitHub54> [travis-worker/master] Update Ruby worker timeouts - Michael S. Klishin

12:04 <antares_> dukeleto: "rake" is default script: value for ruby projects

12:04 <dukeleto> antares_: do you see any build output at http://travis-ci.org/#!/leto/vcap/builds/583349 ?

12:04 <gildegoma> I stop there, and wait until Travis builder and worker are ok.

12:04 <dukeleto> antares_: sure. But I have a custom "script" key, so why should it be doing that?

12:04 <antares_> dukeleto: I will update ruby workers soon but as you can see, people lock up workers all the time

12:05 <antares_> dukeleto: so having a 20 minute timeout for each before_* operation + 15 for install + 30 for build is scary

12:05 <antares_> dukeleto: so maybe you guys should avoid installing 5 rubies. I don't know if we will be OK with this in the future.

12:05 <antares_> we already have diaspora and some other projects consuming very disproportional amount of time

12:06 <dukeleto> antares_: i understand. we currently don't even have this hooked up to our internal CI system :)

12:07 <dukeleto> antares_: i will see what I can do about not compiling every ruby known to man

12:07 <antares_> I think there are scenarios when .travis.yml is not fetched from a branch

12:07 <antares_> and if it is not fetched, script: will have default value

12:07 <dukeleto> antares_: does travis miss github hooks sometimes, or does github not send them?

12:08 <dukeleto> antares_: travis missed a branch merge this morning : https://github.com/parrot/parrot/commits/master http://travis-ci.org/#!/parrot/parrot/builds

12:08 <dukeleto> antares_: not trying to complain, just want to understand what happened :)

12:08 <dukeleto> i have seen github fail to send post-receive hooks about 5% of the time

12:08 <dukeleto> do y'all see something similar? Have they fixed that situation recently?

12:09 <antares_> github is having issues every once in a while

12:09 <antares_> today they deployed something that resulted in pushes being rejected

12:09 <dukeleto> full parrot test suite on travis in 16 minutes! http://travis-ci.org/#!/parrot/parrot/jobs/585401

12:09 <antares_> http://status.github.com/

12:10 <antares_> dukeleto: I think that .travis.yml in some cases (like when project is not on travis yet but you trigger a hook using test hook button) will be fetched from master

12:10 <dukeleto> antares_: ccache made the build take 26 seconds less, fyi :)

12:10 <antares_> because github does not send us commit or something like that

12:11 <dukeleto> antares_: are any alternate compilers installed by default? such as clang and friends

12:11 <dukeleto> antares_: where can i read the full list of packages that come standard with each kind of vm?

12:12 <dukeleto> antares_: sadly though, ccacche gcc took longer than plain gcc

12:12 <antares_> http://about.travis-ci.org/docs/user/ci-environment/

12:12 <antares_> no clang

12:12 <dukeleto> antares_: thanks!

12:23 <dukeleto> antares_: how many is too many env config keys?

12:23 <antares_> dukeleto: you cannot build more than 18 matrix rows concurrently

12:23 <antares_> other that, I don't know

12:24 <antares_> the only question is how long will it take

12:24 <antares_> and I think compiling 5 rubies will make every other inefficiency irrelevant

12:25 <antares_> I bumped timeouts on 2 of 3 machines, by the way

12:25 <dukeleto> antares_: thanks!

12:25 <antares_> we can keep them for maybe a week

12:25 <dukeleto> antares_: https://github.com/parrot/parrot/commit/8b1c382563d3f9508d3d344474f2c84b4cb95b4c

12:25 <dukeleto> antares_: let me know if that is too much

12:25 <antares_> dukeleto: how long does one build take? 16 minutes?

12:26 <dukeleto> antares_: i will try to make our installer more configurable so it doesn't install 50 rubies. can't make any promises :)

12:26 <dukeleto> antares_: yes, roughly 15 mins

12:26 <antares_> 10 builds of parrot * 16 rows = 2.5+ hours of worker time. That's about as long as some large projects take. Diaspora used to take well over 3 hours.

12:27 <antares_> dukeleto: we can host cloudfoundry on a separate machine like rails, then you can keep the installer

12:27 <antares_> dukeleto: same for parrot.

12:28 <antares_> dukeleto: our machines are roughly this http://www.hetzner.de/en/hosting/produkte_rootserver/ex4, but for cloudfoundry or parrot needs they can be smaller (or larger). nodejs1 is is 2-3 times less powerful, it is sufficient for Node projects for now.

12:28 <antares_> rails and spree + subprojects are hosted completely separately

12:29 <antares_> so they never interfere with the rest of Ruby projects

12:29 <antares_> I believe we discussed this with Derek Collison not so long ago, not in the context of cloudfoundry though

12:29 <dukeleto> antares_: is it possible for someone to run their own travis instance?

12:29 <dukeleto> antares_: awesome, you know Derek

12:30 <antares_> dukeleto: well, it is possible but it is not the easiest thing to set up and things change every week

12:30 <dukeleto> antares_: i am currently the owner of the cloudfoundry CI process and I am trying to find better tools. First thing I ran into was Travis :)

12:31 <dukeleto> antares_: modifying the install of cf may be hard, because the installer actually needs to be the way it is to test against switching between our specific ruby versions at runtime

12:32 <dukeleto> antares_: so yeah, a dedicated box is the way to go

12:32 <antares_> dukeleto: then maybe 49 EUR/mo is a reasonable cost for not having to worry much about CI (rails and spree ask us to tweak a thing or two maybe once a month)

12:33 <antares_> dukeleto: and I understand that testing the installer is a very important thing for cloudfoundry

12:33 <antares_> if things do not install properly, they won't be adopted, period

12:34 <antares_> dukeleto: do you use RVM to install rubies?

12:34 <dukeleto> antares_: so if I push another commit, the timeout will be larger? i will remove all my rvm versions other than 1.9.2 for now, to cut down on wastage

12:34 <dukeleto> antares_: yes, we use rvm

12:34 <antares_> dukeleto: if so, then we can just install different rubies and/or aliases on your VM images. Rails and Spree VM images are different from "regular" Ruby VMs

12:34 <antares_> our cookbook is very flexible

12:35 <antares_> dukeleto: well, ruby1 is still not updated

12:35 <dukeleto> antares_: awesome! I can foresee good things

12:35 <antares_> I am waiting for builds on it to quiet down

12:35 <dukeleto> antares_: i must run out the door, but i will be back soon! i will push out a build then

12:35 <antares_> but yes, in 10-20 minutes you can push and it should use new timeout values

12:35 <dukeleto> antares_: thanks so much for all your help!

12:35 <antares_> dukeleto: ok. talk later!

12:36 <dukeleto> antares_: and travis just found test failures on clang for parrot!

12:36 <* dukeleto> really must go now

12:55 <antares_> listrophy: ping

13:10 <sikachu> hey guys

13:10 <sikachu> I need some help using rbx on travis-ci T_T

13:13 <antares_> mmalecki: ping

13:13 <antares_> sikachu: hi

13:14 <sikachu> antares_: my build failed because I has rbx-2.0 in my .travis.yml.

13:14 <sikachu> Was it removed.

13:14 <sikachu> ?

13:15 <sikachu> According to this one, I thought it was still usable: http://about.travis-ci.org/blog/vm_upgrade_oct_31_2011/

13:15 <antares_> sikachu: https://twitter.com/travisci/status/162564041229864960

13:15 <antares_> sikachu: that is from October 2011

13:16 <antares_> sikachu: use rbx-18mode or rbx-19mode from now on. Just rbx is also there (1.8 mode)

13:16 <sikachu> I see. I'm not sure though that I want 18mode or 19mode

13:17 <sikachu> are they both from 2.0 branch?

13:17 <antares_> 2.0.testing

13:17 <antares_> 1.9 mode still has issues, although it is almost as useable as 1.8 mode now

13:17 <antares_> next will it probably will be just as good

13:18 <antares_> sikachu: 2.0 branch is now gone. It is in master since November or so.

13:18 <antares_> in part this is why rbx-2.0 no longer makes sense. It is the same as rbx or rbx-head.

13:18 <antares_> 2.0.testing is what travis uses. Rubinius developers update it when they think it is time. Usually maybe once a week.

13:20 <antares_> so because *only* Rubinius 2.0 is available, we had to reduce # of aliases that all mean the same thing

13:21 <antares_> sikachu: makes sense?

13:21 <antares_> sorry, I need to step away now

13:25 <sikachu> ahhhhh

13:26 <sikachu> thanks a lot, that makes sense

13:26 <sikachu> I didn't follow the development of rbx, so i had no idae.

13:29 <sikachu> O_o

14:58 <ifesdjeen> antares_: ping

16:39 <parndt> svenfuch_: khaase: I accidentally broke testimonials on crowd

16:39 <parndt> I've pushed to master to fix it :)

16:50 <brixen> antares_zzzz: I've updated 2.0.testing

16:50 <brixen> antares_zzzz: a few important fixes in there

16:51 <brixen> antares_zzzz: for example, the travis timeout should be fixed with improved zlib functioning

17:30 <dukeleto> sadly, vcap is still timing out: http://travis-ci.org/#!/leto/vcap/builds/586510

18:05 <joewest> hi

18:05 <joewest> possibly silly question, but is it possible to rerun build/tests without pushing a new commit ?

18:07 <parndt> yes joewest

18:07 <parndt> edit your project on github

18:07 <parndt> go to the service hooks

18:07 <parndt> go to the travis hook

18:07 <parndt> click "test hook"

18:08 <joewest> parndt: nice! thank you

18:08 <joewest> that's perfect

18:09 <parndt> :)

18:25 <listrophy> eeee! "In Review"

18:27 <joewest> parndt: sorry btw, should have seen this -> http://about.travis-ci.org/docs/user/how-to-setup-and-trigger-the-hook-manually/

18:28 <parndt> haha :D

18:37 <dukeleto> ~~

18:41 <parndt> josh-k: i pushed a bugfix to travis crowd

18:41 <parndt> but no idea how to deploy or its state, but FYI

18:44 <joewest> is there a third status in travis .. like green for build/pass all tests and red for 1 or more tests fail and yellow for some configuration / network problem ?

18:48 <parndt> no it goes red

18:48 <joewest> k

18:49 <joewest> getting "unable to access network errors" with qunit which is weird, is there anyway to see why it's not returning status == success ?

18:49 <joewest> (qunit + phantomjs)

18:52 <joewest> I'm testing a javascript framework (http://travis-ci.org/#!/joewest/ember.js) running a ruby webserver (rack)

19:08 <parndt> joewest: well here's how ember.js do it https://github.com/emberjs/ember.js/blob/master/.travis.yml

19:21 <joewest> parndt: I know, I wrote that :)

19:22 <parndt> aha!

19:22 <joewest> weird .. i just pushed another change that fixed it

19:22 <parndt> awesome?

19:22 <joewest> took the line: - bundle exec backup & out of quotes

19:23 <joewest> and it works … weird

19:24 <mpapis> joewest: you really have & on the end ?

19:24 <joewest> yes, I background it .. if I don't it seems to hang foreves

19:24 <joewest> and daemonize had the same unable to access network errors

19:26 <joewest> mpapis: is there a better way to do that ?

19:28 <mpapis> joewest: not sure, but it should not hang forever, if you put it in background then you can't be sure it finished

19:29 <joewest> mpapis: please say more?

19:29 <joewest> mpapis: o that & is just a server that hosts the tests

19:30 <joewest> the tests actually run in a headless web browser (phantoms)

19:30 <joewest> phantomjs*

19:31 <mpapis> joewest: it depends on how it's procesed by the CI server - if it waits for background tasks

19:32 <joewest> mpapis: it doesn't seem to .. it reports pass/fail as soon as the tests finish running and return 0/1

19:32 <mpapis> if this task does not finish before the tests then it can be forced stop half the task after stopping the CI machine

19:34 <mpapis> joewest: run this in your console: ( sleep 30s ; echo a ) &

19:34 <mpapis> and then: echo b

19:34 <mpapis> the "a" is backup task

19:34 <mpapis> and b are tests

19:34 <mpapis> b will finish instantly

19:34 <mpapis> but a will be shown after 30 seconds

19:35 <mpapis> and CI most likely waits only for the tests, not for background tasks, but you can ask antares_ tomorrow for details if it really does not wait

19:36 <joewest> mpapis: you mean the server is waiting indefinitely?

19:36 <mpapis> no it rather kills the task

19:36 <joewest> oh that's good, I want it to

19:36 <joewest> I want it to kill the task after the tests run and finish

19:37 <mpapis> so why you run it if you don't rely on it to finish ?

19:37 <antares_> joewest: operations like script: or before_script: or install: all have timeouts. What language is your project in?

19:38 <joewest> it runs in ruby

19:38 <joewest> tho project is technically javascript

19:38 <joewest> antares_: ^

19:38 <antares_> then the longest you'll have to wait is 30 minutes

19:39 <joewest> antares_: this is my .travis.yml file: https://github.com/joewest/ember.js/blob/6e414789741c848774ee1420c07520dd032e73f6/.travis.yml

19:39 <antares_> joewest: you can add language: node_js and move it to node workers. They have 12 minute timeouts or so.

19:39 <joewest> antares_: it needs ruby since our build environment is ruby atm

19:40 <antares_> joewest: I just needed to know what workers it lands on. I can kill a particular build if you really want me to. It is not a lot of work but we do not currently let anybody do it.

19:40 <antares_> joewest: node VMs have one Ruby (1.9.2)

19:40 <joewest> wait I don't need to kill a build

19:40 <antares_> but it's ok for Ember to use ruby workers

19:40 <joewest> everything is working fine for me

19:40 <antares_> just a suggestion

19:40 <antares_> hm, maybe I misunderstood your conversation with mpapis

19:41 <antares_> cool

19:41 <joewest> antares_: me too, but as I understood it mpapis was just saying that my backgrounding of rack is possibly causing the worker to hang out for 30m

19:41 <mpapis> antares_ / joewest i cant understand the reason to run a task wghich does not have to finish

19:41 <antares_> does ember test suite return 1 on failures now?

19:41 <antares_> mpapis: but they do shut down rack server at the end. They definitely used to.

19:41 <parndt> good morning antares_!

19:41 <joewest> antares_: it sort of always did.. the problem is it didn't return 1 on network timeouts

19:41 <joewest> which it will do once I finish these commits

19:42 <antares_> good day parndt

19:42 <antares_> joewest: cool

19:42 <joewest> the default phantomjs run-qunit script returned 0 on status != success (which is obv wrong)

19:43 <joewest> just to confirm antares_ / mpapis : I'm not DOS'ing the ruby workers by backgrounding rack and the worker kills everything (xvfb and rack) when the tests in "script:" finish running ?

19:46 <antares_> joewest: it does not do anything to rack or xvfb but if your script: command exits fine (which I think it does), the entire VM is powered off after each build

19:47 <mpapis> joewest: what do you have in the backup script, can I see it ?

19:47 <antares_> joewest: and any FS modifications you may do are rolled back, too. See http://about.travis-ci.org/docs/dev/overview/ if you want to learn more about how travis workers, including everything around VMs.

19:48 <antares_> joewest: so no, you are not DOSing anything. We have seen enough poorly written test suites to have all kinds of defenses against hanging builds.

19:48 <joewest> mpapis: `bundle exec rackup &` uses this config: https://github.com/joewest/ember.js/blob/6e414789741c848774ee1420c07520dd032e73f6/config.ru

19:50 <mpapis> joewest: aha !! i have seen backup, and you run rackup - it's all fine then

19:50 <joewest> :)

19:50 <mpapis> <joewest> took the line: - bundle exec backup & out of quotes

19:50 <mpapis> yep backup ^

19:51 <joewest> oh ha i'm going to squash all those commits .. I'll make sure to spell properly :)

19:51 <joewest> on a semi-related note is there an easy way to set up travis locally so I can test out my .travis.yml file without throwing 8-10 commits at it ?

19:53 <antares_> «i have seen backup, and you run rackup - it's all fine then» — mpapis, have considered a rapping career?

19:54 <mpapis> antares_: i'm totaly useless when it goes to any kinds of arts, i'm only good in codding or rather understanding code

19:54 <parndt> I hope if so he has a backup

19:54 <parndt> so he doesn't crack up

19:54 <parndt> from talking all that smack up

19:54 <antares_> hahaha

19:54 <* parndt> stops

19:55 <mpapis> antares_: how about a local invocation of travis, do you support something like this ? I started codding something similar, not sure if i need to do that

19:55 <stephank> Should I care about keeping my API Token secret? I'm pondering setting up Travis for some organisation repos, but colleagues will be able to see it, I suppose?

19:55 <antares_> mpapis: local invocation?

19:55 <mpapis> on my machine to separate tests from my system

19:56 <mpapis> but to make sure before commiting something stupid

19:56 <mpapis> in most cases I commit code that works, sometimes running tests on my os, but running them in separate VMs makes sense also

19:56 <antares_> stephank: they will if they have access to admin pages but today sharing the token is pretty difficult to abuse. Unless your org members are really not trustworthy, you should be fine.

19:57 <mpapis> especially to test different systems (not only ubuntu)

19:57 <stephank> antares_: okeedo, thanks

19:57 <antares_> mpapis: well, how do you want remote VMs get your code :) we currently have tight github integration in several areas :)

19:58 <mpapis> antares_: I have right now only that: https://github.com/mpapis/rvm-test-vagrant - as for the code I could scp a tgz to the machine

19:59 <antares_> mpapis: well, our environment is Ubuntu only right now :) and it will take some work to add CentOS and BSDs, leave alone other things

20:00 <antares_> mpapis: I think travis won't be able to do this for a while. And using vagrant and scp for that sounds like an easy way to do it for you.

20:00 <mpapis> antares_: I thought of allowing anything (os) so I can test when someone reports errors

20:00 <mpapis> antares_: then I will - and most likely it will resuse the .travis.yml

20:00 <antares_> cool

20:01 <mpapis> actually it is good idea for a gem :)

20:02 <mpapis> local-travis :D

20:02 <mpapis> i need a break, bb later

21:30 <antares_> joewest: https://github.com/joewest/ember.js/commit/27a4efe7dea3dafa7e9b77599c41f400765bddc0

21:30 <antares_> joewest: (see my comment)

21:31 <joewest> there's no comment?

21:31 <joewest> o i c it

21:31 <joewest> antares_: hilariously it works sometimes

21:31 <antares_> in theory it may work but will probably go away

21:32 <antares_> it complicates everything a great deal (how do you know if the build has failed or not? different people will tell you different things)

21:32 <antares_> we are already adding a feature that will allow you mark matrix rows as "allowed to fail"

21:32 <antares_> we definitely don't want to do this for individual `script:` lines

21:32 <antares_> makes sense?

21:33 <antares_> I will try to cover this in the docs, unfortunately, people often don't read them :(

21:34 <joewest> antares_: cool, so I want to write this as script: phantomjs tests/qu… "url" && phantomjs tests/qu.. "url 2" && phantomjs tests/qu .. [and so on] ?

21:34 <antares_> joewest: yes. Then && will return 0 only if both expressions return 0.

21:35 <antares_> or so I hope :) mpapis knows better

21:35 <joewest> antares_: also when I background in before-script will it run script only after all of those complete

21:35 <joewest> I'm concerned that I have a timing issue where the bundle exec rackup & isn't actually running before the script: line(s) start running

21:35 <deryl> actually no, what that means is that if the first succeeds, do the next, if that succeeds do the next

21:36 <deryl> if something before the && fails, whatever is after the && will NOT be executed

21:36 <joewest> deryl: good to know

21:37 <antares_> deryl: yes but it will also return the same exit code, right?

21:37 <antares_> or rather, it does not affect it in any way

21:37 <deryl> it'll return the exit code for the failing step

21:38 <antares_> so as far as "returning non-0 on failure" goes, it is exactly what you usually want

21:38 <deryl> whatever it was when it exited

21:38 <antares_> joewest: yes, race conditions are possible. Add one more before_script that does sleep 5 or sleep 10

21:38 <deryl> ah yeah from that point then yes

21:38 <mpapis> back rereading

21:38 <antares_> mpapis: deryl already explained everything to us :)

21:39 <joewest> antares_: any more elegant way to make sure it's running ?

21:39 <antares_> joewest: jasmine test suite checks whether the server is running

21:39 <antares_> for 10 seconds or so

21:39 <antares_> and fails immediately with a meaningful message if it does not

21:39 <antares_> joewest: https://github.com/pivotal/jasmine-gem

21:47 <mpapis> antares_: it's all in ruby code, you could provide common function for waiting on port in bash which could be added to before_install

21:47 <mpapis> antares_: I can give you that function in few minutes, it's not that hard

21:48 <joewest> mpapis: that would be nice to share in common

21:48 <mpapis> globally from travis

21:48 <deryl> ahhh i wass absolutely sure you were doing this as a bas script calling this

21:48 <mpapis> :)

21:48 <deryl> s/bas/bash/

21:48 <antares_> deryl: correct

21:48 <antares_> mpapis is suggesting a bash solution as well

21:49 <antares_> if enough people need this, we may install a few helper scripts in our CI env

21:49 <deryl> ok, then my commentary still stands.

21:49 <antares_> for now, lets just keep it in the ember's .travis.yml

21:49 <deryl> i mistook mpapis's comment to mean you were doing this in ruby (using say %x['list of commands sep by && like that'] )

21:49 <deryl> (not that you need the '')

21:50 <mpapis> deryl: https://github.com/pivotal/jasmine-gem/blob/master/lib/jasmine/base.rb#L33

21:50 <deryl> ahhh

21:50 <deryl> uyeah that would do it. we;re doing something similar in fs_specs

21:51 <joewest> phantomjs could do that too but seems brittle

21:51 <deryl> since freeswitch doesn't come back immediately after you issue a command, we had to sleep until it did. was confusing us within cucumber

21:52 <mpapis> deryl: i thought of a common helper that could be just called in before_install - jsut before "server &"

21:52 <mpapis> sorry after :)

21:52 <deryl> mpapis: what you're showing me.. definitely a worthy helper

21:52 <deryl> i can see multiple uses for L33-40 :)

21:55 <deryl> think I;'m going to snag a few methods out of jasmine-gem and record a pointer to their GH. don't need all of it.

21:59 <joewest> antares_ / mpapis here's my latest .travis.yml in case you're curious .. thanks for the help today !

22:00 <joewest> ^ re https://github.com/joewest/ember.js/blob/176ff528638636e255037a92fbb37eb3523fd333/.travis.yml

22:00 <mpapis> joewest: in most cases it will do it

22:00 <antares_> joewest: cool. Happy to help ember.js development :)

22:01 <deryl> antares_: hehe i like this jasmine-gem. he does it more than fairly clean! me, i grossly overcomplicate methinks.

22:01 <Daegalus> Hey, I wanted to ask, do you guys ever plan to add Bitbucket support? Just curious.

22:01 <antares_> Daegalus: some day

22:01 <Daegalus> Ok cool. I know its not a priority, but was just curious

22:02 <antares_> Daegalus: in my personal opinion, github-only will work great for travis anyway

22:02 <antares_> everybody is on github

22:02 <joewest> mpapis: .. in most cases I'm going to view this as a WIP .. I will probably figure out a better long term solution for that entire last commit in the run-qunit.js file that phantomjs calls (like put all URLs and the test to make sure server is online)

22:02 <antares_> but it won't be too hard to support bitbucket

22:02 <joewest> :)

22:03 <antares_> accounts are the only thing where we will have to do quite a bit of work

22:03 <Daegalus> antares_: oh I know, but out of pure preference, I like to use Bitbucket, since I prefer to use Mercurial over Git. And also I on occasion have private repos, which Bitbucket provides for free.

22:03 <mpapis> joewest: i'm plaing now with simple script to check it in bash ;)

22:03 <antares_> bitbucket provides private repos for free?

22:03 <Daegalus> antares_: yup

22:03 <antares_> do they charge for anything at all?

22:04 <Daegalus> antares_: you can only have 5 contributors TOTAL across all private repos

22:04 <antares_> ok

22:04 <Daegalus> to get more, you need to pay

22:05 <Daegalus> plus, they make a lot fo money from their JIRA family of products, so they have other sources of funding to support Bitbucket

22:05 <antares_> Daegalus: you mean, they are sucking on Atlassian resources because nobody cares about them ;)

22:05 <antares_> but anyway

22:06 <antares_> it will be supported some day

22:06 <antares_> and we already have mercurial preinstalled in the VM environment

22:06 <Daegalus> haha ok, no worries. I can always push any public stuff I have to github.

22:06 <antares_> and Python support is halfway done, at least the design part

22:07 <antares_> although after we ship JVM languages next week, we will probably work on Perl first

22:07 <Daegalus> awesome. Excellent service guys, I hope you guys do well.

22:07 <antares_> (it is much easier to implement Perl support)

22:07 <Daegalus> hehe ya

22:07 <Daegalus> Well mayhbe also on the bottom of the ToDo list, you gusy can add MSBUILD to handle C# and .NET languages

22:08 <antares_> Daegalus: Windows is something we want to support but CI environment automation will be pretty much a completely separate project

22:08 <antares_> we won't be able to reuse much from our cookbooks

22:09 <antares_> especially if you consider that we compile over a dozen of rubies, 6 phps, 3 node.js versions and how many Perls and Pythons it will be all from source

22:09 <antares_> to get access to head versions, RCs and just new releases

22:10 <antares_> if we only focus on .NET first, I guess building images will be relatively easy

22:10 <Daegalus> or you can do basic support for Mono projects

22:10 <Daegalus> which should be easier to get running

22:10 <antares_> we don't have any experience with it but if some MS-oriented company or community wants to help, all we need is a VM image with all the stuff + a way to control it over SSH

22:11 <Daegalus> If I had the time, I would definitely help out. Since I spent quite a bit of time getting Jenkins running with all the Windows/.NET stuff and have it all running on my windows desktop, also handling 2 python versions. One for Google Apps, another for just 3.x development

22:14 <antares_> Daegalus: are you familiar with Chef?

22:14 <Daegalus> the joke programming language?

22:14 <deryl> lol he's the first one i lknow of thats known about that

22:15 <deryl> no he means the configuration mangement engine

22:15 <antares_> Daegalus: yes, we are considering writing all our Windows automation stuff using it :)

22:15 <antares_> Daegalus: seriously though, I mean opscode chef

22:15 <antares_> maybe you have heard of Puppet

22:15 <antares_> it is a similar tool

22:16 <deryl> Daegalus: http://wiki.opscode.com/display/chef/Home

22:16 <Daegalus> actually neither. Probably since I might have never needed cloud automation. (I googled these just now)

22:17 <antares_> Daegalus: ok. I was curious about what kind of alternative tools Windows world may have (Chef and Puppet both work on Windows and Windows support is improving but there are way too many differences to reuse most of the work done by both communities)

22:18 <Daegalus> I can try to look into it. Maybe microsoft might have some tool that Im just not aware of

22:18 <antares_> Daegalus: figuring out if there are any better alternatives should be our first step towards Windows and .NET support

22:19 <deryl> i don;t know of anything int he MS world like it

22:19 <deryl> i mean oyu can do SOME of the things with PowerShell, but not nearly what chef can do

22:19 <antares_> deryl: that sucks. Well, maybe we will find a bunch of evolved monkeys to do all this work for us manually. Then package VM images.

22:19 <deryl> antares_: you see me typo you as oyu again, beat me with a steel pipe.

22:20 <antares_> deryl: yes, and then OSS packages on windows is a completely separate story from Linux, OS X or even Solaris

22:20 <deryl> antares_: hahaha will diseased monkies do?

22:20 <deryl> err monkeys

22:20 <deryl> OSS on windows is a freakin nightmware!

22:20 <deryl> s/mw/m/

22:21 <antares_> deryl: that's why I think just .NET support will be what we start with

22:21 <deryl> antares_: if for nothing else than the friggin licensing

22:21 <antares_> but that is realistically "late 2012" or so

22:21 <joewest> CFEngine > Puppet > Chef

22:22 <joewest> http://cfengine.com/

22:22 <antares_> deryl: we will figure out licenses, Microsoft supports popular projects and we know people who can help.

22:22 <joewest> er wait those aren't greater-thans .. just arrows :)

22:22 <joewest> as in evolved from

22:22 <deryl> antares_: well if you stil to supporting the Intel CLR and Mono, you'll support *most* of what people will be using it for in regards to OSS

22:22 <deryl> s/stil/stick/

22:22 <antares_> Intel has their own CLR implementation?

22:22 <deryl> they have since the beginning

22:22 <antares_> deryl: I won't think many people run Mono in production

22:22 <Daegalus> I was JUST about to suggest CFengine xD

22:23 <deryl> MS and Intel collaborated on the CLR, with MS taking second seat to Intel and then licensing it from Intel

22:23 <deryl> but its INTEL that owns the CLR spec, NOT MS

22:23 <deryl> (thankfully)

22:23 <antares_> ah

22:23 <antares_> so you mean .NET

22:23 <deryl> yep

22:24 <deryl> MS's adaptations to the CLR

22:24 <Daegalus> Weird, the FREE version of cfengine uses Cygwin for Windows while hte Paid version has native windows support o.O

22:24 <deryl> thats not weird

22:24 <deryl> thats quite normal actually

22:24 <deryl> bbiaf. need a cig badly

22:24 <Daegalus> CFEngine Nova users can employ fine-grained management of Microsoft Windows servers and desktops, including native control of the Windows Registry, Windows Services and Windows Access Control Lists (ACLs). A new technical whitepaper on “Windows Management with CFEngine 3 Nova” is available

22:25 <Daegalus> might be something to look into

22:25 <antares_> shit, using cfengine will be like going back to cgi after Rails or Play Framework :)

22:25 <deryl> lol

22:25 <antares_> ok, maybe to fastcgi

22:25 <Daegalus> lol, well im just listing info i find now

22:28 <Daegalus> Ugh, I hate having to setup Jenkins for WIndows Phone 7 support. Such a tedious process getting the MSBUILD to work

22:30 <deryl> i used to have fun with .NET when 2.x was released, but i haven;t touched it since then.

22:30 <deryl> haven't run windows in.. oh well over a year and some change

22:30 <Daegalus> Eh, I am enjoy C# mostly. and I like Visual Studio, have yet to find an IDE that comes close. and I hate eclipse with an undying passion

22:31 <deryl> i hate eclipse myself

22:31 <Daegalus> I use Netbeans for Java projects

22:31 <deryl> i don't touch java.

22:32 <deryl> my jruby book is clloecting dust. i really do not like java

22:32 <deryl> err collecting even

22:32 <antares_> dukeleto: around?

22:32 <GitHub180> [travis-worker] michaelklishin pushed 1 new commit to master: http://git.io/PvTqPg

22:32 <GitHub180> [travis-worker/master] Revert "Update Ruby worker timeouts" - Michael S. Klishin

22:33 <Daegalus> well im still in college, so all my work is in Java -_-. I prefer C# over java, Node.js, or Python. not fond of too much else atm. I absolutely hate C++, C is ok, but I prefer Vala syntax for my C, but you cant use Vala on windows just yet, at least not with GTK3

22:33 <deryl> yes i know its a java impl. of the ruby lang, i just don't touch anything java if i can help it

22:33 <deryl> you can beat me for it :) I'll gladly take the beating

22:33 <deryl> now see i love C and C++

22:33 <antares_> deryl: Java world has a lot to offer. Even Java the language. I think if all the effort spent reinventing some of that stuff in C and Ruby was spent contributing to something like travis, we would live a different world in a few years.

22:34 <deryl> lisp though.. that scares me

22:34 <deryl> antares_: true

22:34 <mpapis> joewest: https://gist.github.com/1692428 - antares you could source that functions so wait_port would be available for everyone

22:34 <deryl> i admit i am overly against java the language. i just can't help it

22:34 <antares_> it is ridiculous how many people ignore java.util.concurrent and hate JRuby just because "Java is ugly" or whatever the stereotype is in the Ruby community

22:34 <Daegalus> Eh, I dunno, i never liked C++, dont think I ever will, but compiled languages are growing on me, I just wish their syntax was more like C# or Python (I know about Vala and Genie but they are still young projects)

22:35 <Daegalus> I could never get into Ruby either. No preference or hate for it, just never got into it.

22:35 <antares_> and a few "thought leaders" who spread that FUD further :(

22:35 <deryl> antares_: oh this is a personal thing, i RARELY follow a stereotype just because the community i'm involved in doesn't like something

22:35 <antares_> deryl: I am saying it in general, not meaning you personally

22:35 <deryl> antares_: this is just from my own experiences with it

22:35 <deryl> ah

22:36 <mpapis> antares_: maybe because Java is for monkeys ... just give them bananas and they will code, and i was a java dev too :(

22:36 <deryl> damn, think i took 1 too many pain meds. feeling sick to my stomach as they kick in. think i'm going to go lay down for a bit

22:37 <deryl> antares_: design me a new damned spine will ya?

22:37 <antares_> mpapis: some of the smartest people I know use Java. Not JVM, Java. have been doing it for years and build systems that actually work and handle huge data volumes.

22:37 <mpapis> antares_: the worst manifestation of java codding I found was when some developer was iterating through array in ruby instead of using each/map and I could not fix his code because that was to hard for him

22:37 <antares_> after OpenJDK 7 becomes the default in Debian and Ubuntu there will be no reason to not use JVM. Even travis experience alone proves that CRuby is just a crappy VM.

22:38 <antares_> and Ruby the language is a dead end once average machines have 32 cores

22:38 <deryl> antares_: see? this is why i like hanging in here. pick up such choice and yummy tidbits of info from you :)

22:38 <antares_> it has 0 concurrency support

22:38 <mpapis> antares_: i don't say there are no good devs in java, just the entry barrier is so low

22:38 <antares_> Java actually has decent one, it is just rarely discussed on reddit

22:39 <antares_> mpapis: well, yes. And overengineering was and probably still is a problem in the Java world.

22:39 <Daegalus> Ive pretty much joined the Javascript bandwagon, and learning that

22:40 <joewest> thanks again guyz, have a nice weekend

22:40 <antares_> although ever since Rails showed up a lot of drastically simpler solutions were developed and official JDK improvement standards keep going into that direction (simplification, conventions)

22:41 <deryl> antares_: i could have sworn that ruby 2.x was supposed to introduce concurrency

22:41 <antares_> deryl: you cannot bolt that stuff on top

22:41 <mpapis> antares_: but still, it's common policy to require very simple codding practices in Java so you can be easily replaced by cheaper devs in year or two

22:41 <antares_> deryl: Ruby community is largely illiterate when it comes to concurrency, most of libraries are written as if everything is always single threaded and there are no concurrency hazards of any kinds :)

22:41 <deryl> antares_: no no, doesn't 1.9 have the basics of native threads?

22:42 <deryl> (which is basically all concurrency in java uses iirc)

22:42 <antares_> deryl: on CRuby 1.9 threads do not run concurrently :)

22:42 <deryl> ohhh, now that i did not know

22:42 <antares_> deryl: so the only improvement is that scheduling is now sane

22:42 <mpapis> antares_: most likely because they had global lock

22:42 <deryl> mpapis: yeah they use a GIL for that

22:43 <deryl> well currently

22:43 <antares_> deryl: also, Java was designed for concurrency and top experts on concurrency designed and built java.util.concurrent

22:43 <antares_> deryl: Ruby has nothing like that

22:43 <deryl> antares_: got ya.

22:43 <deryl> see? i'm being edumicated. :) longer i stay working with ruby the more internals i'm learning :) love it

22:44 <antares_> Java has like 3-4 solid mature concurrency libraries to choose from if you want actors or STM or other approaches

22:44 <mpapis> antares_: so Jruby/Rbx does not have GIL ?

22:44 <antares_> Ruby has 1 decent actors library that is a one big hack :)

22:44 <antares_> mpapis: Rubinius 2.0 won't have the GIL

22:44 <antares_> master does not for like half a year

22:44 <antares_> on JRuby you cannot really add it :)

22:45 <antares_> as long as Ruby threads are backed by JVM threads

22:45 <mpapis> then I know what I will use for developing ;)

22:45 <antares_> the GIL will go in CRuby some day

22:45 <antares_> but there will be huge painful migration to learning about concurrency and making most common libraries safe (even if you use processes and actors, concurrency hazards are there)

22:46 <antares_> and it is hard

22:46 <antares_> and we all know what Ruby devs do when something is hard

22:46 <antares_> they scream and run away

22:46 <mpapis> i know but that will be great experience to be able use all cores ;)

22:46 <antares_> and reinveint "a simpler solution" on top of redis

22:47 <antares_> mpapis: as soon as rbx 1.9 mode is solid, I will only use MRI for testing of my libraries before releases

22:47 <antares_> and with travis that is also much easier

22:47 <antares_> I don't do much Ruby any more, frankly

22:48 <antares_> pretty much only for Travis and when I use Chef

22:48 <mpapis> :) i do mostly bash/zsh

22:48 <mpapis> ruby for fun like testing tests :)

22:49 <antares_> I have been doing Clojure pretty much full time since August, 1 year of Scala before that. Plus Java when it makes sense.

22:49 <antares_> mpapis: if you ever want to read some excellent Java code, see Google Guice and Elastic Search

22:49 <mpapis> btw have you seen deryls testing framework ? https://github.com/wayneeseguin/rvm-test/blob/master/batch_scripts/fast/use

22:50 <antares_> mpapis: I have but I did not really have a chance to investigate it :)

22:50 <antares_> it looks great

22:50 <mpapis> comment testing, it's still runable script, tests are in comments

22:50 <antares_> what does RVM test suite currently cover?

22:50 <antares_> yes, I understand

22:50 <mpapis> https://github.com/wayneeseguin/rvm-test/tree/master/batch_scripts/fast

22:51 <antares_> ah, so gemsets and aliases are covered

22:51 <antares_> nice

22:51 <mpapis> longest part is compiling 1.8.7

22:51 <mpapis> not all sub commands but most important are

22:52 <antares_> mpapis: can you explain how rvm stores and operates aliases?

22:52 <antares_> when I do rvm alias create …, what happens?

22:52 <antares_> I am asking because we need to finish our JDK switcher

22:52 <mpapis> most aliases just go to config file

22:52 <mpapis> default gets additional links in system

22:52 <mpapis> so you can source default

22:53 <antares_> mpapis: can you show me the code for updating that file?

22:53 <mpapis> and it's available in rvm/bin

22:54 <mpapis> https://github.com/wayneeseguin/rvm/blob/master/scripts/alias#L165 - here is alias create

22:54 <mpapis> https://github.com/wayneeseguin/rvm/blob/master/scripts/alias#L204 and here it's added to file

22:57 <antares_> mpapis: very cool, thanks. I will try to play with it tomorrow.

23:14 <deryl> antares_: I will be doing more work on rvm-test either this weekend or next.

23:14 <deryl> i want to remove the clint dep and redo the params stuff in OptionsParse for one

23:15 <deryl> and then talk with mpapis about how to properly extend rvm-test so it can be used to test *all* aspects of rvm

23:15 <antares_> mpapis: jruby-head fails to compile for me on JDK 7 preview on OS X

23:15 <antares_> mpapis: the issue is that default Java heap size seems to be too low for JRuby

23:16 <antares_> mpapis: I guess RVM just runs ant jar, without any special env settings?

23:16 <mpapis> antares_: yes pretty vanilla

23:17 <antares_> ok, then it needs to be fixed on jruby side

23:18 <mpapis> deryl: true let me know before starting, I have some important points to consider

23:19 <deryl> mpapis: ok

23:19 <deryl> mpapis: you mean regarding the OptionsParse rewrite or the extending?

23:19 <mpapis> spliting ;)

23:19 <deryl> splitting?

23:20 <mpapis> let's switch to rvm-test

23:20 <deryl> ok

23:36 <antares_> mpapis: I figured it out

23:36 <antares_> mpapis: jruby master builds fine, jruby-1_6 fails (from git)

23:37 <antares_> so I guess they tweaked this for master but not for jruby-1_6

23:37 <mpapis> antares_: I remember headius mentioned it somewhere

23:38 <mpapis> most likely in tweet

23:40 <antares_> mpapis: I found it :)

23:40 <antares_> jruby.compile.memory=256M on 1.6 and jruby.compile.memory=384M on master

23:40 <antares_> *in master

23:57 <antares_> mpapis: https://github.com/jruby/jruby/pull/118

23:58 <mpapis> nice