Priorities in the todo/wish list wrt. IDE and toolchain... - Page 1

Hey all,
(and welcome to those who have known of GCC4TI through ticalc.org )

A few weeks ago, we've requested, on multiple message boards (TIGCC/TICT, here, TI-Freakware), comments on whether to keep Windows 9x/ME support in TIEmu and TILP. We're now requesting comments on another aspect of TIGCC & GCC4TI: their set of tools, and organization (modularity, etc.) thereof.
Again, the reason why we're asking the community is that the community members can (and do) give us some input about what tools they currently use, and how they use them (perhaps in interesting ways that are not currently planned). They can (and do) also give input on what they would like to do.
In this post, we'll try to present things both from a user's perspective, and from the toolchain maintainers' perspective.


(if you don't feel like reading my large block of text, you can skip to the last paragraph )


In the current state of TIGCC / GCC4TI, there are multiple occurrences of code duplication. Both TIGCC and GCC4TI would like to solve the problem, in order to reduce maintenance and most of all, ease new development.

Let's go into more detail:
* IDE:
____* TIGCC IDE (Delphi) vs. KTIGCC 1 & KTIGCC 2 (C++).

* other tools:
____* tigcc command-line tool: there's a Delphi version for Windows and a C version for *nix...
____* ld-tigcc (TIGCC linker), ar-tigcc (TIGCC archive creator): used as a DLL on Windows, as standalone executables on *nix. The Delphi interface to the DLL sucks, triggers code duplication of its own, and makes further development harder...
____* patcher: this simple tool is embedded as Delphi code in both the Delphi IDE and the Delphi tigcc command-line tool. It's a standalone executable on *nix.
____* tprbuilder: overlap between the functionality of tprbuilder (written in C) and the TPR building code embedded in the Delphi IDE and KTIGCC 1/2 (written in C++). tprbuilders and the IDEs are not fully compatible, though: it's definitely possible to make TPRs that work in one kind of tools, but not in the other.


Advantages of the Delphi IDE:
____* users don't have to install a framework.
Drawbacks of the Delphi IDE:
____* Windows-only (though it runs on Wine - note that I have never tried communicating with an emulator or a real calc under Wine).
____* written in a lesser-known language, poorly commented code.
____* code is not modular at all, see "other tools" above. Let's also mention the Windows-specific emulator & real calculator linking code (which does not support some cable models).

Advantages of KTIGCC:
____* when both KTIGCC 3 and KDE 4 for Windows are ready, a single code base could work on both Windows and *nix.
Drawbacks of KTIGCC:
____* two incompatible code bases, both of which need to be maintained for a while because they have different sets of users:
________* KTIGCC 1: uses Qt/KDE 3.x, *nix only. Usable on GNU/Linux distros which focus on stability (e.g. Debian Etch, the upcoming Debian Lenny, and derivatives thereof). Given the rate of Debian releases (20-23 months for the three last releases), this should be maintained for more than two years;
________* KTIGCC 2: uses Qt/KDE 4.x, *nix only. Usable on GNU/Linux distros which focus on making their users test out the latest technologies (e.g. Fedora). Kevin wrote that KTIGCC 2 is not feature-complete, IIRC. KTIGCC 2 with fixes for non-portable constructs will become KTIGCC 3.
____* on Windows, and a number of GTK+/Gnome-based *nix, users have to install Qt and the KDE framework. On Windows (majority of the user base, as far as we can tell), kde4win is currently far from production quality...
Though KTIGCC 1 & 2 use external standalone executables, which is definitely a step forward, linking to emulators & real calculators is not externalized, and the functionality of tprbuilder is partially rewritten in C++.



To sum things up...
* KTIGCC is definitely a step towards more maintainable code. However, we (GCC4TI) feel that:
____* it's a leap backwards in the footprint of the TIGCC environment (we're talking dozens of megabytes of framework to run a small IDE which has few features that other IDEs don't have, and misses a number of features that common IDEs have...) and the complexity of the installation process. All the more there's already GTK+ for TIEmu and TILP, another *nix-originating framework that yields non-native applications.
____* it doesn't go far enough for modularity and flexibility.
* as a native program, the Delphi IDE is more user-friendly (native UI, no framework installation process). However, it's in dire need for a software re-engineering. No Delphi expert has manifested him/herself to aid in re-engineering...



In another (French-speaking) section of yAronet and on the GCC4TI feature request tracker (between others), we have discussed several ways to go forward from that situation:
* move enough things outside from the Delphi IDE so that it becomes little more than a graphical front-end to tools that do the actual work (and thus, it becomes rather low maintenance). This is a pattern commonly used on *nix, because it is well suited to both scripted use and interactive use, and yields low code duplication rates: let's mention only cdrtools, Sleuthkit, Nmap, MPlayer, Git and their graphical front-ends K3B/Brasero/etc., Autopsy, Zenmap, KMplayer, git-gui&gitk.
That embodies:
____* ld-tigcc, ar-tigcc, patcher (TIGCC and GCC4TI agree that all three should be external executables on all platforms, even if that means slower operation on Windows 9x/ME);
____* tprbuilder, to which a compatibility mode for the IDEs' behaviour should be added (so as to preserve backwards compatibility with both the IDEs' and tprbuilder's behaviour);
____* <to-be-named> application for emulator & real calculator linking. TILP's GUI-less mode can be a first step.
(and keep KTIGCC for *nix platforms, maybe with a bit of code de-duplication)


* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C++ with a dependency on Qt only. We lose some convenience classes, but we don't depend on something which won't work well for quite some time.
* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C#/.Net. Portability would be good (through the use of Mono), but from a user's POV, that's trading a non-default-installed framework with another non-default-installed framework (only a different group of people would be inconvenienced).

With the two latter solutions, it would be easier to introduce a better project format than TIGCC's proprietary build system (TPR) is, than modifying the existing code to try to handle both TPRs and a better project format. The general inflexibility (convoluted ways of doing things that are simple when using the tigcc command-line tool) and incompleteness (there are things that TPRs just cannot do) of TPR have been known for years to multiple developers. That's the topic of ticket #14, https://trac.godzil.net/gcc4ti/ticket/14 .



So, users... in your opinion, should we give up on lightweight IDEs for the Windows platform, even if KTIGCC 3 won't be too usable before months, or even a year ? (there are many other tickets on the todo/wish list, don't worry )
Is there someone knowledgeable in Delphi who would like to - and have enough free time to - help with re-engineering the Delphi IDE ?

