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
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:
Zero's as expected.
Has values as expected
first_msg has been zeroed
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
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.)
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.
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).
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.
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;
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".
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.
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'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.
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.
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).
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 :)
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));
| Sysop: | tracker1 |
|---|---|
| Location: | Phoenix, AZ |
| Users: | 54 |
| Nodes: | 25 (0 / 25) |
| Uptime: | 236:25:41 |
| Calls: | 367 |
| Files: | 1,364 |
| Messages: | 36,299 |