similar to: The next Wine Bug Day will be this Sunday, August 16

Scott Ritchie wrote: > So, briefly: > > Over the past few months, users have added an average of between 12 and > 14 bugs every day. > > Since June 1st: > - 412 total bugs filed > - 87 bugs resolved invalid > - 227 bugs resolved fixed > - 133 bugs confirmed but not resolved (status new) > - 292 bugs created but unconfirmed > > Doing some subtraction that

I've uploaded my 1.1.28 packages for Ubuntu (9.04 is already built, 8.10 and 8.04 are still building as I write this). One of the fixes in this package is to build with support for libgsm, a new feature in Wine that allows Ventrillo support. However, this will only work on 32-bit Ubuntu at this time, as there is no 32 bit version of this library available on Ubuntu 64. I've already

On Sunday, August 18, 2013, the Asterisk community services listed below may have intermittent availability due to network maintenance. This maintenance will begin at approximately 2:00 PM CDT[1] and should last no longer than two hours. The affected services are: * All community services provided by Digium, including, but not limited to: * bamboo.asterisk.org * code.asterisk.org *

Tomorrow, Sunday, community services may have intermittent availability due to maintenance. This maintenance will begin at approximately 2:00 PM CDT[1] and should be complete before 8:00 PM CDT. The affected services include at least: * git.asterisk.org * issues.asterisk.org * crowd.asterisk.org * downloads.asterisk.org * downloads.digium.com * packages.asterisk.org * asterisknow.asterisk.org

Hi Scott, I think that's a good idea and I tried your patch on my copy of the repository. But it looks to me like the recent patch is identical to the previous one, can you confirm this? Frederick On Mon, Feb 19, 2018 at 07:19:32AM +1100, Scott Ritchie wrote: > Thanks Gabriel, > > I think your suggested approach is 100% backwards compatible > > Currently in the case of

It seems like there is a way that is backwards compatible-ish in the sense mentioned and still has the (arguably, but a good argument I think) better behavior: if by.x is 'name', (AND by.y is not also 'name'), then x's 'name' column is called name and y's 'name' column (not used int he merge) is changed to name.y. Now of course this would still change

Anyone know what I'm doing wrong here? I'm following the instruction here: http://www.winehq.org/download/deb, but when I try to add the repository's key to your system's list of trusted APT keys I get the error "invalid packet". TIA -Adam ======================================== adam at linnorm:~/downloads$ cat Scott\ Ritchie.gpg -----BEGIN PGP PUBLIC KEY

Hi all, For the record this approach isnt 100% backwards compatible, because names(mergeddf) will e incompatibly different. Thatx why i claimed bakcwards compatable-ish That said its still worth considering imho because of the reasons stated (and honestly one particular simple reading of the docs might suggest that this was thr intended behavior all along). Im not a member of Rcore through so i

On 17/02/2018 6:36 PM, frederik at ofb.net wrote: > Hi Scott, > > Thanks for the patch. I'm not really involved in R development; it > will be up to someone in the R core team to apply it. I would hazard > to say that even if correct (I haven't checked), it will not be > applied because the change might break existing code. For example it > seems like reasonable code

The attached patch.diff will make merge.data.frame() append the suffixes to columns with common names between by.x and names(y). Best, Scott Ritchie On 17 February 2018 at 11:15, Scott Ritchie <s.ritchie73 at gmail.com> wrote: > Hi Frederick, > > I would expect that any duplicate names in the resulting data.frame would > have the suffixes appended to them, regardless of

Thanks Martin! Can you clarify the functionality of the 'no.dups' argument so I can change my patch to `data.table:::merge.data.table` accordingly? - When `no.dups=TRUE` will the suffix to the by.x column name? Or will it take the functionality of the second functionality where only the column in y has the suffix added? - When `no.dups=FALSE` will the output be the same as it currently

Hi Scott, Thanks for the patch. I'm not really involved in R development; it will be up to someone in the R core team to apply it. I would hazard to say that even if correct (I haven't checked), it will not be applied because the change might break existing code. For example it seems like reasonable code might easily assume that a column with the same name as "by.x" exists in

On Nov 4, 2019, at 4:00 PM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We'd be keen to help out what the community decides to do here. I personally feel it's reasonable that: > - LangRef/DataLayout is updated with semantically coherent changes. > - The midend optimizer is updated by someone who cares about those changes and tests are added that use

Thanks Duncan and Frederick, I suspected as much - there doesn't appear to be any reason why conflicts between by.x and names(y) shouldn't and cannot be checked, but I can see how this might be more trouble than its worth given it potentially may break downstream packages (i.e. any cases where this occurs but they expect the name of the key column(s) to remain the same). Best, Scott On

Thanks Gabriel, I think your suggested approach is 100% backwards compatible Currently in the case of duplicate column names only the first can be indexed by its name. This will always be the column appearing in by.x, meaning the column in y with the same name cannot be accessed. Appending ".y" (suffixes[2L]) to this column means it can now be accessed, while keeping the current

>>>>> Gabriel Becker <gmbecker at ucdavis.edu> >>>>> on Wed, 21 Feb 2018 07:11:44 -0800 writes: > Hi all, > For the record this approach isnt 100% backwards compatible, because > names(mergeddf) will e incompatibly different. Thatx why i claimed > bakcwards compatable-ish exactly. > That said its still worth considering

Hi Frederick, It looks like I didn't overwrite the patch.diff file after the last edits. Here's the correct patch (attached and copied below): Index: src/library/base/R/merge.R =================================================================== --- src/library/base/R/merge.R (revision 74280) +++ src/library/base/R/merge.R (working copy) @@ -157,6 +157,14 @@ }

Hi, > QEMU side is still undergoing polishing, but is already testable. Looked art the qemu side for now, commenting here due to qemu patches not being posted to the list yet (guess that is at least partly already on your todo list): * Both legacy and modern should be switchable. Modern needs to be switchable _anyway_ for backward compatibility with old qemu versions. But legacy

Hi, > QEMU side is still undergoing polishing, but is already testable. Looked art the qemu side for now, commenting here due to qemu patches not being posted to the list yet (guess that is at least partly already on your todo list): * Both legacy and modern should be switchable. Modern needs to be switchable _anyway_ for backward compatibility with old qemu versions. But legacy

Hello I was wondering if someone could put together a bug triage guide and put it on the wiki. I was looking for something to do tonight and z00dax said go hunt some bugs. So I went first to the wiki to look for a guide for a proper procedure on how the team would like bug triaging handled but didn't find one. I have triaged before but i know every place is different. So some guidelines