gnupic: Thread: gpsim-0.21.2 & lcd-0.2.1

Are now released:

http://www.dattalo.com/gnupic/gpsim-0.21.2.tar.gz

http://www.dattalo.com/gnupic/lcd-0.2.1.tar.gz


As many of you are aware, there have been many changes made to gpsim over 
the last couple of months. As a consequence, some new bugs have crept in. 
This release contains even more changes and fixes all of the recently 
reported bugs (I think). And over the next few months, there will be even 
more changes.

(MAC users: I did not apply the fink patch. If one of you can kindly see 
if this patch still applies, I'll go ahead and make the changes permanent 
in gpsim. BTW, I'm starting to use '0' instead of NULL for pointer 
assignments and it works just fine on Linux.)


I made a new release of the LCD module because I know it is compatible
with this release of gpsim.

From a user's perspective, things look identical. However, much has 
changed and continues to change under the hood. The whole interface 
between the gui and the simulator is being re-written. The base C++ 
classes are being enhanced. The gui is being converted to be more C++ (it 
was originally written in C). All of these changes are being made to 
accomodate the expected future growth of gpsim.

Scott

The patch itself fails because the changes made are too much for diff 
to handle.
However, Gpsim builds nicely when I:

1. do a find-and-replace for all NULL's to 0's (match full-words, case 
sensitive)
2. replace config.guess and config.sub with newer versions that know 
Darwin
3. run the commands that should be done when getting a copy of gpsim 
from cvs:
     aclocal && autoheader && automake --add-missing && autoconf
4. use ./configure --disable-shared

michiel

Notes on step 3:
   - make fails because of an outdated aclocal.m4 and a missing depcomp 
otherwise.
   - I used the gpsim-0.21.2.tar.gz source package, not a snapshot from 
cvs.
   - This seems to be triggered by the find/replace changes. I never see 
these complaints about aclocal.m4 and
     depcomp if I try make before replacing the NULL's (it won't build, 
but that's another matter)


On 8-feb-04, at 20:46, Scott Dattalo wrote:
>
>
> (MAC users: I did not apply the fink patch. If one of you can kindly 
> see
> if this patch still applies, I'll go ahead and make the changes 
> permanent
> in gpsim. BTW, I'm starting to use '0' instead of NULL for pointer
> assignments and it works just fine on Linux.)
>

On Sun, 8 Feb 2004, Scott Dattalo wrote:
> (MAC users: I did not apply the fink patch. If one of you can kindly see 
> if this patch still applies, I'll go ahead and make the changes permanent 
> in gpsim. BTW, I'm starting to use '0' instead of NULL for pointer 
> assignments and it works just fine on Linux.)

Some MAC OS/X comments.

I built a new fink package for gpsim-0.21.2, and plan on submitting it
today to the fink folks.

I still needed to patch in order to build. The old patch no longer applies 
cleanly, and I created a new one.

Updated gpsim.info and gpsim.patch are on my site for now.

http://screwdecaf.cx/tools

The led, logic, and lcd modules were not originally included, but I
started looking into having fink build those add-on modules as well.

The stopwatch feature within gpsim still crashes on me even with 0.21.2.
Here is what CrashReport had to say. I snipped out a few hundred
repeating lines.

Host Name:      littlebit.local
Date/Time:      2004-02-08 16:47:04 -0500
OS Version:     10.3.2 (Build 7D24)
Report Version: 2

Command: gpsim
Path:    /sw/bin/gpsim
Version: ??? (???)
PID:     24336
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xbf7ffff0

Thread 0 Crashed:
0   libSystem.B.dylib   0x90001c38 szone_size + 0x18
1   libSystem.B.dylib   0x90001058 free + 0x58
2   libgtk-1.2.0.dylib  0x01c73b54 gtk_entry_get_text + 0xdc 
(gtkentry.c:543)
3   gpsim               0x0009bcfc cyclechanged(_GtkWidget*, 
StopWatch_Window*) + 0x64 (gui_stopwatch.cc:175)
4   libgtk-1.2.0.dylib  0x01ce0954 gtk_handlers_run + 0xd0 
(gtksignal.c:1917)
5   libgtk-1.2.0.dylib  0x01cdfa54 gtk_signal_real_emit + 0x304 
(gtksignal.c:1478)
6   libgtk-1.2.0.dylib  0x01cdd13c gtk_signal_emit + 0x1b8 
(gtksignal.c:553)
7   libgtk-1.2.0.dylib  0x01c712c0 gtk_editable_insert_text + 0x194 
(gtkeditable.c:440)
8   libgtk-1.2.0.dylib  0x01c73490 gtk_entry_set_text + 0x128 
(gtkentry.c:453)
9   gpsim               0x0009bb28 StopWatch_Window::Update() + 0x3b8 
(gui_stopwatch.cc:117)

[...SNIP...]

507 gpsim               0x0009bb70 StopWatch_Window::Update() + 0x400
(gui_stopwatch.cc:121)
508 libgtk-1.2.0.dylib  0x01ce0954 gtk_handlers_run + 0xd0
(gtksignal.c:1917)