Thanks in advance a lot for your feedback (and your contributions, if any)

Lionel Debroux (./1) :
Both TIGCC and GCC4TI would like to solve the problem

While in this case you're correct, please stop speaking for TIGCC, you are not allowed to speak on behalf of a team you aren't even part of.

And please also stop writing about "TIGCC/GCC4TI" everywhere, I'll collect my own data for TIGCC if I need it, thank you very much!

Lionel Debroux (./1) :
Drawbacks of the Delphi IDE:____* Windows-only (though it runs on Wine - note that I have never tried communicating with an emulator or a real calc under Wine).

Last I checked, TIGCC IDE was extremely buggy in WINE and couldn't even compile a project. It's not an option to be considered seriously. Not to mention that switching from a native GNU/Linux executable (KTIGCC) to WINE would be a major step backwards.

____* written in a lesser-known language

Lesser-known and proprietary. And there isn't even a free-of-charge version, except an ancient version (Delphi 6 Personal Edition) which generates executables incompatible with Vista and which isn't available anymore. And it can't be cross-compiled.

____* two incompatible code bases, both of which need to be maintained for a while because they have different sets of users:
________* KTIGCC 1: uses Qt/KDE 3.x, *nix only. Usable on GNU/Linux distros which focus on stability (e.g. Debian Etch, the upcoming Debian Lenny, and derivatives thereof). Given the rate of Debian releases (20-23 months for the three last releases), this should be maintained for more than two years;________* KTIGCC 2: uses Qt/KDE 4.x, *nix only. Usable on GNU/Linux distros which focus on making their users test out the latest technologies (e.g. Fedora). Kevin wrote that KTIGCC 2 is not feature-complete, IIRC. KTIGCC 2 with fixes for non-portable constructs will become KTIGCC 3.

