More int type fixes and tests for drivers #80

errordeveloper · 2014-07-02T12:40:12Z

Just pulled in nightly and got a whole bunch of errors like this:

error: cannot determine a type for this expression: cannot determine the type of this integer; add a suffix to specify the type explicitly

Not sure, may be this just a follow-up on rust-lang/rust#6023?

farcaller · 2014-07-02T12:44:55Z

Not sure how that is "making the language more simple", but whatever. Just one comment above

farcaller · 2014-07-02T12:46:02Z

src/drivers/lcd/c12332.rs

@@ -121,7 +121,7 @@ impl<'a, S: SPI, T: Timer, P: GPIO> C12332<'a, S, T, P> {
    let index = x + (y/8) * 128;
    if color == 0 {
      self.videobuf[index as uint].set(
-        self.videobuf[index as uint].get() & !(1 << (y%8) as uint) as u8);
+        self.videobuf[index as uint].get() & !(1i32 << (y%8i32) as uint) as u8);


Why is this signed int? it's getting downcasted to u8, so using u8 should be fine.

You are right!

Ok, that gives me another error:

/Users/ilya/Code/Work/rust/zinc/src/drivers/lcd/c12332.rs:124:58: 124:61 error: mismatched types: expected `i32` but found `i8` (expected i32 but found i8) /Users/ilya/Code/Work/rust/zinc/src/drivers/lcd/c12332.rs:124 self.videobuf[index as uint].get() & !(1i8 << (y%8i8) as uint) as u8);

Ah. so, y being i32 is kind of a bug, as you cannot really address any pixel < 0. If you have some time to work on this, can you please update function definition to read pub fn set_pixel(&self, x: u32, y: u32, color: u16) ? Then the addressing should be something along the lines of (1u8 << (y % 8u32) as uint) as u8

yes, that's what I was thinking, but wasn't sure...

And is this a bug as well?

src/drivers/lcd/mod.rs: fn pixel(&self, x: i32, y: i32, color: u16);

Yes, that one as well.

Ok, will fix it.

errordeveloper · 2014-07-02T12:46:45Z

I won't be surprised it will go away. May be we need refactor those kind of expressions somehow?

farcaller · 2014-07-02T12:47:50Z

Most of that is bits manipulation. It would be nice to have some macro to do that in a better (and more safe way).

errordeveloper · 2014-07-02T14:04:33Z

It certainly needs some nice macros.

errordeveloper · 2014-07-02T17:29:18Z

Looks a little cleaner now 😄

farcaller · 2014-07-02T17:32:06Z

A bit mode cleaning please: https://travis-ci.org/errordeveloper/zinc/jobs/28985715#L103

errordeveloper · 2014-07-02T17:41:10Z

Yeah... The warning, wasn't quite sure what's the fix...
On 2 Jul 2014 18:32, "Vladimir Pouzanov" [email protected] wrote:

A bit mode cleaning please:
https://travis-ci.org/errordeveloper/zinc/jobs/28985715#L103

Reply to this email directly or view it on GitHub
#80 (comment).

farcaller · 2014-07-02T18:04:05Z

In c12332 — it's safe to remove the check for < 0.

In lcd/mod.rs — you actually broke the algorithm, all the variables other than x0/y0 can be less than zero.

errordeveloper · 2014-07-02T19:23:27Z

So 35440a6 fixes C12332. And for the broken algorithm I'm thinking of fixing it with if di < 0i as u32, which seem about right to me.

farcaller · 2014-07-02T19:31:48Z

No, di must be i32, as di = dy_x2 - dx might be less than zero.

errordeveloper · 2014-07-02T20:15:55Z

Well, if they are unsigned, they will never be less then zero, it will
simply overflow, isn't it?
On 2 Jul 2014 20:31, "Vladimir Pouzanov" [email protected] wrote:

No, di must be i32, as di = dy_x2 - dx might be less than zero.

Reply to this email directly or view it on GitHub
#80 (comment).

errordeveloper · 2014-07-02T20:42:03Z

