• Javascript weirdness

    From deon@VERT/ALTERANT to All on Sunday, April 17, 2022 20:21:22
    Howdy,

    Hoping somebody could help me understand something unusual that's happening wth Javascript. I think it's a bug, but who knows somebody might see the err of my ways.

    I have created an object "MsgArea" which represents a message area and the ability to get a list of "tagged" messages and "untagged" messages.

    Here is the relevant part of the object:

    ====
    function MsgArea() {
    this.msgbase = undefined;
    this.headers = undefined;
    this.tagged_list = undefined;
    this.untagged_list = undefined;

    const PAGE_LENGTH = 4; // The size of our page tag.
    const PAGE_LAST_KEY = 'last_page';

    Object.defineProperty(this,'code',{
    set: function(code) {
    this.msgbase = new MsgBase(code);

    if (! this.msgbase.open('r')) {
    writeln(ma.areas[i].code+' cannot be opened?');
    exit(2);
    }

    this.headers = this.msgbase.get_all_msg_headers(false,false);
    this.msgbase.close();
    }
    });

    // Total tagged messages
    Object.defineProperty(this,'list_tagged',{
    get: function() {
    if (this.tagged_list === undefined) {
    this.tagged_list = [];

    if (! this.headers)
    return this.tagged_list;

    for(var x in this.headers) {
    if (this.headers[x].tags && (this.headers[x].tags.length === PAGE_LENGTH)) {
    this.tagged_list.push(this.headers[x]);
    write(); // Needed else this is not working?
    }
    }
    }

    return this.tagged_list;
    }
    });
    ====

    I'm seeing two problems:

    1)

    If I use:
    var x = new MsgArea();
    x.code = 'PVT_TEST';
    writeln('Tagged Messages: '+x.list_tagged.length);

    It reports 36 (which is correct). If I comment out the "write()" in the function list_tagged, it reports 25. Why? (And I have confirmed that 23 of the 25 do have a "tags" header.)

    2)

    The other 2 messages of the 25 I cannot set a "tags" value in the header - the function put_msg_header() returns an error, but no details.

    Here is one of those message headers (in which I set the tags header to "1829"):

    {"number":27,"tags":"1829","to":"Clearing Houz","subject":"Address Link Code","from":"Hub Robot","from_net_type":2,"from_net_addr":"10:1/1","id":"<625A907B.27.pvt_test@mybbs.com>","ftn_area":"PVT_TEST","date":"Fri, 25 Mar 2022 11:05:08 +1100","attr":0,"votes":0,"auxattr":0,"netattr":0,"when_written_time":1648166708,"when_written_zone":660,"when_imported_time":1650102395,"when_imported_zone":0,"thread_id":27,"thread_next":0,"thread_first":0,"delivery_attempts":0,"field_list":[{"type":160,"data":"RESCANNED 10:1/1@private"},{"type":162,"data":"1/1 998"},{"type":163,"data":"1/1"}],"offset":26,"type":0,"version":768,"when_written_zone_offset":660,"when_imported_zone_offset":0,"thread_back":0,"data_length":869,"text_length":869,"upvotes":0,"downvotes":0,"total_votes":0,"is_utf8":0,"can_read":true}

    Why does the update header error?


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Sunday, April 17, 2022 17:02:10
    Re: Javascript weirdness
    By: deon to All on Sun Apr 17 2022 08:21 pm

    Howdy,

    Hoping somebody could help me understand something unusual that's happening wth Javascript. I think it's a bug, but who knows somebody might see the err of my ways.

    I have created an object "MsgArea" which represents a message area and the ability to get a list of "tagged" messages and "untagged" messages.

    Here is the relevant part of the object:

    ====
    function MsgArea() {
    this.msgbase = undefined;
    this.headers = undefined;
    this.tagged_list = undefined;
    this.untagged_list = undefined;

    const PAGE_LENGTH = 4; // The size of our page tag.
    const PAGE_LAST_KEY = 'last_page';

    Object.defineProperty(this,'code',{
    set: function(code) {
    this.msgbase = new MsgBase(code);

    if (! this.msgbase.open('r')) {

    What significance is this 'r'? I don't think that'll have any effect.

    writeln(ma.areas[i].code+' cannot be opened?');

    'ma' and 'i' don't appear to be defined in this scope. I don't this error handler is going to execute as intended.

    exit(2);
    }

    this.headers = this.msgbase.get_all_msg_headers(false,false);
    this.msgbase.close();
    }
    });

    // Total tagged messages
    Object.defineProperty(this,'list_tagged',{
    get: function() {
    if (this.tagged_list === undefined) {
    this.tagged_list = [];

    if (! this.headers)
    return this.tagged_list;

    for(var x in this.headers) {
    if (this.headers[x].tags && (this.headers[x].tags.length === PAGE_LENGTH)) {
    this.tagged_list.push(this.headers[x]);
    write(); // Needed else this is not working?

    That's pretty strange.

    }
    }
    }

    return this.tagged_list;
    }
    });
    ====

    I'm seeing two problems:

    1)

    If I use:
    var x = new MsgArea();
    x.code = 'PVT_TEST';
    writeln('Tagged Messages: '+x.list_tagged.length);

    It reports 36 (which is correct). If I comment out the "write()" in the function list_tagged, it reports 25. Why? (And I have confirmed that 23 of the 25 do have a "tags" header.)

    Woudn't 23 be the right answer then?


    2)

    The other 2 messages of the 25 I cannot set a "tags" value in the header - the function put_msg_header() returns an error, but no details.

    If put_msg_header() returns false, the details will be contained in MsgBase.error and MsgBase.status. Check/log those property values upon error.

    Here is one of those message headers (in which I set the tags header to "1829"):

    {"number":27,"tags":"1829","to":"Clearing Houz","subject":"Address Link Code","from":"Hub Robot","from_net_type":2,"from_net_addr":"10:1/1","id":"<625A 907B.27.pvt_test@mybbs.com>","ftn_area":"PVT_TEST","date":"Fri, 25 Mar 2022 11:05:08 +1100","attr":0,"votes":0,"auxattr":0,"netattr":0,"when_written_time": 16481 66708,"when_written_zone":660,"when_imported_time":1650102395,"when_import e d_zone":0,"thread_id":27,"thread_next":0,"thread_first":0,"delivery_attempts ": 0,"field_list":[{"type":160,"data":"RESCANNED 10:1/1@private"},{"type":162,"data":"1/1 998"},{"type":163,"data":"1/1"}],"offs et":26,"type":0,"version":768,"when_w ritten_zone_offset":660,"when_imported_zon e_offset":0,"thread_back":0,"data _length":869,"text_length":869,"upvotes":0,"do wnvotes":0,"total_votes":0,"is_utf8":0,"can_read":true}

    Why does the update header error?

    The error/status MsgBase property values will tell you why.
    --
    digital man (rob)

    Rush quote #11:
    Struck between the eyes by the big time world, walking uneasy streets
    Norco, CA WX: 74.4F, 46.0% humidity, 7 mph SSE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Monday, April 18, 2022 11:21:19
    Re: Javascript weirdness
    By: Digital Man to deon on Sun Apr 17 2022 05:02 pm

    if (! this.msgbase.open('r')) {
    What significance is this 'r'? I don't think that'll have any effect.

    Ahh thanks - I just assummed I needed to open it 'r' for read only and 'r+' for read write. I see in the spec that it doesnt take any arguments.

    writeln(ma.areas[i].code+' cannot be opened?');
    'ma' and 'i' don't appear to be defined in this scope. I don't this error handler is going to execute as intended.

    Thanks, a hang over from before it was in the object.

    write(); // Needed else this is not working?
    That's pretty strange.

    It is.

    I'm seeing this in a few places (when parsing throught the output of get_all_msg_headers(). The strange thing is, without it its reporting a different numbers of results. For example, if I'm searching for the message with tags "1826" it doesnt show unless I have the write() statement there.

    It reports 36 (which is correct). If I comment out the "write()" in the function list_tagged, it reports 25. Why? (And I have
    confirmed
    that 23 of the 25 do have a "tags" header.)

    Woudn't 23 be the right answer then?

    No - and actually a typo. In the message base, there are 38 messages. 36 are tagged (which is correct), and 2 are not (which are the two errors I referred to earlier).

    When I remove that "write()", I get a list of 15 untagged - and 13 of those 15 *do* have tags. (And if I put any debugging "write" statements to test the logic, I only get the 2.)

    The strange thing, I'm wondering if it is some memory buffer corruption. I'm sure when I started removing my writeln debug comments, that it was returning a list of 37 of 38, now it is only selecting 15 (and always the same 15).

    I'll remove some of the tags and re-add them and see what happens.

    If put_msg_header() returns false, the details will be contained in MsgBase.error and MsgBase.status. Check/log those property values
    upon error.

    Ahh thanks, I did that and it reports.
    ERROR:"smb_putmsghdr illegal header length increase: 261 (2 blocks, 11 hfields, 2 dfields) vs 253 (1 blocks)"

    And the only thing I'm doing is setting msg.tags = "xxxx" after
    a "var msg = this.msgbase.get_msg_header(msgs[x].number, /* expand: */false)"

    What's that error mean?


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Sunday, April 17, 2022 18:41:15
    Re: Javascript weirdness
    By: deon to Digital Man on Mon Apr 18 2022 11:21 am

    Re: Javascript weirdness
    By: Digital Man to deon on Sun Apr 17 2022 05:02 pm

    if (! this.msgbase.open('r')) {
    What significance is this 'r'? I don't think that'll have any effect.

    Ahh thanks - I just assummed I needed to open it 'r' for read only and 'r+' for read write. I see in the spec that it doesnt take any arguments.

    writeln(ma.areas[i].code+' cannot be opened?');
    'ma' and 'i' don't appear to be defined in this scope. I don't this error handler is going to execute as intended.

    Thanks, a hang over from before it was in the object.

    write(); // Needed else this is not working?
    That's pretty strange.

    It is.

    I'm seeing this in a few places (when parsing throught the output of get_all_msg_headers(). The strange thing is, without it its reporting a different numbers of results. For example, if I'm searching for the message with tags "1826" it doesnt show unless I have the write() statement there.

    It reports 36 (which is correct). If I comment out the "write()" in the function list_tagged, it reports 25. Why? (And I have confirmed that 23 of the 25 do have a "tags" header.)

    Woudn't 23 be the right answer then?

    No - and actually a typo. In the message base, there are 38 messages. 36 are tagged (which is correct), and 2 are not (which are the two errors I referred to earlier).

    When I remove that "write()", I get a list of 15 untagged - and 13 of those 15 *do* have tags. (And if I put any debugging "write" statements to test the logic, I only get the 2.)

    I suspect something else is afoot there.

    This method of counting/collecting messages with a 'tags' header field works for me, without any calls to write():

    var base = MsgBase(code);
    if(!base.open()) {
    alert(base.error);
    exit();
    }
    var list = base.get_all_msg_headers(false, false);
    var result = [];
    for(var i in list) {
    if(list[i].tags)
    result.push(list[i]);
    }
    print(result.length);

    The strange thing, I'm wondering if it is some memory buffer corruption. I'm sure when I started removing my writeln debug comments, that it was returning a list of 37 of 38, now it is only selecting 15 (and always the same 15).

    I'll remove some of the tags and re-add them and see what happens.

    If put_msg_header() returns false, the details will be contained in MsgBase.error and MsgBase.status. Check/log those property values upon error.

    Ahh thanks, I did that and it reports.
    ERROR:"smb_putmsghdr illegal header length increase: 261 (2 blocks, 11 hfields, 2 dfields) vs 253 (1 blocks)"

    And the only thing I'm doing is setting msg.tags = "xxxx" after
    a "var msg = this.msgbase.get_msg_header(msgs[x].number, /* expand: */false)"

    What's that error mean?

    It means the message header in question doesn't have enough enough room for expansion to accommodate your added data (tags, in this case). Headers are stored in 256-byte blocks (allocation units) and if you're trying to add data that would exceed its currently allocation (in blocks), that won't be allowed since it would overwrite the next message's header.

    Generally, message headers aren't updated/extended after the message has been added/imported, so this isn't usually a problem.
    --
    digital man (rob)

    Synchronet "Real Fact" #46:
    Synchronet External X/Y/ZMODEM protocol driver (SEXYZ) was introduced in 2005 Norco, CA WX: 69.7F, 52.0% humidity, 11 mph S wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Monday, April 18, 2022 12:42:25
    Re: Javascript weirdness
    By: Digital Man to deon on Sun Apr 17 2022 06:41 pm

    I suspect something else is afoot there.

    This method of counting/collecting messages with a 'tags' header field works for me, without any calls to write():

    Yeah for me, its not happening on every msg area - on my laptop I only have 4 or 5 with messages in (and a low number of messages), and it's only happening to this one message base.

    Generally, message headers aren't updated/extended after the message has been added/imported, so this isn't usually a problem.

    Ahh, OK so tagging messages after they are received is not guaranteed?


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Sunday, April 17, 2022 21:17:06
    Re: Javascript weirdness
    By: deon to Digital Man on Mon Apr 18 2022 12:42 pm

    Re: Javascript weirdness
    By: Digital Man to deon on Sun Apr 17 2022 06:41 pm

    I suspect something else is afoot there.

    This method of counting/collecting messages with a 'tags' header field works for me, without any calls to write():

    Yeah for me, its not happening on every msg area - on my laptop I only have 4 or 5 with messages in (and a low number of messages), and it's only happening to this one message base.

    Try using a simple script, like the one I pasted?

    Generally, message headers aren't updated/extended after the message has been added/imported, so this isn't usually a problem.

    Ahh, OK so tagging messages after they are received is not guaranteed?

    Not without some padding to accomodate the extra data having been assured to always be there. And then there would still be *some* limit to how much additional data (e.g. the length of the tags header field data) you could add. I could add an option to always pad headers for specific message bases, if this is something you need. I'm not clear on the use case. It was expected that a message author would add tags to their message at the time of posting their message, if they wanted to. Not after.
    --
    digital man (rob)

    Rush quote #73:
    He's wise enough to win the world, but fool enough to lose it ... New World Man Norco, CA WX: 60.9F, 71.0% humidity, 4 mph SSE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Monday, April 18, 2022 20:52:11
    Re: Javascript weirdness
    By: Digital Man to deon on Sun Apr 17 2022 09:17 pm

    Yeah for me, its not happening on every msg area - on my laptop I only have 4 or 5 with messages in (and a low number of messages),
    and it's only happening to this one message base.

    Try using a simple script, like the one I pasted?

    Your script is not that different to mine, but I did try it anyway in case it was the conditional handling. Still the same result :(.

    Perhaps I send you the msgbase and you see if you get the same result? It'll have some messages tagged, and the 2 that wont.

    Not without some padding to accomodate the extra data having been assured to always be there. And then there would still be *some*
    limit
    to how much additional data (e.g. the length of the tags header field data) you could add. I could add an option to always pad headers
    for
    specific message bases, if this is something you need. I'm not clear on the use case. It was expected that a message author would add
    tags
    to their message at the time of posting their message, if they wanted to. Not after.

    So my use case is for my viewdata (videotex) shell that I've been chipping away at the last year or so. With viewdata, everything is a "frame" identified by a number - ie: *642# would display page 642 to the user. My goal is that the content of frame 642 is a message in a mailbase.

    I'm also wanting to enable echomail messages to live on a static page, so for example, *10010051234# would pull out message 1234 from the zone 0010 echomail area 05. Thus as a message is tossed, a post activity would tag the next message in that echoarea as 1235, etc.

    I thought that keeping the frame numbers in the message base (via the tags attribute) was workable, since that isnt really used at all anywhere else, and I dont need to manage it outside the message base (and keep in sync with it).

    I am only aiming to add 4 bytes (a 4 digit page number), so it would be useful to pad the space to ensure that there is always room. I was going to ask if it was too hard to "relocate" the message header, if there isnt room in the current block to hold those extra 4 bytes, and the next block is occupied (not sure if that is an option).

    On a related question, if I set a message area to hold 10000 messages, and the 10001 message comes it, message 1 is eligible for deletion - how is that determined? By the lowest "number", the lowest "when_imported_time" (is "when_imported_zone_offset" considered as well?) or some other field(s).


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Monday, April 18, 2022 10:18:49
    Re: Javascript weirdness
    By: deon to Digital Man on Mon Apr 18 2022 08:52 pm

    Re: Javascript weirdness
    By: Digital Man to deon on Sun Apr 17 2022 09:17 pm

    Yeah for me, its not happening on every msg area - on my laptop I only have 4 or 5 with messages in (and a low number of messages), and it's only happening to this one message base.

    Try using a simple script, like the one I pasted?

    Your script is not that different to mine, but I did try it anyway in case it was the conditional handling. Still the same result :(.

    Perhaps I send you the msgbase and you see if you get the same result? It'll have some messages tagged, and the 2 that wont.

    Unless you use call the write() function? Yeah, please send me the message base.

    Not without some padding to accomodate the extra data having been assured to always be there. And then there would still be *some* limit
    to how much additional data (e.g. the length of the tags header field data) you could add. I could add an option to always pad headers for specific message bases, if this is something you need. I'm not clear on the use case. It was expected that a message author would add tags
    to their message at the time of posting their message, if they wanted to. Not after.

    So my use case is for my viewdata (videotex) shell that I've been chipping away at the last year or so. With viewdata, everything is a "frame" identified by a number - ie: *642# would display page 642 to the user. My goal is that the content of frame 642 is a message in a mailbase.

    I'm also wanting to enable echomail messages to live on a static page, so for example, *10010051234# would pull out message 1234 from the zone 0010 echomail area 05. Thus as a message is tossed, a post activity would tag the next message in that echoarea as 1235, etc.

    I thought that keeping the frame numbers in the message base (via the tags attribute) was workable, since that isnt really used at all anywhere else, and I dont need to manage it outside the message base (and keep in sync with it).

    I am only aiming to add 4 bytes (a 4 digit page number), so it would be useful to pad the space to ensure that there is always room. I was going to ask if it was too hard to "relocate" the message header, if there isnt room in the current block to hold those extra 4 bytes, and the next block is occupied (not sure if that is an option).

    There's a *little* more overhead than just 4 bytes (for a 4-character tag), but not a ton. You're just close to the block-boundary with some of your existing message headers already, so unlucky.

    It's not impossible to move headers upon change, but it's not something currently supported.

    On a related question, if I set a message area to hold 10000 messages, and the 10001 message comes it, message 1 is eligible for deletion - how is that determined? By the lowest "number", the lowest "when_imported_time" (is "when_imported_zone_offset" considered as well?) or some other field(s).

    The order in the index (.sid file) which is generally the lowest number and the lowest when_imported_time first. The time's stored in UTC, so no, we don't need to worry about the time zone offset when sorting.
    --
    digital man (rob)

    Sling Blade quote #6:
    Karl: he should've had a chance to grow up. He would had fun some time.
    Norco, CA WX: 63.8F, 66.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Tuesday, April 19, 2022 12:02:37
    Re: Javascript weirdness
    By: Digital Man to deon on Mon Apr 18 2022 10:18 am

    Perhaps I send you the msgbase and you see if you get the same result? It'll have some messages tagged, and the 2 that wont.

    Unless you use call the write() function? Yeah, please send me the message base.

    Thanks - I emailed it to you - please let me know if you didnt get it.

    On a related question, if I set a message area to hold 10000 messages, and the 10001 message comes it, message 1 is eligible for deletion - how is that determined? By the lowest "number", the lowest "when_imported_time" (is "when_imported_zone_offset" considered as well?) or some other field(s).

    The order in the index (.sid file) which is generally the lowest number and the lowest when_imported_time first. The time's stored in UTC, so no, we don't need to worry about the time zone offset when sorting.

    Ahh OK, and this is reported by "get_index()"? Is this already in order (ie: I dont need to pre-sort it), so for example, I can assume the "first" record would be the next candidate to be deleted if my message base had a max number of message of 10,000, and the 10,001 message was just stored in it?


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Monday, April 18, 2022 21:31:31
    Re: Javascript weirdness
    By: deon to Digital Man on Tue Apr 19 2022 12:02 pm

    Ahh OK, and this is reported by "get_index()"? Is this already in order (ie: I dont need to pre-sort it), so for example, I can assume the "first" record would be the next candidate to be deleted if my message base had a max number of message of 10,000, and the 10,001 message was just stored in it?

    Correct.
    --
    digital man (rob)

    Rush quote #43:
    Summers going fast nights growing colder children growing up old friends, older Norco, CA WX: 62.2F, 70.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to deon on Monday, April 18, 2022 21:37:09
    Re: Javascript weirdness
    By: deon to Digital Man on Tue Apr 19 2022 12:02 pm

    Re: Javascript weirdness
    By: Digital Man to deon on Mon Apr 18 2022 10:18 am

    Perhaps I send you the msgbase and you see if you get the same result? It'll have some messages tagged, and the 2 that wont.

    Unless you use call the write() function? Yeah, please send me the message base.

    Thanks - I emailed it to you - please let me know if you didnt get it.

    Has not arrived yet. <shrug>
    --
    digital man (rob)

    Synchronet "Real Fact" #126:
    Synchronet feature requests: https://gitlab.synchro.net/main/sbbs/-/issues Norco, CA WX: 62.2F, 70.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Wednesday, April 20, 2022 08:09:21
    Re: Javascript weirdness
    By: Digital Man to deon on Mon Apr 18 2022 09:37 pm

    Thanks - I emailed it to you - please let me know if you didnt get it.

    Has not arrived yet. <shrug>

    Not get it yet? I sent it to rob at synchro dot net.


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Tuesday, April 19, 2022 16:35:42
    Re: Javascript weirdness
    By: deon to Digital Man on Wed Apr 20 2022 08:09 am

    Re: Javascript weirdness
    By: Digital Man to deon on Mon Apr 18 2022 09:37 pm

    Thanks - I emailed it to you - please let me know if you didnt get it.

    Has not arrived yet. <shrug>

    Not get it yet? I sent it to rob at synchro dot net.

    Got it. I'll take a look-see.
    --
    digital man (rob)

    Synchronet/BBS Terminology Definition #30:
    FF = Form Feed (ASCII 12, Ctrl-L)
    Norco, CA WX: 70.2F, 48.0% humidity, 8 mph ESE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to deon on Tuesday, April 19, 2022 22:15:19
    Re: Javascript weirdness
    By: Digital Man to deon on Tue Apr 19 2022 04:35 pm

    Re: Javascript weirdness
    By: deon to Digital Man on Wed Apr 20 2022 08:09 am

    Re: Javascript weirdness
    By: Digital Man to deon on Mon Apr 18 2022 09:37 pm

    Thanks - I emailed it to you - please let me know if you didnt get it.

    Has not arrived yet. <shrug>

    Not get it yet? I sent it to rob at synchro dot net.

    Got it. I'll take a look-see.

    There is definitely something weird going, but you don't need to call write(). Calling any method (e.g. even yield()) seems to give a correct answer.

    I'll continue to debug further, but my first suspect is that get_all_msg_headers() method. Thanks for the report,
    --
    digital man (rob)

    Synchronet/BBS Terminology Definition #45:
    IP = Internet Protocol
    Norco, CA WX: 57.3F, 80.0% humidity, 3 mph SSW wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Wednesday, April 20, 2022 21:16:08
    Re: Javascript weirdness
    By: Digital Man to deon on Tue Apr 19 2022 10:15 pm

    I'll continue to debug further, but my first suspect is that get_all_msg_headers() method. Thanks for the report,

    No problem - glad you see it too :)

    BTW: Not sure if it is related, but is the result of get_all_msg_headers() supposed to be read-only?

    Originally I was iterating through through that result to update the messages, but I was noticing the following behaviour:

    * call get_all_msg_headers()
    * iterate through each item "for (hdr in hdrs)"
    * set hdr.tag to "foo"
    * pass hdr to put_msg_header();

    But the items were not updating.

    If, for example hdr.tag = "bar", if I had a writeln(hdr.tag) after setting it to "foo", it would report "foo". But if I JSON.stringify(hdr), the result shows that the tags field is still "bar".

    My workaround was to redo a call to "get_msg_header(hdr.number)" and use that result to update and pass back to put_msg_header(), but (IMHO) that is a waste calls (if get_all_msg_headers is not meant to be r/o)... I also tried JSON.parse(JSON.stringify(hdr)) that worked too.

    Not sure if that is related?


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Thursday, April 21, 2022 18:17:40
    Re: Javascript weirdness
    By: deon to Digital Man on Wed Apr 20 2022 09:16 pm

    Re: Javascript weirdness
    By: Digital Man to deon on Tue Apr 19 2022 10:15 pm

    I'll continue to debug further, but my first suspect is that get_all_msg_headers() method. Thanks for the report,

    No problem - glad you see it too :)

    BTW: Not sure if it is related, but is the result of get_all_msg_headers() supposed to be read-only?

    Originally I was iterating through through that result to update the messages, but I was noticing the following behaviour:

    * call get_all_msg_headers()
    * iterate through each item "for (hdr in hdrs)"
    * set hdr.tag to "foo"
    * pass hdr to put_msg_header();

    But the items were not updating.

    If, for example hdr.tag = "bar", if I had a writeln(hdr.tag) after setting it to "foo", it would report "foo". But if I JSON.stringify(hdr), the result shows that the tags field is still "bar".

    My workaround was to redo a call to "get_msg_header(hdr.number)" and use that result to update and pass back to put_msg_header(), but (IMHO) that is a waste calls (if get_all_msg_headers is not meant to be r/o)... I also tried JSON.parse(JSON.stringify(hdr)) that worked too.

    Not sure if that is related?

    No, get_all_msg_headers() is not r/o.

    Does put_msg_header() return false when you try to use it in that manner?

    On the originally reported issue with Tags, I found:
    - the issue still happens when using get_msg_header() instead
    - the issue does not happen on Win32 builds
    - the issue goes away when changing one line in js_msgbase.c, but it's clear
    why

    - LAZY_STRING_TRUNCSP_NULL("tags", p->msg.tags, JSPROP_ENUMERATE);
    + LAZY_STRING_TRUNCSP("tags", p->msg.tags, JSPROP_ENUMERATE);

    still looking into it.
    --
    digital man (rob)

    This Is Spinal Tap quote #14:
    The Boston gig has been cancelled. [Don't] worry, it's not a big college town. Norco, CA WX: 64.3F, 61.0% humidity, 5 mph S wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Friday, April 22, 2022 22:00:16
    Re: Javascript weirdness
    By: Digital Man to deon on Thu Apr 21 2022 06:17 pm

    Originally I was iterating through through that result to update the messages, but I was noticing the following behaviour:

    * call get_all_msg_headers()
    * iterate through each item "for (hdr in hdrs)"
    * set hdr.tag to "foo"
    * pass hdr to put_msg_header();

    But the items were not updating.

    Does put_msg_header() return false when you try to use it in that manner?

    So I cant reproduce this now. I'll revert my code to use get_all_msg_headers and if I can reproduce it, I'll provide a log and the status returned.


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From deon@VERT/ALTERANT to Digital Man on Friday, April 22, 2022 22:21:39
    Re: Javascript weirdness
    By: deon to Digital Man on Fri Apr 22 2022 10:00 pm

    Originally I was iterating through through that result to update the messages, but I was noticing the following behaviour:

    * call get_all_msg_headers()
    * iterate through each item "for (hdr in hdrs)"
    * set hdr.tag to "foo"
    * pass hdr to put_msg_header();

    But the items were not updating.

    Does put_msg_header() return false when you try to use it in that manner?

    So I cant reproduce this now. I'll revert my code to use get_all_msg_headers and if I can reproduce it, I'll provide a log and the
    status returned.

    OK, I got it. It seems to depend on whether I work with the object vs the attribute of it.

    First run, where I echo the object "after" put_msg_header:

    for (var X in msgs)

    X:35
    ORIG:0353 <-- msgs[x]
    CHANGE:0425 <-- msgs[x].tags = '0425'
    <put_msg_header>
    <JSON.stringify(msgs[x])> object:{"tags":"0425","number":38,"to":"deon","subject":"Test Reply","from":"Clearing ...
    STATUS:0 <!-- return from put_msg_header
    AFTER:0425 <-- msgs[x]

    vs echo the object "before" put_msg_header:

    X:35
    ORIG:0353 <!-- msgs[x]
    CHANGE:0389 <!-- msgs[x] = '0389'
    <JSON.stringify(msgs[x])> (Note it has reverted) object:{"tags":"0353","number":38,"offset":0,"to":"deon","from":"Clearing Houz","subject":"Test ...
    <put_msg_header>
    STATUS:0 <!-- result
    AFTER:0353 <!-- no change

    So it seems JSON.stringifying the object reverts its value, that doesnt seem right, but as long as I dont do that I guess I'm OK.


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From deon@VERT/ALTERANT to Digital Man on Saturday, May 07, 2022 09:19:40
    Re: Javascript weirdness
    By: Digital Man to deon on Thu Apr 21 2022 06:17 pm

    On the originally reported issue with Tags, I found:
    - the issue still happens when using get_msg_header() instead
    - the issue does not happen on Win32 builds
    - the issue goes away when changing one line in js_msgbase.c, but it's clear
    why

    - LAZY_STRING_TRUNCSP_NULL("tags", p->msg.tags, JSPROP_ENUMERATE);
    + LAZY_STRING_TRUNCSP("tags", p->msg.tags, JSPROP_ENUMERATE);

    still looking into it.

    How did you go, any luck?


    ...

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Friday, May 06, 2022 23:23:57
    Re: Javascript weirdness
    By: deon to Digital Man on Sat May 07 2022 09:19 am

    Re: Javascript weirdness
    By: Digital Man to deon on Thu Apr 21 2022 06:17 pm

    On the originally reported issue with Tags, I found:
    - the issue still happens when using get_msg_header() instead
    - the issue does not happen on Win32 builds
    - the issue goes away when changing one line in js_msgbase.c, but it's clear
    why

    - LAZY_STRING_TRUNCSP_NULL("tags", p->msg.tags, JSPROP_ENUMERATE); + LAZY_STRING_TRUNCSP("tags", p->msg.tags, JSPROP_ENUMERATE);

    still looking into it.

    How did you go, any luck?

    Nope, it's a weird one.
    --
    digital man (rob)

    Rush quote #41:
    Angels and demons dancing in my head, lunatics and monsters underneath my bed Norco, CA WX: 60.9F, 82.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net