Only one is needed and will be supported at a time (i.e. KTIGCC 1 will stop being supported as soon as KTIGCC 2 is ready). It is perfectly possible to install KDE 3 libs under KDE 4 or vice-versa. (In fact I'm shipping KTIGCC 1 in current Fedora just fine.) There are even KDE 4 libraries in Lenny (kdelibs5), though an updated version may (or may not, I'll see if there'll be any reason to require 4.2) be needed for the final KTIGCC 2.

____* on Windows, and a number of GTK+/Gnome-based *nix, users have to install Qt and the KDE framework.

A non-issue.

On Windows (majority of the user base, as far as we can tell), kde4win is currently far from production quality...

That will improve over time, it should already be much better when KTIGCC 3 will be ready.

linking to emulators & real calculators is not externalized

And that's by design.

____* it's a leap backwards in the footprint of the TIGCC environment (we're talking dozens of megabytes of framework to run a small IDE which has few features that other IDEs don't have, and misses a number of features that common IDEs have...)

I don't see the problem, really. Users these days stream or download many more megabytes of videos or music than KDE takes. It's downloaded in only a few seconds with a modern broadband connection.

and the complexity of the installation process.

The kdewin-installer is fairly straightforward.

____* it doesn't go far enough for modularity and flexibility.

That's an assertion I don't agree with at all.

In another (French-speaking) section of yAronet and on the GCC4TI feature request tracker (between others), we have discussed several ways to go forward from that situation:

All your solutions are not being considered for TIGCC at all (the first one is a non-solution, the other 2 are huge steps backward), so they'll lead to your "fork" becoming a radically different project with a completely different codebase.

* move enough things outside from the Delphi IDE so that it becomes little more than a graphical front-end to tools that do the actual work (and thus, it becomes rather low maintenance).

This is a non-solution because it doesn't solve the real problem: we still have a second codebase and it's still written in a proprietary lanugage I can't even compile. It also requires major rearchitecture of both the Delphi IDE and KTIGCC (if you want to actually share the code), and all the GUI code, which is obviously most of the code in an IDE, still needs to be duplicated (you can't put GUI code in a library shared between Delphi code and KDE code as they're using completely different GUI toolkits).

So TIGCC will never consider this solution, if you go down this road in GCC4TI, you're on your own.

This is a pattern commonly used on *nix, because it is well suited to both scripted use and interactive use, and yields low code duplication rates: let's mention only cdrtools, Sleuthkit, Nmap, MPlayer, Git and their graphical front-ends K3B/Brasero/etc., Autopsy, Zenmap, KMplayer, git-gui&gitk.

Some of your examples are really bad examples, for example the git GUIs all suck (you can't even clone/checkout a repository with them) and KMplayer doesn't look like an integrated application to the point Kaffeine (which uses xine-lib, an actual library) does.

And what you'll also notice is that all their dialogs of those frontends are inside the frontend. And as that's most of the code in the IDEs (hey, they already are frontends to GCC etc.), I don't really see much stuff left to externalize, so externalizing stuff isn't going to solve the code duplication problem at all.

____* ld-tigcc, ar-tigcc, patcher (TIGCC and GCC4TI agree that all three should be external executables on all platforms, even if that means slower operation on Windows 9x/ME);

Actually I only think patcher should be a standalone executable everywhere because I want KTIGCC everywhere, I don't think changing the Delphi code to an external patcher is that big a win (but it can't hurt if done properly, with no regressions). The broken link.dll interface is a bigger problem. Also note that the patcher is an extremely small piece of code (and should ideally go away entirely, GCC should just be fixed to output the right thing right away).

____* tprbuilder, to which a compatibility mode for the IDEs' behaviour should be added (so as to preserve backwards compatibility with both the IDEs' and tprbuilder's behaviour);

As I already wrote elsewhere, it is impossible or at least highly impractical (i.e. would need a second temporary directory, and there might also be other gotchas) to build the projects using tprbuilder because only the IDE knows the current version of the source files, which are not necessarily saved (!), so it has to be the IDE writing out the sources to the temporary directory. The current version of the project options, which are also not necessarily saved (!), is also only known to the IDE. tprbuilder also can't check which files have changed and which haven't, it just always rebuilds everything. The IDEs both have clever makefile-like logic for that. So it would be extremely hard to get this right and lead to something suboptimal (with 2 or more temporary copies of each source file), whereas the current compilation logic is already implemented and just works. So what would we have to gain from this?

____* <to-be-named> application for emulator & real calculator linking. TILP's GUI-less mode can be a first step.

I consider using the tilibs directly to be a better solution here (and the one I intentionally chose for KTIGCC). As I already wrote elsewhere, KTIGCC relies heavily on the libticonv anyway (and TIGCC IDE really should too if you want to keep it long term, currently it chokes on Greek letters almost everywhere), and it also uses the cable type enums from the libticables2 to store its configuration options internally. And it allows providing the libticalcs2 progress report callbacks to display a nice progress bar for the transfers. And the library interface is well-designed and just works, using an external executable instead would save almost no code (it might even require more code, especially if you want some solution for progress reporting).

* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C++ with a dependency on Qt only. We lose some convenience classes, but we don't depend on something which won't work well for quite some time.

IMHO this is a huge step backwards, you lose all the KDE classes and end up reinventing the wheel, you'll have a hard time to find an editor component comparable to the KatePart, you also get less nice file dialogs under X11 and you win... essentially nothing. And I also disagree about the "something which won't work well for quite some time". Something which still has some glitches left now, OK, but they'll get fixed.

So TIGCC will never consider this solution, if you go down this road in GCC4TI, you're on your own.

* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C#/.Net. Portability would be good (through the use of Mono), but from a user's POV, that's trading a non-default-installed framework with another non-default-installed framework (only a different group of people would be inconvenienced).

This is an inferior framework, you'll also have a hard time supporting Mono, especially if you rely on the WinForms (the alternative being GTK#, most Mono apps use that) and there are some patent concerns with Mono (for example it's still not included in RHEL, though RH grudgingly agreed to include it in Fedora).

