[Rcpp-devel] Rcpp 0.8.3 and those other operating systems

| The lme4a package currently depends on Rcpp_0.8.3 and uses some
| "sugar" constructions - but only in a few places and I could replace
| those with explicit loops or calls to std::transform fairly easily.
| 
| I see that Rcpp_0.8.3 is available on CRAN as the source code package
| but the Windows and OS X binaries are still at 0.8.2
| 
| Furthermore the nightly R-forge builds of lme4a are failing on Windows
| and OS X when they hit a sugar construction.
| 
| Would I be well-advised to back out the use of Rcpp sugar if I want to
| have a package available for the tutorial preceding useR!2010?  It is
| not a big deal to do that but still it is something I would prefer to
| avoid if Windows and Mac OS X builds of 0.8.3 are just around the
| corner.

That's a somewhat complicated issue right now, but hopefully not for long.

"Sugar" started really only good post-0.8.2. And with the Rmetrics meeting
coming up, and a larger than usual set of changes, we released 0.8.3 right
before that meeting. At the time Rcpp passed on all systems we could test on.
We do nto release when we know of failures. [ Hint: If only we already had
"bin-builder" ... ].

But once released, it turned out that Solaris didn't build, and that OS X
failed with ppc (we couldn't test that, as we have x86 only). And worst of
all, Uwe is getting tired of the odd and still unexplained build issues on
'doze and has pushed us to the back of the bus.  So that means we lack Win,
OS X, Solaris.  Mind you even though it builds almost everywhere, but because
we have an obsessively large number of unit tests, something sometimes breaks
somewhere. I think I just fixed something for Windoze related to Dates and a
Windows braindeadness. And we're working on bulk compiles for the tests so
that we no longer run up against Uwe's time limit.

Now, you seem to define "ready" as "being used on R-Forge" and that depends
on the binaries -- which aren't there for the reasons discussed above.

We may get 0.8.4 out in a bit.  We probably want that befoer useR! ourselves.
But whether that migrates through to give you your packages -- dunno.

At the end of the day, maybe you just have to dive in and build lme4a and
Rcpp locally. I presume you only really need two types of binaries, win32 and
OS X/x86. Can you just do those and have people install off a web page / ftp
site?

Regards, Dirk

On 6 July 2010 at 11:11, Douglas Bates wrote:
| The lme4a package currently depends on Rcpp_0.8.3 and uses some
| "sugar" constructions - but only in a few places and I could replace
| those with explicit loops or calls to std::transform fairly easily.
|
| I see that Rcpp_0.8.3 is available on CRAN as the source code package
| but the Windows and OS X binaries are still at 0.8.2
|
| Furthermore the nightly R-forge builds of lme4a are failing on Windows
| and OS X when they hit a sugar construction.
|
| Would I be well-advised to back out the use of Rcpp sugar if I want to
| have a package available for the tutorial preceding useR!2010? ?It is
| not a big deal to do that but still it is something I would prefer to
| avoid if Windows and Mac OS X builds of 0.8.3 are just around the
| corner.

That's a somewhat complicated issue right now, but hopefully not for long.

"Sugar" started really only good post-0.8.2. And with the Rmetrics meeting
coming up, and a larger than usual set of changes, we released 0.8.3 right
before that meeting. At the time Rcpp passed on all systems we could test on.
We do nto release when we know of failures. [ Hint: If only we already had
"bin-builder" ... ].

But once released, it turned out that Solaris didn't build, and that OS X
failed with ppc (we couldn't test that, as we have x86 only). And worst of
all, Uwe is getting tired of the odd and still unexplained build issues on
'doze and has pushed us to the back of the bus. ?So that means we lack Win,
OS X, Solaris. ?Mind you even though it builds almost everywhere, but because
we have an obsessively large number of unit tests, something sometimes breaks
somewhere. I think I just fixed something for Windoze related to Dates and a
Windows braindeadness. And we're working on bulk compiles for the tests so
that we no longer run up against Uwe's time limit.

Now, you seem to define "ready" as "being used on R-Forge" and that depends
on the binaries -- which aren't there for the reasons discussed above.

We may get 0.8.4 out in a bit. ?We probably want that befoer useR! ourselves.
But whether that migrates through to give you your packages -- dunno.

At the end of the day, maybe you just have to dive in and build lme4a and
Rcpp locally. I presume you only really need two types of binaries, win32 and
OS X/x86. Can you just do those and have people install off a web page / ftp
site?

That is a reasonable suggestion if i were willing to mess around with
Windows long enough to install the tools for building packages, etc.
However, my patience for working on Windows runs out after about 5
minutes and I think it will be easier on computers and people near me
if I just create a version of lme4a that will compile against
Rcpp_0.8.2.

You see I work on Ubuntu or Debian systems all the time and there is
this marvelous guy named Dirk who makes it so simple to install the
packages and the build environment etc. there that i am rather
spoiled. :-)

--
?Regards, Dirk

| >

| > | The lme4a package currently depends on Rcpp_0.8.3 and uses some
| > | "sugar" constructions - but only in a few places and I could replace
| > | those with explicit loops or calls to std::transform fairly easily.
| > |
| > | I see that Rcpp_0.8.3 is available on CRAN as the source code package
| > | but the Windows and OS X binaries are still at 0.8.2
| > |
| > | Furthermore the nightly R-forge builds of lme4a are failing on Windows
| > | and OS X when they hit a sugar construction.
| > |
| > | Would I be well-advised to back out the use of Rcpp sugar if I want to
| > | have a package available for the tutorial preceding useR!2010? ?It is
| > | not a big deal to do that but still it is something I would prefer to
| > | avoid if Windows and Mac OS X builds of 0.8.3 are just around the
| > | corner.
| >
| > That's a somewhat complicated issue right now, but hopefully not for long.
| >
| > "Sugar" started really only good post-0.8.2. And with the Rmetrics meeting
| > coming up, and a larger than usual set of changes, we released 0.8.3 right
| > before that meeting. At the time Rcpp passed on all systems we could test on.
| > We do nto release when we know of failures. [ Hint: If only we already had
| > "bin-builder" ... ].
| >
| > But once released, it turned out that Solaris didn't build, and that OS X
| > failed with ppc (we couldn't test that, as we have x86 only). And worst of
| > all, Uwe is getting tired of the odd and still unexplained build issues on
| > 'doze and has pushed us to the back of the bus. ?So that means we lack Win,
| > OS X, Solaris. ?Mind you even though it builds almost everywhere, but because
| > we have an obsessively large number of unit tests, something sometimes breaks
| > somewhere. I think I just fixed something for Windoze related to Dates and a
| > Windows braindeadness. And we're working on bulk compiles for the tests so
| > that we no longer run up against Uwe's time limit.
| >
| > Now, you seem to define "ready" as "being used on R-Forge" and that depends
| > on the binaries -- which aren't there for the reasons discussed above.
| 
| > We may get 0.8.4 out in a bit. ?We probably want that befoer useR! ourselves.
| > But whether that migrates through to give you your packages -- dunno.
| 
| > At the end of the day, maybe you just have to dive in and build lme4a and
| > Rcpp locally. I presume you only really need two types of binaries, win32 and
| > OS X/x86. Can you just do those and have people install off a web page / ftp
| > site?
| 
| That is a reasonable suggestion if i were willing to mess around with
| Windows long enough to install the tools for building packages, etc.
| However, my patience for working on Windows runs out after about 5
| minutes and I think it will be easier on computers and people near me
| if I just create a version of lme4a that will compile against
| Rcpp_0.8.2.

I have a working Windows setup at work (for various definitions of
working). If we define a snapshot, I could wrap up a package for you.
 
| You see I work on Ubuntu or Debian systems all the time and there is
| this marvelous guy named Dirk who makes it so simple to install the
| packages and the build environment etc. there that i am rather
| spoiled. :-)

:-)  

