So I've been trying to implement an #if parser into an infobox, but I seem to be out of luck. The previous code I used seems to be outdated, and I can't find the a way to code it in again, differentely. :/
Basically, in this infobox, if a field is not typed in(or if typed in is left empty) it should become 'invisible' or not even render.
This code worked fine in a previous version of MediaWiki(not sure which one though), but no longer: http://pastebin.com/uQ49mPbQ. I've been trying to use it as a tutorial, and even outright copy and pasted it, but it simply doesn't work. All of the fields would become invisible, regardless of what I would have done to them...
This is the new code that I am using, and would like to be #if'ed: http://pastebin.com/3j0AbN5v
Any help would be welcome.
You need to enable the ParserFunctions extension to be able to use the {{#if}} parser function. Do this in your LocalSettings.php:
require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );
If you want to use the string functions (like {{#replace}}, {{#explode}}, etc), also add:
$wgPFEnableStringFunctions = true;
In recent versions of MediaWiki, ParserFunctions is included (but not enabled) so you don't need to download anything.
Basic troubleshooting: Whenever you see code like {{#zyx:...}} in a wiki page, it (probably) means, that someone tried to use a parser function that is not installed. Unless there is a parser function called “zyx” installed, the code {{#zyx:...}} has no special meaning to the wiki, and the text will be printed just like it is. The most common parser functions are collected in an extension called ParserFunctions, that is used on WikiMedia wikis. You will need the parser functions from ParserFunctions whenever copying templates from e.g. English Wikipedia.
To see what parser functions you have enabled, navigate to Special:Version on your wiki. Below the list of installed extensions is a list of tags (such as <gallery />) and parser functions available. As you can see, “if” is among the parser functions on your old wiki, but not on your new.
Related
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
I am working on a compiler for cool as compiler course assignment but I'd like to code in cool language in notepad++ so I need to define this language for notepad++, I already wrote a lexer definition in flex format and I'm going to develop a parser for cool. Is there anyway to use these material to define the language for notepad++?
I would think so. (I don't use Notepad++ because I don't use Windows, so I have no good way to validate that theory.)
As I understand it, Noteoad++ is based on Scintilla, and Scintilla provides a mechanism to add custom lexers, using the protocol described in the file doc/Lexer.txt in the Scintilla source.
Basically, to make a flex-generated lexer process text using that protocol, you will either need to read the text to be scanned into a temporary buffer, or show yylex how to read the text (which means compiling your lexer with a custom YY_INPUT macro).
I'd go for the first option, because in order to customize YY_INPUT, you need to make sure that several values are visible in the functions which include expansions of YY_INPUT and, unfortunately, the authors of flex never really took that sort of need into account. (It could be done, though. I'm just avoiding the long description of how to do it.)
In order to provide the correct arguments to styler.ColourTo(), you'll need to track the current scintilla cursor position. To do that, initialise a cursor variable to startPos and increment it with cursor += yyleng in every action. Flex makes it easy to do something in every action: just define the macro YY_USER_ACTION. (NOTE: If you use yyless or yymore, you'll need to correct the cursor position in the corresponding actions.)
Is it possible to get access to / modify ColdFusion syntax trees at run time?
I'd wager not, and a 10 minute google search didn't find anything. Fiddling with closures and writing metadata dumps, we can see stringified versions of objects like [runtime expression], for example in the following:
function x(a=b+1) {}
WriteDump(getMetaData(x).parameters[1]["default"]);
Does it allow us to go no deeper than this, or perhaps someone knows how to keep digging and start walking trees?
Default UDF parameter expressions aren't available in function metadata as you've found. Other libraries that have implemented some form of CFML parser are
CFLint (written in Java and using ANTLR)
https://github.com/cflint/CFLint
CFFormat (also uses a binary compiled from Rust)
https://www.forgebox.io/view/commandbox-cfformat
Function LineNums (pure CFML)
https://www.forgebox.io/view/funclinenums
There is also a function callStackGet() docs: https://cfdocs.org/callstackget which might be useful to whatever you are trying to do.
And another CFML parser (written in CFML) here: https://github.com/foundeo/cfmlparser
I have a rather large single documentation page and I want to generate a symbol list (Jump to: on phobos docs, see std.compiler) with dub --build=ddoc because it is not there by default (current documentation page)
I would not want to include a list of all symbols with links in the code for obvious reasons.
I know that this is possible with ddox or javascript, but is there any way to do this using only vanilla ddoc so maintenance effort can be kept at a minimum? Thanks
Edit: I want to generate a listing for both global symbols, but also for members of classes and put the table near the class.
Ddoc is a macro system. It just replaces one thing with something else. The compiler defines certain macros for you (which you can redefine), and for actually generating a documentation page using ddoc, the compiler takes the documentation comments from the module, its list of documented symbols, etc. and basically generates a .dd page like you'd have when creating something like the dlang.org website. It's a bunch of text with ddoc markup. That ddoc markup is then replaced with whatever those ddoc macros are defined to be replaced with. By default, that's a bunch of html geared towards creating a web page, but those macros could be redefined to generate different html than the default or to generate something completely different like latex.
However, ultimately, all you're getting is the equivalent of a .dd page where you can affect what the results are by redefining the macros and thus redefining how one piece of text is converted into another. You have zero capability to iterate a list of symbols or do anything particularly turing complete. All you get is macro expansion.
That's why dlang.org uses javascript to generate the jump to links, and that's why the build process for dlang.org actually has a small D program that it runs to generate the ddoc for the navigation bar with the module list. ddoc can't do any of that. And that's why a tool like ddox uses the json output from the compiler to get at the symbol list and documentation info and generate its own thing.
So, no, you can't do anything like what you're trying to do with just standard ddoc. Really, the only options are to use javascript so that the browser can manipulate the result when viewing the document, to manipulate and/or generate ddoc with an external program, or to generate the documentation with a completely different tool such as ddox.
ddoc is a great macro system and fairly powerful as such, but if you're trying to do anything fancier than affect how the generated documentation looks, ddoc really doesn't get you there - at least not without the help of other tools to generate or manipulate either the ddoc that's processed or the results of processing the ddoc.
Ddoc documentation: https://dlang.org/spec/ddoc.html
There are some alternative documentation generators (which may or may not use ddoc) listed here: https://wiki.dlang.org/Open_Source_Projects#Documentation_Generators
I have some documentation strings embedded within the source code (C/C++ files) as XML tags and I'd like to know what's the most minimal solution to make vim autoclose the tags (closest matching tag).
I've found closetag.vim but is there away to do this neatly without modifying anything but the .vimrc file?
Vim has no built-in support for that, so the closetag.vim plugin is the proper and easiest solution. (I use it myself, too!) Of course, you can develop your own simple mappings (that search backwards for an open tag, get that, drop the attributes, add the slash, and insert that), but:
that will either be very simplistic and therefore often wrong
or ends up with as much complexity as closetag, becoming a reimplementation of that plugin
If some rather strange restrictions (e.g. a custom primitive sync across systems) only allow you to manipulate the ~/.vimrc itself, you could just append the entire plugin's code to it (though I'd recommend against such an ugly hack).