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":"<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?
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.
write(); // Needed else this is not working?That's pretty strange.
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?
If put_msg_header() returns false, the details will be contained in MsgBase.error and MsgBase.status. Check/log those property values
upon error.
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?
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():
Generally, message headers aren't updated/extended after the message has been added/imported, so this isn't usually a problem.
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?
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?
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.
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).
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.
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?
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.
Thanks - I emailed it to you - please let me know if you didnt get it.
Has not arrived yet. <shrug>
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.
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.
I'll continue to debug further, but my first suspect is that get_all_msg_headers() method. Thanks for the report,
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?
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?
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.
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.
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 172:20:48 |
| Calls: | 7,915 |
| Files: | 12,983 |
| Messages: | 5,797,533 |