The STRUCT keywords are missing on the CON sPoint and sLine entries in the "StructureExample.spin2" example file for PNut v45, here is a corrected version.
The STRUCT keywords are missing on the CON sPoint and sLine entries in the "StructureExample.spin2" example file for PNut v45, here is a corrected version.
@cgracey said:
Here is how I see this, and it's very simple:
[ptr] := @variable
ptr[++]
When it comes to pointers, what is inside the brackets has to do with the pointer, itself.
This all stems from making pointers first-class, just like regular variables are.
Well, seems that there is nothing I can say to convince you that disrupting the operators effect is a bad idea, as well there is nothing you can say to convince me of the opposite.
@cgracey said:
Here is how I see this, and it's very simple:
[ptr] := @variable
ptr[++]
When it comes to pointers, what is inside the brackets has to do with the pointer, itself.
This all stems from making pointers first-class, just like regular variables are.
This change makes pointers second-class. Making them first class would mean making it possible to use normal variable operations on them, just like any other first-class value.
@cgracey said:
Here is how I see this, and it's very simple:
[ptr] := @variable
ptr[++]
When it comes to pointers, what is inside the brackets has to do with the pointer, itself.
This all stems from making pointers first-class, just like regular variables are.
This change makes pointers second-class. Making them first class would mean making it possible to use normal variable operations on them, just like any other first-class value.
My use> @macca said:
@cgracey said:
Here is how I see this, and it's very simple:
[ptr] := @variable
ptr[++]
When it comes to pointers, what is inside the brackets has to do with the pointer, itself.
This all stems from making pointers first-class, just like regular variables are.
Well, seems that there is nothing I can say to convince you that disrupting the operators effect is a bad idea, as well there is nothing you can say to convince me of the opposite.
I have thought a lot about how to do this and it's the only way that feels right to me. I don't want to disappoint anyone, but I can't bring myself to do what feels wrong. I've been thinking about this for nearly a year. I would have had it done a long time ago if I had not been talked out of it. A lot of time was lost due to doubt and uncertainty. Now that it's done, I feel good about it and I can move forward again.
Chip can you perhaps show us some more real-world examples of how this hybrid pointer/reference approach can be used. Maybe that will help alleviate some of our concerns. For example is this going to be the potential sort of syntax for how you could implement a method for finding a character in a string when passing in one of these new pointers you have come up with?
PUB findchar(^BYTE string, BYTE char) : result
repeat while string
if string==char
return [string]
string[++]
If you declare a pointer to some structure what happens when you add something directly to it?
PUB test(^STRUCTNAME structure) : result
structure+=3
What does this do? Does it try to add a long or a byte or a word value of 3 to the first element of the passed in structure? Seems like this would be a somewhat limited use of addition operations to only add to the first element.
Also can you do this?
PUB extract(^BYTE stringptr, offset) : result
return stringptr[offset] ' returns the element requested at some offset pos
I'm hoping we don't end up with too many nested brackets in lots of places doing pointer operations given you've sort of overloaded the array index operator in order to do pointer arithmetic.
@rogloh said:
Chip can you perhaps show us some more real-world examples of how this hybrid pointer/reference approach can be used. Maybe that will help alleviate some of our concerns. For example is this going to be the potential sort of syntax for how you could implement a method for finding a character in a string when passing in one of these new pointers you have come up with?
PUB findchar(^BYTE string, BYTE char) : result
repeat while string
if string==char
return [string]
string[++]
The only type overrides allowed for parameters and return values are pointers and small structures (15 longs, max). So, you can't do BYTE, since all parameters must be longs. Pointers are longs and small structures are passed/returned as zero-padded sets of longs.
That last string[++] would just be a lone variable without an operator, causing a compile-time error. You would need to code it as [string]++.
You could code that like this:
PUB findchar(^BYTE string, char) : result
repeat while string
if string[++] == char
return --[string]
If you declare a pointer to some structure what happens when you add something directly to it?
PUB test(^STRUCTNAME structure) : result
structure+=3
What does this do? Does it try to add a long or a byte or a word value of 3 to the first element of the passed in structure? Seems like this would be a somewhat limited use of addition operations to only add to the first element.
The only operators allowed on structures are := to assign, :=: to swap contents with a same-sized structure, ~ to clear it, and ~~ to set it to all $FF's.
If structure had a byte/word/long member 'x', then you could do structure.x += 3.
Also can you do this?
PUB extract(^BYTE stringptr, offset) : result
return stringptr[offset] ' returns the element requested at some offset pos
Yes, that would work as you stated.
I'm hoping we don't end up with too many nested brackets in lots of places doing pointer operations given you've sort of overloaded the array index operator in order to do pointer arithmetic.
I don't thing there'd be many occassions for nested brackets.
@cgracey said:
Here is how I see this, and it's very simple:
[ptr] := @variable
ptr[++]
When it comes to pointers, what is inside the brackets has to do with the pointer, itself.
This all stems from making pointers first-class, just like regular variables are.
This change makes pointers second-class. Making them first class would mean making it possible to use normal variable operations on them, just like any other first-class value.
I was thinking that the pointer, in operation, is first-class, where it IS the variable pointed to. Then, you must use [pointer] notation to operate on the pointer, itself.
@pointer is equivalent to [pointer], whereas @[pointer] is the address of the pointer, itself.
[pointer] must be used for assigning the pointer value, though pointer[++] modifies the pointer value and presents the variable being pointed to for read/modify/write purposes.
I think of the new bracket usage as dealing with the pointer's internal value:
[pointer]
pointer[++]
[--]pointer
What is INSIDE the brackets and related to the pointer variable is affecting the pointer INSIDE, not the pointed-to variable which is its OUTSIDE character.
PUB extract(^BYTE stringptr, offset) : result
return stringptr[offset] ' returns the element requested at some offset pos
Yes, that would work as you stated.
Ok thanks for the reply Chip. This part is probably about the only thing I like about it so far - probably because it works the same as C in this example. In C a char pointer can also be accessed as an array of chars, with the array operator dereferencing the pointer at the element offset provided by the array index. Your SPIN2 code works the same there even though the other way of dereferencing by name alone is automatic (like C references instead of pointers). So stringptr on it's own returns the first byte element (instead of the address itself) which is also the same as accessing stringptr[0]. You could say stringptr == stringptr[0] .
char extract(char *stringptr, int offset)
{
return stringptr[offset];
}
Hopefully we can still advance the pointer by some integer multiples of the structured size by doing this: [stringptr]+=3
@rogloh said:
So stringptr on it's own returns the first byte element (instead of the address itself) which is also the same as accessing stringptr[0]. You could say stringptr == stringptr[0] .
Notice that this is true for all variables. There's no difference between an array and a single variable.
@cgracey said:
That last string[++] would just be a lone variable without an operator, causing a compile-time error. You would need to code it as [string]++.
That should really be valid. If a normal increment is valid as a standalone statement, the pointer increment should be, too.
@cgracey said:
I posted a new PNut_v46 at the top of this thread.
DEBUG gating is added. Constant DEBUG_MASK defines 32 bits which can be used to gate DEBUG commands via DEBUG[MaskBitNumber]{(parameters...)}
DEBUG disabling is added. If constant DEBUG_DISABLE is defined as non-0, all DEBUGs will be ignored in that file.
Automatic prepending of the clock-setter program for PASM-only programs can now be inhibited by defining _AUTOCLK as 0.
VAR blocks can now switch type declarations on each line: VAR BYTE a,b,c, WORD d,e,f, LONG g,h,i
New DEBUG command C_Z will output the states of the C and Z flags, such as "C=0 Z=1".
I just downloaded PNut v46 and it appears that the latest changes has broken the ability to read the DEBUG mouse and keyboard.
If you run your example program DEBUG_Mouse_and_Keyboard.spin2 the program just freezes the first time the
debug(`myplot `pc_mouse(@xpos))
statement is executed. I tried adding DEBUG_DISABLE with both zero and non-zero values. The flag did as expected and suppressed running the debug statements when the value was non-zero, but it didn't make any difference on the DEBUG mouse and keyboard issue.
The original program works fine when using PNut v45.
I just downloaded PNut v46 and it appears that the latest changes has broken the ability to read the DEBUG mouse and keyboard.
If you run your example program DEBUG_Mouse_and_Keyboard.spin2 the program just freezes the first time the
debug(`myplot `pc_mouse(@xpos))
statement is executed. I tried adding DEBUG_DISABLE with both zero and non-zero values. The flag did as expected and suppressed running the debug statements when the value was non-zero, but it didn't make any difference on the DEBUG mouse and keyboard issue.
The original program works fine when using PNut v45.
Thanks for pointing this out, Francis. I will fix it.
It is now fixed and if you download v46 again, you will have the new one.
I had inserted a new "C=0 Z=0" string between two strings in the debugger that needed to be contiguous:
Comments
Oh, yeah. Duh! I wasn't putting it all together.
@cgracey ,
The STRUCT keywords are missing on the CON sPoint and sLine entries in the "StructureExample.spin2" example file for PNut v45, here is a corrected version.
Ah, thanks. I will fix this.
Well, seems that there is nothing I can say to convince you that disrupting the operators effect is a bad idea, as well there is nothing you can say to convince me of the opposite.
This change makes pointers second-class. Making them first class would mean making it possible to use normal variable operations on them, just like any other first-class value.
My use> @macca said:
I have thought a lot about how to do this and it's the only way that feels right to me. I don't want to disappoint anyone, but I can't bring myself to do what feels wrong. I've been thinking about this for nearly a year. I would have had it done a long time ago if I had not been talked out of it. A lot of time was lost due to doubt and uncertainty. Now that it's done, I feel good about it and I can move forward again.
Chip can you perhaps show us some more real-world examples of how this hybrid pointer/reference approach can be used. Maybe that will help alleviate some of our concerns. For example is this going to be the potential sort of syntax for how you could implement a method for finding a character in a string when passing in one of these new pointers you have come up with?
PUB findchar(^BYTE string, BYTE char) : result repeat while string if string==char return [string] string[++]If you declare a pointer to some structure what happens when you add something directly to it?
PUB test(^STRUCTNAME structure) : result structure+=3What does this do? Does it try to add a long or a byte or a word value of 3 to the first element of the passed in structure? Seems like this would be a somewhat limited use of addition operations to only add to the first element.
Also can you do this?
PUB extract(^BYTE stringptr, offset) : result return stringptr[offset] ' returns the element requested at some offset posI'm hoping we don't end up with too many nested brackets in lots of places doing pointer operations given you've sort of overloaded the array index operator in order to do pointer arithmetic.
The only type overrides allowed for parameters and return values are pointers and small structures (15 longs, max). So, you can't do BYTE, since all parameters must be longs. Pointers are longs and small structures are passed/returned as zero-padded sets of longs.
That last string[++] would just be a lone variable without an operator, causing a compile-time error. You would need to code it as [string]++.
You could code that like this:
PUB findchar(^BYTE string, char) : result repeat while string if string[++] == char return --[string]The only operators allowed on structures are := to assign, :=: to swap contents with a same-sized structure, ~ to clear it, and ~~ to set it to all $FF's.
If structure had a byte/word/long member 'x', then you could do structure.x += 3.
Yes, that would work as you stated.
I don't thing there'd be many occassions for nested brackets.
I was thinking that the pointer, in operation, is first-class, where it IS the variable pointed to. Then, you must use [pointer] notation to operate on the pointer, itself.
@pointer is equivalent to [pointer], whereas @[pointer] is the address of the pointer, itself.
[pointer] must be used for assigning the pointer value, though pointer[++] modifies the pointer value and presents the variable being pointed to for read/modify/write purposes.
I think of the new bracket usage as dealing with the pointer's internal value:
[pointer]
pointer[++]
[--]pointer
What is INSIDE the brackets and related to the pointer variable is affecting the pointer INSIDE, not the pointed-to variable which is its OUTSIDE character.
I posted a new PNut_v46 at the top of this thread.
Ok thanks for the reply Chip. This part is probably about the only thing I like about it so far - probably because it works the same as C in this example. In C a char pointer can also be accessed as an array of chars, with the array operator dereferencing the pointer at the element offset provided by the array index. Your SPIN2 code works the same there even though the other way of dereferencing by name alone is automatic (like C references instead of pointers). So stringptr on it's own returns the first byte element (instead of the address itself) which is also the same as accessing stringptr[0]. You could say stringptr == stringptr[0] .
char extract(char *stringptr, int offset) { return stringptr[offset]; }Hopefully we can still advance the pointer by some integer multiples of the structured size by doing this:
[stringptr]+=3Notice that this is true for all variables. There's no difference between an array and a single variable.
That should really be valid. If a normal increment is valid as a standalone statement, the pointer increment should be, too.
@cgracey,
I just downloaded PNut v46 and it appears that the latest changes has broken the ability to read the DEBUG mouse and keyboard.
If you run your example program DEBUG_Mouse_and_Keyboard.spin2 the program just freezes the first time the
debug(`myplot `pc_mouse(@xpos))statement is executed. I tried adding DEBUG_DISABLE with both zero and non-zero values. The flag did as expected and suppressed running the debug statements when the value was non-zero, but it didn't make any difference on the DEBUG mouse and keyboard issue.
The original program works fine when using PNut v45.
Thanks for pointing this out, Francis. I will fix it.
It is now fixed and if you download v46 again, you will have the new one.
I had inserted a new "C=0 Z=0" string between two strings in the debugger that needed to be contiguous:
I changed it to this and PC_MOUSE started working again: