Bearing in mind that
100 > 9
and
.9 > .100
Which of these is the later version?
Version 2.1.100
Version 2.1.9
I'm trying to figure out whether the dots in a version label act as a decimal point or if they are simply delimiters around independently incrementing numbers.
The common practice seems to have 2.1.9 is before 2.1.100. See for instance
Semantic versioning
Debian version comparison algorithm
RPM version comparison algorithm
but people tends to do their own thing, especially when considering old enough software (the RPM documentation reference hints that Perl version had such oddity in the past, probably related to the presence of initial 0 in a segment)
Related
I’m having a problem with printing figures in octave when the figure’s visibility is set to false. For example, the following code produces a “panic: segmentation fault” in Octave version 4.2.2:
t = 1:10;
fh = figure(“visible”, false);
plot(t,sin(t))
print(“fig.png”)
If I run the above code in Octave version 5.2.0, there is no problem. Is this a bug that was fixed in the Octave 5 update? If so, is there a workaround that I can use for Octave 4? I would prefer to use Octave 4 if possible.
Other notes:
I am running this in Ubuntu 16.04.6 LTS and I installed octave 4 using apt.
The answer to your question is, yes. Here is the relevant line from the v5.1.0 NEWS:
Dependencies:
The GUI requires Qt libraries. The minimum Qt4 version supported is Qt4.8. Qt5 of any version is preferred.
The OSMesa library is no longer used. To print invisible figures when using OpenGL graphics, the Qt QOFFSCREENSURFACE feature must be available and you must use the qt graphics toolkit.
Apparently the now deprecated OSMESA dependency and the printing of invisible figures was a long-standing pain-in-the-butt. Maybe you'll have some luck going through bug comments (e.g. someone says that if you make it visible at least once, it may be possible to print).
But as people have said in the comments, the best thing to do would be to upgrade your octave version, and recompile your mexfiles for the new version.
Apache Drill has its own columnar representation like Apache Arrow. But Apache Arrow has support for more programming languages. I am looking forward to use Apache Drill but still I want the programming language support of Apache Arrow.
Some sources say that, Apache Arrow has its roots in Apache Drill's ValueVectors.
Drill represents data internally as JSON documents – similar to
MongoDB and Elasticsearch. These JSON documents are "shredded" into
columns, which allows Drill to deliver the performance enhancements of
columnar analytics but retain the ability to query complex data. Note,
this internal representation is not based on Apache Arrow. - Source
Why cannot Apache Drill make use of the Apache Arrow project? How is Drill's internal representation differ from Apache Arrow and what advantages Arrow has over Drill's ValueVectors and vice-versa.
The Apache Arrow Java library started out as a fork of Drill's ValueVectors as the Apache Arrow project began at the beginning of 2016. The memory representation is nearly the same; one significant difference is that Arrow uses 1 bit to represent whether a vector slot is null, will Drill uses 1 byte. We decided to change this for reasons of memory efficiency and for using popcount intrinsic operations to check whether a batch of values contain any nulls.
It has been discussed whether to use exactly Arrow's representation in Apache Drill, but there is no timeline for this to happen. The relevant issue is https://issues.apache.org/jira/browse/DRILL-4455
Apache Arrow has been developed as an open standard with a public API in many programming languages. We have some level of support now for 11 programming languages, either through native implementations or bindings. This include C, C++, C#, Go, Java, JavaScript, MATLAB, Python, R, Ruby, and Rust.
I am not aware of any performance analysis comparing the memory representations, but the difference relating to null representation is unlikely to cause a significant difference.
Drill's community is considering to move onto Apache Arrow. Please take a look the following tickets:
https://issues.apache.org/jira/browse/ARROW-3164
https://issues.apache.org/jira/browse/DRILL-4455
But it is on hold right now, since there were a lot of changes and improvements in both projects. So there are some differences in Terminology, Metadata Notation, Data Types, Data Layout..
You can reply to this mail thread in drill dev mailing list to discuss it further:
https://lists.apache.org/thread.html/8d895fb40702f3120532f15594ea935a818ac0eb5acdb4fd1248d89f#%3Cdev.drill.apache.org%3E
Also contributions are very welcome :)
I've a compiled tcl version 8.4 and want to check if --enable-threads was set when it was compiled or not ?
or if there is any another way to get the list of all passed flags.
Thanks
IMPORTANT NOTE!
Tcl 8.4 is out of long-term support. Absolutely no further changes will be forthcoming to it, not even if a catastrophic security error is discovered; if your issue isn't fixed by 8.4.20, you'll need to go to 8.5 or later. We don't know of any such security issues, but we aren't looking and won't fix them if they're found.
Support here is only on a “because we feel nice” basis. You should not create new work based on 8.4.
The global array element tcl_platform(threaded) is defined and set to 1 when the currently-used Tcl library is built with thread support. This is true from at least Tcl 8.4 onwards. Here's how to reliably get a nice boolean value you can check:
set isThreaded [expr {
[info exist tcl_platform(threaded)] && $tcl_platform(threaded)
}]
NB: Some platforms are virtually always threaded anyway (because of how they work internally; this is the case with Windows and OSX if I remember right). Future versions of Tcl (8.7 onwards) will default to threaded everywhere; this will be the only supported build mode from 9.0 on. You'll still need the Thread package to work with threads in your script, but that's a standard extension these days.
Starting with 8.5 (TIP 59), one can retrieve details about the build configuration using tcl::pkgconfig:
% tcl::pkgconfig get threaded
1
Note that this is not available in Tcl 8.4; if available, one does not have to protect against requesting an inexistent array entry tcl_platform(threaded).
I understand that using ^2.x and ^2.1.2 will both update minor versions and patches as long as major version is still 2, however should I specify minor version and/or patch version if I use the caret?
One of the comments in https://bytearcher.com/articles/semver-explained-why-theres-a-caret-in-my-package-json/ says:
you don't actually want 2.., because that allows both newer and older releases. ^2.1.2 means "2.1.2 or newer".
But if I know ^2.1.2 is already released, wouldn't using ^2.x essentially always be equivalent to ^2.1.2, so is there a purpose to including minor and patch version?
Use this tool to test your hypotheses: https://semver.npmjs.com/
According to this tool, there is a point in including the minor and/or patch version. After experimenting a little bit, it seems that the caret symbol will lock down the minor version but it won't pull in anything that is older than the version you supplied.
So for example: ^2 can pull in version 2.2 but ^2.3 will not.
According to mysql document
"Encoding with a 128-bit key length is used, but you can extend it up to 256 bits by modifying the source."
But they didn't seem to provide instruction where to change. Anyone experience with this situation? which source file should change?
Note: I use these steps to compile.
I found little help from mysql mailing list
file include/my_aes.h
#define AES_KEY_LENGTH 128 /* must be 128 192 or 256 */
as I'm using OpenSuSe 11.1 need to have following tools
sudo zypper install gcc gcc-c++ ncurses-devel
then just compile it by this instruction - here
Credit to LenZ and tripanel.net
It's probably going to be a more maintainable solution to carry out the encryption in the client application.
Moreover, you'll also then get the benefit of then having the data carried over the network encrypted and not sending the key over the network (Of course you can use SSL to connect to mysql to mitigate this anyway).
If this does not seem like a good approach, please post your requirements.
You probably do not want to compile your own mysql binaries; there are more useful things for developers to do than building their own mysql binaries. MySQL / Sun's ones are extensively tested and won't contain performance regressions (we hope).
The mysql AES_ENCRYPT() functions are also potentially not secure because they haven't documented
How they hash the password into the key
What cipher mode they use
If they're done in a vulnerable way, the encryption could be very weak. It depends on your use-case whether this matters.