« first day (671 days earlier)      last day (3190 days later) » 
00:00 - 21:0022:00 - 00:00

00:00
RELOAD!
[Hosch250/Rubberduck] 25 commits. 5396 additions. 4035 deletions.
[retailcoder/Rubberduck] 14 commits. 1077 additions. 682 deletions.
[rubberduck-vba/Rubberduck] 9 commits. 11 opened issues. 12 closed issues. 55 issue comments. 3776 additions. 3307 deletions.
[Vogel612/TranslationHelper\‌​] 9 commits. 5 opened issues. 1 closed issue. 11 issue comments. 260 additions. 156 deletions.
[VSDiagnostics/VSDiagnostics] 1 opened issue. 4 issue comments.
[Zomis/LocoMotion] 3 commits. 588 additions.
 
1 hour later…
01:03
@SimonForsberg I've taken a quite lengthy break from ML due to personal issues, but I'd like to get back into it, and I figured I should do that by applying it. Do you recommend any problems for me to apply ML to? (face recognition, etc)
 
4 hours later…
04:37
> How to make a Monster with an effect that summons another Monster when played or summons a Monster when it dies.
 
3 hours later…
08:14
@SirPython You can always start with the MNIST problem, simply googling will give you enough info, not sure what you want to do with ML though, build your own code or use an existing system and tune the parameters?
08:25
The string magic is real in Rust and awesome: llogiq.github.io/2015/07/10/cow-redux.html
 
2 hours later…
09:59
@Duga Who is that?
@SirPython I find that one of the most interesting problems is text analysis. Face recognition is a tough one and needs to use quite optimized Neural Network implementations to be done correctly.
10:29
hey
lol, reading an article about Rust
> The Rust community seems to be populated entirely by human beings. I have no idea how this was done.
wat
BTW, i'm imagining std::result::Result a bit like Future<T> from Java or Promise<T> from JavaScript
So... is there a way I can "join" several results?
Like...
Result.wait_all([...]).and_then(...)
That article is huge
You mean joining like promises using async stuff?
I don't think Rust itself supports that
Yeah, I thought it might not be in the standard library
10:32
Threading makes it more difficult I'd imagine, but maybe a library does?
Maybe it's a XY problem
But waiting for multiple I/O operations in parallel doesnt' seem like such a bad thing
Hmm this is interesting
#[stable(feature = "rust1", since = "1.0.0")]
impl<T> Index<usize> for Vec<T> {
    type Output = T;

