#17

oy. shall we delegate some tasks?

ie. i can throw in some hours finishing a cut-copy job of making (nearly everything) into OPs on another branch?

#18

If you like. Only problem is that vars and arrays can’t get turned into ops, until ops gain the ability to run in the set postion (a.k.a left).

We need to change

typedef struct {
    const char *name;
    void (*func)(void);
    char params;
    int8_t returns;
    const char *doc;
} tele_op_t;

to

typedef struct {
    const char *name;
    void (*get)(void);
    void (*set)(int16_t);
    char params;
    int8_t returns;
    const char *doc;
} tele_op_t;

and then update validate to allow ops to work with either get (a.k.a left) or set (right).

We need a way to indicate that an op doesn’t support the set operation. Either NULL or a special notsupported function pointer that we can check for equality. validate and process needs to take this into account.

If you’ve got time to burn at the moment and you want to get on with things I can try and go into even greater detail about how I’d do it? Otherwise I’ll be able to get stuff sorted in the next week or so.

#19

Right, C unit testing, I’ve given up on fork based. We’re just going to have to be careful with our testing and global state.

So far I’ve got:

Header only

Minimal C

I quite like the look of the silentbicycle pair. Particularly theft as we might be able to use it to stress test the parser and validator. Greatest also mentions that it doesn’t allocate which could be useful for running on hardware (if we ever do that).

I will try and get a PR in tomorrow with a working test runner and some helper functions / macros for testing the parse and validate functions, then we can start creating some test cases.

2 Likes
#20

:thumbsup:

It’s funny. On my way to work I was thinking, screw it, we could just write a simple framework in maybe a file. Happy to see someone’s already done it!

Needless to say, stoked to see this happen. Let me know if I can help.

1 Like
#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