Have a subroutine with a $include file item in it. One of the common variables held in the $include file isn't being updated.
Wondering if somehow the include isn't being included, hence question regarding displaying source code including $include source code.
In UniVerse an include is a bit of source that is pulled in at compilation time and added to the source of your program.
If you have something like this...
$INCLUDE INC.BP OBJ.LOGGING.MESSAGES
The compiler will use the VOC entry "INC.BP" as the file and read in all of the lines from the record "OBJ.LOGGING.MESSAGES" as if they were entered in the source code.
You should be able to view or edit this as you would any other bit of source code. If you can compile your code than the include file at least exists.
Related
Is there a way to have comments in a _CoqProject file?
I'd like to compile only part of a library, without completely removing all the other files from the _CoqProject file.
# is treated as a comment-the-rest-of-the-line symbol.
I think it is not documented as of now (see issue #7647). But the source code and some experiments show that it works.
I am looking for a way to separate the repetitive html codes from web pages, and for this I am planning to use the macro functionality. The problem here is for every macro I need to put this macro in a file, or put some of them in a file and include this in the template file.
What I need is to include once just the directory name something like
<#import "/tags/widgetDirectory" as widgets />
here the /tags/widgetDirectory is a directory , and every files here can be seen as a macro defined.
when I need to insert a code part from a file from this directory lets say slide.ftl I will just use
<#widgets.slider />
the system will check for slider.ftl in the /tags/widgetDirectory directory . here the slider.ftl can have <#macro> as first and as last line , or these can transparently added and system can load it as a macro
this will easy my designer work.
Maybe there is better way for doing this kind of widgets/components based web design ?
best regards,
This feature (importing directories) is something that's planned for FM actually... but it won't happen anytime soon. But I guess it can be solved fairly well with a hack right now. Instead of #import, use your own TemplateMethodModelEx, that you could use like <#assign widgets = importDirectory('/tags/widgetDirectory') >. This will return a TemplateHashModel that's also implemented by you and is bound to the directory path. When an item of that hash is get, it uses Environment.getCurrentEnvironment().include. The included file is expected to create a macro with name __main or something. So then you get that variable with Environment.getCurrentNamespace().get("__main") and return it as the result of the hash lookup. Of course this hash should also maintain a cache, so that if the same item is get twice, it wont include the template for the second time, just return the macro extracted earlier. This can be developer further, so that if the include file didn't define __main, then it's supposed that it prints directly to the output, and so it will be included again, when the "tag" is called again.
I'm developing a plugin in Jekyll that inserts a new Liquid Tag (a block tag) named latex. It's purpose is to insert a block of LaTeX source code inside a post source file this way:
... post file contents ...
{% latex density=300 usepackages=pstricks-all, %}
\pspicture(5,5)
\psframe(0,0)(5,5) \psline(0,0)(5,5) \psline(0,5)(5,0)
\endpspicture
{% endlatex %}
... post file contents ...
The output post will contain a <img> tag instead of the Liquid Tag block once compiled and the LaTeX source will be compiled by a chained execution of latex, dvips, convert. So it will depend on external programs (TexLive and ImageMagick).
I've not found any issue with the explained so far. I can take the block of LaTeX, put it in a temporary file, and finally compile it to PNG. The rendered files must be put in the same folder of the post.
But just there I'm stuck: I want to put the generated PNG image to this folder inside the destination output folder. No problem defining a site-config variable to define the folder (in fact, I do that), nor put a file there. The problem is simple: I can write to the source folder, but the generated files will not be copied to the destination folder.
I know the reason: Jekyll generates first and renders afterwards. The copy process happens before the render part, so the generated files will not be copied.
I've found this SO entry: "How to generate files from Liquid blocks in Jekyll?", but the answer doesn't feel right: You must make a two-pass build for the files to be copied.
Also found "Generate file inside _site with Jekyll plugin", but this is not applicable because I don't want to render documents by templates.
The solution I've been planning is this:
Keep a folder with all the generated files and some index strategy for their final placement.
Implement a Sitewide method for the final placement procedure, something like:
class Site
def generate_latex_adds
// Code that copies the generated files to destination folders
end
end
Add self.generate_latex_adds calling that method inside the site_process.rb script just before the self.cleanup and self.write calls.
This will probably solve the problem, but I feel wrong to modify the site_process.rb. I'm considering pull this Liquid Tag to the community as a GitHub project, and as such, I must document this manual edit of site_process.rb to the users of this plugin. I know it's probably a common situation and a common solution, but I wonder if there is a better way to pospone the copy of the generated files without modifying core files. I'd like to keep the plugin simple: just copy the plugin file to the _plugins directory.
Any ideas?
EDIT: I'm more interested in the reasoning that on the actual code. I want to learn, not asking for a code solution.
As anyone has answered my question up to now, and I had kept investigating the issue. Finally I've got an elegant solution: use the Jekyll::StaticFile class. I have missed that class (sidenote: Read more carefully the docs).
When you add one object of this class to the site.static_files array, you are marking this file as pending for copy after the render process is completed. In fact, the copy of such files is done in the site.write process. Take a look at the site_process.rb file in your Jekyll installation.
The usage of this class is easy. When you need to mark a file for future copy, you simply execute a code like this:
site.static_files << Jekyll::StaticFile.new(site, site.source, path, filename)
Where path and filename depends on the location of your file in the src folder.
And that's all: You generate the files in the src folder, mark them as pending for copy and let Jekyll do the rest. No modification of site_process.rb at all!
You can take a look at the resulting LaTeX -> PNG liquid tag code at GitHub: https://github.com/fgalindo/jekyll-liquid-latex-plugin
I've also implemented a cleanup method there to eliminate orphaned generated files from posts that have been modified and rebuilt.
I am writing a small tool in c++. It is actually more of a framework that is open to customization. It has the following directory structure (simplified example).
src/
main/myexec # linked to libapple.so
apple/
coder/libapple.so
john/libapple.so
.
.
james/libapple.so
Here, the directory "coder" is a generic dummy, with some example code to generate libapple.so. Different users can checkout this tool, create directories of their own, copy the template code from "coder" and customize as they wish. Depending on the configure option (indicating the user), the respective libapple.so needs to be generated.
As I mentioned, this is a simplified example. It is not a matter of generic programming, inheritance etc. In fact, similar to the "apple" folder there are others like "scripts", "docs", "configs" etc each having similar user specific folders. Also, the tool will be maintained at a single repository location to allow me to support & maintain all the code that is not specific to user. As a policy, users are expected to modify and check-in only the contents of their folders.
The problem I am facing is with "configure.ac". I do not want to use "AC_ARG_WITH" option as it would require each new user to edit configure.ac. Also for each user the AC_CONFIG_FILE entries would be exactly the same except for his folder name. I tried using "--enable-user=User" and then AC_SUBST(USERDIR), which also helps in setting "SUBDIRS = #USERDIR#" in Makefile.am. Everything looks good except for the fact that "Makefile.in" is not getting created under the user folder when I specify "AC_CONFIG_FILE = ([apple/${USERDIR}/Makefile])".
Please advice how to overcome this issue. In the worst case I may end up in creating softlinks :(
After one full day of scratching my head, following is the solution that I have come up with.
Create a file "project_makefiles.m4.in" like this
AC_CONFIG_FILES([ apple/USERDIR/Makefile ]
Add the below to configure.ac
m4_include([project_makefiles.m4])
Create a wrapper script like "build.sh" which will create "project_makefiles.m4" from "project_makefiles.m4.in" by replacing "USERDIR". This is done before the automake.
/* $Id: file.c,v 1.0 2010/09/15 01:12:10 username Exp $ */
I find this line in many source code files in the comment at the top (header) of the file. Why? Is it aimed for the version control software? -Thanks.
These sort of comments are automatically modified by various source code control systems, things like author, date, history and so forth.
See here for some common ones for RCS which is the first source code control system I ever saw to implement this sort of thing (that doesn't mean it was the first, just that RCS was the first I ever used and it had that capability).
One particular trick we used to use was to put the line:
static char *fileId = "$Id: $";
into the source file (and header files as well, although the names had to be unique) so that, when it was built, it would automatically have the ID of the files in the executable itself.
Then we could use something like strings to find out which source files were used to build the executable. Ideal for debugging problems in the field.
It tells CVS (and other VCSs) to expand the value of the Id at check-out time, so anybody reading the source file in question will know what version exactly was checked out for it. Not very popular any more (you can always ask your VCS for such info if you keep the source file in a client / repository / working directory -- or however else your VCS calls such things;-).
I believe you are correct. It appears to be a keyword substitution string for CVS.
Take a look at this question $id: name of file, date/time creation Exp $