Since my experience with HTML is fairly rudimentary (and pretty old), I am not sure if my requirement is realistic.
Lets say that I have quite a few files containing Lua source-code, and all of them have the ".lua" extension and available in a particular subdirectory. What I'd like to do is create a static index.html file, which when loaded in a browser, would show the list of the lua source-code files in a drop-down. Once one of the source-code files is selected, I'd like that the file gets loaded into an "area" on the same page, and is pretty-printed, i.e. with syntax-highlighting in browser. I was wondering if I could use something like the google-code-prettyfy for the syntax-highlighting part ? Also, I am not clear if an external lua sourcecode file can be loaded, and displayed within a certain region of html page as being rendered. If yes, would appreciate elaboration on the how part.
A tool like LDoc can be used to accomplish a lot of what you want, much as Doxygen would be used for a C language source kit.
Both are heavily driven by inclusion of specially formatted comments that carry documentation.
I know Doxygen can fold source code into the generated document set, I don't recall about LDoc. Both are actively under development.
It isn't necessarily a bad idea to use both tools on a project, especially if you have C source code implementing Lua modules. You could use Doxygen to build the overall document tree for your engine and C modules, and LDoc to build documentation of the Lua parts. It should be possible with a little care and configuration of both tools to get them to play well together.
I have created a separate include files for general purpose uses in my assembly programs. (such as string operations / formatted input/etc.)
When i include those files i notice all of the functions get included in the target binary file.
Is there way I can manage to include only the used functions(like using include files in C/C++ library files)?
I'm using MASM and targeting x86.
To extract separate functions from an object file, the linker needs to know where each one starts and where it ends. It can't reliably tell that from the assembly, so you need to help it.
A common way is to put each function into a separate file and assemble them like that; this way the linker can include or exclude each object file independently. This is the simplest way and works with most assemblers, not just MASM, so I'd recommend trying it.
Another way could be to put each function into a separate segment; the MS linker can exclude unused segments but only if they're marked as so-called "COMDAT" (communal data). Unfortunately, MASM does not support setting this attribute.
There have been some work on adding this info to the OBJ file as a post-processing step, but unfortunately the archive with the tool seems to be gone from the Internet:
Function level linking with MASM
Additional links:
How to achieve "function level linking" with MASM? (includes a tool for semi-automated splitting into several files).
flat assembler - COMDAT support
MSDN forums - Comdat
JWASM:
Support for COFF COMDATs
The last link mentions "Support for COMDAT is added in jwasm v2.10."
I've just moved my project that was created on Kohana3.3 from Windows to Ubuntu (local server), and it stopped working. I believe the problem is upper-/lowercase issues (it says for Table.__ or Model_ they don't exist).
I need some explanation about uppercase/lowercase file names and class names.
What I've found is SO question: Kohana 3.3 Not working from Subdirectory:
Kohana 3.3 adds partial support for the PHP Framework Interop Group's PSR-0 standard. PHP framework developers are encouraged to follow this standard to simplify interaction between frameworks. One of the requirements of PSR-0 is that the class names and file names match.
Also, I see the Controller folder in Kohana3.3 starts with a capital letter C (not as in 3.2). Also, Welcome.php file starts with W (not as in 3.2).
So, my simple questions for Kohana3.3 are:
Should the Model folder start with a capital letter?
Should all controller files start with a capital letter?
Should all model files in the Model folder start with a capital letter?
Should I write ORM::factory('Capital'), but not ORM::factory('capital')?
What about view folder: is it View or view?
I've read some examples for Kohana, but from what I've found I doubt it is for 3.3.
Also, my question: why did it work under Windows?
You can figure most of this out by simply reading the documentation and/or just experimenting and seeing what works and what does not work.
In short, in PSR-0 filenames must be exactly the same as the class name. So, if you call a class named Penguins_CanNot_Fly then the filename should be exactly Penguins/CanNot/Fly.php.
On Linux filenames are case sensitive. So, File.txt and file.txt are two different files. On Windows, however, the two files are considered to be the same file (this is because windows is case insensitive). This means that PSR-0 does not work properly on Windows, unless you modify the autoloader to check the exact file path.
As for the ORM, yes you need to keep in mind that models should be case sensitive. ORM::factory('Blog') and ORM::factory('blog') will load different models, but the same table will be used.
It would be nice to have a more or less complete list over what files and/or directories that shouldn't (in most cases) be under source control. What do you think should be excluded?
Suggestion so far:
In general
Config files with sensitive information (passwords, private keys etc.)
Thumbs.db, .DS_Store and desktop.ini
Editor backups: *~ (emacs)
Generated files (for instance DoxyGen output)
C#
bin\*
obj\*
*.exe
Visual Studio
*.suo
*.ncb
*.user
*.aps
*.cachefile
*.backup
_UpgradeReport_Files
Java
*.class
Eclipse
I don't know, and this is what I'm looking for right now :-)
Python
*.pyc
Temporary files
- .*.sw?
- *~
Anything that is generated. Binary, bytecode, code/documents generated from XML.
From my commenters, exclude:
Anything generated by the build, including code documentations (doxygen, javadoc, pydoc, etc.)
But include:
3rd party libraries that you don't have the source for OR don't build.
FWIW, at my work for a very large project, we have the following under ClearCase:
All original code
Qt source AND built debug/release
(Terribly outdated) specs
We do not have built modules for our software. A complete binary is distributed every couple weeks with the latest updates.
OS specific files, generated by their file browsers such as
Thumbs.db and .DS_Store
Some other Visual Studio typical files/folders are
*.cachefile
*.backup
_UpgradeReport_Files
My tortoise global ignore pattern for example looks like this
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
files that get built should not be checked in
I would approach the problem a different way; what things should be included in source control? You should only source control those files that:
( need revision history OR are created outside of your build but are part of the build, install, or media ) AND
can't be generated by the build process you control AND
are common to all users that build the product (no user config)
The list includes things like:
source files
make, project, and solution files
other build tool configuration files (not user related)
3rd party libraries
pre-built files that go on the media like PDFs & documents
documentation
images, videos, sounds
description files like WSDL, XSL
Sometimes a build output can be a build input. For example, an obfuscation rename file may be an output and an input to keep the same renaming scheme. In this case, use the checked-in file as the build input and put the output in a different file. After the build, check out the input file and copy the output file into it and check it in.
The problem with using an exclusion list is that you will never know all the right exclusions and might end up source controlling something that shouldn't be source controlled.
Like Corey D has said anything that is generated, specifically anything that is generated by the build process and development environment are good candidates. For instance:
Binaries and installers
Bytecode and archives
Documents generated from XML and code
Code generated by templates and code generators
IDE settings files
Backup files generated by your IDE or editor
Some exceptions to the above could be:
Images and video
Third party libraries
Team specific IDE settings files
Take third party libraries, if you need to ship or your build depends on a third party library it wouldn't be unreasonable to put it under source control, especially if you don't have the source. Also consider some source control systems aren't very efficient at storing binary blobs and you probably will not be able to take advantage of the systems diff tools for those files.
Paul also makes a great comment about generated files and you should check out his answer:
Basically, if you can't reasonably
expect a developer to have the exact
version of the exact tool they need,
there is a case for putting the
generated files in version control.
With all that being said ultimately you'll need to consider what you put under source control on a case by case basis. Defining a hard list of what and what not to put under it will only work for some and only probably for so long. And of course the more files you add to source control the longer it will take to update your working copy.
Anything that can be generated by the IDE, build process or binary executable process.
An exception:
4 or 5 different answers have said that generated files should not go under source control. Thats not quite true.
Files generated by specialist tools may belong in source control, especially if particular versions of those tools are necessary.
Examples:
parsers generated by bison/yacc/antlr,
autotools files such as configure or Makefile.in, created by autoconf, automake, libtool etc,
translation or localization files,
files may be generated by expensive tools, and it might be cheaper to only install them on a few machines.
Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.
This exception is discussed by the svn guys in their best practices talk.
Temp files from editors.
.*.sw?
*~
etc.
desktop.ini is another windows file I've seen sneak in.
Config files that contain passwords or any other sensitive information.
Actual config files such a web.config in asp.net because people can have different settings. Usually the way I handle this is by having a web.config.template that is on SVN. People get it, make the changes they want and rename it as web.config.
Aside from this and what you said, be careful of sensitive files containing passwords (for instance).
Avoid all the annoying files generated by Windows (thumb) or Mac OS (.ds_store)
*.bak produced by WinMerge.
additionally:
Visual Studio
*.ncb
The best way I've found to think about it is as follows:
Pretend you've got a brand-new, store-bought computer. You install the OS and updates; you install all your development tools including the source control client; you create an empty directory to be the root of your local sources; you do a "get latest" or whatever your source control system calls it to fetch out clean copies of the release you want to build; you then run the build (fetched from source control), and everything builds.
This thought process tells you why certain files have to be in source control: all of those necessary for the build to work on a clean system. This includes .designer.cs files, the outputs of T4 templates, and any other artifact that the build will not create.
Temp files, config for anything other than global development and sensitive information
Things that don't go into source control come in 3 classes
Things totally unrelated to the project (obviously)
Things that can be found on installation media, and are never changed (eg: 3rd-party APIs).
Things that can be mechanically generated, via your build process, from things that are in source control (or from things in class 2).
Whatever the language :
cache files
generally, imported files should not either (like images uploaded by users, on a web application)
temporary files ; even the ones generated by your OS (like thumbs.db under windows) or IDE
config files with passwords ? Depends on who has access to the repository
And for those who don't know about it : svn:ignore is great!
If you have a runtime environment for your code (e.g. dependency libraries, specific compiler versions etc.) do not put the packages into the source control. My approach is brutal, but effective. I commit a makefile, whose role is to downloads (via wget) the stuff, unpack it, and build my runtime environment.
I have a particular .c file that does not go in source control.
The rule is nothing in source control that is generated during the build process.
The only known exception is if a tool requires an older version of itself to build (bootstrap problem). In that case you will need a known good bootstrap copy in source control so you can build from blank.
Going out on a limb here, but I believe that if you use task lists in Visual Studio, they are kept in the .suo file. This may not be a reason to keep them in source control, but it is a reason to keep a backup somewhere, just in case...
A lot of time has passed since this question was asked, and I think a lot of the answers, while relevant, don't have hard details on .gitignore on a per language or IDE level.
Github came out with a very useful, community collaborated list of .gitignore files for all sorts of projects and IDEs that is worth taking a look.
Here's a link to that git repo: https://github.com/github/gitignore
To answer the question, here are the related examples for:
C# -> see Visual Studio
Visual Studio
Java
Eclipse
Python
There are also OS-specific .gitignore files. Following:
Windows
OS X
Linux
So, assuming you're running Windows and using Eclipse, you can just concatenate Eclipse.gitignore and Windows.gitignore to a .gitignore file in the top level directory of your project. Very nifty stuff.
Don't forget to add the .gitignore to your repo and commit it!
Chances are, your IDE already handles this for you. Visual Studio does anyway.
And for the .gitignore files, If you see any files or patterns missing in a particular .gitignore, you can open a PR on that file with the proposed change. Take a look at the commit and pull request trackers for ideas.
I am always using www.gitignore.io to generate a proper one .ignore file.
Opinion: everything can be in source control, if you need to, unless it brings significant repository overhead such as frequently changing or large blobs.
3rd party binaries, hard-to-generate (in terms of time) generated files to speed up your deployment process, all are ok.
The main purpose of source control is to match one coherent system state to a revision number. If it would be possible, I'd freeze the entire universe with the code - build tools and the target operating system.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Let's compile a list of tips.
(Understandably there will be some subjectivity involved, but some pointers would be useful to someone overwhelmed by tackling a large project within the Flash framework.)
These are just scattered thoughts on organization for projects being worked on mostly with the Flash IDE.
First, I highly recommend using source control, like Subversion, CVS, or Git.
Organization of filesystem folder structure is subjective, but I generally have a "src" folder for all my source FLAs and AS class files, and a "deploy" or "bin" folder for compiled files. The src folder would contain class package files, with class packages organized in reverse domain style (e.g. - com.codehinting.projectname.context ). Modify the publish path of your FLA to publish to the deploy folder by tracing back up using the "../" path segment, for as many levels as needed to trace back from the nesting in the src folder.
Also, I typically place third-party libraries (that are pretty well "baked") in a separate location and then modify the global classpath in the Flash IDE to point to this location.
Two extremely handy plugins for the Flash IDE are Create Basic Layers and Library Generator, which quickly create your skeleton layer and library folder structure - saves time versus manually creating layers and folders.
I adopted the Project Naming guidelines from Blitz:
Blitz Project Naming Conventions & Organizational Guidelines
My DEV_Source is divided in database/flash/flex directories.
The Flex directory is standard to the Adobe conventions, but the flash has a custom setup.
bin -- Output of SWF, contains JS and index.html
classes -- AS3 code
doc -- AS Doc output of code
libs -- 3rd party libraries and components
src -- FLA files (set the Publish settings to compile in bin)
test -- AS Unit test cases of classes
A complex project will have many dependencies. In my Flash projects, I put all my libraries in a version controlled location as they are. Third party libraries are usually a mishmash of assets, code, demos and docs.
I keep a small yaml file that keeps track of the location of each type of resource associated with each library on my system. When I add a new library, its location goes into this file first, then I run my Ruby script to move the files over to a single location. This way there is no jockeying around with third party library paths, and making sure include paths in my projects match in my fla files and Flex builder projects.
A single source to bind them all.