I work in that environment too, most of the time.

Regards, Dirk

"Sugar" started really only good post-0.8.2. And with the Rmetrics meeting
coming up, and a larger than usual set of changes, we released 0.8.3 right
before that meeting. At the time Rcpp passed on all systems we could test
on.
We do nto release when we know of failures. [ Hint: If only we already had
"bin-builder" ... ].

I think you mean win-builder (http://win-builder.r-project.org/), and yes,
using
this service as part of integration testing before releasing to CRAN will
reduce
the number of problems for client packages that use Rcpp. 1000 unit tests
will
not help. Indeed, this should be required given that you do not use or test
under Windows, yet there are many Windows users.

It would also be helpful if you inform the authors of client packages before
releasing duplicate functionality that will break the build for these
packages (Rcpp 0.8.3 broke the build of cxxPack). This incompatibility
was known, yet was released.

Dominick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100706/72602e8a/attachment.htm>

Le 06/07/10 19:23, Dominick Samperi a ?crit :

On Tue, Jul 6, 2010 at 12:44 PM, Dirk Eddelbuettel <edd at debian.org
<mailto:edd at debian.org>> wrote:

    "Sugar" started really only good post-0.8.2. And with the Rmetrics
    meeting
    coming up, and a larger than usual set of changes, we released 0.8.3
    right
    before that meeting. At the time Rcpp passed on all systems we could
    test on.
    We do nto release when we know of failures. [ Hint: If only we
    already had
    "bin-builder" ... ].


I think you mean win-builder

No, that is not what Dirk meant. We are already quite aware of win 
builder and we send packages there very very often.

It only helps for windows, so "bin builder" would be something more 
general.

(http://win-builder.r-project.org/), and
yes, using
this service as part of integration testing before releasing to CRAN
will reduce
the number of problems for client packages that use Rcpp. 1000 unit
tests will
not help.
Indeed, this should be required given that you do not use or test
under Windows, yet there are many Windows users.

This is just plain wrong. We do test on windows. We obviously want it to 
work on windows.

It would also be helpful if you inform the authors of client packages before
releasing duplicate functionality that will break the build for these
packages (Rcpp 0.8.3 broke the build of cxxPack). This incompatibility
was known, yet was released.

Dominick

You cannot claim that we don't advise you of things, as we have done it 
before.

As I said to you privately, releasing this version was higher on our 
(mainly mine) priority list because I wanted to demonstrate the released 
version. I though I had time to alert you but my time has been sinked by 
the conference, and the wireless connection was not all that good.

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

Le 06/07/10 18:11, Douglas Bates a ?crit :

The lme4a package currently depends on Rcpp_0.8.3 and uses some
"sugar" constructions - but only in a few places and I could replace
those with explicit loops or calls to std::transform fairly easily.

I see that Rcpp_0.8.3 is available on CRAN as the source code package
but the Windows and OS X binaries are still at 0.8.2

Furthermore the nightly R-forge builds of lme4a are failing on Windows
and OS X when they hit a sugar construction.

Would I be well-advised to back out the use of Rcpp sugar if I want to
have a package available for the tutorial preceding useR!2010?  It is
not a big deal to do that but still it is something I would prefer to
avoid if Windows and Mac OS X builds of 0.8.3 are just around the
corner.

The svn version of Rcpp works on windows (at least on my copy).

As Dirk said, we do definitely want Rcpp 0.8.4 before useR, preferably 
before the end of this week.

I'm not sure why it does not work on the ppc arch on OSX, we might be 
using a compiler feature that was introduced after moving to intel ... I 
need to have a closer look and perhaps involve the r-sig-mac list.

solaris is something else entirely. We might need more iterations.

Romain

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

(http://win-builder.r-project.org/), and

yes, using
this service as part of integration testing before releasing to CRAN
will reduce
the number of problems for client packages that use Rcpp. 1000 unit
tests will
not help.
Indeed, this should be required given that you do not use or test
under Windows, yet there are many Windows users.

This is just plain wrong. We do test on windows. We obviously want it to
work on windows.

Good to know. This was hard to see given the dismissive comments about
Windows made
earlier in this thread.

As I said to you privately, releasing this version was higher on our
(mainly mine) priority list because I wanted to demonstrate the released
version. I though I had time to alert you but my time has been sinked by the
conference, and the wireless connection was not all that good.

Are you prepared to make Dirk's assurance more precise by stating that in
the future
releases will not be done if known incompatibilities are introduced with
client packages
that will cause the build of those client packages to fail? You are of
course free to set your
priorities as you see fit, but client package authors need to understand
these priorities.

Thanks,
Dominick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100706/dd51ebc6/attachment.htm>

Le 06/07/10 20:54, Dominick Samperi a ?crit :

On Tue, Jul 6, 2010 at 2:07 PM, Romain Francois
<romain at r-enthusiasts.com <mailto:romain at r-enthusiasts.com>> wrote:

        (http://win-builder.r-project.org/), and
        yes, using
        this service as part of integration testing before releasing to CRAN
        will reduce
        the number of problems for client packages that use Rcpp. 1000 unit
        tests will
        not help.
        Indeed, this should be required given that you do not use or test
        under Windows, yet there are many Windows users.


    This is just plain wrong. We do test on windows. We obviously want
    it to work on windows.

Good to know. This was hard to see given the dismissive comments about
Windows made
earlier in this thread.

I don't like windows at all, but people seem to use it.

    As I said to you privately, releasing this version was higher on our
    (mainly mine) priority list because I wanted to demonstrate the
    released version. I though I had time to alert you but my time has
    been sinked by the conference, and the wireless connection was not
    all that good.


Are you prepared to make Dirk's assurance more precise by stating that
in the future
releases will not be done if known incompatibilities are introduced with
client packages
that will cause the build of those client packages to fail?

no. see this in about every single file:

// Rcpp is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.

You are of
course free to set your
priorities as you see fit

how nice of you

but client package authors need to understand
these priorities.

no comment ... not even a sarcasm

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

no. see this in about every single file:

// Rcpp is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.

OK, then Dirk should not make false promises that give potential
clients a false sense that you will actually behave responsibly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100706/9be088f0/attachment.htm>

And worst of
all, Uwe is getting tired of the odd and still unexplained build issues on
'doze and has pushed us to the back of the bus.

This explains why the Windows builds are being delayed (Uwe is responsible
for Windows builds), but this does not explain why the Linux builds (other
than
Fedora) are being delayed. Is there a problem with Debian and other Linux
builds? I was under the impression that the process is automated, and it
normally
happens within one day.

Dominick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100706/292f9d91/attachment-0001.htm>

Dominick, wtf?

Rcpp is on one of the most rapid development cycles that I've ever
seen.  If you want stability, then why don't you wait about six more
months before you start using Rcpp in your projects.

Alternatively, you can easily center your package on a particular
version by enclosing your preferred version of Rcpp inside of your
package.  git submodules make this task particularly easy:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules.

We c++ users are very lucky that Romain and Dirk are making it so easy
to use c++ within R.  Please don't lose sight of the larger picture
because a few builds break every now and then.

-Whit

On Tue, Jul 6, 2010 at 3:04 PM, Romain Francois <romain at r-enthusiasts.com>
wrote:

no. see this in about every single file:

// Rcpp is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
// GNU General Public License for more details.

OK, then Dirk should not make false promises that give potential
clients a false sense that you will actually behave responsibly.

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel at lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Rcpp is on one of the most rapid development cycles that I've ever
seen.  If you want stability, then why don't you wait about six more
months before you start using Rcpp in your projects.

I have been using the Rcpp library in my projects since 2005 when I
created it (see CRAN package page for cxxPack / Old sources / Ancestry).
I agree that the pace of development for what is now known as the Rcpp
project increased dramatically after November of 2009, immediately after
I released a major update to the Rcpp library (in RcppTemplate package).
See the README file from Rcpp 0.8.3, which was created after my update,
for additional information.

For this reason and to prevent wasteful duplication of effort I
decided to standardize on this work. Thus RcppTemplate became
cxxPack.

Thanks,
Dominick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100707/13f9fe96/attachment.htm>