Makefile and compile warnings/errors

[Timmy Douglas]

"Steve Folta" <st...@folta.net> writes:

> I tried to reply to the list, but it wouldn't accept it. Here's what I said:
>
> ---------- Forwarded message ----------
> From: Steve Folta <st...@folta.net>
> Date: Sat, Dec 13, 2008 at 12:01 AM
> Subject: Re: Welcome to the next generation of the Slate programming language
> To: slate-l...@googlegroups.com
>
>
> On Fri, Dec 12, 2008 at 8:05 PM, Timmy Douglas <goo...@timmy.tmbx.com> wrote:
>> You shouldn't be getting warnings about printf statements because %ld
>> should be signed like word_t. I would like to see those warnings
>> you're getting if that's the case.
>
> There were lots of them, here are just a few examples:
> vm.c:595: warning: format '%ld' expects type 'long int', but argument
> 2 has type 'word_t'
> vm.c:603: warning: format '%lX' expects type 'long unsigned int', but
> argument 3 has type 'word_t'
> vm.c:6800: warning: format '%lu' expects type 'long unsigned int', but
> argument 3 has type 'size_t'
>
> Like I said, changing the signedness of word_t didn't make any
> difference. If I'm interpreting /usr/include/stdint.h correctly,
> intptr_t is "int" on my system, not "long int", so I guess that's why
> it's complaining (even though "int" and "long" are both 32 bits wide).
> GCC 4.1.2, Gentoo.

Yeah, it's defined as long int here, so I guess someone else has
already figured out this for us. I just pushed a change which should
fix this for you. Tell me if I missed any.


>>> I also had to comment out the "ARCH=-m64" line in the Makefile. Why
>>> is that even needed? Wouldn't "-m64" be used implicitly in a 64-bit
>>> environment?
>>
>> I originally had it like that but it seems that it isn't implicit (or
>> implicitly the right setting?) on Brian's mac so I put it in like
>> that.
>
> If it can't be fixed, you had better mention it in README. "make
> ARCH=-m32" works. But I just tried it on Mac (10.5.5) and it worked
> fine without "-m64" -- but I did use the 32-bit kernel. I would
> suggest not defining $(ARCH) by default, and letting people with
> special situations define it from the command line... but it looks
> like you just checked in something like that.

hopefully those changes work out, I spent all night trying to get
libtool and the parts I took from the old slate makefile to work.

[Steve Folta]

On Dec 13, 7:11 am, Timmy Douglas <goo...@timmy.tmbx.com> wrote:
> I just pushed a change which should fix [the printf warnings] for you. Tell me if I missed any.

You missed lines 791 and 896. Thanks for the fix, I'm not sure I
would've ever discovered "PRIdPTR". Speaking of warnings, I still get
these:

=====
vm.c:4499: warning: unused variable ‘sin6’
vm.c:4497: warning: unused variable ‘options’
=====

Later versions of GCC are so picky...

> hopefully those [Makefile] changes work out, I spent all night trying to get

> libtool and the parts I took from the old slate makefile to work.

Working fine here, thanks. Before I pulled them, I tried "-m64" on
the Mac, which worked fine with the 64-bit image. So Mac can be built
as either 32-bit or 64-bit. But with the new Makefiles, $(ARCH) is
gone and there doesn't seem to be a good way to add "-m64" to the
command line if you do want it. "make CFLAGS=-m64" built without a
problem and the vm ran, but all the CFLAGS from the Makefiles were
clobbered (notably "-DSLATE_DATADIR" and "-pthread"). I didn't try
anything complicated when running it, so I don't know what effect the
lack of those CFLAGS had.

One other question: when in the debugger, how does one use the "0" and
"1" options? Just typing "0" or "1" followed by the return key
doesn't do anything. Typing "0." or "1." just prints "0" or "1".
(And it took me a while to realize that all the debugger commands must
be terminated with a period to do anything.)

May I suggest adding a ".gitignore" file? It would make "git
status"es and commit message edit buffers much cleaner. Here's what
I've got:

=====
vm
vm.debug
*.image
=====

[Timmy Douglas]

On Dec 13, 5:36 pm, Steve Folta <stevefo...@gmail.com> wrote:
> On Dec 13, 7:11 am, Timmy Douglas <goo...@timmy.tmbx.com> wrote:
>
> > I just pushed a change which should fix [the printf warnings] for you. Tell me if I missed any.
>
> You missed lines 791 and 896.  Thanks for the fix, I'm not sure I
> would've ever discovered "PRIdPTR".  Speaking of warnings, I still get
> these:
>
> =====
> vm.c:4499: warning: unused variable ‘sin6’
> vm.c:4497: warning: unused variable ‘options’
> =====
>
> Later versions of GCC are so picky...

ok good. i get those two also. it's a reminder for me to add IPv6
support to the socket primitives. Probably will only take 10 minutes
but I haven't had enough motivation to do it yet.

> > hopefully those [Makefile] changes work out, I spent all night trying to get
> > libtool and the parts I took from the old slate makefile to work.
>
> Working fine here, thanks.  Before I pulled them, I tried "-m64" on
> the Mac, which worked fine with the 64-bit image.  So Mac can be built
> as either 32-bit or 64-bit.  But with the new Makefiles, $(ARCH) is
> gone and there doesn't seem to be a good way to add "-m64" to the
> command line if you do want it.  "make CFLAGS=-m64" built without a
> problem and the vm ran, but all the CFLAGS from the Makefiles were
> clobbered (notably "-DSLATE_DATADIR" and "-pthread").  I didn't try
> anything complicated when running it, so I don't know what effect the
> lack of those CFLAGS had.

I just added something where you can do ARCH=64 make
and that should put the flag there.

> One other question: when in the debugger, how does one use the "0" and
> "1" options?  Just typing "0" or "1" followed by the return key
> doesn't do anything.  Typing "0." or "1." just prints "0" or "1".
> (And it took me a while to realize that all the debugger commands must
> be terminated with a period to do anything.)

: 0.

the whole repl debugger needs to be fixed. if you do:

: up.

too many times it gets screwed up. anyone interested in fixing it? heh

> May I suggest adding a ".gitignore" file?  It would make "git
> status"es and commit message edit buffers much cleaner.  Here's what

ok I just added that file. thanks. I didn't know about that feature.

[Steve Folta]

I wrote:
> > One other question: when in the debugger, how does one use the "0" and
> > "1" options? Just typing "0" or "1" followed by the return key
> > doesn't do anything. Typing "0." or "1." just prints "0" or "1".
> > (And it took me a while to realize that all the debugger commands must
> > be terminated with a period to do anything.)

On Dec 13, 2:54 pm, Timmy Douglas <goo...@timmy.tmbx.com> wrote:
> : 0.
>
> the whole repl debugger needs to be fixed. if you do:

Didn't work:

=====
Debug [0..1]: :0.

The following condition was signaled from within the debugger:
Error: Line 2: Only the first argument to a binary message may be
implicit
Debug [0..1]: Nil
Debug [0..1]:
=====

"restart: 0." did work.

[Timmy Douglas]

you need a space after the :.