PPC Thread State:
  srr0: 0x90001c38 srr1: 0x0000f030                vrsave: 0x00000000
    cr: 0x44044244  xer: 0x00000004   lr: 0x90001c30  ctr: 0x90001c20
    r0: 0x90001058   r1: 0xbf800050   r2: 0xa0001010   r3: 0x02800000
    r4: 0x02126b30   r5: 0x021242c0   r6: 0xbf8002c0   r7: 0x00000000
    r8: 0x00020000   r9: 0x0000011c  r10: 0x01d0f6dc  r11: 0x00e86614
   r12: 0x90001c20  r13: 0x00e81fdc  r14: 0x00e862e4  r15: 0x00e862e4
   r16: 0x00e81fdc  r17: 0x00e862e4  r18: 0x00e862e4  r19: 0x00e862dc
   r20: 0xbffff5b0  r21: 0x00e862e0  r22: 0xbf8002c0  r23: 0x01d5755c
   r24: 0x00000000  r25: 0x01d57580  r26: 0x01d57584  r27: 0x02126b30
   r28: 0xa000b430  r29: 0x02800000  r30: 0x02126b30  r31: 0x90001010

Binary Images Description:
    0x1000 -   0x108fff gpsim   gpsim
  0xcc4000 -   0xcc5fff libgmodule-1.2.0.dylib /sw/lib/libgmodule-1.2.0.dylib
  0xcd1000 -   0xcd6fff libpopt.0.dylib         /sw/lib/libpopt.0.dylib
  0xe65000 -   0xe85fff libglib-1.2.0.dylib /sw/lib/libglib-1.2.0.dylib
  0xec5000 -   0xeeefff libncurses.5.dylib /sw/lib/libncurses.5.dylib
  0xf61000 -   0xf8bfff libgdk-1.2.0.dylib /sw/lib/libgdk-1.2.0.dylib
 0x1808000 -  0x1834fff libreadline.4.dylib /sw/lib/libreadline.4.dylib
 0x198c000 -  0x19f6fff libgtkextra-0.99.17.dylib /sw/lib/libgtkextra-0.99.17.dylib
 0x1c24000 -  0x1d4ffff libgtk-1.2.0.dylib /sw/lib/libgtk-1.2.0.dylib
0x20010000 - 0x200e4fff libiconv.2.dylib        /sw/lib/libiconv.2.dylib
0x20540000 - 0x20544fff libintl.1.dylib         /sw/lib/libintl.1.dylib
0x85c90000 - 0x85c9bfff libXext.6.dylib /usr/X11R6/lib/libXext.6.dylib
0x85ef0000 - 0x85fbbfff libX11.6.dylib  /usr/X11R6/lib/libX11.6.dylib
0x8fe00000 - 0x8fe4ffff dyld    /usr/lib/dyld 
0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 
0x939d0000 - 0x939d4fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib

On Sun, 2004-02-08 at 19:46, Scott Dattalo wrote:
>  BTW, I'm starting to use '0' instead of NULL for pointer 
> assignments and it works just fine on Linux.)

I'm comming to this story near the end, but can you explain why you
are using "0" in place of NULL ?

It seems an od thing to do as IMHO it reduces readability while
not providing any benefit.

Peter

Peter Onion wrote:
> I'm comming to this story near the end, but can you explain why you
> are using "0" in place of NULL ?
> It seems an od thing to do as IMHO it reduces readability while
> not providing any benefit.

I may have mis-remembered this, but isn't the point of NULL to avoid 
issues with putting 0 into a pointer variable on systems where 
sizeof(void *) != sizeof(int)?

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

On Mon, 9 Feb 2004, Peter Onion wrote:

> On Sun, 2004-02-08 at 19:46, Scott Dattalo wrote:
> >  BTW, I'm starting to use '0' instead of NULL for pointer 
> > assignments and it works just fine on Linux.)
> 
> I'm comming to this story near the end, but can you explain why you
> are using "0" in place of NULL ?
> 
> It seems an od thing to do as IMHO it reduces readability while
> not providing any benefit.

I agree Peter. The only purpose was to get gpsim to compile on a Mac
without having Mac users apply a patch. Alex Holden sent me a capture of 
the errors that are produced without this patch. I'd rather use this 
information and try to identify the specific problem. So I'm not going to 
go through all of gpsim and change NULL to 0.

Scott

On Monday 09 February 2004 05:49 am, Peter Onion wrote:
> On Sun, 2004-02-08 at 19:46, Scott Dattalo wrote:
> >  BTW, I'm starting to use '0' instead of NULL for pointer
> > assignments and it works just fine on Linux.)
>
> I'm comming to this story near the end, but can you explain why you
> are using "0" in place of NULL ?
>
> It seems an od thing to do as IMHO it reduces readability while
> not providing any benefit.

The usage of 0 vs NULL has to do with differences in C/C++ and how
NULL might be defined on different systems (and sometimes defined
in multiple places - use the -E pre-processor only flag to find out
what version of NULL your environment is using).


