On the netbeans that I am using, I cannot do a basic thing such hovering the mouse over a variable and getting its type as shown in the below picture.
How can I obtain this behaviour?
On my system there is windows XP, Netbeans 6.1 and my application is a Vega7000 Application
Why are you using such an old version? It may well be a bug or simply a missing feature.
So answer is, upgrade!
https://netbeans.org/downloads/
If you need the old version for release builds, you can perhaps still do the actual development and debugging using a newer and shinier version.
Also, if you are not using one yet, use source control! I prefer git, but this is very subjective, other DVCS are good too. And note that so called distributed VCS works extremely well locally inside one source tree directory, it does not have to be distributed to many places. When working with old fragile complex code you are afraid of breaking, very frequent local commits, and diffing to known-good versions when problems arise are life savers. If you care about publishing work in progress, at least git (presumably all DVCS) allow squashing multiple commits into one before pushing to non-personal repo or branch.
Related
The command "Pkg.add("ConditionalJuMP)" works.
However when, I am trying the command (using ConditionalJuMP), I am getting this error. Anyone can propose me something?
Have you taken a look at ConditionalJuMP's GitHub repo? The latest release (0.1.0) has been for Julia 1.0, and thus seems pretty outdated by now with not much work going on...
Diff master w.r.t. 0.1.0 release: here
Telling from your screenshot, Julia tried to precompile ConditionalJuMP into ./julia/compiled/v1.5. So I guess you are using Julia 1.5, right?
First thing I'd do is trying to go back to Julia 1.0 and see whether ConditionalJuMP would be working with it (or if that woudlnd't suffice on its own by actively chossing earlier JuMP versions as explicit packages within your project), since overall it seems like GenericRangeConstraint is missing/not found - which was part of earlier JuMP versions, but probably isn't anymore (not a JuMP expert here, though).
ConditionalJuMP doesn't support the latest version of JuMP. You will need to install an old version via: ] add JuMP#0.18.
I would encourage you to instead use the latest version of JuMP, and its native support for indicator constraints: https://jump.dev/JuMP.jl/stable/constraints/#Indicator-constraints-1
I have a software compiled and running on centos 5, Now i am intrested in running it on Centos 6, unmodified without compilation on new machine.
Here is the challenge:-
My process requires certain lib say libcap.so.1 but centos 6 has newer version say libcap.so.2
I am able to make old software work with any of below hacks
create a symlink(libcap.so.1) to libcap.so.2
copy libcap.so.1 to new machine(centos 6)
What is recommended between two and are there any known issues with this approach, compiling on centos6 would be my last option.
Creating a sym link like that will sometimes work, depending on what exactly the changes were that led to the new version - they would have to be minimal changes that especially did not remove access to any routines/variables that the old library had or drastically change the signature of any of the routines/variables that remain. If the library uses symbol versioning (like the gcc standard C library does), it's possible the .2 version still contains the full API the previous version provided, but I don't know off the top of my head if libpcap does that...
If the new library does not encapsulate the old API, your safest bet is to recompile. If your application is not mission-critical, and/or you can deal with crashes and the possibility of corrupted data, it shouldn't hurt (much) to just try the sym link route...
I'm trying to port my project to another platform and I've found a few differences between this new platform and the one I started on. I've seen the autotools package and configure scripts which are supposed to help with that, but I was wondering how feasible it would be to just have a separate branch for each new platform.
The only problem I see is how to do development on the target platform and then merge in changes to other branches without getting the platform-dependent changes. If there is a way to do that, it seems to me it'd be much cleaner.
Has anyone done this who can recommend/discourage this approach?
I would definitely discourage that approach.
You're just asking for trouble if you keep the same code in branches that can't be merged. It's going to be incredibly confusing to keep track of what changes have been applied to what branches and a nightmare should you forget to apply a change to one of your platform branches.
You didn't mention the language, but use the features available in the language to separate code differences between platforms, but using one branch. For example, in C++, you should first use file-based separation. For example, if you have sound code for Mac, Linux and Windows platforms, create a sound_mac.cpp, sound_windows.cpp and sound_linux.cpp file, each containing the same classes and methods, but containing very different platform-specific implementations. Obviously, you only add the appropriate file to the IDE on the particular platform. So, your Xcode project gets sound_mac.cpp file, while your Visual Studio project uses the sound_windows.cpp file. The files which reference those classes and methods will use #ifdef's to determine which headers to include.
You'll use a similar approach for things like installer scripts. You may have a different installer on the Mac than on Windows, but the files for both will be in the branch. Your build script on the Mac will simply utilize the Mac-specific installer files and ignore the Windows-specific files.
Keeping things in one branch and just ignoring what doesn't apply to the current platform allows you merge back and forth between topic branches and the master, making your life much more sane.
Branching to work out compatibility for a target platform is doable. Just be sure to separate out changes that don't have to do with the target platform specifically into another branch.
I am working on a project where I've to implement Distributed File System, so for I/O operations, I was thinking of using NIO2 (JDK7)
JDK7 will be released in August next year.
My questions are:
Would it be good idea to use NIO2 from snapshot of JDK7 ? What problems can I face?
If I compile my code which uses both JDK6 and JDK7 classes is it possible to compile using JDK7 ?
1 - Would it be good idea to use NIO2 from snapshot of JDK7 ? What problems can I face?
For a student / research project I see no major issues, apart from the general ones like:
new APIs may still be in a state of flux, and may change without notice,
you are more likely to encounter JDK/JRE/JVM bugs, and
people who want to try out your project have to use JDK 7.
For a project that needs to go into production before the actual release of JDK 7, you probably should be more cautious.
2 - If I compile my code which uses both JDK6 and JDK7 classes is it possible to compile using JDK7?
You cannot be certain until you actually try it, but I'd be very surprised if the answer is anything other than "yes". The Java team are very aware of the need to maintain backwards compatibility.
(However, it is unlikely that you'll be able to compile using JDK 6 ... unless they decide that it is technically feasible and worthwhile to provide a backport of the feature for JDK 6. For something like NIO2, it could be "no" on both counts.)
I am writing a C program. What I have seen from my earlier experiences is that I make some changes on a correct version of my program, and after that change, the program is computing incorrectly.
Now, for one occasion it may be easy to detect where I made that change and undo it or do it in some other way, and for other occasions I find it hard (with labor) to detect where exactly the problem is.
Can you suggest some platform or tool which allows you to put the new version and old version of the program side by side and mark the changes that were employed on the new version.
I am using gcc 4.3.2 to compile c programs on Ubuntu 10.04 OS.
Any suggestion is welcome.
regards,
Anup
Use a version control system. I recommend Subversion. This will allow you to compare your newer version with the older one to see exactly what changed and you can revert to the older working version if you break your code.
If you want a tiny, small, portable, one-file personal control version system, I can suggest fossil. A documentation is available here.
What you are requesting is some diff-like tool. There is a plethora of such tools, ranging from the diff command line utility to GUI frontend such as http://meld.sourceforge.net/. Most of these tools can be combined with (or have counterparts in) revision control systems as Subversion.
I would do this with some version control system, like Git. Refer to Git for beginners: The definitive practical guide if you're new to version control systems and/or git.
Thats the main purpose of all the version control management software.
I recommand to look at Subversion, GIT or Mercurial.
There are thousands of internet resources for this programs.
And they all have good comparision programs integrated in their GUI Tools.
Also, try to use Git/Mercurial/whatever together with Dropbox, it will allow you to continue developing on other computers. It will also teach you how to collaborate with others and with yourself.
This is slightly easier to do with the newer VCS systems like Git and Mercurial.
If you would use a version control system, such as Git or Mercurial, and follow a few good practices:
committing small, self contained changes (which includes committing, i.e. saving changes to version control, often)
committing known good state (or at least trying to, e.g. ensuring that code compiles before you commit)
you would be always able to go back to known good state.
If bug is/was in your current changes, you can compare current state with previous version: somewhere in changed lines there is bug... or something in changed lines uncovered an existing bug.
If bug was introduced by some earlied, unknknown commit, you can use bisect to search through history to find first commit that exhibits given bug: see for example git bisect manpage.
HTH