I'm not sure if this is the right place to post about it, as I think that Javascript code is correct, maybe it is a bug in the Javascript interpreter.

The problem is that since upgraded to lastest build Synchronet (3.15 I think). Bullseye doesn't seem to be working rightly. Whatevet I select a bulletin to display it says "Invalid bulletin number". I switched the Bullseye program from the Baja one to the Javascript version, as I understand js better and could take a look to the code (the problem was still there, no matter the switch).

It looks like the problem is related to the File.position property, at lines 41 and 42:

mode=file.readln();
filepos=file.position;

The former reads the first line of bullseye.cfg correctly, retrieving the number stored there, but them for some strange reason, the latter line stores in filepos the number -4. Being file.position the offset in bytes of the file and as the first line is just a character (4 bytes), it doesn't make much sense to be "-4", it should be "4". From that point the program won't work correctly as it will never enter in the loop:

file.position=filepos; // file.position=-4
i=0;
while((str=file.readln())!=null) {

If I change the first line with this one:

file.position=4;

The Bullseye starts working again as it should. So I think that it could be something wrong in the file seeking functions.

I don't know if this is a bug, but it's actually so weird.

Saludos,
Carlos

HispaMSX BBS
Fidonet: 2:345/111
Redes integradas: HispaMSX, Fidonet, DOVE-Net


---
■ Synchronet ■ HISPAMSX

Re: Bug related to Bullseye bulletin board?
By: Karloch to All on Sun Oct 26 2008 12:20 pm

I'm not sure if this is the right place to post about it, as I think that Javascript code is correct, maybe it is a bug in the Javascript
interpreter.

The problem is that since upgraded to lastest build Synchronet (3.15 I think). Bullseye doesn't seem to be working rightly. Whatevet I select a bulletin to display it says "Invalid bulletin number". I switched the Bullseye program from the Baja one to the Javascript version, as I understand js better and could take a look to the code (the problem was still there, no matter the switch).

It looks like the problem is related to the File.position property, at
lines 41 and 42:

mode=file.readln();
filepos=file.position;

The former reads the first line of bullseye.cfg correctly, retrieving the number stored there, but them for some strange reason, the latter line stores in filepos the number -4. Being file.position the offset in bytes of the file and as the first line is just a character (4 bytes), it doesn't make much sense to be "-4", it should be "4". From that point the program won't work correctly as it will never enter in the loop:

file.position=filepos; // file.position=-4
i=0;
while((str=file.readln())!=null) {

If I change the first line with this one:

file.position=4;

The Bullseye starts working again as it should. So I think that it could be something wrong in the file seeking functions.

I don't know if this is a bug, but it's actually so weird.

It sounds like a bug, but I haven't been able to reproduce it here. What are the contents of your bullseye.cfg file?

If the first line is a single digit (e.g. 0), that should normally be 3 characters (3<CR><LF>), not 4. Maybe you could e-mail me your bullseye.cfg file as an attachment and I'll see if I can reproduce it here.

digital man (xbox-live: digitlman)

Snapple "Real Fact" #146:
The smallest county in America is New York County, better known as Manhattan. Norco, CA WX: 70.3°F, 62% humidity, 0 mph E wind, 0.00 inches rain/24hrs

Re: Bug related to Bullseye bulletin board?
By: Digital Man to Karloch on Fri Oct 31 2008 12:18:50

It sounds like a bug, but I haven't been able to reproduce it here. What
are the contents of your bullseye.cfg file?

I emailed you my bullseye.cfg file. It's not different from the standard one.

If the first line is a single digit (e.g. 0), that should normally be 3 characters (3<CR><LF>), not 4. Maybe you could e-mail me your bullseye.cfg file as an attachment and I'll see if I can reproduce it here.

You're right, so the file.filepos should be 12 (3 characters * 4 bytes = +12 bytes offset). Even so, it does not make any sense to be -4.


Saludos,
Carlos

HispaMSX BBS
Fidonet: 2:345/111
Redes integradas: HispaMSX, Fidonet, DOVE-Net

---
■ Synchronet ■ HISPAMSX

Re: Bug related to Bullseye bulletin board?
By: Karloch to Digital Man on Sat Nov 01 2008 07:35 pm

Re: Bug related to Bullseye bulletin board?
By: Digital Man to Karloch on Fri Oct 31 2008 12:18:50

It sounds like a bug, but I haven't been able to reproduce it here. What are the contents of your bullseye.cfg file?

I emailed you my bullseye.cfg file. It's not different from the standard one.

Hm... What's the length of the file (in bytes)? I didn't receive the e-mail.

If the first line is a single digit (e.g. 0), that should normally be 3 characters (3<CR><LF>), not 4. Maybe you could e-mail me your bullseye.cfg file as an attachment and I'll see if I can reproduce it here.

You're right, so the file.filepos should be 12 (3 characters * 4 bytes =
+12 bytes offset). Even so, it does not make any sense to be -4.

4 bytes per character? No, it's ASCII - one byte per character, so after reading 3<CR><LF>, the file position should be 3. Unless you converted it to UTF-32?

digital man (xbox-live: digitlman)

Snapple "Real Fact" #12:
Emus and Kangaroos cannot walk backwards.
Norco, CA WX: 59.3°F, 76% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

Re: Bug related to Bullseye bulletin board?
By: Digital Man to Karloch on Sun Nov 02 2008 21:48:16

Hm... What's the length of the file (in bytes)? I didn't receive the
e-mail.

I tried to email the file to you, but your mail server keeps rejecting my messaage (I was using your address at www.synchro.net).

Anyway, I solved the mistery. It turned out to not be a bug, I'll explain...

4 bytes per character? No, it's ASCII - one byte per character, so after reading 3<CR><LF>, the file position should be 3. Unless you converted it
to UTF-32?

You're absolutely right: it's 1 byte/char. I was afraid my text editor switched the format from ANSI to UTF-8, but that was not the case. The <CR><LF> you put turned on my alarms.

Last summer I migrated my BBS from Synchronet/Linux to Synchronet/Win32. The process was smooth, but some things remain in Unix format. The bullseye.cfg was ANSI Unix, using just <LF> as endline char, not the <CR><LF> from DOS. This was the thing confusing the program. As soon as I converted the file to DOS format the bulletin started working again.

A question about Unix->Win32 migration, is it necessary to switch the path backslash from "/" to "\" in every path specified at the SCFG utility? What about configuration files?


Saludos,
Carlos

HispaMSX BBS
Fidonet: 2:345/111
Redes integradas: HispaMSX, Fidonet, DOVE-Net

---
■ Synchronet ■ HISPAMSX

Re: Bug related to Bullseye bulletin board?
By: Karloch to Digital Man on Tue Nov 04 2008 12:12 am

Re: Bug related to Bullseye bulletin board?
By: Digital Man to Karloch on Sun Nov 02 2008 21:48:16

Hm... What's the length of the file (in bytes)? I didn't receive the e-mail.

I tried to email the file to you, but your mail server keeps rejecting my messaage (I was using your address at www.synchro.net).

Anyway, I solved the mistery. It turned out to not be a bug, I'll
explain...

4 bytes per character? No, it's ASCII - one byte per character, so after reading 3<CR><LF>, the file position should be 3. Unless you converted
it to UTF-32?

You're absolutely right: it's 1 byte/char. I was afraid my text editor switched the format from ANSI to UTF-8, but that was not the case. The <CR><LF> you put turned on my alarms.

Last summer I migrated my BBS from Synchronet/Linux to Synchronet/Win32.
The process was smooth, but some things remain in Unix format. The bullseye.cfg was ANSI Unix, using just <LF> as endline char, not the <CR><LF> from DOS. This was the thing confusing the program. As soon as I converted the file to DOS format the bulletin started working again.

Ah, that makes sense. It was probably reading the entire file in that first file.readln() call then.

A question about Unix->Win32 migration, is it necessary to switch the path backslash from "/" to "\" in every path specified at the SCFG utility? What about configuration files?

No, forward slash works fine on Win32.

digital man (xbox-live: digitlman)

Snapple "Real Fact" #14:
Camel's milk does not curdle.
Norco, CA WX: 63.6°F, 65% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs