search for: unported

On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: > It would be nice to add support for placing globals at fixed addresses in memory. I don't know. From my experience, the usefulness is very, very limited. As in: drivers are about the only thing that can make use of it. > For example, low level driver code tends to contain things like this > > *(int*)0x00001000

Hi all It would be nice to add support for placing globals at fixed addresses in memory. For example, low level driver code tends to contain things like this *(int*)0x00001000 which is horrible. Alternatively people are using linker scripts and assembly hacks to put symbols at fixed addresses. I propose we add first class support to this in the compiler. Like addrspace(#) we should have

...ink it would be a good idea to take this opportunity and make the new PM the default one which gives us enough time to work out any kinks that might come out of this switch before LLVM 10.0.0 branch point. We suspect that there may be other LLVM projects that will be affected by this, probably from unported passes. Does anyone have any opinions on this? Off the top of my head, the next immediate work would be to update the docs with instructions on how to write or port a new PM pass, and address any breakages for other LLVM projects. Thanks, Leonard -------------- next part -------------- An HTML a...

Hello Everyone, I am an avid Sweave user and I am trying to pretty print floating point numbers for latex output. For example in my document, I would like: 4.2\cdot 10^-{8} Instead of: 4.2e-08 The Hmisc package has a nice function for doing this- but Hmisc has a ton of dependencies and has proved very unportable to the various machines I work on. So, I set out to write my own function that

Just my two cents: Anyone thought of asking Red Hat to use documentation? I think they are getting much from the community so to copy public accessible documentation when permitted by RH could be an easy way. Why not giving that a try? Am 18. Januar 2015 20:56:59 MEZ, schrieb Darr247 <darr247 at gmail.com>: >On 18 January 2015 @19:07 zulu, Mark LaPierre wrote: >> good at C or C++

Hello everybody, My partner and I want to make a parser generator that will generate LLVM bitcode directly so that it can use libraries compiled in any LLVM-based language. Unfortunately we are running into some problems with dependencies on libc since it is different on every operating system. The Mac, for example, defines stdin as a macro in stdio.h. Is there going to be a collection of

...od idea to take this opportunity and make > the new PM the default one which gives us enough time to work out any kinks > that might come out of this switch before LLVM 10.0.0 branch point. We > suspect that there may be other LLVM projects that will be affected by > this, probably from unported passes. > > Does anyone have any opinions on this? > > Off the top of my head, the next immediate work would be to update the > docs with instructions on how to write or port a new PM pass, and address > any breakages for other LLVM projects. > > Thanks, > Leonard > &g...

(resent due to mailing list breakage) On Dec 6, 2011, at 6:55 AM, Joerg Sonnenberger wrote: > On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: >> It would be nice to add support for placing globals at fixed addresses in memory. > > I don't know. From my experience, the usefulness is very, very limited. > As in: drivers are about the only thing that can make

...and make >>> the new PM the default one which gives us enough time to work out any kinks >>> that might come out of this switch before LLVM 10.0.0 branch point. We >>> suspect that there may be other LLVM projects that will be affected by >>> this, probably from unported passes. >>> >>> Does anyone have any opinions on this? >>> >>> Off the top of my head, the next immediate work would be to update the >>> docs with instructions on how to write or port a new PM pass, and address >>> any breakages for other LLVM...

On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> wrote: > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Actually, undefined behavior is essential for serious projects, but not for the reasons mentioned. If the language has no undefined behavior, then from the compiler's view, there is no such thing as a bad program. All

We have: ---------------------------------------------------------------------- typedef unsigned long uint4; ---------------------------------------------------------------------- which on an LP64 system is a lie. If uint4 is used on disk (and it's used in the btree implementation) then it would make the databases unportable, which probably isn't a good idea (unless we already have

Hi, Recently added to doc/NEWS.Rd: 'R CMD check' now gives a warning rather than a note if it finds inefficiently compressed datasets. With 'bzip2' and 'xz' compression having been available since R 2.10.0, there is no excuse for not using them. Why isn't a note enough for this? Generally speaking, warnings are for things that are dangerous, or unsafe,

> > p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent > article: http://www.baus.net/on-tcp_cork Thanks for this pointer. I'd been meaning to reply on this thread, but hadn't got around to it, primarily because I didn't really understand TCP_CORK (the linux manpage is, as usual, fairly unclear on what exactly it does). Now I understand! > >

This one may well be the first fully capable audio/midi DAW program to work in both Windows and Linux. This is because it is not based on Microsoft's framework. I got the freebie while this offer was around. Version 2 is supposed to come out soon. (I presently use Cakewalk Home Studio--Sonar's not so little sister and a lot of bang for the buck. I have gotten used to drawing

...ion when permitted by RH could be > an easy way. > > Why not giving that a try? There's no need to ask them, they've already given permission: > Copyright ? 2014 Red Hat, Inc. > This document is licensed by Red Hat under the Creative Commons > Attribution-ShareAlike 3.0 Unported License. If you distribute this > document, or a modified version of it, you must provide attribution > to Red Hat, Inc. and provide a link to the original. If the document > is modified, all Red Hat trademarks must be removed. I'd say that's good enough. Peter

Hello Dovecot users, Not much Sieve development was done in the last five weeks, but some important platform-dependent bugs were found and repaired. The main new feature is the addition of a custom Sieve language extension for debugging in the Sieve command line tools. Changelog Sieve v0.1.4: * Started work on the sieve-filter tool. With this command line tool it will be possible to

Hello Dovecot users, Not much Sieve development was done in the last five weeks, but some important platform-dependent bugs were found and repaired. The main new feature is the addition of a custom Sieve language extension for debugging in the Sieve command line tools. Changelog Sieve v0.1.4: * Started work on the sieve-filter tool. With this command line tool it will be possible to

Citeren Arnaud Quette <aquette.dev op gmail.com>: > Date: Thu, 09 Dec 2010 14:01:14 +0000 > Subject: svn commit r2726 - in branches/windows_port: common drivers include > Author: fbohe-guest > Date: Thu Dec 9 14:01:07 2010 > New Revision: 2726 > URL: http://trac.networkupstools.org/projects/nut/changeset/2726 > > Log: > More work on serial drivers. > Still

...! For your reference, I am copying the contents of its README file here. ======== lpep LDAP passwd Enumerator for Puppet Purpose ------- Add users and groups from Active Directory to your Red Hat 6.x compatible systems License ------- Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License Setup ----- On Red Hat 6.x compatible systems: (1) command: yum install pam_ldap (2) command: authconfig --enableldapauth --ldapserver="ldap://ad.example.com" --ldapbasedn="dc=example,dc=com" --updateall (3) in /etc/pam_ldap.conf, add the following lines towards the...

> As a streaming server, it's fairly crucial for icecast to > send out data with as low a delay as possible (many clients > don't care, but some do). That's why we use TCP_NODELAY - we > actually WANT to send out data as soon as we can. Nagle is inherently unsuited for streams. NODELAY was (imho) ment for connections for which Nagle isn't sufficient and CORK is not