So TIGCC will never consider this solution, if you go down this road in GCC4TI, you're on your own.

TIGCC's proprietary build system (TPR)

I'd rather call it "specialized". I don't see how it is proprietary, it's a nice clear INI format.

And please also stop writing about "TIGCC/GCC4TI" everywhere, I'll collect my own data for TIGCC if I need it, thank you very much!

1) I'll keep writing TIGCC/GCC4TI, especially for things that may apply to both code bases. The compatibility between both code bases will stay good, certainly.
2) You don't collect your own data, or at least, you disregard the data (VTI support, etc.).

As for ./3... thanks for giving your opinion
But it's just that, an "opinion". Have you noticed the number of times you wrote "I" in ./3 ?
As The_One_Guy and Peter Fernandes (hypersonic) have mentioned on ticalc.org, as maeyhem has mentioned on the TIGCC/TICT message board, as we have mentioned countless times on yAronet, your opinion, my opinion, or the opinion of everyone else, is not the universal truth. There can be people who disagree, and act otherwise. Learn to live with that.

Just two things:
* as we discussed in another section of yAronet, the behaviour of the TIGCC IDEs wrt. compilation in a temp folder and non-saved files is definitely uncommon for IDEs and build systems. tprbuilder can be modified to check which files have changed and which haven't, in order to avoid rebuilding everything in some cases.
* in France, "format propriétaire" is often used for a format that is understood by a single tool / toolchain. TPR and the help system files belong to that definition.

Lionel Debroux (./4) :
1) I'll keep writing TIGCC/GCC4TI, especially for things that may apply to both code bases.

Those things do not apply to both code bases. I am not interested in the feedback you're collecting at all (especially because your "options" are all non-options for TIGCC).

The compatibility between both code bases will stay good, certainly.

No it won't, because you're about to radically change the IDEs in GCC4TI, changes which TIGCC is not going to make (e.g. completely changing the way projects are built, and also introducing a new incompatible project format), whereas on the other hand in TIGCC, the plan is still to have KTIGCC be the only supported IDE, a move which you are not interested in making in GCC4TI. So the code bases will soon be very different, especially as it comes to the IDE(s).

Please speak for your project only.

2) You don't collect your own data, or at least, you disregard the data (VTI support, etc.).

Indeed, I wrote "if I need it" for a reason. The thing is, I don't need your data.

Stop trying to speak on my behalf.

As for ./3... thanks for giving your opinion
But it's just that, an "opinion". Have you noticed the number of times you wrote "I" in ./3 ?

But obviously it's all correct because you didn't bother replying (except for 2 minor details).

