similar to: Some commits not getting sent to the mailing lists.

For example, 7984b47401f7f36475619abf2ff02de3b5ff0481 does not seem to have made it to any mailing lists. This makes things harder for me as release manager, as those changes are essentially landing under the radar. Can we please make sure all commits that get pushed upstream are sent to a -commits list? Who is the right person to ask about this? Thanks, Hans

On Thu, Jan 30, 2020 at 9:50 AM Tom Stellard <tstellar at redhat.com> wrote: > > On 01/30/2020 05:25 AM, Hans Wennborg via llvm-dev wrote: > > For example, 7984b47401f7f36475619abf2ff02de3b5ff0481 does not seem to > > have made it to any mailing lists. > > > > This makes things harder for me as release manager, as those changes > > are essentially landing

On Thu, Feb 6, 2020 at 11:24 AM Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Jan 30, 2020 at 4:04 PM Hans Wennborg <hans at chromium.org> wrote: > > > > On Thu, Jan 30, 2020 at 9:50 AM Tom Stellard <tstellar at redhat.com> wrote: > > > > > > On 01/30/2020 05:25 AM, Hans Wennborg via llvm-dev wrote: > > > > For example,

I read through the editorial. This is the one of the most mega-ultra-super-biased articles I've ever read. e.g. The authors encourage Baysian methods, and literally encourage subjective approaches. However, there's only one reference to robust methods and one reference to nonparametric methods, both of which are labelled as purely exploratory methods, which I regard as extremely

Buenos días, estoy realizando análisis de texto con Twitter y tengo un problema con unos carácteres que no logro quitar. Són cadenas de letras con forma similar a *xaexdfxdeaxoa*. Creo que surgen de la códificación de los emojis. Yo suelo utilizar, más o menos el siguiente codigo con gsub para limpiar texto, pero no me sirve # remove rt x = gsub("rt", "", x) # remove at x =

On Thu, April 16, 2015 10:09 am, Les Mikesell wrote: > On Thu, Apr 16, 2015 at 10:01 AM, James B. Byrne <byrnejb at harte-lyne.ca> wrote: >> This morning I discovered this in my clamav report from one of our imap servers: >> /usr/share/nmap/scripts/irc-unrealircd-backdoor.nse: >> Unix.Trojan.MSShellcode-21 FOUND >> I have looked at this script and it appears to be

Good morning, On Sat, 2018-12-01 at 16:20 -0800, Greg Ogonowski wrote: > UTF-8 is now the universal standard. (ICY context:) Expect if you are in Asia. Or in central Europe. Or maybe in Africa. I'm not aware of servers on the poles, maybe they use..., ... > It supports ALL character sets. As long as "ALL" is defined as what English people need plus all emoji in all skin

The CentOS team likes to offer an apology for the political spam mails which went through our mail servers earlier today. Due to the nature of mailing list software for public discussion groups, there aren't that many security measures which can be taken to check which mails are supposed to get through and which mails aren't. Total safety can only be had by a moderation of all lists -

The CentOS team likes to offer an apology for the political spam mails which went through our mail servers earlier today. Due to the nature of mailing list software for public discussion groups, there aren't that many security measures which can be taken to check which mails are supposed to get through and which mails aren't. Total safety can only be had by a moderation of all lists -

On 02/10/2020 01:02 PM, Martin Storsjö wrote: > On Thu, 6 Feb 2020, Tom Stellard via llvm-dev wrote: > >> On 02/06/2020 02:48 PM, Greg Bedwell wrote: >>> Here's a non-MLIR commit that also wasn't sent to any list: >>> b3576f60ebc8f660afad8120a72473be47517573 >>> >>> >>> I don't think that this is the same issue as the

Hi everyone, I've noticed new behavior in `regexpr(..., perl = TRUE)` on Windows with R4.0 and above with Unicode characters. Here's a minimal example where I'd expect to see a start value of `5` (as R 3.6.2 and below gives), but R 4.0.0 (and R 4.0.1) now returns: ``` > regexpr("b", "foo\U0001F937bar", perl = TRUE) #> [1] 6 #>

On 02/06/2020 02:48 PM, Greg Bedwell wrote: > Here's a non-MLIR commit that also wasn't sent to any list: > b3576f60ebc8f660afad8120a72473be47517573 > > > I don't think that this is the same issue as the mlir commits. This particular one is likely due to the issue of non-ascii characters the commit summary (author/comitter name in this case) causing some sort

Greetings Icecast masters! Does anyone know what the supported character encoding(s) are for strings in ICY metadata? The closest I?ve been able to get via a Google search is this thread: http://forums.winamp.com/showthread.php?t=208096&highlight=handle+unicode+characters%3F <http://forums.winamp.com/showthread.php?t=208096&highlight=handle+unicode+characters?> Which would

Hi, I've got a problem with Weatherscope (available freely here: http://sdg.ocs.ou.edu/builds/final/win/WeatherScope/WeatherScope-1.4.1.exe) where the filtering of combo boxes using text typed in a line edit is broken. (Bug here: http://bugs.winehq.org/show_bug.cgi?id=7085) This can be seen by running the program (full path required), selecting product (from the invisible menubar) and

Hi ? This is giving me a headache. I?m trying to do a relatively simple optimization ? actually trying to approximate the output from the Excel Solver function but at roughly 1000x the speed. ? The optimization parameters look like this. The only trouble is that I want to add a constraint that sum(wgt.vect)=1, and I can?t figure out how to do that in optim. Mo.vect <-

https://bugzilla.samba.org/show_bug.cgi?id=14401 Bug ID: 14401 Summary: unicode character conversion problem from MacOS to Linux despite iconv Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

>>>>> Duncan Murdoch >>>>> on Sun, 10 Nov 2019 11:48:26 -0500 writes: > On 10/11/2019 9:17 a.m., Bryan Hanson wrote: >> >> >>> On Nov 10, 2019, at 3:36 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>> >>>>>>>> Gabriel Becker

I just submitted a patch on bugzilla[1] to update the internal column-width tables to a more recent version of Unicode.? The most obvious way this shows up is with emoji now having a computed width of 2 columns instead of 1 once the patch is applied: > nchar('\U0001F600', type='width'). # grinning face emoji [1] 2 This wasn't really an issue for a long time as many

Hi, I log in to Phab using my @chromium account with the "Log In or Register Google" button on https://reviews.llvm.org/auth/start/?next=%2F . That has worked fine for me, but now it fails with ``` Auth > Unhandled Exception ("Exception") Expected to retrieve an "account" email from Google Plus API call to identify account, but failed. ``` Is anyone else

> On Mar 3, 2020, at 17:16, Shoaib Meenai <smeenai at fb.com> wrote: > > `arc patch` should preserve the author information in the original commit, if there was any. At least it has in my experience. Yes, but I think people can upload raw patches to Phabricator without using `arc diff`. I know I ran into one of these just last week where I used Johannes' script (thanks!) and