libsigcx-main Mailing List for libSigC++ Extras (Page 4)
Status: Beta
Brought to you by:
rottmann
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(6) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
(3) |
2004 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
(5) |
Jun
(34) |
Jul
(1) |
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
(5) |
May
(10) |
Jun
(1) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2006 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christer P. <pa...@no...> - 2004-05-30 17:42:19
|
Hi Martin! Martin Schulze wrote: > > Which classes from libSigCX do you need? At some time I had some > random thoughts about libSigCX & sigc++-2.0 - Some things should be > much easier to implement with the new API. > My app depends rather heavily on SigCX::GtkDispatcher and SigCX::ThreadTunnel to do cross-thread signalling. I also pass around a lot of signal arguments by reference, so I also depend on beeing able to have fully synchronous signals. Perhaps it would be a good idea to extend the existing Glib::Dispatcher mechanism to provide the functionality of SigCX? IMO, Glib::Dispatcher is rather useless in its current form, and yet, cross-thread signalling is definitely one of the, if not _the_, most convenient and elegant way of doing multithreaded gtkmm programming... -- Christer Palm |
From: Andreas R. <a.r...@gm...> - 2004-05-30 16:29:59
|
Martin Schulze <mar...@hi...> writes: > Am 2004.05.30 14:21 schrieb(en) Christer Palm: >> Hi! >> >> I'm (finally) moving over to gtkmm 2.4, but I can't find a libSigCX >> package to match sigc++-2.0 used in 2.4. It appears that it only >> supports sigc++-1.2. > > That's right. I think libSigCX is being maintained by Andreas Rottmann. > I didn't hear of any plans to port it to sigc++-2.0 > Right, I've mostly stalled development of libsigcx, but with a helping hand, I might invest a bit of effort to make it work on sigc++ 2.0. (I mainly waited to see if there would be any demand at all :). >> I tried to simply tweak configure.ac to make it build against the >> sigc++-2.0 package, but it doesn't compile, unfortunately. > > libSigCX depends on internal structures of sigc++-1.2. Since sigc++-2.0 > has been written from scratch the internal structure is completely > different. > >> Does anyone have any updates on the status of libSigCX or otherwise >> have any experience that could help me out? > > Which classes from libSigCX do you need? At some time I had some > random thoughts about libSigCX & sigc++-2.0 - Some things should be > much easier to implement with the new API. > I've thought about moving the sigcx functionality into Yehia[0] when switching to sigc++ 2.0. [0] http://ucxx.sf.net Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 To iterate is human; to recurse, divine. |
From: Martin S. <mar...@hi...> - 2004-05-30 13:05:30
|
Am 2004.05.30 14:21 schrieb(en) Christer Palm: > Hi! >=20 > I'm (finally) moving over to gtkmm 2.4, but I can't find a libSigCX > package to match sigc++-2.0 used in 2.4. It appears that it only > supports sigc++-1.2. That's right. I think libSigCX is being maintained by Andreas Rottmann. I didn't hear of any plans to port it to sigc++-2.0 > I tried to simply tweak configure.ac to make it build against the > sigc++-2.0 package, but it doesn't compile, unfortunately. libSigCX depends on internal structures of sigc++-1.2. Since sigc++-2.0 has been written from scratch the internal structure is completely different. > Does anyone have any updates on the status of libSigCX or otherwise > have any experience that could help me out? Which classes from libSigCX do you need? At some time I had some random thoughts about libSigCX & sigc++-2.0 - Some things should be much easier to implement with the new API. Regards, Martin |
From: Christer P. <pa...@no...> - 2004-05-30 12:21:16
|
Hi! I'm (finally) moving over to gtkmm 2.4, but I can't find a libSigCX package to match sigc++-2.0 used in 2.4. It appears that it only supports sigc++-1.2. I tried to simply tweak configure.ac to make it build against the sigc++-2.0 package, but it doesn't compile, unfortunately. Does anyone have any updates on the status of libSigCX or otherwise have any experience that could help me out? -- Christer Palm |
From: Mark W. <mw...@ll...> - 2004-03-05 19:28:44
|
confirm 670201 |
From: Andreas R. <a.r...@gm...> - 2004-02-27 16:49:12
|
"Daniel Verret" <dan...@qc...> writes: > Thank for your inputs I appreciate it. > > > > First, if I can manage to build the libsigcx.dll using Cygwin, does that > mean I will be able to use it with a VC6 project. I mean can an > executable produced with VC6 link with such a dll? What would be the > header file to use? > No, I'm almost sure you can't. You must use the same compiler suite for your whole project - this means either all Cygwin or all VC6. If you manage to build libsigcx ith Cygwin, however, I think you have really good chances for suceeding in creating a VC6 project file for it (assuming familiarity with such an undertaking). > > Now, I'm not there yet. What I did so far is installed the > libsigc++-1.2.5 files on my computer. In Cygwin I have configure, make > and make install libsigc++ and the process went through no problem. Now > I have a cygsigc-1.2-5.dll. Then I configure libsigcx-0.6.4 and it was > OK. When I try to make it then I have the following error message: > I've only blank lines where there error message was supposed to be (My mailer is configured to only display the text part of html+text messages, as commonly sent by Outlook). Please consider using text-only messages and perhaps also reading http://www.netmeister.org/news/learn2quote.html. Note that there is a mailing list for libsigcx: http://lists.sourceforge.net/lists/listinfo/libsigcx-main. > Is there anything I should do? > Well, see above ;-) Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Make free software, not war! |
From: Andreas R. <a.r...@gm...> - 2004-02-26 22:34:43
|
"Daniel Verret" <dan...@qc...> writes: > Hi, > >=20=20 > > I want to use try the libsigcx examples but I can't get the installation > right. I'm working on windows 2000/XP and use MSVC 6.0. I have download > and installed the libsigc++-1.2.5 and configure - make - make install it > with Cygwin and then I went back to MSVC 6.0 to build the dll (using the > provided files) that I can now use in the libsigc++ examples. > I'm not familiar with building libsigc++ under Win32. Doesn't Cygwin produce a .dll? > When I downloaded libsigcx I tried to configure it but it looks like > there are some Error messages near the end. I have run the make and > make install > This won't get you anywhere without completing the configure run first. > anyway but there is no MSVC 6.0 project file or .lib or > .dll file I can use. I know there is something missing in the > process. > Under Cygwin, there should be nothing "missing in the process", it just appears that libsigcx doesn't compile out of the box under Cygwin. > Is there an installation/compilation guide I can use with my > configuration? > Not yet (apart from the usual Un*x ./configure && make && make install cycle). libsigcx has not yet been ported to MSVC, AFAIK. I don't have access to a Windows (or Cygwin for that matter) development environment, but maybe I could figure things out from the error messages (from the configure run under Cygwin). PS: General advice: *always* include error messages in problem reports. Regards, Andy --=20 Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.= at http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B= 62 Latein ist das humanoide =C3=84quivalent zu Fortran. -- Alexander Bartolich in at.linux |
From: Stephan R. <sr...@ev...> - 2003-12-11 19:49:57
|
Andreas, thank you for your fast response. I'm seriously thinking of using 'your' lib for an ambitious project, so it is nice to see there is some life here... BTW: *visible* event based programming for synchronizing threads and communication between them is new for me regarding C++: I've used it unvisibly while programming a VC++ GUI some time ago though (at least I think so ;-) ) and I've some experience with C++ thread programming. Greetings, Stephan Andreas Rottmann wrote: > Stephan Rudlof <sr...@ev...> writes: > > >>> Roland Welker <roland@mm...> writes: >>> >>> > Hi, >>> > >>> > I am working on a project, where I send Signals between threads >>> > in a non blocking way. However, I would like to know, how many >>> > SIgnals are currently in the queue: >>> > >>> > The application would be something like if n signals have been >>> > queued, block the next call (or fail it), or, even better, emit >>> > a signal to my self (emitting thread). >>> > >>> Well, the number of signals pending could be counted and provided via >>> a Tunnel method. I'm not really sure if this really make sense, since >>> there is already a (not exactly specifiable) maximum number of pending >>> signals, since the callback info (about 2 machine words) is written to >>> a pipe which doesn't have unlimited buffer space (so further signals >>> will block). >> >>If I've understood correctly, signals can be many kinds of C++-objects. >>Is there a limitation in their size? If so: is there a possibility to >>get the limits (for inner thread and between threads cases)? >> > > There is no size limit, as the callback is passed as a pointer. There > is only an inherent limit of the number of signals that can be in the > queue at a given time due to the use of a pipe. > > Andy -- Stephan Rudlof (sr...@ev...) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3 |
From: Andreas R. <a.r...@gm...> - 2003-12-10 09:37:44
|
Stephan Rudlof <sr...@ev...> writes: >> Roland Welker <roland@mm...> writes: >> >> > Hi, >> > >> > I am working on a project, where I send Signals between threads >> > in a non blocking way. However, I would like to know, how many >> > SIgnals are currently in the queue: >> > >> > The application would be something like if n signals have been >> > queued, block the next call (or fail it), or, even better, emit >> > a signal to my self (emitting thread). >> > >> Well, the number of signals pending could be counted and provided via >> a Tunnel method. I'm not really sure if this really make sense, since >> there is already a (not exactly specifiable) maximum number of pending >> signals, since the callback info (about 2 machine words) is written to >> a pipe which doesn't have unlimited buffer space (so further signals >> will block). > > If I've understood correctly, signals can be many kinds of C++-objects. > Is there a limitation in their size? If so: is there a possibility to > get the limits (for inner thread and between threads cases)? > There is no size limit, as the callback is passed as a pointer. There is only an inherent limit of the number of signals that can be in the queue at a given time due to the use of a pipe. Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 This reality is really just a fucked-up dream -- Papa Roach |
From: Stephan R. <sr...@ev...> - 2003-12-10 00:15:30
|
Hello Andreas, I have a question going into the same direction: > From: Andreas Rottmann <a@gm...> > Re: Signal Queue Length > 2003-06-23 05:32 > > Roland Welker <roland@mm...> writes: > > > Hi, > > > > I am working on a project, where I send Signals between threads in a non > > blocking way. > > However, I would like to know, how many SIgnals are currently in the queue: > > > > The application would be something like if n signals have been queued, block > > the next call (or fail it), or, even better, emit a signal to my self > > (emitting thread). > > > Well, the number of signals pending could be counted and provided via > a Tunnel method. I'm not really sure if this really make sense, since > there is already a (not exactly specifiable) maximum number of pending > signals, since the callback info (about 2 machine words) is written to > a pipe which doesn't have unlimited buffer space (so further signals > will block). If I've understood correctly, signals can be many kinds of C++-objects. Is there a limitation in their size? If so: is there a possibility to get the limits (for inner thread and between threads cases)? Greetings, Stephan > > To convince me to implement this, I'd like to hear a real example > where this behaviour is useful or needed. > > Regards, Andy > -- > Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gm... > http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc > Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 > > Python is executable pseudocode, Perl is executable line-noise. > -- Stephan Rudlof (sr...@ev...) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3 |
From: Peter G. <pg...@de...> - 2003-09-06 22:34:47
|
There was something messed up with my IDE, a reinstall of libsigcx and it worked. I don't know what was up. PG On Sat, 2003-09-06 at 11:15, Peter Gasper wrote: > I included "<sigcx/thread_tunnel.h>" and my compiler complained about > not finding sigcxconfig.h (which is included within thread_tunnel.h). > > I looked around and it wasn't in the include directory anywhere. I then > looked into the directory where I compiled libsigcx and it was there. > Moving the file to /usr/local/include/libsigcx-0.6/ took care of the > compiler error, though I haven't tested to see if anything works yet. > > I didn't get any errors during installation that I remember. Did > something go wrong, or did I just miss a direction somewhere? -- Peter Gasper <pg...@de...> |
From: Peter G. <pg...@de...> - 2003-09-06 17:15:13
|
I included "<sigcx/thread_tunnel.h>" and my compiler complained about not finding sigcxconfig.h (which is included within thread_tunnel.h). I looked around and it wasn't in the include directory anywhere. I then looked into the directory where I compiled libsigcx and it was there. Moving the file to /usr/local/include/libsigcx-0.6/ took care of the compiler error, though I haven't tested to see if anything works yet. I didn't get any errors during installation that I remember. Did something go wrong, or did I just miss a direction somewhere? -- Peter Gasper <pg...@de...> |
From: Andreas R. <a.r...@gm...> - 2003-08-20 15:04:42
|
Laurent Marzullo <mar...@la...> writes: [Note: You've mailed to libsigcx-main-admin instead of libsigcx-main] > Hello, > > I've seen in the mail archive that someone has got a problem with > creating a dll for libSigCX. > > I've got the same problem (I'm using mingw and not cygwin). > > Does someone has corrected the problem or not ? > > libtool output the following: > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 > shared libraries > > so libtool do not create the shared library > The workaround is to create a static library. Windows shared libraries (i.e. DLLs) cannot depend on other libs, as far as I understand (that's *real* crappy, IMNSHO, but well, what can you expect of this "OS"...). Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Make free software, not war! |
From: Laurent M. <mar...@la...> - 2003-08-20 14:48:59
|
Hello, I've seen in the mail archive that someone has got a problem with creating a dll for libSigCX. I've got the same problem (I'm using mingw and not cygwin). Does someone has corrected the problem or not ? libtool output the following: libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries so libtool do not create the shared library thanks -- Laurent Marzullo <mar...@la...> |
From: Andreas R. <a.r...@gm...> - 2003-07-19 18:21:51
|
"Patrik Sundberg" <pat...@te...> writes: >> Someting is going very wrong on linking... could you send me >> the output of 'objdump -xC sigcx/.libs/libsigcx-0.6.a'? > > ahh.. it's blank - no members at all (an 8 byte file..). > I attached the whole build log to this mail. > Hmm, seems libtool is at fault. Does creating a static library help (configure --disable-shared --enable-static)? Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 It's GNU/Linux dammit! |
From: Andreas R. <a.r...@gm...> - 2003-07-19 17:59:32
|
"Patrik Sundberg" <pat...@te...> writes: >> From: Patrik Sundberg [mailto:pat...@te...] >> Sent: den 19 juli 2003 18:27 >> To: 'rot...@us...' >> >> Hi! >> >> I am trying to compile your libSigCX under Cygwin and I'm not >> having much luck. I would like to ask if you know if anyone >> have tried this before? >> >> I'm not going to run my application under cygwin, but I need >> to be able to develop both under windows and unix at the >> moment, and therefore compiling under cygwin could be very nice. >> >> The lib itself compiles ok, but not the tests who I would >> like to run to see if everyting is ok. Attached is the errorlog I get. >> make[2]: Entering directory `/cygdrive/h/libsigcx-0.6.4/tests' /bin/bash ../libtool --mode=link g++ -Wall -O2 -o x_thread_test.exe x_thread_test.o ../sigcx/libsigcx-0.6.la -lpthread -L/usr/local/lib -lsigc-1.2 g++ -Wall -O2 -o x_thread_test.exe x_thread_test.o ../sigcx/.libs/libsigcx-0.6.a -L/usr/local/lib -lpthread /usr/local/lib/libsigc-1.2.dll.a -L/usr/local/lib -L/usr/local/lib x_thread_test.o(.text+0x38):x_thread_test.cc: undefined reference to `SigCX::StandardDispatcher::StandardDispatcher[not-in-charge]()' x_thread_test.o(.text+0x5f):x_thread_test.cc: undefined reference to `SigCX::ThreadTunnel::ThreadTunnel[in-charge](SigCX::Dispatcher&, SigCX::ThreadTunnel::Mode)' ... Someting is going very wrong on linking... could you send me the output of 'objdump -xC sigcx/.libs/libsigcx-0.6.a'? Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Python is executable pseudocode, Perl is executable line-noise. |
From: Andreas R. <a.r...@gm...> - 2003-06-23 13:59:22
|
Roland Welker <ro...@mm...> writes: > Fairly simple, one thread holds a GUI (i.e. is the complete user interface), > the other task(s) is(are) executing the "hard work". The plan was, that the > GUI is completly independend (and non blocking) of the functionality. The > problem is, that some calculations might take a longer time (non of the > current implemented one has this problem, but you never knwo:-)). > Furthermore, I want to avoid, that a user starts clicking around, if there > seems nothing to happen any more. > Conclution, after n signals have been queued, a simple message to the user, > informing him, that there are currently jobs processed, and giving him the > option to queue more, or wait till the queue is empty again. > OK, this seems reasonable. I'll add a method returning the number of pending callbacks in the next release (and as soon as I've some time in CVS). Of course I welcome patches ;-) Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 This reality is really just a fucked-up dream -- Papa Roach |
From: Roland W. <ro...@mm...> - 2003-06-23 13:09:14
|
On Monday 23 June 2003 1:32 pm, Andreas Rottmann wrote: > Roland Welker <ro...@mm...> writes: > > Hi, > > > > I am working on a project, where I send Signals between threads in a non > > blocking way. > > However, I would like to know, how many SIgnals are currently in the > > queue: > > > > The application would be something like if n signals have been queued, > > block the next call (or fail it), or, even better, emit a signal to my > > self (emitting thread). > > Well, the number of signals pending could be counted and provided via > a Tunnel method. I'm not really sure if this really make sense, since > there is already a (not exactly specifiable) maximum number of pending > signals, since the callback info (about 2 machine words) is written to > a pipe which doesn't have unlimited buffer space (so further signals > will block). > > To convince me to implement this, I'd like to hear a real example > where this behaviour is useful or needed. > Fairly simple, one thread holds a GUI (i.e. is the complete user interface), the other task(s) is(are) executing the "hard work". The plan was, that the GUI is completly independend (and non blocking) of the functionality. The problem is, that some calculations might take a longer time (non of the current implemented one has this problem, but you never knwo:-)). Furthermore, I want to avoid, that a user starts clicking around, if there seems nothing to happen any more. Conclution, after n signals have been queued, a simple message to the user, informing him, that there are currently jobs processed, and giving him the option to queue more, or wait till the queue is empty again. Roland > Regards, Andy -- Roland Welker System Administrator MMS Graphics 6 Tyock Ind. Est Elgin, Moray IV30 1XY |
From: Andreas R. <a.r...@gm...> - 2003-06-23 12:32:27
|
Roland Welker <ro...@mm...> writes: > Hi, > > I am working on a project, where I send Signals between threads in a non > blocking way. > However, I would like to know, how many SIgnals are currently in the queue: > > The application would be something like if n signals have been queued, block > the next call (or fail it), or, even better, emit a signal to my self > (emitting thread). > Well, the number of signals pending could be counted and provided via a Tunnel method. I'm not really sure if this really make sense, since there is already a (not exactly specifiable) maximum number of pending signals, since the callback info (about 2 machine words) is written to a pipe which doesn't have unlimited buffer space (so further signals will block). To convince me to implement this, I'd like to hear a real example where this behaviour is useful or needed. Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Python is executable pseudocode, Perl is executable line-noise. |
From: Roland W. <ro...@mm...> - 2003-06-23 12:08:32
|
Hi, I am working on a project, where I send Signals between threads in a non blocking way. However, I would like to know, how many SIgnals are currently in the queue: The application would be something like if n signals have been queued, block the next call (or fail it), or, even better, emit a signal to my self (emitting thread). Thanks a lot Roland -- Roland Welker System Administrator MMS Graphics 6 Tyock Ind. Est Elgin, Moray IV30 1XY |
From: Andreas R. <a.r...@gm...> - 2003-06-10 14:04:31
|
Maurizio Umberto Puxeddu <mau...@ya...> writes: > hello. > > what if you need to use send signal from some thread that is create from > someone else? (for example a third party library) > You can send signals from threads that run no Dispatcher, but you need a running Dispatcher in the thread you send the signals to (or rather thread zou have the tunnel to, in sigcx terminology). If you need to build a tunnel to a thread that's created by a third-party library, you need to write a dispatcher that runs in that thread. PS: There is a seperate sigcx mailing list. Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Packages should build-depend on what they should build-depend. |
From: Andreas R. <a.r...@gm...> - 2003-06-03 18:15:19
|
Hello! [Note: I CC'ed gtkmm-list, since there were several questions about a more featureful GLib::Dispatcher, which is exactly what SigCX provides, and furthermore this release features a gtkmm example] I'm pleased to announce the release of libSigCX (also called libsigc++ extras). What is it? ---------- libSigC++ Extras is a library consisting of new features built on top of libSigC++ and features that formerly were in libSigC++ and were removed from it. The focus is on multi-threading; libSigCX provides type-safe cross-thread signal/slot support. For more information, see http://libsigcx.sourceforge.net. New in 0.6.4: ------------- * New example, showing libSigCX with gtkmm; also included in the documentation. * New static method Thread::yield(). * SignalDispatcher bugfix (potential segfault). * Performance increases in StandardDispatcher::remove() and the timeout handler processing in StandardDispatcher::run(). Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 It's GNU/Linux dammit! |
From: Andreas R. <a.r...@gm...> - 2003-04-25 10:51:49
|
Dan Alderman <d.a...@18...> writes: > Andy, > > We are running and building with Red Hat 9 here which has libtool 1.4.3 > (1.922.2.111 2002/10/23 02:54:36) and not 1.5. In your Makefile you > state that we need 1.5 as you are using the --tag option. Is this > necessary? Can we change it to use 1.4.3 instead or will I need to get > 1.5 and install in /usr/local to build libSigCX from cvs? > It is not strictly necessary; you could comment out that line int sigcx/Makefile.am, remove scipts/libtool.m4 and build with 1.4.3, however 1.5 is recommended. Regards, Andy PS: Please consider getting nto the libsigcx-main mailing list -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Make free software, not war! |
From: Andreas R. <a.r...@gm...> - 2003-01-05 18:54:45
|
Hi folks! I just released 0.5.7 of libSigCX, it is available for download from the usual place, its SF download page [0]. 0.5.7 only contains a few bug-fixes, but since I've forgotten to announce previous releases, be warned: The Dispatcher interface has changed in 0.5.6. Regards, Andy -- Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 |
From: Andreas R. <a.r...@gm...> - 2002-08-23 16:27:55
|
Hi! I am proud to release the first public version of the "SigC++ Extras" library (SigCX for short). It was formerly part of Yehia (ucxx.sf.net) and is now split out, as it started to include features that formerly were part of libSigC++. From the features list: * A full threading API, including classes for threads, semaphores, mutual exclusions and thread-private data. The API can be compiled against either POSIX Threads (pthreads) or GLib threads without affecting binary compatibilty (ABI). * A dispatcher class that provides an abstraction of a event loop and a stand-alone as well as a GTK+ based implementation. * A fully SigC++ compatible way of invoking slots in other threads, including creating proxy slots that will invoke the original slot in another thread. Furthermore, it "took over" the convert() function formerly in SigC++. If you would like me to include more abandoned features of SigC++ (such as Chain & Closure), please drop me a mail - I am happy to help out. For more information, download & build instructions and documentation please visit http://libsigcx.sourceforge.net. Regards, Andy -- Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.r...@gm... http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 |