I probably should have started it as a rc branch, especially given the large
number of changes that ended up going in already, but I made one now.
I did not want to change api/interfaces in 7.0.1, but yes, we should at least
check openssl/gnutls return codes, and the exception stuff does need to b
I think I have all the changes needed for a 7.0.1 release in now.
I did bring in some downstream patches from Debian, and minimally fixed
support for openssl 1.1. A lot of the rest was code cleanup and a few small
bug fixes, as well as getting rid of some obsolete build things we had
accumulated.
The short answer, for Jeffrey Walton, is Yes.
The reference codebase has been and will be hosted with git on Savannah. It
is only up to 7.0.0 presently. I am going to bring in changes originally
proposed for 7.0.1, and then start on a 7.0.2 release with additional patches
and fixes from that. A
I was able to qa the string patch sfl is using sufficiently to include in the
next release...
On Monday, September 01, 2014 04:55:19 PM Tristan Matthews wrote:
> Hi,
>
> - Original Message -
>
> > From: "Dominyk Tiller"
> > To: bug-commoncpp@gnu.org
> > Sent: Sunday, August 31, 2014 8:
The first we already seem to already have in the current and/or for the next
release. I think there has always been some confusion about the role of
UCOMMON_EXTENDED and what we were doing for facilitating special case builds
for deeply embedded services, such as putting sipwitch onto routers.
Please confirm with 5.5.0 and/or 6.0.0. I believe all original bsd
build issues were closed by 5.5.0, and 6.0.0 has also been tested with
and fixed for clang.
On 11/11/2012 08:57 AM, oth...@safetymail.info wrote:
> You guys have always been helpful in resolving issues with the GNU Telephony
> pac
and I would love to see it adopt srtp and zrtp.
On 04/05/2012 12:11 PM, Tristan Matthews wrote:
> - Original Message -
>> From: "David Sugar"
>> To: bug-commoncpp@gnu.org
>> Sent: Wednesday, April 4, 2012 2:10:58 PM
>> Subject: Re: "gaurd"
>> I do recall sflphone and I would love to see it adopt srtp and zrtp.
>
> We do currently support srtp and zrtp, albeit with an older version of ccrtp.
Very cool, and I did not know
At the very least we (I mean as in GNU Telephony) should be mentioning it...
_
I actually almost hate these kind of errors, because they nonetheless do
touch upon linkage abi. Actually it is probably a good time to
consider what will become 6.0, which offers a good opportunity to also
consider depreciating/changing/break other abi issues. I have thought
about re-organizing
I would be happy to take this patch in for the next release. I will
also have to see if this applies to ucommon. I see there we currently have:
#ifdef _MSWINDOWS_
unsigned Socket::pending(socket_t so)
{
u_long opt;
if(so == INVALID_SOCKET)
return 0;
ioctlsocket(so, FIONREAD,
bugs or issues.
On 06/05/2010 03:51 PM, Leon Pollak wrote:
> On Saturday June 5 2010, David Sugar wrote:
>> First, the queue core class can use a reusable pool, but this is for
>> internal management of it's own pointers. The queue is passed an object
>> to post into it th
(of the same size) polled from
> buffer pool (which classes?).
> Then A sends these buffers to B (which classes).
> B receives buffers, process them and returns to the pool.
>
> Just, please, name the classes, i will try to understand how to use them...
>
> Thanks again.
&g
The queue class was written because there are some older Bayonne drivers
that would likely make use of it when the rest of Bayonne is ported to
ucommon, and it is also based on some stuff also used in the original
Common C++. However, those drivers (in particular, Dialogic and Pika,
which used an
Probably instead, connect methods should actually do this if the so is
invalid when they are called. If we do fail to connect, we should
release the resource as we do now. If we decide to close/delete the
object on a connect failure, then we would not be waisting resources
acquiring a brand new s
Maybe this can be wrapped in a configure library test to make sure there
really is a "clock_nanosleep()" to link with? I should see if this is
relevant to ucommon as well...
Reinhard Drube wrote:
> for Solaris one need a change in
>
> src/timer.cpp:
>
> 130,131c130
> < // ::clock_nanoslee
I had been largely away the last few months, and I have also been at
times off-grid, working with various American Indian groups, two of whom
have now formally withdrawn, and others who are in the process of
formally withdrawing, from treaty with the governments of the United
States and Canada. I
When a new thread is created, it records the thread instance it was
created from, and this becomes the "parent" reference. However, using
notify requires that the parent does not dissapear (get deleted) before
it's child, and requires tracking of thread meta data. For these
reasons, I actuall
early as
June.
Conrad T. Pino wrote:
The project's founder David Sugar http://savannah.gnu.org/users/dyfet
has migrated the project's home from time to time which means you'll
find it and the code in multiple locations; for example:
http://sourceforge.net/projects/cplusplus/
http://w
The 1.0 release of UCommon was distributed this afternoon. This release
includes full doxygen generated interface documentation, which may be
viewed online at http://www.gnutelephony.org/doxy/ucommon. The
distribution tarball may be found at
http://www.gnutelephony.org/dist/archive/ucommon-1.0.0.
Normally you would load each [] into a different keydata object. If you
merge keydata sections into a single object instance, there is no means
to determine which instance it was loaded under. Mostly merging is
meant to load "default" keys into a given object, and then override them
with live val
What attach does is dissasociate the controlling terminal and
potentially associate with a new one under a new process group. The
same code is reused for detach, which does the dissociate and single
fork on some platforms, and a dual fork on others.
Wolfgang Alper wrote:
> Hello,
>
> Sorry, i ju
There is a new security sip proxy which apparently uses Common C++ core
classes and ccrtp. I wonder if anyone has looked at this project yet
(http://www.sip-soxy.org). It also reminds me why we have to be careful
when thinking about any major changes in GNU Common C++ so that we do
not break "ups
is multithread, actually only 1 thread can execute until
> the library function exits (it isn't a fix execution time), so it's a
> fake multithread and performance speed is heavily penalized indeed.
> To have this working, I have to increase the couter of the semaphore?
> Can you
s context?
>> Thanks,
>> Carlo
>>
>> David Sugar ha scritto:
>>> I think what he really wants to do is use the Common C++ Semaphore with
>>> a count of 1, since semaphore can block with a "timeout", and with a "1"
>>> count in effe
This seemed like a good time to discuss some current ideas for common
c++ 2.0...
First, I have wanted to make object management smarter, and borrow a
little from objective-c. Hence, we will have a new commonly used
virtual base class, "Object", which will include a release() virtual.
This can be
I will see if this is still true with 1.5.5...
Alan Mizrahi wrote:
> Hello,
>
> Unfortunately commoncpp2-1.5.0 doesn't build when using -fstack-protector gcc
> flags.
> The stack protector flags are supported in gcc 4.1.1, could you verify this?
>
> Regards,
>
begin:vcard
fn:David Sugar
n:Suga
ick...we should have changed the abi rev level then...it got missed...
Mark Purcell wrote:
> David,
>
> It would appear that commoncpp2-1.5.3 isn't ABI compatible with previous
> releases due to changes with ost::Thread::isRunning
>
> http://bugs.debian.org/402009
>
> Mark
>
> -- Fo
This was already removed in 1.5.3...
Mark Purcell wrote:
> David,
>
> I have received a report about your install-local-data rule in libcommoncpp2.
>
> Apparently you have made some assumptions about the target directory, which
> isn't always correct.
>
> The full bug report is available at ht
This will break abi, so I will do it for a new 1.6 release set...
Mark Purcell wrote:
>
> -- Forwarded Message --
>
> Subject: Fwd: Bug#352123: libcommoncpp2-dev: slog should not cut after 128
> bytes
> Date: Friday 10 February 2006 11:07
> From: Mark Purcell <[EMAIL PROTECTED
I think what he really wants to do is use the Common C++ Semaphore with
a count of 1, since semaphore can block with a "timeout", and with a "1"
count in effect acts as a mutex...
The larger question though of what to do with the stuck thread, perhaps
from a broken library, is important also. He
I already changed it for the next release :)
[EMAIL PROTECTED] wrote:
OK, I'll fix up the source and post patches when I get a chance to do that.
Should be before the end of the week.
Cheers,
Erik.
-Original Message-
From: David Sugar [mailto:[EMAIL PROTECTED]
Sent: M
class are
consistent.
How do you want it? Make them all ost::PersistException?
Just let me know, and I'll do the editing from the last release sources and
patch file providing.
Erik.
-Original Message-
From: David Sugar [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 12, 2006 4:0
Originally persist had a completely different exception system of it's
own at a time that Common C++ did not have a standardized exception
model, as the code has separate origin. I you are correct that it
should be consolidated for consistency. This was probably overlooked
when that was initi
Some may have been related to behaviors found originally in much older
platform sdk's and never updated...
INADDR_NONE is usually used to "disconnect" the socket from any active
connection. But if setting broadcast is nessisary, then certainly it
can be done. However, then the socket may be
I have been asked about the possibility of speaking in Maracaibo at the
end of next month, and perhaps doing a workshop in Caracas, and I am
curious if we have anyone from that part of the world represented here.
David
begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
adr:;;USA
The other config.h is generated from configure.ac, so really then these
defines should migrate into something emitted from
configure.ac...perhaps wrapped in a #ifdef WIN32 block
Holger Tasch wrote:
Hello List,
a problem occured while trying to build commoncpp2-1.3.19 in MSYS with MINGW
(a
Hmm...I think I removed the d naming so that later one could substitute
the debug version for testing of an app by changing the PATH, without
having to use a different link name. This was otherwise causing all
sorts of headaches in Bayonne's w32 build and testing because I could
not directly s
alf Of
Conrad T. Pino
Sent: Wednesday, August 31, 2005 19:54
To: David Sugar
Cc: Bug Common C++
Subject: Microsoft w32/tests/*.dsp Projects Question
Hi David,
The "tests" programs build on Linux but they are omitted
from both Microsoft "common.dsw" and "common.sln"
At one time, when machine speeds were still measured in mghz, and g++
was still rather slow to compile, this was done to save on time waiting
for the package to build. After all, nobody building just to install
wanted to also wait to build the demos and test programs they were not
using. To m
There is a configure option --without-compression, which gets rid of the
need for libz. There is also --without-libxml2. If your not using
exceptions, you might want to use --without-exceptions as well...
All you really need to do is make sure the resulting arm libcc* files
are on a valid li
ickly.
Conrad T. Pino wrote:
Hi David,
From: David Sugar
Sent: Monday, August 29, 2005 21:50
The other question to confirm is whether something links with it (such
as the demo apps). That is where interesting things could be quickly
identified, particularly I find in the windows builds on any
. Pino
Sent: Monday, August 29, 2005 11:38
From: David Sugar
Sent: Monday, August 29, 2005 07:48
This may be readyI was actually looking for something to consider
for a point release today since I am also doing a new cape build, and
resolving this problem is very worth considering.
The
Debian package system.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Sugar
Sent: Monday, August 29, 2005 13:32
To: Conrad T. Pino
Cc: Bug Common C++
Subject: Re: No "configure" script in CVS?
configure is generated in a cvs
A later step in reconfig automatically rebuilds aclocal.m4. You can
ignore that message.
Conrad T. Pino wrote:
When I run "./reconfig" immediately after a CVS checkout I get this message:
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
A subsequent run in the
configure is generated in a cvs checkout from ./reconfig
Conrad T. Pino wrote:
Hi David,
There is no "configure" script in the CVS archive.
How do I bring one into existence on Linux 2.6?
Conrad
begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
adr:;;USA
email;internet:[EMAIL PR
This may be readyI was actually looking for something to consider
for a point release today since I am also doing a new cape build, and
resolving this problem is very worth considering.
Conrad T. Pino wrote:
Hi David,
From: David Sugar
Sent: Thursday, August 25, 2005 13:52
To: Conrad T
,
-Original Message-
From: David Sugar
Sent: Thursday, August 25, 2005 04:48
To: Conrad T. Pino
Cc: Bug Common C++
Subject: Re: ccgnu2 - Win32 Microsoft Compiler Warnings
I had wondered if there was a more elegant way of handling the platform
sdk version, as it seems the older and newer sdk
Not at all. I simply have not tested with vc6 without the later
platform sdk's for so very long that it is quite possible it is now
broken. This sounds like a useful patch.
Conrad T. Pino wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I presume it's well known the HEAD revision does
I had wondered if there was a more elegant way of handling the platform
sdk version, as it seems the older and newer sdk have mutually exclusive
requirements for the ordering of header files...for the moment the
distribution assumes the newer sdk is installed by default.
Conrad T. Pino wrote:
This sounds good too! I know we had in the past a few people using bcc,
which is where the Makefile for Borland originally came from, but they
had not submitted updates in recent times. I do think supporting many
different compilers (beyond gcc) is very useful as a matter of principle
as each
yes.
Conrad T. Pino wrote:
OK, I'm taking that to mean the SourceForge "gnutelephony" project
and NOT the SourceForge "cplusplus" project.
Thank you very much.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Sugar
Sent: W
Currently we are using the sourceforge one. This was because I could
consolidate all my work and all the packages where I am the primary or
only person currently doing active changes in just one place under one
repository. The one exception is ccrtp, which is also very activily
maintained by
I think ccscript3 is essentially complete at this point. The primary
reason it remains at 0.7.x rather than 1.0 is twofold. First, I would
not be surprised to find some additional minor issues in ccscript3 as
bayonne development goes forward. But the second reason is that until a
rpl server,
bool big : 1;
110 } ministring;
111 } content;
112
113 #if defined(__GNUC__) || !defined(_AIX) && !defined(__hpux)
114 #pragma pack()
115 #endif
-Original Message-
From: David Sugar [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 07, 2005 9:50 PM
Would something like #if !defined(_AIX) || defined(__GNUC__) work?
[EMAIL PROTECTED] wrote:
FYI,
I was able to successfully compile commoncpp2-1.3.13 on AIX using
VisualAge C++ after some minor tweaking:
* include/cc++/string.h -- line 114 "#pragma pack()" wasn't liked, pack
requires
I think your right.
Migel Nick wrote:
Hi!
I think there is a bug in string.cpp in commoncpp2-1.3.12 and
previous versions.
size_t String::setSize(size_t chars)
{
if(chars <= minsize && !isBig())
return minsize;
if(chars <= slotlimit)
{
chars = chars / slotsize;
++chars *= sl
Which version of common c++? It looks like you have libc_r linked in
(user mode) rather than libpthread...
Shie Erlich wrote:
hi guys,
i have an application that was written on linux and runs flawlessly.
on freebsd, the threads just don't start.
i start them with start(), but on FreeBSD, th
I think it probably should be public...
Ken Sewell wrote:
Is there a reason that SimpleTCPStream inherits Socket as protected, while
TCPStream, UDPSocket,... all inherit it as public?
Ken Sewell Defense Research Associates
Project Engineer 3915 Germany Lane, Suite
From what I gather, depending on which version of the platform sdk you
have installed with VC++ 6.0 (whether the one it originally comes with,
or the latest one), you either MUST include windows.h before, or after
winsock2.h or everything will break. and there is no easy way to find
out which y
s for a thread when it exits.
So I think either ThreadImpl::ThreadDestructor should delete 'th' if it
determines its a detached thread, or ThreadImpl::ThreadDestructor should
not be called for an already deleted thread.
David Sugar wrote:
Ah, I think I might see...both the exit handling
LL);
before the call to th->close() in
ThreadImpl::ThreadExecHandler(Thread*th) sorts out the problem, however
I am not actually sure of the side effects of this call. Maybe is
should be conditional, depending on the detached state of the thread.
David... its over to you
Nick
David Sugar w
read.
David... its over to you
Nick
David Sugar wrote:
In older versions of the library you would use "delete this" for
detached threads. In the current (1.3) releases, you should NEVER do
this. That final() was appearently leftover from before detach
behavior was changed. In 1.?
In older versions of the library you would use "delete this" for
detached threads. In the current (1.3) releases, you should NEVER do
this. That final() was appearently leftover from before detach behavior
was changed. In 1.?2? and definately 1.3, detach deletes the the thread
the object for
as virtual, and you are not deleting objects
multiple times.
Nick
David Sugar wrote:
Hmm...perhaps it is a dynamic casting issue. The thread close method
itself is only really aware of a "Thread" object as the base class
itself, at that point in time. If it is unable to handle the
In fact, I will go a step further...Thread() is built with a virtual
destructor...it appears to me that virtual destructors are not working
correcting on your compiler. This would explain the memory offset of
the delete free() operation in Thread::close, which I am guessing is
likely the offse
Hmm...perhaps it is a dynamic casting issue. The thread close method
itself is only really aware of a "Thread" object as the base class
itself, at that point in time. If it is unable to handle the delete of
the derived virtual object by recasting the pointer references, then
perhaps the order
66 matches
Mail list logo
