search for: _itself_

...ld work better in the first place. I actually tried early on to use LLDB, but I gave up quickly. The API seems to be designed so that you must always attach one process to another, using an operating system facility like ptrace. That is not really compatible with the idea of the program inspecting _itself_, although I think there is definitely a place for that, e.g. portable stack traces, source info without the need for __FILE__ and __LINE__ boilerplate, etc. Does LLDB support anything like this, and I just didn't find it? Or going another route, is there any plan for the DWARF classes in LLVMD...

...g difficulty conceiving a comparable analogy) that just because 1 party decides to do something that breaks long standing practice that is effective for the vast majority of people, everyone else looses. http://www.lsoft.com/news/2014/dmarc-debacle-us.asp is an excellent example of Yahoo! shooting _itself_ in the foot, breaking its products for about one month and the "fix" causing yet more issues. In both instances, Yahoo! caused additional confusion and frustration. I can completely understand it for certain uses like vendor/customer interactions, especially over a CRM (customer relatio...

I recommend someone verify that tar.gz and tar.xz files ( at https://www.kernel.org/pub/linux/utils/boot/syslinux/ ) unpack without errors. (I assume use of compression is in hope of saving download bandwidth) Regards

>>> Looks like the patch mostly addresses the initial search to find the right handle for PXE.? I think I found the remaining source of the issue (the part that's generating the handle->Configure() messages). I'm trying to read through pieces of the EFI spec, gnu-efi API, and a few other sources.? I'm pretty certain you'll see that the previous patch/binaries

...nting. > I somehow had the notion syslinux was meant to be compatible with FAT, as in > "The Syslinux Project covers lightweight bootloaders for MS-DOS FAT > filesystems (SYSLINUX), ?". > Not the same as in the zip file, thankfully. > ? > Anyway, thanks! The boot loader _itself_ is compatible. This is merely a single header file in the source portion of the archive file and unnecessary for normal use. If I recall correctly, tar can store symlinks while zip can not and must duplicate the file to store it. -- -Gene

...ors might mess up. >>>> Extracting onto a file system that has no concept of a symlink like say FAT >>>> will also have issues. ? >>> >>> ______________________________________________________________________ >>> ? >> >> The boot loader _itself_ is compatible. This is merely a single header >> file in the source portion of the archive file and unnecessary for normal >> use. If I recall correctly, tar can store symlinks while zip can not and >> must duplicate the file to store it. >> ? > > ___________________...

...ies or true llvm bytecode archives. Those -L paths that do contain them are omitted from the call to the system linker. This should resolve http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=525 We can not just issue an error when the user feeds an -L path to the llvm-g++ compiler, because llvm-g++ _itself_ appends it's lib directories to the call to gccld. The result is that llvm-g++'s bytecode archive files (see libstdc++.a and libc.a) are included in _any_ call to gccld by llvm-g++. Hopefully this is the correct fix once and for all. Thanks, Adam Treat -------------- next part -----...

>>> The key is that the handle _itself_ is the proper link between the EFI_PXE_BASE_CODE_PROTOCOL and EFI_UDP4_SERVICE_BINDING_PROTOCOL. _IT_ is the piece that must be stored and reused. I found this thanks to a Google search "EFI_PXE_BASE_CODE_PROTOCOL EFI_MANAGED_NETWORK_PROTOCOL" and http://sourceforge.net/p/edk2/mailm...

...he right NIC again at > main.c\efi_create_binding() > as explained here. > http://www.syslinux.org/archives/2015-May/023453.html > Cao's patch fails doing this because it relies on certain assumptions on > handle "order" that are not correct. The key is that the handle _itself_ is the proper link between the EFI_PXE_BASE_CODE_PROTOCOL and EFI_UDP4_SERVICE_BINDING_PROTOCOL. _IT_ is the piece that must be stored and reused. I found this thanks to a Google search "EFI_PXE_BASE_CODE_PROTOCOL EFI_MANAGED_NETWORK_PROTOCOL" and http://sourceforge.net/p/edk2/mailman/me...

> As per > prior discussions, the "From:" field should remain > with the > original sender. One (important) > reason is that frequent participants > in the > Syslinux Mailing List tend to use the "From:" > field, for > instance as search filter. Well I consider the search filter by subject is a much better approach, for participating on a

> On Sun, Jan 18, 2015 at 8:18 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > > Hi Gene: > > Everything that comes from the list goes to my spam folder > > because the message looks as spam to yahoo. > > A simple filter resolves this: > > Deliver to "Inbox" if > To/CC contains "syslinux at zytor.com" > > > why is

On Mon, 31 Jul 2023 09:25:12 +0800, "zhanghao1" <zhanghao1 at kylinos.cn> wrote: > A new virtio pci driver is added for listening to vcpus > inside guest. Each vcpu creates a corresponding thread to > periodically send data to qemu's back-end watchdog device. > If a vCPU is in the stall state, data cannot be sent to > back-end virtio device. As a result, the

I've seen alot of posts lately on Queue and Agent functionality, and alot of hacks to make them do different things that most call center managers want. In the sake of doing this one time, I'd like to develop a single list of request so we can consolidate a feature request for the Queue/Agent system. Here are the ones that I run into the most: 1. Queue should know the status of agents