These are chat archives for bjz/gfx-rs

8th
Jul 2014
Corey Richardson
@cmr
Jul 08 2014 01:56
r? bjz/glfw-rs#185
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:01
what dies -C extra-filename=_rust do?
Corey Richardson
@cmr
Jul 08 2014 02:01
makes it libglfw_rust.so
instead of libglfw.so
thus causing every project ever to have massive link hemmorages
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:01
waaaa
Corey Richardson
@cmr
Jul 08 2014 02:01
part of the recent crate name changes
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:02
why?
why are we doing this?
Corey Richardson
@cmr
Jul 08 2014 02:02
I don't remember, ask wycats/alex
why are we doing what? removing the crate hash?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:02
so we don't want to conflict with the real libglfw on a user's machine?
Corey Richardson
@cmr
Jul 08 2014 02:03
no, we really don't :P
also it causes the gfx-rs examples to fail to build
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:03
interesting
ok, just wondering
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:03
the good news is make files are going to be easier to write.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:04
why _rust and not -rs? Is that a convention?
Corey Richardson
@cmr
Jul 08 2014 02:04
I think _rust is clearer, makes it obvious what the file belongs to
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:05
so this is a temporary thing, pending an actual, official convention
Corey Richardson
@cmr
Jul 08 2014 02:05
No, it's a thing for people who use the makefile instead of cargo :P
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:05
wait really?
Corey Richardson
@cmr
Jul 08 2014 02:06
yes, cargo passes all the flags into rustc correctly already.
brendanzab @bjz is so confused
Corey Richardson
@cmr
Jul 08 2014 02:06
So rustc grew an --extern flag
that lets you pass in the location where a crate lives
extern crate foo;
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:06
rustc --crate-file-name foo.rs is not good enough?
Corey Richardson
@cmr
Jul 08 2014 02:06
and then rustc --extern foo=path/to/foo.whatever
And you can use -C extra-filename to add junk to the object file that rustc produces.
brendanzab @bjz is sad that we can't just use the name of the project, glfw-rs
Corey Richardson
@cmr
Jul 08 2014 02:08
we could use -rs, I don't care :P
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:08
do we just conflict because we are also linking to libglfw?
Corey Richardson
@cmr
Jul 08 2014 02:09
yeah
it sees the Rust libglfw first, and then stops looking for the real libglfw
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:09
then projects that aren't wrappers would normally just use their name
Corey Richardson
@cmr
Jul 08 2014 02:09
yep
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:09
but wrappers might have conflicts
Corey Richardson
@cmr
Jul 08 2014 02:10
(they'd also normally just use cargo)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:10
I would say just use the github project name
Corey Richardson
@cmr
Jul 08 2014 02:10
(which handles it all for you)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:10
libglfw-rs
Corey Richardson
@cmr
Jul 08 2014 02:12
@bjz updated
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:13
if you build with cargo, or a makefile, will the import be different?
Corey Richardson
@cmr
Jul 08 2014 02:13
no
only thing that changes is flags you pass to rustc
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:14
extern crate glfw; vs extern create glfw = "glfw-rs";
Corey Richardson
@cmr
Jul 08 2014 02:14
extern crate glfw; still works with -C extra-filename=foo
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:14
ok
Corey Richardson
@cmr
Jul 08 2014 02:14
yeah the extra-filename doesn't change anything about how the crate is used
thankfully
that'd be a nightmare
Coraline Sherratt
@removed~csherratt
Jul 08 2014 02:14
how does it the library get found?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:16
src/comm/lib.rs:16:1: 17:2 error: invalid character `.` in crate name: `github.com/bjz/gfx-rs#comm:0.1`
src/comm/lib.rs:16 #![crate_name = "github.com/bjz/gfx-rs#comm:0.1"]
:/
Corey Richardson
@cmr
Jul 08 2014 02:16
noooo bueno
@csherratt no idea
Dzmitry Malyshau
@kvark
Jul 08 2014 02:16

@bjz Rust complains that bitflags do not implement Show:

failed to find an implementation of trait core::fmt::Show for rast::Comparison

Corey Richardson
@cmr
Jul 08 2014 02:17
Oh you did the crate name weirdly
it's not an id
it'd just be gfx
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:17
@kvark we need to implement it manually
@kvark unfortunately
@kvark just do a bitflags! { #[deriving(Show)] flags ... }
then I will do it later
brendanzab @bjz also hates the name rast :P
Dzmitry Malyshau
@kvark
Jul 08 2014 02:19
@bjz ok. What name do you want?
Also, last call to do something with Factor type
@bjz bitflags! { #[deriving(Show)] flags ... } fails to compile
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:20
what error?
brendanzab @bjz looks at Factor again
@bjz I could call it State but that would be pretty generic...
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:22
Could you post the bitflags! invocation?
brendanzab @bjz wrote bitflags! (minus the later additions)
Dzmitry Malyshau
@kvark
Jul 08 2014 02:23
bitflags! {
    flags Comparison: u8 {
        static Never   = 0b000,
        static Less    = 0b001,
        static Equal   = 0b010,
        static Greater = 0b100,
        static Always  = 0b111
    }
}
actually, it complains not about deriving Show. I'm getting the same error when trying to implement it manually.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:24
compiles
hmm, let me hack together an example
btw, I have a Q about Factor, but I will do this first
Dzmitry Malyshau
@kvark
Jul 08 2014 02:28
how do I express 0 if I don't have it explicitly named?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:28
?
please clarify
Dzmitry Malyshau
@kvark
Jul 08 2014 02:29
in a match statement, how do I write the case for 0 (no flags set)?
Supposing I don't have Never defined, and I need to match bitflags! against all combinations. The 0b001 case will look like Less => gl::LESS. How would the 0b000 case look like?
Corey Richardson
@cmr
Jul 08 2014 02:31
@bjz bjz/glfw-rs#186
;p
Dzmitry Malyshau
@kvark
Jul 08 2014 02:33
looks like the match doesn't work at all :(
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:41
weird how match doesn't work :(
my kinda ugly thing: http://is.gd/6Sp3Bh
Corey Richardson
@cmr
Jul 08 2014 02:43
Hello this is window
HELLO THIS IS DOGE
Dzmitry Malyshau
@kvark
Jul 08 2014 02:44
@bjz this should be a part of bitflags! macro. The main concern now is not Show implementation but the match statement
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:44
Indeed
Dzmitry Malyshau
@kvark
Jul 08 2014 02:44
should we stay with my original code then for now? Until bitflags! are sorted out...
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:45
yeah whatevs
:(
we should use bitflags! more though - especially for the performance critical stuff
@cmr:
mkdir -p lib
rustc --out-dir=lib -O src/comm/lib.rs
rustc -L lib -L deps/gl-rs/lib -L deps/glfw-rs/lib --out-dir=lib --cfg=gl -O src/device/lib.rs
rustc -L lib -L deps/gl-rs/lib -L deps/glfw-rs/lib --out-dir=lib --cfg=glfw -O src/platform/lib.rs
rustc -L lib -L deps/gl-rs/lib -L deps/glfw-rs/lib --out-dir=lib --cfg=glfw -O src/render/lib.rs
rustc -L lib -L deps/gl-rs/lib -L deps/glfw-rs/lib --out-dir=lib --cfg=glfw -O src/gfx/lib.rs
mkdir -p examples
rustc -L lib -L deps/gl-rs/lib -L deps/glfw-rs/lib --out-dir=examples src/examples/triangle/main.rs
error: linking with `cc` failed: exit code: 1
note: cc '-m64' '-L' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib' '-o' 'examples/main' 'examples/main.o' '-Wl,-force_load,/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libmorestack.a' '-nodefaultlibs' '-Wl,-dead_strip' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libnative-4e7c5e5c.rlib' '/Users/bzabarauskas/dev/gfx-rs/lib/libgfx.rlib' '/Users/bzabarauskas/dev/gfx-rs/lib/librender.rlib' '/Users/bzabarauskas/dev/gfx-rs/lib/libplatform.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libtime-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libserialize-4e7c5e5c.rlib' '/Users/bzabarauskas/dev/gfx-rs/lib/libdevice.rlib' '/Users/bzabarauskas/dev/gfx-rs/lib/libcomm.rlib' '/Users/bzabarauskas/dev/gfx-rs/deps/gl-rs/lib/libgl.rlib' '/Users/bzabarauskas/dev/gfx-rs/deps/glfw-rs/lib/libglfw.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libsemver-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/liblog-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libstd-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/librand-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libsync-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/librustrt-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libcollections-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/liballoc-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/liblibc-4e7c5e5c.rlib' '/usr/local/lib/rustlib/x86_64-apple-darwin/lib/libcore-4e7c5e5c.rlib' '-L' 'lib' '-L' 'deps/gl-rs/lib' '-L' 'deps/glfw-rs/lib' '-L' '/Users/bzabarauskas/dev/gfx-rs/.rust' '-L' '/Users/bzabarauskas/dev/gfx-rs' '-lglfw3' '-framework' 'Cocoa' '-framework' 'OpenGL' '-framework' 'IOKit' '-framework' 'CoreFoundation' '-framework' 'CoreVideo' '-lSystem' '-lpthread' '-lc' '-lm' '-Wl,-rpath,@loader_path/../../../../../usr/local/lib/rustlib/x86_64-apple-darwin/lib' '-Wl,-rpath,@loader_path/../deps/glfw-rs/lib' '-Wl,-rpath,/usr/local/lib/rustlib/x86_64-apple-darwin/lib' '-lcompiler-rt'
note: ld: warning: directory not found for option '-L/Users/bzabarauskas/dev/gfx-rs/.rust'
0  0x103ebe0e7  __assert_rtn + 144
1  0x103ef5c82  archive::File<x86_64>::makeObjectFileForMember(archive::File<x86_64>::Entry const*) const + 1142
2  0x103ef564e  archive::File<x86_64>::justInTimeforEachAtom(char const*, ld::File::AtomHandler&) const + 122
3  0x103f0aa0b  ld::tool::InputFiles::searchLibraries(char const*, bool, bool, bool, ld::File::AtomHandler&) const + 219
4  0x103f127c4  ld::tool::Resolver::resolveUndefines() + 160
5  0x103f1492d  ld::tool::Resolver::resolve() + 79
6  0x103ebec47  main + 679
A linker snapshot was created at:
    /tmp/main-2014-06-07-194402.ld-snapshot
ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember, file /SourceCache/ld64/ld64-236.4/src/ld/parsers/archive_file.cpp, line 355.
clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error
Corey Richardson
@cmr
Jul 08 2014 02:46
@bjz #83
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:46
@cmr was trying to fix the #[crate_name ...] thing
Corey Richardson
@cmr
Jul 08 2014 02:46
I don't know what you did
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:46
ooh
Corey Richardson
@cmr
Jul 08 2014 02:46
but rustc deffers didn't like it
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:47
lets wait for travis on that patch
hehe
Dzmitry Malyshau
@kvark
Jul 08 2014 02:47
@bjz no, really, don't put your head into the ground please. I don't like how either Comparison or Factor look now, but since bitflags! is not supported...
Also, if you want to have it under a different name (than rast) now is a good time to tell it.
Corey Richardson
@cmr
Jul 08 2014 02:48
yeah Comparison and Factor are weird
I was thinking a syntax extension that would parse an equation into the right constants
S - D
etc :P
the cool thing is that with rust that's actually possible
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:48
wut? bigger example plz
Dzmitry Malyshau
@kvark
Jul 08 2014 02:49
@cmr yeah, I was going to add the string parser for that (similar to how Comparison is parsed)
You specify an equation that combined the source and destination somehow
it's very limited what it can do though
Dzmitry Malyshau
@kvark
Jul 08 2014 02:50
The whole blending state is pretty crappy. We should have had it programmable already... Too many enums these days.
I only read to part 9
but it was pretty informative, if written slightly weird
@bjz travis passed
Dzmitry Malyshau
@kvark
Jul 08 2014 02:51
@cmr seems pretty nice at the first glance
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:52
@cmr it's awesome to have you on board btw
Corey Richardson
@cmr
Jul 08 2014 02:53
This is a lot of fun, I'm learning a ton about graphics.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:53
@cmr I head home on the 20th btw
Corey Richardson
@cmr
Jul 08 2014 02:53
I'm going to start working on a COM wrapper to get D3D support.
Dzmitry Malyshau
@kvark
Jul 08 2014 02:53
@cmr we haven't even started doing the fun stuff yet. We are just doing baby steps...
@bjz may have some fun implementing terrain sample though ;)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:53
@cmr would be cool to catch up again in person, chat about graphics stuff
Corey Richardson
@cmr
Jul 08 2014 02:54
yeah
I'm not sure I have a lot to chat about
I don't really know much >_>
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:55
haha
Corey Richardson
@cmr
Jul 08 2014 02:56
libglfw-rs.so is pretty nice
good call
Brendan Zabarauskas
@brendanzab
Jul 08 2014 02:57
:)
Dzmitry Malyshau
@kvark
Jul 08 2014 03:06
@bjz #79 is kinda ready, unless you have more concerns... BTW, have you filed a bug on bitflags! for yourself yet?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:06
@kvark could you explain what Factor is again?
Dzmitry Malyshau
@kvark
Jul 08 2014 03:07
it's the blend factor - a multiplier for either the source or the destination value (same type for both)
See @cmr -provided link on blending. For example, with ADD equation, the result value of the stage is: S*Fs + D*Fd, where Fs - is a source factor, and Fd is a destination factor.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:09
I have an idea!
Dzmitry Malyshau
@kvark
Jul 08 2014 03:09
All factors except one are paired: there is 1-X for each X
kvark @kvark is listening, but no one speaks
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:11
just a sec
making a gist
sorry!
sorry for giving you the run-around on this
Dzmitry Malyshau
@kvark
Jul 08 2014 03:11
np, take your time
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:12
perhaps we merge, then I we can re-'factor'
:P
Dzmitry Malyshau
@kvark
Jul 08 2014 03:12
lol
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:17
pub enum BlendValue {
    BlendZero,
    BlendOne,
    BlendSourceColor(InverseFlag),
    BlendSourceAlpha(InverseFlag),
    BlendSourceAlphaSaturated(InverseFlag),
    BlendDestColor(InverseFlag),
    BlendDestAlpha(InverseFlag),
    BlendConstColor(InverseFlag),
    BlendConstAlpha(InverseFlag),
}
?
@cmr @kvark ^
Dzmitry Malyshau
@kvark
Jul 08 2014 03:18
@bjz sorry, that's doesn't seem to be a much better solution to me
Zero and One are not exceptions, because One = Inverse(Zero)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:19
ah
Dzmitry Malyshau
@kvark
Jul 08 2014 03:19
so you could have BlendZero(InverseFlag), and then you are left with only 1 exception, while everything else is just repeating the InverseFlag...
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:20
interesting
Dzmitry Malyshau
@kvark
Jul 08 2014 03:20
@cmr good catch, I fixed the commit message now
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:20
what do other APIs do?
Corey Richardson
@cmr
Jul 08 2014 03:21
Same thing GL does really.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:21
yay, merged at last!
Dzmitry Malyshau
@kvark
Jul 08 2014 03:21
everything just uses plain enumerations for all cases (without any inverse flag)
yay!
Interesting! they don't have saturated alpha there, which means we can safely ignore that. Without saturated alpha there are no exceptions for the inverse flag
@bjz see Alpha Blending section at your link. It's rather small though
Corey Richardson
@cmr
Jul 08 2014 03:25
Hm
I can't really figure out how to operate this documentation
It's the same as OpenGL though
Dzmitry Malyshau
@kvark
Jul 08 2014 03:26
@cmr agreed, total mess
Oh, my bad. Everyone has saturated alpha...
Corey Richardson
@cmr
Jul 08 2014 03:33
I made sure every operation is supported by D3D
I hope to have a D3D device/renderer next week or so
depends on how much pain COM is to wrap, but I don't expect too much...
Wine thankfully does a lot of the hard work.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:34
Awesome!
Dzmitry Malyshau
@kvark
Jul 08 2014 03:36
@cmr that would be huge! don't forget to create an issue for that and update it, for our pleasure to read ;)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:37
@kvark he already has one I think?
lol:
ERROR:device::gl:     array buffer creation unsupported, ignored
ERROR:device::gl::shade: Uniform blocks are not supported, ignored
ERROR:device::gl: Ignored unsupported GL Request: CastBindArrayBuffer(0)
task '<main>' failed at 'assertion failed: `(left == right) && (right == left)` (left: `1282`, right: `0`)', src/device/gl/mod.rs:91
task '<unnamed>' failed at 'receiving on a closed channel', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libsync/comm/mod.rs:827
brendanzab @bjz should have checked the capabilities patch
Dzmitry Malyshau
@kvark
Jul 08 2014 03:38
@bjz well you had a chance... It is sad though, since it's working fine for me
Corey Richardson
@cmr
Jul 08 2014 03:39
It also works for me.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:39
yeah I did, my own fault
Corey Richardson
@cmr
Jul 08 2014 03:39
how can you not support VAO though O_o
Dzmitry Malyshau
@kvark
Jul 08 2014 03:39
@cmr has #56 which is by far not the D3D back-end. It needs a new issue.
Corey Richardson
@cmr
Jul 08 2014 03:39
linux or os x?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:39
I will see if I can get to the bottom of it
osx
Dzmitry Malyshau
@kvark
Jul 08 2014 03:39
@bjz share your apitrace
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:39
it might be making an incorrect context
how do I do that?
oh we don't specify the context version now?
Dzmitry Malyshau
@kvark
Jul 08 2014 03:40
@bjz https://github.com/apitrace/apitrace, unless you have it somewhere
Corey Richardson
@cmr
Jul 08 2014 03:41
@bjz oh did changing it to version 2.0 break it?
Dzmitry Malyshau
@kvark
Jul 08 2014 03:41
the triangle sets 2.1
Corey Richardson
@cmr
Jul 08 2014 03:41
or 2.1
whatever
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:41
osx is very picky
Corey Richardson
@cmr
Jul 08 2014 03:41
I think OS X only does 3.x core profile right?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:41
I will figure it out
Corey Richardson
@cmr
Jul 08 2014 03:41
maybe 4.1 now..
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:42
I could do a cfg for osx
Dzmitry Malyshau
@kvark
Jul 08 2014 03:42
I'm off for today, will assist you tomorrow if the problem doesn't solve itself by then ;)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:42
    /// This is used to set the window hints for the next call to
    /// `Glfw::create_window`. The hints can be reset to their default values
    /// using calling the `Glfw::default_window_hints` function.
    ///
    /// Wrapper for `glfwWindowHint`
    ///
    /// # OpenGL 3.x and 4.x on Mac OS X
    ///
    /// The only OpenGL 3.x and 4.x contexts supported by OS X are
    /// forward-compatible, core profile contexts.
    ///
    /// 10.7 and 10.8 support the following OpenGL versions:
    ///
    /// - `glfw::ContextVersion(3, 2)`
    ///
    /// 10.9 supports the following OpenGL versions
    ///
    /// - `glfw::ContextVersion(3, 2)`
    /// - `glfw::ContextVersion(3, 3)`
    /// - `glfw::ContextVersion(4, 1)`
    ///
    /// To create an OS X compatible context, the hints should be specified as
    /// follows:
    ///
    /// ~~~rust
    /// glfw.window_hint(glfw::ContextVersion(3, 2));
    /// glfw.window_hint(glfw::OpenglForwardCompat(true));
    /// glfw.window_hint(glfw::OpenglProfile(glfw::OpenGlCoreProfile));
    ///
~~~
Corey Richardson
@cmr
Jul 08 2014 03:42
Annoyyyying.
We should add an autodetect helper.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:45
my context is apparently 2.1 though
when I do window.get_context_version()
:{
Corey Richardson
@cmr
Jul 08 2014 03:48
well 2.1 doesn't support VAOs
it's correct in that regard.
however usually drivers support the extension even on older contexts
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:48
Then how does yours work?
Corey Richardson
@cmr
Jul 08 2014 03:48
I guess OS X is weird with that
it queries for the extension
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:49
I think osx doesn't load the extension if it is in the wrong context
Corey Richardson
@cmr
Jul 08 2014 03:49
something like that, makes sense.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:51
do we allow cfgs on block exprs?
Corey Richardson
@cmr
Jul 08 2014 03:51
nope
Brendan Zabarauskas
@brendanzab
Jul 08 2014 03:52
:(
WOW
seg-fault
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:02
This message was deleted
Corey Richardson
@cmr
Jul 08 2014 04:03
hey I was reading that
lol
so much for making it smaller!
Corey Richardson
@cmr
Jul 08 2014 04:03
:P
I wonder if its returning a bad string for the extension list
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:05
hmm
how would I figure it out?
Corey Richardson
@cmr
Jul 08 2014 04:06
println-debugging?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:11
So it is happening in Esxtensions::new
str::raw::c_str_to_static_slice I think
Corey Richardson
@cmr
Jul 08 2014 04:12
the backtrace agrees with you :P
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:13
indeed it does
:P
well bytes is 0x0
:P
@csherratt what platform are you on?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:21
@cmr lol invalid enum for gl::GestString(gl::EXTENSIONS)
Corey Richardson
@cmr
Jul 08 2014 04:22
ugh
Ohhhhhh how is that working anywhere
isn't that only available with glGetStringi?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:23
GLEW has a problem with core contexts. It calls glGetString(GL_EXTENSIONS)​, which causes GL_INVALID_ENUM​ on GL 3.2+ core context as soon as glewInit()​ is called. It also doesn't fetch the function pointers. The solution is for GLEW to use glGetStringi​ instead
Corey Richardson
@cmr
Jul 08 2014 04:23
You're supposed to use glGetIntegerv(GL_NUM_EXTENSIONS, outptr) and then iterate afaik
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:23
ahh
I will fix it then
I think it might be because OS X forces you to do forward compat
Corey Richardson
@cmr
Jul 08 2014 04:24
sounds plausible.
annoying though :(
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:24
if you set up a forward compat profile on the triangle example, does it break?
Corey Richardson
@cmr
Jul 08 2014 04:26
yup it does.
we should test with that flag then
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:28
ok, I am fixing the thingy
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:40
lol, I am not seg-faulting anymore
now I am still not getting array buffers
Corey Richardson
@cmr
Jul 08 2014 04:41
with 3.2 core profile?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:41
my extensions are:
GL_ARB_blend_func_extended
GL_ARB_draw_buffers_blend
GL_ARB_draw_indirect
GL_ARB_ES2_compatibility
GL_ARB_explicit_attrib_location
GL_ARB_gpu_shader_fp64
GL_ARB_gpu_shader5
GL_ARB_instanced_arrays
GL_ARB_internalformat_query
GL_ARB_occlusion_query2
GL_ARB_sample_shading
GL_ARB_sampler_objects
GL_ARB_separate_shader_objects
GL_ARB_shader_bit_encoding
GL_ARB_shader_subroutine
GL_ARB_shading_language_include
GL_ARB_tessellation_shader
GL_ARB_texture_buffer_object_rgb32
GL_ARB_texture_cube_map_array
GL_ARB_texture_gather
GL_ARB_texture_query_lod
GL_ARB_texture_rgb10_a2ui
GL_ARB_texture_storage
GL_ARB_texture_swizzle
GL_ARB_timer_query
GL_ARB_transform_feedback2
GL_ARB_transform_feedback3
GL_ARB_vertex_attrib_64bit
GL_ARB_vertex_type_2_10_10_10_rev
GL_ARB_viewport_array
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_depth_bounds_test
GL_EXT_framebuffer_multisample_blit_scaled
GL_EXT_texture_compression_s3tc
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_mirror_clamp
GL_EXT_texture_sRGB_decode
GL_APPLE_client_storage
GL_APPLE_container_object_shareable
GL_APPLE_flush_render
GL_APPLE_object_purgeable
GL_APPLE_rgb_422
GL_APPLE_row_bytes
GL_APPLE_texture_range
GL_ATI_texture_mirror_once
GL_NV_texture_barrier
4.1 :P
Corey Richardson
@cmr
Jul 08 2014 04:41
ah
even better
also wow that's a short list of extensions
they really do take "core profile" seriously.
hm
that's problematic actually.
I assumed we would always be able to query extensions for supported features.
But if OS X is only doing some extensions, and relying on the version for everything else...
brendanzab @bjz has no excuse for not testing @Kimundi's patch
Brendan Zabarauskas
@brendanzab
Jul 08 2014 04:44
:P
Corey Richardson
@cmr
Jul 08 2014 04:44
Yuck this is super annoying.
We could maintain a list of extensions that correspond to each version
Corey Richardson
@cmr
Jul 08 2014 05:02

GL_SGIS_texture_lod was not found, but is available in driver version 2.1 INTEL-8.26.34 


what is that
"but is available"
tying into whatever it is using would be good
Marvin Löbel
@Kimundi
Jul 08 2014 08:22
Good morning!
Corey Richardson
@cmr
Jul 08 2014 08:24
Morn
Have you ever used trello?
Marvin Löbel
@Kimundi
Jul 08 2014 08:25
No
Corey Richardson
@cmr
Jul 08 2014 08:25
It looks like it might be useful.
Marvin Löbel
@Kimundi
Jul 08 2014 08:27
Ugh, reading the backscroll... I could've explained all the weirdness bjz had with my patch directly. Damn timezones...
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:28
@Kimundi I should head to bed...
Corey Richardson
@cmr
Jul 08 2014 08:28
hahah
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:28
#84 - added some more stuff
I still haven't got it to work on OSX though
Corey Richardson
@cmr
Jul 08 2014 08:29
I hate not having access to OSX
it's like they don't /want/ you to develop for their platform unless you are in their little bubble
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:30
heh
Corey Richardson
@cmr
Jul 08 2014 08:33
@bjz have you used trello?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:33
I have
Corey Richardson
@cmr
Jul 08 2014 08:33
is it useful?
could it be useful for gfx-rs?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:34
like any other task management thingy - your milage may vary - I tried it for voyager, but didn't stick to it
brendanzab @bjz has tried bazillions of task management apps in the past... including pen and paper... none stuck... now he stumbles around in a daze of muddled confusion
Kimundi @Kimundi wonders how to fix that GL_EXTENSIONS thing...
Corey Richardson
@cmr
Jul 08 2014 08:39
@Kimundi it's very weird to me that OSX doesn't expose every extension the driver implements, even if the extension is core.
@bjz I see what you mean about make updating the submodules now, lol.
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:40
? what's that?
Corey Richardson
@cmr
Jul 08 2014 08:40
in gl-rs if you're trying to test the changes to the submodule updates before you commit
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:40
ah
hehe
Corey Richardson
@cmr
Jul 08 2014 08:41
but it just checks out the submodule.... overwriting it
pretty confusing
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:41
:)
cmr @cmr should also sleep
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:41
didn't I change that?
Corey Richardson
@cmr
Jul 08 2014 08:41
I changed it back didn't I?
because too many people were confused about why it wouldn't build
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:42
ahh
yay git submodules how we love you
Corey Richardson
@cmr
Jul 08 2014 08:43
Also deprecation warnings are SO nice
I severely underestimated how nice they are
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:57
indeed
Marvin Löbel
@Kimundi
Jul 08 2014 08:59
Getting the infamous 1280 != 0 error message with @bjz's versioning patch :P
Brendan Zabarauskas
@brendanzab
Jul 08 2014 08:59
ahh, invalid_enum
maybe it doesn't like the gl::GetStringi for your version?
Marvin Löbel
@Kimundi
Jul 08 2014 09:01
Wouldn't suprise me, cause thats the reason I went with the regular glGetString ;)
Marvin Löbel
@Kimundi
Jul 08 2014 09:07
Haha
My system supports gl::GetStringi
Corey Richardson
@cmr
Jul 08 2014 09:08
Eugh yeah actually.
Marvin Löbel
@Kimundi
Jul 08 2014 09:08
But not get_uint(gl::NUM_EXTENSIONS)
Corey Richardson
@cmr
Jul 08 2014 09:08
The GL_NUM_EXTENSIONS stuff is all 3.2+ core profile
fuck. that.
Marvin Löbel
@Kimundi
Jul 08 2014 09:08
Yeah it is :P
Corey Richardson
@cmr
Jul 08 2014 09:08
WHY do they not have a portable way to query capabilities :(
Marvin Löbel
@Kimundi
Jul 08 2014 09:11
Okay, how about this: Provide a helper like best_context_between(GL21, GL32CORE) that sets the best supported context, and then have detection of the running context to choose between GetString and GetStringi
Corey Richardson
@cmr
Jul 08 2014 09:11
Seems like something that belongs in glfw-rs unfortunately....
What I'm thinking now is a few layers of checking.
Every capability we care about is in some version of OGL.
So we first check if we have at least that version.
No? Check the version to figure out how to query extensions.
Then query for the supported extension
Marvin Löbel
@Kimundi
Jul 08 2014 09:12
Well, gfx already has GlfwPlatform. Couldn't we simply make "context creation" one of its responsibilities?
Corey Richardson
@cmr
Jul 08 2014 09:12
If this fails, then you don't support the capability.
We could, yeah. There's no real way to determine the highest version profile though
Marvin Löbel
@Kimundi
Jul 08 2014 09:13
Oh, there isn't?... Ugh
Okay, in that case, do hat you just proposed :P
Corey Richardson
@cmr
Jul 08 2014 09:15
Yeah it's a super pain.
"While there is no way to ask the driver for a context of the highest supported version, most drivers provide this when you ask GLFW for a version 1.0 context."
Kimundi @Kimundi silently hopes his laptop dies, and he has to get a new one with better graphics
Marvin Löbel
@Kimundi
Jul 08 2014 09:17
most. Yeah...
Corey Richardson
@cmr
Jul 08 2014 09:19
suchhhh a pain
I think we can work around it though.
We do need to add some way to request a "Good GL Context" though
Leaving it up to the application isn't very polite
Marvin Löbel
@Kimundi
Jul 08 2014 09:23
Why not? If we can handle any possible context version greater than 2.1...
Corey Richardson
@cmr
Jul 08 2014 09:24
OS X doesn't support 2.1 with extensions, you need to use a 3.2+ core profile to get any features
(and actually on linux we can support 2.0 :headphones: )
Marvin Löbel
@Kimundi
Jul 08 2014 09:26
Ah right, OS X ...
Minimum context version per platform maybe?
Corey Richardson
@cmr
Jul 08 2014 09:28
that might work
Marvin Löbel
@Kimundi
Jul 08 2014 10:51
Hm, I see glfw provides a extension_supported function
That might be smart enough to handle the extension querying at least
But it means we have to thread Platform into Device somehow...
Marvin Löbel
@Kimundi
Jul 08 2014 11:45
Hm, one possible way to detect the supported opengl context is just to try to create it, and then successively try lower versions
Doesn't seem that bad an approach, considering its only being done once at startup
Dzmitry Malyshau
@kvark
Jul 08 2014 12:55
Wait, why can't we switch glGetString/glGetStringi behavior based on the GL_VERSION that we receive? That doesn't require any GLFW involvement.
Marvin Löbel
@Kimundi
Jul 08 2014 12:55
That works too
Dzmitry Malyshau
@kvark
Jul 08 2014 12:56
I assume OSX will return 3.2 for GL_VERSION, even when we ask for 2.1.
Marvin Löbel
@Kimundi
Jul 08 2014 12:57
My thinking right now is: Just try 3.2, and if context creation fails try 2.1
Dzmitry Malyshau
@kvark
Jul 08 2014 12:57
Aside from that, we can augment VAO checks to complain only if we don't know what to do. I.e. with a typical scenario of creating a single VAO, binding it, and using all through the way, the device doesn't need to complain that it doesn't support it, because it doesn't need to support it.
@Kimundi but that would require more complex logic on the example code side, wouldn't it?
Marvin Löbel
@Kimundi
Jul 08 2014 12:58
Sure, lazy extension usage would also be good :)
Well, I'm trying to keep it simple
Dzmitry Malyshau
@kvark
Jul 08 2014 12:58
I'm not talking about lazy extension, but rather a smart minimal-effort emulation of VAO
Marvin Löbel
@Kimundi
Jul 08 2014 12:59
Ideally it just ends up as a helper function for GlfwPlatform
Dzmitry Malyshau
@kvark
Jul 08 2014 12:59
@Kimundi oh true, that would work too
Marvin Löbel
@Kimundi
Jul 08 2014 13:00
kvark: Ah, even smarter than just lazy detection. Sounds good :)
Right now I'm toying around with making this work:
Dzmitry Malyshau
@kvark
Jul 08 2014 13:01
oh, glfw has a fallback? neat!
Marvin Löbel
@Kimundi
Jul 08 2014 13:01
It hasn't :P
Dzmitry Malyshau
@kvark
Jul 08 2014 13:01
you are adding it then? double neat!
Marvin Löbel
@Kimundi
Jul 08 2014 13:02
Thats what I'm working on. (Its a extension trait, but it doesn't have to be)
Its really simple though
It runs the first callback, runs create_Window(), and if that failed it tries the second one
Dzmitry Malyshau
@kvark
Jul 08 2014 13:03
Sounds good
Marvin Löbel
@Kimundi
Jul 08 2014 13:03
But hey, thats what error result values are for. ;)
Anyway, that code blob can just end up as a GlfwPlatform::init_recommended_context() helper or so, with some form of this builder API exposed for people that needs more control
Dzmitry Malyshau
@kvark
Jul 08 2014 13:05
Or init_default_context, either way the idea is great
Marvin Löbel
@Kimundi
Jul 08 2014 13:06
yup
Dzmitry Malyshau
@kvark
Jul 08 2014 13:18
@cmr I'm kinda tempted to do clustered lighting with CPU filling the 3D cluster texture. (Not my idea, but I like it). GPUs are not good at rendering into 3D textures anyway, and using CPU for that is not difficult, assuming the density is not too high. This would be compatible with GL-2.1 easily, and we can sacrifice lighting latency for performance by using the last-frames cluster texture.
@csherratt Does that sound reasonable? ^
Dzmitry Malyshau
@kvark
Jul 08 2014 13:24
Actually, It's still unclear how to store lists of lights... Eh, nevermind then, the idea needs more thought on it.
Dzmitry Malyshau
@kvark
Jul 08 2014 13:32
Could be solved with double-indirection: we have one buffer with light information, one buffer with linear light indices, and the clustered 3D texture contains just an offset (and possibly count, encoded into the same uint32) into the light indices buffer. So the fragment shader extracts the light buffer "slice", then iterates the light indices buffer, and of each index iterates the light buffer. It may sound like a lot of indirection but really we are reading the same memory, so it's cache-friendly.
Dzmitry Malyshau
@kvark
Jul 08 2014 14:13
Created a gist to not overflow this thread with ideas ;)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 14:28

