search for: formalising

Hi all, I've updated our Team page a bit, added a table for everyone already there. Now I still don't like the fact that we have the distinction between the Core members (whatever that means) and the others. Some have a @centos.org email address, we could use that as a distinction ? I do think we need to make that page exclusive to people that have some sort of responsibility, and

On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote: > ? Looking at NUT pull request (PR) history on GitHub, I see that we have > had a non-trivial number of stalled driver contributions sharing a prominent > similarity: proposed names for some of the variables did not fit into the list > defined at https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt > ? I

On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote: > ? Looking at NUT pull request (PR) history on GitHub, I see that we have > had a non-trivial number of stalled driver contributions sharing a prominent > similarity: proposed names for some of the variables did not fit into the list > defined at https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt > ? I

Good morning, I am Martin Bodin, a postdoc at the CMM in Santiago de Chile, and I am currently in the process of formalising (a part of) the R language into the Coq proof assistant. This work makes me look frequently at the source code of R. I have noticed a strange line in the file src/main/util.c of the trunk branch: https://github.com/wch/r-source/blob/e42531eff56ee6582d7dc6a46f242af5447c633e/src/main/util.c#L70 The...

# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # logcheck (1.3) unstable; urgency=low # # * Formalise the dropping of violations.d/logcheck. Please see # /usr/share/doc/logcheck-database/NEWS.Debian.gz for more information # (closes: #471072). # * Add Auto-Submitted header to outgoing mails (closes: #489172). # * ignore.d.server/kernel: # -

Thanks very much for the quick response. I have read the text many times, but it was not very clear to me why checking the two conditions involving dominance frontiers is equivalent to proving the pair {entry, exit} defines a refined region. I was asking for an mathematical proof really. It sounds to me like there should be a theorem or two in the graph theory endorsing it. Or do you mean, the

hello guys i have centos5.1, and my subject is : when i install a package without the rpm tool cause its not rpm package like configure , make , make install how can i uninstall it later ? thank u all for ur time _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE!

On 27 July 2016 at 17:47, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > First and foremost please don’t consider lack of dissent on the thread as > presence of consensus. Hi Chris, First things first: I give you my word that I will be yelling louder than others if this ever happens. (I can be *very* loud! :) People can push and yell all they want, changes like

I agree with Paul that we need to formalise the compatibility policy before we start removing support for old intrinsics. Do we want a deprecation warning of some kind for the use of any intrinsic used in auto-upgrade, would that actually be useful or just a nuisance? In the meantime I’m happy to help fix any missing test coverage. > On 20 Sep 2017, at 22:16, Robinson, Paul via llvm-dev

Hi, I believe we have a formal policy: we support every bitcode produced since LLVM 3.0: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility (until we decide to uprev the version we support). Unfortunately, the testing was only added around 3.6 or 3.7? And support is only as good as the testing we have... -- Mehdi 2017-09-21 0:23 GMT-07:00 Simon Pilgrim via llvm-dev <

> On Oct 19, 2015, at 9:27 AM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Oct 19, 2015 at 08:25:16AM -0700, Chris Lattner via llvm-dev wrote: >> 1) We could introduce a novel legal solution. > > Please, no. > >> 2) We could require new contributors to sign the Apache CLA. > > To me, this is the most acceptable

On Fri, 28 May 2021, Roger Price wrote: > On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote: > >> ? Looking at NUT pull request (PR) history on GitHub, I see that we have had >> a non-trivial number of stalled driver contributions sharing a prominent >> similarity: proposed names for some of the variables did not fit into the >> list defined at >>

On Fri, 28 May 2021, Roger Price wrote: > On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote: > >> ? Looking at NUT pull request (PR) history on GitHub, I see that we have had >> a non-trivial number of stalled driver contributions sharing a prominent >> similarity: proposed names for some of the variables did not fit into the >> list defined at >>

As can be seen in the trunk, I'm working on the alarm functions in NUT. Only two drivers actively use these at the moment and I intend to add a third one to that (usbhid-ups, in an effort to clean up the mess we created there with undocumented status flags). At the moment, docs/new-drivers.txt says about the alarm functions the following: "There is no official list of alarm words as of

Hi all, I have an idea for a proposal for the summer of code which I think is pretty cool, but I wanted to run it past you all to see what you thought of it first. Basically, the proposal is to use LLVM as a test bed for a more theoretical idea I have. I want to develop a grammar-level way of formally specifying how to translate between two languages. Borrowing from XSLT (a way of transforming

Hello all, Looking at NUT pull request (PR) history on GitHub, I see that we have had a non-trivial number of stalled driver contributions sharing a prominent similarity: proposed names for some of the variables did not fit into the list defined at https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt During discussions of these contributions, original driver authors often

Hello all, Looking at NUT pull request (PR) history on GitHub, I see that we have had a non-trivial number of stalled driver contributions sharing a prominent similarity: proposed names for some of the variables did not fit into the list defined at https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt During discussions of these contributions, original driver authors often

I wonder if it isn't time to change the reply-to-list policy of R-help and adopt the alternative convention of replying to the author and asking him/her to summarize to the list. Recently R-help has been too busy for me to keep up with. There were quite a few identical responses in the "Finding indices with a certain property" thread, rather than an extended discussion. I think

hi all, i've searched the samba archived but found little information on the topic related to setting permissions. i wanted to have this effect on a share -- SHARE: [answers] | +--- 1 ---+-- date1 | | | +-- date2 | +--- 2 ---+-- date1 | +-- date2 GROUPS: faculty, students PATH: /home/samba/shares/answers ../answers/ (faculty

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Everyone, It gives me great pleasure to announce the formation of the CentOS Linux AltArch Special Interest Group ( SIG ). This SIG will be setup and managed by community members who want to come and help port CentOS Linux to architectures and platforms not supported by the Core SIG itself. Note: this is not called secondary arch group, since