    #[inline]
    fn index(&self, index: usize) -> &T {
        // NB built-in indexing via `&[T]`
        &(**self)[index]
    }
}
Then again, maybe it would be more easily solved with Channels and Rust just doesn't have a suitable abstraction aroudn that yet
Because Vec[T] is actually a slice of T like &[T] you can just use that indexing method
Rust isn't feature-complete though it provides a stable base it seems
Turns out there's some work on it, but it's generally considered needing a rework
10:35
There's so much that they want to rework :o
It's a very new language]
Hmmm so Vec has a get method, now only trying to figure out where it comes from
it's "only" 6 years old
I'm happy with the lang itself even if the stdlib needs work
To be fair stable 1.0 got released in December 2015?
Yeah, the latest stable release (1.9) was yesterday
The fact it has a package manager built-in basically helps alleviate any concerns I have about stdlib anyway
10:36
Implementing doc.rust-lang.org/std/ops/trait.Index.html gives you an index() method that is directly used by [], but where's get
i'm excited about this language because it's the first "new language" I've seen for a while that seems to be useful outside of academia
Yeah Cargo is awesome, it seems to be on-level with Java's Gradle and React's thingie
also, looks like cargo has future, eventual along with others..
React doesn't have a thingie, you're thinking of Node's npm
I'm excited because it's a way to get into lower level programming without losing my mind :D
@DanPantry Ah yes npm
I love it's type system
it's seriously awesome
that's what i was looking for it seems
future exists but it hasn't been updated in ~6 mo
10:39
Once they rework macros to allow concat/intermangling in function names it's going to be really awesome
My only complaint about pushing things outside the stdlib is that support is not guaranteed
The current bit-vec package for BitVec is not optimal and issues are not being work on on a steady basis
sure but on the other hand
not being in stdlib usually means faster iterations of progress
That's also true, if people work on it
I got news yesterday that it might be possible to replace my Algorithms subject at uni with something else :o
I can implement algorithms but creating your own is basically walking into hell
Only maybe I can "replace" it with a subject I've already done, for that I need to get an overview of my study programme and seeing as it has been modified over 9000 times that's pretty difficult :/
@skiwi looks like the solution to the future thing is basically Barrier
but it's blocking... :(
That's not really helpful then
i forgot how easy it was to use concurrency in javascript compared to everything else
10:46
Doesn't JS allow you to blow stuff up though?
you don't get the same type safety guarantees but I'm not sure what you mean by blow stuff up
So it seems the soltuion for non-blocking communication is Channel with try_recv
Mutating stuff from two threads?
JS only has one thread, so that's not possible
Right, that's one way to solve it
What is the special thing about promises then?
If it's all executed consecutively then it seems like it shouldn't be an issue to implement that in Rust
Promises let you "wait" for multiple async operations to finish or wait for one of them to finish, error, etc
But with JavaScript at least this isn't blocking behaviour
So i mean sure it's easy to spawn multiple threads and join them and block in Rust waiting for those threads to finish
but that may not always be ideal
example, let's say I'm writing a game using opengl
in rust
and I want to load a file
I'd have to block and wait for those file(s) to finish loading
unless there's some kind of asynchronous continuation thing I can use across multiple threads
to synchornise threads but without blocking
fn when_all<T: Any, K: Error>(results: &[Result<T, K>]) -> Result<&[T], K>
I'd basically be looking for something like that, which would condense multiple results into a single result that would eagerly return an error int he first result that occurred, or return the results if it succeeded
10:54
But isn't Result exactly how Promise works?
hope that makes sense
result is exactly how promise works, but there's no method like the one I put above, which promises have
Promise.all([async(), async2(), async3()]).then((async1, async2, async3) => ...).catch((error) => ....)
the above is possible in JS
You have the and method for chaining manually
That's a start
that sort-of works, unless you're dealing with an array of Results
Or and_then maybe
or slice or whatever it is in rust-speak
10:55
You are right about the array case though
or slice
Seems like you could quite easily make a macro though that does that
I'm not a fan of macros (after my limited exp in C++)
but I guess if that is the way to do it..
So get() shows up on Vec in the docs but it doesn't define it nor implements a trait that defines it
I'm finding the docs are pretty hard to navigate too
There's no clear "this type implements these traits" list
it's hard to tell where X method comes from
Never mind, yes there is. RIght at the bottom lol
11:01
But then Vec does not have any direct relation with SliceExt
> impl<T> Borrow<[T]> for Vec<T>
fn borrow(&self) -> &[T]
Perhaps that is the trick there
Likewise
> impl<T> BorrowMut<[T]> for Vec<T>
fn borrow_mut(&mut self) -> &mut [T]
Vec doesn't have any relation with SliceExt, but the items it has are housed in a slice
so it makes sense that vec would expose slice operations
So Vec[T] is not a [T], but a reference &Vec[T] is a &[T] likewise for mutable
(even if that is implementation detail)
Also SliceExt has no self operations defined, so it doesn't own anything it just borrows
So being a slice gives you all the nice methods, but a BitVec being a slice doesn't make sense because a slice of bools is not efficient
I'm thinking if I should implement some of doc.rust-lang.org/core/slice/trait.SliceExt.html methods on my BitVector
Though not many make sense, like contains()
Check if it contains a true or false value :D
11:40
> lib.rs:28:10: 28:50 error: binary operation `!=` cannot be applied to type `<S as std::ops::BitAnd<usize>>::Output` [E0369]
lib.rs:28 (self.data[data_index] & (1 << remainder) != 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib.rs:28:10: 28:50 help: run `rustc --explain E0369` to see a detailed explanation
lib.rs:28:10: 28:50 note: an implementation of `std::cmp::PartialEq` might be missing for `<S as std::ops::BitAnd<usize>>::Output`
lib.rs:28 (self.data[data_index] & (1 << remainder) != 0)
WHY
impl<S> Index<usize> for BitVector<S>
    where S: Sized + BitAnd<usize> + Not + Eq {
    type Output = bool;

    fn index(&self, index: usize) -> &bool {
        let data_index = index / (std::mem::size_of::<S>() * 8);
        let remainder = index % (std::mem::size_of::<S>() * 8);
        (self.data[data_index] & (1 << remainder) != 0)
    }
}
Do you have any clues there @DanPantry?
where's the type of data?
struct BitVector<S = usize>
    where S: Sized + BitAnd<usize> + Not + Eq {
    data: Vec<S>,
    capacity: usize
}
I'm not sure if I should be duplicating that type everywhere, probably not?
hm
i'm not sure
maybe it's because you're comparing usize and, from the looks of it, f32
with f32 being 1<< remainder
nvm i'm an idiot
Would that turn into f32?
basically you're doing usize & f32 != i32
i would assume so
11:43
It complains mostly about the ::Output type though? Which is bool
otherwise you'd lose precision
I'm not sure, then
I think f32 and i32 are the same on bitwise ops but not sure
I can't really read rust that well at the moment
As far as I know bools definitely have a != method though
Well, I can read it, but the whole type inference thing i'm not great at
11:44
Same here so far
The error basically seems to be that you're trying to != on usize, which is not supported
I think I'll go into the depths of SO...
Oh screw me
I'm missing parentheses, ain't I?
i think so.
(self.data[data_index] & (1 << remainder)) != 0
Except it gives the same error
hm
i think this expression
(self.data[data_index] & (1 << remainder) != 0)
11:46
But they are placed better this way
ends up being
BitAnd<usize>::Output != int32
and those two aren't comparable / you can't do != on that output
The self.data[data_index] is of type Sized + BitAnd<usize> + Not + Eq
That I could understand, only I don't see yet how it gets there
Yes, but BitAnd is the trait that implements +.
basically BitAnd<S>::Output doesn't work with !=
Unless that != check doesn't produce a bool?
well it's a binary operation, not a boolean one, apparently, not sure if that means anything to you
11:50
SO time... I think
Or reddit, though SO seems to be the more logical place
Oh imagine the amount of rep I can earn once I understand Rust and start being active on SO again
lol
i'm just struggling to understand the type system
Like, BitAnd<usize>::Output - what type is that?
that's the nested type of BitAnd but what does it implement? what can I cast it to? etc
I'm looking for a way to get a better title than "Help"
"help plz"
I don't know why it comes up with the ::Output type there
Because BitAnd returns Output when you use it
fn bitand(self, rhs: RHS) -> Self::Output
ahh
11:54
So it is complaining about that output? That might explain more
for BitAnd<usize>::Output, Self::Output = usize
so yeah it simplifies to usize != i32
and as far as I remember those two are not comparable
right?
Note that that wasn't in the docs and I had to look into the source :(
Shouldn't that expand to Self::Output = S?
> for BitAnd<usize>::Output, Self::Output = usize
so yeah it simplifies to usize != i32
I'm going on SO nevertheless though, but now have issues formatting the error message lol
fn main() {
  let size: usize = 5;
  let num: i32 = 0;

  println!("{}", size != num);
}
This will throw a type error
Though I am confused why it doesn't show you the type error instead of the error it was giving you which is quite cryptic
but that is what I see the issue boiling down to
((self.data[data_index] & (1 << remainder)) as i32 != 0)
you could maybe try that (be careful because 1 << remainder is a float
as a proof of concept
12:00
0
Q: Binary operation != cannot be applied when using generics for a bit vector

skiwiI'm in the process of implementing a Bit Vector class as an exercise, however only knowing Rust for less than a week I run into trouble with the following code: use std::cmp::Eq; use std::ops::BitAnd; use std::ops::Index; use std::ops::Not; struct BitVector<S = usize> where S: Sized + BitAnd<

I'm giving it a shot, but continuing here as well
I'm not sure about BitAnd<usize> actually
Shouldn't that be BitAnd<S> in the first place as S = usize?
(as default)
yea you could do that but you'll have to restrict your S to the types that BitAnd implements
I agree, though, it seems "wrong" to use usize for every type
Ideally I want S to be things like u32, u64, usize
just do something like this then
...hm, never mind
I don't think i32 could qualify as I rely on the bits all being zero
you can't do "or" in trait constraints can you?
well BitAnd supports basically all numeric types + usize/isize
12:04
I don't think I can or
BitAnd uses a macro to implement it
Though technically I think I could literally write all zeroes to the value passed into S but that seems to be not so nice
I changed BitAnd<usize> to BitAnd<S>
> Compiling bit-vector v0.1.0 (file:///C:/Users/Frank/Dropbox/workspace/bit-vector)
lib.rs:27:35: 27:49 error: mismatched types:
expected `S`,
found `_`
(expected type parameter,
found integral variable) [E0308]
lib.rs:27 (self.data[data_index] & (1 << remainder)) != 0
^~~~~~~~~~~~~~
lib.rs:27:35: 27:49 help: run `rustc --explain E0308` to see a detailed explanation
lib.rs:27:10: 27:50 error: binary operation `!=` cannot be applied to type `<S as std::ops::BitAnd>::Output` [E0369]
lib.rs:27 (self.data[data_index] & (1 << remainder)) != 0
yeah i would be surprised if you didn't get errors for that
S could potentially be anything bit BitAnd only supports a few types.
So it complains that (1 << remainder) is not of type S
yes, that makes sense, 1 << remainder will be a float
12:07
Or I'm not sure here
Expected type parameter, found integral variable seems more severe
i don't understand that error
I'm going in circles
    impl<S> Index<usize> for BitVector<S>
        where S: Sized + BitAnd<S> + Shl<usize> + Not + Eq {
        type Output = bool;

        fn index(&self, index: usize) -> &bool {
            let data_index = index / (std::mem::size_of::<S>() * 8);
            let remainder = index % (std::mem::size_of::<S>() * 8);
            (self.data[data_index] & (((1 as S) << remainder) as S)) != 0
        }
    }
Now I"m back at the original error message again
I thought Shl<usize> is correct though, you want to be able to shift S by usize
Actually S should also implement One and then I can call S::one() instead of (1 as S)
This github.com/contain-rs/bit-vec/blob/master/src/lib.rs bit-vec implementation doesn't clarify much either
12:54
-1
A: Binary operation != cannot be applied when using generics for a bit vector

Chris EmersonYou've said that S must implement Eq, but not that it needs PartialEq in your where clause. Adding that should allow the function to use !=. It's worth reading the compiler error carefully; it's trying to say just that.

Interesting, someone else downvoted that answer
13:07
Could you help me understand what'sg oing on here, @skiwi?
struct Circle {
    x: Option<f32>
}

impl Circle {
    fn take_ownership(self) {

    }
}

fn main() {
    let circle = Circle { x: Option::None };
    circle.take_ownership();

    println!("{:?}", circle.x);
}
From what I understand, take_ownership takes.. ownership of self, which means then self will collected when take_ownership ends
Which means then that circle has "moved"
Correct?
13:18
Checking..
@DanPantry I'm not sure about that
In your current statement there is nothing to move it into
But it should be moved on the other hand
@skiwi there is something to move it into
take_ownership takes ownership of self, so it's "moved" into take_ownership
And as an effect it's simple gone?
I don't want to rain on your parade, but Index::index returns a &Output so you cannot compute it on the fly... — Matthieu M. 19 mins ago
this sounds bad
Yes, because take_ownership takes ownership of the self object that object will be collected at the end of take_ownership's scope
As far as I understand, move || {} is essentially equivalent to taking ownership of that value
so it's the same semantics as thread::spawn
Ahhhhhh
3
A: Binary operation != cannot be applied when using generics for a bit vector

DogbertThis particular error here, in simple terms, means that the Output of BitAnding S and usize does not implement PartialEq. One fix would be to add a constraint that S's BitAnd<usize>s Output is S: BitAnd<usize, Output = S> After this, you'll run into another error because you're comparing the v...

This makes sense
Instead of 0 I have to use S::zero()
I read that, that's a really comprehensive answer
> To fix that you can define your own Zero trait and use that
How would that work?
13:26
Same as the One trait I think
> impl Zero for usize
fn zero() -> usize
Ah, BitAnd<usize, Output = S> also makes sense, I perform the bit-and with usize which is (1 << remainder) (so it's not a float?) and have an S as output
it's intersting when you use bad mutable patterns how you realise how inefctious mutables can be
struct Point {
    x: f32,
    y: f32,
    z: f32
}

struct Player<'a> {
    // Ouch!
    position: &'a mut Point
}

fn main() {
    let mut position = Point {
        x: 0.0,
        y: 0.0,
        z: 0.0
    };

    let player = Player {
        position: &mut position
    };
}
for "traditional" player objects based on OOP, you have to have mutability everywhere
And once it's obvious where you're using mutability, you suddenly start to care about it a lot more
I'm not following it... yet
The code for Point and Player is the part that is correct, right?
13:41
it was more the demonstration that once you try and use mutable properties in Rust, it really makes it obvious just how much you have to make mutable for that to work
I'm not saying "this code is bad or good", I'm just saying that rust points out exactly what you are making mutable, which is pretty cool
if I wrote code lke that in OOP, I wouldn't care. But after seeing just how much can be changed at any point by any thing it really makes me care about immutability
But the position binding has to be mutable for player to make sense, right?
with that structure, yes
I think the cool thing is that you can use your Point class both mutably and immutably
yes that's also cool
I'm trying to figure out how to use the Zero trait as it's unstable :/
Uh ok it only works in Nightly right now..
So I'd have to define my own trait
13:51
So what would be the semantic difference between these two, @skiwi?
These two?
    struct Player {
        position: Point
    }

     struct Player<'a> {
        position: &'a Point
     }
first one takes ownership of the position and so it will be collected when it goes out of scope, but doesn't the second one as well?
I wouldn't have the slightest clue actually on this
My code compiled!
Lifetimes are hard.
Do I need to import my own module in infile tests or something?
13:54
no, you can use super:: if your tests are in ad iffernt module and the main code isn't in one
also, yes, now I worked io ut
in the first one player takes ownership of the position and nothing else can use it
in the second one, the player doesn't taken ownership of position so anyone can access it, but the Position struct is collected when the Playero ne is (I think)
Ah of course you are right on that one
super::? Ok I'll try
mod tests {
    use super::*;

    fn test_with_capacity() {
Doesn't work
> lib.rs:71:27: 71:58 error: failed to resolve. Use of undeclared type or module `BitVector` [E0433]
lib.rs:71 let vec_32_1024 = BitVector::<u32>::with_capacity(1024);
when I had this, this worked..
struct Foo;

mod tests {
  fn test() {
    super::Foo
  }
}
pseudo of course
Ah
Hmm :/
> lib.rs:71:27: 71:58 error: no associated item named `with_capacity` found for type `BitVector<u32>` in the current scope
lib.rs:71 let vec_32_1024 = BitVector::<u32>::with_capacity(1024);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ah maybe not pub
So the unit tests actually test pub/"non-pub" as well? Cool!
> lib.rs:69:27: 69:65 error: no associated item named `with_capacity` found for type `BitVector<u32>` in the current scope
lib.rs:69 let vec_32_1024 = super::BitVector::<u32>::with_capacity(1024);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wtf doesn't work
It works if I don't hae the ::<u32> there
I'm not sure if BitVector<S = usize> is doing what I think it does
Oh hmm
> lib.rs:71:27: 71:58 error: no associated item named `with_capacity` found for type `BitVector<u32>` in the current scope
lib.rs:71 let vec_32_1024 = BitVector::<u32>::with_capacity(1024);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib.rs:71:27: 71:58 note: the method `with_capacity` exists but the following trait bounds were not satisfied: `u32 : std::ops::BitAnd<usize>`
14:12
you don't sound like you're having much fun
I think it's still difficult
What I need in order for it to work is that either u32 implements BitAnd<usize> which it does and should not as it could be 64-bits
Or I need to cast remainder, which has size usize to S which can have size u8, u16, u32, u64 or usize
Only casting usize on a 32-bit machine to u64 is an edge-case, but that should work
Eh casting usize to u8 is bound to fail
But I know as a fact that remainder will never exceed the capacity of S...
14:32
@DanPantry is.gd/IIdiSQ it works
I'm slowly understanding lifetimes
trait Item {}

trait ItemContainer {
    fn has_item<T: Item>(&self, item: &T) -> bool;
}

struct Inventory<'a> {
    items: Vec<&'a Item>
}

impl <'a> ItemContainer for Inventory<'a> {
    fn has_item<T: Item>(&self, item: &T) -> bool {
        false
    }
}

#[derive(Debug)]
struct InventoryItem {}
impl Item for InventoryItem {}

fn main() {
    let item = InventoryItem {};
    {
        let container = Inventory {
            items: vec![]
        };
        assert!(!container.has_item(&item));
Very bad example above
basically if I wanted to store Items in a vec, I need to make srue that Items at least have the same lifetime of the enclosing Inventory
You'd want to implement Hash or something btw, might be helpful ona real example in future
Though how <'a> works just seems magic to me
Lots of lifetimes
And what if you had <'a, 'b>?
How does that work?
14:42
The 'a and 'b etc. are captured on their types, not in the <> definition
So for <'a, 'b> they need to be put somewhere on the types either arguments or return value
And then it just does the lifetime rule twice I guess
This hack...
static TRUE: bool = true;
static FALSE: bool = false;

macro_rules! bool_ref {
    ($cond:expr) => ({
        if $cond { &TRUE } else { &FALSE }
    })
}
I get that, but I mean..
hm.
I don't know how to phrase it.
macro_rules! bool_ref {
    ($cond:expr) => (if $cond { &TRUE } else { &FALSE })
}
if I had <'a, 'b> and say one was put on the return value and one on the input parameter, for example
That actually works
how would 'a and 'b differ there? why wouldn't they have teh same lifetime?
14:44
Good question... The chapter on lifetimes kind of answers that
Only I don't understand the answer yet
I read that, but I couldn't understand it
idk maybe I'm just being a bit slow today
Cannot help with that one
it explains how lifetimes are used, but doesn't explain how they work
meh. i'll just haev to bash at it until i get it wrong and then learn from that
Extra open tabs since learning Rust: Over 9000 90
U seen my BitVector implementation now?
and at least half of them probably pointing to one of [Borrowing, Ownership or Lifetimes] i bet x)
14:45
Well, it's just a start to be honest
my brain kinda turned to mush while reading it
but I just had an espresso, so give me half an hour.. lol
15:00
wtf, how do i even do this
I want to store &T and also be able to use .contains on that vector
but as a result it means that .contains has to accept &K where K : &T, PartialEq
which makes it impossible to compare
sounds like I shouldn't be using a vec for this
strictly speaking what I am trying to do is more suited towards a hash map anyway
okay, it makes more sense now.
impl PartialEq for Item {
    fn eq(&self, other: &Item) -> bool {
        let Item(other_id) = *other;
        let Item(my_id) = *self;

        other_id == my_id
    }
}
I wasn't implementing PartialEq properly
the error message for not using *other is really cryptic
it claims that it expected &T but got T. Actually, it's the other way around, I was givign it &T but it wanted T.
by "it" I mean the destructuring pattern
15:25
Modules in rust are weird
mod inventory;

use inventory::Inventory;

fn main() {
    let inventory  = Inventory {};

}
I have to use mod to reference a local module (./inventory.rs) and then use it to alias the typename
15:49
@DanPantry There's a Borrow<K> trait, might be useful?
@DanPantry Yeah, modules are "double"
Any clue how this works?
1
Q: implement generic Fibonacci in Rust without Copy trait

skanurI'm trying to learn Rust and am a beginner. How does one go about implementing a generic version of Fibonacci number generation without using Copy trait in Rust? My code is given below. I had to use Copy trait, otherwise the compiler would complain cannot move out of borrowed content [E0507] in...

In the iterator he uses self.next but I don't see next defined anywhere
16:29
Thinking about Macros in Rust again, they actually make lots of sense: It is much better to use a macro for any non-implementation-detail private method because it didn't really belong in that class as a method in the first place
 
1 hour later…
17:33
I just realized that DugaBot is pushing by itself to the Duga repo
@skiwi Congratulations :)
I knew something was doing it, but not that it was called DugaBot ^^
Weekend finally? :)
[skiwi2/bit-vector] Ping: Approachable is better than simple.
[skiwi2/bit-vector] skiwi2 pushed commit c5514390 to master: Initial commit
[skiwi2/bit-vector] skiwi2 pushed commit 5d440e55 to master: Merge branch 'master' of github.com:skiwi2/bit-vector
@skiwi Yes!!! And a long one it is. National Holiday on Monday
Nice :)
17:50
@skiwi She created her Github account a long while ago. Was about time she started using it
18:09
[skiwi2/bit-vector] skiwi2 pushed commit 71074e98 to master: Added Travis configuration
18:21
http://www.commitstrip.com/en/2016/06/03/right-click-not-allowed/
CommitStrip
Right-click not allowed!
CommitStrip
1464977768
2
[skiwi2/bit-vector] skiwi2 pushed commit 493ebc79 to master: Updated Travis configuration
I have a feeling that I forgot a build hook...
[skiwi2/bit-vector] build for commit 493ebc79 on master: The Travis CI build passed
@Duga How does this work without a build hook?
 
2 hours later…
20:15
[skiwi2/bit-vector] skiwi2 pushed commit 98736013 to master: Updated Travis configuration to avoid failures on nightly
[skiwi2/bit-vector] build for commit 98736013 on master: The Travis CI build could not complete due to an error
BUILD FAILURE!
Now that's ironic...
[skiwi2/bit-vector] skiwi2 pushed commit ef892fe6 to master: Fixed issue that prevented the Travis YML file from being parsed correctly
[skiwi2/bit-vector] build for commit ef892fe6 on master: The Travis CI build passed
[skiwi2/bit-vector] skiwi2 pushed commit 1dfcc8e6 to master: BitVector now implements the Zero and One traits for the num package instead of custom traits and also implements the Unsigned trait
[skiwi2/bit-vector] build for commit 1dfcc8e6 on master: The Travis CI build passed
00:00 - 21:0022:00 - 00:00

« first day (671 days earlier)      last day (3190 days later) »