Hi ALL,
I tried to post a regular diff of this, but it was too messed up at 80 char, so here's the hand method:
IN bulleye.js REPLACE THIS:
if(str.search(/\.htm/)!=-1)
bbs.exec("?typehtml -color "+str);
else
bbs.exec("?typeasc "+str+" BullsEye Bulletin #"+b);

WITH THIS:
if(html) { // if the user can do html
if(str.search(/\.htm/)!=-1) // and the file is html then
console.printfile(fname); // just give it to them
else // otherwise convert from CTRL-A to HTML
bbs.exec("?typeasc "+str+" BullsEye Bulletin #"+b);
}
else { // if the user can't do html
if(str.search(/\.htm/)!=-1) // but that's what the file is
bbs.exec("?typehtml -color "+str); // convert it
else // otherwise just give it to them
console.printfile(fname);
}

IN typehtml.js ADD THE FOLOWING:
load("sbbsdefs.js"); // USER_HTML

I've found that using elinks --dump (on linux) outputs a very nice looking formatted ASCII from an HTML file, BTW.
-j-

---
■ Synchronet ■ Delbert's Place BBS | telnet://delberts.audizar.com

Re: bullseye.js PATCH
By: Delbert to All on Wed Aug 15 2007 02:37 pm

Hi ALL,
I tried to post a regular diff of this, but it was too messed up at 80 char, here's the hand method:
IN bulleye.js REPLACE THIS:

WITH THIS:

... and why? :-)

digital man (xbox-live: digitlman)

Snapple "Real Fact" #91:
There are more telephones then people in Washington D.C.
Norco, CA WX: 91.2°F, 31% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

Re: bullseye.js PATCH
By: Digital Man to Delbert on Wed Aug 15 2007 19:05:00

WITH THIS:

... and why? :-)

As it was it converted to HTML no matter what. Very unattractive on the ANSI TERM. It looks like Deuce is headed toward HTML capability in syncTERM with USER_HTML and ?HTML? in answer.c. I got the impression he just wasn't quite done with the checking done in bullseye.js.

The patch in typehtml.js fixes the "not defined" for USER_HTML.

I uploaded both as diff to your sysop uploads.

Please keep up the good work.
-j-

---
■ Synchronet ■ Delbert's Place BBS | telnet://delberts.audizar.com

Re: bullseye.js PATCH
By: Delbert to Digital Man on Wed Aug 15 2007 10:15 pm

Re: bullseye.js PATCH
By: Digital Man to Delbert on Wed Aug 15 2007 19:05:00

WITH THIS:

... and why? :-)

As it was it converted to HTML no matter what. Very unattractive on the ANSI TERM.

I agree, but the reason for that appears to be this line in typeasc.js:

if(1 || (user.settings & USER_HTML)) {

Removing the "1 ||" should fix it.

digital man (xbox-live: digitlman)

Snapple "Real Fact" #178:
The first ballpoint pens were sold in 1945 for $12.00
Norco, CA WX: 80.4°F, 41% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

Re: bullseye.js PATCH
By: Digital Man to Delbert on Wed Aug 15 2007 22:51:00

As it was it converted to HTML no matter what. Very unattractive on the A TERM.

I agree, but the reason for that appears to be this line in typeasc.js:

if(1 || (user.settings & USER_HTML)) {

Removing the "1 ||" should fix it.

I was wondering what he was doing there. ;) Thanks for the fix.
-j-

---
■ Synchronet ■ Delbert's Place BBS | telnet://delberts.audizar.com

Re: bullseye.js PATCH
By: Delbert to Digital Man on Thu Aug 16 2007 01:50:38

Removing the "1 ||" should fix it.

I was wondering what he was doing there. ;) Thanks for the fix.
-j-

Oh, but wait a minute, when you instead now use load() in bullseye.js, doesn't that include typeasc.js in the same scope? I think that corrputs your "i" in bullseye.js after that, and also fails to actually load subsequent menu requests because your "f" is always already declared after the first selection.

