I got a .pl file through an eclipse plugin called JTransformer.The problem is that the .pl file I got is based on swiprolog and now I need to do query based on prolog in a java file which is easy to achieving using tuprolog. But I can't consult the .pl using tuprolog, since it was writen in swiprolog and there were some marks that only supported by swiprolog. What can I do to change it from swiprolog to tuprolog. The .pl file is in my google drive https://drive.google.com/folderview?id=0B4KCEwRVmr_yWjQwOEp3LWpYdk0&usp=sharing .
At first glance, that file has very little specific to SWI. You could try to remove altogether any directive: those lines beginning with :-. Then build you theory - I think that's tuProlog way to modules and see if you're ready to go.
Those directives, for instance :- dynamic factbase_export_time_stamp/2., eventually should be changed to :- dynamic(factbase_export_time_stamp/2)., instead of being deleted, depending on your use case. The same holds for :- multifile ones.
Related
I'm using Visual SVN on my Windows Box.
I have Repository Application, which has Framework as an svn:external. All well and good.
When I make a checkout of Application, I'd like to have the version of Application and Framework for inclusion in a footer file. This way I could have something like:
Application Version $ApplicationVersion$, Framework Version $FrameworkVersion$
Ordinarily, I understand I could use svn:keywords and add the revision - but as I understand it, svn:keywords apply on a per-file basis. A few sites have suggested using svnversion to produce the output for each variable, but I'm not entirely sure how to go about this.
Once again, on a Windows Box, using VisualSVN. I also develop on a Mac using Versions.app if it provides a more familiar interface for people to answer :)
Edit - my application is a PHP web application. As such, there is no compiling.
Thanks!
To use svnversion, you need to integrate it into the build process. If you run it on a subversion checkout, it will output a string like 73597:73598, indicating what version your tree has (notice that different files may have different versions, plus files may have also local modifications). You put something like
CFLAGS+=-DSVNVERSION="\"`svnversion`\""
into your Makefile, and then put
#define VERSION_STRING "Application version" SVNVERSION ", Framework version" FRAMEWORK_VERSION
into the code. If you don't use Make, or cannot readily have your build process run a command whose output produces a compiler command line option, then you can also use the subwcrev utility that comes with TortoiseSVN. You use that as a pre-build step, and have it transform some file with placeholders into a copy of the file with the placeholders replaced with the actual version; then your compilation will compile and link the new file.
Edit: For the PHP case, it is not possible to have the revision written automatically into a file on checkout or update. Instead, you could run svnversion on every PHP access, putting its output into the HTML response. If that gets too expensive, you can cache the svnversion result in a file and only regenerate the file if it is older than one hour (say), leaving it up to the user to remember to delete the file after an update to make it recompute the cache right away.
I got a Java project from another developer and I found several files with these two names strewn around the source folder:
vssver.scc
filesystem.attributes
I know the first one is from Visual SourceSafe but what about the second? Are these files from Visual SourceSafe too?
It's difficult to search this as Google simply ignores the dot character in between, even if I put the whole thing in quotes.
Edit: File contents are binary but mostly have references to classes from Java and libraries:
After some digging, it looks to be a (presumably obsolete) Netbeans thing. The only real reference I could find is this Netbeans mailing list post from August 2000, which says it was used to store various IDE metadata about each file.
It is created automatically when you modify some attributes of a file
using the IDE itself. [...] Every file (including directories) stores its
attributes in a filesystem.attributes located alongside it (in the
same containing directory). FileUtil.extractJar specially recognizes
filesystem.attributes in a JAR, so if you jar up your directory then
when it is extracted the jarred attributes will be applied to the
extraction folder.
The post mentions a "future reimplementation" using an XML-based filesystem, which I think has happened by now. This later post mentions using the name .nbattrs to replace the old filesystem.attributes. I'm not a NetBeans user, but this seems to be what happened; for instance, I found an example in this gist.
I've been using WinMerge, Eclipse's compare tool and Tortoise's to see my changes before committing. The problem is that when I edit a file that hasn't been edited by someone else since we last updated our autoformatter-configuration I'll see many, many changes caused by the autoformatter.
Now I have to copy the code from the previous revision, autoformat it in Eclipse and copy it into WinMerge to only see I really made.
Is there a tool that can automatically autoformat both versions of the file I'm comparing?
Any diff tool that allows you to set up an external conversion before the comparison should handle that. External conversions are primarily intended for things like Word/Excel/PDF to Text conversion, but you can do anything you want as long as you can run it from the command line.
For Beyond Compare we already have an optional add-on rule that will use Jalopy to format Java source and another one that use HTML Tidy for HTML files.
WinMerge doesn't look like it supports a Java reformatter out of the box, but their plugins page does describe how you could add one using a dll or Windows Scripting Host scriptlet.
I stumbled upon the need to find out (inside Java code) which files are dynamically loaded by an SWF-file. Is there any possibility to get a list of paths of every object referenced inside?
I tried out some libraries without proper documentation and gave up. Although I ran out of Google Search Phrases... ;)
Maybe there is an external tool which can be accessed by Java via command line?
Ggreat thanks in advance
Maybe you can get to the information you need using the dump tool which is part of Apparat.
I use actionscript more than Java, so I also recommend having a look at AS3SWF which is a great library you could use to load and analyze the swf you need. Think of it as decompiling at runtime.
Either way, the SWF Format Specifications will come in handy.
I'm not sure there's something that does exactly what you want, but I imagine you could collect all the strings (DefineText tags), loop through them and run an URL RegEx against them.
I think even if you could analyze a SWF file, you can't be sure to get this information. I have Flex Project (finally a swf file) which dynamically loads some modules, but the names (URLs) of the available modules are requested from the server. So there is no chance to retrieve this information from the main swf file.
I have written extensive JavaDoc documentation on my application, and added lots of useful info at overview.html and package.html files (including links on the former to illustrations in doc-files/). Maven's Javadoc plugin nicely uses the standard javadoc tool to generate the classic JavaDoc frameset, but now I need to generate a PDF with the whole documentation.
AurigaDoclet generates very pretty PDFs, and I was able to make DocFlex work also. However, both ignore my overview.html and package.html files (tried both inside and outside Maven - the PDF will be a once-only thing, since I'd rather have the HTMLs on the long run).
Does anyone know how to make AurigaDoclet recoginze my non-Java files? Or, alternatively, another to generate a decent-looking PDF from either the source code or the JavaDoc-generated HTML?
Nailed it. After trying all the possible tools to generate straight from the source, I returned to HTMLDOC. It is not JavaDoc-aware, but it is so well built that a few tweaks are enough to make it generate a pretty usable PDF.
Here goes a step-by-step description of how I did it:
Download the software on the releases page;
Generate your traditional HTML docs in your preferred way (Ant, Maven, command-line javadoc - your choice);
The GUI is nice, but adding all files manually can be cumbersome, so just create a .book file with Document Type set to "Web Page", add one of the HTML files from your generated javadoc's root folder (e.g., overview-summary.html, anyone will do, it's just for reference on step 5). On the Output tab select the PDF format and set a name for it, and add other options to your heart's content (logos, colors, lots of cool stuff here). Save this project (say, myjavadocpdf.book) and close the GUI
Generate a list of all HTML files in your javadoc. I did it with Cygwin's find command (my DOS/cmd shell days are long over), but you can do anything you want, as long as you get a file list. In my case a find . | grep html$ | sort -r > files.txt did the trick;
For Windows users, dir /s/b *.html > files.txt should do the same (but keep in mind you may have to replace \s with /s if they appear like so on the next step).
Open the .book file generated on step 3 in your favorite pure text editor (as a programmer you should have strong opinions on that, so will keep my opinions to myself - NOT ;-) ) and append the list generated on step 4 to this .book file (it keeps the list of files at the end, making life really easy). Don't forget to fix the relative paths, if needed with a global search/replace (that's why you needed at least one file added on step 3 - to see which file path pattern htmldoc expects);
Now you should sort the files in a convenient order. I put my overview first, then package descriptions and each class, then the full index, and everything else at the end. Remember that any file you delete will become an external (hence broken) link, so choose wisely;
Save your .book file and re-open it on HTMLDOC. Voila: all files added and sorted. Click on generate. That's it!
You may want to fiddle with images (hint: use HTML width/height, not style/css). In the end, the resulting file is surprisingly good: nice looking and fully navigable for internal and external links. Impressive when you consider that the tool is not Java(Doc) aware at all...
EDIT: software is now free from original author; updated links, thank you #mohammed
According to the Sun JavaDoc FAQ, there's a couple of options -- mostly free, with one or two commercial offerings as well. Check it out at http://java.sun.com/j2se/javadoc/faq/index.html#print.
AurigaDoclet fails to process package.html.
For a fix see my comment at https://sourceforge.net/projects/aurigadoclet/forums/forum/339169/topic/1572199/index/page/1
If this question was bumped anyways, I can use this to link my ltxdoclet project.
This creates from the source (by being a JavaDoc plugin) documentation in LaTeX format, which you then can pass through PdfLaTeX to produce a PDF.
Optionally it also can include pretty-printed source code.