Rayman, one question... are you going to publish your code somewhere ?
It is not that I want to look at it, it is that with the loss of BST's source code a (imho) great loss happened, shouldn't happen again.
Usually, I'd say no. But, I'm leaning towards making an exception in this case. Mostly because it's mostly somebody else's code. I just played around with the colorizer a bit...
It is now in P2 mode with open and save file enabled.
Added some code to speed up screen updates. Was getting bogged down when file size got big before.
Added font sizing using ctrl-wheel, like Prop Tool.
Publishing this source code might be tricky. I uses an edit control by Chris Losinger and there is no license attached to it specifying how it may be used or distributed.
Mind you, the same can be said of any binary executable that includes that code.
/*********************************************************************
Copyright (C) 2001 Smaller Animals Software, Inc.
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Main thing that bothers me right now is that you can have multiple background colors on a single line in the Prop tool, but not with my code.
This could be fixed by creating a list of multi-colored lines and then drawing them specially.
But, I don't feel like doing it because I think it's bad style...
Can we define Spin2 to only recognize the first section keyword on a line?
The Spin compiler will only recognize the section keywords as the first thing on a line. It will give you an error for any section keyword parsed that doesn't start on column 1.
So, while you can type that mess into PropTool and see it colored that way, it shouldn't compile.
It's fine if your editor does not color them the same as PropTool, since it's invalid. In fact, it's probably better to have it not coloring it like PropTool does, since it visually signals that something is wrong.
Is there a way to capture the response of the compiler and parse for error on line number xxx then highlight the line number or scroll to the line number and indicate the line number. Or at least show the line number in a text box.
The Spin compiler will only recognize the section keywords as the first thing on a line...
Thanks Roy! That helps a lot.
I was about to say it's done, but just noticed that VAR and OBJ have different keywords than PUB and PRI.
I think CON might be different as well...
Guess I'll just paste all the keywords in the Prop Tool and see what highlights...
Is there a way to capture the response of the compiler and parse for error on line number xxx then highlight the line number or scroll to the line number and indicate the line number. Or at least show the line number in a text box.
Good news! The app seems to work great in Wine Not sure if I'm using the latest one or not (it's the one in your first post), but it seems to be highlighting things nicely and not crashing, which is generally a win for any app in Wine :P
Another nice thing about BST was folding. That might be tricky but it is really nice to fold up the code so you only see the method names until you click on the method name then the methods code expands.
This is really exciting, @Rayman! I was able to get it to run under Wine as well, although since I don't have the Propeller font the text didn't come out very well (letters were overlapping sometimes). Probably not something to worry about for a long time, if ever.
I didn't see a menu option to compile or run. Did I miss it, or is that still on the TODO list?
Then you have a thing. A project. Everyone will know were to find it. It will be easy for people to find the latest version. Quite likely people will turn up to contribute code for new features or bug fixes. At least they will have a place to report bugs, in github's issue tracker for example.
Generally I have a downer on people producing platform specific code. In this case Windows. It's not so hard now a days to create code that can be built for Windows, Mac and Linux. And others.
However, as a long time Linux user I also harbor an evil thought... Perhaps sometimes the simplest, easiest way to create a program that anyone can use is to stick to the old Windows API's. Then you have a single build of your program that will run on Windows and all the thousands of different Linux systems thanks to Wine. No doubt the Mac guys have a way to run it as well. No need to make specific builds for different operating systems, no need to rely on Linux distro package maintainers to support it.
A prime example of this is one of my favorite programs of all time, the LTSpice circuit simulator by Linear Technology. That is a big and complex application that has always worked flawlessly under Wine. I suspect Linear goes out of their way to ensure that is always so.
Well, blow me down. Just an hour or so after my expounding on my "evil" thoughts about writing to the Win32 API as a good way to make cross-platform software, I find this from a couple of days ago by Bryan Lunduke:
Although written for Windows, I think you'll see most of the original code was just standard C++, outside of the GUI drawing. I would think the GUI part could be fairly easily reproduced in Qt.
So, even if this code isn't inherently cross-platform the colors, data, and logic is there for someone who wants to make it cross platform...
Of course, my stuff has a lot of MFC, like CString, for example. But, it's not too hard to fix that or use Qt equivalent...
I'm getting the interpreter tuned up. It's 95% done. I still have compiler work ahead. It's all going to work really nicely. Compact, fast, and potent.
Getting the serial ports working on Linux should not be a problem.
Thing is WINE is not an emulator. It's not just for running compiled Windows executables. There is libwine the library that implements the Win32 and other Windows API's and there is wine that loads and runs Windows binaries.
One can actually compile Windows programs using GCC on Linux, linking them with libwine and then run them like any other Linux program. Without actually going near any actual Windows machine. Years ago I did exactly that as an experiment. My simple Win 32 program with buttons, dialog boxes and such compiled and ran without fuss. It was kind of spooky.
So, given that you release the source code some kind soul might take up the challenge of adding Linux serial port support.
From the libwine documentation:
What you gain by recompiling your application with Winelib is the ability to make calls to Unix APIs, directly from your Windows source code. This allows for a better integration with the Unix environment than is allowed by running an unmodified Windows application running in Wine. Another benefit is that a Winelib application can relatively easily be recompiled on a non-Intel architecture and run there without the need for a slow software emulation of the processor.
Comments
Will be interesting to see if this slows down this editor...
It is not that I want to look at it, it is that with the loss of BST's source code a (imho) great loss happened, shouldn't happen again.
It is now in P2 mode with open and save file enabled.
Added some code to speed up screen updates. Was getting bogged down when file size got big before.
Added font sizing using ctrl-wheel, like Prop Tool.
Mind you, the same can be said of any binary executable that includes that code.
/********************************************************************* Copyright (C) 2001 Smaller Animals Software, Inc. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution.This could be fixed by creating a list of multi-colored lines and then drawing them specially.
But, I don't feel like doing it because I think it's bad style...
Can we define Spin2 to only recognize the first section keyword on a line?
So, while you can type that mess into PropTool and see it colored that way, it shouldn't compile.
It's fine if your editor does not color them the same as PropTool, since it's invalid. In fact, it's probably better to have it not coloring it like PropTool does, since it visually signals that something is wrong.
Thanks Roy! That helps a lot.
I was about to say it's done, but just noticed that VAR and OBJ have different keywords than PUB and PRI.
I think CON might be different as well...
Guess I'll just paste all the keywords in the Prop Tool and see what highlights...
That should be straightforward, we'll see...
Also, there's a nasty bug in Prop Tool where parenthesis characters in VAR section mess up the background color...
I've heard that basic MFC apps work pretty well under Wine...
I'm going to try to force myself to post the code today (before I get too attached to it)...
I didn't see a menu option to compile or run. Did I miss it, or is that still on the TODO list?
Thanks,
Eric
But, I also made it a P1 editor along the way.
As of now, it's just a very basic text editor.
But, I've seen code I can borrow to make it compile and run Spin2.
Better to put it into a git repository and push it to github https://github.com or bitbucket https://bitbucket.org
Then you have a thing. A project. Everyone will know were to find it. It will be easy for people to find the latest version. Quite likely people will turn up to contribute code for new features or bug fixes. At least they will have a place to report bugs, in github's issue tracker for example.
Generally I have a downer on people producing platform specific code. In this case Windows. It's not so hard now a days to create code that can be built for Windows, Mac and Linux. And others.
However, as a long time Linux user I also harbor an evil thought... Perhaps sometimes the simplest, easiest way to create a program that anyone can use is to stick to the old Windows API's. Then you have a single build of your program that will run on Windows and all the thousands of different Linux systems thanks to Wine. No doubt the Mac guys have a way to run it as well. No need to make specific builds for different operating systems, no need to rely on Linux distro package maintainers to support it.
A prime example of this is one of my favorite programs of all time, the LTSpice circuit simulator by Linear Technology. That is a big and complex application that has always worked flawlessly under Wine. I suspect Linear goes out of their way to ensure that is always so.
So, even if this code isn't inherently cross-platform the colors, data, and logic is there for someone who wants to make it cross platform...
Of course, my stuff has a lot of MFC, like CString, for example. But, it's not too hard to fix that or use Qt equivalent...
I'd bet serial port code in WIN32 would not work under Wine (but maybe I'm wrong).
https://www.onetransistor.eu/2015/12/wine-serial-port-linux.html
But, that may not give you access to do DTR line. Or?
I'm getting the interpreter tuned up. It's 95% done. I still have compiler work ahead. It's all going to work really nicely. Compact, fast, and potent.
Getting the serial ports working on Linux should not be a problem.
Thing is WINE is not an emulator. It's not just for running compiled Windows executables. There is libwine the library that implements the Win32 and other Windows API's and there is wine that loads and runs Windows binaries.
One can actually compile Windows programs using GCC on Linux, linking them with libwine and then run them like any other Linux program. Without actually going near any actual Windows machine. Years ago I did exactly that as an experiment. My simple Win 32 program with buttons, dialog boxes and such compiled and ran without fuss. It was kind of spooky.
So, given that you release the source code some kind soul might take up the challenge of adding Linux serial port support.
From the libwine documentation:
What you gain by recompiling your application with Winelib is the ability to make calls to Unix APIs, directly from your Windows source code. This allows for a better integration with the Unix environment than is allowed by running an unmodified Windows application running in Wine. Another benefit is that a Winelib application can relatively easily be recompiled on a non-Intel architecture and run there without the need for a slow software emulation of the processor.
https://wiki.winehq.org/Winelib_User's_Guide#What_is_Winelib.3F
If you double-click on a section in the tree, the main view jumps to that line.
I'm thinking about changing the icons in the tree so they have matching colors to their respective section...
I think this can replace the "Summary" view of the Prop Tool... Might be even better as you can keep it open all the time...