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!ã

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ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

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!ã

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ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

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!ã

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ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

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!ã

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ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

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!ã

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ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

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!ã

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ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

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!ã