We have a C++ Builder application that has lived through many versions of Embarcadero RAD Studio. Now I was trying to get it to compile in XE2 and ran into a problem where a class called TGroup became ambiguos with the TGroup class of Winsock.
To my anger I found that the initial architects of the system didn't use any namespaces, which would have solved this problem. I decided to add all the project code to a single namespace to start with. But pretty soon it dawned on me that I would have to go through about 1400 .h and .cpp files.
Please, for the love of god... Is there a good tool out there to quickly encapsulate an entire project within a namespace?
Most of the files differ a bit in layout. Some have defines after the includes and some do not etc. But to just insert the namespace declaration after the includes should probably work ok to start with and then close it just before the last #endif, which is the inclusion guard #define.
Check if the offending header files already use namespaces. All VCL-based header files DO use namespaces, but they also have using namespace statements at the bottom to dump everything into the global namespace by default. Most versions have special #define values you can set to disable that behavior.
Related
I am using Delphi XE6 and using Datasnap and JSON in my project. There is a bug I want to correct in the VCL unit System.JSON.pas (in the TJSONString.ToString function) where it should be escaping backslash characters as well as quotes. In order to fix this I carried out the following :
Copied System.JSON.pas from the standard VCL source folder to my project source folder
Added System.JSON.pas to my project (using the newly copied file)
Fixed the bug and attempted to compile
I get the error 'Unit Data.DBXCommon was compiled with a different version of System.JSON.TJSONObject'
I can see that the Data.DBXCommon unit references System.JSON, so I guess the compiler is now seeing 2 versions - my fixed version and the standard VCL version.
What is the correct way to implement VCL changes to avoid this problem?
There are two common reasons for this issue:
You made changes to the interface section of the unit. You cannot do this without also re-compiling all units that use the unit you are modifying.
You re-compile the unit with different compiler options from those used to build it originally. Deal with that by ensuring the compiler options used to compile the unit you modify are the same as used by Embarcadero. Typically Embarcadero compiles with default options. Impose these directly in the source file being modified, right at the very top of the file.
Having said this, a recent question here on a similar topic could not be resolved using option 2 above. In that question, under XE6 only, the unmodified Classes unit could not be re-compiled and linked at all. Which makes me wonder if this particular technique has had its day. Perhaps it's not even possible. Before you give up, see if you can compile and link the unmodified unit.
More broadly, using a detour is generally an easier way to solve such problems as you face. Using a detour rather than re-compiling makes the management of the fix cleaner and simpler.
Update 1
I cannot get the unmodified System.JSON unit to re-compile and link. Which I think means that the issue raised in that other question is broader than just the Classes unit. I think you will find this a tricky hurdle to overcome and recommend the use of a detour.
Update 2
The problem that appears to have been introduced in XE6, seems to have been resolved by the release of XE7. The unmodified System.JSON unit will compile and link in XE7.
What if Delphi XE6 original System.JSON.dcu wasn't compiled with Delphi XE6 but it was compiled with one of the previous versions of Delphi.
You claim that you managed to implement your fix in Delphi XE2 using same approach by changing source and then recompiling System.JSON. SO I suggest you first make a comparison between original System.JSON files that ship with both Delphi XE2 and Delphi XE6.
If they are the same then the changed System.JSON.dcu that you managed to recompile with Delphi XE2 might also work with Delphi XE6.
I resolved a similar issue by :
Deleting the .dcu files which are on different versions ( i.e. conflicting files).
Re-build the project to create new .dcu files.
When I compile the same project with ant many times it gives a different sizes for each compilation
I added the rsl and more option to mxml it works fine ,but the size is still changed
Please any idea to unify the size
This is not really possible, unless you do some, quite involved post-processing. Below is the list of things I know to change the size between compiles, but it may not be exhaustive:
When you compile pure AS3 project or a project that uses framework:
Resources you embed on variables have their class names generated using the current date in the name.
Flex compiler generates a tag of obscure purpose (can be removed manually, but persists in release builds), which seem to contain a GUID and a compilation time or something similar. It is usually found at the very beginning of the SWF file, somewhere after the rectangle of the SWF dimensions.
In a project that uses framework:
All code generation is suspect to generating inconsistent names, particularly, all bindings will certainly produce different assembly upon each compile. Styles and some other rarely used metadata will cause this too.
Specifically for spark skins, which come as sources rather then compiled libraries - some of them embed resources in a bad way, so you would probably need to compile them into a library and plug it into a project, removing the sources from the source path.
All in all, if you are using pure AS3 project, your task is difficult, but doable (will require following certain conventions and some post-build script that unzips the SWF, purges the compiler-added extra tag and zips the SWF back. But if it is a SWF based on the framework - I'd say the effort isn't worth it, just accept it cannot be done.
We are currently using the RazorGenerator library to generate pre-compiled views for a project. Up until now we have been using the Visual Studio Extension to handle the generation, with these generated files also being committed to our repository.
This is causing bit of a pain point as we constantly have to resolve merge defects in a generated file. With that in mind I've set about to try and integrate the RazorGenerator.MsBuild target library into our build process so we can get away from storing the code-genned files in our repository.
So far I've disabled the VS Extension, and got the build target working as required however I've now lost intellisense and resharper support for the generated files as they are no longer part of the Solution.
I'm wondering if anyone else has come down this path before, Ideally what I'm trying to achieve is using the Build target to generate the cs files, removing the need to include these cs files in the repository, and still having Intellisense/Resharper coverage for the generated files.
Any thoughts?
I've resolved this problem by creating a an empty partial class for each of the cshtml templates which implements our own base class, which in-turn implements RazorGenerator.Templating.RazorTemplateBase.
By doing it this way we have access to all the publicly accessible properties and methods exposed on those classes which makes intellisense/resharper happy and at build time the templates .cs files are generated which do the heavy lifting for outputting the layout etc.
I'm having trouble finding good advice and common practices for the use of namespaces in Clojure. I realize that namespaces are not the same as Java packages so I'm trying to tease out the conventions in Clojure, which seem surprisingly hard to determine.
I think I have a pretty good idea how to split functions into clj files and even roughly how I'd want to organize those files into directories. But beyond that I'm having trouble finding the mechanics for my dev environment. Some inter-related questions:
Do I use the same uniqueness conventions for Clojure namespaces as I would normally use for Java packages? [ie backwards-company-domain.project.subsystem]
Should I save my files in a directory structure that matches my namespaces? [ala Java]
If I have multiple namespaces, do I need to compile all of my code into a jar and add it to my classpath to make it accessible?
Should each namespace compile to one jar? Or should I create a single jar that contains clj code from many namespaces?
Thanks...
I guess it's ok if you think it helps, but many Clojure projects don't do so -- cf. Compojure (using a top-level compojure ns and various compojure.* ns's for specific functionality), Ring, Leiningen... Clojure itself uses clojure.* (and clojure.contrib.* for contrib libraries), but that's a special case, I suppose.
Yes! You absolutely must do so, or else Clojure won't be able to find your namespaces. Also note that you musn't use the underscore in namespace names or the hyphen in filenames and wherever you use a hyphen in a namespace name, you must use an underscore in the filename (so that the ns my.cool-project is defined in a file called cool_project.clj in a directory called my).
You need to make sure all your stuff is on the classpath, but it doesn't matter if it's in a jar, multiple jars, a mixture of jars and directories on the filesystem... As long as it obeys the correct naming conventions (your point no. 2) you should be fine.
However, do not compile things ahead-of-time if there's no particular reason to do so -- this may prevent your code from being portable across various versions of Clojure without providing any benefits besides a slightly improved loading time.
You'll still need to use AOT compilation sometimes, notably in some Java interop scenarios -- the documentation of the relevant functions / macros always mentions that. There are examples of things requiring AOT in clojure.contrib; I've never needed it, so I can't provide much in the way of details.
I'd say you should use jars for functional units of code. E.g. Compojure and Ring get packaged as single jars containing many namespaces which together compose the whole package. Also, clojure.contrib is notably packaged as a single jar with multiple unrelated libraries; but that again may be a special case.
On the other hand, a single jar containing all of your project's code together with its dependencies might occasionally be useful for deployment. Check out the Leiningen build tool and its 'uberjar' facility if you think that sort of thing may be useful to you.
Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.
I spent this morning in trying to figure out where the system.linq.expressions namespace is. The following is what I did:
In VS 2008, Create a new C#/Smart Device/Windows Mobile 6 Professional SDK/.NET CF v3.5/Class Library
Used SqlMetal (in Program Files/Microsoft SDKs/Windows/v6.0A/Bin) to generate the data context.
Added the data context .cs file into the project.
Compile and many errors for missing namespaces: System.Data.Linq, System.Data.Linq.Mapping, System.Linq.Expressions
After some research added System.Data.Linq.dll in c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 (The dll was not directly listed when I choose to add reference and I used "browse" tab to finally located the one, which is for normal framework)
Compile again, less errors, but still System.Linq.Expressions namespace is missing.
The document says System.Linq.Expressions is in System.Core.dll but it seems my System.Core.dll (located in Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE) contains much less namespace than document says.
Thanks in advance!
The Compact Framework does not support LINQ to SQL. All objects in the documentation for System.Data.Linq confirms this by being completely devoid of the "supported in the CF" icon. For example, look over at the docs for DataTable, which is supported. You'll see a little icon by each supported method/property.
You cannot "add" support by simply referencing a desktop assembly like you did in your step 5. The CF cannot consume full framework assemblies, for a variety of reasons.
Dynamic code generation (Reflection.Emit) is not available in NETCF. What this means is that a lot of features that depend on this is not available, this includes DLR (dyanmic language runtime and hence languages like IronRuby), Linq-to-SQL/
If you just want the Linq.Expressions and you are doing your own stuff with it i.e. not trying to get linq to sql working then you can use the System.Linq.Expression stuff from the db4o guys.
I am using it on my project using linq to objects.
db4o linq implementation