search for: detangl

Hello list, I wondered if those of you using Polycom phones could recommend a decent cord detangler. I've had quite a few handsets get the tabs broken off in the jack from cord detanglers due to the recessed nature of the jack. This seems like it would work but I wanted some opinions before I go buy some: http://www.voiplink.com/Extended_Handset_Cord_Detangler_p/detangler-e.htm I perso...

So I have a patch to try and straighten out the ppbus/ppc interrupt stuff a bit. Rather than passing IRQ numbers around as ivars, etc., ppc is smart enough to let child devices ask for SYS_RES_IRQ rid 0 and let them use its assigned IRQ resource. It then uses an interrupt event to mange the list of child interrupt handlers which it invokes from its own interrupt handler. I don't

...nt to Record's constructor, and a > corresponding factory method to RecordKeeper. This looks like great progress to me, applied in r121659. That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? Another random question: why is createRecord better than using "new Record"? If createRecord is better, it would be good to make the Record ctor private so the code doesn't evolve into sometimes using one and sometimes using the other. So...

Hey Chris, The following patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of

...ferences to a RecordKeeper instance for the tblgen >> utility. > > This looks like great progress to me, applied in r121659. > > That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? I'll see if I can come up with another approach. This internal reference was motivated by the Record::setName(...) and UnOpInit::Fold(...) implementations accessing the previous global RecordKeeper instance. We could add a RecordKeeper& argument...

...s considered very much a legacy use case. Use evdev or the new libinput driver instead. Egbert's fix untangles overlaps between multimedia keys and the jp Henkan/Muhenkan keys. Alan Coopersmith (1): Mark xf86OSKbdPreInit as _X_EXPORT in header to match definitions Egbert Eich (1): Detangle inet keys and jp Henkan/ Muhenkan keys Peter Hutterer (3): Init LEDs to zero before querying the value linux: bring our process group to the foreground (#89653) keyboard 1.8.1 git tag: xf86-input-keyboard-1.8.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-k...

...ions that should work with iptr: > Basic math: add, subtract, multiply, divide, mod. > Bitwise binary operators: shl, ashr, lshr, and, or, xor, etc. > Comparison operations. > alloca - currently doesn't work with i64, should it? Yes, alloca should work with i64. Recently malloc was detangled from alloca, but alloca should definitely support an arbitrary integer size. I don't know anyone planning to do this. In any case, for the first implementation stage of intptr, just converting to an i32 to do the alloca should be fine (no worse than what we have today). When allo...

...Keeper instance for the tblgen >>> utility. >> >> This looks like great progress to me, applied in r121659. >> >> That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? > > I'll see if I can come up with another approach. This internal reference was motivated by the > Record::setName(...) and UnOpInit::Fold(...) implementations accessing the previous > global RecordKeeper instance. We could add a Record...

...- Basic math: add, subtract, multiply, divide, mod. > - Bitwise binary operators: shl, ashr, lshr, and, or, xor, etc. > - Comparison operations. > - alloca - currently doesn't work with i64, should it? > > Yes, alloca should work with i64. Recently malloc was detangled from > alloca, but alloca should definitely support an arbitrary integer size. I > don't know anyone planning to do this. In any case, for the first > implementation stage of intptr, just converting to an i32 to do the alloca > should be fine (no worse than what we have today)....

On Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 10, 2009, at 4:10 PM, Talin wrote: > > I realize that most users of LLVM aren't affected by this, because most > frontends aren't target-neutral, and thus know in advance how big a pointer > is. At least, that's my impression. > > I believe that. > > >

On Nov 10, 2009, at 4:10 PM, Talin wrote: > I realize that most users of LLVM aren't affected by this, because most frontends aren't target-neutral, and thus know in advance how big a pointer is. At least, that's my impression. I believe that. > There's only a tiny handful of fairly esoteric cases which require selecting a target before you generate IR. Unfortunately, the

Hi, Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. This would be fine if it N32 was

...s then it shouldn't be too bad to do so. Even if it weren't an API problem I'm not sure it'd be a good idea. I think we could add a with-abi configuration option to match the current gcc one rather than tacking it onto triple parsing. That said, I'm more than happy to help you detangle the existing API and come up with a good strategy for the MC level API. Thanks! -eric ps. It also doesn't appear that Matthew (who took over my gcc responsibilities, thanks!) has added support for this in gcc yet either. echristo at dzur ~/b/build-gcc-mips64abin64> .../configure --targe...