Search Results: "jeroen"

16 December 2021

Dirk Eddelbuettel: RProtoBuf 0.4.18: Multiple Updates

A new release 0.4.18 of RProtoBuf arrived on CRAN earlier today. RProtoBuf provides R with bindings for the Google Protocol Buffers ( ProtoBuf ) data encoding and serialization library used and released by Google, and deployed very widely in numerous projects as a language and operating-system agnostic protocol. This release, the first since March of last year, contains two contributed pull requests improving or extending the package, some internal maintance updating the CI setup as well as retiring an old-yet-unused stub interface for RPC, as well as an update for UCRT builds on Windows. The following section from the NEWS.Rd file has more details.

Changes in RProtoBuf version 0.4.18 (2021-12-15)
  • Support string_view in FindMethodByName() (Adam Cozzette in #72).
  • CI use was updated first at Travis, later at GitHub and now uses r-ci (Dirk in #74 and (parts of) #76).
  • The (to the best of our knowledge) unused minimal RPC mechanism has been removed, retiring one method and one class as well as the import of the RCurl package (Dirk in #76).
  • The toJSON() method supports two (upstream) formatting toggles (Vitali Spinu in #79 with minor edit by Dirk).
  • Windows UCRT builds are now supported (Jeroen in #81, Dirk and Tomas Kalibera in #82).

Thanks to my CRANberries, there is a diff to the previous release. The RProtoBuf page has copies of the (older) package vignette, the quick overview vignette, and the pre-print of our JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

26 June 2021

Dirk Eddelbuettel: RcppRedis 0.1.11: Minor Update

A new minor release of RcppRedis arrived on CRAN, the first update since the last release in January of last year. RcppRedis is one of several packages connecting R to the fabulous Redis in-memory datastructure store (and much more). RcppRedis does not pretend to be feature complete, but it may do some things faster than the other interfaces, and also offers an optional coupling with MessagePack binary (de)serialization via RcppMsgPack. The package has carried production loads for several years now. This release updates CI to using r-ci, adds a quit() methods, and updates the windows library in builds thanks to a PR by Jeroen which also enables builds under the experimemtal UCRT windows flavor.

Changes in version 0.1.11 (2021-06-26)
  • The CI setup was updated to use run.sh from r-ci (Dirk).
  • A new function quit can be used to close a connection (Dirk).
  • The windows build was updated to libhiredis 1.0.0, and UCRT support was added (Jeroen in #42).

Courtesy of CRANberries, there is also a diffstat report for this release. More information is on the RcppRedis page. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

23 June 2021

Dirk Eddelbuettel: RcppGSL 0.3.9: Polish and More Builds

Release 0.3.9 of the RcppGSL package arrived at CRAN today, pretty much exactly one year since the last upload. The RcppGSL package provides an interface from R to the GNU GSL by relying on the Rcpp package. This release brings some small documentation and CI polish, and enables builds on the newer (and still experimental) windows UCRT flavor (which will bring native utf-8 chars to Windows, see this and this write-up) thanks to a PR by Jeroen.

Changes in version 0.3.9 (2021-06-23)
  • The pdf vignette was extended by a small subsection (Dirk).
  • The CI setup was updated to use run.sh from r-ci (Dirk).
  • The windows was updated to GSL 2.7, and UCRT support was added (Jeroen in #28).

Courtesy of CRANberries, a summary of changes to the most recent release is also available. More information is on the RcppGSL page. Questions, comments etc should go to the issue tickets at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

13 May 2021

Bits from Debian: New Debian Developers and Maintainers (March and April 2021)

The following contributors got their Debian Developer accounts in the last two months: The following contributors were added as Debian Maintainers in the last two months: Congratulations!

15 July 2017

Dirk Eddelbuettel: Rcpp 0.12.12: Rounding some corners

The twelveth update in the 0.12.* series of Rcpp landed on CRAN this morning, following two days of testing at CRAN preceded by five full reverse-depends checks we did (and which are always logged in this GitHub repo). The Debian package has been built and uploaded; Windows and macOS binaries should follow at CRAN as usual. This 0.12.12 release follows the 0.12.0 release from late July, the 0.12.1 release in September, the 0.12.2 release in November, the 0.12.3 release in January, the 0.12.4 release in March, the 0.12.5 release in May, the 0.12.6 release in July, the 0.12.7 release in September, the 0.12.8 release in November, the 0.12.9 release in January, the 0.12.10.release in March, and the 0.12.11.release in May making it the sixteenth release at the steady and predictable bi-montly release frequency. Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 1097 packages (and hence 71 more since the last release in May) on CRAN depend on Rcpp for making analytical code go faster and further, along with another 91 in BioConductor. This releases contain a fairly large number of fairly small and focused pull requests most of which either correct some corner cases or improve other aspects. JJ tirelessly improved the package registration added in the previous release and following R 3.4.0. Kirill tidied up a number of small issues allowing us to run compilation in even more verbose modes---usually a good thing. Jeroen, Elias Pipping and Yo Gong all contributed as well, and we thank everybody for their contributions. All changes are listed below in some detail.

Changes in Rcpp version 0.12.12 (2017-07-13)
  • Changes in Rcpp API:
    • The tinyformat.h header now ends in a newline (#701).
    • Fixed rare protection error that occurred when fetching stack traces during the construction of an Rcpp exception (Kirill M ller in #706).
    • Compilation is now also possibly on Haiku-OS (Yo Gong in #708 addressing #707).
    • Dimension attributes are explicitly cast to int (Kirill M ller in #715).
    • Unused arguments are no longer declared (Kirill M ller in #716).
    • Visibility of exported functions is now supported via the R macro atttribute_visible (Jeroen Ooms in #720).
    • The no_init() constructor accepts R_xlen_t (Kirill M ller in #730).
    • Loop unrolling used R_xlen_t (Kirill M ller in #731).
    • Two unused-variables warnings are now avoided (Jeff Pollock in #732).
  • Changes in Rcpp Attributes:
    • Execute tools::package_native_routine_registration_skeleton within package rather than current working directory (JJ in #697).
    • The R portion no longer uses dir.exists to no require R 3.2.0 or newer (Elias Pipping in #698).
    • Fix native registration for exports with name attribute (JJ in #703 addressing #702).
    • Automatically register init functions for Rcpp Modules (JJ in #705 addressing #704).
    • Add Shield around parameters in Rcpp::interfaces (JJ in #713 addressing #712).
    • Replace dot (".") with underscore ("_") in package names when generating native routine registrations (JJ in #722 addressing #721).
    • Generate C++ native routines with underscore ("_") prefix to avoid exporting when standard exportPattern is used in NAMESPACE (JJ in #725 addressing #723).

Thanks to CRANberries, you can also look at a diff to the previous release. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

7 May 2017

Dirk Eddelbuettel: RInside 0.2.14

A new release 0.2.14 of RInside is now on CRAN and in Debian. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by Rcpp. It has been nearly two years since the last release, and a number of nice extensions, build robustifications and fixes had been submitted over this period---see below for more. The only larger and visible extension is both a new example and some corresponding internal changes to allow a readline prompt in an RInside application, should you desire it. RInside is stressing the CRAN system a little in that it triggers a number of NOTE and WARNING messages. Some of these are par for the course as we get close to R internals not all of which are "officially" in the API. This lead to the submission sitting a little longer than usual in incoming queue. Going forward we may need to find a way to either sanction these access point, whitelist them or, as a last resort, take the package off CRAN. Time will tell. Changes since the last release were:

Changes in RInside version 0.2.14 (2017-04-28)
  • Interactive mode can use readline REPL ( ukasz aniewski-Wo k in #25, and Dirk in #26)
  • Windows macros checks now uses _WIN32 (Kevin Ushey in #22)
  • The wt example now links with libboost_system
  • The Makevars file is now more robist (Mattias Ellert in #21)
  • A problem with empty environment variable definitions on Windows was addressed (Jeroen Ooms in #17 addressing #16)
  • HAVE_UINTPTR_T is defined only if not already defined
  • Travis CI is now driven via run.sh from our forked r-travis

CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page, or to issues tickets at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

19 March 2017

Dirk Eddelbuettel: Rcpp 0.12.10: Some small fixes

The tenth update in the 0.12.* series of Rcpp just made it to the main CRAN repository providing GNU R with by now over 10,000 packages. Windows binaries for Rcpp, as well as updated Debian packages will follow in due course. This 0.12.10 release follows the 0.12.0 release from late July, the 0.12.1 release in September, the 0.12.2 release in November, the 0.12.3 release in January, the 0.12.4 release in March, the 0.12.5 release in May, the 0.12.6 release in July, the 0.12.7 release in September, the 0.12.8 release in November, and the 0.12.9 release in January --- making it the fourteenth release at the steady and predictable bi-montly release frequency. Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 975 packages on CRAN depend on Rcpp for making analytical code go faster and further. That is up by sixtynine packages over the two months since the last release -- or just over a package a day! The changes in this release are almost exclusively minor bugfixes and enhancements to documentation and features: James "coatless" Balamuta rounded out the API, I aki Ucar fixed a bug concerning one-character output, Jeroen Ooms allowed for finalizers on XPtr objects, Nathan Russell corrected handling of lower (upper) triangular matrices, Dan Dillon and I dealt with Intel compiler quirks for his algorithm.h header, and I added a C++17 plugin along with some (overdue!) documentation regarding the various C++ standards that are supported by Rcpp (which is in essence whatever your compiler supports, i.e., C++98, C++11, C++14 all the way to C++17 but always keep in mind what CRAN and different users may deploy).

Changes in Rcpp version 0.12.10 (2017-03-17)
  • Changes in Rcpp API:
    • Added new size attribute aliases for number of rows and columns in DataFrame (James Balamuta in #638 addressing #630).
    • Fixed single-character handling in Rstreambuf (I aki Ucar in #649 addressing #647).
    • XPtr gains a parameter finalizeOnExit to enable running the finalizer when R quits (Jeroen Ooms in #656 addressing #655).
  • Changes in Rcpp Sugar:
    • Fixed sugar functions upper_tri() and lower_tri() (Nathan Russell in #642 addressing #641).
    • The algorithm.h file now accomodates the Intel compiler (Dirk in #643 and Dan in #645 addressing issue #640).
  • Changes in Rcpp Attributes
    • The C++17 standard is supported with a new plugin (used eg for g++-6.2).
  • Changes in Rcpp Documentation:
    • An overdue explanation of how C++11, C++14, and C++17 can be used was added to the Rcpp FAQ.

Thanks to CRANberries, you can also look at a diff to the previous release. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

27 April 2016

Niels Thykier: auto-decrufter in top 5 after 10 months

About 10 months ago, we enabled an auto-decrufter in dak. Then after 3 months it had become the top 11th remover . Today, there are only 3 humans left that have removed more packages than the auto-decrufter impressively enough, one of them is not even an active FTP-master (anymore). The current score board:
 5371 Luca Falavigna
 5121 Alexander Reichle-Schmehl
 4401 Ansgar Burchardt
 3928 DAK's auto-decrufter
 3257 Scott Kitterman
 2225 Joerg Jaspert
 1983 James Troup
 1793 Torsten Werner
 1025 Jeroen van Wolffelaar
  763 Ryan Murray
For comparison, here is the number removals by year for the past 6 years:
 5103 2011
 2765 2012
 3342 2013
 3394 2014
 3766 2015  (1842 removed by auto-decrufter)
 2845 2016  (2086 removed by auto-decrufter)
Which tells us that in 2015, the FTP masters and the decrufter performed on average over 10 removals a day. And by the looks of it, 2016 will surpass that. Of course, the auto-decrufter has a tendency to increase the number of removed items since it is an advocate of remove early, remove often! .:) Data is from https://ftp-master.debian.org/removals-full.txt. Scoreboard computed as:
  grep ftpmaster: removals-full.txt   \
   perl -pe 's/.*ftpmaster:\s+//; s/\]$//;'   \
   sort   uniq -c   sort --numeric --reverse   head -n10
Removals by year computed as:
 grep ftpmaster: removals-full.txt   \
   perl -pe 's/.* (\d 4 ) \d 2 :\d 2 :\d 2 .*/$1/'   uniq -c   tail -n6
(yes, both could be done with fewer commands)
Filed under: Debian

4 December 2015

Dirk Eddelbuettel: RQuantLib 0.4.2: Now with intra-day times

A new minor release of RQuantLib was released onto CRAN and into Debian. It takes advantages of some changes from last week's QuantLib release 1.7. 500 Rcpp packages Particularly noteworthy is the addition of support for intra-daily times in QuantLib based on work by Klaus Spanderen. If QuantLib was configured with the -enable-intraday option, we use the higher granularity of the time representation in all option pricers and implied volatility calculations. The impact of this feature is illustrated in the graph below. The graph shows the valuation of a Call option, European expiry, struck at the money with sensible short rate, dividend yield and volatility. We vary the time to expiry from five days to zero in steps of a quarter day. In darker blue is the correct valuation declining in parabolic shape. In lighter blue is what we get with QuantLib up to release 1.6, or newer releases configured without intra-day time support: an ugly step function that is off, and increasingly so we approach the expiration. Which leads to an appeal: a volunteer is needed to update the QuantLib 1.7 build for Windows. Jeroen tried, but ran into a snag and out of time. If you can help, please get in touch to Jeroen and myself. We suspect that the largest part of RQuantLib users relies on the prebuilt binaries from CRAN, and it would nice to have these updated to the current version of QuantLib. The full changes are detailed below.
Changes in RQuantLib version 0.4.2 (2015-12-03)
  • Changes in RQuantLib code:
    • Intra-day times are now available if QuantLib 1.7 or later is used, and has been configured with --enable-intraday
    • New helper functions getQuantLibVersion() and getQuantLibCapabilties()
    • New package startup code detects and warns about outdated QuantLib versions, or missing intra-day capability, unless not interactive.
    • The missing Monthly parameter has been added to matchFrequency (fixing issue ticket #19)
Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list off the R-Forge page. Issue tickets can be filed at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

3 December 2015

Dirk Eddelbuettel: RcppCCTZ 0.0.2 -- now with Solaris support

Following on yesterday's announcement of RcppCCTZ, what is the only thing better than another date, time, or timezones library package? One that works on Solaris too :) Bradley White from CCTZ upstream spotted the failed compilation on the machine in Oxford and suggested a quick fix. Jeroen quickly tested what I had put into a branch, and there we have it: version 0.0.2 which now builds everywhere. Changes (for both releases) are summarized here:
Changes in version 0.0.2 (2015-12-02)
  • Additional #ifdef statements suggested by Bradley White in CCTZ ticket #5 permitting compilation on Solaris with thanks to Jeroen for testing our branch.
Changes in version 0.0.1 (2015-12-01)
  • Initial CRAN upload.
  • Package is functional and provides examples.
We now 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.

9 January 2015

Dirk Eddelbuettel: random 0.2.3

A new release of my random package for truly (hardware-based) random numbers as provided by random.org is now on CRAN. The main change is a switch to the curl() function from the eponymous package by Jeroen Ooms. This was caused by random.org now using https instead of http, annd the fact that te url() function from R does not cope well with the redirect. Besides this (enforced) change, everything else remains the same. Courtesy of CRANberries comes a diffstat report for this release. Current and previous releases are available here as well as on CRAN.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

12 December 2014

Dirk Eddelbuettel: RProtoBuf 0.4.2

A new release 0.4.2 of RProtoBuf is now on CRAN. RProtoBuf provides R bindings for the Google Protocol Buffers ("Protobuf") data encoding library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects. Murray and Jeroen did almost all of the heavy lifting. Many changes were triggered by two helpful referee reports, and we are slowly getting to the point where we will resubmit a much improved paper. Full details are below.
Changes in RProtoBuf version 0.4.2 (2014-12-10)
  • Address changes suggested by anonymous reviewers for our Journal of Statistical Software submission.
  • Make Descriptor and EnumDescriptor objects subsettable with "[[".
  • Add length() method for Descriptor objects.
  • Add names() method for Message, Descriptor, and EnumDescriptor objects.
  • Clarify order of returned list for descriptor objects in as.list documentation.
  • Correct the definition of as.list for EnumDescriptors to return a proper list instead of a named vector.
  • Update the default print methods to use cat() with fill=TRUE instead of show() to eliminate the confusing [1] since the classes in RProtoBuf are not vectorized.
  • Add support for serializing function, language, and environment objects by falling back to R's native serialization with serialize_pb and unserialize_pb to make it easy to serialize into a Protocol Buffer all of the more than 100 datasets which come with R.
  • Use normalizePath instead of creating a temporary file with file.create when getting absolute path names.
  • Add unit tests for all of the above.
CRANberries also provides a diff to the previous release. RProtoBuf page which has a draft package vignette, a a 'quick' overview vignette, and a unit test summary vignette. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

30 April 2014

Mirco Bauer: Smuxi 0.11 "Distractions" Release

And here we go again! We're proud to announce the new version of Smuxi, release 0.11 "Distractions". During the development, 11 bug reports and 2 feature requests in 112 commits were worked on. Notable highlights in this release are:

User Interface Enhancements
  • The chat list can be shrunken. This is especially handy with XMPP/Jabber and long group chat identifiers.
  • The highlight counter is now a separate column. This enhances the vertical alignment with other highlights and guarantees to be visible even if the chat name was truncated.

Multi Identity Support Smuxi cares for user feedback. Multi identity support was the most voted feature and thus it has been implemented! Now you can please your schizo^Wdesire to use different nicks, users and real names depending on the server. Simply edit the server in preferences and change the details.

Message Patterns Everybody knows text can be boring because it is all just text. Nothing can sidetrack you except reading that bare text. Text often has recurring patterns from which something useful and interactive can be created. For example, someone writes:
Hey meebey, do you know RFC2812?
RFCs are a recurring pattern with a distinct number behind it and are real references to something in the internet (collection of protocol specifications). So I would usually fire up a browser tab, copy/paste or type RFC2812 into my favorite search engine and click the first hit. Then I'd reply to the question afterwards. But with Smuxi's message patters, it turns RFC2812 into a link on which you can simply click to launch the relevant document. Wow this is very cool, but isn't this already happening with http URLs and email addresses? Exactly! Why shouldn't more information be used to create useful things from it? Smuxi message patterns allow you to define text patterns that are transformed into clickable links. This can be used for RFCs, CVEs, bug report numbers (#XXX), git commit hashes and much more. Make good use of your creativity! By default Smuxi comes with built-in message patterns for:
  • URLs
  • heuristic URLs (not starting with http:// etc)
  • email addresses
  • RFCs
  • CVEs
  • Debian Security Advisories (DSA)
  • Many popular bug trackers (GNU, GCC, kernel, Launchpad, freedesktop, GNOME, KDE, Xfce, Debian, Redhat, Novell, Xamarin, openSUSE, Mozilla, Samba, SourceForge, CPAN, boost, Claws and Smuxi)
If you know more general patterns useful for others, please submit them. For a full list of built-in message patterns or how to add your own patterns, head over to the message pattern documentation.

Hooks Enhancements
  • A bug was fixed that prevented hooks from issuing more than one command
  • New hook points:
    • engine/session/on-group-chat-person-added
    • engine/session/on-group-chat-person-removed
    • engine/session/on-group-chat-person-updated
  • New hook variables:
    • CMD
    • CMD_PARAMETER
    • CMD_CHARACTER
    • PROTOCOL_MANAGER_PRESENCE_STATUS: Unknown, Offline, Online, Away

Twitter Enhancements As of 14 Jan 2014, Twitter disallows unencrypted HTTP requests which broke Smuxi's Twitter support. Smuxi is now making exclusively encrypted requests (HTTPS) and thus works with Twitter again.

JabbR (Beta) Enhancements
  • Messages now raise Smuxi hooks
  • The Validate certificate setting is now correctly honored.

Updated Translations Smuxi should now be in your language, including:
  • Initial complete Dutch (Jeroen Baten)

Behind the Scenes
  • New Smuxi git repository @ GNOME
  • Cleaner XMPP code (Oliver Schneider)
  • Smuxi's STFL text frontend is doing a graceful shutdown on quit (Calvin B))
  • New sexy website! We hope you like it :)

Contributors Contributors to this release are the following people:
  • Mirco Bauer (98 commits)
  • Oliver Schneider (6 commits)
  • Calvin B (6 commits)
  • Andr s G. Aragoneses (1 commit)
  • Jeroen Baten (translations)
Thank you very much for your contributions to Smuxi! Want it? Go here and grab it right now!

Posted Mon Apr 14 13:23:29 2014

20 January 2014

Dirk Eddelbuettel: RProtoBuf 0.4.0: A whole lot of goodies and Windoze support

A new major release 0.4.0 of RProtoBuf, is now on CRAN. RProtoBuf provides GNU R bindings for the Google Protocol Buffers ("Protobuf") data encoding library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects. With this release, we are welcoming Jeroen Ooms to the team. Jeroen had already worked on some RProtoBuf extensions in the context of his OpenCPU project; we have now integrated those Protocol Buffers functions. And Jeroen pushed all the right buttons to finally get RProtoBuf built on everybody's least-favourite operating system by provding a static library for use by win-builder and CRAN. Murray once again did a lot of work on internals. His use of the LLVM tool llvm-format was particular helpful to make our coding style a little more consistent. The complete NEWS file entry for this release follows:
Changes in RProtoBuf version 0.4.0 (2014-01-14)
  • Changes to support CRAN builds for MS Windows.
  • Added functions serialize_pb, unserialize_pb, and can_serialize_pb plus documentation from Jeroen Ooms RProtoBufUtils package.
  • New dir inst/python with some Python examples.
  • Added Jeroen Ooms as author.
  • Vignettes have been converted to the R 3.0.0 or later use of external vignette builders, no longer need a Makefile
  • Added missing methods to dollar completion list for Message, Descriptor, EnumValueDescriptor, and FileDescriptor classes.
  • Add missing export for .DollarNames EnumValueDescriptor to allow completion on that class.
  • Add more than 15 additional pages to the main Intro vignette documenting better all of the S4 classes implemented by RProtoBuf, updating the type mapping tables to take into account 64-bit support, and documenting advanced features such as Extensions.
  • Added better error checking in EnumDescriptors to catch the case when wrong types are provided.
  • Updated the FileDescriptor name() method to accept a boolean for full paths just like the generic name() method.
  • Correct a bug that incorrectly dispatched as.character() when as.list() was called on Descriptor objects.
  • Update FileDescriptor $ dispatch to work properly for the names of fields defined in the FileDescriptor, instead of just returning NULL even for types returned by $ completion.
  • Added a reservation for extension fields in the example tutorial.Person schema.
  • Support setting int32 fields with character representations and raise an R-level stop() error if the provided string can not be parsed as a 32-bit integer, rather than crashing the R instance.
  • Update the project TODO file.
  • Add better documentation and tests for all of the above.
  • Corrected the handling of uint32 and fixed32 types in protocol buffers to ensure that they work with numbers as large as 2^32 - 1, which is larger than an integer can hold in R since R does not have an unsigned integer class. These values are stored as doubles internally now to avoid losing precision.
  • Added unit tests to verify behavior of RProtoBuf with extreme values for uint32 types.
  • Removed old exception handling code and instead rely on the more modern Rcpp::stop method maintained in Rcpp.
  • Add better error messages when setting a repeated field of messages to inform the user which element index was of the wrong type and what the expected type was.
  • Add an optional 'partial' argument to readASCII allowing uninitialized message fragments to be read in.
  • (internal) Added const qualifiers in more places throughout the C++ code for type safety.
  • (internal) Standardize coding conventions of the C++ files and run them through clang-format for consistency. A STYLE file has been submitted to R-Forge with details about the coding standards and how they are enforced with Emacs and clang-format.
  • Applied changes suggested by Kevin Ushey to the S4 class handling to support both the currently released Rcpp as well as the currently pending next version.
CRANberries also provides a diff to the previous release 0.3.2. More information is at the RProtoBuf page which has a draft package vignette, a 'quick' overview vignette and a unit test summary vignette. Questions, comments etc should go to the rprotobuf mailing list off the RProtoBuf page at R-Forge.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

31 August 2013

Christian Perrier: DebConf 13: hacking outcome

I *did* some hacking at DebConf, as usual. For once, I had no TODO list: after all, I never complete these, so why make one? Still, I participated to discussions around samba packaging, mostly animated by Ivo De Decker and I think we're making good progress towards samba 4.x packages. The road is long, quite complicated, but we now have a stronger team, with a very active Ivo, Jeroen Dekkers who officially joined, Steve Langasek who still cherishes one of his pet packages (and even branched in our git with the Ubuntu packages). Great work and thanks to Ivo for pushing this forward. I also worked quite actively on the migration of fonts packages to git (I now reached the point where I'm more comfortable with git than SVN, yes, everything can happen). These packages were modernized at the same time and checked for new upstream versions (I have to say that few of these fonts had new upstream versions, indeed). We unfortunately found no time to have a good font BoF in Vaumarcus, indeed...but I'm not sure we would have many things to say. The work is done and done well, in this team. Some progress was made, also, for restoring a working "monolithic" build of D-I. This build gathers together all udebs from unstable, which means it offers a D-I image that uses ALL udebs from nustable.....which is not the default of other images. This would be very helpful for translators who want to check their work as soon as possible. In the future, with a Jenkins task that would build each package at each commit and then build a monolithic image, we could have a way to provide a tes snapshot of D-I git repos.....which could help catching more bugs (or more of my stupid mistakes). So, in general, I consider this a quite successful DebConf when it comes at "real" production.

23 March 2012

Raphaël Hertzog: People behind Debian: J rg Jaspert, FTPmaster, Debian Account Manager, and more

Photo by Wouter Verhelst

J rg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones) Better known as Ganneff (his IRC nick), he s not exactly the typical hacker. He has no beard and used to drink milk instead of beers. :-) Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager. Raphael: Who are you? J rg: My name is J rg Jaspert and I m 35 years old working for a small company doing system administration and consulting work for our customers. I m married for a little while now and sometime soon a little Ganneff will be crawling out of my wife. (Whoever didn t think of the movie Alien now is just boring). Raphael: How did you start contributing to Debian? J rg: I started using Debian somewhere around 2000, 2001. Before that I had the misfortune to try SuSE and RedHat, both with a user experience that let me fully understand why people think Linux is unusable. (Due to my work I m in the unfortunate situation to have to use RedHat on two machines. Funny how they are still utter crap and worse than bad toys). And all of this lets get a Linux running here came up because I was trying to find a replacement for my beloved OS/2 installation, which I had for some years. So after I got Debian installed, good old Potato, I got myself active on our mailing lists, starting with the German user one. A bit later I replied to a question if someone can help as staff for a Debian booth somewhere. It was the most boring event I ever visited (very nice orga, unfortunately no visitors), but I got a few important things there: The software I packaged, found me a sponsor and voila, maintainer I was. Some more packages got added and at some point my sponsor turned out to be my advocate. The NM process run around 2 months, and mid April 2002 I got THE MAIL. Raphael: Some Debian developers believe that you have too many responsibilities within Debian (DAM, FTPMaster, Debconf, Partners, Planet Debian, Mirrors, ). Do you agree that it can be problematic, and if yes, are you trying to scale down? J rg: It s DebConf, tssk. And yes, I do have some extra groups and roles. And you even only list some, leaving out all I do outside Debian. But simply counting number of roles is a plain stupid way to go. Way more interesting is how much work is behind a role and how many other people are involved. And looking at those you listed I don t see any I am a SPOF. Let s look at those you listed: DAM: Here I did start out assisting James to get the huge backload down which had accumulated over time. Nowadays I am merely the one with the longest term as DAM. Christoph Berg joined in April 2008 and Enrico Zini followed during October 2010, both very active. Especially Enrico, lately with the redesign of the NM webpages. FTPMaster: The basic outline of the FTPMaster history is similar to the DAM one. I joined as an assistant, after the oh-so-famous Vancouver meeting in 2004. Together with Jeroen, we both then got the backload down which had accumulated there. He did most of the removals while I had a fun time cleaning up NEW. And we both prepared patches for the codebase. And in 2007, as the last action as DPL, Sam made me FTPMaster. Since then I haven t been alone either. In fact we have much more rotation in the team than ever before, which is a good thing. Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee. Though we always like new blood and would welcome more volunteers. DebConf: I am very far outside the central DebConf team. I am not even a delegate here. Currently I am merely an admin, though there are 4 others with the same rights on the DebConf machines. I ve not taken any extra jobs this year, nor will I. Probably for next year again, but not 2012. Planet: I am one of three again, but then Planet is mostly running itself. Debian developers can just edit the config, cron is doing the work, not much needed here. Occasional cleanups, every now and then a mail to answer, done. In short: No real workload attached. Mirrors: My main part here is the ftpsync scriptset. Which is a small part of the actual work. The majority of it, like checking mirrors, getting them to fix errors, etc. is done by Simon Paillard (and since some time, Raphael Geissert is active there too, you might have heard about his http.debian.net). Having said that, there is stuff I could have handled better or probably faster. There always is. Right now I have 2 outstanding things I want to do a (last) cleanup on and then give away. Raphael: You got married last year. I know by experience that entertaining a relationship and/or a family takes time. How do you manage to combine this with your Debian involvement? J rg: Oh well, I first met my wife at the International Conference on OpenSource 2009 in Taiwan. So OpenSource, Debian and me being some tiny wheel in the system wasn t entirely news to her. And in the time since then she learned that there is much more behind when you are in a community like Debian, instead of just doing it for work. Even better that she met Debian people multiple times already, and knows with who I am quarreling Also, she is currently attending a language school having lots of homework in the evening. Gives me time for Debian stuff. :) How that turns out with the baby I have no idea yet. I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject), but it might take a day or twenty before it gets so far. :) Raphael: Thanks to the continuous work of many new volunteers, the NEW queue is no longer a bottleneck. What are the next challenges for the FTPmaster team? J rg: Bad link, try this one. :) Also, no longer sounds like its recent. It s not, it s just that people usually recognize the negative only and not the positive parts. Well, there are a few challenges actually. The first one, even if it sounds simple, is an ongoing one: We need Debian Developers willing to do the work that is hidden behind those simple graphs. Yes, we are currently having a great FTP Team doing a splendid work in keeping that queue reasonably small this is a/THE sisyphean task per excellence. There will always be something waiting for NEW, even if you just cleaned the queue, you turn around and there is something else back in already. Spreading this workload to more people helps not burning one out. So if one or more of the readers is interested, we always like new volunteers. You simply need to be an uploading DD and have a bit of free time. For the rest we do have training procedures in place. Another one is getting the multi-archive stuff done. The goal is to end up with ONE host for all our archives. One dak installation. But separate overrides, trees, mirrors, policies and people (think RMs, backports team, security team). While this is halfway easy to think of in terms of merging backports into main it gets an interesting side note when you think of merging security into main . The security archive does have information that is limited to few people before public release of a security announce, and so we must make sure our database isn t leaking information. Or our filesystem layer handling. Or logs. Etc. Especially as the database is synced in (near) realtime to a DD accessible machine. And the filesystem data too, just a little less often. There is also a discussion about a good way to setup a PPA for Debian service. We do have a very far developed proposal here how it should work, and I really should do the finishing touches and get it to the public. Might even get a GSoC project on it. So far for some short to middle term goals. If you want to go really long term, I do think that we should get to the point where we get rid of the classical view of a source package being one (or more) tarballs plus the Debian changes. Where a new version requires the full upload of one or more of those parts of the source package. I don t know exactly where it should end up. Sure, stuff like one central DVCS, maintainers push there, the archive generates the source tarballs and prepares the mirrors do sound good for a quick glance. But there are lots of trouble and pitfalls and probably some dragons hidden here. Raphael: The Debian repositories are managed by DAK (Debian Archive Kit) which is not packaged. Thus Debian users pick tools like reprepro to manage their package repositories. Is that how things should be? J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does, though yes, DAK is not exactly a quick-and-easy thing to install. But nowadays it is a trillion times easier than the past thanks to Mark s work people can now follow the instructions, scripts and whatever they find inside the setup directory. Still, it really depends on the archive size you are managing. A complex tool like dak does not make sense for someone who wants to publish one or a dozen of his own packages somewhere. Thats just like doing a finger amputation with a chainsaw it certainly works and is fun for the one with the chainsaw but you probably end up a little overdoing it. I myself am using dpkg-scan[packages sources] from a shell script but also mini-dinstall in places (never got friend with reprepro when I looked at it). Works, and for the few dozen packages those places manage it is more than enough. Also, using dak forces you into some ways of behaviour that are just what Debian wants but might not be what a user wants. Like inability to overwrite an existing file. One of the reasons why mentors.debian.net won t work with dak. Or the use of a postgres database. Or that of gpg. Sure, if you end up having more than just a dozen packages, if you have many suites and also movement between them, then dak is sure a thing to look at. And how should things be : however the user and admins of that certain install of reprepro, mini-dinstall, dak, whatever want it. This is not one-tool-for-all land :) Raphael: What is the role of Debian Account Managers (DAM)? Do you believe that DAMs have a responsibility to shape Debian by defining limits in terms of who can join and what can be done within Debian? J rg: Quote from https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:
The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.
Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it s our job. We usually aren t quick about it. And we don t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The expulsion procedure , luckily not invoked that often, does guarantee a slow process and lots of input from others. Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby Debian. We aren t trained in dealing with the situations that can come up. But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us. Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you re still bitter about? J rg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Or my current job. Or a GR against me. Not many running around with that badge, though I m still missing my own personal Serious problems with Mr. Jaspert thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD. Raphael: Is there someone in Debian that you admire for their contributions? J rg: Yes.
Thank you to J rg for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

One comment Liked this article? Click here. My blog is Flattr-enabled.

28 January 2012

Bartosz Feński: dibbler 0.8.1

Can t believe its almost 7 years since my first sponsored upload of Dibbler to Debian archive. I did it cause upstream promised to maintain it and fix any bugs submitted by Debian users. Unfortunately after 3-4 years he stopped to do it. Well since I was the sponsor of it, then I should feel responsible for these packages after him. It s quite hard to do it, cause I m not using these packages at all ;) Anyway, I finally found some time and reviewed them. It wasn t easy cause in the meantime whole build process totally changed. To whom it may concern: Dibbler is an IPv6 DHCP client, relay and server. I ve just uploaded the newest upstream version. Changelog follows: dibbler (0.8.1-1) unstable; urgency=low * ACK previous NMUes thanks!
* New upstream version (Closes: #629685)
uses correct example adsress pool in examples (Closes: #544323)
corrects scope of stateless in manpage (Closes: #615165)
* Fix pending l10n issues. Debconf translations:
Danish courtesy of Joe Hansen (Closes: #597767)
Dutch courtesy of Jeroen Schot (Closes: #632628)
* Fixes handling of children processes using resolvconf (Closes: #627317)
* Doesn t conflict with other resolver configuration daemons (Closes: #627786)
* Correctly handles multiselect values from debconf (Closes: #629681)
* Debianized almost from scratch, uses new source format.
* New Standards-Version (no changes needed). Bartosz Fenski <fenio> Fri, 27 Jan 2012 14:37:13 +0100 Yep, it fixes 8 bugs, and brings the newest upstream version with huge number of new features to Debian. Enjoy!

18 January 2012

Christian Perrier: Zou....Italian (and Danish, and Dutch....) take off!

The increasing storm of localization NMUs and uploads, related to debconf translations, has an interesting effect: some teams are now incredibly active at pushing translations for their language towards the magic 100%. So, after Danish (effort lead by Joe Hansen) and Dutch (effort lead by Jeroen Schot) which I already mentioned, it seems that the Italian localization team started engines and is now taking off. It will be interesting to watch these teams competing (in a friendly way) to climb in statistics over next months..:-) So, if you're Italian (or speak it well) and want to help, please join the Italian l10n mailing list (debian-l10n-italian on lists.debian.org. If you're Danish or Dutch and want to stay ahread the two others, please joind debian-l10n-danish or debian-l10n-dutch. PS: why did I write "Zou" in this post's title? Because this is a common French interjection for "Whoooosh" and because this is part of the nickname of the tireless and incredibly active, in many places, Francesca Ciceri, aka MadameZou, who's is doing so much for Italian localization (and many other areas in Debian such as the publicity and web team). And that really deserves some lights, trumpets, etc.

7 January 2012

Christian Perrier: Towards 100% in wheezy for debconf translations

This article could become one of my recurring "let's make noise about translators work" articles. You've been warned. In Squeeze, a few languages reached full completion of debconf strings, those "questions" that are asked during packages installation or upgrades. This can be followed here (for unstable: we don't have an online status page for testing).. Many of you, particularly those who aren't bored at reading me, know that I like pushing this friendly "competition" as a good way to encourage progress in localization of that part of Debian. As of now, we have really good and active teams that are able to maintain a great completion in this. Several of them are likely to reach full 100% completion for wheezy. Let's look at the current status: I hope this maybe gave you the idea of joining these efforts. Please pop up on one of the i18n mailing lists if you're interested, and if you don't know where to start, then debian-i18n< is what you're looking for. See you soon!

13 March 2011

Lars Wirzenius: DPL elections: candidate counts

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.
Year Count Names
1999 4 Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000 4 Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001 4 Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002 3 Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003 4 Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004 3 Martin Michlmayr, Gergely Nagy, Branden Robinson
2005 6 Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006 7 Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007 8 Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008 3 Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009 2 Stefano Zacchiroli, Steve McIntyre
2010 4 Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011 1 Stefano Zacchiroli (no vote yet)
Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

Next.