As The_One_Guy and Peter Fernandes (hypersonic) have mentioned on ticalc.org, as maeyhem has mentioned on the TIGCC/TICT message board

Again, please stop speaking on behalf of other people. I'm sure hypersonic won't appreciate you using something he wrote as an argument in your favor, and I really don't see how his only comment in the ticalc.org thread confirms what you're saying in any way.

* as we discussed in another section of yAronet, the behaviour of the TIGCC IDEs wrt. compilation in a temp folder and non-saved files is definitely uncommon for IDEs and build systems.

But it's how TIGCC works and it will not change in TIGCC.

tprbuilder can be modified to check which files have changed and which haven't, in order to avoid rebuilding everything in some cases.

To some extent yes, but it doesn't work for unsaved changes. The IDEs have additional logic to detect unsaved changes as a changed file.

* in France, "format propriétaire" is often used for a format that is understood by a single tool / toolchain. TPR and the help system files belong to that definition.

Call it the way you want, but there's nothing wrong with a "proprietary" format under that definition, the real problems with truly proprietary formats are completely different (obscure binary data which is hard to reverse-engineer, software patents etc.) and don't apply to the TPR format at all.

No it won't, because you're about to radically change the IDEs in GCC4TI

move which you are not interested in making in GCC4TI

We're not necessarily "about to" radically change the IDEs !
It seems that you have understood NOTHING about the point of this topic (and to a lesser extent, of the point of the fork)...


Your announcement, in a topic complaining about the unusable state of kdewin, that KTIGCC 3 would some day replace the Delphi IDE, despite the added footprint, was the trigger for an organized fork of TIGCC. Most of "us" ("us" includes some long-time yAronet members that were made aware of GCC4TI before the first release, but have not contributed code yet, like "troll" Flanker, as you labeled him on #tigcc) had disagreed for years with some of your opinions (it's our right !) and with the way you're managing TIGCC (multiple persons see a use for something, but realize, when discussing it with you, that you don't like it => it usually doesn't get implemented because we know you won't integrate it => progress retarded).
However, nothing, up to that announcement of yours, despite the obviousness of the lack of usability of kdewin (stability...), had made us take the great plunge.


Yes, maintaining the Delphi IDE for a longer period of time is part of the todo/wish list. Of course it is, it's the trigger of the fork.
The problem is, easing maintenance requires significant refactoring work for reducing code duplication and increasing modularity...
GCC4TI is something we do during our free time, like you do for TIGCC, so we'd better focus on things that are deemed important, shouldn't we ?
We're therefore explicitly asking the community to help us prioritize the todo/wish list. We have our own idea on it, but the community can (and should !) influence the todo list.
What if it turns out that all active TI-68k developers see no problem with having to install yet another framework, and wait months for you to make KTIGCC 3 ? Should we be bone-headed, or should we focus on other things ?

Please speak for your project only.

Stop trying to speak on my behalf.

Speaking on the TIGCC behalf (or "your behalf", it's the same thing and you're mixing freely the two), in posts where we're asking for community input, makes TIGCC sound more community-driven than it is. If you're unhappy with that, fine

But obviously it's all correct because you didn't bother replying (except for 2 minor details).

I like your sense of humour

KTIGCC 2 and then 3 would get done faster if you guys helped me with it.

KTIGCC 2 and then 3 would get done faster if you spent more time working on TIGCC.

Speaking on my own: you know that I'm pretty inexperienced in C++, and also that I don't know the Qt and KDE APIs... therefore, there would be quite a lot of catch-up for me before I could do something useful on the KTIGCC code.
I'd better concentrate on things that I'm more capable of making: I've made a working solution to #3 (that was easy, using a language that's well suited to the task), and started working on #20 (making ld-tigcc faster by using algorithmically better data structures), #32 (Vista trouble, reported by multiple persons), #33 & #34 (David Randall's feature requests). Not to mention that the manual building process of the GCC4TI first public release gave me some data for ticket #29 (build process automation)
On #32, I've done the work of getting a signature of the problem (ProcessMonitor captures), but I don't know the cause of the problem, and therefore, I don't know the solution.
On #33, the sucky ld-tigcc Windows interface makes things harder. On #33 and #34, no thanks to Kevin for making buggy tools that don't check user input, resulting in toolchain crashes or generated calculator programs that don't work, nor fixing the bugs in a timely manner


