Search Results

Search found 1402 results on 57 pages for 'linking'.

Page 21/57 | < Previous Page | 17 18 19 20 21 22 23 24 25 26 27 28  | Next Page >

  • Confused about using SpringMVC Vs JEE project in Netbeans

    - by Sanju
    Hi all, I want to start a my first JEE project. I have read a lot that springMVC framework is a good choice (never used though) My earlier experience with java is not much. only some small app development using Netbeans. so I have some experience using Netbeans. but I see that I can start a JEE project in Netbeans. so what kind of framework netbeans is using underneath. PS: My understanding of framework (e.g. SpringMVC) is that you follow rule of framework to configure your app. and then framework take care or linking your View, controller and model. so if i am using netbeans, do i need to take care of linking of my MVC by myself?

    Read the article

  • Kohana 3 ORM limitations

    - by yoda
    Hi, What are the limitations of Kohana 3 ORM regarding table relationships? I'm trying to modify the build-in Auth module in order to accept groups of users in adition, having now the following tables : groups groups_users roles roles_groups users user_tokens By default, this module is set to work without groups, and linking the users and roles using a third table named roles_users, but I need to add groups to it. I'm linking, as you can see by the names, the groups to users and the roles to groups, but I'm failing building the ORM code for it, so that's pretty much the question here, if ORM is limited to 2 relationships or if it can handle 3 in this case. Cheers!

    Read the article

  • How do I customize what a third party MSM does?

    - by sqlrob
    I'm trying to convert a project in Visual Studio 2008 from static linking of the CRT to dynamic linking. This was easy enough, and I added the CRT MSM and policy MSM to my Wix file with no problems. I am not that happy with the MSI that is output though, it is much larger than what I expected. Looking at the MSI with Orca shows three copies of the CRT DLLs that I need. From looking at the conditions, one of the sets is used for pre-XP installs. Since the system requirements are XP and later, how do I remove this component without touching the original MSM? This needs to be done in an automated build, so Orca isn't a possible solution. Plus, when I tried it with Orca, the filesize remained the same after deleting the File and Component rows. And somewhat related, how do I set the permanent attribute in the components that remain?

    Read the article

  • iOS app won't compile on device but works fine in simulator

    - by Jhorra
    I'm assuming this has something to do with linking, but I've removed RestKit and re-added it. I made sure all my connections and linking was in place. If I set XCode to use the simulator it runs fine, but as soon as I set it to run on any device it won't even build. The only other thing of note is this didn't start happening till I upgraded to XCode 4.5. Below are the errors it gives me ld: warning: ignoring file /Users/luke/Library/Developer/Xcode/DerivedData/ehrx-btsujlxuhtytahfaikwjeqfjybtt/Build/Products/Debug-iphoneos/libRestKit.a, file was built for archive which is not the architecture being linked (armv7s): /Users/luke/Library/Developer/Xcode/DerivedData/ehrx-btsujlxuhtytahfaikwjeqfjybtt/Build/Products/Debug-iphoneos/libRestKit.a Undefined symbols for architecture armv7s: "_OBJC_CLASS_$_RKClient", referenced from: objc-class-ref in ehrxAppDelegate.o objc-class-ref in ehrxLoginView.o objc-class-ref in ehrxInboxView.o objc-class-ref in ehrxCMView.o objc-class-ref in ehrxEncounterDemoView.o objc-class-ref in ehrxEncounterDiagListView.o objc-class-ref in ehrxEncounterChargeView.o ... ld: symbol(s) not found for architecture armv7s clang: error: linker command failed with exit code 1 (use -v to see invocation)

    Read the article

  • libriaries on Android

    - by Will
    In native development, you can produce libraries - .so, .dll etc - that other libraries and programs can share. In Java, you can put your code in a JAR in the classpath and other programs and libraries can use it. So how can you do modular programs in Android? I get the impression from the documentation that each APK is a self-contained island. Can different APKs share code? And how does installation work when you have these external dependencies? Can you specify that you rely on library that is not in your APK and get it installed too? If you can't have 'dynamic linking', can you have 'static linking' by developing your shared code and somehow putting the equiv of a JAR into each APK that requires it?

    Read the article

  • Creating a project, from Makefile to static/dynamic libraries in UNIX

    - by Sasha
    Guys, would you describe a few things about c++ building blocks, on unix. I want to create an application that links against static libs and dynamic libs (.so). Question 1: How do I create static library using gcc/g++ ?How do I make my app link against it. Question 2: How to specify it in the makefile, linking against static and dynamic libs, assuming that both libraries have header files Summary: I have been using makefiles and libraries for years, written by someone else. Thus every time I modified it, I simply cut-and-pasted things around, without really understanding it. Now I want to get down to the ground and understand the building/linking/Creating Makfile process in-depth. What is a good book describing these concepts in intimate details? Thanks

    Read the article

  • static library vs dynamic libraries

    - by user295030
    Can someone please explain in easy terms what is static library linking vs dynamic library linking other one has a larger memory map than the other or that the static library is used to compile/link with the program that will use it versus being loaded at runtime? I also need to create a static library of a program that I made in vs2008 and give one function interface to access the library. one of the requirements reads as such " * API should be in the form of static library. company xxx will link the library into a third party application to prevent any possible exposure of the code(dll)" how can they say both static and dll at the same time. I have never works with static library before. So please any help would be nice.

    Read the article

  • gcc architecture question

    - by Andy
    Hi, I'm compiling my program with architecture set to -mtune=i386 However, I'm also linking statically against several libs (libpng, zlib, jpeglib, vorbisfile, libogg). I've built these libs on my own using configure and make, so I guess these libs were built with architecture being set to my system's architecture which would be i686. But I don't want that! I want my program to run on i386, too, so I need to make sure that all these libs that I'm statically linking against are built for i386, too. So my question: Is there a convenient way to build libpng/zlib/jpeglib/vorbisfile/libogg etc. for i386 or do I have to modify all of their makefiles manually and make sure that -mtune is set to i386? Thanks for help! Andy

    Read the article

  • GCC: visibility of symbols in standalone C++ applications

    - by Albert
    Hi, Because of a strange C++ warning about the visibility of some symbols and an interesting answer, linking to a paper which describes the different visibility types and cases (section 2.2.4 is about C++ classes), I started to wonder if it is needed for a standalone application to export symbols at all (except main - or is that needed?). Why exactly are they needed to be exported in standalone applications? Is "an exported symbol" an synomym for "visible symbol"? I.e. a hidden symbol is a symbol which is not exported? Do the object files already differ between visible symbols and hidden symbols? Or is this made at the linking step, so that only the visible symbols are exported? Does the visibility of symbols matter in case for debug information? Or is that completely independent, i.e. I would also get a nice backtrace if I have all symbols hidden? How is STABS/DWARF related to the visibility of symbols?

    Read the article

  • How to tell the MinGW linker not to export all symbols?

    - by James R.
    Hello, I'm building a Windows dynamic library using the MinGW toolchain. To build this library I'm statically linking to other 2 which offer an API and I have a .def file where I wrote the only symbol I want to be exported in my library. The problem is that GCC is exporting all of the symbols including the ones from the libraries I'm linking to. Is there anyway to tell the linker just to export the symbols in the def file? I know there is the option --export-all-symbols but there seems not to be the opposite to it. Right now the last line of the build script has this structure: g++ -shared CXXFLAGS DEFINES INCLUDES -o library.dll library.cpp DEF_FILE \ OBJECT_FILES LIBS -Wl,--enable-stdcall-fixup EDIT: In the docs about the linker it says that --export-all-symbols is the default behavior and that it's disabled when you don't use that option explicitly if you provide a def file, except when it doesn't; the symbols in 3rd party libs are being exported anyway. EDIT: Adding the option --exclude-libs LIBS doesn't keep their symbols from being exported either.

    Read the article

  • Why is it so hard to share resource files (resx) with my Silverlight client?

    - by Jordan
    I'm trying to share a resource file (.resx file) from my web (RIA Service?Silverlight Host) to client (Silverlight) by linking the resource file into my client. When I try to access resources using the ResourceManager object I get the following error: System.Resources.MissingManifestResourceException was caught Message=Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "PPCa.Modules.ProjectManager.Client.ViewModels.ResourceStrings.resources" was correctly embedded or linked into assembly "PPCa.Modules.ProjectManager.Client" at compile time, or that all the satellite assemblies required are loadable and fully signed. StackTrace: at System.Resources.ManifestBasedResourceGroveler.HandleResourceStreamMissing(String fileName) at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark) at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark) at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents) at System.Resources.ResourceManager.GetString(String name, CultureInfo culture) at System.Resources.ResourceManager.GetString(String name) at PPCa.Modules.ProjectManager.Web.Helpers.ResourceHelper.GetEnumText[TResource](ProjectStatus a_projectStatus) InnerException: Edit: When I say I was linking the resource file, I mean I am using the 'Add as Link' option when adding the existing resx file to my project.

    Read the article

  • CakePHP hasOne ineffeciency?

    - by Andre
    I was looking at examples on the CakePHP website, in particular hasOne used in linking models. http://book.cakephp.org/view/78/Associations-Linking-Models-Together My question is this, is CakePHP using two queries to build the array structure of data returned in a model that uses hasOne linkage? Taken from CakePHP: //Sample results from a $this-User-find() call. Array ( [User] => Array ( [id] => 121 [name] => Gwoo the Kungwoo [created] => 2007-05-01 10:31:01 ) [Profile] => Array ( [id] => 12 [user_id] => 121 [skill] => Baking Cakes [created] => 2007-05-01 10:31:01 ) ) Hope this all makes sense.

    Read the article

  • How can I resolve naming conflict in given precompiled libraries?

    - by asm
    I'm linking two different libraries that have functions with exactly same name (it's opengl32.lib and libgles_cm.lib - OpenGL ES emulation under Win32 platform), and I want to be able to specify, which version I'm calling. I'm porting a game to OpenGL ES, and what I want to achieve, is a split-screen rendering, where left side is an OpenGL version, and right side is a ES version. To produce the same result, they will recieve slightly different calls, and I'll be able to visually compare them, effectively finding visual artifacts. It worked perfectly with OpenGL/DirectX at the same window, but now the problem is that both versions imports the functions with the same name, like glDrawArrays, and only one version is imported. Unfortunately, I don't have sources of any of that libraries. Is there a way to... I dont' know, wrap one library into additional namespace before linking (with calls like ES::glDrawArrays), somehow rename some of functions or do anything else? I'm using microsoft compiler now, but if there will be solution with another one (GCC/ICC), I'll switch to it.

    Read the article

  • In SQL, a Join is actually an Intersection? And it is also a linkage or a "Sideway Union"?

    - by Jian Lin
    I always thought of a Join in SQL as some kind of linkage between two tables. For example, select e.name, d.name from employees e, departments d where employees.deptID = departments.deptID In this case, it is linking two tables, to show each employee with a department name instead of a department ID. And kind of like a "linkage" or "Union" sideway". But, after learning about inner join vs outer join, it shows that a Join (Inner join) is actually an intersection. For example, when one table has the ID 1, 2, 7, 8, while another table has the ID 7 and 8 only, the way we get the intersection is: select * from t1, t2 where t1.ID = t2.ID to get the two records of "7 and 8". So it is actually an intersection. So we have the "Intersection" of 2 tables. Compare this with the "Union" operation on 2 tables. Can a Join be thought of as an "Intersection"? But what about the "linking" or "sideway union" aspect of it?

    Read the article

  • Hyperlinked, externalized source code documentation

    - by Dave Jarvis
    Why do we still embed natural language descriptions of source code (i.e., the reason why a line of code was written) within the source code, rather than as a separate document? Given the expansive real-estate afforded to modern development environments (high-resolution monitors, dual-monitors, etc.), an IDE could provide semi-lock-step panels wherein source code is visually separated from -- but intrinsically linked to -- its corresponding comments. For example, developers could write source code comments in a hyper-linked markup language (linking to additional software requirements), which would simultaneously prevent documentation from cluttering the source code. What shortcomings would inhibit such a software development mechanism? A mock-up to help clarify the question: When the cursor is at a particular line in the source code (shown with a blue background, above), the documentation that corresponds to the line at the cursor is highlighted (i.e., distinguished from the other details). As noted in the question, the documentation would stay in lock-step with the source code as the cursor jumps through the source code. A hot-key could switch between "documentation mode" and "development mode". Potential advantages include: More source code and more documentation on the screen(s) at once Ability to edit documentation independently of source code (regardless of language?) Write documentation and source code in parallel without merge conflicts Real-time hyperlinked documentation with superior text formatting Quasi-real-time machine translation into different natural languages Every line of code can be clearly linked to a task, business requirement, etc. Documentation could automatically timestamp when each line of code was written (metrics) Dynamic inclusion of architecture diagrams, images to explain relations, etc. Single-source documentation (e.g., tag code snippets for user manual inclusion). Note: The documentation window can be collapsed Workflow for viewing or comparing source files would not be affected How the implementation happens is a detail; the documentation could be: kept at the end of the source file; split into two files by convention (filename.c, filename.c.doc); or fully database-driven By hyperlinked documentation, I mean linking to external sources (such as StackOverflow or Wikipedia) and internal documents (i.e., a wiki on a subdomain that could cross-reference business requirements documentation) and other source files (similar to JavaDocs). Related thread: What's with the aversion to documentation in the industry?

    Read the article

  • Link To Work Item &ndash; Visual Studio extension to link changeset(s) to work item directly from VS history window

    - by Utkarsh Shigihalli
    Originally posted on: http://geekswithblogs.net/onlyutkarsh/archive/2014/08/11/link-to-work-item-ndash-visual-studio-extension-to-link.aspxBy linking work items and other objects, you can track related work, dependencies, and changes made over time. As the following illustration shows, specific link types are used to track specific work items and actions. (– via MSDN) While making a check-in, Visual Studio 2013 provides you a quick way to search and assign a work item via pending changes section in Team Explorer. However, if you forget to assign the work item during your check-in, things really get cumbersome as Visual Studio does not provide an easy way of assigning. For example, you usually have to open the work item and then link the changeset which involves approx. 7-8 mouse clicks. Now, you will really feel the difficulty if you have to assign work item to multiple changesets, you have to repeat the same steps again. Hence, I decided to develop a small Visual Studio extension to perform this action of linking work item to changeset bit easier. How to use the extension? First, download and install the extension from VS Gallery (Supports VS 2013 Professional and above). Once you install, you will see a new "Link To Work Item" menu item when you right click on a changeset in history window. Clicking Link To Work Item menu, will open a new dialog with which you can search for a work item. As you can see in below screenshot, this dialog displays the search result and also the type of the work item. You can also open work item from this dialog by right clicking on the work item and clicking 'Open'. Finally, clicking Save button, will actually link the work item to changeset. One feature which I think helpful, is you can select multiple changesets from history window and assign the work item to all those changesets.  To summarize the features Directly assign work items to changesets from history window Assign work item to multiple changesets Know the type of the work item before assigning. Open the work item from search results It also supports all default Visual Studio themes. Below is a small demo showcasing the working of this extension. Finally, if you like the extension, do not forget to rate and review the extension in VS Gallery. Also, do not hesitate to provide your suggestions, improvements and any issues you may encounter via github.

    Read the article

  • Daily tech links for .net and related technologies - May 10-12, 2010

    - by SanjeevAgarwal
    Daily tech links for .net and related technologies - May 10-12, 2010 Web Development jQuery Templates and Data Linking (and Microsoft contributing to jQuery) - ScottGu ASP.NET MVC and jQuery Part 4 – Advanced Model Binding - Mister James Creating an ASP.NET report using Visual Studio 2010 - Part 1 & Part 2 & Part 3 - rajbk Caching Images in ASP.NET MVC -Evan How to Localize an ASP.NET MVC Application - mikeceranski Localization in ASP.NET MVC 2 using ModelMetadata - Raj Kiamal Web Design...(read more)

    Read the article

  • Much Ado About Nothing: Stub Objects

    - by user9154181
    The Solaris 11 link-editor (ld) contains support for a new type of object that we call a stub object. A stub object is a shared object, built entirely from mapfiles, that supplies the same linking interface as the real object, while containing no code or data. Stub objects cannot be executed — the runtime linker will kill any process that attempts to load one. However, you can link to a stub object as a dependency, allowing the stub to act as a proxy for the real version of the object. You may well wonder if there is a point to producing an object that contains nothing but linking interface. As it turns out, stub objects are very useful for building large bodies of code such as Solaris. In the last year, we've had considerable success in applying them to one of our oldest and thorniest build problems. In this discussion, I will describe how we came to invent these objects, and how we apply them to building Solaris. This posting explains where the idea for stub objects came from, and details our long and twisty journey from hallway idea to standard link-editor feature. I expect that these details are mainly of interest to those who work on Solaris and its makefiles, those who have done so in the past, and those who work with other similar bodies of code. A subsequent posting will omit the history and background details, and instead discuss how to build and use stub objects. If you are mainly interested in what stub objects are, and don't care about the underlying software war stories, I encourage you to skip ahead. The Long Road To Stubs This all started for me with an email discussion in May of 2008, regarding a change request that was filed in 2002, entitled: 4631488 lib/Makefile is too patient: .WAITs should be reduced This CR encapsulates a number of cronic issues with Solaris builds: We build Solaris with a parallel make (dmake) that tries to build as much of the code base in parallel as possible. There is a lot of code to build, and we've long made use of parallelized builds to get the job done quicker. This is even more important in today's world of massively multicore hardware. Solaris contains a large number of executables and shared objects. Executables depend on shared objects, and shared objects can depend on each other. Before you can build an object, you need to ensure that the objects it needs have been built. This implies a need for serialization, which is in direct opposition to the desire to build everying in parallel. To accurately build objects in the right order requires an accurate set of make rules defining the things that depend on each other. This sounds simple, but the reality is quite complex. In practice, having programmers explicitly specify these dependencies is a losing strategy: It's really hard to get right. It's really easy to get it wrong and never know it because things build anyway. Even if you get it right, it won't stay that way, because dependencies between objects can change over time, and make cannot help you detect such drifing. You won't know that you got it wrong until the builds break. That can be a long time after the change that triggered the breakage happened, making it hard to connect the cause and the effect. Usually this happens just before a release, when the pressure is on, its hard to think calmly, and there is no time for deep fixes. As a poor compromise, the libraries in core Solaris were built using a set of grossly incomplete hand written rules, supplemented with a number of dmake .WAIT directives used to group the libraries into sets of non-interacting groups that can be built in parallel because we think they don't depend on each other. From time to time, someone will suggest that we could analyze the built objects themselves to determine their dependencies and then generate make rules based on those relationships. This is possible, but but there are complications that limit the usefulness of that approach: To analyze an object, you have to build it first. This is a classic chicken and egg scenario. You could analyze the results of a previous build, but then you're not necessarily going to get accurate rules for the current code. It should be possible to build the code without having a built workspace available. The analysis will take time, and remember that we're constantly trying to make builds faster, not slower. By definition, such an approach will always be approximate, and therefore only incremantally more accurate than the hand written rules described above. The hand written rules are fast and cheap, while this idea is slow and complex, so we stayed with the hand written approach. Solaris was built that way, essentially forever, because these are genuinely difficult problems that had no easy answer. The makefiles were full of build races in which the right outcomes happened reliably for years until a new machine or a change in build server workload upset the accidental balance of things. After figuring out what had happened, you'd mutter "How did that ever work?", add another incomplete and soon to be inaccurate make dependency rule to the system, and move on. This was not a satisfying solution, as we tend to be perfectionists in the Solaris group, but we didn't have a better answer. It worked well enough, approximately. And so it went for years. We needed a different approach — a new idea to cut the Gordian Knot. In that discussion from May 2008, my fellow linker-alien Rod Evans had the initial spark that lead us to a game changing series of realizations: The link-editor is used to link objects together, but it only uses the ELF metadata in the object, consisting of symbol tables, ELF versioning sections, and similar data. Notably, it does not look at, or understand, the machine code that makes an object useful at runtime. If you had an object that only contained the ELF metadata for a dependency, but not the code or data, the link-editor would find it equally useful for linking, and would never know the difference. Call it a stub object. In the core Solaris OS, we require all objects to be built with a link-editor mapfile that describes all of its publically available functions and data. Could we build a stub object using the mapfile for the real object? It ought to be very fast to build stub objects, as there are no input objects to process. Unlike the real object, stub objects would not actually require any dependencies, and so, all of the stubs for the entire system could be built in parallel. When building the real objects, one could link against the stub objects instead of the real dependencies. This means that all the real objects can be built built in parallel too, without any serialization. We could replace a system that requires perfect makefile rules with a system that requires no ordering rules whatsoever. The results would be considerably more robust. We immediately realized that this idea had potential, but also that there were many details to sort out, lots of work to do, and that perhaps it wouldn't really pan out. As is often the case, it would be necessary to do the work and see how it turned out. Following that conversation, I set about trying to build a stub object. We determined that a faithful stub has to do the following: Present the same set of global symbols, with the same ELF versioning, as the real object. Functions are simple — it suffices to have a symbol of the right type, possibly, but not necessarily, referencing a null function in its text segment. Copy relocations make data more complicated to stub. The possibility of a copy relocation means that when you create a stub, the data symbols must have the actual size of the real data. Any error in this will go uncaught at link time, and will cause tragic failures at runtime that are very hard to diagnose. For reasons too obscure to go into here, involving tentative symbols, it is also important that the data reside in bss, or not, matching its placement in the real object. If the real object has more than one symbol pointing at the same data item, we call these aliased symbols. All data symbols in the stub object must exhibit the same aliasing as the real object. We imagined the stub library feature working as follows: A command line option to ld tells it to produce a stub rather than a real object. In this mode, only mapfiles are examined, and any object or shared libraries on the command line are are ignored. The extra information needed (function or data, size, and bss details) would be added to the mapfile. When building the real object instead of the stub, the extra information for building stubs would be validated against the resulting object to ensure that they match. In exploring these ideas, I immediately run headfirst into the reality of the original mapfile syntax, a subject that I would later write about as The Problem(s) With Solaris SVR4 Link-Editor Mapfiles. The idea of extending that poor language was a non-starter. Until a better mapfile syntax became available, which seemed unlikely in 2008, the solution could not involve extentions to the mapfile syntax. Instead, we cooked up the idea (hack) of augmenting mapfiles with stylized comments that would carry the necessary information. A typical definition might look like: # DATA(i386) __iob 0x3c0 # DATA(amd64,sparcv9) __iob 0xa00 # DATA(sparc) __iob 0x140 iob; A further problem then became clear: If we can't extend the mapfile syntax, then there's no good way to extend ld with an option to produce stub objects, and to validate them against the real objects. The idea of having ld read comments in a mapfile and parse them for content is an unacceptable hack. The entire point of comments is that they are strictly for the human reader, and explicitly ignored by the tool. Taking all of these speed bumps into account, I made a new plan: A perl script reads the mapfiles, generates some small C glue code to produce empty functions and data definitions, compiles and links the stub object from the generated glue code, and then deletes the generated glue code. Another perl script used after both objects have been built, to compare the real and stub objects, using data from elfdump, and validate that they present the same linking interface. By June 2008, I had written the above, and generated a stub object for libc. It was a useful prototype process to go through, and it allowed me to explore the ideas at a deep level. Ultimately though, the result was unsatisfactory as a basis for real product. There were so many issues: The use of stylized comments were fine for a prototype, but not close to professional enough for shipping product. The idea of having to document and support it was a large concern. The ideal solution for stub objects really does involve having the link-editor accept the same arguments used to build the real object, augmented with a single extra command line option. Any other solution, such as our prototype script, will require makefiles to be modified in deeper ways to support building stubs, and so, will raise barriers to converting existing code. A validation script that rederives what the linker knew when it built an object will always be at a disadvantage relative to the actual linker that did the work. A stub object should be identifyable as such. In the prototype, there was no tag or other metadata that would let you know that they weren't real objects. Being able to identify a stub object in this way means that the file command can tell you what it is, and that the runtime linker can refuse to try and run a program that loads one. At that point, we needed to apply this prototype to building Solaris. As you might imagine, the task of modifying all the makefiles in the core Solaris code base in order to do this is a massive task, and not something you'd enter into lightly. The quality of the prototype just wasn't good enough to justify that sort of time commitment, so I tabled the project, putting it on my list of long term things to think about, and moved on to other work. It would sit there for a couple of years. Semi-coincidentally, one of the projects I tacked after that was to create a new mapfile syntax for the Solaris link-editor. We had wanted to do something about the old mapfile syntax for many years. Others before me had done some paper designs, and a great deal of thought had already gone into the features it should, and should not have, but for various reasons things had never moved beyond the idea stage. When I joined Sun in late 2005, I got involved in reviewing those things and thinking about the problem. Now in 2008, fresh from relearning for the Nth time why the old mapfile syntax was a huge impediment to linker progress, it seemed like the right time to tackle the mapfile issue. Paving the way for proper stub object support was not the driving force behind that effort, but I certainly had them in mind as I moved forward. The new mapfile syntax, which we call version 2, integrated into Nevada build snv_135 in in February 2010: 6916788 ld version 2 mapfile syntax PSARC/2009/688 Human readable and extensible ld mapfile syntax In order to prove that the new mapfile syntax was adequate for general purpose use, I had also done an overhaul of the ON consolidation to convert all mapfiles to use the new syntax, and put checks in place that would ensure that no use of the old syntax would creep back in. That work went back into snv_144 in June 2010: 6916796 OSnet mapfiles should use version 2 link-editor syntax That was a big putback, modifying 517 files, adding 18 new files, and removing 110 old ones. I would have done this putback anyway, as the work was already done, and the benefits of human readable syntax are obvious. However, among the justifications listed in CR 6916796 was this We anticipate adding additional features to the new mapfile language that will be applicable to ON, and which will require all sharable object mapfiles to use the new syntax. I never explained what those additional features were, and no one asked. It was premature to say so, but this was a reference to stub objects. By that point, I had already put together a working prototype link-editor with the necessary support for stub objects. I was pleased to find that building stubs was indeed very fast. On my desktop system (Ultra 24), an amd64 stub for libc can can be built in a fraction of a second: % ptime ld -64 -z stub -o stubs/libc.so.1 -G -hlibc.so.1 \ -ztext -zdefs -Bdirect ... real 0.019708910 user 0.010101680 sys 0.008528431 In order to go from prototype to integrated link-editor feature, I knew that I would need to prove that stub objects were valuable. And to do that, I knew that I'd have to switch the Solaris ON consolidation to use stub objects and evaluate the outcome. And in order to do that experiment, ON would first need to be converted to version 2 mapfiles. Sub-mission accomplished. Normally when you design a new feature, you can devise reasonably small tests to show it works, and then deploy it incrementally, letting it prove its value as it goes. The entire point of stub objects however was to demonstrate that they could be successfully applied to an extremely large and complex code base, and specifically to solve the Solaris build issues detailed above. There was no way to finesse the matter — in order to move ahead, I would have to successfully use stub objects to build the entire ON consolidation and demonstrate their value. In software, the need to boil the ocean can often be a warning sign that things are trending in the wrong direction. Conversely, sometimes progress demands that you build something large and new all at once. A big win, or a big loss — sometimes all you can do is try it and see what happens. And so, I spent some time staring at ON makefiles trying to get a handle on how things work, and how they'd have to change. It's a big and messy world, full of complex interactions, unspecified dependencies, special cases, and knowledge of arcane makefile features... ...and so, I backed away, put it down for a few months and did other work... ...until the fall, when I felt like it was time to stop thinking and pondering (some would say stalling) and get on with it. Without stubs, the following gives a simplified high level view of how Solaris is built: An initially empty directory known as the proto, and referenced via the ROOT makefile macro is established to receive the files that make up the Solaris distribution. A top level setup rule creates the proto area, and performs operations needed to initialize the workspace so that the main build operations can be launched, such as copying needed header files into the proto area. Parallel builds are launched to build the kernel (usr/src/uts), libraries (usr/src/lib), and commands. The install makefile target builds each item and delivers a copy to the proto area. All libraries and executables link against the objects previously installed in the proto, implying the need to synchronize the order in which things are built. Subsequent passes run lint, and do packaging. Given this structure, the additions to use stub objects are: A new second proto area is established, known as the stub proto and referenced via the STUBROOT makefile macro. The stub proto has the same structure as the real proto, but is used to hold stub objects. All files in the real proto are delivered as part of the Solaris product. In contrast, the stub proto is used to build the product, and then thrown away. A new target is added to library Makefiles called stub. This rule builds the stub objects. The ld command is designed so that you can build a stub object using the same ld command line you'd use to build the real object, with the addition of a single -z stub option. This means that the makefile rules for building the stub objects are very similar to those used to build the real objects, and many existing makefile definitions can be shared between them. A new target is added to the Makefiles called stubinstall which delivers the stub objects built by the stub rule into the stub proto. These rules reuse much of existing plumbing used by the existing install rule. The setup rule runs stubinstall over the entire lib subtree as part of its initialization. All libraries and executables link against the objects in the stub proto rather than the main proto, and can therefore be built in parallel without any synchronization. There was no small way to try this that would yield meaningful results. I would have to take a leap of faith and edit approximately 1850 makefiles and 300 mapfiles first, trusting that it would all work out. Once the editing was done, I'd type make and see what happened. This took about 6 weeks to do, and there were many dark days when I'd question the entire project, or struggle to understand some of the many twisted and complex situations I'd uncover in the makefiles. I even found a couple of new issues that required changes to the new stub object related code I'd added to ld. With a substantial amount of encouragement and help from some key people in the Solaris group, I eventually got the editing done and stub objects for the entire workspace built. I found that my desktop system could build all the stub objects in the workspace in roughly a minute. This was great news, as it meant that use of the feature is effectively free — no one was likely to notice or care about the cost of building them. After another week of typing make, fixing whatever failed, and doing it again, I succeeded in getting a complete build! The next step was to remove all of the make rules and .WAIT statements dedicated to controlling the order in which libraries under usr/src/lib are built. This came together pretty quickly, and after a few more speed bumps, I had a workspace that built cleanly and looked like something you might actually be able to integrate someday. This was a significant milestone, but there was still much left to do. I turned to doing full nightly builds. Every type of build (open, closed, OpenSolaris, export, domestic) had to be tried. Each type failed in a new and unique way, requiring some thinking and rework. As things came together, I became aware of things that could have been done better, simpler, or cleaner, and those things also required some rethinking, the seeking of wisdom from others, and some rework. After another couple of weeks, it was in close to final form. My focus turned towards the end game and integration. This was a huge workspace, and needed to go back soon, before changes in the gate would made merging increasingly difficult. At this point, I knew that the stub objects had greatly simplified the makefile logic and uncovered a number of race conditions, some of which had been there for years. I assumed that the builds were faster too, so I did some builds intended to quantify the speedup in build time that resulted from this approach. It had never occurred to me that there might not be one. And so, I was very surprised to find that the wall clock build times for a stock ON workspace were essentially identical to the times for my stub library enabled version! This is why it is important to always measure, and not just to assume. One can tell from first principles, based on all those removed dependency rules in the library makefile, that the stub object version of ON gives dmake considerably more opportunities to overlap library construction. Some hypothesis were proposed, and shot down: Could we have disabled dmakes parallel feature? No, a quick check showed things being build in parallel. It was suggested that we might be I/O bound, and so, the threads would be mostly idle. That's a plausible explanation, but system stats didn't really support it. Plus, the timing between the stub and non-stub cases were just too suspiciously identical. Are our machines already handling as much parallelism as they are capable of, and unable to exploit these additional opportunities? Once again, we didn't see the evidence to back this up. Eventually, a more plausible and obvious reason emerged: We build the libraries and commands (usr/src/lib, usr/src/cmd) in parallel with the kernel (usr/src/uts). The kernel is the long leg in that race, and so, wall clock measurements of build time are essentially showing how long it takes to build uts. Although it would have been nice to post a huge speedup immediately, we can take solace in knowing that stub objects simplify the makefiles and reduce the possibility of race conditions. The next step in reducing build time should be to find ways to reduce or overlap the uts part of the builds. When that leg of the build becomes shorter, then the increased parallelism in the libs and commands will pay additional dividends. Until then, we'll just have to settle for simpler and more robust. And so, I integrated the link-editor support for creating stub objects into snv_153 (November 2010) with 6993877 ld should produce stub objects PSARC/2010/397 ELF Stub Objects followed by the work to convert the ON consolidation in snv_161 (February 2011) with 7009826 OSnet should use stub objects 4631488 lib/Makefile is too patient: .WAITs should be reduced This was a huge putback, with 2108 modified files, 8 new files, and 2 removed files. Due to the size, I was allowed a window after snv_160 closed in which to do the putback. It went pretty smoothly for something this big, a few more preexisting race conditions would be discovered and addressed over the next few weeks, and things have been quiet since then. Conclusions and Looking Forward Solaris has been built with stub objects since February. The fact that developers no longer specify the order in which libraries are built has been a big success, and we've eliminated an entire class of build error. That's not to say that there are no build races left in the ON makefiles, but we've taken a substantial bite out of the problem while generally simplifying and improving things. The introduction of a stub proto area has also opened some interesting new possibilities for other build improvements. As this article has become quite long, and as those uses do not involve stub objects, I will defer that discussion to a future article.

    Read the article

  • Overview of getting and setting the URL and parts of the URL using angularjs and/or Javascript

    - by Sandy Good
    Getting and Setting the URL, and different parts of the URL are a basic part of Application Design. For Page Navigation Deep Linking Providing a link to the user Querying Data Passing information to other pages Both angularjs and javascript provide ways to get/set the URL and parts of the URL. I'm looking for the following information: Situation: Show a simple URL in the browser address bar to the user Provide a more detailed URL with string parameters to the page that the user will not see. In other words, two different URLs will be used, one simple one that the user sees in the browser, a more detailed one available to the page on load. Get URL info with PHP when then page intially loads, both don't reload the PHP page when the user needs more detailed info that is already loaded but not displayed yet. Set the URL with a more detailed URL for deep linking as the user drills down to more specific information. Get URL info in a controller or JavaSript when angularjs detects a change in the URL with routing. Hash or Query String or Both? Should I use a hash # in the URL, a string ?= or both? Here is what I currently know and what I want: A Query String HTTP:\\www.name.com?mykey=itemID will prevent angularjs from reloading the page. So, I can change the URL by adding/changing the string at the end, thereby providing new info to the page, and keep the page from reloading. I can change the URL and force a page reload with: window.location.href = "#Store/" + argUserPubId + "?itemID=home"; If home is the itemID string, I want code to simply load the page, and not display more detailed information. If there is a real itemID in the URL query string, I want the code to display the more detailed information. Code from angularjs will run either from the controller specified in the routing, or a controller specified in the HTML, or both. The angularjs code specified in the routing seems to run first, before the code specified in the HTML. A different URL for the page can be used in angularjs templateURL: than the URL that was sent to the browser address bar. when('/Store/:StoreId', { templateUrl: function(params){return 'Client_Pages/Stores.php?storeID=' + params.StoreId;}, controller: 'storeParseData' }). The above code detects http:\\www.name.com\Store\StoreID in the browser, but SENDS http:\\www.name.com\Client_Pages/Stores.php?storeID=StoreID to the page. In the above code, a function is used for the angularjs routing templateURL: to dynamically set the templateURL. So, when the user clicks something to see details of an item, how should I configure the URL? Should I use angularjs $location or window.location.href ? Should I use a longer URL with more parameters, a hash bang, or a query string? Should I use: http:\\www.name.com\Store\StoreID\ItemID or http:\\www.name.com\Store\StoreID#ItemID or http:\\www.name.com\Store\StoreID?ItemID or http:\\www.name.com\Store#StoreID?ItemID or Something else?

    Read the article

  • Google indexing wrong domain that does not work

    - by user174117
    Can anyone tell me why Google indexes a site http://0.3c.7aae.static.theplanet.com instead of the actual domain name (my domain was registered with webmaster tools). The aforementioned link was linking to my site, but has now become a broken link. Initially I tried 301 directs, but nothing worked. The hosting company cannot explain why. Leaving me wondering what to do? Any guidance would be appreciated. Thks

    Read the article

  • DNS lookup when using a CDN

    - by Steven Wu
    Using a CDN can vastly improve the load time of a website. I been thinking of using it to host all my external files like CSS, JS, Images, Videos etc. However I was thinking when linking to a CDN, wouldn't the browser have to use additional DNS lookup? So wouldn't this be counter productive? Or is the benefit to host every external files on a CDN out weighs the additional cost of a DNS lookup? What are your thoughts?

    Read the article

< Previous Page | 17 18 19 20 21 22 23 24 25 26 27 28  | Next Page >