Re: [Tuxpaint-dev] [fwd] Re: Tux Paint in Gnome? [panel crashing bug]
On Mon, 2004-12-13 at 00:03, Bill Kendrick wrote: > I was unable to reproduce the Gnome-panel-crashing bug with Tux Paint 0.9.15 > from CVS. Can someone out here with a Gnome setup test this? (Esp. if you're > able to crash with 0.9.14 :^) ) I had that happen just today. I assumed that the kernel chose to kill the panel to get more memory. The system was swapping like crazy when it happened. Fortunately, Tux Paint died and GNOME restarted the panel. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] NoNags.com - HOW do you get listed!?
Karl! Do you (or anyone else out here) happen to know what kind of criteria NoNags.com uses when chosing what software to list? Or... how about deciding whether or not to even respond to people!? >:^( This is so irritating! I submitted Tux Paint 0.9.14 immediately after it was released, on October 12th. It didn't show up by their next site update, so I submitted it again on October 22nd, being very careful when submitting. Almost a month later, on November 20th, I emailed them to ask if I did anything wrong, or if Tux Paint is merely in a long queue. No response. I emailed them again this past Thursday (December 9th). Again, no response so far! Man, I've obviously been taking sites like SourceForge and Freshmeat for granted, because it seems in the Windows world even the 'top' software directories aren't very up-to-date. Sheesh! Anyway, sorry for ranting. If anyone out here has any previous relationship with the folks who run this site, or know anyone who does, can you help out? Thanks, -bill! [EMAIL PROTECTED] Have I been helpful? http://newbreedsoftware.com/http://svcs.affero.net/rm.php?r=billkendrick ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] [fwd] Re: Tux Paint in Gnome? [panel crashing bug]
I was unable to reproduce the Gnome-panel-crashing bug with Tux Paint 0.9.15 from CVS. Can someone out here with a Gnome setup test this? (Esp. if you're able to crash with 0.9.14 :^) ) Thanks, -bill! - Forwarded message from John Baillie - Date: Sat, 11 Dec 2004 09:19:40 -0500 From: John Baillie Subject: Re: Tux Paint in Gnome? Hello Bill, I reinstalled the earlier release. I don't have much debugging experience. I can go back and look at some log files if it would help you in any way. Or I can reinstall and see if it is still happening. Let me know. John PS. Thanks for a wonderful application! On Sat, 2004-12-11 at 04:47, Bill Kendrick wrote: > Hi John, this is Bill Kendrick, author of Tux Paint. > > Did you ever find out why, and/or solve, the problem where Tux Paint was > crashing your Gnome panel? > (See: http://www.redhat.com/archives/k12osn/2004-October/msg00555.html ) > > Thanks! > -bill! [EMAIL PROTECTED] Have I been helpful? http://newbreedsoftware.com/http://svcs.affero.net/rm.php?r=billkendrick ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, Dec 12, 2004 at 08:53:55PM -0500, Albert Cahalan wrote:
> That goto should almost never execute. When it does,
> the stamp is a poor candidate for tinting and ought
> to be fixed. (thus the warning I had added about the
> fall-back processing -- did that actually print???)
Not that I ever saw. Though I may not have been looking.
But, then, Tux Paint's pretty quite on the printf() front, so you'd
/think/ I'd notice it. :^)
> 1. The usage of mixed tabs as spaces prevents me from
>using a block indent command. (^K-,) Either spaces
>or tabs would be fine, but not mixed.
I blame VIM! Damned thing!!! I used to use only emacs, but have
been finding VI varients load a LOT quicker, plus take the least effort
to get syntax highlighting going. Beyond that, though, it's actually quite
a pain in the butt to use.
Maybe we should throw the code through prettyprint or something?
> 2. The indentation of '}' breaks autoindent. My editor
>does not contain a whole figgin LISP interpreter and
>a LISP compiler and LISP libraries and a kitchen sink.
>BTW, this also causes the human to make many errors.
Can you explain this one? Do you mean the Emacs style of this:
if (blah)
..{
stuff();
..}
If so, then yeah... it's a pain when PARTS of the code is indented
like that, and others are indented in the more standard way:
if (blah)
{
..stuff();
}
> Basically, I am unable to change the indent level.
> The coding features of my editor work great on just
> about any style except the one used by Tux Paint.
> I feel like I'm using notepad.exe, though I'm not.
Sorry.
> I think /usr/src/linux/Documentation/CodingStyle is sane,
> even though it isn't my favorite. You need this for it:
>
> (defun linux-c-mode ()
> "C mode with adjusted defaults for use with the Linux kernel."
> (interactive)
> (c-mode)
> (c-set-style "K&R")
> (setq tab-width 8)
> (setq indent-tabs-mode t)
> (setq c-basic-offset 8))
Before I delve back into an Emacs environment, I'll see how painful
a post-processing would be with prettyprint or something similar, just
to get some 'cleaner' looking code into CVS.
Also, way down at the end of the to-do-list in my brain is a note to
break tuxpaint.c up into sane pieces. It wasn't a big deal when the code
was only ~2000 lines long, but now that it's reaching 15,000 it's getting
a little insane. (I can still navigate the code with relative ease... it
just takes far longer to compile than it should.)
We both need newer PCs. :^) Where are the grants, these days, anyway!? ;^)
-bill!
[EMAIL PROTECTED] Have I been helpful?
http://newbreedsoftware.com/http://svcs.affero.net/rm.php?r=billkendrick
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, 2004-12-12 at 18:26, Bill Kendrick wrote: > I see what's happening. "i" drops down to zero, but you've got a > "goto" in there which jumps back up. That goto should almost never execute. When it does, the stamp is a poor candidate for tinting and ought to be fixed. (thus the warning I had added about the fall-back processing -- did that actually print???) > Can we get rid of the goto? It's difficult work. Since my machine is slow, I don't use emacs. I use joe, which is like WordStar. Two things about the coding style are very hostile to my editor: 1. The usage of mixed tabs as spaces prevents me from using a block indent command. (^K-,) Either spaces or tabs would be fine, but not mixed. 2. The indentation of '}' breaks autoindent. My editor does not contain a whole figgin LISP interpreter and a LISP compiler and LISP libraries and a kitchen sink. BTW, this also causes the human to make many errors. Basically, I am unable to change the indent level. The coding features of my editor work great on just about any style except the one used by Tux Paint. I feel like I'm using notepad.exe, though I'm not. I think /usr/src/linux/Documentation/CodingStyle is sane, even though it isn't my favorite. You need this for it: (defun linux-c-mode () "C mode with adjusted defaults for use with the Linux kernel." (interactive) (c-mode) (c-set-style "K&R") (setq tab-width 8) (setq indent-tabs-mode t) (setq c-basic-offset 8)) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.216, 1.217
On Mon, Dec 13, 2004 at 01:25:09AM +, Albert Cahalan wrote: > Update of /cvsroot/tuxpaint/tuxpaint/src > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4886/src > > Modified Files: > tuxpaint.c > Log Message: > no need to assign twice Err.. uhh... src/tuxpaint.c: In function `find_most_saturated': src/tuxpaint.c:3581: error: `i' undeclared (first use in this function) ;) -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, 2004-12-12 at 18:26, Bill Kendrick wrote:
> So okay, I'm seriously confused. How did moving i-- cause an array overrun?
>
>
> This code is crashing for me:
>
> while (i--)
> {
> mc = work + i;
If you have N items and need 0-based access to them,
the "while(N--)" loop is a nice idiom for handling
the problem.
When you moved the i-- past the assignment of mc, the
values assigned to mc become 1-based instead of 0-based.
Add -lefence to your compiler flags to link in Electric
Fence if you want to reliably see the problem.
Valgrind would be even better.
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] Tux Paint Commits list archive
The tuxpaint-commits list seems to have gotten picked up by The Mail Archive,
so I added 'archive' links to it on the Tux Paint website ("Lists" page).
For example:
http://www.mail-archive.com/tuxpaint-commits%40tux4kids.net/msg01802.html
;)
-bill!
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, Dec 12, 2004 at 03:26:16PM -0800, Bill Kendrick wrote: > > Can we get rid of the goto? > Okay, I just added a simple patch that restores "i" to the original incoming value before starting the while() loop over (which happens via the goto) Let me know if this works for you, Albert! -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, Dec 12, 2004 at 03:05:43PM -0800, Bill Kendrick wrote:
> On Sun, Dec 12, 2004 at 07:38:48PM +, Albert Cahalan wrote:
> > Update of /cvsroot/tuxpaint/tuxpaint/src
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25817/src
> >
> > Modified Files:
> > tuxpaint.c
> > Log Message:
> > moving i-- caused an array overrun w/ SIGSEGV
>
> 8^[
>
> And now tinting stamps crashes again! We need to look into this
> more closely, I guess...
So okay, I'm seriously confused. How did moving i-- cause an array overrun?
This code is crashing for me:
while (i--)
{
mc = work + i;
// if not in the first range, and not in the second range, skip this one
//
if ((mc->huehue>upper_hue_1) &&
(mc->huehue>upper_hue_2))
continue;
if(mc->sat > max_sat)
{
max_sat = mc->sat;
key_color_ptr = mc;
}
}
I see what's happening. "i" drops down to zero, but you've got a
"goto" in there which jumps back up.
Since "while (i--)" (with "i == 0", where "i" is an unsigned int)
ends up being 'true' ("i" becomes a very large number), the loop gets
executed again, with a bogus value for "i".
Can we get rid of the goto?
-bill!
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.212, 1.213
On Sun, Dec 12, 2004 at 08:10:27PM +, Albert Cahalan wrote: > Log Message: > neaten up LOW_QUALITY_STAMP_OUTLINE support and make outlines > flip/mirror/resize again Heh, whoops. Talk about 'rigorous' testing. Sorry. I've been coding late at night lately. :^( -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, Dec 12, 2004 at 07:38:48PM +, Albert Cahalan wrote: > Update of /cvsroot/tuxpaint/tuxpaint/src > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25817/src > > Modified Files: > tuxpaint.c > Log Message: > moving i-- caused an array overrun w/ SIGSEGV 8^[ And now tinting stamps crashes again! We need to look into this more closely, I guess... -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
Awesome! Can we 'backport' the fix to Tux Paint 0.9.14 and release a Mac OS X version? I'd rather do that, then wait until 0.9.15 is settled, since so many Mac users have been asking me where the new Tux Paint is, and the latest out there is still 0.9.12! :^) (Martin, you can also take the small tweak I did last night to help the "tiny" mouse pointer shape. :^) ) Thanks! I'd be happy to just take the 0.9.14 source tar.gz and edit it and send it to you. :^) Sure, send me an updated 0.9.14 source tarball with your cursor changes and Albert's fixes, and I'll get the new Mac OS X package ready today. By the way, where can I browse through previous commits? I notice there is no tuxpaint-commits archive. Martin ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Sun, Dec 12, 2004 at 09:04:10AM -0500, Albert Cahalan wrote: > What compiler do you use? I hope it's 3.3 at least. gcc (GCC) 3.3.4 (Debian 1:3.3.4-13) -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] alpha generation program
I added a new mode especially for pure light sources,
such as fire against a black background. I added a
new mode for compositing a test image with your choice
of foreground, background, and alpha. I improved the
handling of tiny values, reducing the crazy colors.
There's a new -T option that sets a cut-off for what
is considered tiny; I used 29 for the palm tree.
Basic usage remains the same: make your best attempt
at editing away the foreground, do the same for the
background (weird, I know), and then feed *.ppm images
into the program. You'll get alpha as a *.pgm image.
Edit that, feed it back into the program, and you'll
get an improved foreground image. Repeat as desired.
For the final *.png file, use pnmtopng:
pnmtopng -force -alpha a.pgm f.ppm > stamp.ppm
Anybody using this tool?
/
//
///
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/
static void usage(const char *s, int code, int err){
if(s){
if(err){
perror(s);
}else{
fprintf(stderr, "Error: %s\n", s);
}
}
fprintf(stderr, "Usage:\n"
" ./a.out -b background.ppm -o original.ppm -f foreground.ppm >
alpha.pgm\n"
" ./a.out -b background.ppm -o original.ppm -a editedalpha.pgm -f
foreground.ppm > newforeground.ppm\n"
" ./a.out -b background.ppm -o original.ppm -a editedalpha.pgm >
newforeground.ppm\n"
" ./a.out -b background.ppm -f newforeground.ppm -a editedalpha.pgm >
likeoriginal.ppm\n"
" ./a.out -b background.ppm -o fire-like-original.ppm > foreground.ppm\n"
);
exit(code);
}
/
static unsigned width, height;
#define TYPE_PGM '5'
#define TYPE_PPM '6'
//
// quick hack reader for binary P*M files
static unsigned char *readpnm(const char *name, int desired){
int fd = open(name, O_RDONLY);
if(fd<3) usage("fd open failure",80,1);
char *cp;
int type;
struct stat sbuf;
fstat(fd, &sbuf);
cp = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, fd, 0);
if(cp==MAP_FAILED) usage("mmap failure",81,1);
close(fd);
if(cp[0] != 'P') exit(7);
type = cp[1];
if(type != TYPE_PGM && type != TYPE_PPM) exit(56);
cp += 2;
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
width = strtoul(cp, &cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
height = strtoul(cp, &cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
if(strtoul(cp, &cp, 10)!=255) exit(33);
cp++;
if(type==desired)
return cp;
if(type==TYPE_PPM && desired==TYPE_PGM){
// let'd pick the red channel
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
data[i] = cp[i*3];
}
return data;
}
if(type==TYPE_PGM && desired==TYPE_PPM){
unsigned i = width*height;
unsigned char *data = mmap(0, i*3, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
unsigned char tmp = cp[i];
data[i*3+0] = tmp;
data[i*3+1] = tmp;
data[i*3+2] = tmp;
}
return data;
}
exit(93);
}
// This goes from 8-bit sRGB (range 0 to 255) to linear (range 0 to 1).
// The math to produce a table entry:
//tmp = oldvalue / 255.0;
//result = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
static const float sRGB_to_linear_table[256] = {
0.00, 0.000304, 0.000607, 0.000911, 0.001214, 0.001518, 0.001821,
0.002125, 0.002428, 0.002732, 0.003035, 0.003347, 0.003677, 0.004025,
0.004391, 0.004777, 0.005182, 0.005605, 0.006049, 0.006512, 0.006995,
0.007499, 0.008023, 0.008568, 0.009134, 0.009721, 0.010330, 0.010960,
0.011612, 0.012286, 0.012983, 0.013702, 0.01, 0.015209, 0.015996,
0.016807, 0.017642, 0.018500, 0.019382, 0.020289, 0.021219, 0.022174,
0.023153, 0.024158, 0.025187, 0.026241, 0.027321, 0.028426, 0.029557,
0.030713, 0.031896, 0.033105, 0.034340, 0.035601, 0.036889, 0.038204,
0.039546, 0.040915, 0.042311, 0.043735, 0.045186, 0.046665, 0.048172,
0.049707, 0.051269, 0.052861, 0.054480, 0.056128, 0.057805, 0.059511,
0.061246, 0.063010, 0.064803, 0.066626, 0.068478, 0.070360, 0.072272,
0.074214, 0.076185, 0.078187, 0.080220, 0.082283, 0.084376, 0.086500,
0.088656, 0.090842, 0.093059, 0.095307, 0.097587, 0.099899, 0.102242,
0.104616, 0.107023, 0.109462, 0.111932, 0.114435, 0.116971, 0.119538,
0.122139, 0.124772, 0.127438, 0.130136, 0.132868, 0.135633, 0.138432,
0.141263, 0.144128, 0.1470
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Sun, 2004-12-12 at 05:07, Bill Kendrick wrote: > On Fri, Dec 10, 2004 at 07:33:12AM -0500, Albert Cahalan wrote: > > It's not crashing here. Type of crash? > > (SIGKILL, SIGFPE, SIGSEGV, SIGBUS...) > > Sigsegv. I think my gcc didn't like "while (i--)" or something? > (or maybe there was a double free()... i wasn't debugging it very > professionally ;^) ) > > anyway, seems fixed and works fine now! What compiler do you use? I hope it's 3.3 at least. Random code tweaks are unreliable and unsafe. BTW, some of the stuff you found odd: Declaring variables right before use is less error-prone. If you declare them at the top of the function and then share them, the compiler is less able to correctly warn about uninitialized variables. (the variables might be initialized for one use, but not for later uses) Considering these: work = malloc(sizeof *work * width * height); work = malloc(sizeof(multichan) * width * height); In general, the "sizeof *work" one is safer. If the data type is ever changed, the "sizeof(multichan)" one breaks. I didn't check free() because: 1. Linux generally won't return an error anyway; the kernel will send SIGKILL if it can not provide the memory. (this is configurable, to satisfy financial institutions) 2. There is no reasonable way to handle the error. Calling exit() is really just a crash. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Fri, Dec 10, 2004 at 07:33:12AM -0500, Albert Cahalan wrote: > It's not crashing here. Type of crash? > (SIGKILL, SIGFPE, SIGSEGV, SIGBUS...) Sigsegv. I think my gcc didn't like "while (i--)" or something? (or maybe there was a double free()... i wasn't debugging it very professionally ;^) ) anyway, seems fixed and works fine now! I'm beginning to reconsider having a Mac OS X 0.9.14 backport, and just going ahead with a 0.9.15 release this month. Does that seem too soon? :^) (back the day, before we were using CVS, I was releasing on a weekly basis!) -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
