[SOLVED] Objects and assignment in interpreter

MTK358 · 02-27-2011, 04:17 PM

If compiled, finally! Not even a single warning!

I actually still did it myself, but used your code to help me where I got stuck. There were a few places where you misinterpreted my code because of my mistakes.

Now I'll see if it actually works...

MTK358 · 02-27-2011, 05:34 PM

@Nominal Animal

Why did you delete all your posts? Was I the one who insulted you?

Anyway:

I made it try to evaluate a single number node, but it segfaults.

I used GDB, and it says that it's trying to push to an array whose count is a really huge appearantly random number. I have no idea how it happens. The error occurred in GC_realloc, which was callsed by array_push, which was called by env_set, which was called by create_number_env.

Here is my code, in case you want it (while making the archive, I accidentally overwrote array.c with an archive of the rest of the files because of a mistake in the command line. But I got it back via the attachment I made to a previous post, and thankfully array.c was one of the files that had no errors that I would need to fix again):

Nominal Animal · 02-27-2011, 05:37 PM

Quote:

Originally Posted by MTK358

If compiled, finally! Not even a single warning!

I actually still did it myself, but used your code to help me where I got stuck. There were a few places where you misinterpreted my code because of my mistakes.

Now I'll see if it actually works...

Great! I hoped you'd do exactly that, use it as a helper to fix your own code. It's much more useful that way.

I'm not surprised I'd misinterpreted your code here and there, especially the macros are a devil to parse right.
Perhaps static inline functions would be better than macros here? They're just as fast in C99, no downsides or overhead compared to macros.

Instead of the build.sh script, you might find this Makefile easier to use:

Code:

CC	:= gcc
CFLAGS	:= -Wall -std=c99 -pedantic -O3 -ftree-vectorize -fomit-frame-pointer -I/usr/include/gc
LD	:= $(CC)
LDFLAGS	:= $(CFLAGS) -lgc
RM	:= /bin/rm

PROG	:= prog
OBJS    := array.o ast.o boolean_type.o c_function.o env.o main.o node_function.o number_type.o string_type.o

.PHONY: all clean

all: $(PROG)

clean:
	$(RM) -f $(OBJS) $(PROG)

%.o: %.c
	$(CC) $(CFLAGS) -c $<

$(PROG): $(OBJS)
	$(LD) $(LDFLAGS) -o $@ $^

For example, make will track changes, so that it only recompiles the changed bits. To do a full rebuild, run make clean all
I also used quite aggressive optimization settings, -O3 -ftree-vectorize -fomit-frame-pointer that tend to produce very efficient code on all architectures.

If you really like the output with ANSI colors, you could use this Makefile instead:

Code:

CC	:= gcc
CFLAGS	:= -Wall -std=c99 -pedantic -O3 -ftree-vectorize -fomit-frame-pointer -I/usr/include/gc
LD	:= $(CC)
LDFLAGS	:= $(CFLAGS) -lgc
ECHO	:= /bin/echo
RM	:= /bin/rm

PROG	:= prog
OBJS    := array.o ast.o boolean_type.o c_function.o env.o main.o node_function.o number_type.o string_type.o

.PHONY: all clean

all: $(PROG)

clean:
	@$(ECHO) -e "\033[1;36m$(RM)\033[0;36m -f \033[1;36m$(OBJS) $(PROG)\033[0;31m"
	@$(RM) -f $(OBJS) $(PROG)
	@$(ECHO) -e "\033[0;32mBuild directory is \033[1;32mclean\033[0;32m.\033[0m"

%.o: %.c
	@$(ECHO) -e "\033[1;36m$(CC)\033[0;36m $(CFLAGS) -c \033[1;36m$<\033[0;31m"
	@$(CC) $(CFLAGS) -c $<
	@$(ECHO) -e "\033[1;32m$@\033[0;32m compiled successfully.\033[0m"

$(PROG): $(OBJS)
	@$(ECHO) -e "\033[1;36m$(LD)\033[0;36m $(LDFLAGS) -o \033[1;36m$@\033[0;36m $^\033[0;31m"
	@$(LD) $(LDFLAGS) -o $@ $^
	@$(ECHO) -e "\033[1;32m$@\033[0;32m built successfully.\033[0m"

Nominal Animal · 02-27-2011, 05:50 PM

Quote:

Originally Posted by MTK358

@Nominal Animal

Why did you delete all your posts? Was I the one who insulted you?

No, of course not. It was an unambiguous direct insult from a member that to my knowledge has never participated in the same threads I have. I thought XavierP had decided to let the insult stand, but I was wrong; it was an unfortunate oversight -- and an understandable one, because XavierP couldn't even see the insult at all. I assumed this was modus operandi for LQ moderators, and deleted my posts in an attempt to bring it to wider attention. So it wasn't the insult per se; I have very little tolerance for bullying, and none at all for those that turn a blind eye. Unfortunately, I ended up bullying XavierP myself.

Quote:

Originally Posted by MTK358

I used GDB, and it says that it's trying to push to an array whose count is a really huge appearantly random number. I have no idea how it happens. The error occurred in GC_realloc, which was callsed by array_push, which was called by env_set, which was called by create_number_env.

Here is the warning gcc-4.4.3 with the above Makefile reports:

Code:

env.c: In function ‘env_set’:
env.c:30: warning: ‘env_with_member’ may be used uninitialized in this function

Basically, env_with_member may not be set in the do-while loop. Because it's a local variable, it's not initialized by the compiler (to zeros), and gets some random value (whatever was in the stack there earlier).

I think you can just set env_with_member initially to this, if I understand the code correctly -- that it's supposed to be the topmost parent with a key of that name, or this one if no such key exists.

MTK358 · 02-27-2011, 07:13 PM

Quote:

Originally Posted by Nominal Animal

No, of course not. It was an unambiguous direct insult from a member that to my knowledge has never participated in the same threads I have. I thought XavierP had decided to let the insult stand, but I was wrong; it was an unfortunate oversight -- and an understandable one, because XavierP couldn't even see the insult at all. I assumed this was modus operandi for LQ moderators, and deleted my posts in an attempt to bring it to wider attention. So it wasn't the insult per se; I have very little tolerance for bullying, and none at all for those that turn a blind eye. Unfortunately, I ended up bullying XavierP myself.

But you deleted your first post here, before anyone ever posted in this thread!

Almost all your useful posts are gone, and I don't remember seeing anything remotely insulting to anyone in them!

I would like to know, but it seems like you have PM disabled.

MTK358 · 02-27-2011, 07:32 PM

It works now. I'll try making a few ASTs in the main function and evaluating them, to make sure it all works.

Then, I will try to integrate it will Lex/YACC and possibly get a working language interpreter!

MTK358 · 02-27-2011, 07:50 PM

I but together a slightly more complex AST:

Code:

    node_t *node = node_new(NODETYPE_CALL, array_new_prefill(1, node_new(NODETYPE_NUMBER, "3", 0)), 1,
                                node_new(NODETYPE_MEMBER, "__op_add", 1, 
                                    node_new(NODETYPE_NUMBER, "8", 0)
                                )
                           );

It segfaulted, and this is wht GDB says:

Code:

Reading symbols from /home/michael/newlang/a.out...done.
(gdb) run
Starting program: /home/michael/newlang/a.out 
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff785954e in ?? () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff785954e in ?? () from /lib/libc.so.6
#1  0xdac803ff83b189c2 in ?? ()
Cannot access memory at address 0xdac803ff83b189c2

?????????????????

Note that it first segfaulted due to an unititialized pointer, because initially I wrote

Code:

		if (node->child_count == 1) env_with_var = (env_t*) node_eval(node->children[1], env);

instead of

Code:

		if (node->child_count == 1) env_with_var = (env_t*) node_eval(node->children[0], env);

in line 95 of ast.c (in the part that evaluates member access nodes). But when I fixed it, the above error happens!

Nominal Animal · 02-27-2011, 08:38 PM

Quote:

Originally Posted by MTK358

But you deleted your first post here, before anyone ever posted in this thread!

I deleted all my posts. Like I said, I thought it was a wider problem, and wanted visibility.

Quote:

Originally Posted by MTK358

Almost all your useful posts are gone, and I don't remember seeing anything remotely insulting to anyone in them!

It was not in a post. I've been slowly fixing and reinstating my posts.

Quote:

Originally Posted by MTK358

I would like to know, but it seems like you have PM disabled.

I thought I had enabled them, but I hadn't; thanks for letting me know. Private messaging should work now.

