Geekboy, Tari, and I are (very slowly) working on a wireless CALCnet adapter. We're not making it very discrete (as in invisible), though it is discrete (as in separate). You can see our languishing progress log here:
http://www.cemetech.net/forum/viewtopic.php?t=8265

I think I'll probably write a disclaimer to go with the program, just in case anyone is to use it for any dishonest practices.

BUMP!

[UPDATE #3 14/7/13] - Cleaning The Output Up...

Sorry that there hasn't been an update for a while, one, I have been very busy and two, I've been trying to make the output to the computer from the calculator reasonably clean. I can now say that I have succeeded in cleaning up the output, but a lot more work needs to be done.

I have found that the bridge program can detokenize capital letters, no problem, but when it gets to detokenization of lowercase letters and symbols I begin to have a problem in the form of a string of random letters. When you want to send a query to WolframAlpha, this is undesirable, so I will make it a priority to sort this.

I am, however unsure where to start. Kerm gave me this link over IRC.

Apologies for the lack of screenshot of the day today, I am not at the computer running the bridge.

DEVELOPMENT PRIORITIES

▪ Add extra token support
▪ Spruce up the GUI (Scrollbars, Icons)
▪ Get W|A AppID and begin to play with API using a python binding

It is very likely that this list will extend, but I don't want to overload myself with millions of goals all at once.

Stay tuned for further updates...

To detokenize, the code looks something like this:
Code:
Hope that helps.

[UPDATE #4 20/7/13] - GUI Sketches and Detokenization Progress

This rather crude biro sketch is a visualisation of what I would like the GUI to look like. There will be two screens (as pictured), the first to take the user's query and the latter to display the results. Note the use of a scroll bar to scroll through the pages of information.

In other news, development for the detokenizer function in the python bridge is well under way. Once it is finished, there will be support for upppercase letters, lowercase letters, numbers and a selection of symbols. These symbols are likely to be:

+ - / * π ! ^

However, it is highly likely that more will be added as the need arises.

Also, I have applied for my WolframAlpha AppID, so I can begin to have a poke around with python and W|A.

Finally, I'd just like to give a big thank you to Kerm and benryves who have been very helpful with technical support and terminology and have been extremely patient with me.

Full steam ahead with WAti!

You're most welcome, Electronics. Although some of the new programming skills and techniques might seem daunting now, you'll eventually get to the point where they seem blindingly obvious if you persist. Have you gotten a chance to test your detokenization routine yet, Electronics? Don't hesitate to post what you have if you get lost with it.

It isn't yet finished. I'm still populating the dictionaries. I must say, Kerm, your detokenizer pseudocode is actually really quite easy to understand if you examine it carefully, and understand the underlying concepts behind it (which I now do! ).

BUMP!
[UPDATE #5 21/7/13] - Symbols W|A Users Would Use (And Another Crude Sketch...)
The TI-OS has an abundance of strange and mathematically useful characters and symbols to aid every kind of mathematician, scientist and engineer, and with this in mind, which of these symbols will be essential to WAti users?

Pictured in the link below is the DCS7 keymap for symbols (once more, crudely drawn by myself)
http://img40.imageshack.us/img40/4596/63yz.jpg
This probably doesn't cover all of the symbols, but a lot of them are there. Most of these will probably be used in the detokenizer, along with numbers, capital letters and lowercase letters

My detokenizer function will need to take all of the symbols that I choose into account. At the moment, I am going through the painstaking process of putting all of the necessary tokens and their tokenized hex versions into a python dictionary.

For Example

Code:


On top of that, however, there will need to be some double byted character support (I'm talking chiefly about the lowercase letters in 0xBB more than anything), and in order to do that, I will need to use sub-dictionaries.

For Example

Code:


Once the necessary list of tokens is compiled into this dictionary form, development using Kerm's pseudocode for detokenization will begin. Hopefully compiling this list of essential tokens won't take too long.

As well as that, I am going to make a few more test DCSB Libs GUI programs, just so I know a little bit more about what I am doing with these libraries. An experiment with scroll bars will probably be worthwhile here.

If anyone has any ideas as to which symbols they would specifically like to see in WAti, do not hesitate to post your ideas. Bare in mind however, that I will be using DCS7's character set at the moment, considering that this project will use DCSB libs predominantly.

I would really really really really just suggest reading the TokenIDE XML file rather than putting it all into a dictionary by hand.

merth, I second that idea, but I don't know how to process XML in python. Perhaps I should read up about it.

JSON is significantly more lightweight than XML. Python, Perl and the others can read and write both XML and JSON just fine. But since there's already a set of XML token definitions, it can indeed make sense to piggyback it.

Can you propose a method of parsing these XML tokens?

The method of parsing the XML tokens depends on what you need to do with the data contained in the XML:
* I strongly doubt it applies to you, but when one needs an explicit representation of any element in the syntax tree or wants to perform several kinds of heavy refactoring in the tree, the solution is DOM. Web browsers provide a DOM interface to the HTML document.
* DOM is generic, but heavyweight. SAX is another method, where the parser uses the callbacks that you define (event-driven parsing), and you store stuff into your data structures in the callbacks' code. Parsing of complicated documents with SAX can be cumbersome due to the need for tracking the parsing state yourself (which element(s) the parser traversed before);
* for simply parsing a document with a well-known format, and creating your own data structures (hash tables, i.e. dictionaries), which is what I think you want to do, the best solution is StAX. Basically, since you know what the format of the document is, you tell the parser "now I want to read an element with name X", "now I want to read an element with name Y", and the parser gives you either an error or the element and its attributes.

As for the actual code and library to use in Python, well, I hardly speak Python (I prefer Perl), but the Internet does
There are certainly plenty of modules for parsing XML in Python, with differences in execution speed / RAM consumption. Any of them would be good enough for an XML file of up to several thousands of elements, though.

Google is your friend. This seems simple enough. Someone like elfprince or tari or someone else might know of a better lib.

I also have my scripts that turn Shaun's XML into big PHP arrays for SourceCoder3, which I considered slightly modifying to spit out a PHP dictionary for EGeek. I decided not to on the grounds that Electronics needs about 245 tokens at the most, not the 800-odd that the XML files contain. I'd be happy to do so anyway if you want the full set of tokens, EGeek.

I mean, if you make the loading general enough it should be able to take in any XML files, even if they're culled to just the 245 tokens he needs. This list should just be read in at start up each time, and why not just load in all the tokens?

You want ElementTree or lxml.

At least for SourceCoder3, it was too expensive to load all the XML files every time someone visited SourceCoder, incur all the overhead of starting up the XML parser, and so on. It turned out to be much more economical to have pre-parsed PHP versions of the files. For Electronic's project, I could see it being simpler and not that expensive to use an XML parser, given that the XML would only need to be started when the Python bridge was started, which needn't be often.

Thanks for all the info everyone. Regretfully, I will probably be 'computerless' until Friday (or Thursday for most of you, given the different time zones in which we all live). In that time, I'll play around with the GUI a bit more and get some flowcharts sorted.

Great. It sounds like you pretty much have the tokenization/detokenization sorted (or at least the concepts behind the processes), so it makes sense to move on to the design of the program flow. I hope that part will be relatively simple; I would expect so. Did you get your API key?