You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
(7) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(7) |
2006 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
(5) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(17) |
Nov
(18) |
Dec
(1) |
2007 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(1) |
2008 |
Jan
(17) |
Feb
(20) |
Mar
(8) |
Apr
(8) |
May
(10) |
Jun
(4) |
Jul
(5) |
Aug
(6) |
Sep
(9) |
Oct
(19) |
Nov
(4) |
Dec
(35) |
2009 |
Jan
(40) |
Feb
(16) |
Mar
(7) |
Apr
(6) |
May
|
Jun
(5) |
Jul
(5) |
Aug
(4) |
Sep
(1) |
Oct
(2) |
Nov
(15) |
Dec
(15) |
2010 |
Jan
(5) |
Feb
(20) |
Mar
(12) |
Apr
|
May
(2) |
Jun
(4) |
Jul
|
Aug
(11) |
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
|
2011 |
Jan
(8) |
Feb
(19) |
Mar
|
Apr
(12) |
May
(7) |
Jun
(8) |
Jul
|
Aug
(1) |
Sep
(21) |
Oct
(7) |
Nov
(4) |
Dec
|
2012 |
Jan
(3) |
Feb
(25) |
Mar
(8) |
Apr
(10) |
May
|
Jun
(14) |
Jul
(5) |
Aug
(12) |
Sep
(3) |
Oct
(14) |
Nov
|
Dec
|
2013 |
Jan
(10) |
Feb
(4) |
Mar
(10) |
Apr
(14) |
May
(6) |
Jun
(13) |
Jul
(37) |
Aug
(20) |
Sep
(11) |
Oct
(1) |
Nov
(34) |
Dec
|
2014 |
Jan
(8) |
Feb
(26) |
Mar
(24) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(28) |
Oct
(4) |
Nov
(4) |
Dec
(2) |
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(13) |
Jul
|
Aug
(3) |
Sep
(8) |
Oct
(11) |
Nov
(16) |
Dec
|
2016 |
Jan
|
Feb
(6) |
Mar
|
Apr
(9) |
May
(23) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(3) |
Jun
|
Jul
(3) |
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
(3) |
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
(2) |
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
(1) |
|
|
|
|
|
|
From: <ana...@ko...> - 2006-04-30 05:28:07
|
МАЙСКАЯ АКЦИЯ Только для фирм, чей профиль: Тренинги, Семинары, Недвижимость Если вы ещё до сих пор не наш клиент Бесплатная пробная .E.-.m.a.i.l .р.а.с.с.ы.л.к.а ждёт вас Спешите!!! Попробовав качество наших услуг - вы станете нашим постоянным клиентом навсегда!!! Напишите нам с пометкой в теме письма что вы по поводу акции May...@Ho... Только несколько первых написавших получат бесплатную р.а.с.с.ы.л.к.у В письме укажите род деятельности и конт. данные |
From: Steve H. <S.W...@ec...> - 2006-04-02 10:13:11
|
I think what youre discovering is that the TCP support doesn't work, noon= e up til now has really used it, and not many other OSC implementation support it. However some people have mentioned recently that they'd like it, so there is some hope it will get fixed eventaully. - Steve On Sun, Apr 02, 2006 at 02:21:21 +0200, Sz=E9kelyi Szabolcs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > [please Cc me again] >=20 > Hi, >=20 > I'm not sure I understand the usage of lo_send_from(). When sending fro= m > a TCP server, it gives errors ("Broken pipe"). When send_data() chooses > which file descriptor to write the data to, it uses from->socket if fro= m > is not NULL. But (for TCP sockets) from->socket is in a LISTENING state > (ie. (it should be) blocked on accept()), so writing data into it makes > not much sense. connect() should be called first, but it would result i= n > an error ("Transport endpoint is already connected"). Or, we could > create a new socket, bind() it to the same port as the server is bound > to... Ooops, the server is already bound to that port. :-S What about > completely disabling lo_send_from() for TCP servers? :'( >=20 > Shouldn't be there a check in send_data() to make sure protocol of the > "from" server matches the protocol specified in the target address? >=20 > If someone has time, please play around with this to confirm my experie= nces. >=20 > Simple test case attached. Which shows a(nother) bug: > lo_message_get_source() returns "empty" addresses for TCP sources when > called from a method handler (or maybe from other places, too). Changin= g > both protocols to UDP makes everything work fine. >=20 > Thanks, bye > - -- > Szabolcs >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) >=20 > iD8DBQFELxkBGJRwVVqzMkMRAiibAJ9KL+5Tk+qtOoq3y5Lpn8rdU09CdwCfaaFY > 8Wh8nTWpOjHZZrrcG1evx20=3D > =3DbzDv > -----END PGP SIGNATURE----- |
From: <cc...@ma...> - 2006-04-02 00:21:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [please Cc me again] Hi, I'm not sure I understand the usage of lo_send_from(). When sending from a TCP server, it gives errors ("Broken pipe"). When send_data() chooses which file descriptor to write the data to, it uses from->socket if from is not NULL. But (for TCP sockets) from->socket is in a LISTENING state (ie. (it should be) blocked on accept()), so writing data into it makes not much sense. connect() should be called first, but it would result in an error ("Transport endpoint is already connected"). Or, we could create a new socket, bind() it to the same port as the server is bound to... Ooops, the server is already bound to that port. :-S What about completely disabling lo_send_from() for TCP servers? :'( Shouldn't be there a check in send_data() to make sure protocol of the "from" server matches the protocol specified in the target address? If someone has time, please play around with this to confirm my experiences. Simple test case attached. Which shows a(nother) bug: lo_message_get_source() returns "empty" addresses for TCP sources when called from a method handler (or maybe from other places, too). Changing both protocols to UDP makes everything work fine. Thanks, bye - -- Szabolcs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFELxkBGJRwVVqzMkMRAiibAJ9KL+5Tk+qtOoq3y5Lpn8rdU09CdwCfaaFY 8Wh8nTWpOjHZZrrcG1evx20= =bzDv -----END PGP SIGNATURE----- |