I don't need a new IDE. I am happy with the VSC Editor.
And the compiler from Macca don't compile unused Methods.
I call unused Methods frequently with callbacks.
You can disable the unused method removal from the preferences page, and the command line compiler doesn't remove unused methods by default anymore.
This must be new. I will give Vers. 0.43 a try.
Thanks for the hint.
Uwe
If an #include file feature is eventually supported we could just put common defines in a single shared file there and include them in the required files. This might also be useful for including shared CON constants from different levels in the object hierarchy.
Being able to #include different files from #ifdef logic is a particularly useful thing, otherwise everything conditional needs to be put into a single file - or at least on a per included object basis (which itself is going to be very useful).
#include will be very very useful.
But I have another big Problem. My Propeller 2 Projekt is very big with many objects.
The last Pnut Version is v35u to compile my software.
All newer Versions brings Error: OBJ data exceeds 1024k limit.
I think Chip cannot expand the OBJ data space.
So I must wait for Pnut48 TS which has the #include Command and not the OBJ data space limit.
Uwe
Uwe, are you saying that older versions of PNut used to compile your large program, but newer ones do not? Perhaps I introduced some kind of pinch point, inadvertently.
Does the program grow during compilation, before duplicate objects are recognized and then collapsed into one? I am wondering why this occurs.
If an #include file feature is eventually supported we could just put common defines in a single shared file there and include them in the required files. This might also be useful for including shared CON constants from different levels in the object hierarchy.
Being able to #include different files from #ifdef logic is a particularly useful thing, otherwise everything conditional needs to be put into a single file - or at least on a per included object basis (which itself is going to be very useful).
#include will be very very useful.
But I have another big Problem. My Propeller 2 Projekt is very big with many objects.
The last Pnut Version is v35u to compile my software.
All newer Versions brings Error: OBJ data exceeds 1024k limit.
I think Chip cannot expand the OBJ data space.
So I must wait for Pnut48 TS which has the #include Command and not the OBJ data space limit.
Uwe
Uwe, are you saying that older versions of PNut used to compile your large program, but newer ones do not? Perhaps I introduced some kind of pinch point, inadvertently.
Does the program grow during compilation, before duplicate objects are recognized and then collapsed into one? I am wondering why this occurs.
Yes, i can compile my Programm with v35u without Problems.
V36 has a bug and don’t work for me.
V37 - 48 brings the error: OBJ data exceeds 1024k limit
In v37 Parameterization added to child-object instantiations.
You say to me that this is the problem. I think you cannot expand the OBJ data space.
I don’t use Parameterization but I have very much objects.
Uwe, do you have some files that are full of constants, mainly, that get included throughout your object tree?
I think redundancy might be causing the overflow. I am modifying the compiler now to check if an identical object exists before adding it to the buffer. If it exists, already, it will just set the new pointers to the extant object. We shouldn't need more than 2MB to fix this.
Uwe, I added some smarts to the internal object handling and I think it will solve the problem. I also realized there were some limit checks missing, which I added. If you go to the obex, it's in PNut_v48p3.zip:
@cgracey said:
Uwe, I added some smarts to the internal object handling and I think it will solve the problem. I also realized there were some limit checks missing, which I added. If you go to the obex, it's in PNut_v48p3.zip:
@cgracey said:
Uwe, I added some smarts to the internal object handling and I think it will solve the problem. I also realized there were some limit checks missing, which I added. If you go to the obex, it's in PNut_v48p3.zip:
Chip, I try to compile it and now I get: Limit of 512 object files exceeded
I have over 1000 objects in my Project.
Compiler output with Pnut35u:
Uwe, thanks for trying that out. I will expaaaaand the limits some more.
When the compiler went to object parameterization, I started keeping a buffer of all objects. So objects weren't thrown out along the way, with the compiler only working incrementally.
I have a question. Are you ever instantiating arrays of objects, like this?
AnObjectArray[100] : "SomeObject"
The compiler considers an array of objects as a single object. So, you have over 1,000 instantiations, which may or may not include arrays.
I will increase the object limit from 512 to 4096. I also have a limit of 32 unique sub-object files per object. I will increase that to 256.
wenn i not include the array I have 700 instantiations.
I now the limit of 32 unique sub-object files per object.
And i have exactly 32 objects in my main File.
It was great wenn you will increase that to 256.
My Propeller 2 Projekt is very big with many objects.
I'm really kind of curious about your application that uses all those objects, Uwe. I have a couple of really big apps with my laser tag job, but I've never run into the problems you're having. Again, it's just a curiosity thing. Can you share what you're doing?
wenn i not include the array I have 700 instantiations.
I now the limit of 32 unique sub-object files per object.
And i have exactly 32 objects in my main File.
It was great wenn you will increase that to 256.
@wummi said:
@cgracey, 256 objects are more than enough.
@JonnyMac, sorry i can not share what i am doing.
Okay, I will make it at least 256.
I think Jon's question was aimed at discovering why you have so many objects, rather than what the program actually does. I am kind of curious, too, about why you decided to build your system using so many objects. It seems like an unusual design decision.
@cgracey, why can't you just malloc more buffers as they fill up? Rather than rewriting everything to support fully dynamic memory, just allocate a certain size at the beginning - way more than enough to hold any single reasonable object, and enough to hold small programs -, and if less than a certain amount is still left when you're about to start a new object, ignore the unused space (virtual memory means not more than 4KB of what you don't use will actually get allocated and thereby wasted) and start a new buffer. RAM is cheap. This technique would allow you to keep what sounds like a simple bump allocator without having to move anything already allocated.
EDIT: Even simpler, just "allocate" a whole gigabyte worth of buffer up front and let virtual memory do its job of not allocating pages until you first use them.
@Electrodude said:
@cgracey, why can't you just malloc more buffers as they fill up? Rather than rewriting everything to support fully dynamic memory, just allocate a certain size at the beginning - way more than enough to hold any single reasonable object, and enough to hold small programs -, and if less than a certain amount is still left when you're about to start a new object, ignore the unused space (virtual memory means not more than 4KB of what you don't use will actually get allocated and thereby wasted) and start a new buffer. RAM is cheap. This technique would allow you to keep what sounds like a simple bump allocator without having to move anything already allocated.
EDIT: Even simpler, just "allocate" a whole gigabyte worth of buffer up front and let virtual memory do its job of not allocating pages until you first use them.
I was thinking of something like this earlier today. As it is, I've allocated buffers for pointers for different things. It's all static.
Hi Chip,
Pnut_v48p4x do not compile my program.
The Compiler crashed after some Objects and is closed without an Error Message.
The Windows10 Eventlog says: Application Error 1000
@wummi said:
Hi Chip,
Pnut_v48p4x do not compile my program.
The Compiler crashed after some Objects and is closed without an Error Message.
The Windows10 Eventlog says: Application Error 1000
Smaller programs can compiled without Problems.
Thank you for trying this, Uwe. I have no idea why this has happened. I need to look into it.
Seems like this is a bit "Chicken and egg". I'm also wondering for @wummi if you would be able to share an example project to Chip privately, perhaps with your sensitive code removed, but with enough dummy code to cause the error, and give Chip something to work with solving ?
I have been looking over my compiler code and I can't figure out why it would fail with "Application Error 1000" (which means that the app crashed). It seems to compile multi-level objects fine for me, but I don't know what causes failure with Uwe's huge code with a thousand objects.
I did make one optimization that further reduces data redundancy, but I'm not sure if it would make any difference in Uwe's case.
Meanwhile, I added multi-bit waveforms to the LOGIC debug display, so that you can see both bits and level representations of multiple bits, all aligned together. This is in v48p5x mentioned above.
CON _clkfreq = 10_000_000
PUB go() | i, j
debug(`LOGIC MyLogic SAMPLES 256 'Low' 8 RANGE 'Mid' 2 red 'High' 4 orange 'd' 4 RANGE cyan 'e' magenta 'f' 2 RANGE white LINESIZE 2 DOTSIZE 0 SPACING 4)
debug(`MyLogic TRIGGER $FF $80 HOLDOFF 2)
repeat
j := i & $FF + getrnd() << 8
j.[17..14] := i.[4..1]
debug(`MyLogic `$(j))
i++
waitms(5)
@cgracey said:
I have been looking over my compiler code and I can't figure out why it would fail with "Application Error 1000" (which means that the app crashed). It seems to compile multi-level objects fine for me, but I don't know what causes failure with Uwe's huge code with a thousand objects.
I did make one optimization that further reduces data redundancy, but I'm not sure if it would make any difference in Uwe's case.
Hi Chip,
Pnut v48p5x also crashed.
I can give you an old version from the program witch compiles with V35u and not with V37-48.
How can I send you the ZIP-File?
When I added parameters to objects in PNut_v37, I started pushing ~180KB of object data onto the stack for each recursive compiler call. When running PNut on Uwe's code from the Delphi compiler, instead of just crashing, it showed me that a stack overflow was occuring at object-depth 6. I only had 1MB of stack allocated and 6 x 180KB was blowing past it. So, I expanded the stack to 4MB which more than accommodates the max object-depth of 16. Then, Uwe's program started compiling.
Without Uwe's code, this would have been hard to figure out. It means he's maybe the only guy that has gone past 5 levels of object depth using PNut.
Thanks Chip, it works!
I can compile the last version of my program. And it runs on my Hardware for this project.
Now I can start to rewrite my program.
I would use the new multitasking, it is much better then my Multitasker written in spin.
I would use your flash file system, it is also much better than mine.
Next use the structs, that makes the program easier and I think much more readable.
The new pointer syntax is also much more readable.
And i habe a last Wish: Is it possible to get pointers to objects, to call the methods with obj_prt.method_name(....)
@wummi said:
Thanks Chip, it works!
I can compile the last version of my program. And it runs on my Hardware for this project.
Now I can start to rewrite my program.
I would use the new multitasking, it is much better then my Multitasker written in spin.
I would use your flash file system, it is also much better than mine.
Next use the structs, that makes the program easier and I think much more readable.
The new pointer syntax is also much more readable.
And i habe a last Wish: Is it possible to get pointers to objects, to call the methods with obj_prt.method_name(....)
You make a great job.
Uwe, I am glad it works on your code now. And I'm really happy that you are eager to use the newer Spin2 features.
Comments
This must be new. I will give Vers. 0.43 a try.
Thanks for the hint.
Uwe
Uwe, are you saying that older versions of PNut used to compile your large program, but newer ones do not? Perhaps I introduced some kind of pinch point, inadvertently.
Does the program grow during compilation, before duplicate objects are recognized and then collapsed into one? I am wondering why this occurs.
Yes, i can compile my Programm with v35u without Problems.
V36 has a bug and don’t work for me.
V37 - 48 brings the error: OBJ data exceeds 1024k limit
In v37 Parameterization added to child-object instantiations.
You say to me that this is the problem. I think you cannot expand the OBJ data space.
I don’t use Parameterization but I have very much objects.
Uwe
Uwe, I've got a new version of PNut that has a 2MB object buffer. I will post it here in just a minute....
Uwe, here is a new PNut v48.2x which should compile your big application code:
https://obex.parallax.com/obex/pnut-spin2-latest-version/
Thanks Chip,
I try it and get: OBJ data exceeds 2048k limit.
Next try with 4096k?
Yes, I will make it bigger, then. Thank you for trying it.
Uwe, do you have some files that are full of constants, mainly, that get included throughout your object tree?
I think redundancy might be causing the overflow. I am modifying the compiler now to check if an identical object exists before adding it to the buffer. If it exists, already, it will just set the new pointers to the extant object. We shouldn't need more than 2MB to fix this.
Uwe, I added some smarts to the internal object handling and I think it will solve the problem. I also realized there were some limit checks missing, which I added. If you go to the obex, it's in PNut_v48p3.zip:
https://obex.parallax.com/obex/pnut-spin2-latest-version/
Chip, I try to compile it and now I get: Limit of 512 object files exceeded
I have over 1000 objects in my Project.
Compiler output with Pnut35u:
Uwe, thanks for trying that out. I will expaaaaand the limits some more.
When the compiler went to object parameterization, I started keeping a buffer of all objects. So objects weren't thrown out along the way, with the compiler only working incrementally.
I have a question. Are you ever instantiating arrays of objects, like this?
AnObjectArray[100] : "SomeObject"
The compiler considers an array of objects as a single object. So, you have over 1,000 instantiations, which may or may not include arrays.
I will increase the object limit from 512 to 4096. I also have a limit of 32 unique sub-object files per object. I will increase that to 256.
Hi Chip,
yes I use obj-arrays
FG1[4] : "FG1" FG6[8] : "FG6" MOD[9] : "Modul" io[9] : "IO" s[2] : "schedule"wenn i not include the array I have 700 instantiations.
I now the limit of 32 unique sub-object files per object.
And i have exactly 32 objects in my main File.
It was great wenn you will increase that to 256.
I'm really kind of curious about your application that uses all those objects, Uwe. I have a couple of really big apps with my laser tag job, but I've never run into the problems you're having. Again, it's just a curiosity thing. Can you share what you're doing?
Well, would you like more than 256?
@cgracey, 256 objects are more than enough.
@JonnyMac, sorry i can not share what i am doing.
Okay, I will make it at least 256.
I think Jon's question was aimed at discovering why you have so many objects, rather than what the program actually does. I am kind of curious, too, about why you decided to build your system using so many objects. It seems like an unusual design decision.
Uwe, I made a new PNut_v48p4x.exe that should compile your program. Could you please try it out?
https://obex.parallax.com/obex/pnut-spin2-latest-version/
@cgracey, why can't you just malloc more buffers as they fill up? Rather than rewriting everything to support fully dynamic memory, just allocate a certain size at the beginning - way more than enough to hold any single reasonable object, and enough to hold small programs -, and if less than a certain amount is still left when you're about to start a new object, ignore the unused space (virtual memory means not more than 4KB of what you don't use will actually get allocated and thereby wasted) and start a new buffer. RAM is cheap. This technique would allow you to keep what sounds like a simple bump allocator without having to move anything already allocated.
EDIT: Even simpler, just "allocate" a whole gigabyte worth of buffer up front and let virtual memory do its job of not allocating pages until you first use them.
I was thinking of something like this earlier today. As it is, I've allocated buffers for pointers for different things. It's all static.
Hi Chip,
Pnut_v48p4x do not compile my program.
The Compiler crashed after some Objects and is closed without an Error Message.
The Windows10 Eventlog says: Application Error 1000
Smaller programs can compiled without Problems.
Thank you for trying this, Uwe. I have no idea why this has happened. I need to look into it.
Seems like this is a bit "Chicken and egg". I'm also wondering for @wummi if you would be able to share an example project to Chip privately, perhaps with your sensitive code removed, but with enough dummy code to cause the error, and give Chip something to work with solving ?
I have been looking over my compiler code and I can't figure out why it would fail with "Application Error 1000" (which means that the app crashed). It seems to compile multi-level objects fine for me, but I don't know what causes failure with Uwe's huge code with a thousand objects.
I did make one optimization that further reduces data redundancy, but I'm not sure if it would make any difference in Uwe's case.
For what it's worth, I posted it here (v48p5x):
https://obex.parallax.com/obex/pnut-spin2-latest-version/
Meanwhile, I added multi-bit waveforms to the LOGIC debug display, so that you can see both bits and level representations of multiple bits, all aligned together. This is in v48p5x mentioned above.
CON _clkfreq = 10_000_000 PUB go() | i, j debug(`LOGIC MyLogic SAMPLES 256 'Low' 8 RANGE 'Mid' 2 red 'High' 4 orange 'd' 4 RANGE cyan 'e' magenta 'f' 2 RANGE white LINESIZE 2 DOTSIZE 0 SPACING 4) debug(`MyLogic TRIGGER $FF $80 HOLDOFF 2) repeat j := i & $FF + getrnd() << 8 j.[17..14] := i.[4..1] debug(`MyLogic `$(j)) i++ waitms(5)Hi Chip,
Pnut v48p5x also crashed.
I can give you an old version from the program witch compiles with V35u and not with V37-48.
How can I send you the ZIP-File?
I’ve sent you a PM with Chips email address. Or use support@parallax.com and it will get to him!
Thanks Uwe and VonSzarvas. Looking forward to fixing this.
Okay, I found the problem.
When I added parameters to objects in PNut_v37, I started pushing ~180KB of object data onto the stack for each recursive compiler call. When running PNut on Uwe's code from the Delphi compiler, instead of just crashing, it showed me that a stack overflow was occuring at object-depth 6. I only had 1MB of stack allocated and 6 x 180KB was blowing past it. So, I expanded the stack to 4MB which more than accommodates the max object-depth of 16. Then, Uwe's program started compiling.
Without Uwe's code, this would have been hard to figure out. It means he's maybe the only guy that has gone past 5 levels of object depth using PNut.
I posted a new PNut_v48p6 here:
https://obex.parallax.com/obex/pnut-spin2-latest-version/
Thanks Chip, it works!
I can compile the last version of my program.
And it runs on my Hardware for this project.
Now I can start to rewrite my program.
I would use the new multitasking, it is much better then my Multitasker written in spin.
I would use your flash file system, it is also much better than mine.
Next use the structs, that makes the program easier and I think much more readable.
The new pointer syntax is also much more readable.
And i habe a last Wish: Is it possible to get pointers to objects, to call the methods with obj_prt.method_name(....)
You make a great job.
Uwe, I am glad it works on your code now. And I'm really happy that you are eager to use the newer Spin2 features.
I think method pointers already do what you want.
p := @objectname.methodname 'get a method pointer
p() 'call the method via the pointer