I´d like to compile an dll in ironpython AND add some information on the file-version. In former versions (e.g. 2.7.7) there has been the theoretical possibility to do this by
ipy.exe pyc.py test.py /out:test /file_version:1.1.1.1 /target:dll
In newer versions I can´t see the feature (/file_version) anymore (also not in ipyc.exe, which is shipped with ironpython). Does someone know the way?
I found the feature. At least in the versions 2.7.11 and 3.4.0alpha I found the feature in ipyc.exe
ipyc.exe /out:dummy.dll /copyright:dummycopyright /fileversion:1.1 /productname:dummy /productversion:1.1 <skripts>
Unfortunalely, it is not documented in
ipyc.exe /h
I was looking there for the feature, that´s why I raised the question.
Well, I prefer hidden features to hidden bugs. ;)
Related
I am trying to follow along with some Youtube tutorials by the maker of HackRF and when using GNU Radio it seems they no longer have Osmocom, or WX blocks. So I go to the repo found here https://github.com/osmocom/gr-osmosdr/tree/master , also note they dont have an "issues" tab to ask questions in. Anyways I follow the instructions and get this failure:
CMake Error at /usr/lib/cmake/pybind11/pybind11Tools.cmake:165 (add_library):
Target "osmosdr_python" links to target "sndfile::sndfile" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/gnuradio/GrPybind.cmake:261 (pybind11_add_module)
python/bindings/CMakeLists.txt:28 (GR_PYBIND_MAKE_OOT)
CMake Error at lib/CMakeLists.txt:51 (add_library):
Target "gnuradio-osmosdr" links to target "sndfile::sndfile" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
So I am not sure where to go from here. Is there a replacement to Osmocom? I noticed a "soapy" source called HackRF but it is so basic compared to the Osmocom one. I dont really understand how GNURadio works but nerfing a feature that is documented all over the internet in GNU Radio tutorials seems odd.
Any ideas?
Yes, gr-soapy is the what I'd recommend you use. It's not a "replacement", it's an alternative. But unlike gr-osmosdr (which was never part of GNU Radio), it's part of modern GNU Radio.
Your youtube tutorials must be really outdated if they still use WXGui (we've started telling people WXGUI was no longer maintained and will be removed about 10 years ago). That's a bad start. Instead, try to go through the official GNU Radio Academy at https://tutorials.gnuradio.org
but it is so basic compared to the Osmocom one
What feature that the HackRF actually has and that is useful to you are you missing?
I am working on a C/C++ product that only builds in the Linux environment. It is a massive code base and generating lint targets manually is going to be incredibly painful. I know that you can link Lint into cmake so cmake generates these targets for you while it builds the code. Cmake has a macro called add_pc_lint (https://cmake.org/Wiki/PC-Lint) which does this for you. I wanted to know if there is something similar that could be used for Flexelint?
I currently have a PC-Lint license and wanted to ask this question before spending $998 on a Flexelint license. Thanks!
FlexeLint and PC-lint share the same manual so I'm pretty sure they are fully compatible on the command line. You should be able to use the same make files for both, or with minor changes. Otherwise they do offer a 30-day money-back guarantee.
Another option might be to run PC-lint under Wine. I tried this once and I got it working, but then I never used it much so I'm not sure how well it worked.
So I did get a FlexeLint license yesterday and now I am trying to integrate it into my CMakeLists. I am looking at the source code of cmake's add_pc_lint function and trying to modify it to work for FlexeLint. If anyone has played around with it before, please comment. The FlexeLint manual is not at all helpful.
After building with CMAKE for visual studio 2015, I found that there were some build errors that required me to edit the code. I feel that this should not be necessary and would like to know if I might have done something wrong in build process to make these errors surface
Firstly I had to correct the compiler name from vc130 to vc140 in the files include/CGAL/auto-link/auto-link.h and cmake/module/CGAL_GeneratorSpecificSettings.cmake. I assume that this is simply because it has not been tested VS2015 and someone just assumed that vc130 would follow vc120.
The other issue I ran into was that eight functions that did not compile. These were the functions
Segment_2<R_>::min
Segment_2<R_>::max
Segment_2<R_>::vertex
Segment_2<R_>::point
Segment_2<R_>::operator[]
Segment_3<R_>::min
Segment_3<R_>::max
The issue seemed to be that the type signature of the implementation did not match that of the declaration. I tried fixing the type signature, but was unable to get it to match exactly. To fix this I ended up moving the implementation of these functions into the declaration. I would like why this is apparently necessary as presumably it compiles for other people. Sloriot commented that it was because the VS2015 compiler was more recent than the one CGAL is tested with. It is however my understanding that the visual studio compilers are backwards compatible, an thus it should not break the code to update the compiler.
The first version of CGAL officially compatible with VS2015 will be CGAL 4.7.
It seems that the new version of the Microsoft has some issues compiling valid C++ code it was accepting before. This explains why the release 4.6 of CGAL (or prior versions) has some compilation issues with that new compiler.
I mean, can I use the com.sun.org.apache (all subpackages) classes as I use they from org.apache (in any Apache lib)?
Will the OpenJDK maintain this package up to date with apache updates?
And the JDK7 will maintain this package?
Where can I find information about that?
It is a very bad idea to use it. Once upon a time, Sun took a copy of Xerces, chock full of bugs. They made some changes. Perhaps they subtracted some bugs. We know that there are many very serious bugs that they did not subtract.
And they renamed it to com.sun.... for one reason: to tell you not to use it. At any time, in any point release, in any patch, they can change those classes incompatibly or remove them.
Further, these classes may not be in IBM's copy of the JRE, or Apple's, or (haha) Microsoft's, or JRocket.
If you want Xerces, use Xerces. To find information about this, read the Xerces-j mailing list archive for many stern warnings from the Xerces developers about the version forked by Sun.
The fact that the classes are formally 'public' means nothing except that Sun needed to be able to new them from some other package.
Err I wouldn't, just based on the fact that they're internal classes and there is a risk of them changing over time. Use the org.apache classes instead.
No idea about the intentions with keeping them up to date, maybe try posting a message on the openjdk forum:
http://mail.openjdk.java.net/mailman/listinfo
My understanding is that this is a fork of the apache code. At one point they were the same, but no more. So you can't count on the same bug fixes being present in both versions.
If documentation for this package says that it is public, then it's OK to use.
Otherwise they can pool a floor underneath you when they decide not to support it in the future.
Usually, you should not rely on anything other than java and javax in JDK.
Sometimes I want to look up the implementations of functions in the stdlib, I've downloaded the sourcecode, but it's quite messy.
Just greping is not really suitable because of the many hits.
Does anyone know a webpage doxygen style that has the documentation.
The same goes for the linux kernel.
Thanks
You should check if your distribution is using the vanilla GLIBC or the EGLIBC fork (Debian and Ubuntu have switched to EGLIBC EDIT: they switched back around 2014).
Anyway, the repository browser for GLIBC is at http://sourceware.org/git/?p=glibc.git
http://code.woboq.org/userspace/glibc/, posted by #guruz below, is a good alternative.
The source is a bit complicated by the presence of multiple versions of the same files.
How about this for libc documentation? And perhaps this for the kernel? There is also Google Code search; here is an example search.
More on Google Code Search You can enter search queries like this: package:linux-2.6 malloc for any references to malloc in the linux-2.6 kernel.
Edit: Google Code search is now shut down. But you can access the git repo at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git and it has search as well.
You can try http://code.woboq.org/userspace/glibc/
It has nice navigation/hilighting similar to an IDE.
To help navigate the source to glibc, perhaps try something like ctags or cscope?
Note: I get dumber every time I look at the glibc source, so please be careful! :)
If you are using GNU C (glibc), the functions (beyond the GNU extensions) follow the POSIX standard as far as their arguments, implementation, failure and return values. If you want to peek under the hood of static members, you'll have to look at the code.
Every push (that I can remember) to try and adopt something like Doxygen for glibc was rejected for the following reasons:
Redundant, POSIX already documents almost everything thats exposed, as well as man and info pages.
Too much work initially
More work for maintainers
As far as the kernel goes, Linux does use a system very similar to Doxygen called Kerneldoc.
You can also get actual Doxygen-generated docs from http://fossies.org/dox/glibc.