Spenceboy98 wrote:
I wondering, would/could you implement Prizm C programming as well? It would sure save some time for beginners, so they wouldn't have to find all the latest Prizm SDK files.
+1
KermMartian wrote:
That's quite a good idea, actually; let me explore what we'd need to do for this, and perhaps see if I can delegate it to our Prizm C toolchain experts, Tari and Jonimus.
Thank you all in advance - hopefully Programmer Nerd and gbl08ma will be able to help Tari and Jonimus. I think eventually it may even save their time currently kindly spent on helping people with setups on different platforms and to make further development of their viewers and other add-ins with more customized setups like Eigenmath more feasible.
I hope they don't mind me mentioning their names here - I'm very grateful for their and other experts' help and contributions to this great community.
I have been attempting to collaborate on several projects through somewhat less-than-ideal means lately. I think it would be a great advantage for some users if SC3 featured some sort of project sharing capability. Kerm mentioned that the projects are stored in a format similar to the 8xg, and that it should be possible to access these files from multiple accounts. It will probably be necessary to implement some sort of locking mechanism so that people cannot edit the same project/file at the same time.
Additionally, SC3 is currently lacking rudimentary version control and/or the ability to interface with GitHub. This makes it difficult to undo large mistakes without keeping external backups.
I would love for SC3 to support external storage APIs (BitBucket/GitHub/Google Drive/DropBox), but this is definitely a non-trivial undertaking to do well.
As I was telling jonbush, I have looked at PHP APIs for GitHub to allow SourceCoder projects to be committed to / pulled from GitHub, and then almost immediately ran away screaming. I do love the idea of collaborative ownership of projects and GitHub integration, though.
The ideas of collaborative edition and integration with Github are good, and in fact not new. The first one is not that hard with a properly designed model, but the latter is much harder...
Spenceboy, I believe you mentioned difficulties with a multi-file project. Is that still the case?
Saving PNG images correctly in projects and then using them with the C compilation feature is needed.
KermMartian wrote:
Spenceboy, I believe you mentioned difficulties with a multi-file project. Is that still the case?
Saving PNG images correctly in projects and then using them with the C compilation feature is needed.
Yeah, I have to add a blank file to get it to open the file properly.
Suggestion (not sure if this has already been suggested)
When one selects the asm or c editors, it would be nice if either a template of the standard headers and such be either pasted, or a button appear to paste the basic start header stuff for them. Not sure how hard that would be to implement, though.
Spenceboy98 wrote:
KermMartian wrote:
Spenceboy, I believe you mentioned difficulties with a multi-file project. Is that still the case?
Saving PNG images correctly in projects and then using them with the C compilation feature is needed.
Yeah, I have to add a blank file to get it to open the file properly. I'm afraid you lost me there. What exactly do you mean?
tifreak8x: I'm planning to add "New Blank Program", "New TI-BASIC Program", "New z80 ASM Program", "New ez80 ASM Program", and "New TI-84 Plus CE C Program", or thereabouts. What do you think?
Edit: I also need an updated ti84pce.inc in there.
KermMartian wrote:
Spenceboy98 wrote:
KermMartian wrote:
Spenceboy, I believe you mentioned difficulties with a multi-file project. Is that still the case?
Saving PNG images correctly in projects and then using them with the C compilation feature is needed.
Yeah, I have to add a blank file to get it to open the file properly. I'm afraid you lost me there. What exactly do you mean?
Like this:
If I don't have the Blah.h file there, it says it's unable to open CatSprites.h. I don't actually have to include Blah.h.
I believe that issue is now fixed. Please confirm at your convenience.
KermMartian wrote:
I believe that issue is now fixed. Please confirm at your convenience.
I can confirm the issue has been fixed.
*BUMP*
I may have found another bug.
I keep getting this error:
Code: CC: No file(s) "\bin\eZ80cc.c" found
main.c
\USR\LOCAL\BIN\CSDK\INCLUDE\STD\MATH.H (8,7) : ERROR (100) Syntax error
\USR\LOCAL\BIN\CSDK\INCLUDE\STD\MATH.H (8,24) : ERROR (178) "unsigned" and "signed" may be used in conjunction only with "char", "short", "int" or "long"
No such bug. We since resolved this, I believe.
Since my last post here, SourceCoder 3 has been upgraded to v2.1 of the CSDK and the libraries. In addition, the RAM/Archive switch now works, and selecting Debug Off or Debug On (whether to emit debug code for CEmu's use) is now an option.
Spenceboy98 wrote:
*BUMP*
I may have found another bug.
I keep getting this error:
Code: CC: No file(s) "\bin\eZ80cc.c" found
main.c
\USR\LOCAL\BIN\CSDK\INCLUDE\STD\MATH.H (8,7) : ERROR (100) Syntax error
\USR\LOCAL\BIN\CSDK\INCLUDE\STD\MATH.H (8,24) : ERROR (178) "unsigned" and "signed" may be used in conjunction only with "char", "short", "int" or "long"
I'm getting this error again. Don't know what the issue could be. :/
It's your code again. You need to make sure you are using the correct prototypes.
*bump* For those using the C programming tools, the underlying toolchain and libraries have both been upgraded to v3.4, and custom Makefile confusion has been resolved (so that libraries and compilation all work nicely). The static linking flag will be exposed soon too, allowing programs to be compiled with libraries built-in instead of requiring Libload.
Quote:
The static linking flag will be exposed soon too
Oooh... This is a terrible idea, because of well-identified negative consequences on availability of programs on future hardware revisions of existing models, or new similar models. For the community's sake (both programmers and users), I urge you not to do that
In our context, detailed below, static linking of libraries is an anti-feature. It should never have been added to the toolchain, and SC3 (or PB, for that matter) shouldn't expose it.
To summarize, static linking of most calculator detection code, program loading and utility functions (changing interrupt vectors, which includes the grayscale routine, etc.) was responsible for the magnitude of the breakage on the TI-68k series, when the V200 came out in 2002, and the 89T came out in 2004. Breakage would definitely have occurred even if "kernel"-based dynamic linking (after which libload is modeled, for good reasons) had been more popular - but not by the same amount.
A number of TI-68k "kernel"-based programs which follow best practices (i.e. not quite all of them, especially in the earliest days, where hard-coded addresses of system variables and suchlike dangerous practices were the norm...) made before the V200 can run unchanged on the 89T; on the static linking side, no pre-89T program which attempts to detect the calculator model, use grayscale (and more generally, launch other programs, and possibly a few other widespread practices that I forget about at the moment, works on the 89T.
Newer history of TI calculators show that hardware changes aren't few and far between: the Nspire CX has seen 23 hardware revisions in 5 years. Some of these were major.
Besides precluding forward compatibility, static linking also takes a toll on the storage requirements. Again, from the TI-68k series:
* screen saving code, which nearly all programs have ? Several dozens of bytes x n programs;
* grayscale routine ? The better part of 1 KB x n programs;
* working around an elusive, very hard to find bug in AMS's event loop (said workaround being grossly over-used because it's triggered by the usage of hundreds of ROM_CALLs, probably 90% of which are irrelevant, but oh well...) ? 100+ bytes x n programs.
One might say that TI breaking stuff once in a while, sometimes to optimize their costs (as shown by the "CR" phases), helps keeping a programmer community alive, for fixing stuff once in a while and making workarounds for closed-source programs. But that's a poor way to maintain a community. What about trying to do better now, and reduce work load later ?
I haven't used some of the other standard arguments against static linking, because they're largely irrelevant for our platforms.
Dynamic linking is no silver bullet against major hardware changes such as rotating the screen by 90°, but I nevertheless advise against knowingly, willfully squandering availability of current and future programs for the TI-eZ80 series, by using well-identified recipes for disaster (creating ticking time bombs) such as static linking
That's not what the static link flag does at all Kerm. It just statically links the C run time library rather than using the one in the bootcode. Just mainly for speed, as it clearly states in the makefile; even with comments and everything
Much better then