Oh, and it would be easier for us or anyone else to help you on KTIGCC if the code was better commented, BTW. This is yet another well-known good software engineering practice that you aren't following...
As it stands, the comment to code ratio in KTIGCC is far from being the best I've ever seen... Most files and functions don't have a comment to explain what they do, and the few such comments are not even in Javadoc/Doxygen-type format...
(this remark also goes for ld-tigcc between others, BTW)

ld-tigcc has a lot of comments. KTIGCC has few comments because most of the code is self-explaining, and also because I had to write it in a hurry to meet GSoC deadlines.

ld-tigcc has a lot of comments.

Indeed, I know that.
But your remark makes me understand that my paragraph didn't make it clear what was on my mind (in my mind, "this remark" applied only to the second part of the whole sentence, since ld-tigcc has comments, as you mentioned), so I'll give it a second try.

"
As it stands, the comment to code ratio in KTIGCC is far from being the best I've ever seen... Most files and functions don't have a comment to explain what they do, and the few such comments are not even in Javadoc/Doxygen-type format...
(That comments are not in Javadoc/Doxygen-type format, also goes for ld-tigcc between others, BTW)
"

That should be better.

Why should they be? It allows generating some external HTML documentation (which is yet another thing to consult for somebody wanting to modify the code), at the expense of readability of the comments (which get marked up with lots of @distracting @markup). I can see how such an external documentation makes sense for the public API of a library, but for the internal API of a program, it's much nicer to be able to read the comments within the code. Just look at the header file for the comments.

which get marked up with lots of @distracting @markup

They don't have to. The simple replacement of a series of // lines, or even a /* */ block, by a /** */ block, would improve a lot what Doxygen-type tools can yield with the ld-tigcc code.
Actually, we started doing just that, but the work isn't complete yet, so I guess that you don't see anything wrong with us not having committed it yet

which is yet another thing to consult for somebody wanting to modify the code

Do the comments within the code / header files tell about the call graphs within a program, which is very useful to grasp a program ?
Do the comments within the code / header files tell at a single glance about all places where a given field of a given structure is used ?

No and no. But knowing that at a glance was VERY useful to me for ticket #20 (optimizing ld-tigcc by using data structures more scalable than linked lists).
Yes, I could have resorted to vim + ctags/etags (none of which I know how to use), which make it slower to get the same kind of information (and in a form which is neither graphical nor automated, at that). What's the point of working like in the '70s ?

Profile the program with callgrind and you get all the callgraphs you want.

And what you're really looking for is the upcoming KDevelop 4's definition-use chains.

Profile the program with callgrind and you get all the callgraphs you want.

What a stupid suggestion...
Getting a callgraph that does what I want would require that all code paths are exercised in a given execution of the program, and it obviously isn't so: for example, if one's outputting a Flash OS, then a number of other export chunks are not exercised.

I'm using callgrind, but much more for getting performance information than for getting runtime callgraphs. If I just want runtime callgraphs (which I've hardly ever done so far), I can use lower-key, faster approaches such as http://www-128.ibm.com/developerworks/library/l-graphvis/
Heck, if Linux had a good tracing option for user-space programs, I could even use DTrace-type programs to do that.

And what you're really looking for is the upcoming KDevelop 4's definition-use chains.

Maybe, though Doxygen did the work for me so far.
But anyway, I'm not using KDevelop, and it will be quite some time before I'm switching to KDE 4...

* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C++ with a dependency on Qt only. We lose some convenience classes, but we don't depend on something which won't work well for quite some time.

This would be my preference, as long as it was using Qt 4. In my experience, Qt 4 apps fit in nicely wherever I run them (Windows, GNOME, Mac OS X) while Qt 3 and KDE 3/4 apps stick out like a sore thumb. (And gtk+ apps on windows aren't that pretty, either). I will probably be starting on a project in Qt 4 at some point next year, so I may be able to help with some of the coding if you decide to go this route.

Aaaah, someone goes in to give a piece of the feedback we're seeking for
We were thinking of Qt 4 instead of Qt 3, indeed.

I will probably be starting on a project in Qt 4 at some point next year, so I may be able to help with some of the coding if you decide to go this route.

Good to know.