So in terms of geometry, what does the zero represent here? Is it more like
the centre of a line (-∞:0:+∞) or beginning of a line [0:+∞)?

errordeveloper · 2014-07-02T20:43:27Z

@farcaller I'm thinking that we should have test for this, generate a bitmap and compare it to a static bitmap, what do you think?

farcaller · 2014-07-02T20:57:57Z

Ok. I can run the test on actual hw this weekend, but you can go on and make an unit test.

errordeveloper · 2014-07-02T23:37:20Z

Yeah, I'd love to! Might need a little help, if you don't mind... Will ping
you tomorrow ;)
On 2 Jul 2014 21:57, "Vladimir Pouzanov" [email protected] wrote:

Ok. I can run the test on actual hw this weekend, but you can go on and
make an unit test.

Reply to this email directly or view it on GitHub
#80 (comment).

errordeveloper · 2014-07-04T10:48:11Z

Will re-open when unit tests are done.

errordeveloper · 2014-07-06T17:34:36Z

@farcaller this is on top of #89.

farcaller · 2014-07-06T17:37:03Z

Rakefile

+  source:  'main.rs'.in_source,
+  deps:    [:core_crate],
+  produce: 'zinc_test'.in_build,
+  recompile_on: [:triple, :platform, :features],


Do not recompile on :triple, host triple isn't going to change.

farcaller · 2014-07-06T17:43:09Z

src/drivers/lcd/mod.rs

