• MsgBase first_msg property.

    From deon@1:103/705 to Digital Man on Fri May 6 21:05:49 2022
    Hey DM,

    I've noticed everytime I use the MsgBase first_msg property, it is always zero. (last_msg seems to always be correct.)

    Should it always be zero?

    Looking at one of my msgbases, fsx_gen:

    Opening [1002101] - (fsx_gen)
    - First:0 <-- first_msg property
    - Last:60001 <-- last_msg property
    50203:undefined <-- first of get_all_msg_headers(false,false)
    ...
    60000:undefined
    60001:undefined <-- last of get_all_msg_headers(false,false)

    (Dont worry about the "undefined" - I'm just listing all messages to see which have a "tag".


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Fri May 6 12:48:58 2022
    Re: MsgBase first_msg property.
    By: deon to Digital Man on Fri May 06 2022 09:05 pm

    Hey DM,

    I've noticed everytime I use the MsgBase first_msg property, it is always zero. (last_msg seems to always be correct.)

    Should it always be zero?

    Looking at one of my msgbases, fsx_gen:

    Opening [1002101] - (fsx_gen)
    - First:0 <-- first_msg property

    Seems to work for me. I wrote this simple test script and it displays non-zero first message values for my mail base and sub-boards:

    var base = new MsgBase(argv[0]);
    if(!base.open())
    alert("Can't open " + base.code);
    print(base.first_msg);
    --
    digital man (rob)

    Synchronet "Real Fact" #10:
    The name "DOVE-Net" was suggested by King Drafus (sysop of The Beast's Domain) Norco, CA WX: 78.8øF, 42.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Sat May 7 09:08:59 2022
    Re: MsgBase first_msg property.
    By: Digital Man to deon on Fri May 06 2022 12:48 pm

    Looking at one of my msgbases, fsx_gen:

    Opening [1002101] - (fsx_gen)
    - First:0 <-- first_msg property

    Seems to work for me. I wrote this simple test script and it displays non-zero first message values for my mail base and sub-boards:

    OK, your little script works as well for me.

    I've triggered my issue, appreciate your thoughts on it.

    I'm using objects - (not sure if you still have my msgbase.js) - in that I create an object representing the message base (with headers).

    So I:

    x=new MsgArea()
    x.code = 'fsx_gen';

    Setting the code triggers:
    * this.msgbase = new MsgBase(code);
    * open the msgbase
    * this.headers = this.msgbase.get_all_msg_headers(false,false) || [];
    * this.msgbase.close();

    If I dump this.msgbase, before the open(BO:), after the open (AO:) and after the close (AC:), I get this:

    BO:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen","name":"01:GEN","description":"General Chat","qwk_name":"FSX_GEN","area_tag":"FSX_GEN","newsgroup":"0021_FSX.01_GEN","ars":"","read_ars":"","post_ars":"","operator_ars":"","moderated_ars":"","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_origin":"I'm playing with ANSI+videotex - wanna play too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":102137891,"ptridx":28,"qwk_conf":0,"max_crcs":10000,"max_msgs":0,"max_age":365,"print_mode":0,"print_mode_neg":0},"error":"","status":0,"file":"/opt/sbbs/data/subs/fsx/fsx_gen","retry_time":30,"retry_delay":0,"first_msg":0,"last_msg":0,"total_msgs":0,"max_crcs":0,"max_msgs":0,"max_age":0,"attributes":0,"subnum":40,"is_open":false}

    Zero's as expected.

    AO:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen","name":"01:GEN","description":"General Chat","qwk_name":"FSX_GEN","area_tag":"FSX_GEN","newsgroup":"0021_FSX.01_GEN","ars":"","read_ars":"","post_ars":"","operator_ars":"","moderated_ars":"","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_origin":"I'm playing with ANSI+videotex - wanna play too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":102137891,"ptridx":28,"qwk_conf":0,"max_crcs":10000,"max_msgs":0,"max_age":365,"print_mode":0,"print_mode_neg":0},"error":"","status":0,"file":"/opt/sbbs/data/subs/fsx/fsx_gen","retry_time":30,"retry_delay":250,"first_msg":50203,"last_msg":60018,"total_msgs":9816,"max_crcs":10000,"max_msgs":0,"max_age":365,"attributes":0,"subnum":40,"is_open":true}

    Has values as expected

    AC:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen","name":"01:GEN","description":"General Chat","qwk_name":"FSX_GEN","area_tag":"FSX_GEN","newsgroup":"0021_FSX.01_GEN","ars":"","read_ars":"","post_ars":"","operator_ars":"","moderated_ars":"","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_origin":"I'm playing with ANSI+videotex - wanna play too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":102137891,"ptridx":28,"qwk_conf":0,"max_crcs":10000,"max_msgs":0,"max_age":365,"print_mode":0,"print_mode_neg":0},"error":"","status":0,"file":"/opt/sbbs/data/subs/fsx/fsx_gen","retry_time":30,"retry_delay":250,"first_msg":0,"last_msg":60018,"total_msgs":9816,"max_crcs":10000,"max_msgs":0,"max_age":365,"attributes":0,"subnum":40,"is_open":false}

    first_msg has been zeroed

    So why when the message base, is the "first_msg" attribute set to zero, but all other attributes are untouched?

    Can it be left untouched?

    (This is on a build as of yesterday - commit 6de0ebc0d.)


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Fri May 6 23:23:31 2022
    Re: MsgBase first_msg property.
    By: deon to Digital Man on Sat May 07 2022 09:08 am

    Re: MsgBase first_msg property.
    By: Digital Man to deon on Fri May 06 2022 12:48 pm

    Looking at one of my msgbases, fsx_gen:

    Opening [1002101] - (fsx_gen)
    - First:0 <-- first_msg property

    Seems to work for me. I wrote this simple test script and it displays non-zero first message values for my mail base and sub-boards:

    OK, your little script works as well for me.

    I've triggered my issue, appreciate your thoughts on it.

    I'm using objects - (not sure if you still have my msgbase.js) - in that I create an object representing the message base (with headers).

    So I:

    x=new MsgArea()
    x.code = 'fsx_gen';

    Setting the code triggers:
    * this.msgbase = new MsgBase(code);
    * open the msgbase
    * this.headers = this.msgbase.get_all_msg_headers(false,false) || [];
    * this.msgbase.close();

    If I dump this.msgbase, before the open(BO:), after the open (AO:) and after the close (AC:), I get this:

    BO:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen" ,"n ame":"01:GEN","description":"General Chat","qwk_name":"FSX_GEN","area_tag":"FSX _GEN","newsgroup":"0021_FSX.01_GE N","ars":"","read_ars":"","post_ars":"","opera tor_ars":"","moderated_ars":" ","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_o rigin":"I'm playing with ANSI+videotex - wanna play too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":1021378 91,"ptridx":28,"qwk_conf":0,"max_crcs":100 00,"max_msgs":0,"max_age":365,"print_ mode":0,"print_mode_neg":0},"error":"" ,"status":0,"file":"/opt/sbbs/data/subs/f sx/fsx_gen","retry_time":30,"retry _delay":0,"first_msg":0,"last_msg":0,"total_m sgs":0,"max_crcs":0,"max_msgs" :0,"max_age":0,"attributes":0,"subnum":40,"is_ope n":false}

    Zero's as expected.

    AO:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen" ,"n ame":"01:GEN","description":"General Chat","qwk_name":"FSX_GEN","area_tag":"FSX _GEN","newsgroup":"0021_FSX.01_GE N","ars":"","read_ars":"","post_ars":"","opera tor_ars":"","moderated_ars":" ","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_o rigin":"I'm playing with ANSI+videotex - wanna play too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":1021378 91,"ptridx":28,"qwk_conf":0,"max_crcs":100 00,"max_msgs":0,"max_age":365,"print_ mode":0,"print_mode_neg":0},"error":"" ,"status":0,"file":"/opt/sbbs/data/subs/f sx/fsx_gen","retry_time":30,"retry _delay":250,"first_msg":50203,"last_msg":6001 8,"total_msgs":9816,"max_crcs" :10000,"max_msgs":0,"max_age":365,"attributes":0, "subnum":40,"is_open":true}

    Has values as expected

    AC:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen" ,"n ame":"01:GEN","description":"General Chat","qwk_name":"FSX_GEN","area_tag":"FSX _GEN","newsgroup":"0021_FSX.01_GE N","ars":"","read_ars":"","post_ars":"","opera tor_ars":"","moderated_ars":" ","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_o rigin":"I'm playing with ANSI+videotex - wanna play too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":1021378 91,"ptridx":28,"qwk_conf":0,"max_crcs":100 00,"max_msgs":0,"max_age":365,"print_ mode":0,"print_mode_neg":0},"error":"" ,"status":0,"file":"/opt/sbbs/data/subs/f sx/fsx_gen","retry_time":30,"retry _delay":250,"first_msg":0,"last_msg":60018,"t otal_msgs":9816,"max_crcs":100 00,"max_msgs":0,"max_age":365,"attributes":0,"sub num":40,"is_open":false}

    first_msg has been zeroed

    As I would expect. These property values are dynamic (query the open message base), so the msgbase needs to be open.

    So why when the message base, is the "first_msg" attribute set to zero, but all other attributes are untouched?

    The others are stale values from the previous time you queried the properties contained in the status header.

    Can it be left untouched?

    You can copy the value if you want to save a snapshot of it.

    (This is on a build as of yesterday - commit 6de0ebc0d.)

    It's not a bug. If anything, I'd just work to make all the other cached values 'undefined' rather than return stale values. That's not going to help you either.
    --
    digital man (rob)

    This Is Spinal Tap quote #3:
    How much more black could this be? and the answer is none. None more black. Norco, CA WX: 60.9øF, 82.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Sat May 7 22:19:19 2022
    Re: MsgBase first_msg property.
    By: Digital Man to deon on Fri May 06 2022 11:23 pm

    AC:{"cfg":{"number":40,"grp_number":3,"grp_name":"0021:FSX","code":"fsx_gen" ,"n ame":"01:GEN","description":"General
    Chat","qwk_name":"FSX_GEN","area_tag":"FSX _GEN","newsgroup":"0021_FSX.01_GE N","ars":"","read_ars":"","post_ars":"","opera
    tor_ars":"","moderated_ars":" ","data_dir":"/opt/sbbs/data/subs/fsx/","fidonet_o rigin":"I'm playing with ANSI+videotex - wanna play
    too?","qwknet_tagline":"Alterant | an SBBS in Docker on Pi!","settings":1021378 91,"ptridx":28,"qwk_conf":0,"max_crcs":100
    00,"max_msgs":0,"max_age":365,"print_ mode":0,"print_mode_neg":0},"error":"" ,"status":0,"file":"/opt/sbbs/data/subs/f
    sx/fsx_gen","retry_time":30,"retry _delay":250,"first_msg":0,"last_msg":60018,"t otal_msgs":9816,"max_crcs":100
    00,"max_msgs":0,"max_age":365,"attributes":0,"sub num":40,"is_open":false}

    first_msg has been zeroed

    As I would expect. These property values are dynamic (query the open message base), so the msgbase needs to be open.

    So why when the message base, is the "first_msg" attribute set to zero, but all other attributes are untouched?

    The others are stale values from the previous time you queried the properties contained in the status header.

    Can it be left untouched?

    You can copy the value if you want to save a snapshot of it.

    (This is on a build as of yesterday - commit 6de0ebc0d.)

    It's not a bug. If anything, I'd just work to make all the other cached values 'undefined' rather than return stale values. That's not
    going to help you either.

    When the message base is closed (is_open = false), what would change the other values?

    If the values are only guaranteed to be correct when the message base is open, then programatically, you know when you can trust the values, by checking "is_open", right?

    So instead of scrubbing the "cached values", does it impact anything if they are left intact as at the last time the message base was open? (Including first_msg.)

    I know I can create new variables with those values that I need, but that does seem a waste when I have a variable that has this object already (especially if it is updated when I reopen the message base).


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sat May 7 09:44:49 2022
    Re: MsgBase first_msg property.
    By: deon to Digital Man on Sat May 07 2022 10:19 pm

    first_msg has been zeroed

    As I would expect. These property values are dynamic (query the open message base), so the msgbase needs to be open.

    So why when the message base, is the "first_msg" attribute set to zero, but all other attributes are untouched?

    The others are stale values from the previous time you queried the properties contained in the status header.

    Can it be left untouched?

    You can copy the value if you want to save a snapshot of it.

    (This is on a build as of yesterday - commit 6de0ebc0d.)

    It's not a bug. If anything, I'd just work to make all the other cached values 'undefined' rather than return stale values. That's not going to help you either.

    When the message base is closed (is_open = false), what would change the other values?

    I'm not clear on the question. The improvement I proposed would just change the MsgBase property 'getter' to return 'undefined' when the message base isn't opened. If you're curious about the implementation, that'd be changing js_msgbase_get() in js_msgbase.c

    If the values are only guaranteed to be correct when the message base is open, then programatically, you know when you can trust the values, by checking "is_open", right?

    Yup.

    So instead of scrubbing the "cached values", does it impact anything if they are left intact as at the last time the message base was open? (Including first_msg.)

    Currently, I'm not scrubbing any cached values (namely, the contents of the SMB "status header", which includes such things as the last message number). The first message number must be queried every time the property is read, that value is not cached in any SMB data structure.

    I know I can create new variables with those values that I need, but that does seem a waste when I have a variable that has this object already (especially if it is updated when I reopen the message base).

    You can look at js_msgbase.c if you're curious how/why it works the way it does and offer suggestions, but right now, it's working as designed and expected.
    --
    digital man (rob)

    Sling Blade quote #7:
    Karl: I don't reckon the Good Lord would send anybody like you to Hades.
    Norco, CA WX: 63.5øF, 81.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Sun May 8 22:41:46 2022
    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sat May 07 2022 09:44 am

    Currently, I'm not scrubbing any cached values (namely, the contents of the SMB "status header", which includes such things as the last
    message number). The first message number must be queried every time the property is read, that value is not cached in any SMB data
    structure.

    I know I can create new variables with those values that I need, but that does seem a waste when I have a variable that has this
    object already (especially if it is updated when I reopen the message base).

    You can look at js_msgbase.c if you're curious how/why it works the way it does and offer suggestions, but right now, it's working as
    designed and expected.

    OK, thanks for the guidance - I see what's going on now.

    Would you be adverse to something like this:

    diff --git a/src/sbbs3/js_msgbase.c b/src/sbbs3/js_msgbase.c
    index d52c7000f..8df7a7d9c 100644
    -+- a/src/sbbs3/js_msgbase.c
    +++ b/src/sbbs3/js_msgbase.c
    @@ -2967,6 +2967,7 @@ static JSBool js_msgbase_get(JSContext *cx, JSObject *obj, jsid id, jsval *vp)
    idxrec_t idx;
    private_t* p;
    jsrefcount rc;
    + static uint32_t first_msg = 0;

    if((p=(private_t*)JS_GetPrivate(cx,obj))==NULL)
    return JS_FALSE;
    @@ -2997,6 +2998,11 @@ static JSBool js_msgbase_get(JSContext *cx, JSObject *obj, jsid id, jsval *vp)
    rc=JS_SUSPENDREQUEST(cx);
    memset(&idx,0,sizeof(idx));
    smb_getfirstidx(&(p->smb),&idx);
    + if (SMB_IS_OPEN(&(p->smb))) {
    + first_msg = idx.number;
    + } else {
    + idx.number = first_msg;
    + }
    JS_RESUMEREQUEST(cx, rc);
    *vp=UINT_TO_JSVAL(idx.number);
    break;

    IE: I'm hoping the smb.status header retains it's values when the msgbase is closed (and you can trust those values as correct as at the time of closure). I'm assuming this wont affect anything else, given that you can see if the message base is open (and thus the values are current), if "is_open = true".


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sun May 8 11:28:25 2022
    Re: MsgBase first_msg property.
    By: deon to Digital Man on Sun May 08 2022 10:41 pm

    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sat May 07 2022 09:44 am

    Currently, I'm not scrubbing any cached values (namely, the contents of the SMB "status header", which includes such things as the last message number). The first message number must be queried every time the property is read, that value is not cached in any SMB data structure.

    I know I can create new variables with those values that I need, but that does seem a waste when I have a variable that has this object already (especially if it is updated when I reopen the message base).

    You can look at js_msgbase.c if you're curious how/why it works the way it does and offer suggestions, but right now, it's working as designed and expected.

    OK, thanks for the guidance - I see what's going on now.

    Would you be adverse to something like this:

    diff --git a/src/sbbs3/js_msgbase.c b/src/sbbs3/js_msgbase.c
    index d52c7000f..8df7a7d9c 100644
    -+- a/src/sbbs3/js_msgbase.c
    +++ b/src/sbbs3/js_msgbase.c
    @@ -2967,6 +2967,7 @@ static JSBool js_msgbase_get(JSContext *cx, JSObject *obj, jsid id, jsval *vp)
    idxrec_t idx;
    private_t* p;
    jsrefcount rc;
    + static uint32_t first_msg = 0;

    I would be adverse, yes, as static variables are shared among on threads (e.g. nodes) and if you opened 2 message bases, that variable would be stomped on by the second opened message base. That's not going to work.

    IE: I'm hoping the smb.status header retains it's values when the msgbase is closed (and you can trust those values as correct as at the time of closure).

    The smb.status header is not cleared when the msgbase is closed. But that's sort of what I was proposing: it should be. Or at least js_msgbase_get() should return 'undefined' for those properties when the message base isn't open to let you know that you've done something unexpected.

    I'm assuming this wont affect anything else, given that you can
    see if the message base is open (and thus the values are current), if "is_open = true".

    I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.
    --
    digital man (rob)

    This Is Spinal Tap quote #46:
    "Not an Exit" - we don't want an exit. Well that's true.
    Norco, CA WX: 64.1øF, 64.0% humidity, 11 mph S wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Mon May 9 09:32:59 2022
    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sun May 08 2022 11:28 am

    I would be adverse, yes, as static variables are shared among on threads (e.g. nodes) and if you opened 2 message bases, that variable would be stomped on by the second opened message base. That's not going to work.

    Ahh, OK, of course ...

    The smb.status header is not cleared when the msgbase is closed. But that's sort of what I was proposing: it should be. Or at least js_msgbase_get() should return 'undefined' for those properties when the message base isn't open to let you know that you've done something unexpected.

    I guess I'm not understanding why it "should be". For me, it still provides value when the message base is closed, and programatically I can know if those values are current.

    I probably could delay my closure of the msgbase until later (and I'll have to if you do go down that route) - but hestitant too, as I am not sure what other things may be locked out if I do and I'm too slow...

    I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.

    Thanks, I was going for what you were doing but couldnt figure out how first_msg would default to zero if the attribute was read and the msgbase hadnt been opened yet. How are you getting that? I thought with c++ it could get some random number (from the contents of the memory location that it's pointer was pointing too...) hence why I tried static.

    Appreciate your help.


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sun May 8 17:17:13 2022
    Re: MsgBase first_msg property.
    By: deon to Digital Man on Mon May 09 2022 09:32 am

    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sun May 08 2022 11:28 am

    I would be adverse, yes, as static variables are shared among on threads (e.g. nodes) and if you opened 2 message bases, that variable would be stomped on by the second opened message base. That's not going to work.

    Ahh, OK, of course ...

    The smb.status header is not cleared when the msgbase is closed. But that's sort of what I was proposing: it should be. Or at least js_msgbase_get() should return 'undefined' for those properties when the message base isn't open to let you know that you've done something unexpected.

    I guess I'm not understanding why it "should be". For me, it still provides value when the message base is closed, and programatically I can know if those values are current.

    The intention was that those properties would provide the current information. If the message base is closed, they can't do that. But since you have a use case for the most-recent (but not necessarily current) values and that was supported/provided by most of those properties already, I guess it's fine to just leave it as is, although that was an unintentional use case.

    I probably could delay my closure of the msgbase until later (and I'll have to if you do go down that route) - but hestitant too, as I am not sure what other things may be locked out if I do and I'm too slow...

    Nothing's locked when a msgbase is open.

    I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.

    Thanks, I was going for what you were doing but couldnt figure out how first_msg would default to zero if the attribute was read and the msgbase hadnt been opened yet. How are you getting that?

    This line zeroes-out the index structure (where the first message number is taken):
    memset(&idx,0,sizeof(idx));

    If the call to smb_getfirstidx() fails, then the idx is just left as is (all zeroed-out).

    I thought with c++ it could
    get some random number (from the contents of the memory location that it's pointer was pointing too...) hence why I tried static.

    Appreciate your help.

    No problem.
    --
    digital man (rob)

    Sling Blade quote #14:
    Karl Childers: Some folks call it a sling blade, I call it a kaiser blade. Norco, CA WX: 67.5øF, 59.0% humidity, 7 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Mon May 9 11:42:18 2022
    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sun May 08 2022 05:17 pm

    I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.

    Thanks, I was going for what you were doing but couldnt figure out how first_msg would default to zero if the attribute was read and the msgbase hadnt been opened yet. How are you getting that?

    This line zeroes-out the index structure (where the first message number is taken):
    memset(&idx,0,sizeof(idx));

    If the call to smb_getfirstidx() fails, then the idx is just left as is (all zeroed-out).


    Thanks, yes I saw that. But it's only called if the msgbase is opened.

    What if

    x = new MsgBase(code);
    JSON.stringify(x);

    It still shows first_msg is zero (as is last_msg) - which I know is what it should be - I couldnt follow how that was achieved for "first_msg" (I see how it is done for the other attributes). Or was that pure luck, and it could potentially be anything?

    It doesnt impact what I'm doing, just learning c++ code, one idea at a time :)


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sun May 8 19:37:51 2022
    Re: MsgBase first_msg property.
    By: deon to Digital Man on Mon May 09 2022 11:42 am

    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sun May 08 2022 05:17 pm

    I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.

    Thanks, I was going for what you were doing but couldnt figure out how first_msg would default to zero if the attribute was read and the msgbase hadnt been opened yet. How are you getting that?

    This line zeroes-out the index structure (where the first message number is taken):
    memset(&idx,0,sizeof(idx));

    If the call to smb_getfirstidx() fails, then the idx is just left as is (all zeroed-out).


    Thanks, yes I saw that. But it's only called if the msgbase is opened.

    What if

    x = new MsgBase(code);
    JSON.stringify(x);

    It still shows first_msg is zero (as is last_msg) - which I know is what it should be - I couldnt follow how that was achieved for "first_msg" (I see how it is done for the other attributes). Or was that pure luck, and it could potentially be anything?

    No, not luck. In js_msgbase_constructor(), the private_t (which contains the cached first_msg value) that is allocated and associated with the object is zeroed:

    memset(p,0,sizeof(private_t));

    Today, I would write that line:

    memset(p, 0, sizeof(*p));

    But, same result.

    It doesnt impact what I'm doing, just learning c++ code, one idea at a time :)

    No problem.
    --
    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: 59.8øF, 71.0% humidity, 10 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Mon May 9 13:13:29 2022
    Re: MsgBase first_msg property.
    By: Digital Man to deon on Sun May 08 2022 07:37 pm

    No, not luck. In js_msgbase_constructor(), the private_t (which contains the cached first_msg value) that is allocated and associated with the object is zeroed:

    memset(p,0,sizeof(private_t));

    Today, I would write that line:

    memset(p, 0, sizeof(*p));

    Got it, thanks :)


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)