search for: enode

Hi all, I'm looking to migrate from Shoutcast to Icecast. Our current configuration is such that we have a low bitrate encoding on port 8000, and a high bitrate encoding on 889. I've been looking through the documentation but haven't found a good way to make this happen in Icecast. We're using Darkice to stream to the server, and that does the different enodings fine, but

...f(!n->status.st.reachable) { ifdebug(SCARY_THINGS) logger(LOG_DEBUG, _("Purging node %s (%s)"), n->name, n->hostname); @@ -93,7 +93,7 @@ nnext = nnode->next; n = nnode->data; - if(!n->status.reachable) { + if(!n->status.st.reachable) { for(enode = edge_weight_tree->head; enode; enode = enext) { enext = enode->next; e = enode->data; @@ -127,7 +127,7 @@ next = node->next; c = node->data; - if(c->status.remove) { + if(c->status.st.remove) { connection_del(c); if(!connection_tree->head)...

On Mon, 24 Jan 2005 18:57:48 -0800, Josh Burley <jburley@kuci.org> wrote: > Hi all, > > I'm looking to migrate from Shoutcast to Icecast. Our current > configuration is such that we have a low bitrate encoding on port 8000, > and a high bitrate encoding on 889. I've been looking through the > documentation but haven't found a good way to make this happen in

...2() called on node N, which is overlapping Y and Z. The edges (N,Y) and (N,Z) are all-zeroes. Y and Z are overlapping and already have an interference edge. Z is just on the limit of not being conservatively allocatable: NumOpts is 8 and DeniedOpts is also 8. It is contained in NotProvablyAllocatableNodes. G.setEdgeCosts() is called and then the call stack grows with Solver->handleSetEdgeCosts(), handleRemoveEdge() into handleDisconnectEdge(), where NMd.handleRemoveEdge() is called, which decreases the DeniedOpts by one. After this, it looks like a bug to me that Z is moved to ConservativelyAllo...

..., which is overlapping Y and Z. The edges (N,Y) > and (N,Z) are all-zeroes. Y and Z are overlapping and already have an > interference edge. Z is just on the limit of not being conservatively > allocatable: NumOpts is 8 and DeniedOpts is also 8. It is contained in > NotProvablyAllocatableNodes. G.setEdgeCosts() is called and then the call > stack grows with Solver->handleSetEdgeCosts(), handleRemoveEdge() into > handleDisconnectEdge(), where NMd.handleRemoveEdge() is called, which > decreases the DeniedOpts by one. After this, it looks like a bug to me that > Z is moved t...

...bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: 27 January 2015 06:06 To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PBQP crash Hi Jonas, > * The problematic node that was spilled again, was in the ConservativelyAllocatableNodes set during reduce(). The comment in reduce() “Conservatively allocatable nodes will never spill…” indicates that perhaps this is an incorrect insertion, as the regs did in fact run out in this case. Arnaud is correct: A node should never be put into the conservatively allocatable list if there...

...illist is open to participation by everyone. To subscribe, point a web browser at: https://lists.sourceforge.net/lists/listinfo/uci-devel ..or simply send a subscription request to: uci-devel-request@lists.sourceforge.net We also have an NNTP gateway, web archives, and an IRC channel on FreeNode for discussing UCI development. More details can be found on the main project page. Some basic specifications and documentation as to the current direction of UCI development are available from the main project page. Please note that these "specifications" are preliminary and subject t...

(Second try to send this. I wonder if the first one gotten eaten by a spam filter; I'll link to patches instead of attaching them.) Here are the tincctl patches I've been working on. They apply to http://www.tinc-vpn.org/svn/tinc/branches/1.1@1545. I intend to commit them once the crypto stuff's fixed. Since they're basically done, I'm emailing them now for review and in case