Neil McGovern: A new journey GNOME Foundation Executive Director


/usr/share/zoneinfo
. RcppCCTZ connects this library to R by relying on Rcpp.
A nice example is the helloMoon()
function (based on an introductory example in the CCTZ documentation) showing the time when Neil Armstrong took a small step, relative to local time in New York and Sydney:
R> library(RcppCCTZ)
R> helloMoon(verbose=TRUE)
1969-07-20 22:56:00 -0400
1969-07-21 12:56:00 +1000
New_York Sydney
"1969-07-20 22:56:00 -0400" "1969-07-21 12:56:00 +1000"
R>
R> example(formatDatetime)
frmtDtR> now <- Sys.time()
frmtDtR> formatDatetime(now) # current (UTC) time, in full precision RFC3339
[1] "2016-12-12T13:21:03.866711+00:00"
frmtDtR> formatDatetime(now, tgttzstr="America/New_York") # same but in NY
[1] "2016-12-12T08:21:03.866711-05:00"
frmtDtR> formatDatetime(now + 0:4) # vectorised
[1] "2016-12-12T13:21:03.866711+00:00" "2016-12-12T13:21:04.866711+00:00" "2016-12-12T13:21:05.866711+00:00"
[4] "2016-12-12T13:21:06.866711+00:00" "2016-12-12T13:21:07.866711+00:00"
R> example(parseDatetime)
prsDttR> ds <- getOption("digits.secs")
prsDttR> options(digits.secs=6) # max value
prsDttR> parseDatetime("2016-12-07 10:11:12", "%Y-%m-%d %H:%M:%S"); # full seconds
[1] "2016-12-07 04:11:12 CST"
prsDttR> parseDatetime("2016-12-07 10:11:12.123456", "%Y-%m-%d %H:%M:%E*S"); # fractional seconds
[1] "2016-12-07 04:11:12.123456 CST"
prsDttR> parseDatetime("2016-12-07T10:11:12.123456-00:00") ## default RFC3339 format
[1] "2016-12-07 04:11:12.123456 CST"
prsDttR> now <- trunc(Sys.time())
prsDttR> parseDatetime(formatDatetime(now + 0:4)) # vectorised
[1] "2016-12-12 07:21:17 CST" "2016-12-12 07:21:18 CST" "2016-12-12 07:21:19 CST"
[4] "2016-12-12 07:21:20 CST" "2016-12-12 07:21:21 CST"
prsDttR> options(digits.secs=ds)
R>
We also have a diff to the previous version thanks to CRANberries. More details are at the RcppCCTZ page; code, issue tickets etc at the GitHub repository.Changes in version 0.1.0 (2016-12-11)
- Synchronized with
CCTZ
upstream.- New parsing and formating helpers for Datetime vectors
- New parsing and formating helpers for (two)
double
vectors representing fullstd::chrono
nanosecond resolutions- Updated documentation and examples.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
The demo that probably drew the most attention was from my friend Georg who demoed some LulzBot Mini 3D Printers. They really seem to love Debian which is great!At #Debconf? Join the #HetznerSA #Supermariobros challenge and stand a chance to win a case of #Leagueofbeers pic.twitter.com/DpkOj6wmZb HetznerSA Careers (@HetznerCareers) July 2, 2016
LulzBot Mini #3Dprinters were on the scene at @DebConf Open Festival in South Africa. We re powered by @debian! pic.twitter.com/AOBS64ZtiJ LulzBot (@lulzbot3D) July 13, 2016DebConf (6 August to 12 August) If I try to write up all my thoughts and feeling about DC16, I ll never get this post finished. Instead, here as some tweets from DebConf that other have written:
@o0karen0o delivering today s #DebConf16 keynote pic.twitter.com/hG1wD5MBhH Michael Banck (@mbanck) July 3, 2016
Great to see Sicelo Mhlongo speaking about issues using @debian in Swaziland #debconf16 pic.twitter.com/U6z7HA8zd5 Neil McGovern (@nmcgovern) July 7, 2016
What happened at #DebConf16 yesterday? Sandstorm Principles talking about the freedom to choose #software #sandbox pic.twitter.com/ltYaw3dAmP Obsidian Systems (@obsidianza) July 5, 2016
All @DebConf end with similar feelings: we re an incredible crowd working together for a incredibly important cause. https://t.co/DYuUWT5eKt Didier Raboud (@OdyX_) July 9, 2016
My congratulations to the #DebConf video team. As usual, they are doing an amazing work at #DebConf16Day Trip We had 3 day trips:
Marcelo Santana (@mgsantana) July 8, 2016
make
,
that would fail so hard that hundreds of lines of errors and warnings
were outputted. There are two main reasons doing this is a bad idea:
/var/log/
, a web page on a local
server, anything. Learn where different software write logs on your
system, and integrate reading them in your workflow. Often, it will be
your only information about the bug. Often, it will tell you where the
bug lies. Sometimes, it will even give you hints on how to fix it.
You may have to filter out a lot of garbage to find relevant
information about your bug. Learn to spot some keywords like error
or warning
. In long stacktraces, spot the lines concerning your
files; because more often, your code is to be blamed, rather than
deeper library code. grep
the logs with relevant keywords. If you
have the option, colorize the output. Use tail -f
to follow a file
getting updated. There are so many ways to grasp logs, so find what
works best with you and never forget to use it!
Print foobar
That one doesn't concern compilation errors (unless it's a Makefile
error, in that case this file is your code anyway).
When the program logs and output failed to give you where an error
occured (oh hi Segmentation fault
!), and before having to dive into
a memory debugger or system trace tool, spot the portion of your
program that causes the bug and add in there some print
statements. You can either print("foo")
and print("bar")
, just to
know that your program reaches or not a certain place in your code, or
print(some_faulty_var)
to get more insights on your program
state. It will give you precious information.
stderr >> "foo" >> endl;
my_db.connect(); // is this broken?
stderr >> "bar" >> endl;
my_db
that is broken if you get foo
and not bar
on your
standard error.
(That is an hypothetical example. If you know something can break,
such as a database connection, then you should always enclose it in a
try
/catch
structure).
Isolate and reproduce the bug
This point is linked to the previous one. You may or may not have
isolated the line(s) causing the bug, but maybe the issue is not
always raised. It can depend on many other things: the program or
function parameters, the network status, the amount of memory
available, the decisions of the OS scheduler, the user rights on the
system or on some files, etc. More generally, any assumption you made
on any external dependency can appear to be wrong (even if it's right
99% of the time). According to the context, try to isolate the set of
conditions that trigger the bug. It can be as simple as "when there is
no internet connection", or as complicated as "when the CPU load of
some external machine is too high, it's a leap year, and the input
contains illegal utf-8 characters" (ok, that one is fucked up; but it
surely happens!). But you need to reliably be able to reproduce the
bug, in order to be sure later that you indeed fixed it.
Of course when the bug is triggered at every run, it can be
frustrating that your program never works but it will in general be
easier to fix.
RTFM
Always read the documentation before reaching out for help. Be it
man
, a book, a website or a wiki, you will find precious information
there to assist you in using a language or a specific library. It can
be quite intimidating at first, but it's often organized the same
way. You're likely to find a search tool, an API reference, a
tutorial, and many examples. Compare your code against them. Check in
the FAQ, maybe your bug and its solution are already referenced there.
You'll rapidly find yourself getting used to the way documentation is
organized, and you'll be more and more efficient at finding instantly
what you need. Always keep the doc window open!
Google and Stack Overflow are your friends
Let's be honest: many of the bugs you'll encounter have been
encountered before. Learn to write efficient queries on search
engines, and use the knowledge you can find on questions&answers
forums like Stack Overflow. Read the answers and comments. Be wise
though, and never blindly copy and
paste
code from there. It can be as bad as introducing malicious security
issues into your code, and you won't learn anything. Oh, and don't
copy and paste anyway. You have to be sure you understand every single
line, so better write them by hand; it's also better for memorizing
the issue.
Take notes
Once you have identified and solved a particular bug, I advise to
write about it. No need for shiny interfaces: keep a list of your bugs
along with their solutions in one or many text files, organized by
language or framework, that you can easily grep
.
It can seem slightly cumbersome to do so, but it proved (at least to
me) to be very valuable. I can often recall I have encountered some
buggy situation in the past, but don't always remember the
solution. Instead of losing all the debugging time again, I search in
my bug/solution list first, and when it's a hit I'm more than happy I
kept it.
Further print
statement (at the price of being
over-engineered for simple programs): severity levels (info
,
warning
, error
, fatal
, etc), output in rotating files, and
many more.The cross architecture configuration files have moved to the new cross-config package and the older dpkg-cross binary with supporting perl module are now deprecated. Future uploads will only include the cross-config package. Use cross-config to retain support for autotools and CMake cross-building configuration. If you use the deprecated dpkg-cross binary, now is the time to migrate away from these path changes. The dpkg-cross binary and the supporting perl module should NOT be expected to be part of Debian by the time of the Stretch release.2.6.14 also marks the end of my involvement with dpkg-cross. The Uploaders list has been shortened but I'm still listed to be able to get 2.6.14 into NEW. A future release will drop the perl module and the dpkg-cross binary, retaining just the new cross-config package.
/usr/share/zoneinfo
. RcppCCTZ connects this library to R by relying on Rcpp. This new version adds more support to the notion of civil time representation -- i.e. independent of timezones -- which can then be mapped to different time zone representations.
Changes in this version are summarized here:
Changes in version 0.0.4 (2016-04-17)A quick example is provided here where we look at the time when Neil Armstrong first stepped on the moon as an absolute ("civil") time and two local representations:
- Synchronized with
CCTZ
v2 upstream.- Updated
examples.cpp
accordingly
// from examples/hello.cc
//
// [[Rcpp::export]]
int helloMoon()
cctz::time_zone syd;
if (!cctz::load_time_zone("Australia/Sydney", &syd)) return -1;
// Neil Armstrong first walks on the moon
const auto tp1 = cctz::convert(cctz::civil_second(1969, 7, 21, 12, 56, 0), syd);
const std::string s = cctz::format("%F %T %z", tp1, syd);
Rcpp::Rcout << s << "\n";
cctz::time_zone nyc;
cctz::load_time_zone("America/New_York", &nyc);
const auto tp2 = cctz::convert(cctz::civil_second(1969, 7, 20, 22, 56, 0), nyc);
return tp2 == tp1 ? 0 : 1;
We can call this from R, and get the expected result (of equivalence between the dates):
R> library(RcppCCTZ)
R> helloMoon()
1969-07-21 12:56:00 +1000
[1] 0
R>
We also have a diff to the previous version thanks to CRANberries.
More details, issue tickets etc at the GitHub repository.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Next.