I would like to add a new language (called 'kiwi') into the Brackets code editor which is based on C++. It uses the exact same rules but has additional keywords.
I've already done the part of adding the additional keywords with separate syntax highlighting directly on the clike.js file but i don't really like directly modifying the def for C++
Can someone explain to me how I can achieve this? I don't really understand the difference between using def() and CodeMirror.defineMIME(). If this new language will take cpp/hpp input files, how will the editor switch from C++ -> kiwi?
Thanks in advance
Patching your local copy of the code, as you've done, might be perfectly fine for your needs. (And if you run from a Git copy of the source, it's easy to pull down updates without losing your local diffs).
If you want to do it a "cleaner" way, you can write a Brackets extension to define the new language - this way the change is easily shareable with others, and updating Brackets is even easier.
The way you'd do this roughly follows the Defining a new language docs:
Write an extension to package up your code that will define the new language (below)
The CM mode "clike" is already loaded, so you don't need to worry about that
Call CodeMirror.defineMIME() to set up a clike configuration with the right list of keywords - using a new mimetype name of your choosing. (Looking at the def() code in clike.js, I don't think the extra stuff it does is especially relevant for Brackets).
Call LanguageManager.defineLanguage() to tell Brackets about your new language mode (and what file extensions map to it, etc.). You should be able to mostly copy how the C++ mode is defined here - except with your new MIME name instead.
You should read CodeMirror documentation to find out about writing your modes.
But in short you can define your own type of clike language, by using CodeMirror.defineMIME().
You also asked what's the difference between def() and CodeMirror.defineMIME(). If you look at the code you can see that def() function is calling CodeMirror.defineMIME() at the end, so I believe it is just a more readable way of defining the type.
Also it seems that it's impossible to define more than one language on the same extension type (not 100% sure).
Related
I am trying to make changes to the behavior of a function and print the results to a file. The ViewCfg plug-in described in the Plug-in Development Guide does something similar, but I am trying to avoid having to use Ast.get, which ViewCfg uses. I am thinking of extending Printer.extensible_printer which, according to the Frama-C API Documentation, is something I can do if I want to obtain a custom pretty-printer.
However, if I extend the pretty-printer as described in the API docs, unless I'm doing something wrong, I notice that the changes I make take place regardless of which project is set as the current project. I'm using File.create_project_from_visitor to create a new project and Project.set_current to set the new project as the current project before I use the custom pretty-printer.
Is it true that any change made by a class that extends Printer.extensible_printer applies to all projects? I happen to be using frama-c-Aluminium-20160502, which I know is not the latest version.
EDIT: Sorry, I should have made this clearer in the beginning, but I'm not actually making changes to the behavior of a function. I'm reading in the behavior of a function, then based on that, I'm trying to generate as output valid C code that's meant to be read as input by another program.
Regarding AST.get, the only reason I was avoiding it was that it sounds like it gets the entire AST, while I'm only interested in part of it, i.e. behaviors. But if I'm just making things harder for myself by avoiding it, then I'll go ahead and use it.
How to use dart-mirror API to create a anonymous closure dynamically?
Like as the interpreter, compile the code during run-time.
var funcstr='bool (String s){ return (s==null); }';
var func=parseStr(funcstr);
// func(s)-> s==null;
var r=func('false');
// r=false;
so, how to do with "parseStr"?
my project:
http://github.com/stevehsu77/surebet
At the moment there is no way to do this. Dart has no eval and no code generation at runtime.
But it is something Gilad Bracha (the language spec lead of Dart) wants to have (https://groups.google.com/a/dartlang.org/forum/#!topic/misc/6O4g7eEHgOU) at least for the development environment.
Also
We’d like to support more powerful reflective features in the future. These would include mirror builders, designed to allow programs to extend and modify themselves, and a mirror-based debugging API as well.
https://www.dartlang.org/articles/reflection-with-mirrors/
So it'll probably be supported some time in the future. But right now it's not possible.
As mentioned above, Dart does not have eval, however it is possible to load new source code in another isolate using spawnUri().
I am not sure if there are any examples of how to use this. Perhaps post a message on the dart discussion group.
Using isolates and spawnUri() is quite a different than using eval, so it may not be the right fit for your project.
I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:
FooLibrary.Bar
FooLibrary.Qux.Rumps
FooLibrary.Qux.Scrooge
..
Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.
First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
This is my main issue.
However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "#export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:
goog.requireRecursively('FooLibrary')
in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.
I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.
You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.
If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.
First, I need closurebuilder.py to send the full list of files to the closure compiler. ...
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.
What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.
My GeolocationMarker library has an example of this strategy.
Im learning how to use QT's translate stuff for the first time for work.
They already have things working to some degree and its my job to clean
things up and get it working properly as well as using lupdate to keep
things in sync when they change etc. We are also using QML in which we
wrote a wrapper function for all our strings, so lupdate does not find
our function to add to the .ts XML file. The reason we use a wrapper is
for centralizing other functions at once place for all strings. We also
dont always use a string literal in our 'source' argument but a defined
property, such as:
property string buttonTxt: "ButtonText"
then: commonTRFunction(context, buttonTxt)
which of course lupdate does not find for both reasons.
Ive looked into updating the lupdate source very briefly
and Im not sure if its worth trying to hack it to find our function or
write our own parser to find the standard QT tags AND also our new ones?
Secondly, and related to the first part, Id like a way to make one
context section that contains all the common words we use in our app
such as 'Back', 'Save', 'Ok' etc etc without repeating it over and over
throughout the .ts file. lupdate seems to repeat things over and over
in multiple contexts which seems both inefficient and a waste of lines
in the ts file.
I haven't found any QT docs that really explain the differences between tr(), qsTr(), qsTranslate(), QT_TR_NOOP() and QT_TRANSLATE_NOOP(). I know you sometimes need a context and the source,
and other times just use the source without a context. We dont use
the disambigous arg. Most of our code is in QML and not C++.
Also we are running lupdate from the command line.
Does anyone have thoughts, suggestions or even a tool someone wrote
that can be used for what we have? I appreciate your help.
i use customfiel php code inside one of my views to translate a string since 2.x of views is bad at localization. i use the following php code:
echo t('Watch Video');
but the string does not appear in the "translate interface" section.
thanks for your help.
lukas
The accepted answer is wrong, as the localization script is not scanning anything. The string is registered in the translate interface as soon as it gets passed through the t() function for the first time in the non-standard language.
Therefore, for translation it doesn't matter if the code you are writing is eval'd (interpreted from the database) or exists in the source. Obviously good practice would be to keep code in files where it belongs.
This blog post describes what needs to be done to get your strings into the translate interface.
The localisation database is built by scanning the source code, looking for instances of the t() function (and Drupal.t() in Javascript).
If the code in question has been entered into a text box in the Drupal admin area, then it isn't in the source code, so it won't be picked up by the localisation process.
For this reason (and others), you should put as little code as possible into the admin text boxes. There is usually an alternative way to achieve the same thing, but even if there isn't, you should reduce the code to a minimum -- best practice would be to have nothing there except a single line function call: have it call a function, and write the function code in your module or theme. That way it will be parsed when you run the localisation.