A new(old) SimpleIDE?

Rsadeika · 2012-11-20 05:24

Since jazzed let it out that the next SimpleIDE will not have Spin available, the way it is now anyway, when will we be seeing the next version of SimpleIDE, and when? I am also imagining that there will not be any new things added to SimpleIDE, otherwise it will not be called SimpleIDE.

I noticed, in another thread, that SRLM made a functional CODE::BLOCKS for PropGCC, has anybody made one for Eclipse, or another popular IDE? The reason I am asking these questions, I am starting to think along the lines of, one IDE that can handle multiple languages. For right now, I guess I can still put up with a separate IDE for Spin and PropGCC, but it is starting to be inconvenient, especially when you want to work in different OS's. It seems like we are going backwards around here, which may or may not be a good thing.

Thanks

Ray

Heater. · 2012-11-20 06:13

No worries about SimpleIDE. If Jazzed/Parallax does not put out a version of the next release that has Spin support I certainly will.
Seems it will be simple enough to build it from source with Spin support. No guarantee that it won't be broken in some way but know Jazzed it will work just fine:)

Edit: Linux only builds from me I'm afraid.

jazzed · 2012-11-20 11:34

SimpleIDE will have 2 modes for the next release: Simple View and Project View.

The modes hide/show items based on the view settings. Project View is more or less the same as what we have now. There will be a few new tools added and other small changes which were requested by Parallax.

The next release has very specific customer targets and Spin is not a requirement for them. There are some requirements for Spin that will be impossible to meet for the next release anyway. UTF16 support in Qt is a complication right now. The goal is to eventually have full Spin support.

Heater. · 2012-11-20 11:56

Call me old fashioned but I always thought the idea of using anything but 8 bit chars in source code was nuts. ASCII say.

Now I notice that the Go language source is exepected to be UTF-8. Perhaps other languages support this kind of thing. Which means you can do this in your source code:

&#936;det := &#936;.Det()

Which means of course that soon there will be source code like this:

if &#21654;&#21857; == &#20182;&#26159;&#25105;&#26368;&#21916;&#27426;&#30340;&#27468;&#25163; {
...bla bla
}

Which adds a whole new dimention to obfuscated code:)

Anyway, given that I know nothing of these internationalization efforts, could anyone summarise:
a) Why we need it?
b) What's the issue with UTF16 vs UTF8?

jazzed · 2012-11-20 12:27

Heater. wrote: »

Anyway, given that I know nothing of these internationalization efforts, could anyone summarise:
a) Why we need it?
b) What's the issue with UTF16 vs UTF8?

a) Why we need it?

To expanding reach in markets in Asia for example. As I understand it, comments are a translation of code in Chinese for example. GCC supports Chinese comments.

b) What's the issue with UTF16 vs UTF8?

Qt loading UTF16 is as slow as a man trying to push a 4 ton ball up a hill.

Once it's loaded it can be saved as UTF8, but I'm concerned about people losing their original version. UTF8 works nicely with the schematic characters as far as I can tell.

jnml · 2012-11-21 01:32

jazzed wrote: »

The next release has very specific customer targets and Spin is not a requirement for them. There are some requirements for Spin that will be impossible to meet for the next release anyway. UTF16 support in Qt is a complication right now. The goal is to eventually have full Spin support.

May I please ask about issue 60? I reported it some time ago and it's neither accepted or closed.

TIA

-j

ersmith · 2012-11-21 09:13

Heater. wrote: »

Call me old fashioned but I always thought the idea of using anything but 8 bit chars in source code was nuts. ASCII say.

Anyway, given that I know nothing of these internationalization efforts, could anyone summarise:
a) Why we need it?
b) What's the issue with UTF16 vs UTF8?

(a) Even for European languages there are more characters than fit in 8 bits. Unicode at last has made it possible to represent all of those characters (not to mention Asian languages, mathematical symbols, etc. etc.) in a standard way.

(b) UTF-8 is a strict superset of ASCII, which is very very nice for backwards compatibility -- if you're comfortable doing everything in English, you can just stick to ASCII and still be UTF-8 compatible. Similarly, lots of existing code written for ASCII will "just work" when presented with UTF-8 multibyte characters.

UTF-16, on the other hand, is not compatible with ASCII, since it represents characters in (at least) 2 bytes. With UTF-16 there are also endian issues (big endian versus little endian). Moreover, UTF-16 has a hidden trap in it -- it can represent *almost* all characters in 2 bytes, but a few of the rarer Asian or ancient language characters actually need 4 bytes (two UTF-16 code points) to represent. Most code doesn't handle this well, since people originally thought that 16 bits was enough for all characters (it isn't). UTF-8 has the same problem, but it's very obvious in UTF-8 and UTF-8 programs that don't deal correctly with multibyte sequences get discovered very quickly once you test them with anything outside of plain ASCII.

Eric

jazzed · 2012-11-21 09:42

jnml wrote: »

May I please ask about issue 60? I reported it some time ago and it's neither accepted or closed.

Sorry I didn't receive an email notice - not sure why. Someone else reported that problem and I looked at it briefly. It's important to handle of course, but my time has been consumed with Parallax requests. I'll put notes on the issue for you on where that piece is handled.

Thanks,
--Steve

A new(old) SimpleIDE?

Comments