Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: beqroson on November 05, 2013, 08:18:20 pm
-
Hello everybody,
Congrats to the development of the CodeBlocks application, which I partly admire (I could create a list of admirations and things that still lack ;) , but I will not). I am a newcomer and I respect that fact. However, there has been an idea bugging my mind for at least a year now. I would like to present this idea in this topic on this forum as I believe it would be appropriate. For all ideas, there is "someone" that must "do it". Now, that may be solved, possibly, by me contributing my share to the codeblocks application, if the idea takes off.
The general idea is to enable that any programming language should be possible to use with very little preparation in the codeblocks IDE. I am not talking about just C++, but ANY language. By this I mean compiling, code-completion, hightlightning, everything that a developer needs. Now, the IDE already supports many languages, but that is not the point. Any language could also, by customizing the IDE, be implemented, but that is neither the point.
Now, my idea is more specific than the general idea, but let us come back to the specific idea when some opinions about the concept above has been let out. I know that there can be issues about implementing and so forth, but let us take one opinion at a time.
/Beqroson
-
I am responding myself to my post. I was content this is the right forum tab for this subject. Now I was less sure, moderator, if you find another forum tab better, feel free to move it.
Thanks
-
I'm really interested in reading your idea as soon as you share it in this forum. Even though expanding an IDE to support multiple languages create extra problems, I would say that supporting only 2 or 3 the most is the ideal thing.
If I am not mistaken, they are in the process to add Python support too, which is more than awesome IMO (because I use it myself), but supporting multiple languages? That would be very challenging to keep up to date and maintainable.
Let's see how things will evolve in the meantime.
-
I would say that supporting only 2 or 3 the most is the ideal thing.
How come? I mean, let us suppose an IDE that is targeted at supporting those 2-3 languages, but which has the bonus of being able to support ANY language with only a little extra cost? I am not guaranteeing it is implementable, but then again, I see no obstacle. Although, why do you want to "cripple" the IDE to only support those 2-3 languages and no more? Any specific reason?
-
Although, why do you want to "cripple" the IDE to only support those 2-3 languages and no more? Any specific reason?
Because we use a single language in our day work and we don't care for the others much. Is this enough for a reason?
If you have a favourite language that is not supported you can:
1. look at the C::B's code
2. start making changes, so the support is improved or possible.
3. post a patch or better series of patches
4. fix reported problems and don't be afraid of criticism
Expecting that we'll start doing changes to our SDK (without a specific requirements) in order to support random/every language is optimistic.
On the other hand: we're working on better SDK for CC plugins, so in the future it will be possible to CC for any language there is a plugin written.
But the internal build system is tightly coupled with the C/C++ way of building projects and I don't see this changing soon.
Of course we have custom makefile support, so C::B could build anything make could build.
-
This sounds a little like Fermat's last theorem. "I have a proof for this, but there's not quite enough room in the margin of this notepad..." And it was finally solved using what can only be described as a brute force approach.
I think we are open to having the IDE support multiple languages (but the developers certainly vary in their level of interest), and we've taken many steps in that direction. The editor syntax highlighting works for whatever languages Scintilla supports, the build system is very flexible and can be configured to support a wide range of compilers and languages. We have a pretty flexible API for supporting debugging via plugins (I have written a debugger plugin for python using it) and we are well on the way to doing the same for code completion (I have a partially working plugin for python). But that still leaves a LOT of work to write all of the interfaces for language you would hope to support. So you really need to tell us more about what you have in mind ...
-
On the other hand: we're working on better SDK for CC plugins, so in the future it will be possible to CC for any language there is a plugin written.
If you are curious, this thread (http://forums.codeblocks.org/index.php/topic,18114.0.html) contains some details.
-
First off, thanks for the response. I know your time is limited between all the forum posts.
Because we use a single language in our day work and we don't care for the others much. Is this enough for a reason?
Yes, it is reason, more than enough reason in fact.
Expecting that we'll start doing changes to our SDK (without a specific requirements) in order to support random/every language is optimistic.
At the moment I am just handling the idea. As for my self I havent invested in any expectation at all for your part. However, I am already starting to visualize how to implement it. The difference may be sutble, but I apologize if I sound or read as arrogant.
If you have a favourite language that is not supported you can:
1. look at the C::B's code
2. start making changes, so the support is improved or possible.
3. post a patch or better series of patches
4. fix reported problems and don't be afraid of criticism
Yes, I can agree to that being a proper way to proceed. Unless the idea is a little different than that. I am not talking about adding one language at a time, but to add ANY language in one single step. I want to synchronize with you all about this. But I am not going to do anything if my idea is not supported, right? However, I am willing to create all of the low level code for this, how does that sound? But, you are the core developers. I must know that once the low level code is created, that you will implement it somehow, by way of a single plugin or two or in any way. If there is no relatively covering consensus about this, the question is if I really should go about on this.
Sure, when I say in one single step, I am talking pretty big strides.
Do you think that it would be possible to do something like:
5. Create some of the "low level" code as a showcase to give you the idea of the concept?
Not that I am on my way to do any such horrendously stupid thing yet... ;)
But if that be an option to proceed?
-
This sounds a little like Fermat's last theorem. "I have a proof for this, but there's not quite enough room in the margin of this notepad..." And it was finally solved using what can only be described as a brute force approach.
I think we are open to having the IDE support multiple languages (but the developers certainly vary in their level of interest), and we've taken many steps in that direction. The editor syntax highlighting works for whatever languages Scintilla supports, the build system is very flexible and can be configured to support a wide range of compilers and languages. We have a pretty flexible API for supporting debugging via plugins (I have written a debugger plugin for python using it) and we are well on the way to doing the same for code completion (I have a partially working plugin for python). But that still leaves a LOT of work to write all of the interfaces for language you would hope to support. So you really need to tell us more about what you have in mind ...
Sure, I will be more specific. And I will not keep you on your toes. I will present any information until the idea is proven wrong, which happens most of the time, just as you pointed out.
Many of the steps that you have taken covers most of the usage out there. It even covers a lot of my general idea of supporting any language. But it will lack some space in order to support my specific idea.
-
On the other hand: we're working on better SDK for CC plugins, so in the future it will be possible to CC for any language there is a plugin written.
If you are curious, this thread (http://forums.codeblocks.org/index.php/topic,18114.0.html) contains some details.
I will surely look into all the current work and streamline any solution of an implementation to make use of as much as possible of the current implementations.
-
Ok, I have a couple of responses about the general idea. Thus I can present the specific idea.
The specific idea is to support not only any programming language that the code may be written in, but...
to also support ANY natural language that the code may be written in. By just adding this support in the IDE!
-
Ok, I have a couple of responses about the general idea. Thus I can present the specific idea.
The specific idea is to support not only any programming language that the code may be written in, but...
to also support ANY natural language that the code may be written in. By just adding this support in the IDE!
You do realize you are coming off as a person who knows nothing about programming!
Tim S.
-
Ok, I have a couple of responses about the general idea. Thus I can present the specific idea.
The specific idea is to support not only any programming language that the code may be written in, but...
to also support ANY natural language that the code may be written in. By just adding this support in the IDE!
You do realize you are coming off as a person who knows nothing about programming!
Tim S.
Either know nothing... or too much! No, just kidding. Sorry if I have trouble to make myself clear and understandable among all those enthusisastic traits of me. For the record, I am not new to programming. More like moderately advanced in C++, knowledge about a few other languages, computer theory, the psychology of language, some about ergonomy...
Dont get fooled by me though. I can be too enthusiastic. Better safe than sorry.
-
It sounds like you want to do YAGKBS (yet another generic killer build system) and then you want us to make a C::B plugin for it. Am I correct?
-
It sounds like you want to do YAGKBS (yet another generic killer build system) and then you want us to make a C::B plugin for it. Am I correct?
Hmm, you got me thinking there. Damn, a long time since I used my brain. :D
Well, now that you mention it, I realize that I am thinking about some kind of quick cheat that may not cover corner cases about programming. No, I am very content about the YAGKBS that codeblocks already have. The quick cheat I am referring to is to use something like a preprocessor that will work on top of a source (as if preprocessors worked in some other way). I mean, just look on GCC that cannot support other than ASCII set of characters. However, when referring to the the implementation of support for natural language (and parts to programming language) a preprocessor may be what really is needed.
I am thinking about some showcase implementation. I hope to be able to scramble something together rather quickly. Just to convince myself that it is workable. And for you to see more clearly what I intend. I dont think it is correct for me to give you details here. Or? Do you want me to go into details? If you are that curious/or want to finish this discussion rather quickly?
-
I have been following this topic and frankly all I read is the same repetitive thing without an actual sample either in the form of pseudo or literal programming code.
If you want a generic natural language mechanim, you should see how Perl is implemented by a linguist (Larry Wall). It's a great example of a powerfully flexible language that does exactly what you have in mind I would say. Again, maybe I'm wrong.
Another great example would be Lua, yet another powerful scripting language (and old too; blimey, 20 years old already!), that can let you use it to create any kind of Domain Specific Language (DSL) with its amazing metatable and metamethod operations.
Now, don't take my word as the absolute way of doing things, just experiment with your ideas; but provide us something here so we can get a rough idea of what you need.
-
I have been following this topic and frankly all I read is the same repetitive thing without an actual sample either in the form of pseudo or literal programming code.
If you want a generic natural language mechanim, you should see how Perl is implemented by a linguist (Larry Wall). It's a great example of a powerfully flexible language that does exactly what you have in mind I would say. Again, maybe I'm wrong.
Another great example would be Lua, yet another powerful scripting language (and old too; blimey, 20 years old already!), that can let you use it to create any kind of Domain Specific Language (DSL) with its amazing metatable and metamethod operations.
Now, don't take my word as the absolute way of doing things, just experiment with your ideas; but provide us something here so we can get a rough idea of what you need.
Yes, well, the discussion would be if the idea is desirable, and next if it is implementable. I hope to give you a showcase this evening. This will enable me also to dig into some code and my mind works better to figure out if it is good or not. Also it is a good way to visualize what I intend.
-
If you want a generic natural language mechanim, you should see how Perl is implemented by a linguist (Larry Wall). It's a great example of a powerfully flexible language that does exactly what you have in mind I would say. Again, maybe I'm wrong.
Aha. No, I used the term natural language too casually. What I really meant was to be able to write code in your mother tongue. Not that the actual compiler will know anything specific about your mother tongue. My showcase is coming together as expected so far, so if I dont hit a major snag I can upload it relatively soon.
Hmm, actually I have no specific web space to upload it to and link. Is there any suitable place where I can upload a zip file between 50-150MB to link in this forum? I was planning to create a codeblocks project to use together with a compiled console application and hook it up in the codeblocks IDE.
Update: As usual there was a programming error which I thought was a compiler version error. So after some hours recompiling libs I realize that it was a bug. I will get back on this tomorrow. However, I have not much time tomorrow, so this is going to take a couple of days. At least I managed to update to GCC 4.8, wxwidgets 3.0-RC2 and some others.
-
Now I have made a small showcase test. It is a Codeblocks project that you can open with instructions in the header file. The file can be retrieved from a site that is on www.fileconvoy.com that can store temporary files on the net. This is the first time I use the fileconvoy service, so if there is any problem, please report them to me in here. The file:
http://www.fileconvoy.com/dfl.php?id=gbd5fa2503222f2ef999409854738b3006fc813032
Update: This project will only be usable on Windows.
-
Why don't you (a) just explain what it is rather than have us download some random file from a web-site known for malware, or (b) share your code publicly using one of the many reputable source hosting sites: github, gitorious, launchpad, pastebin, sourceforge, berlios.
-
Why don't you (a) just explain what it is rather than have us download some random file from a web-site known for malware, or (b) share your code publicly using one of the many reputable source hosting sites: github, gitorious, launchpad, pastebin, sourceforge, berlios.
a) Of course it could be malware. You dont know me and I dont know you.
b) Share the code? What in the code is interesting as it is neither finished nor advanced nor complete.
c) I may have picked the wrong sub-forum. I should have placed this discussion on the suggestion forum and moved up from there.
d) If you want me to create a sample that you can compile yourself, someone will ask why I dont compile it for them instead of giving the code.
e) The program is not malware.
f) This discussion is not over yet. And if I get what I want, it will not be put down, but developed into a new standard for C++ and other languages where it is trivial to program using your innate language.
-
Instead of pseudo code, perhaps I can describe usage patterns that I personally would like to see.
Open a source code project downloaded from the net:
1. Open the project.
2. Select menu->languages->Italian, which immediately translates the source into the Italian language.
Compile the source project:
1. Press menu->Build, the Italian code is "JIT"-translated into code known by the current compiler, such as GCC.
Release a source header set:
1. Press menu->Export, the code is stripped off the Italian language and is left with only the compiler known language, such as C++.
Start using a third-party header dependent library, such as WxWidgets.
1. Download and install the header files.
2. Download and install/or create your own/ translation module that translates all the the terms, such as wxComboBox into wxKombinataBoxxy (or what it is called in Italy? ???
Create your own source distribution, such as source code for CodeBlocks:
1. Create the source.
2. Attach a set of already completed source translation modules.
3. Pack it up in a bundle. The users can themselves select which language is preferred.
-
Read this thread twice, I don't understand what you are going to achieve.
Only one question: Do you understand the "Parsing technology"? If the answer is yes, you can write parsers for a specific language. If the answer is no, I don't think can do much about "code completion feature".
-
Read this thread twice, I don't understand what you are going to achieve.
Only one question: Do you understand the "Parsing technology"? If the answer is yes, you can write parsers for a specific language. If the answer is no, I don't think can do much about "code completion feature".
No, I dont know specifics about any "Parsing technology". However, I have written a parser for equations, does that help?
-
Read this thread twice, I don't understand what you are going to achieve.
Only one question: Do you understand the "Parsing technology"? If the answer is yes, you can write parsers for a specific language. If the answer is no, I don't think can do much about "code completion feature".
I will look into this about the code completion. I will be aiming at reusing the basic code completion plugin and place translation on it. This can be done for a specific language where a code completion plugin already exists. For a programming language with no code completion plugin available I was thinking to let the user tag their code invisibly by selecting from a pop-up menu and thus making the code completion feature available without using any parsing technology.
-
Instead of pseudo code, perhaps I can describe usage patterns that I personally would like to see.
Open a source code project downloaded from the net:
1. Open the project.
2. Select menu->languages->Italian, which immediately translates the source into the Italian language.
Compile the source project:
1. Press menu->Build, the Italian code is "JIT"-translated into code known by the current compiler, such as GCC.
Release a source header set:
1. Press menu->Export, the code is stripped off the Italian language and is left with only the compiler known language, such as C++.
Start using a third-party header dependent library, such as WxWidgets.
1. Download and install the header files.
2. Download and install/or create your own/ translation module that translates all the the terms, such as wxComboBox into wxKombinataBoxxy (or what it is called in Italy? ???
Create your own source distribution, such as source code for CodeBlocks:
1. Create the source.
2. Attach a set of already completed source translation modules.
3. Pack it up in a bundle. The users can themselves select which language is preferred.
I still not understand what you want to get in those steps.
You just want to translate all the Italian words in one source file to English words??? Maybe, you should show us some code snippets, screen shots, patches againt current SVN Head, I don't want to download/try a binary if I know nothing about the binary.
-
I still not understand what you want to get in those steps.
You just want to translate all the Italian words in one source file to English words??? Maybe, you should show us some code snippets, screen shots, patches againt current SVN Head, I don't want to download/try a binary if I know nothing about the binary.
Ay, ay sir. ... Rethinking world definition, please hold... :D
No, but seriously, I am listening to all you say here. Maybe I should create a completely different sample. Against SVN, create a plugin (if it is relatively swift to make a crude one?). At the moment I am mostly collecting opinions though. But, hard if you cannot see the whole picture.
-
The reason I did not just upload the source was because the code is tied into the same code that is used for another project, of which I am not sure if I can share that code. However, when I create the plugin I will split up the code separately so that it can be included in the CodeBlocks project (if that happen).
-
Nobody seems to be backing me up on this idea yet. Is there no good reason to be able to program in your own language? There is a reason that we have many languages on our globe, right? It creates boundaries between different cultures. Should we not reflect that in the business of C++ as well, or am I the only one thinking like that? Maybe, just maybe... just maybe, it would be better if I just go and do harakiri on myself, then I dont need to bother. :P
-
Instead of pseudo code, perhaps I can describe usage patterns that I personally would like to see.
Open a source code project downloaded from the net:
1. Open the project.
2. Select menu->languages->Italian, which immediately translates the source into the Italian language.
Sounds like a mixed C Processor and Poedit combined with Comment Translator.
Compile the source project:
1. Press menu->Build, the Italian code is "JIT"-translated into code known by the current compiler, such as GCC.
Sounds like a C Processor.
Release a source header set:
1. Press menu->Export, the code is stripped off the Italian language and is left with only the compiler known language, such as C++.
Sounds like a Text Processor tool.
So far, I see no need for a CB Plugin; I suggest trying out the CB Contrib ToolPlus Plugin and see if that will do all that you need.
If nothing else it might be quicker during development.
Tim S.
-
Nobody seems to be backing me up on this idea yet. Is there no good reason to be able to program in your own language? There is a reason that we have many languages on our globe, right? It creates boundaries between different cultures. Should we not reflect that in the business of C++ as well, or am I the only one thinking like that? Maybe, just maybe... just maybe, it would be better if I just go and do harakiri on myself, then I dont need to bother. :P
The main problem is you NEVER really defined what you meant by language!
I can see the word Language to mean "Programming Language" (C,C++,D, Pascal) or "Native Language" (English, French, or Spanish).
Tim S.
-
Nobody seems to be backing me up on this idea yet. Is there no good reason to be able to program in your own language?
I think it is that most of us reading this thread (or at least myself) do not understand what exactly your idea is trying to achieve. (Also, posting binary-only files as an idea for an open source project is... unusual.)
If by language you mean "native language", the general consensus here is that if one localizes one's source/build process to anything other than English, one will achieve nothing but a headache when trying to search documentation/error messages.
-
Instead of pseudo code, perhaps I can describe usage patterns that I personally would like to see.
Open a source code project downloaded from the net:
1. Open the project.
2. Select menu->languages->Italian, which immediately translates the source into the Italian language.
Sounds like a mixed C Processor and Poedit combined with Comment Translator.
Compile the source project:
1. Press menu->Build, the Italian code is "JIT"-translated into code known by the current compiler, such as GCC.
Sounds like a C Processor.
Release a source header set:
1. Press menu->Export, the code is stripped off the Italian language and is left with only the compiler known language, such as C++.
Sounds like a Text Processor tool.
So far, I see no need for a CB Plugin; I suggest trying out the CB Contrib ToolPlus Plugin and see if that will do all that you need.
If nothing else it might be quicker during development.
Tim S.
Thanks a lot, stahta01, I may have prematurely removed the idea to use other tools for the task, thinking it would be better it it was integrated. Then again, maybe not. Perhaps several tools is better since there are several tasks involved.
-
Nobody seems to be backing me up on this idea yet. Is there no good reason to be able to program in your own language? There is a reason that we have many languages on our globe, right? It creates boundaries between different cultures. Should we not reflect that in the business of C++ as well, or am I the only one thinking like that? Maybe, just maybe... just maybe, it would be better if I just go and do harakiri on myself, then I dont need to bother. :P
The main problem is you NEVER really defined what you meant by language!
I can see the word Language to mean "Programming Language" (C,C++,D, Pascal) or "Native Language" (English, French, or Spanish).
Tim S.
Yes, my definition was that both the programming language and the native language can be one. Such as if I write wholly in English, ie "function DoSomething()" or in Italian, ie "funzione FareQualcosa()", then both the native and the programming sentences could be categorized as "Italian" language.
Now, in the world of programming, I was thinking that the translation can be only to exchange words one by one, straight.
-
Nobody seems to be backing me up on this idea yet. Is there no good reason to be able to program in your own language?
I think it is that most of us reading this thread (or at least myself) do not understand what exactly your idea is trying to achieve. (Also, posting binary-only files as an idea for an open source project is... unusual.)
If by language you mean "native language", the general consensus here is that if one localizes one's source/build process to anything other than English, one will achieve nothing but a headache when trying to search documentation/error messages.
Yes, I agree to that, unless all the developers understand the same other language, which today may be more and more uncommon. That which I was trying to achieve was to connect the knowledge of programming with the bulk of knowledge that you possess in your native language. As such it would be more comfortable for the mind to program in your native language, especially when you strain the mind with more advanced thinking in algorithms and more. Using two languages for the process demands the mind to have two different language centers, which for the mind reduces the thinking process.
The headache that you are talking about is apparently both well known and real. I was figuring that if the source could be distributed as a common language, then that would be no problem.
I have not dealt with the language used in commentary though.
However, a scenario where we would only have one global language, such as English? I am very pessimistic about that. What I see is that a language tend to accumulate a certain set of traits. With only one language, then we would by that theory have only one set of traits at a global level. Such a reduction of the wealth of the human culture would be... simply unacceptable.
-
If I create a tool based on a variant of UTF-8, that I call UTF-82. The only thing that differs between UTF-8 and UTF-82 is that the forbidden byte sequences C0-C1, F9-FF are accepted in the string. In order to scan and display an UTF-82 string is to just ignore those byte sequences. Would you include UTF-82 as a file format in CodeBlocks? That would be very helpful.
Update: Or, if I am supposed to include it myself? If I post patches, would you accept me doing this and have it added? Or is this the task of someone else? I do not know what rules apply here.
-
As a native english speaker, it's hard for me to judge how much of an impediment not being able to work in ones native language is. I guess it must be some, but it's not like English == C++, and sometimes the English names for programming constructs are actually misleading (e.g. "Cookie").
It's not clear that modifying the IDE itself is the best way to achieve what you want. If I am reading correctly, I think what you have in mind is sort of a pre-processor that converts the users native language source to language that the compiler understands ("program langauge") using a dictionary that maps native "words" to their compile-able equivalent. You also need to be able to convert the compiler messages back to their native language equivalents. At least from the compiler perspective, the best way to do this might be a command line tool that wraps around the GCC toolchain that handles the necessary conversions. You could then add support for this in Code::Blocks (or any other IDE that has flexible build system) by calling your commandline tool instead of the regular GCC toolchain.
On the other hand, allowing the user to use their native language for code completion (and other things like class and project wizards) would require very significant changes to the IDE. The CC parser would need to convert the native language to program language when parsing, and tokens would need to be converted from program language to native language for display in the UI.
-
As a native english speaker, it's hard for me to judge how much of an impediment not being able to work in ones native language is. I guess it must be some, but it's not like English == C++, and sometimes the English names for programming constructs are actually misleading (e.g. "Cookie").
The effect is not noticeable at first. After years of programming, at least for me, it was bugging me increasingly. Even though I am quite fluent in the English language, that still bugged the crap out of me. Maybe I am sensitive. But there are more than just the comfort in it. If you think about how many times you use each syntactic term in C++ when programming. Maybe you print in the term "if" thousands of times each project. The effect adds up. Even so if I would be using my native language, the equivalent "om" in Swedish, that would eventually bug the crap out of me as well. But with a translator, I can switch between two or more variants of that. Now, the most important thing is of course to have the first term in the native language. I also notice that when I use "if", I would prefer writing the comments in English. When I switch to "om", my mind prefer writing the comment in Swedish (my native language). This is because the lowest level of terms, such as "if" would be hard coded in my mind after years of use, and that switches over my mind to its respective language. Each switch to another language takes an additional toll on the mind. (Not huge, but enough to make the mind outside of the comfort zone). So, this is not just an idea. My whole mind actually crave to be able to write in my native language, such as coding. I could get by continue to use the "normal" English terms. But I would be disappointed and less vital in my work.
It's not clear that modifying the IDE itself is the best way to achieve what you want. If I am reading correctly, I think what you have in mind is sort of a pre-processor that converts the users native language source to language that the compiler understands ("program langauge") using a dictionary that maps native "words" to their compile-able equivalent. You also need to be able to convert the compiler messages back to their native language equivalents. At least from the compiler perspective, the best way to do this might be a command line tool that wraps around the GCC toolchain that handles the necessary conversions. You could then add support for this in Code::Blocks (or any other IDE that has flexible build system) by calling your commandline tool instead of the regular GCC toolchain.
A such wrapper may indeed be the best way to do it. If it is decided that such is the way to go, then I will do it. The problem may be that I need to write one such tool wrapper for each compiler. That can get nasty considering how variants of MinGW, MinGW64, and now TDM keeps emerging.
On the other hand, allowing the user to use their native language for code completion (and other things like class and project wizards) would require very significant changes to the IDE. The CC parser would need to convert the native language to program language when parsing, and tokens would need to be converted from program language to native language for display in the UI.
I was kind of hoping that there would be a solution that would not require huge changes to the IDE. Actually, I am already running a command line tool for all my programming tasks that already translates the code. And this works. Also it works for debugging.
The reason that I still am bugging you over this are first, I like to make this available to everyone as an option in the world of programming. Also, an additional bonus would be if the code completion would work with this, but for me personally, that is not necessary. I get by without the full code completion.
At least, I do not want to place any burden on you folks, so I hope a simple solution is possible without too much effort. That is why this needs to be discussed, so we can figure out if there is a solution that simple enough to implement in CodeBlocks. I think it could be a good reputation for CodeBlocks if it could brag about this feature. I am not sure, just intuitively I think it would be a winning concept.
-
If I create a tool based on a variant of UTF-8, that I call UTF-82. The only thing that differs between UTF-8 and UTF-82 is that the forbidden byte sequences C0-C1, F9-FF are accepted in the string. In order to scan and display an UTF-82 string is to just ignore those byte sequences. Would you include UTF-82 as a file format in CodeBlocks? That would be very helpful.
Update: Or, if I am supposed to include it myself? If I post patches, would you accept me doing this and have it added? Or is this the task of someone else? I do not know what rules apply here.
I am working on designing the console application to use xml files. Later on, when creating the plugin, the code can just be copied over, I hope. But there is a design issue that I am pondering. And that is whether to at all try to use the UTF82 for this. The good thing with UTF82 is that one can include control strings embedded in the string. Instead of creating a document format, the UTF82 could provide a standardized way of creating your own document format, but with the ground structure already in place such as the encoding of UTF. The down side would be the hassle to implement the possibility to open any UTF82 document for example in CodeBlocks. It would make a totally different IDE, but for what purpuse, just to add the translation capability. Hardly worth the effort. Then again, in order to get such a versatile translation mechanism, UTF82 looks like a creamy cake to me. What do you think, should I ignore worldly facts and implement it as UTF82?
-
Code::Blocks uses a very slightly modified version of tinyXML in the CB SVN path of src/base/tinyxml
If UTF82 is NOT supported by tinyXML, you would have to write your own way of reading/writing XML.
Or, submit patches and have them accepted at tinyXML.
Edit2: The above is based on the idea you are making a CB Plugin or might in the future.
Edit: Have you ever built CB from SVN source? If not, I suggest doing so.
Tim S.
-
Edit: Have you ever built CB from SVN source? If not, I suggest doing so.
Due to the fact that ollydbg only run 32-bit Windows, and the bug report I put on Berlios now is suspected to originate from 64-bit implementation, I am at the moment compiling from SVN. So, the suggestion is proceeded.
BTW, good point about the xml. If tinyXml does not support the UTF82, then you are right, it aggravates things considerably. I know eventually, to be usable, the UTF82 needs to be standardized. I expect the implementation of UTF82 to change several times before that happens, if it happens.
-
However, a scenario where we would only have one global language, such as English? I am very pessimistic about that. What I see is that a language tend to accumulate a certain set of traits. With only one language, then we would by that theory have only one set of traits at a global level. Such a reduction of the wealth of the human culture would be... simply unacceptable.
Perhaps I spoke with too many absolutes. I was not arguing that English is a special language that everyone needs to learn.
However, for English based programming languages (specifically C/C++, which is Code::Blocks' main target), I consider using non-English identifier names and comments to be as confusing as mixing vocabulary from multiple languages to form a sentence.
That said, I do believe your idea has merit, as it sounds that your goal is lossless and bidirectional.
-
as it sounds that your goal is lossless and bidirectional.
Yep, that is two aspects of the goal.
-
I consider using non-English identifier names and comments to be as confusing as mixing vocabulary from multiple languages to form a sentence.
I believe that identifier names is fixable with an advanced translator mechanism. That can be a good win for the programmer. However, it demands specifying two identifier names for each identifier. Comments in another deal altogether. I have no clue about how comments could be fixed. And I do not think that there is a solution for comments that is simple enough to make it worth any effort.
As for comments I have been pondering using a huge database with pretranslated strings. But that is also a hassle if you must assemble all comments using templated text strings. Besided it means you need to connect to the database, update the database and so forth. Too cumbersome.
-
I consider using non-English identifier names and comments to be as confusing as mixing vocabulary from multiple languages to form a sentence.
I believe that identifier names is fixable with an advanced translator mechanism. That can be a good win for the programmer. However, it demands specifying two identifier names for each identifier. Comments in another deal altogether. I have no clue about how comments could be fixed. And I do not think that there is a solution for comments that is simple enough to make it worth any effort.
As for comments I have been pondering using a huge database with pretranslated strings. But that is also a hassle if you must assemble all comments using templated text strings. Besided it means you need to connect to the database, update the database and so forth. Too cumbersome.
With both this stuff about comments and your UTF-82 talk, I think you are WAY overcomplicating things.
To me, the potential "win" here is to create set of standardized translation tables that translates programming language keywords and all of the exportable user defined tokens of the libs you care about (i.e. public classes, functions and variables of the libraries the user would use) to and from their foreign language equivalent. Comments, especially the doc strings for toolkits like wxWidgets, would be nice, but they aren't necessary to get a program to compile and dealing with them in the right way has to be part of a much larger translation effort.
To reiterate, you don't really need to integrate this into C::B to make your proof of concept. And you shouldn't because if it is useful to C::B users it will be useful to programmers more genrally. Why don't you start by writing a simple tool that takes the users foreign language source files (UTF-8), a speficified translation table, and outputs the english programming language equivalent (and vice versa). From there it would be easy enough to integrate into the GCC and other toolchains. Then turn it into a Library and IDEs will be able to take advantage of it too.
-
With both this stuff about comments and your UTF-82 talk, I think you are WAY overcomplicating things.
Overcomplicating... nope, I am not
To me, the potential "win" here is to create set of standardized translation tables
Standardized translation? Noooo...
Comments, especially the doc strings for toolkits like wxWidgets, would be nice, but they aren't necessary to get a program to compile and dealing with them in the right way has to be part of a much larger translation effort.
Agree, comments need more effort from the developer than from any translation tool creator.
To reiterate, you don't really need to integrate this into C::B to make your proof of concept.
No, that is true, to the no...
And you shouldn't because if it is useful to C::B users it will be useful to programmers more genrally.
No, I should not. But can I keep my sticky fingers from it? Nope.
Why don't you start by writing a simple tool that takes the users foreign language source files (UTF-8), a speficified translation table, and outputs the english programming language equivalent (and vice versa). From there it would be easy enough to integrate into the GCC and other toolchains. Then turn it into a Library and IDEs will be able to take advantage of it too.
No, that I will do. So, no. Wtf, I mean yes, YES.
-
Comments, especially the doc strings for toolkits like wxWidgets, would be nice, but they aren't necessary to get a program to compile and dealing with them in the right way has to be part of a much larger translation effort.
I think you are too speeding reading. In conclusion my point all the time was that I will not touch comments, just skip over them in the translator.
-
your UTF-82 talk
8)
Well, you are probably correct about overcomplicating that stuff. I hope the UTF82 is just a temporary hickup. If I decide to implement it I will be way beyond my available time not to mention unnecessarily complex.
-
The general idea is to enable that any programming language should be possible to use with very little preparation in the codeblocks IDE. I am not talking about just C++, but ANY language. By this I mean compiling, code-completion, hightlightning, everything that a developer needs.
Wtf!! What the hell was I talking about? My mouth must be running at a higher clock speed than my mind. I mean, OK for an idea, but it is not easy to implement in an afternoon. I knew that already, but I talk too much!
-
However, I am looking to create the algorithm for the translation phase. This is what I came up with so far:
In order to translate terms in the source document, the basic algorithm is as follows:
- Use a source string and a destination string for the pass.
- Scan the document for comments, skip all comment by writing directly to the destination.
- Create hash for each term found by doing the following
- For each byte that is not within a comment, check if it is equal or greater than 0x80, if so, it is a character to check.
- If it is less than 0x80, use a lookup table to get if it is a character to check, e.g [A-Z,a-z,0-9].
- For all characters to check, create a hash value by round robin over an uint64_t.
- When a byte that is not a character to check is entered, stop creating the hash and save the length of the byte sequence.
- With the length of the string, go into a lookup array using the length as index.
- In the lookup array two values are retrieved, the lower bound and the upper bound as a subset of a long list of hashes.
- We now know in what range in the long hash table a match can be found.
- Using binary search algorithm, the upper and lower bound converges until a definite match can be found.
- If the hash value is found in the list, there is great probability that it is the correct match, but that should probably be confirmed by double checking.
- Using the index of the matched hash, enter the same index into another lookup table, retrieve another index and length that goes into a compact table with the replacement string and write to the destination.
-
Question is if there need to be the double checking of the found hashvalue at all? Since the hash value is equal to the byte sequence for the first eight bytes, all short strings will have an exact hash match. For any string of byte length nine or greater, the probability of a hash collision must be very small. Doing the double check will take relatively much processing time. The shortest string with eight bytes, however, is two character UTF8 of very high unicode point values. Question is also how often they will show up. More common short strings of UTF8 with eight bytes will be somewhere of 4+ characters.
An example where a hash collsion will occur is the terms "templates" and "semplatet". Using those terms, the only anagrams of nine byte strings that collide is where the first and last letters are interchanged. Question is if you would wait until a collision is detected by the user, and let the user switch to a checked version of the hash. I know it is substandard to make shortcuts like this. That is why I am asking.
-
Probably it is going to be checked, that is the only reasonable way. Besides, the search string to check can reside in the same table as the replacement string, right before it. Thus the term is first checked, then replaced by just keep going in the same table, using two length values and one index value.
-
Great, the inner loop in its most basic form seems to become somewhat defined. Now, the next item to solve in the list will be how to treat variable scope.
-
One way to treat variable scope, is to... not treat variable scope. To avoid variable scope is to avoid using parsing technology. To avoid using parsing technology is to create one-for-all mechanism for the translation.
The idea is to use several versions of the source files as follows:
________________________________________________________
|
| Specific language cpp-source file, *.hscrp.h and *.cppscrp.cpp
|________________________________________________________
A
| Lossless bidirectional translation
V
_________________________________________________________
|
| Common language cpp-source file, *.hlang.h and *.cpplang.cpp
|________________________________________________________
| One way translation
V
___________________________________
|
| Normal cpp-source file, *.h and *.cpp
|__________________________________
-
Yes, my definition was that both the programming language and the native language can be one. Such as if I write wholly in English, ie "function DoSomething()" or in Italian, ie "funzione FareQualcosa()", then both the native and the programming sentences could be categorized as "Italian" language.
Now, in the world of programming, I was thinking that the translation can be only to exchange words one by one, straight.
Don't get me wrong on that, but this is the most stupid idea I've heard in a while.
Not only that, but it also won't work. Languages do not translate word by word, and languages have grossly different grammar. Many languages have characters that do not exist in others. What if someone writes Tagalog or Chinese and you expect Italian or German? How is this supposed to work? Do you expect comments being magically translated as well?
Not few terms translate in an awkward manner to say the least, even when done by professinal translators. I regularly have to stop and think what they're trying to say when I see IT translations from English to my native language done by professionals working for multi-million-dollar companies. Let alone word-by-word computer translation.
Plus, most people who are moderately familiar with programming are also firm in English.
That much for natural languages, and as far as "any programming language" goes, I can think of least 6 grossly different categories of languages, and these are certainly not all:
- compiler based bytecode languages (e.g. Java)
- compiler and linker based languages (e.g. C or C++)
- interpreted/bytecode languages without explicit compiler (e.g. Python, Lua,... )
- interpreted/bytecode embedded languages (e.g. AngelScript, Squirrel, and again Python, Lua)
- interpreted/bytecode remote languages (e.g. PHP)
- weirdo languages that do near unpredictable stuff (e.g. bash script, perl)
- weirdo languages that nobody can understand (e.g. Lisp)
Some of these need a compiler invoked, some of them need the executable to be linked afterwards. Some need the binaries and resources packed in a zip file and a bytecode interpreter launched afterwards instead.
Some need an interpreter launched, some need a host application (including bindings).
Some need files being uploaded to a different machine where an interpreter runs as server process.
Some need ... something else.
All of these categories are so grossly different that it is hardly possible to pack them all into one unified build process or one unified notion of a "project".
-
Don't get me wrong on that, but this is the most stupid idea I've heard in a while.
Ok, I will not get you wrong. ;)
Thus it may also become the most stupid idea that you heard in a while, that also gets to be implemented.
-
I think it was an interesting and well written comment by thomas. But I do not know how to interpret the message. I will assume that the message was not directed for me, but instead intended for all the other forum members to get a more "healthy" viewpoint.
-
I will assume that the message was not directed for me, but instead intended for all the other forum members to get a more "healthy" viewpoint.
(http://2.bp.blogspot.com/-tptLLXmB4_o/T6MIYzmfHmI/AAAAAAAAOJY/94fFTfhEa2I/s72-c/Jerry-Mouse-Facepalm%255B1%255D.jpg)
-
I will assume that the message was not directed for me, but instead intended for all the other forum members to get a more "healthy" viewpoint.
(http://2.bp.blogspot.com/-tptLLXmB4_o/T6MIYzmfHmI/AAAAAAAAOJY/94fFTfhEa2I/s72-c/Jerry-Mouse-Facepalm%255B1%255D.jpg)
OK, if the idea is that bad, then I am ready to defend it politically also! So, if this has political implications, hit me! I am ready and will NOT get angry/backstabbing/sad.
-
I think this topic has left the scope of our forum by far.
Note: this forum is dedicated to Code::Blocks and related themes, but this discussion has become much more general.
Please stop the discussion (or move it to another platform), or I will lock the topic.
-
I think this topic has left the scope of our forum by far.
Note: this forum is dedicated to Code::Blocks and related themes, but this discussion has become much more general.
Please stop the discussion (or move it to another platform), or I will lock the topic.
Sure, I will look on the options and get back as to where to move it, or otherwise how to proceed.
Edit: I am thinking like this. I will start a couple of threads in another couple of forums to discuss "the political aspect" but also "the practical aspect" and maybe "the ergonomic aspect". I think this thread can stay for the moment because the original idea was to implement it as a plugin in CodeBlocks. But since I provoked you a little, and the result is ambiguous, I think it is important to discuss it in a proper forum.
How does the administrator react to that?
-
What you want to do is already done with Falcon programming language. You can see it for yourself through their official documentation
Survival Introduction (http://www.falconpl.org/index.ftd?page_id=sitewiki&prj_id=_falcon_site&sid=wiki&pwid=Survival%20Guide&wid=Survival%3AIntroduction)
-
What you want to do is already done with Falcon programming language. You can see it for yourself through their official documentation
Survival Introduction (http://www.falconpl.org/index.ftd?page_id=sitewiki&prj_id=_falcon_site&sid=wiki&pwid=Survival%20Guide&wid=Survival%3AIntroduction)
;D you are correct! I did not know that. Excuse me, I have a few programming manuals to read.