Nominal Animal · 02-27-2011, 08:55 PM

Quote:

Originally Posted by MTK358

I but together a slightly more complex AST:

Okay, I think the AST at node looks like this:

Code:

NODETYPE_CALL (payload = array_t, a single entry: NODETYPE_NUMBER (payload = 3) )
 + NODETYPE_MEMBER (payload = "__op_add")
    + NODETYPE_NUMBER (payload = 8)

Do you agree? But first, please get more detailed debug info by using -O0 -g gcc options, and rerunning the test.

MTK358 · 02-28-2011, 07:45 AM

Quote:

Originally Posted by Nominal Animal

Okay, I think the AST at node looks like this:

Code:

NODETYPE_CALL (payload = array_t, a single entry: NODETYPE_NUMBER (payload = 3) )
 + NODETYPE_MEMBER (payload = "__op_add")
    + NODETYPE_NUMBER (payload = 8)

Do you agree?

Yes

Quote:

Originally Posted by Nominal Animal

But first, please get more detailed debug info by using -O0 -g gcc options, and rerunning the test.

Same thing happens (using "gcc -c -g -O0 -Wall sourcefile.c" to compile each file, and "gcc -lgc *.o" to link).

Nominal Animal · 02-28-2011, 12:23 PM

Quote:

Originally Posted by MTK358

Yes

Okay, so the first complex bit of code executed is this in ast.c, right?

Code:

case NODETYPE_CALL:
{
    function_t *func = (function_t*) node_eval(node->children[0], env);
        if (func == NULL || func->objtype != OBJTYPE_FUNCTION)
            node_eval_throw_exception(create_exception_env((object_t*) create_string_env("TypeError"), (object_t*) create_string_env("Only functions can be called")));
        int i;
        for (i=0; i<((array_t*) (node->payload))->count; i++)
            array_set(node->payload, i, node_eval(array_get(node->payload, i), env));
        return func->call(func, node->payload);
}

I'd first add a couple of fprintf(stderr, ...)'s in there, to see how far that gets, and what the various variables actually hold. Also, I'd add another fprintf(stderr, ...) in the beginning of node_function_call() in node_function.c, to see if the callback stuff is initialized correctly. (If it never gets called, something must be wrong in the construction phase, node_function_new() in the same file.)

Hey, is there a return missing from before the node_eval_throw_exception above?

Quote:

Originally Posted by MTK358

Same thing happens (using "gcc -c -g -O0 -Wall sourcefile.c" to compile each file, and "gcc -lgc *.o" to link).

Yes, but the gdb output should contain more details, like function names and so on, where the problems happen. Could you show the gdb output when the binaries are compiled like that and the program run in gdb, please?

MTK358 · 02-28-2011, 12:42 PM

I kept trying to fix it, and came across this:

Code:

number_type.c: In function ‘ismembernum’:
number_type.c:8:12: error: ‘member’ redeclared as different kind of symbol
number_type.c:6:35: note: previous definition of ‘member’ was here
number_type.c:8:5: warning: passing argument 2 of ‘env_get’ from incompatible pointer type
env.h:29:7: note: expected ‘char *’ but argument is of type ‘struct env_t *’

What does it mean? This is the code:

Code:

6   int ismembernum(env_t *env, char *member)
7   {
8       env_t *member = (env_t*) env_get(env, member);
9       return member != NULL && member->objtype == OBJTYPE_ENV && member->envtype == ENVTYPE_NUMBER;
10  }

Nominal Animal · 02-28-2011, 01:01 PM

Quote:

Originally Posted by MTK358

I kept trying to fix it, and came across this:

Code:

number_type.c: In function ‘ismembernum’:
number_type.c:8:12: error: ‘member’ redeclared as different kind of symbol
number_type.c:6:35: note: previous definition of ‘member’ was here
number_type.c:8:5: warning: passing argument 2 of ‘env_get’ from incompatible pointer type
env.h:29:7: note: expected ‘char *’ but argument is of type ‘struct env_t *’

What does it mean? This is the code:

You have a local env_t variable named member, but also a parameter member to the function. You need to rename one.

MTK358 · 02-28-2011, 01:28 PM

It actually worked!!!

Code:

$ ./a.out
11.000000

Nominal Animal · 02-28-2011, 01:35 PM

Congratulations!

What's next, members and assignment?