search for: unport

...*)0x00001000 > > which is horrible. The drivers I have seen can't work that way because they are written to cover more than one specific machine. As soon as you go anywhere near an IO abstraction, this doesn't apply anymore. As such, I think this feature primarily helps making ugly, unportable code differently ugly, unportable code. Joerg

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...

...eryone, 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 uses basic R commands, it looks like this: latexNum <- function (x,dig=4,sci=T) { x <- format(x,digits=dig,scientific=sci) x <- gsub("e\\+00","",x) x <-...

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++

...d 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 precompiled headers for Clang that will abstract away some of the unportabilities of C from a runtime perspective using aliases and inlines in the place of macros? If not, will the proposed type system for LLVM 3.0 solve some of these problems? I'm hoping to avoid needing the runtime libraries of each programming language we're supporting. I also cannot be al...

...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 >...

...hich is horrible. > > The drivers I have seen can't work that way because they are written to > cover more than one specific machine. As soon as you go anywhere near an > IO abstraction, this doesn't apply anymore. As such, I think this > feature primarily helps making ugly, unportable code differently ugly, > unportable code. Your argument appears to be that this feature would have little use to you. Noted, I guess. We've spoken to several people who do write drivers and other code like the above, and they seem pretty enthusiastic about the idea. If you have input...

...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 LLV...

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

...---------------------------------------------------------- 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 endianness issues, although even there, an ILP32 and an LP64 process on the same machine should really be able to share databases, although I haven't checked for alignment problems). I'm also not sure why quartz_types.h / fl...

...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, or unportable, or for anything that could potentially cause trouble. I don't see how using gzip instead of bzip2 or xz could fall into that category (and BTW gzip is the default for save() and for 'R CMD build' resave-data feature). The problem is that bzip2 and xz compressions are slower and al...

...;re willing to make some concessions to broken clients, an inability to speak TCP correctly is well outside what I consider sensible, particularly given that it will degrade icecast's performance for working clients (you remain welcome, of course, to hack up your local copy). It's also very unportable. Mike

...ts MIDI devices properly allowing WINE (using alsa or OSS interfaces) to feed it the correct devices. It detects audio devices by looking for drivers in the windows directory. How do I know? It finds a Delta44 asio driver even though I do not have the card, just the file. This is a very bad and unportable approach, obviously.

...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

...ve tools. - Fixed issue with opening relative paths as a mail file. Bug reported by Ian P. Christian. - Fixed MAC OSX compile problem. Turns out the extern modifier was missing at multiple places. Bug reported by Edgar Fuss. - Fixed Solaris compile problem: removed unecessary and unportable linker flags that caused compile to fail. Bug reported by Andres Yacopino. The release is available as follows: http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.4.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.4.tar.gz.sig Have fun testing the new release...

...ve tools. - Fixed issue with opening relative paths as a mail file. Bug reported by Ian P. Christian. - Fixed MAC OSX compile problem. Turns out the extern modifier was missing at multiple places. Bug reported by Edgar Fuss. - Fixed Solaris compile problem: removed unecessary and unportable linker flags that caused compile to fail. Bug reported by Andres Yacopino. The release is available as follows: http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.4.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.4.tar.gz.sig Have fun testing the new release...

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 th...

...In most cases it would, in my opinion, enhance icecasts' performance, since the optimum TCP packet size is being used. CORK would normally result in a more stable data throughput (because each packet is filled to max) using less bandwidth (due to minimizing overhead). > It's also very unportable. It is, that's why my first proposal was to incorporate it as a ./configure option. That way you can leave the default the way it is now, but give end users the option of using it. However i will cleanup the patch for distribution and then sent it to those who requested it. I hope you'...