Wait, why can't we switch glGetString/glGetStringi behavior based on the GL_VERSION that we receive? That doesn't require any GLFW involvement.

Yeah that was my plan

Also, note that you can check if individual symbols are loaded with gl-rs, and reload them at will.
Dzmitry Malyshau
@kvark
Jul 08 2014 14:32
ok, good. You are still unable to run @bjz?
Marvin Löbel
@Kimundi
Jul 08 2014 14:48
%"struct.MyWrap<[]>" = type { %"struct.glfw::Glfw<[]>[#15]" }LLVM ERROR: Broken function found, compilation aborted!
yay ._.
Dzmitry Malyshau
@kvark
Jul 08 2014 14:49
ouch, you collapsed the universe
Dzmitry Malyshau
@kvark
Jul 08 2014 15:11
@bjz can we remove everything but gfx-rs from the web hook? I imagine we'd need to update Travis script with that too (which refers to the hook)
Marvin Löbel
@Kimundi
Jul 08 2014 15:12
Hm, what would be the best place to hook a glfw-specific function into the GlfwPlatform? Can't make it a static function of the GlfwGraphicsContext because it doesn't use the type paramter...
Dzmitry Malyshau
@kvark
Jul 08 2014 15:14
@Kimundi why "not using the type parameter" stopping you from adding the function?
Marvin Löbel
@Kimundi
Jul 08 2014 15:15
kvark: GlfwPlatform::create_window(...) => "error: unconstrained type parameter"
Dzmitry Malyshau
@kvark
Jul 08 2014 15:16
but don't you know the type of C at the point of invocation?
Marvin Löbel
@Kimundi
Jul 08 2014 15:16
yes, because the function has nothing todo with the GlfwGraphicsContext struct :)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:18
@kvark done
Marvin Löbel
@Kimundi
Jul 08 2014 15:18
Gonna change it to a free function and a public glfw module for now...
Dzmitry Malyshau
@kvark
Jul 08 2014 15:18
@bjz does it work for you now?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:18
@Kimundi could you post a gist?
@kvark yep
@kvark I posted a test message on #84
Dzmitry Malyshau
@kvark
Jul 08 2014 15:20
why do Rust guidelines allow matching cases to be squashed into a single line?.. seems inconsistent
kvark @kvark assumes @bjz always follows these darn guidelines
brendanzab @bjz has no idea
brendanzab @bjz waits for rustfmt
Dzmitry Malyshau
@kvark
Jul 08 2014 15:22
oh wait, #84 always uses getStringi? where is the branch for GL2?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:22
@kvark making one now
Dzmitry Malyshau
@kvark
Jul 08 2014 15:23
I like how well you treated Version type. Perhaps, we can add typedefs for Major, Minor, Revision into there?
Marvin Löbel
@Kimundi
Jul 08 2014 15:24
@kvark @bjz: Kimundi/gfx-rs@d9a1b1b
How does this look for a initial design?
Its an API to provide different GLFW initialization fallbacks
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:25
woah, what is with all those lifetimes!
Marvin Löbel
@Kimundi
Jul 08 2014 15:25
Well, thats what happens if you move inference into struct fields :P
Dzmitry Malyshau
@kvark
Jul 08 2014 15:27
@bjz it's also becoming a bit weird to scan the shading language version twice - once for Info and once for cross-platform shader model in Capabilities
Marvin Löbel
@Kimundi
Jul 08 2014 15:28
Anyway, that + dynamic selection between glGetString/glGetStringiShould make the example and gfx compile and run under both OSX and my laptop :P
Should I make a PR?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:34
what would you like me to do?
do a selection just doing checking for 3.2 and below?
I am going to implement a lexical sort for versions
Dzmitry Malyshau
@kvark
Jul 08 2014 15:37
@bjz either do a match similar to shade::get_model (and replace it) or leave it as is until better times
Marvin Löbel
@Kimundi
Jul 08 2014 15:39
Just to confirm, am I allowed to review an merge things? :)
Dzmitry Malyshau
@kvark
Jul 08 2014 15:40
@Kimundi well you do have push access :smile:
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:40
@Kimundi if it is a majorish change, make sure there is consensus, if it is a minor bug fix, got ahead
just use discretion
I trust you
Marvin Löbel
@Kimundi
Jul 08 2014 15:41
Alright
Dzmitry Malyshau
@kvark
Jul 08 2014 15:41
discretion is a bit subjective... numerous times was I tempted to hit that big fat green button :hand:
so far I got us into no disaster, so perhaps my discretion kinda works ok
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:42
haha
brendanzab @bjz gets us in hot water all the time
Dzmitry Malyshau
@kvark
Jul 08 2014 15:42
hah, especially with those batched issue closing
Brendan Zabarauskas
@brendanzab
Jul 08 2014 15:44
haha
Brendan Zabarauskas
@brendanzab
Jul 08 2014 16:08
ok, I almost have the glsl version checking done
but I need to get to work
sorry :(
Brendan Zabarauskas
@brendanzab
Jul 08 2014 16:15
@Kimundi does #84 work for you now?
Ok, to work!
It still doesn't fix the triangle example though
Marvin Löbel
@Kimundi
Jul 08 2014 16:18
trying...
@bjz: Works
including triangle example
Brendan Zabarauskas
@brendanzab
Jul 08 2014 16:19
\o/
@kvark #84?
Marvin Löbel
@Kimundi
Jul 08 2014 16:23
@bjz with #87, the config flag for the triangle flag become unnecessary again, and we could also let it try versions higher than 3.2 first if neccessary
Err, the config flags for the triangle example
Kimundi @Kimundi should start commenting his PRs
Dzmitry Malyshau
@kvark
Jul 08 2014 16:58
@bjz I assume you don't have time for the Capabilities::shader_model?
brb
Dzmitry Malyshau
@kvark
Jul 08 2014 17:17
@bjz so you are ready to merge? I can't test it now, but I don't mind fixing it later on if anything is broken ;)
Brendan Zabarauskas
@brendanzab
Jul 08 2014 17:18
ready to merge
I can fix the shader stuff later
Dzmitry Malyshau
@kvark
Jul 08 2014 17:18
sure
Corey Richardson
@cmr
Jul 08 2014 18:11
Brendan Zabarauskas
@brendanzab
Jul 08 2014 18:11
aye
pretty awesome
Marvin Löbel
@Kimundi
Jul 08 2014 18:29
@kvark: If I make the first fallback special, I also need a new name for the lifetimes, arguments and fields, because now now all of them are fallbacks. What do you think would be a good name?
setup?
Dzmitry Malyshau
@kvark
Jul 08 2014 18:31
yeah, setup would be nice
Marvin Löbel
@Kimundi
Jul 08 2014 18:36
@kvark: Comments addressed
hm
Dzmitry Malyshau
@kvark
Jul 08 2014 18:44
@Kimundi sweet!
@bjz have you had a look?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 18:44
sorry - working right now
Dzmitry Malyshau
@kvark
Jul 08 2014 19:01
@bjz kuudos for review skills!
Marvin Löbel
@Kimundi
Jul 08 2014 19:13
Hm, the gitter activity bar is tricky. It shows pr comments, but not line comments :P
Brendan Zabarauskas
@brendanzab
Jul 08 2014 20:14
@kvark sorry :(
Dzmitry Malyshau
@kvark
Jul 08 2014 20:16
@bjz ?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 20:17
@kvark you were being sarcastic right?
Dzmitry Malyshau
@kvark
Jul 08 2014 20:17
just trying to figure out why you are sorry
I wasn't sarcastic, no
Marvin Löbel
@Kimundi
Jul 08 2014 20:55
@bjz: Any idea about my last comment on #87?
Brendan Zabarauskas
@brendanzab
Jul 08 2014 22:39
@Kimundi I'll look at it later - sorry