similar to: [LLVMdev] To APR Or Not To APR. That is the question.

Dear All, Time to add my two cents: I think incorporating something like APR into the LLVM tree is fine, given that it works, its licensing doesn't interefere with our licensing (and doesn't give me a headache), and we can merge it into the LLVM source base relatively seamlessly (i.e. users don't need to install it before building LLVM and APR plays nice with our build system).

John, If we were to do this, I don't think that adding it to the LLVM source base is the right way to go. We would simply use "configure" to find the library and header files. The moment we put APR into our source base, it would be out of date. Keeping it up to date would not be fun for anyone and there's no reason for us to do that. Furthermore, this approach completely avoids

Reid, Adding APR as one possible implementation of lib/System makes sense, and is what I originally suggested when I brought up the question of using APR. In particular, I agree that we want to keep APR or any other similar layer encapsulated behind lib/System. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Sep 13, 2004, at 10:34 AM, Reid Spencer wrote: > John, >

Reid Spencer wrote: > John, > > If we were to do this, I don't think that adding it to the LLVM source > base is the right way to go. We would simply use "configure" to find the > library and header files. The moment we put APR into our source base, it > would be out of date. Keeping it up to date would not be fun for anyone > and there's no reason for us to

mån 2010-03-22 klockan 17:23 -0700 skrev Chris Lattner: > We generally prefer for GSoC projects that are useful to a broad range > of people or that opens llvm to a new community. My idea was to propose bringing LLVM to Inferno OS (the complement project of Plan 9 from Bell Labs). This OS has a virtual machine (called Dis) included in the kernel, which is the only option to write

Hi John, > As for instructions, I don't know of an instruction which does nothing, > won't be removed by optimization, and yet does not inhibit > optimization. Perhaps a local alloca and a volatile load or store would > do the trick? Being volatile, the compiler won't remove it (or if it > does, it's a bug, and you should file a bug report), and since it loads

Hi, John Criswell-4 wrote: > > > You may want to use LLVM Metadata features. Search for MDNode in the > doxygen docs for some information on how to create metadata. > > I use metadata information in this way: unsigned mk = Context.getMDKindID(mdtype); Value *V = MDString::get(Context,StringRef(str)); MDNode* n = MDNode::get(Context, &V, 1);

On Mar 22, 2010, at 4:34 PM, Nick Frolov wrote: >> There is a high maintenance cost to having backends in the tree (every >> codegen change requires updating all backends). Adding stuff that >> noone uses and can barely test is not goodness. > > So, proposing a backend for an unpopular architecture is not a good idea > for GSoC project in general? We generally prefer

On 10/25/10 10:43 AM, Duncan Sands wrote: > Hi John, > >> As for instructions, I don't know of an instruction which does nothing, >> won't be removed by optimization, and yet does not inhibit >> optimization. Perhaps a local alloca and a volatile load or store would >> do the trick? Being volatile, the compiler won't remove it (or if it >> does,

On 10/25/10 9:49 AM, Xinfinity wrote: > Hi, > > > John Criswell-4 wrote: >> >> You may want to use LLVM Metadata features. Search for MDNode in the >> doxygen docs for some information on how to create metadata. >> >> > I use metadata information in this way: > unsigned mk = Context.getMDKindID(mdtype); > Value *V =

On Mon, Oct 25, 2010 at 10:52 AM, John Criswell <criswell at illinois.edu> wrote: > On 10/25/10 10:43 AM, Duncan Sands wrote: >> Hi John, >> >>> As for instructions, I don't know of an instruction which does nothing, >>> won't be removed by optimization, and yet does not inhibit >>> optimization.  Perhaps a local alloca and a volatile load or

Hi, I hope I can ask my question here and get answers, hints about what might be wrong.     Googled, but got no meaningful answer     Asked GHDL developers but it's not a GHDL issue.     Thus, I arrived here     Already many thanks in advance. - System: Linux-Mint 19 - For building of GHDL, LLVM is required. - Went to apt.llvm.org - Browsed down till Ubuntu square and add the LLVM-8 deb

Hi All Though, I have used clang which is great. I am dumb in LLVM design. Will somebody be kind enough to answer Will LLVM be suitable for developing valgrind like tools? Regards --Dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130107/84a92ae4/attachment.html>

On Sun, 25 Oct 2020, Bananradion wrote: > I changed to "localhost" in the ices-config and got this error: > > EROR stream/ices_instance_stream Failed initial connect to localhost:8443 > (TLS connection can not be established because of bad certificate: Success) This might not help your situation, but there is absolutely 0 need to use TLS on localhost as the packets never

On Mon, 26 Oct 2020, Bananradion wrote: > Ok! So how can i fix this issue then? > All works great if I connect ices to port 8086, but I need it to connect to > 8443 without getting "Socket is busy". In all honesty, I don't know what that error means adn I've not tried to use TLS with Icecast. I guess you could set up two listen sockets on port 8443, one on 127.0.0.1

Hi there! It’s windows 7. It’s the initial cmd prompt I’m having trouble with, it won’t allow the program to start., as in, the window with the ice cast gui fails to start. Any help is appreciated as I’m somewhat clueless with computers 🙃 Thanks again, Jess ________________________________ From: Icecast <icecast-bounces at xiph.org> on behalf of Ashley Bernard <ashleyb1019 at

This is a proposal for either adding a new, or updating an existing command line option such that a diagnostic can optionally be produced for unused -D macros. Long-lived large projects with thousands of files and many contributors have a tendency to accumulate build options over time. As time passes some build options like macros become replaced, obsolete, or simply no longer used. At the same

http://www.matroska.org/ I just found out about this and I think it looks like a great idea. I figured some on this list would be interested. Also, speaking now without having reviewed matroska in detail, nor being involved in Ogg/Vorbis: Perhaps it would be a viable alternative for the Ogg format for Theora if nothing else. I read about the .ogg format a while back, and while I have no

I have a problem with adding my icecast-stream till the YP-directory. I don't get any error messages regarding WHY my station isn't added to the YP either. Stream URL: bananradion.bananklubben.se:8086 Hostname: bananradion.bananklubben.se <listen-socket> <port>8086</port> <!-- <bind-address>127.0.0.1</bind-address> -->

On Sun, Sep 12, 2004 at 04:21:22PM -0700, Reid Spencer wrote: > Downside: > * Makes LLVM dependent on a third party library > * Makes LLVM platform support dependent on > * Error handling in APR is somewhat strange and it could be quite > difficult for us to continue to meet the "throw std::string" > approach we have today. I vote