I'm sending you a diff that fixes it, but I'm sure you'll code the actual fix more to your liking. ;)
-j-

---
■ Synchronet ■ Delbert's Place BBS | telnet://delberts.audizar.com

Re: bullseye.js PATCH
By: Delbert to Digital Man on Thu Aug 16 2007 05:07:08

I'm sending you a diff that fixes it, but I'm sure you'll code the actual fi more to your liking. ;)
-j-

Also, it probably breaks typehtml.js the same way.
-j-

---
■ Synchronet ■ Delbert's Place BBS | telnet://delberts.audizar.com

Re: bullseye.js PATCH
By: Delbert to Digital Man on Thu Aug 16 2007 05:07 am

Re: bullseye.js PATCH
By: Delbert to Digital Man on Thu Aug 16 2007 01:50:38

Removing the "1 ||" should fix it.

I was wondering what he was doing there. ;) Thanks for the fix.
-j-

Oh, but wait a minute, when you instead now use load() in bullseye.js, doesn that include typeasc.js in the same scope? I think that corrputs your "i" in bullseye.js after that, and also fails to actually load subsequent menu requests because your "f" is always already declared after the first selecti

I'm sending you a diff that fixes it, but I'm sure you'll code the actual fi more to your liking. ;)

It's working here on Vertrauen just fine. Are you actually having a problem?

digital man (xbox-live: digitlman)

Snapple "Real Fact" #158:
The first MTV video was "Video Killed the Radio Star," by the Buggles.
Norco, CA WX: 91.7°F, 40% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

Re: bullseye.js PATCH
By: Delbert to Digital Man on Thu Aug 16 2007 05:07 am

I'm sending you a diff that fixes it, but I'm sure you'll code the actual fi more to your liking. ;)

Nothing personal. :-)

digital man (xbox-live: digitlman)

Snapple "Real Fact" #132:
A crocodile cannot move its tongue.
Norco, CA WX: 94.8°F, 38% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

Re: bullseye.js PATCH
By: Digital Man to Delbert on Thu Aug 16 2007 11:44:00

It's working here on Vertrauen just fine. Are you actually having a problem?

Yes, after installing the fix, it looks like it's working at first, but actually it only displays the first menu you select. IOW, you pick #3, read it, go back to menu and pick #1, and it just shoes you #3 again, until you exit bullseye, and rerun it.

Whatever the first choice is gets a file descripter in typeasc.js, and subsequent menu choices fail the if test so the new filename doesn't get a new fd after that.

That, and the "i" from bullseye.js gets changed to a 0 in typeasc.js when implictly defined in the while(). Using load() puts both "i"s into the same scope because neither is in a function or anything... changing the "i" in typeasc.js to a "j" fixes that. You can see this in the log when it shows that the user chose #1, no matter what they really chose. The #1 is "i" after being made a 0 and then going through the while loop in typeasc.js once.

The diff I sent you illustrates this, I think.

Rob, the diffs I send are more to illustrate the problem than they are to represent replacement code. That's all I meant when I said you'd probably want to code the real fix your own way. ;) (I put the darn smily thing on there;)

To duplicate this bug, tail the log, go to bullseye.js, select #4, read it, then return to the menu and select anything but #4. You will get #4 again, adn the log will say you looked at #1 both times.

You're sure you're not using bullseye.bin? ;)

-j-

---
■ Synchronet ■ Delbert's Place BBS | telnet://delberts.audizar.com

Re: bullseye.js PATCH
By: Delbert to Digital Man on Thu Aug 16 2007 04:11 pm

You're sure you're not using bullseye.bin? ;)

Yup, I'm sure. I committed the fix already, which loads()s the type*.js files in their own context/scope.

digital man (xbox-live: digitlman)

Snapple "Real Fact" #158:
The first MTV video was "Video Killed the Radio Star," by the Buggles.
Norco, CA WX: 97.5°F, 30% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs