search for: l370

Hi all, Is there way to tell the ORC JIT infrastructure to run the static constructors in a module that has just been compiled? I see that the ExecutionEngine class has a runStaticConstructorsDestructors function, is that relevant with ORC and if so, how should it be accessed? Thanks, Daniele -------------- next part -------------- An HTML attachment was scrubbed... URL:

...e modules and then execute them manually as you would with any other function. The simplest solution is to take this code and modify it to get the list of constructor functions: https://github.com/llvm-mirror/llvm/blob/1154d31e8c429e53307d3fc0edd13d9b261c26dc/lib/ExecutionEngine/ExecutionEngine.cpp#L370 This might be not the most ideal solution, but it works. Cheers, Alex. > On 14. Mar 2019, at 22:15, Daniele Vettorel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Is there way to tell the ORC JIT infrastructure to run the static constructors in a module th...

Until Syslinux 3.86, isolinux.bin contained a checksum that was calculated by 'core/checksumiso.pl'. The checksum is related to the patching of the boot info table. During May 2009, a commit by Peter deleted the checksumiso.pl file. The commit is: core: LZO compress the PM part of the core repo.or.cz/syslinux.git/commit/0d82b71304d596d80f3c4520f9dcf90048ca50b7 And so, since

Hi, this is partly Postfix related, but I want to know if there could be way to distinguish port of the SASL AUTH request to segregate user services. Currently I use unix listener for dovecot sasl auth, but could change to inet_listener. Only way I can think is to have different SASL AUTH services for each master.cf entry where its needed. But is it possible for Dovecot to have more than

...ng still is applied somehow during building of isolinux.bin. In the diff of core/Makefile i see a new program ../lzo/prepcore applied. In its source, one can see the Boot Info Table checksum calculation: http://repo.or.cz/syslinux.git/blob/0d82b71304d596d80f3c4520f9dcf90048ca50b7:/lzo/prepcore.c#l370 It looks to me as if it computes the checksum of payload and block padding. (This explains why the installed isolinux.bin are always block aligned.) Nevertheless, something must be different there, compared to libisofs and the check in the running isolinux.bin boot image program. For now i fail t...

...ing options(warn = 1) shows that the "invalid char string in output conversion" warning is outputted over and over in an infinite loop. This warning is generated by dummy_vfprintf() defined in src/main/connections.c (https://github.com/wch/r-source/blob/R-3-3-branch/src/main/connections.c#L370); # define BUFSIZE 10000 int dummy_vfprintf(Rconnection con, const char *format, va_list ap) { [...] if(ires == (size_t)(-1) && errno != E2BIG) /* is this safe? */ warning(_("invalid char string in output conversion")); [...] } Note BUFSIZE, note the...

Since December 2014, clients using the Python poplib library (getmail in my case) started to limit the line length of RETR and other command responses sent from the server to 2048 bytes: See https://bugs.python.org/issue16041 (Included at least in Python-2.7.9) Dovecot doesn't have line split in the POP3 module, so Python fails to retrieve messages with long lines. RFC 1939 says: "

...turns lines longer than 2048 bytes: https://hg.python.org/cpython/file/0db36098b908/Lib/poplib.py#l227 https://hg.python.org/cpython/file/0db36098b908/Lib/poplib.py#l165 https://hg.python.org/cpython/file/0db36098b908/Lib/poplib.py#l142 https://hg.python.org/cpython/file/0db36098b908/Lib/poplib.py#l370 def _getline(self): line = "" renewline = re.compile(r'.*?\n') match = renewline.match(self.buffer) while not match: self._fillBuffer() >>> if len(self.buffer) > _MAXLINE: # _MAXLINE...

Hello. While playing with Compiz window switchers (there are several) I noticed that the selected window name is displayed but not vocalized by the screen reader. I was initially surprised after discovering that the window title is not drawn with GTK; but I understand that Compiz itself does not actually depend on GTK --- only the GTK window decorator and CCSM use it. So Compiz renders text

...ow during building of > isolinux.bin. > > In the diff of core/Makefile i see a new program ../lzo/prepcore applied. > In its source, one can see the Boot Info Table checksum calculation: > http://repo.or.cz/syslinux.git/blob/0d82b71304d596d80f3c4520f9dcf90048ca50b7:/lzo/prepcore.c#l370 > It looks to me as if it computes the checksum of payload and block padding. > (This explains why the installed isolinux.bin are always block aligned.) > > Nevertheless, something must be different there, compared to libisofs and > the check in the running isolinux.bin boot image p...

...ak existing behaviour. The issue of cleaning up disks in general is a hard one to solve. With the OpenStack backend we try our best as long as virt-v2v exits on a normal failure path: https://github.com/libguestfs/libguestfs/blob/e2bafffce24cd8c0436bf887ee166a3ae2257bbb/v2v/output_openstack.ml#L370-L384 However there are always going to be cases where that is not possible (eg. virt-v2v segfaults or is kill -9'd or whatever), and in that case I envisaged for OpenStack some sort of external garbage collector. To this end, disks which have not been finalized are given a special description...

[Adding Tomas Golembiovsky] On Wed, Sep 26, 2018 at 12:11 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > Rather than jumping to a solution, can you explain what the problem > is that you're trying to solve? > > You need to do <X>, you tried virt-v2v, it doesn't do <X>, etc. > Well, that's mainly IMS related challenges. We're working on

...e issue of cleaning up disks in general is a hard one to solve. > > With the OpenStack backend we try our best as long as virt-v2v > exits on a normal failure path: > > > https://github.com/libguestfs/libguestfs/blob/e2bafffce24cd8c0436bf887ee166a3ae2257bbb/v2v/output_openstack.ml#L370-L384 > > However there are always going to be cases where that is not possible > (eg. virt-v2v segfaults or is kill -9'd or whatever), and in that case > I envisaged for OpenStack some sort of external garbage collector. To > this end, disks which have not been finalized are giv...