Someone does a good job of explaining what is going on here:
http://groups.google.com/groups?q=NULL+group:comp.lang.c%2B%
2B.*&hl=en&lr=&ie=UTF-8&group=comp.lang.c%2B%
2B.*&selm=gb6pet0ujm0qmkd50or3ro9ceqr3mns0r3%404ax.com&rnum=1

There used to be a very good explaination in some FAQ, but I can't
find it again.  Basically it said use NULL in C, use 0 in C++.

Here's a slightly terser explaination:
http://groups.google.com/groups?q=NULL+group:comp.lang.c%2B%
2B.*&start=10&hl=en&lr=&ie=UTF-8&group=comp.lang.c%2B%
2B.*&selm=1991Sep20.213017.2961%40microsoft.com&rnum=19

Finally, Stroustrup has this to say
(http://www.research.att.com/~bs/bs_faq2.html#null)

] Should I use NULL or 0?
] 
]  In C++, the definition of NULL is 0, so there is only an aesthetic
]  difference. I prefer to avoid macros, so I use 0. Another problem
]  with NULL is that people sometimes mistakenly believe that it is
]  different from 0 and/or not an integer. In pre-standard code, NULL
]  was/is sometimes defined to something unsuitable and therefore
]  had/has to be avoided. That's less common these days.


A small excerpt from the second reference (which has some concrete examples of
how code might break if the wrong NULL is used).

] -- Clearly if one can really *trust* NULL to be identically '0' no matter
] what one's fellow programmers do, and no matter what libraries one
] uses, then one can use '0' and NULL intechangably.
] 
] Unfortunately, historically, various vendors, programmers, and libraries
] have had differing ideas of what the "proper" thing for NULL to be
] really is -- and why.  Thus in C++ when one programs using NULL
] one finds one's program's behavior changes depending on *who's *
] definition of NULL one actually gets on a given day!
] 
] Here's a short list of a few things I've seen NULL to be defined as
] over the years:
] 
] 0
] 0L
] ((void*)0)
] ((char*)0)
] ((void far*)0)
] ((void near*)0)
] etc.


mike

On Mon, 9 Feb 2004, Mike Durian wrote:

> On Monday 09 February 2004 05:49 am, Peter Onion wrote:
> > On Sun, 2004-02-08 at 19:46, Scott Dattalo wrote:
> > >  BTW, I'm starting to use '0' instead of NULL for pointer
> > > assignments and it works just fine on Linux.)
> >
> > I'm comming to this story near the end, but can you explain why you
> > are using "0" in place of NULL ?
> >
> > It seems an od thing to do as IMHO it reduces readability while
> > not providing any benefit.
> 
> The usage of 0 vs NULL has to do with differences in C/C++ and how
> NULL might be defined on different systems (and sometimes defined
> in multiple places - use the -E pre-processor only flag to find out
> what version of NULL your environment is using).

Wow, I didn't realize the history on this...

Alex Holden sent me a capture of the errors produced on a Mac compilation
of gpsim. The "offending" file was intcon.cc. There's nothing special
about it per se except that it doesn't #include <stdio.h>. A little
digging around showed that on my Linux box stdio.h includes stddef.h which
has:

#undef NULL
#if defined(__cplusplus)
#define NULL 0
#else
#define NULL ((void *)0)
#endif

Coming from an (ancient) C background, I like the idea of using NULL to 
differentiate pointers from non-pointers. However, this pre-processor 
snippet and testimony from others shows that for C++ NULL is, well, NULL. 
While the use of "NULL" may show intent, it really has no substance in 
C++. So for here on out, I'm going to start using 0 instead of NULL.

Scott

The only remaining benefit I see with NULL is that it makes the code 
more clear; 

- when we see a NULL, we know Scott was assigning a zero to a pointer.
- when we see a 0, we know Scott was assigning a zero to a scalar value.

Yes, it is redundant.  But so are comments.

If the portability of NULL is a concern, define it yourself.

-- 
James Cameron    ####@####.####     http://quozl.netrek.org/

> The only remaining benefit I see with NULL is that it makes the code 
> more clear; 
> 
> - when we see a NULL, we know Scott was assigning a zero to a pointer.
> - when we see a 0, we know Scott was assigning a zero to a scalar value.
> 
> Yes, it is redundant.  But so are comments.
> 
> If the portability of NULL is a concern, define it yourself.

I agree with James.  Only a CS professor would whine about NULL vs 0
for 'null' pointers.  If your system is broken, *fix it*.  We're all
talking about GNU systems, right?  Open source?  Don't like it, then
fix the source?

NULL has only one meaning, to use as a value to assign to a pointer
to make it clear that it points to *nothing good*.  Most modern
systems define it as 0 (or some odd cast of zero which makes no
difference).  And then they unmap the '0' page of memory so that
references to it will segfault.  That's the only use of it these
days.  Well, that and to have some value that you can say:

if (p == NULL)
  panic();

Compared to all of the complexity of the design of gpsim, the amount
of time we've already spent arguing about the NULL pointer is getting
rediculous.

Here's a patch:

+ #include "fiat.h"

fiat.h is:
#define NULL 0

Cheers,
David