I want to make deoplete autocompletion suggestions pop up faster, that calls for setting
g:deoplete#auto_complete_delay
help says this requires +timers support. How do I enable this timers in config?
Thanks!
+timers is a compile-time feature of Vim that is available in Neovim from v0.1.5 onwards.
Compile-time features cannot be dynamically toggled, they are either there or not. +timers is an optional feature in Vim but non-optional in Neovim. So if you are using Neovim 0.1.5+, you already have the feature active. In fact, deoplete would not work properly without it.
You can verify that the feature is enabled: :echo has('timers'). If the result is 1, it's there, 0 mean it is not.
Related
I implemented a SV module which contains soft constraints. However, as far as I know soft constraints are only supported since 1800-2012 standard. Therefore I would like to add an alternative implementation in case a simulator is used that only supports older standard versions.
Is there a way to retrieve this information with a system task or pre-processor directive in such a way:
if($get_version_specifier == "1800-2012")
// do fancy stuff with soft constraints
else
// alternative fancy stuff
I already found an option for a similar problem by using begin_keywords, end_keywords, but I think that would not solve my issue since it only defines the set of keywords for a specific standard. And if the simulator does not support this version I guess only an error would occur.
Thanks in advance!
sebs
The problem you ask about is more complicated than it seems. Different features of SystemVerilog are implemented by different versions of tool; sometimes before the standard is released, sometimes after. I do know that some tools supported soft constraints before the release of the 1800-2012 standard, and no commercial tool that I know of has yet to support operator overloading, which was in the first IEEE 1800-2005 standard.
A better solution would be to define a set of macros like USE_SOFT_CONSTRAINTS for features that do not have universal support. Then you can include a common featureset.svh file that defines the feature set you want to use. Another good practice is to DOCUMENT the reason you added a specific feature macro (i.e the tool version you were using that didn't support the feature and why you decided it was worth the effort to implement both branches of the code).
As far as I know, there isn't any "standard" way of getting the version of the standard you are using. C++ had a similar problem before the 2011 release (see here). One answer there states that different compilers added different proprietary defines (something like the INCA macro set for the Incisive simulator). You'll have to ask your simulator vendor if a define for the version of the SV standard exists (something like SV2012_OR_GREATER).
Cadence, for example, has something like this for Specman, so if they're consistent they might have this for SystemVerilog as well. Assuming such a thing exists, you could have:
`ifdef SV_2012_OR_GREATER
// do fancy stuff with soft constraints
`else
// alternative fancy stuff
`endif
Bonus: Soft constraints are a declarative construct, so I don't see how you could use an if block to decide whether to use them or not (unless maybe if it's an if inside a constraint block). Also, I'm not sure whether you're able to truly emulate soft constraints in any way, however fancy your approach is, so I don't know if it really makes sense to try.
I can test that DMD is compiling the given code using version(DMD){}, but how can I check which version of it? (2.66/2.65 etc)
More concisely, I want to check that the #nogc modifier exists,
and if not - define a dummy one.
I came up with a workaround:
static if(!__traits(compiles, ()#nogc{}))
{
struct nogc;
}
but is there a better way? for example even checking directly for the existence of that specific modifier?
You can use the predefined __VERSION__ constant.
See also the std.compiler module (version_major and version_minor, specifically) for an easier way to use it.
However, your workaround might be a better approach. It will allow the code to work correctly even for compiler builds between released versions.
I'm using Eclipse Galileo with CDT for C development targeting embedded devices.
Like so many other compilers targeted at µcontrollers, the IAR compiler uses some non-standard variable types that Eclipse/CDT doesn't recognize and flags them as problems. Since these variable types are the foundations of other variable types I use the problem cascades to the point that just about every line using variables declared with the non-standard types are flagged as having syntax problems, even when the syntax is correct. It's not a critical problem, but it is definitely a nuisance.
Is there a setting within Eclipse/CDT where I can add non-standard syntax, or...
Is there some predefined macro within Eclipse/CDT that I can access with something like #ifdef SECRET_ECLIPSE_MACRO ... for conditionally setting or clearing a macro with the string of the offending variable type definition?
Well, you can go the other way around. Define a NOT_ECLIPSE macro when you compile your code, and check for its non-existence in your code. If it's not defined, you're in Eclipse.
Is there some predefined macro within Eclipse/CDT that I can access
Yes, there are many.
See this page.
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.cdt.doc.user/reference/cdt_u_prop_build_variables.htm
Don't forget to check the 'SHow system variables' option.
__CDT_PARSER__
is defined during CDT editor preprocessing stage (works at least with Indigo SR2)
The official documentation here only lists the minimum required version for a very small number of attributes:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Is there a complete list of which version each attribute was added in? Even better would be a list that also shows which ones are compatible with pcc and tcc.
For gcc versions:
http://www.ohse.de/uwe/articles/gcc-attributes.html
For pcc:
http://pcc.ludd.ltu.se/fisheye/browse/~raw,r=HEAD/pcc/pcc/cc/ccom/gcc_compat.c
For tcc:
??
For a lot of the useful ones you can copy the gcc version tests from glib's gmacros.h:
http://git.gnome.org/browse/glib/tree/glib/gmacros.h
Depending on your project you may also be able to just use GLib, and then use G_GNUC_NORETURN or whatever instead of the __attribute__ directly.
It probably would be better in principle to do HAVE_GCC_ATTRIBUTE_NORETURN as Juliano suggests, but it may also be YAGNI work, depending on your project.
I found this link which is slightly newer than the accepted answer:
https://patchwork.ozlabs.org/project/gcc/patch/20170706132518.GO3988#redhat.com/
Apparently up to 8.1.0. Not sure it is complete though.
Do yourself a favor and don't do that.
Perhaps your software has some pre-compilation configuration/setup phase (like the autoconf team... ugh! (shivers) or something more sane like CMake), use that.
Write small tests (autoconf macros) that check if the compiler accepts the __attribute__ you are interested in and if it works as expected. If successful, write a HAVE_GCC_ATTRIBUTE_XXX macro in a config.h file which is included from your source.
Then use that macro with #ifdef to test if you should put or not the attribute in the function, or perhaps if you should use another hack to emulate the lack of the attribute.
There is someone in my team that swears by using some kind of GVim feature to do manually code folding.
As I'm using another editor and do not really need the folding feature, I think it only pollutes the source code with tags like:
/* {{{1 */
Convincing the person not to use this folding is not an option (got into some heated discussions before).
I'm not really a GVim guy, I'm wondering if there are not any other ways to do the folding without changing the team's code?
Maybe putting the folding directions in a separate file, or
Doing some kind of smart folding that takes the syntax of the programming language into account without changing the source code?
I would imagine he could just add the following to his .vimrc:
set foldmethod=syntax
Assuming he is using a version of VIM that supports that. :)
It only took a Google for "vim folding" to discover that Vim supports six fold methods.
syntax, indent and diff all mean that the user has little control over where the folding happens. That may or may not be a problem.
marker is a problem for you because you don't like the markers.
expr had a little of each of those problems, depending on the expression you create.
If your man wants to define his own fold points, and store them in an separate file, it seems like set foldmethod=manual combined with :mkview and :loadview would do the trick.
You should try it yourself. Once you start using foldmethod=marker there is just no going back. I am working on a project now where I can't use marker folding and it feels like washing clothes in a time before there were washing machines.