SBJS

[JRS]

Thanks Charles!

That solves the position in the bit map and unmystifies the ORing of these flags. Setting them to TRUE/FALSE still has me scratching my head. I'm on the fence to try to wrap this as a C function or emulate it in Script BASIC.

I think its checking v (object pointer) to see if it exists (non-NULL) before setting a TRUE/FALSE condition.

HERE is the Github project site for V7 if needed.

My plan is to create a Windows JS extension module once the Linux version is done.

I think V7 would be a cool extension to O2 as a DLL interface.

HERE is a thread on All BASIC about my progress embedding V7 in Script BASIC.

[Mike Lobanovsky]

if v then return n or (n<<16) else return n<<16)
---->
if v then return n*0x10000 + n else return n*0x10000

Mmm, I'm afraid not exactly.

While <<16 and *0x10000 are interchangeable and we may even drop the (v7_prop_attr_desc_t) member of the macro painlessly because it's effectively just a cast of n to an unsigned long (cf.  typedef unsigned long v7_prop_attr_desc_t;) to shut up the C compiler's strict type checking, we may not substitute bitwise or with addition here.

So, both

If v Then Return (n BitwiseOr (n << 16)) Else Return (n << 16)

and

If v Then Return (n BitwiseOr (n * 0x10000)) Else Return (n * 0x10000)

are safe for any given n and their combinations be they signed or unsigned, original or cast, as long as we're shifting to the left. When shifting to the right, we must also be aware of signed or unsigned n shifts. In the case of signed negative n, C will preserve its highest-order bit (the leftmost one in Calculator's binary number representation, or the 31st one in the 0..31 bit range) in its place while right shifting. OTOH the highest-order bit of an unsigned n will be right-shifted down together with the other bits in this number. So, right shifts, if any, is where the (v7_prop_attr_desc_t) cast would also matter.

But at any rate, for such a dramatic headlong dash to the left addition is only usable up to a certain "pivot point" where the total of bits in n wouldn't exceed 0xFFFF0000, because any attempt to add yet another bit (i.e. property attribute) to the total rather than bitwise or them together would yield an entirely wrong total:

Code: C

1. #AppType Console
2.  
3. ? "test 0xFFFF0000"
4. test(0xffff0000)
5. ? "-------------------------"
6. ? "test 0xFFFF0001"
7. test(0xffff0001)
8.  
9. DynC test(%n)
10.   void main(int n)
11.   {
12.     printf("    signed + : %d\n", n + (n << 16));
13.     printf("  unsigned + : %u\n", n + (n << 16));
14.     printf("(unsigned) + : %u\n", (unsigned)n + ((unsigned)n << 16));
15.     printf("    signed | : %d\n", n | (n << 16));
16.     printf("  unsigned | : %u\n", n | (n << 16));
17.     printf("(unsigned) | : %u\n", (unsigned)n | ((unsigned)n << 16));
18.   }
19. End DynC
20.  
21. Pause

Output:

test 0xFFFF0000
    signed + : -65536
  unsigned + : 4294901760
(unsigned) + : 4294901760
    signed | : -65536
  unsigned | : 4294901760
(unsigned) | : 4294901760
-------------------------
test 0xFFFF0001
    signed + : 1        <== All wrong! 1 means V7_PROPERTY_NON_WRITABLE!
  unsigned + : 1        <== ditto
(unsigned) + : 1        <== ditto
    signed | : -65535
  unsigned | : 4294901761
(unsigned) | : 4294901761

[JRS]

Mike,

Should I try to keep this bit shift stuff in C and just pass property attribute status info to an extension module routine?  (if possible)

[Mike Lobanovsky]

Exactly!

You won't be able to express the entire range of this macro's conditions in traditional BASIC without a lot of time-consuming extra compensatorial math.

If you can, prefer to leave it on the C language side of the SB:C interface.

[JRS]

Thanks Mike!

I'll take your advice. The unknown (for me) is can I assign a parameter in a macro as a variable passed from a SB ext. module function call?

[Mike Lobanovsky]

The macro would accept valid literal or variable v and n arguments: v should evaluate to a whole integer (0 = FALSE, otherwise TRUE), and n can be any literal or variable. The C side of the interface should explicitly cast any v that comes in from the SB side to an int, long, or BOOL, while the macro's (v7_prop_attr_desc_t) cast (i.e. (insigned long) cast) will be applied to any incoming literal or variable n automatically.

[JRS]

Excellent!

I'll give it a shot and see what happens. I will make a seperate ext. module call for each property attribute option. All I should have to pass is v  (object pointer) and a true/false for the attribute state. I should be able to OR the property attribute functions results (using Charles's bit mask table values) in the SB function v7_def() call.

Code: C

1. v7_def(v7, v, "foo", -1, (V7_PROPERTY_NON_WRITABLE | V7_OVERRIDE_ATTRIBUTES),v7_mk_number(v7, 1.0)),0);
2.  

Code: Script BASIC

1. rtncode = JS::DEF(jsobj, propobj, JS::V7_PROPERTY_NON_WRITABLE(1) OR JS::V7_OVERRIDE_ATTRIBUTES(0), JS::MK_NUMBER(jsobj,1.0)),0)
2.  

[Charles Pegge]

