search for: straitjacket

Displaying 6 results from an estimated 6 matches for "straitjacket".

2006 May 17
5
Plan to free myself from AAH
Hi, I'm actually using a slightly old version of AAH with Asterisk 1.2.1, because at first install it was perfect for my moderate knowledge of Asterisk. It is working well but I gradually introduced many changes to dialplan during normal use and now I'm feeling like in a straitjacket! Moreover I'd like to have the chance to upgrade Asterisk regularly. I have not the experience to rewrite dialplan from scratch and I'd like only to clean actual AAH dialplan. I was thinking to this plan: - install another server with Red Hat 4 U3 - install PHP, MySQL and other usefuls stu...
2006 Jun 28
3
Trixbox maunual configuration
I love the added apps installed with trixbox, ARI, Web-Meetme, FOP, and Reports are great. FreePBX on the other hand, is nearly impossible to do everything with. Trying to edit the configs manually proves impossible due to the excessive use of includes and macros. It is kind of like watching someone try to bite their own ear off. Has anybody tried to wipe all the configs clean and program the
2013 Feb 06
2
[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API
...n indication that if the choice is between fixing the code and maintaining backwards compatibility then developers are free to fix the code. That doesn't mean that we should never think about the cost to downstream developers when we churn APIs, it just means that we shouldn't be held in a straitjacket by these concerns. And the cost of changing an API is that it MUST be properly documented. Whenever you make the choice to break an API, you are saying 'I am saving my time by not writing compatibility interfaces, and everyone else must rewrite their code to support my changes.' If you...
2013 Feb 06
0
[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API
...n indication that if the choice is between fixing the code and maintaining backwards compatibility then developers are free to fix the code. That doesn't mean that we should never think about the cost to downstream developers when we churn APIs, it just means that we shouldn't be held in a straitjacket by these concerns. > > And the cost of changing an API is that it MUST be properly documented. Whenever you make the choice to break an API, you are saying 'I am saving my time by not writing compatibility interfaces, and everyone else must rewrite their code to support my changes....
2013 Feb 06
0
[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API
On Feb 4, 2013, at 11:54 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 5 Feb 2013, at 01:32, Bill Wendling wrote: > >> No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes haven't made it there though). > > The attributes API has
2013 Feb 05
3
[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API
On 5 Feb 2013, at 01:32, Bill Wendling wrote: > No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes haven't made it there though). The attributes API has undergone a horrendous amount of churn over the last few months, both before and after the 3.2 release. I've lost