+  fn should_fill_and_clear() {
+    let io = TestLCD::new();
+    io.set_fill(128);
+    io.for_each(|_, x| {


io.for_each(|_, x| assert!(x == 128));

ok, so generally make things like this to one line unless it's too long?

the syntax is actually nicer then Ruby!

Right. you don't need curly braces if the statement is simple, if it spans a few lines you still add them for readability (although it's syntactically correct to drop them).

farcaller · 2014-07-06T17:47:06Z

I think you can do with a much smaller buffer, like 5x5 pixels, this way you can make a helper test case macro that makes a call and verifies it by the "picture". Bonus points if you define the template with something like

let match = "
.....
.XXXX
.X..X
.XXXX
....."

errordeveloper · 2014-07-06T19:11:37Z

@farcaller regarding the buffer, I though might as well print a letter using putc, so 16x16 seemed like good enough...

errordeveloper · 2014-07-07T07:05:41Z

Travis might have hit a rustc bug, but I'd rather rebase this on #92 first. I'm also thinking to squash this down to a couple of commits. From 15 to 3 or 5, perhaps...

errordeveloper · 2014-07-07T10:06:31Z

Does anyone else want to review this or we can merge?

farcaller · 2014-07-07T10:08:12Z

Please remove this test: test dummy_test ... ok

errordeveloper · 2014-07-07T10:16:04Z

Removed. Should I squash or it's okay?

farcaller · 2014-07-07T10:21:20Z

src/drivers/lcd/mod.rs

+
+    io.line(0, 0, 15, 15, 1);
+
+    // TODO: investigate why this hangs the test run in `__psynch_cvwait()`


Please 'own' the todo: // TODO(errordeveloper): ...

farcaller · 2014-07-07T10:21:48Z

Yes, you can squash it a bit (reasonably).

- pixel coordinates are always unsigned - use `for ... in range(...)` instead of `while ...`

bharrisau · 2014-07-07T13:12:03Z

src/drivers/lcd/mod.rs

+  fn line(&self, x0_b: u32, y0_b: u32, x1: u32, y1: u32, color: u16) {
+    let mut x0: u32 = x0_b;
+    let mut y0: u32 = y0_b;
+    let mut dx: u32;


Do these dx want to be i32?

dx, dy, dx_sym and dy_sym at the minimum should be signed. This should fix your hanging test.

And it might be nicer if you get rid of the 'mut' and just rebind with another let statement. di, x0 and y0 should be mut.

Yes, those must me signed, as dx = x1-x0 may be less than zero as we discussed above. @errordeveloper, please fix and re-enable the 15,15 -> 0,0 test, it should work.

@bharrisau, thanks for catching that.

bharrisau · 2014-07-07T13:28:33Z

Tests looks great. Thanks for this.

- fix hanging test by fixing signed/unsigned types - get rid of C copypastaz and not needed mut vars - more refactoring of while loops

bharrisau · 2014-07-08T09:51:38Z

We don't get any notifications when you update things - so you need to post here if you are ready for review.

farcaller · 2014-07-08T09:57:17Z

Well, I do have notifications for stale "ready for review" PRs, but the script is broken :)

bharrisau · 2014-07-08T10:06:52Z

A simple r? should be fine. I don't think non-contributors can update
labels on issues.

farcaller · 2014-07-08T10:08:53Z

oh well. yes, then a simple 'r?' is fine, somehow I missed the permissions bit.

errordeveloper · 2014-07-08T15:11:37Z

So is this good to merge now?

farcaller · 2014-07-08T15:36:46Z

Yup, thanks for your work.

More int type fixes and tests for drivers Reviewed-by: farcaller

farcaller reviewed Jul 2, 2014
View reviewed changes

farcaller mentioned this pull request Jul 3, 2014

Basic support for the STM32F429I-DISCO board #81

Closed

errordeveloper closed this Jul 4, 2014

errordeveloper mentioned this pull request Jul 4, 2014

Add type suffixes to integer literals explicitly #84

Merged

errordeveloper reopened this Jul 6, 2014

farcaller changed the title ~~More int type fixes~~ More int type fixes and tests for drivers Jul 6, 2014

farcaller reviewed Jul 6, 2014
View reviewed changes

errordeveloper mentioned this pull request Jul 7, 2014

Add test to CharIO #89

Closed

farcaller reviewed Jul 7, 2014
View reviewed changes

errordeveloper added 5 commits July 7, 2014 12:36

Refactor LCD mod -

8b9abd7

- pixel coordinates are always unsigned - use `for ... in range(...)` instead of `while ...`

Enable zinc tests

3123d2b

Remove dummy test

0e650af

Add tests to CharIO

b015160

Add tests to LCD

01181d9

bharrisau reviewed Jul 7, 2014
View reviewed changes

Refactor LCD even further -

3b083b9

- fix hanging test by fixing signed/unsigned types - get rid of C copypastaz and not needed mut vars - more refactoring of while loops

farcaller added cleanup labels Jul 8, 2014

hacknbot added a commit that referenced this pull request Jul 8, 2014

Merge pull request #80 from errordeveloper/more_int_fixes

c008f64

More int type fixes and tests for drivers Reviewed-by: farcaller

hacknbot merged commit 3b083b9 into hackndev:master Jul 8, 2014

errordeveloper deleted the more_int_fixes branch July 8, 2014 16:49


		io.line(0, 0, 15, 15, 1);

		// TODO: investigate why this hangs the test run in `__psynch_cvwait()`

More int type fixes and tests for drivers #80

More int type fixes and tests for drivers #80

Conversation

errordeveloper commented Jul 2, 2014

farcaller commented Jul 2, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

errordeveloper commented Jul 2, 2014

farcaller commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

farcaller commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

farcaller commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

farcaller commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

farcaller commented Jul 2, 2014

errordeveloper commented Jul 2, 2014

errordeveloper commented Jul 4, 2014

errordeveloper commented Jul 6, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

farcaller commented Jul 6, 2014

errordeveloper commented Jul 6, 2014

errordeveloper commented Jul 7, 2014

errordeveloper commented Jul 7, 2014

farcaller commented Jul 7, 2014

errordeveloper commented Jul 7, 2014

Choose a reason for hiding this comment

farcaller commented Jul 7, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bharrisau commented Jul 7, 2014

bharrisau commented Jul 8, 2014

farcaller commented Jul 8, 2014

bharrisau commented Jul 8, 2014

farcaller commented Jul 8, 2014

errordeveloper commented Jul 8, 2014

farcaller commented Jul 8, 2014