A question to ask - TIGCC Programming - Active Forums - TI-Chess Team HQ - Message Board - Message Board - Yuku

RSS
Email

0 Kudo

<< Previous Topic Next Topic >>

A question to ask

Author	Comment
xcvista	A question to ask	Lead	[-]
Posts: 1 (2009-05-07 16:30:00) More My Recent Posts Message Me Connection Blocking Invite Report Post	I am a programmer of Visual Studio, and a lover of TI programming. I Do hope to combine them - transfer TIGCC for Windows into Visual Studio 2008, as a programming language. And, with the famous Microsoft IDE, a lot of work may be saved as the IDE provided itself.
Lionel Debroux		#1	[-]
Posts: 3021 (2009-05-08 09:35:13) Former Admin More My Recent Posts Message Me Connection Blocking Invite Report Post	Short answer: the TIGCC building system isn't designed to be (depending on whom you ask, you can get is designed and implemented so as not to be) embedded into any other IDE than the Delphi TIGCC IDE or its C++/Qt/KDE KTIGCC reimplementation. The IDEs have a monolithic implementation of a building system specific to TIGCC ("TIGCC Projects", TPRs for short). This building system has at least two capabilities (ability to compile unsaved files; "virtual folders"), which make it unlike most other building systems. This difference with other building system makes some people consider those capabilities as bugs. In the previous paragraph, "monolithic" means that there is a TPR building logic built into the IDEs, instead of it being entirely in an external executable (which would be the classic way of implementing scriptable things: graphical front-ends to command-line tools). There is also an external executable, tprbuilder, but it has never supported "virtual folders" the exact same way the IDEs do. As a result, it's fairly easy to create TPRs that work with the IDEs but don't work with tprbuilder, and vice-versa. There are at least three ways to fix the incompatibility between tprbuilder and the IDEs: * favor TPRs that work with the IDEs, break TPRs that don't work with the IDEs. Not very kind to users, because both flavors of TPRs have coexisted for years. * favor TPRs that work with tprbuilder, break TPRs that don't work with tprbuilder. Worse than the previous solution, because TPRs that work only with tprbuilder are less common than TPRs that work only with the IDEs. * add an "IDE compatibility" mode to tprbuilder, refactor the IDEs. This is the route I took a few days ago, in order to fix a 32/64-bit compatibility bug in TIEmu without disrupting users switching from 32 bit to 64 bit *nix computers. Nobody has yet tackled the task of healing the TIGCC build system. We can help you if you wish tackling it, but I can already tell you it might not be that smooth of a sailing
xcvista		#2	[-]
Posts: 2 (2009-05-08 10:39:53) More My Recent Posts Message Me Connection Blocking Invite Report Post	I recommend VS IDE because perhaps some features included only in TIGCC may also present in VS IDE - like Virtual Directorys in TIGCC may be translated into Namespaces, or even project references in VS IDE. And also, VS IDE have a powerful support of devices, orignally designed for PDA's, can be used for TI calculators, of course, after adapting it. In addition, the device emulator orignally included in VS IDE emulates an ARMv4 or an ARMv5 processor - exactly used in TI n-spire series. This also provides a 'extra' compability to those calcs. Anyway... Do you program in .net? If the answer is YES, would you like to help me translate TIGCC into managed code? And also, I would like to make some programming language different than C for TI calcs - like Visual Basic or Visual C#. Can you help? Perhaps a "Visual Studio 2008 TI Edition" will be made based on isolated VS2008 shell, and a set of TI programming languages, include the traditional C for TIGCC, Visual Basic and Visual C# with limited library, even simulated TI-BASIC, and all based on VS2008
Kevin Kofler		#3	[-]
Posts: 7002 (2009-05-08 11:17:16) Admin More My Recent Posts Message Me Connection Blocking Invite Report Post	As I answered you per e-mail, you'd have to rewrite the code from scratch if you want something which integrates into Visual Studio, both for technical reasons and for licensing reasons: making a Visual Studio plugin out of TIGCC IDE's or KTIGCC's code violates its GPL license. As I also already answered you per e-mail, I am not interested in Visual Studio integration at all, and in any case it can never be the official TIGCC IDE. Proprietary dependencies are a definite showstopper. And even if it wasn't proprietary software, integrating into another IDE is likely to give an inferior result, lacking many of TIGCC IDE's specific features and cluttering the UI with stuff which is completely irrelevant for calculator development. This topic ("Why a standalone IDE? Why not 'just' write a plugin for IDE X?") comes up regularly, but the people who ask always miss the point: 1. The "IDE X" which comes up varies. I've seen people suggest Eclipse, Code::Blocks (those are at least serious suggestions as they are Free Software and cross-platform), Visual Studio, XCode (those are not, proprietary single-platform solutions are useless for TIGCC!) and more. So if the TIGCC IDE was a plugin for IDE X, people would undoubtedly still whine about it not being a plugin for IDE Y. 2. Those IDEs have a feature set which is not geared towards calculator development. You may be able to add some of the features, but not those which depend on the internals of the TIGCC toolchain, and you cannot easily hide or remove the features which make no sense for calculator development. like Virtual Directorys in TIGCC may be translated into Namespaces, or even project references in VS IDE You don't seem to understand how virtual directories work at all. And also, VS IDE have a powerful support of devices, orignally designed for PDA's, can be used for TI calculators, of course, after adapting it. I doubt it. In addition, the device emulator orignally included in VS IDE emulates an ARMv4 or an ARMv5 processor - exactly used in TI n-spire series. This also provides a 'extra' compability to those calcs. This is completely useless as there's no way to run compiled code on the TI-Nspire at all, so it's impossible to support it in a toolchain. And even if that changes, it would need a completely separate toolchain. TIGCC is only for the 68k. Do you program in .net? No. would you like to help me translate TIGCC into managed code? No. We are not interested in your project. If you want to do it, do it on your own, and without using any of our code because linking it into the proprietary Visual Studio violates its license. And stop spamming us through all possible channels (IRC, e-mail, message board).
Kevin Kofler		#4	[-]
Posts: 7003 (2009-05-08 11:25:41) Admin More My Recent Posts Message Me Connection Blocking Invite Report Post	And for Lionel: * favor TPRs that work with the IDEs, break TPRs that don't work with the IDEs. Not very kind to users, because both flavors of TPRs have coexisted for years. ... except nobody except you uses tprbuilder-only .tpr files and you're exploiting a bug in tprbuilder, so it's normal that they'll break at any moment. That said: * add an "IDE compatibility" mode to tprbuilder Having 2 modes is something I can do, but the IDE-compatible mode will be the default. And you're spamming this discussion in any topic which is even remotely related with it, please stop, I got your point!

<< Previous Topic Next Topic >>