#21

I am so happy to see the unit testing discussion happening. Given my relative inexperience with C, I know I’m gonna need tests if I’m ever going to be able to lend a hand in a productive way.

1 Like
#22

OK, wow. I see that mentioned in the other thread. It would be great to get this going for the monome repos. I’m a big fan of travis.

#23

my “smart” time is dedicated to other tasks at the moment-- but i could commit some autopilot-type activity (ie cut-paste).

#24

Nicely put. I’m pretty cool with a bit of autopilot coding here and there, my emacs-fu is pretty good these days, plus there’s something therapeutic about it if you get into a good rhythm. My main concern is holding you up really.

Ah, travis, I really appreciate it as a service, but I despise writing .travis.yml files, for me it really is an afternoon spent:

10 vim .travis.yml
20 git push -f
30 make tea
40 if error goto 10

You can be in charge of it now :stuck_out_tongue:

2 Likes
#25

:smile:

Ah, but you’re nearly there! Seriously though, I’m happy to help. Not sure I have the right perms though…

Added a ticket to track: teletype/issues/28.

1 Like
#26

@ppqq added you to the team

1 Like
#27

Watch out what you ask for eh?

EDIT: Landed. And as of @cbb9fe8,

we’ve got stinking badges too.

:gift:

2 Likes
#28

Nice one @ppqq.

Shall I submit the one I wrote for libavr32?

It downloads a copy of the master branch for each of the modules, copies the updated version of libavr32 over and makes sure it compiles.

I was quite chuffed with myself for writing it!

https://travis-ci.org/samdoshi/libavr32

https://github.com/samdoshi/libavr32/blob/travis/.travis.yml

3 Likes
#29

Been cracking on with the unit testing this morning, I used the 1.0 scenes as a corpus of valid statements… anyway there are a few typos on that page, search for:

RE 4 1
TR. PULSE A
DEL MUL T 4 : TR.PULSE
1 Like
#30

are these typos on the webpage only? i think the .txt files should be direct exports and work. the webpage was transcribed poorly by someone unfamiliar with the protocol-- i’ve already corrected many typos. will get these fixed, thanks.

#31

impressive! sure, let’s put it in.

#32

The unit tests (or should I say unit test) are pretty basic. It just checks that parse and validate return E_OK for a bunch of statements.

If anyone wants to refactor it or add some more tests please feel free. I’ll crack on with merging vars, arrays and keys into ops this weekend.

3 Likes
#33

:thumbsup:

Cool stuff. I agree.

#34

sorry, haven’t been participating much, was sick and been having troubles with my audio interface having to go through a couple of replacements, should be able to start helping with some stuff next week.

1 Like
#35

Here is my ops branch, if anyone fancies following along with what I’ve been doing.

So far… tele_op_t has become:

typedef struct {
    const char *name;
    void (*get)(const void *data);
    void (*set)(const void *data, int16_t value);
    uint8_t params;
    bool returns;
    const void *data;
    const char *doc;
} tele_op_t;

The main additions are the set fn pointer and const void* data, which is there to make some automations easier by holding arbitrary data, such as keys… which no longer exist, they’ve been converted to ops like so

static void op_CONSTANT(const void *data) {
    push((intptr_t)data);
}

and using a macro MAKE_CONSTANT

#define MAKE_CONSTANT_OP(n, v, d)                                 \
    {                                                             \
        .name = #n, .get = op_CONSTANT, .set = NULL, .params = 0, \
        .returns = 1, .data = (void *)v, .doc = d                 \
    }

et voila:

The plan is to use data to automate the creation of vars and arrays by holding either the array index or a struct offset (via. offsetof). It’s not the safest bit of code, but I figure that the reduction in potential duplication makes it worth it.

It could also enable us to create operators like ADD3 x y z, ADD4 w x y z, etc, without code duplication.

Next up, I’m going to modify process to return the last value on the stack (if there is one) and move output and output_new to main.c. This should enable me to write some tests for process (within the bounds of the global state we have).

DONE:

I’ve limited the update to output and output_new to when you’re in live mode, hope that was right. Seems like it works fine on my device.

TEST test_ADD() {
    // beware of global state!!!
    char* test1[1] = { "ADD 5 6" };
    CHECK_CALL(process_helper(1, test1, 11));

    char* test2[1] = { "ADD 2 -2" };
    CHECK_CALL(process_helper(1, test2, 0));

    PASS();
}

:smiley:

3 Likes
#36

amazing work! i’ll check it out code, though your summary here is very insightful.

i’m really looking forward to building features on top of this new implementation-- it feels very robust.

1 Like
#37

Hot stuff! Perusing your branch now. I love where you’re going. Quick question/nit: Any thoughts on more descriptive field names for process_result_t? At first blush h and v are (to me anyway) a bit opaque.

EDIT: maybe best to take the down-in-the-weeds chatter over to github. Popping over there for any other nits…

#38

Here is fine. At the moment a lot of the ancillary stuff is just a means to an end, it’s entirely possible that much of it will disappear. Once I’ve got the big ticket item done (i.e. merging ops, arrays & variables), I’ll revisit most of it and write some more comments and such.

It’s getting pretty close though, next step is to get the set function pointer of ops working and switch P and PN to use them instead of the hacks.

1 Like
#39

I’ve just pushed a change to switch P and PN to use the new set function pointer. This gets rid of any hacks in validate. I’m going to re-review the changes tomorrow or on Monday, as this was the most fiddly bit.

I had to remove the value parameter from the set function pointer, as it doesn’t work due to the ordering of values in the stack. If that’s the only mistake I’ve made with my plan, I’ll be very chuffed!

Next up, convert the simple variables (e.g. X, DRUNK.MIN) to ops, via a generic variable get & set op. I’m planning on converting tele_vars to a struct and removing the enum and array indexing. Instead I’ll use some offsetof tricks to peek and poke into the struct. Anyone spot any flaws with that?

1 Like
#40

Looks great to me! (I added some comments, mainly about style, but feel free to ignore if they’re off base.)

1 Like