Reminder to Kerm. lol Expandable program editor window.
Also noticing that when clicking on a command in the right window (like Horizontal), it pastes 15 of them in a row, not just one.
BlackOnyx wrote:
[...]
Also noticing that when clicking on a command in the right window (like Horizontal), it pastes 15 of them in a row, not just one.
That is exactly what my previous post was about, how to fix that
Sorunome wrote:
About the problem with multiple tokens appearing per click:
You only add event listeners to the token clicking, triggering multiple, same, events on clicking on it.
All you do is add the clicking event (line 498) but I fail to see where you remove it, you'll have to remove it when the user switches the token pannel.
Reference for that:
http://api.jquery.com/off/
Hope this'll help you out
EDIT: maybe do instead tdir.off('click','.clk').on('click', '.clk'
I believe that this did the trick. Can people please test that it's fixed for not just me?
Edit: Current pending bugs and feature requests.
Known Bugs:
[ ] Things like A<|LMINE(1) turns into the <| symbol. How to fix?
[ ] Comments and \s don't get saved in the project list. What to do?
[X] Image dimensions don't seem to be displayed at all. I only get: "Dimensions: x px" Wasn't properly handling non-textareas
[X] Bitmaps don't seem to work at all.
[X] Google Chrome makes token strings be emitted 2 or 3 times. Believed to be repaired by Sorunome's fix
Feature requests:
[ ] Add/create AppVar
[ ] Drag-n-drop all filetypes
[ ] Import old SourceCoder files (might not be done if insufficient size)
[X] Automatic pausing of jstified when hidden; possibly optional. I don't think I would ever disable it, but perhaps someone might want their code to work on a large computation for a while as they continue to code more.
[ ] A more Axe-friendly hexadecimal image output. The data spit out already is correct, but ideally (for small images, at least) it should be formatted just as one long string rather than split across multiple lines, and possibly enclosed in square brackets. The square brackets enclose hexadecimal data in Axe, but it's probably easy enough for a user to add the opening and closing brackets.
[ ] User-resizeable code box
[ ] Export .8xi and other image formats
Edit #2: Automatic pausing of jsTIfied is now done, and jsTIfied starts as paused when jsTIfied first loads, thanks to cleverness with the sc3_present variable.
Edit #3: Loading bitmap images now works. Here's some proof, from a random 32x32-pixel BMP I found using Google Image Search. I used det(9) in Doors CSE to display it.
I can confirm the multiple token bug to be fixed, using google chrome.
KermMartian wrote:
[ ] Things like A<|LMINE(1) turns into the <| symbol. How to fix?
Change the <| token to something else
Well, I suspect that <|L is not the only ambiguity. How do you solve this is TokenIDE? Do you detect ambiguities?
The same thing would happen in TokenIDE as happens in source coder. I underline the token so it's obvious what will be tokenized:
but detecting the ambiguities is hard.
merthsoft wrote:
The same thing would happen in TokenIDE as happens in source coder. I underline the token so it's obvious what will be tokenized:
but detecting the ambiguities is hard.
I see, you underline all contiguous multi-character tokens, then? I really should consider making that part of my syntax highlighter, once I create one. I think if I had that underlining, it would make me happy enough to not worry much about ambiguities in the actual detokenized text. I still need to think about storing programs, strings, and appvars as plaintext, though, in order to avoid discarding the \s and the comments. My goal with storing binaries instead was to ensure people weren't using SourceCoder to store arbitrary text files. Then again, I guess almost all reasonable non-unicode text can be tokenized for the calculators.
Yup. I figure the performance loss of checking for all possible ambiguities isn't worth it--you just need to be aware of what's going on as a programmer.
Sounds really cool! I'm looking forward to this.
Smiley-Faces-88 wrote:
Sounds really cool! I'm looking forward to this.
Actually, you can already try it out if you want; the URL isn't exactly a secret any more.
merthsoft wrote:
Yup. I figure the performance loss of checking for all possible ambiguities isn't worth it--you just need to be aware of what's going on as a programmer.
Thanks, then I'll direct my effort into delineating tokens in the code view rather than try to detect ambiguities at the parsing phase. I'll still have to remember to switch to storing program text instead of binaries, but that's a trivial issue compared with detecting ambiguities or annotating token boundaries. Thanks for the expertise.
Edit: although the controls are messily arranged, you can now type part of a token to search for it.
*bump* Over the course of the day, I gradually implemented the necessary pieces to add exporting images, a feature I pulled over from SourceCoder 2.5 and greatly improved. You can export .8xi, .8ci, and .8ca files from any image (SC2.5 could only export if the image had the same dimensions as the calculator picture/image format). You can choose to fit the original's width or height, center the original, or stretch the original (SC2.5 could do none of these). You can choose the Pic or Image number to export to (SC 2.5 always used Pic2 and Image2). This is one of the last pieces I needed to put in place before SourceCoder 3 replaces SourceCoder 2.5 as the default SourceCoder, the final pieces being importing SC2.5 projects properly and fixing up the UI a bit.
Known Bugs:
[ ] Things like A<|LMINE(1) turns into the <| symbol. Fix by syntax-highlighting token boundaries
[ ] Comments and \s don't get saved in the project list. Save plaintext of tokenized formats (strings, equations, programs, appvars)
Feature requests:
[X] Export .8xi and other image formats
[X] Neaten up interface, put token search with token pane
[X] Update project contents list when item name changes
[ ] Make project pane expand on hover.
[X] Make lists and matrices resizeable
[ ] Add/create AppVar
[ ] Drag-n-drop all filetypes
[ ] Import old SourceCoder files (might not be done if insufficient size)
[ ] A more Axe-friendly hexadecimal image output. The data spit out already is correct, but ideally (for small images, at least) it should be formatted just as one long string rather than split across multiple lines, and possibly enclosed in square brackets. The square brackets enclose hexadecimal data in Axe, but it's probably easy enough for a user to add the opening and closing brackets.
[ ] User-resizeable code box
[ ] Add server-side tokenization code for numerical types (numbers, lists, matrices)
Edit: Lists and matrices are now resizeable, and new lists and matrices are created with a default of one element instead of zero. Resizing lists and matrices took a lot more code than I anticipated, mostly in terms of validating the dimensions entered.
It's awesome to see progress going again on this fantastic online editor.
Still quite the list of things on the TO DO list, eh? I'll see if I can find some time soon to test some of these functions.
tifreak8x wrote:
It's awesome to see progress going again on this fantastic online editor.
Still quite the list of things on the TO DO list, eh? I'll see if I can find some time soon to test some of these functions.
Thanks! Luckily all I really want to do before declaring this a beta is fix how the project pane gets displayed and fix importing SC2.5 projects. Then, once it's public, I can worry about things like proper syntax highlighting, counting While/Repeat/For/Ends, and the other bits of shiny I want to add.
Edit: After wrestling with CSS and HTML for about two hours, I made the project contents appear when you hover over the project pane header. How should I make it visually clear that you can hover over it? If you're not sure what I mean, please try opening a group in SourceCoder 3. I also made the Open Saved Projects list a bit spiffier, namely multiple columns of 10 projects each, which can be scrolled horizontally.
Known Bugs:
[ ] Things like A<|LMINE(1) turns into the <| symbol. Fix by syntax-highlighting token boundaries
[ ] Comments and \s don't get saved in the project list. Save plaintext of tokenized formats (strings, equations, programs, appvars)
[ ] Fix saving/exporting single files vs projects (need different buttons?)
Feature requests:
[X] Export .8xi and other image formats
[X] Neaten up interface, put token search with token pane
[X] Update project contents list when item name changes
[X] Make project pane expand on hover.
[X] Make lists and matrices resizeable
[X] Fix SC3 projects displayed as "unknown" projects
[X] Import old SourceCoder files (might not be done if insufficient size) -> Specifically, convert all the wacky HTML tokens -> Or just export the SC2.5 project as a binary and import the binary
[ ] Export full projects to jsTIfied as group or multiple files
[ ] Import program from jsTIfied
[ ] Make projects renamable: click to rename
[ ] Add/create AppVar
[ ] Drag-n-drop all filetypes
[ ] A more Axe-friendly hexadecimal image output. The data spit out already is correct, but ideally (for small images, at least) it should be formatted just as one long string rather than split across multiple lines, and possibly enclosed in square brackets. The square brackets enclose hexadecimal data in Axe, but it's probably easy enough for a user to add the opening and closing brackets.
[ ] User-resizeable code box
[ ] Add server-side tokenization code for numerical types (numbers, lists, matrices)
Edit #2: Implemented converting SourceCoder 2.x projects into SourceCoder 3 projects, complete with a warning to double-check that the conversion succeeded.
Opened up the data file for LibHelp. It wasn't overly happy about it at first. lol It took a few seconds to process it all.
Also, it seems that anything after a ; is a brownish color.
Would it be possible to have it display the size of the program/appvar/etc, and only update when someone clicks on a refresh button for it to look through the source again?
Yes, my syntax highlighting is quite incomplete; that's my next todo item. I'm currently changing how token lists are sent from the server to the client to make hinting and completing tokens easier, then I'll be able to do sane syntax coloring. Yes, that would be entirely possible; I'll add it to my todo list.