Hi Mike,

Yes, Script Basic only uses signed integers as its integer type, so one would need to ensure that only bits 0..14 were used to encode all the attributes, before using multiplication and addition.

The header section posted by John shows only bits 0..8 being used.

But I find the scheme of this header perplexing.

[JRS]

But I find the scheme of this header perplexing.

Q. How many function variations can you fit in a one line macro?

First there is defining each property attribute with a shifted ORable bit driven sequence followed by property existence validation and finally attribute state assignment. (true/false)

[Charles Pegge]

Perplexed because I would expect bit attributes to be handled in a simple manner:

Testing attribute n in v
if (v and n) ...

Setting attribute n in v
v or=n

Clearing attribute n in v
v and= not(n)

Inverting (toggling) attribute n in v
v xor= n

[Mike Lobanovsky]

@Charles:

... so one would need to ensure that only bits 0..14 were used to encode all the attributes ...

Hi,

That's exactly what I meant by extra BASIC arith.

The header section posted by John shows only bits 0..8 being used.

That's correct but the end user's visual memory may render them an ill service elsewhere the next time they try to add high-order bit flags instead of bitwise or them. After all, John's extension module aims for BASIC, not C, end users.

But I find the scheme of this header perplexing.

I think that's clearly not a valid C header file but rather a mixture of snippets:

#define _V7_MK_DESC(v, n) \
  (((v7_prop_attr_desc_t)(n)) << _V7_DESC_SHIFT | ((v) ? (n) : 0))

may not precede

typedef unsigned long v7_prop_attr_desc_t;

because the C preprocessor knows nothing of such an O2 goodie as #lookahead.


@John:


Hi,

I seem to fail trying to find Peter's original site with full SB documentation to read up on SB's bitwise logic and stuff, and your All Basic link to the SB Reference seems incomplete.

Perplexed because I would expect bit attributes to be handled in a simple manner:

So am I. I wouldn't expect v being anything else but n itself, tested for n != 0...

Q. How many function variations can you fit in a one line macro?

Actually, a hell of a bloody lot.

The C preprocessor is a language unto itself all right, a valuable extra shipped free out of the C box. Its "glue" operator ## would allow you to work miracles chopping your C code and gluing parts of it (down to separate letters' level) at will according to your very personal idea of what "readable code" means.

I've seen pieces of code rendered absolutely unmaintainable due to the author's very peculiar notion of "code readability".

But I've also seen compilable PP code that would express in a handful of lines almost the entire functionality of a library compatible with licensed zlib.dll.

[JRS]

HERE is a link to the Script BASIC wiki. It contains the user and developer guides along with docs for some of the extension modules.

Peter Verhas's (original author of Script BASIC) www.scriptbasic.com site is no longer. He is Java centric and I don't see Peter going back to C anytime soon.

The C preprocessor is a language unto itself all right,

I think C BASIC is a good example of that.

[Mike Lobanovsky]

Oh, thanks John!

Developers Guide - ONLINE is exactly what I've been looking for.

(sorry for confusing Peter with Paul -- my sacrilegeous blunder's just been fixed)

[JRS]

Mike,

I think I have everything figured out except the OR aspect of these property attributes. I was thinking of the SB ext. module attribute functions returning the shift offset value Charles posted. Do you see that as a valid solution?

Update:

I think I'm going to use the following method for setting/clearing property attributes. If the attribute flag isn't passed it is (re)set to zero (false) unless P is passed which leaves unreferenced attributes as is.

Code: Script BASIC

1. JS::DEF(jsobj, propobj, "my_property", 11, "WECGSP", 123)
2.  

• W - Writable
  
• E - Enumerable
  
• C - Configurable
  
• G - Getter
  
• S - Setter
  
• P - Preserve
  

[Mike Lobanovsky]

... I have everything figured out except the OR aspect of these property attributes.

Just in case you're still having difficulties with the C preprocessor, you may wish to use procedural equivalents of the macros on either the SB or C side of the interface. It is feasible, albeit a bit slower than inlined macros.

Consider the following SB routines (SB docs say SB would convert bitwise OR and NOT arguments to integers automatically, and trial shows any IF argument evaluates to TRUE if it is <> 0 or <> FALSE):

Code: Script BASIC

1. FUNCTION _V7_MK_DESC(v, n)
2.     IF v THEN
3.         _V7_MK_DESC = (n OR (n * 0x10000))
4.     ELSE
5.         _V7_MK_DESC = INT(n * 0x10000)
6.     END IF
7. END FUNCTION

and

Code: Script BASIC

1. FUNCTION _V7_MK_DESC_INV(v, n)
2.     _V7_MK_DESC_INV = _V7_MK_DESC(NOT v, n)
3. END FUNCTION

or their C language equivalents:

Code: C

1. unsigned long _V7_MK_DESC(int v, unsigned long n) {
2.     if (v)
3.         return (n | (n << 16));
4.     return (n << 16);
5. }

and

Code: C

1. unsigned long _V7_MK_DESC_INV(int v, unsigned long n) {
2.     return _V7_MK_DESC(!v, n);
3. }

then "functionalize" the other macros at the bottom of your greenish pseudo C header as calls to the two functions above, should you need them too on either side of your interface implementation at all.

Hope this helps.