I am interested in using the new open protocols in acoustic telemetry and wanted to know if they are comparable with older MAP versions.
The Open Protocols (OPi and OPs) are currently not compatible with older MAP versions.
As mentioned by Kim B. Some older protocols as R64K are compatible up to MAP 114.
The overview of which protocols are compatible across manufacturers can help to explain: https://www.europeantrackingnetwork.org/en/compatibility-tag-protocols
The new open protocols are compatible with older MAP versions (up to MAP114 on the R64K codeset), but NOT the newer version (MAP115) which is encrypted. To find our more, you can visit the European Tracking Network website (https://www.europeantrackingnetwork.org/en/open-protocol); they have some pretty good explanations of what codesets are compatible with each other!
There are also issues with using the older protocols that are cross-compatible with MAP114 (InnovaSea). We have used S256 tags in an array with multiple manufacturer's receivers and have tons of false detections that make the animal movements extremely challenging to resolve. The results from OPi and OPs testing suggest that this issue can be resolved with the new protocols to improve interoperability!
But both R64K and the two new OPi and OPs are all compatible on other manufacturers protocols. I suggest you look up those (Thelma, Lotek and Sonotronics).
Related
I am a student studying reverse engineering
I mainly use C and Perl, and I think this is a good choice
However, python is still being developed for ida, but idaperl says development has been discontinued (github). I have two questions.
Has idaperl development stopped?
github supports ida 6.5. Can this be used informally in 7.0?
The repo README.md says it's been discontinued,
note: I am not actively developping this plugin anymore, since i myself now mostly use idapython for scripting.
I have been looking for active forks, but there seems to be none. So your best bet might effectively to use IDAPython. It's anyone's guess whether this version supports 7.0, but you might want to downgrade to 6.5 if you effectively want to use that. There seem to be some tools that support reverse engineering in CPAN; depending on what you want to do, one of them might be useful if you're keen on using Perl.
Why is Scala binary incompatible between different releases?
It has to do with the way traits are compiled, because traits are kind of like interfaces but they can contain implementation. This makes it so it is VERY easy to make changes that don't break source compatibility but break binary compatibility, because when you add a new method to a trait along with an implementation, you have to recompile everything that implements that trait so that they will pickup that implementation. There's probably other issues, too, but I think they're mostly along the same lines.
Lack of JVM support for Scala-specific features, such as traits mentioned, and the fact that it is actively evolving.
Here's background on this, straight from Odersky, if you want to understand the specific language issues that cause problems:
http://www.scala-lang.org/node/9346
It's worth reading in conjunction with this post from David Pollack if you are new to the issue and want to understand the impact this can have on applications:
http://lift.la/scalas-version-fragility-make-the-enterprise
I've implemented support for Scala in the japi-compliance-checker 1.6 and performed analysis of backward compatibility for all versions of Scala (both binary- and source-compatibility).
So now you can view breaking changes in details. The report is available here: http://abi-laboratory.pro/java/tracker/timeline/scala/
The report is updated every other day, so you can monitor changes in the recent versions of Scala.
It's still relatively young and undergoing active development.
There are some changes in the new release that were anxiously awaited and that help with a lot of problems, but it wasn't possible to make them backward compatible.
Because Sun is kind of restrictive about updates, Java changes rather slowly, and usually tries to remain backward compatible to the bitter end. Sometimes this stands in the way of progress, but big companies love a stable language.
Scala, on the other hand, is in the hands of a small group of academics, and it's not (yet) widely used in the industry, so they have (or take) some more freedom with changes.
Umm, no. Get your facts straight.
There was no recompilation needed* when going from 2.7.2.3b1 -> 2.7.2.3b2, which was a real relief for me because of the large customer base we had with entrenched legacy code using 2.7.2.3b1 features.
*Caveat - unless you foolishly used code in scala.collection._ or scala.xml._
I am in possession of a dictionary application (takes in text as input, outputs definitions + grammar analysis). I have all the source files (about 50 pages of code), written in Ada, as well as Windows and Unix executables. I want to be able to use this dictionary in an iOS app.
I'm not at all familiar with Ada, so my question is, in a nutshell—are there any shortcuts to somehow wrap the application and use it on iOS? Or is the only way just re-writing the entire application in C/Objective-C?
Shark8 mentioned JVM-targeted Ada. ACT sells a version of Gnat that targets the JVM. However, I do not believe iOS devices currently run Java. Apple does not want to lose control of the platform, so they do not allow any development environments other than their own, which is Objective C based. I understand the Java folks are working to fix this, but even if they do Apple will probably refuse to allow any such app into their online store. Note that this is not a problem unique to Ada. Any app written in any language other than C or Objective C has the same problem with iOS. (This is one of the many reasons why developers tend to prefer to target Android platforms than iOS).
So what you really need is something that can get your code compilable with Apple's Objective C compiler. Supposedly Objective C is a strict superset of C. If this is true for Apple's implementation, then an Ada compiler that outputs compilable C sources should do the job for you.
Fortunately, there is such an Ada compiler (or at least there used to be). AdaMagic at one point had C available as a "target". It is now sold by SofCheck. When last I saw a discussion of it years and years ago, they referred to it as a "service" as much as a compiler, so it may not be cheap. But if you have a real business need, it would certainly be cheaper than spending man-years rewriting a working app.
Your other option of course would be to say "Screw Apple and their facist OS", and shoot for Android instead. Sadly, for business reasons, that may not be feasible. :-(
Update (2016/2012): The assets of SofCheck have become available from AdaCore, as the two companies have merged in early 2012.
I want to be able to use this dictionary in an iOS app.
Well, if there is an Ada compiler that targets iOS -- and there probably is considering that GCC has an Ada front-end -- then re-using the packages should be straight-forward so long as the source isn't compiler- (for a different compiler) or architecture-specific.
The most experience I have with porting Ada to other architectures was to port some code I had compiling to the native machine to the JVM (there's an Ada compiler which targets the JVM); the "gotchas" were more along the line of the JVM's case-sensitivity interacting with Ada's case insensitivity for naming classes and packages.
I am developing a trading engine and i have to use FIX engines. If i use a FIX engine of a higher version can it communicate with a FIX engine of a lower version ?
Are there any FIX engines capable of automatically converting the request to a lower version in case they are communicating with a lower version FIX engine ?
Which version of FIX should i use ?
I am developing a trading engine and i have to use FIX engines. If i use a FIX engine of a higher version can it communicate with a FIX engine of a lower version ?
Yes. Many financial institutions still use the FIX 4.4 and 4.2 versions. And many stock exchanges use FIX 5.0. So there is backward compatibility between them to support the older versions unless and until everybody moves to the same version.
Are there any FIX engines capable of automatically converting the request to a lower version in case they are communicating with a lower version FIX engine ?
Automatically no. It doesn't happen that you input a FIX 5.0 message and you get a FIX 4.2 message. You have to accept a FIX 5.0 message and parse the message and convert it to a FIX 4.2 message. Quickfix is one open source library. There is Cameron, but not open source. You have to do it for all messages, but more specifically for messages you want to support. Some message structures are still same so shouldn't be a big bummer.
Version you need to use is dependent on the clients you need to exchange messages with. Should ask what version they use or are intending to migrate to ?
I have been sold on the fun of using linq in areas other than pure database interaction. (See Calling fellow code nerds - Alternatives to Nested Loops?).
We are stuck on 2.0. I have told the powers that be about the ease of updating to 3.5 (we have already migrated to VS2008) but they are wanting a list of "benefits" for upgrading.
Can those that have experience in 3.5 help provide some talking points for the benefits of updating an existing app to 3.5?
UPDATE: Found an additional reason: Microsoft's inclusion of Charting tools for Asp.Net as a patch on top of 3.5! They get their business value, I get the fun...
Can YOU make a case for it? Sounds like you want it because LINQ is fun. Other people are mentioning features that are fun. I've always had a problem selling fun features to management because they aren't very compelling reasons to potentially disrupt an environment.
Honestly, it really depends on what you are using C# for. Are you a web developer, system admin, something else? Taking a general approach, I would use the following selling points (you will need to do some work to prove these things):
Zero-disruption for end-users when upgrading. Upgrading to the new version will be seamless and we will have a thoroughly reviewed test plan for updating all clients to this version. All of our old applications that require .NET 1.x or .NET 2.0 will still work perfectly.
Programmer Efficiency. You could mention how more of the Windows API is wrapped by .NET classes, thus making programmer more efficient because they don't have to P/Invoke as much. LINQ makes your more productive because of x, y, and z. Lambda expressions make you more productive because of x, y, and z.
Ease pains of future OS migration. Moving to WPF now will prepare us for Vista/Windows 7. We won't have to migrate applications using the now deprecated "Windows Forms" to WPF, because we will already be using it.
More applications purchased from 3rd parties will require it, so we will have to upgrade sooner or later.
In the end, you need to prove that at the very least, this move will not cost you money in terms of increased support or testing costs. If you can show it will make you be more productive and it will be a rather painless switch, then you will get your wish.
Maybe you should talk to some Java developers who are probably still forced to develop using 1.3 or 1.4 despite 1.5 being out for over 3 years and 1.6 for a couple... it appears platform consistency across the business is often of greater importance than the benefits of using the latest and greatest.
Also remember that 3.5 is just additional BCL libraries. You are still running on CLR 2.0. Same is true for 3.0. Usually when people find out that the underlying framework is the same and that you are just adding in new libraries they are more likely to go along with it.
You don't need .NET 3.5 to get LINQ or C# 3.0 features. You can implement your own LINQ for .NET 2.0. I am using C# 3.0 all over the place in my .NET 2.0 application. I don't know the full details on how to start the conversion process because I didn't set it up myself. This might be a good link for you: http://www.danielmoth.com/Blog/2007/05/using-c-30-from-net-20.html.
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Transitioning onto 3.5 would help you reap the benefits/ features of:
LINQ to (Entities/ XML / Objects / Datasets etc ).
WCF, WF and WPF.
ASP.net MVC where MVC is kind of a de facto standard in other
platforms like Ruby/Python which
allow you pure HTML/ Javacript based
development.
ORM options with ADO.net Entity
Framework/ Linq to Sql
4.
With a few addons you can have
support for dynamic languages
like
IronPython/IronRuby.
Oh ya I almost forgot ADO.net Data Services..one of my fav.
These are the few benefits that immediately come to my mind.
In my experience, the addition of LINQ and Extension methods alone have made many previously arduous and/or time consuming tasks much easier and faster. The increased developer productivity from that alone is worth the upgrade effort IMHO.
Lambda expressions are awesome. There is no end to the places where I find that lambda expressions help me out in a very concise and readable way.
Automatic properties, while being a simple concept, really help making the code base smaller and clearer.
Also, I sencond the extension methods.
Before I even opened this question I had my answer: LINQ - it's one of the greatest extensions ever in .NET - I love it. It took me a few days to figure out, but now I've got it, I use it all over the place. The ability to query collections and arrays is worth the upgrade alone in my mind.
Decreased development time (and therefore increased ROI)
Less time wasted finding workarounds for .NET bugs that've been fixed in newer releases.
Extension methods for native types (in a similar fashion to JavaScript prototyping)
LINQ extensions - they take a couple of days to get your head around, but it's awesome!
LINQ to XML makes working with XML so much simpler
LINQ to objects/collections
A nice new 3.5 poster from Microsoft that you can pin up in your cubicle.
As a manager if I have a happier more productive team that is producing more in less time, then its a no brainer.
Ask yourself this: Will the developers be more effective and will their increased productivity actually increase benefit to the company or reduce corporate costs once you've considered the upgrade/transition/installation on the servers/additional testing etc? If the answer is truly yes, then do the upgrade and quit arguing about it.