search for: enyoing

On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: > Is this really a problem for MLton?  I think you only get less precise > alias analysis, and that's it. Correct. However, I want a fair comparison between LLVM performance and the native x86 codegen. If I don't give LLVM the same information the x86 codegen has, it's an unfair comparison.

Hello Rene, Maybe have you already upgrade you openssl/openssh packages if you using debian (or *buntu). http://article.gmane.org/gmane.linux.debian.security.announce/1614 We have found some weak keys : - nightlycomp@rio (sure) - comp@rio (maybe) Are you up to date ? Can Fabrice sent you new ssh public ? Tahnks Best Regards -- Gabriel CORRE gac@4js.com - Four J's Development Tools -

On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: > On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: > > Is this really a problem for MLton?  I think you only get less precise > > alias analysis, and that's it. > > Correct. However, I want a fair comparison between LLVM performance > and the native x86 codegen. If I don't

* Rahul Chaudhry via gnu-gabi: > The encoding used is a simple combination of delta-encoding and a > bitmap of offsets. The section consists of 64-bit entries: higher > 8-bits contain delta since last offset, and lower 56-bits contain a > bitmap for which words to apply the relocation to. This is best > described by showing the code for decoding the section: > > typedef

I am trying to figure out if I am missing something simple here. After upgrading to puppet 3.0 running puppet-rspec tests that use custom resources from modules in the fixtures directory are failing. I have a module that uses the anchor type and with 2.7.19 it works fine. After upgrading to 3.0 all of the tests are failing with Puppet::Error: Puppet::Parser::AST::Resource failed with

* Scott Michel: > On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an > unexpected success (i.e., "grep -w shlh %t1.s | count 9" succeeds.) > > I get the same unexpected success on my x86_64 Mac 10.4.11. > > On the x86_64 buildbot, the same test fails. The culprit is grep, > evidently. It's just that simple. There have been issues the GNU libc

On Wed, Dec 31, 2008 at 3:35 AM, Florian Weimer <fw at deneb.enyo.de> wrote: > * Scott Michel: > >> On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an >> unexpected success (i.e., "grep -w shlh %t1.s | count 9" succeeds.) >> >> I get the same unexpected success on my x86_64 Mac 10.4.11. >> >> On the x86_64 buildbot, the same

* Neale Ferguson: > So the SimpleTy variable which is a SimpleTypeValue is behaving strangely. > It's found within a private definition: > > union { > uintptr_t V; > SimpleValueType SimpleTy; > const Type *LLVMTy; > }; > > The comment in the above fix indicates that in this 64-bit system the enum > needs to be 64-bits is correct,

* Wesley W. Terpstra: >> Logically, what you want is a distinct LLVM type for every ML union type >> and each of its constructors.  Unfortunately, LLVM does structural >> uniquing of types, so that won't work. > > Is there absolutely no way to generate a new type? Not even an > 'opaque' one? Is this really a problem for MLton? I think you only get less

Hallo, Enyoing the Rails framework, I often write loop like this: for j_method in @service.j_methods for parameter in j_method.parameters @output = j_method.name+ " is in "+parameter.name end end So: * @service.j_methods => j_method * j_method.parameters => parameter forall @ser...

Hi, Does anyone know how to prevent snmpd from writing the below into /var/log/messages/ Nov 29 19:35:02 serenity snmpd[2287]: Received SNMP packet(s) from UDP: [127.0.0.1]:34309 Nov 29 19:35:02 serenity snmpd[2287]: Connection from UDP: [127.0.0.1]:34309 Nov 29 19:35:02 serenity last message repeated 7 times Nov 29 19:40:02 serenity snmpd[2287]: Connection from UDP: [127.0.0.1]:34313 Nov 29

Package: xen-utils-4.0 Version: 4.0.1-5.2 After clean upgrade from Lenny I got xend highly use CPU resources causing domU don't being created - due to timeouts for vifs and vbds (mostly CPU Steal Time was increasing - no iowaits). Tried Xen boot options acpi=noirq|ht without success. Option acpi=off solved that issue, but performance of the server was horrible. The final workaround was to

* Roland McGrath: > Given this corpus of "reloc traces" you can code up many competing encoding > formats and do serious measurements of their space savings across the > entire corpus from simple simulations without having to implement each > encoding in an actual toolchain and dynamic linker to do the analysis. On the other hand, the linker currently assumes that the order

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: >> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: >> > Is this really a problem for MLton? I think you only get less precise >> > alias analysis, and that's it. >> >> Correct. However, I want a fair comparison between LLVM performance >> and the native x86

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I maintain this Samba 3.6.6 PDC with ldap backend for 45 Windows 7 clients, with 92G of data in there profiles because things like itunes and other programs keep storing data in the roaming profiles causing very long start-up and shut-down times. I would like to switch to folder redirection (GPO) but I have not found any information

The generic-abi thread has gone into broader subjects of the benefits and desireability of the work. I'm willing to take it as given that the encoded size of pure-relative address relocs (i.e. R_*_RELATIVE equivalents)--ultimately the RODATA segment size of a given ET_DYN file--as sole metric is a worthy goal and the ballpark savings ratios we're seeing are worth committing to a new ABI.

I searched the archives and found this from last month: I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== ---

On Sat, Jun 13, 2009 at 9:44 PM, John McCall<rjmccall at apple.com> wrote: > On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote: > Currently I just represent %c as i8*. I assume that this can have > consequences in terms of aliasing. I tried opaque*, but llvm-as didn't > like that. Is there any way to better represent the type %c to LLVM? > > I assume this is for

A simple combination of delta-encoding and run_length-encoding is one of the first schemes we experimented with (32-bit entries with 24-bit 'delta' and an 8-bit 'count'). This gave really good results, but as Sri mentions, we observed several cases where the relative relocations were not on consecutive offsets. There were common cases where the relocations applied to alternate

Hi, I have a system based on a Supermicro X8DTH-i motherboard and a Xeon E5506 CPU. It was previously running Debian lenny with xen-hypervisor-3.2-1-amd64 (3.2.1-2) / linux-image-2.6.26-2-xen-amd64 (2.6.26-29) without incident. I upgraded it to Debian squeeze, with xen-hypervisor-4.0-amd64 (4.0.1-4) / linux-image-2.6.32-5-xen-amd64 (2.6.32-45) and now it does not complete a boot of the dom0