I want to create a documentation for my own Project in folder "MyOwnProject".
Standard seems to be Godoc where the help tells me to use godoc package [name...]
It doesn't seem to work tough:
godoc package MyOwnProject -path ..../go
-> Cannot find file ..../go/src/pkg/package
godoc MyOwnProject -path ..../go
-> Cannot find file ..../go/src/pkg/MyOwnProject
For one, the directory /src/pkg/ it adds doesn't make any sense, stuff is either in go/pkg OR go/src. Next it somehow seems to be looking for a single file. I want it to work on all files given for that project. What am I doing wrong with my parameters?
The word package in usage: godoc package [name ...] is a placeholder for the full name of your package, and [name ...] is a placeholder for the name of a specific function/variable which you want to restrict the search to. The three dots mean that you can specify more than one name. The square brackets mean that it is optional.
If your package is located in $GOPATH/src/MyOwnProject, then its full name is simply MyOwnProject and all you need to type to get the full documentation of your package is:
godoc MyOwnProject
Related
I'm using clearcase 8.0.1.17, I want to compare a file in my wiew and his version at a specific baseline.
I can open version tree and see my baseline but I want to do that with command line.
My purpose is to do something like :
> myScript.sh file.c baseline
This will open bcompare and compare my actual file vs the version baseline
How can I do that ?
I can do :
> cleartool lsvtree myfile | grep myBaseline
But is there is no changes at myBaline it doesn't work.
First, make sure to try that in a dynamic view
Then check out the concept of version extended path: using a pathname_ccase syntax, you can add characters to the end of a relative or full path name, turning it into a VOB-extended path name.
VOB-extended path names that specify versions of elements are the most commonly used; they are called version-extended path names.
/vobs/proj/foo.c##/main/motif/4
That means you can:
find the version of the file with as label the Baseline name: see "How to search files by label"
compare that extended path name with the one currently visible in your view.
The idea is: in a dynamic view, you can access (read the content of) any version of a file through the extended pathname.
Which means you can execute bcompare on those contents (the one with the extended path, and the one currently visible in your view)
Of course, if this is an incremental baseline (instead of full), you might need a cleartool chbl -full to convert it to a full baseline, applying the UCM associated label to all files.
If you do a cleartool describe baseline:mybaseline#\myvobtag you will probably find that your baseline is an incremental baseline. Incremental baselines do not have a label on the version if it was changed in a prior baseline and not the current one...
cleartool diffbl -versions {baseline} {current stream} | grep {filename} can be used to find the version of the target file that is in the baseline, which you can use to do the compare...
I'm trying to write a bunch of functions in an SML file and then load them into the interpreter. I've been googling and came across this:
http://www.smlnj.org/doc/interact.html
Which has this section:
Loading ML source text from a file
The function use: string -> unit interprets its argument as a file name relative to sml's current directory and loads the text from that file as though it had been typed in. This should normally be executed at top level, but the loaded files can also contain calls of use to recursively load other files.
So I have a test.sml file in my current directory. I run sml, all good so far. Then I try use test.sml; and I get:
stdIn:1.6-1.14 Error: unbound structure: test in path test.sml
Not sure why this isn't working. Any ideas?
Thanks,
bclayman
As you mentioned, the function use has type string -> unit. This means it takes a string and returns unit. When you do use test.sml, you are not giving it a string. You need to do use "test.sml" (notice the quotes)
I inherited an ADA program where the source file names and package file names don't follow the default naming convention. ADA is new to me, so I may be missing something simple, but I can't see it in the GNAT Pro User's Guide. (This similar question didn't help me.)
Here are a couple of examples:
File Name: C_Comm_Config_S.Ada
Package Name: Comm_Configuration
File Name: D_Bus_Buffers_S.Ada
Package Name: Bus_Buffers
I think I have the _S.Ada and _B.Ada sorted out, but I can't find anything in the program source or build files that show the binding between the Package Name and the rest of the File Name.
When I compile a file that doesn't use any other packages, I get a warning: file name does not match unit name... This appears to be from the prefix of C_ or D_, in this particular case.
Also, I'm not clear if the prefixes C_ and D_ have any special meaning in the context of ADA, but if it does, I'd like to know about it.
So I appear to have two issues, the Prefix of C_ or D_ and in some cases the rest of the file name doesn't match the package.
You could use gnatname: see the User’s Guide.
I copied subdirectories a/ and d/ from the ACATS test suite to a working directory and created a project file p.gpr:
project p is
for source_dirs use ("a", "d");
end p;
and ran gnatname with
gnatname -P p -d a -d d \*.ada
which resulted in an edited p.gpr and two new files, p_naming.gpr and p_source_list.txt. These are rather long, but look like
p.gpr:
with "p_naming.gpr";
project P is
for Source_List_File use "p_source_list.txt";
for Source_Dirs use ("a", "d");
package Naming renames P_Naming.Naming;
end P;
p_naming.gpr:
project P_Naming is
for Source_Files use ();
package Naming is
for Body ("d4a004b") use "d4a004b.ada";
for Body ("d4a004a") use "d4a004a.ada";
for Body ("d4a002b") use "d4a002b.ada";
...
for Body ("aa2010a_parent.boolean") use "aa2010a.ada" at 4;
for Body ("aa2010a_parent") use "aa2010a.ada" at 3;
for Spec ("aa2010a_parent") use "aa2010a.ada" at 2;
for Spec ("aa2010a_typedef") use "aa2010a.ada" at 1;
...
for Body ("a22006d") use "a22006d.ada";
for Body ("a22006c") use "a22006c.ada";
for Body ("a22006b") use "a22006b.ada”;
end Naming;
end P_Naming;
The for Body ("aa2010a_parent") use "aa2010a.ada" at 3; is used when there’s more than one unit in the source file.
p_source_list.txt:
a22006b.ada
a22006c.ada
a22006d.ada
a27003a.ada
a29003a.ada
...
d4a002b.ada
d4a004a.ada
d4a004b.ada
When building, for example, test d4a004b, you have to use the file name and suffix:
gnatmake -P p d4a004b.ada
The Ada standard does not say anything about source file naming conventions. As it appears that you use GNAT, I assume that you mean the "GNAT default naming convention".
You can tell GNAT about alternatively named files in a Naming package inside your project files.
A simple example:
project OpenID is
...
package Naming is
for Implementation ("Util.Log.Loggers.Traceback")
use "util-log-loggers-traceback-gnat.adb";
for Implementation ("Util.Serialize.IO.XML.Get_Location")
use "util-serialize-io-xml-get_location-xmlada-4.adb";
end Naming;
end OpenID;
We are moving into Scala/SBT from a Java/Gradle stack. Our gradle builds were leveraging a task called processResources and some Ant filter thing named ReplaceTokens to dynamically replace tokens in a checked-in .properties file without actually changing the .properties file (just changing the output). The gradle task looks like:
processResources {
def whoami = System.getProperty( 'user.name' );
def hostname = InetAddress.getLocalHost().getHostName()
def buildTimestamp = new Date().format('yyyy-MM-dd HH:mm:ss z')
filter ReplaceTokens, tokens: [
"buildsig.version" : project.version,
"buildsig.classifier" : project.classifier,
"buildsig.timestamp" : buildTimestamp,
"buildsig.user" : whoami,
"buildsig.system" : hostname,
"buildsig.tag" : buildTag
]
}
This task locates all the template files in the src/main/resources directory, performs the requisite substitutions and outputs the results at build/resources/main. In other words it transforms src/main/resources/buildsig.properties from...
buildsig.version=#buildsig.version#
buildsig.classifier=#buildsig.classifier#
buildsig.timestamp=#buildsig.timestamp#
buildsig.user=#buildsig.user#
buildsig.system=#buildsig.system#
buildsig.tag=#buildsig.tag#
...to build/resources/main/buildsig.properties...
buildsig.version=1.6.5
buildsig.classifier=RELEASE
buildsig.timestamp=2013-05-06 09:46:52 PDT
buildsig.user=jenkins
buildsig.system=bobk-mbp.local
buildsig.tag=dev
Which, ultimately, finds its way into the WAR file at WEB-INF/classes/buildsig.properties. This works like a champ to record build specific information in a Properties file which gets loaded from the classpath at runtime.
What do I do in SBT to get something like this done? I'm new to Scala / SBT so please forgive me if this seems a stupid question. At the end of the day what I need is a means of pulling some information from the environment on which I build and placing that information into a properties file that is classpath loadable at runtime. Any insights you can give to help me get this done are greatly appreciated.
The sbt-buildinfo is a good option. The README shows an example of how to define custom mappings and mappings that should run on each compile. In addition to the straightforward addition of normal settings like version shown there, you want a section like this:
buildInfoKeys ++= Seq[BuildInfoKey](
"hostname" -> java.net.InetAddress.getLocalHost().getHostName(),
"whoami" -> System.getProperty("user.name"),
BuildInfoKey.action("buildTimestamp") {
java.text.DateFormat.getDateTimeInstance.format(new java.util.Date())
}
)
Would the following be what you're looking for:
sbt-editsource: An SBT plugin for editing files
sbt-editsource is a text substitution plugin for SBT 0.11.x and
greater. In a way, it’s a poor man’s sed(1), for SBT. It provides the
ability to apply line-by-line substitutions to a source text file,
producing an edited output file. It supports two kinds of edits:
Variable substitution, where ${var} is replaced by a value. sed-like
regular expression substitution.
This is from Community Plugins.
This is really a newbie question - but basically, how do I enable a template for certain filetypes.
Basically, I just want the template to insert a header of sorts, that is with some functions that I find useful, and libraries loaded etc.
I interpret
:help template
the way that I should place this in my vimrc
au BufNewFile,BufRead ~/.vim/skeleton.R
Running a R script then shows that something could happen, but apparently does not:
--- Auto-Commands ---
This may be because a template consists of commands (and there are no such in skeleton.R) - and in this case I just want it to insert a text header (which skelton.R consist of).
Sorry if this question is mind boggeling stupid ;-/
The command that you've suggested is not going to work: what this will do is run no Vim command whenever you open ~/.vim/skeleton.R
A crude way of achieving what you want would be to use:
:au BufNewFile *.R r ~/.vim/skeleton.R
This will read (:r) your file whenever a new *.R file is created. You want to avoid having BufRead in the autocmd, or it will read the skeleton file into your working file every time you open the file!
There are many plugins that add a lot more control to this process. Being the author and therefore completely biased, I'd recommend this one, but there are plenty of others listed here.
Shameless plug:
They all work in a relatively similar way, but to explain my script:
You install the plugin as described on the linked page and then create some templates in ~/.vim/templates. These templates should have the same extension as the 'target' file, so if it's a template for .R files, call it something like skeleton.R. In your .vimrc, add something like this:
let g:file_template_default = {}
let g:file_template_default['R'] = 'skeleton'
Then create your new .R file (with a filename, so save it if it's new) and enter:
:LoadFileTemplate
You can also skip the .vimrc editing and just do:
:LoadFileTemplate skeleton
See the website for more details.
Assume that your skeletons are in your ~/.vim/templates/ directory, you can put this
snippet in your vimrc file.
augroup templates
au!
" read in templates files
autocmd BufNewFile *.* silent! execute '0r ~/.vim/templates/skeleton.'.expand("<afile>:e")
augroup END
Some explanation,
BufNewFile . = each time we edit a new file
silent! execute = execute silently, no error messages if failed
0r = read file and insert content at top (0) in the new file
expand(":e") = get extension of current filename
see also http://vim.wikia.com/wiki/Use_eval_to_create_dynamic_templates
*fixed missing dot in file path
Create a templates subdirectory in your ~/.vim folder
$ mkdir -p ~/.vim/templates
Create a new file in subdirectory called R.skeleton and put in the header and/or other stuff you want to automagically load upon creating a new ".R " file.
$ vim ~/.vim/templates/R.skeleton
Then, add the following to your ~/.vimrc file, which may have been suggested in a way by "guest"
autocmd BufNewFile * silent! 0r $HOME/.vim/templates/%:e.skeleton
Have a look at my github repository for some more details and other options.
It's just a trick I used to use .
It's cheap but If you ain't know nothing about vim and it's commands it's easy to handle.
make a directory like this :
~/.vim/templates/barney.cpp
and as you konw barney.cpp should be your template code .
then add a function like ForUncleBarney() to end of your .vimrc file located in ~/.vimrc
it should be like
function ForBarneyStinson()
:read ~/.vim/templates/barney.cpp
endfunction
then just use this command in vim
:call ForBarneyStinson()
then you see your template
as an example I already have two templates for .cpp files
:call ForBarney()
:call ACM()
sorry said too much,
Coding's awesome ! :)
Also take a look at https://github.com/aperezdc/vim-template.git.
I use it and have contributed some patches to it and would argue its relatively full featured.
What about using the snipmate plugin? See here
There exist many template-file expanders -- you'll also find there explanations on how to implement a rudimentary template-file expander.
For my part, I'm maintaining the fork of muTemplate. For a simple start, just drop a {ft}.template file into {rtp}/template/. If you want to use any (viml) variable or expression, just do. You can even put vim code (and now even functions) into the template-file if you wish. Several smart decisions are already implemented for C++ and vim files.