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
|
3
|
4
|
5
|
6
|
7
|
8
(1) |
9
|
10
|
11
|
12
(1) |
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
(5) |
24
(4) |
25
(3) |
26
|
27
|
28
|
29
|
30
|
|
|
|
|
From: Camille T. <ca...@os...> - 2013-04-25 12:12:04
|
On 25 avr. 2013, at 13:37, Stephen Sinclair <rad...@gm...> wrote: > Great! Is homebrew's automake version 1.13? The last time I updated automaker from brew on Mac OS X it was version 1.13. |
From: Stephen S. <rad...@gm...> - 2013-04-25 11:37:43
|
On Thu, Apr 25, 2013 at 8:02 AM, NicoBats <sl1...@gm...> wrote: > Le 25/04/13 00:08, Stephen Sinclair a écrit : > >> I think he means the brew version of automake, not liblo. > > you're right > I've updated the make thanks to homebrew and indeed it works fines Great! Is homebrew's automake version 1.13? >> I did a bit of work to try and update the automake script for OS X >> 10.8 (actually, for automake 1.13) and thought I had fixed the issues, >> but if there are still problems please let me know. > > wich repo did you update? > if you want I can try to install automake 1.13 and rebuild liblo. Some small changes in commit 5fa3767, which should be included in the version you were testing. These seemed to get it to work for me under automake 1.13, but I'll need to try to do a bit more testing under OS X. Steve |
From: NicoBats <sl1...@gm...> - 2013-04-25 06:02:19
|
Le 25/04/13 00:08, Stephen Sinclair a écrit : > I think he means the brew version of automake, not liblo. you're right I've updated the make thanks to homebrew and indeed it works fines > > I did a bit of work to try and update the automake script for OS X > 10.8 (actually, for automake 1.13) and thought I had fixed the issues, > but if there are still problems please let me know. wich repo did you update? if you want I can try to install automake 1.13 and rebuild liblo. tell me. ++ > > Steve > > > On Wed, Apr 24, 2013 at 10:52 PM, NicoBats <sl1...@gm...> wrote: >> Camille, >> how do you brew the git repo of liblo? >> >> ++ >> Nicolas >> Le 24/04/13 20:33, Camille Troillard a écrit : >>> I have been experiencing tricky issues with automake on OS X. >>> >>> Reinstalling it may help. Latest version of automake on brew worked for me. >>> >>> >>> On 24 avr. 2013, at 16:09, Stephen Sinclair <rad...@gm...> wrote: >>> >>>> On Tue, Apr 23, 2013 at 8:50 PM, NicoBats <sl1...@gm...> wrote: >>>>> Steve, >>>>> Le 23/04/13 19:34, Stephen Sinclair a écrit : >>>>> >>>>>> On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: >>>>>>> Hi, >>>>>>> while trying to compile a fresh clone of the git repo (because you've >>>>>>> made lot of work since 0.26....), it appears that a 0 is missing >>>>>>> ../lo/lo_endian.h:121:5: error: expected value in expression >>>>>>> #if >>>>>>> ^ >>>>>>> 1 error generated. >>>>>> Hi, this doesn't happen for me. Can you give some system details, and >>>>>> what version of git you are using? The master is currently at >>>>>> 4e2f2a0. >>>>> it's on a mac osX.8. >>>>> lo compiled with clang >>>>> I'm not sure of the good way to retrieve the git revision number... >>>>> grandMaster:liblo nico$ git rev-parse --short HEAD >>>>> 3b81d44 >>>>> >>>>> grandMaster:liblo nico$ git rev-list HEAD --count >>>>> 276 >>>> Okay that's quite a recent version. >>>> >>>> >>>>>> Can you also post your config.log file? In particular, ubuntu 12.10 >>>>>> on my 32-bit AMD machine reports: >>>>>> >>>>>> $ grep LO_BIGENDIAN config.log >>>>>> LO_BIGENDIAN='0' >>>>>> #define LO_BIGENDIAN "0" >>>>>> >>>>>> You should get something similar. >>>>> here's what I've got >>>>> grandMaster:liblo nico$ grep LO_BIGENDIAN config.log >>>>> LO_BIGENDIAN='' >>>>> #define LO_BIGENDIAN "" >>>>> >>>>> attached the config.log >>>> Thanks, yes I see that LO_BIGENDIAN is not getting defined, but I'm >>>> afraid I can't see why that would happen. >>>> >>>> I don't have a Mac with 10.8 right now, perhaps someone else could test? >>>> There have been some autotools-related issues with 10.8. >>>> >>>> Steve >>>> >>>> ------------------------------------------------------------------------------ >>>> Try New Relic Now & We'll Send You this Cool Shirt >>>> New Relic is the only SaaS-based application performance monitoring service >>>> that delivers powerful full stack analytics. Optimize and monitor your >>>> browser, app, & servers with just a few lines of code. Try New Relic >>>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >>>> _______________________________________________ >>>> liblo-devel mailing list >>>> lib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel >>>> >>> ------------------------------------------------------------------------------ >>> Try New Relic Now & We'll Send You this Cool Shirt >>> New Relic is the only SaaS-based application performance monitoring service >>> that delivers powerful full stack analytics. Optimize and monitor your >>> browser, app, & servers with just a few lines of code. Try New Relic >>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >>> _______________________________________________ >>> liblo-devel mailing list >>> lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> liblo-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/liblo-devel > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > liblo-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/liblo-devel |
From: Stephen S. <rad...@gm...> - 2013-04-24 22:09:02
|
I think he means the brew version of automake, not liblo. I did a bit of work to try and update the automake script for OS X 10.8 (actually, for automake 1.13) and thought I had fixed the issues, but if there are still problems please let me know. Steve On Wed, Apr 24, 2013 at 10:52 PM, NicoBats <sl1...@gm...> wrote: > Camille, > how do you brew the git repo of liblo? > > ++ > Nicolas > Le 24/04/13 20:33, Camille Troillard a écrit : >> I have been experiencing tricky issues with automake on OS X. >> >> Reinstalling it may help. Latest version of automake on brew worked for me. >> >> >> On 24 avr. 2013, at 16:09, Stephen Sinclair <rad...@gm...> wrote: >> >>> On Tue, Apr 23, 2013 at 8:50 PM, NicoBats <sl1...@gm...> wrote: >>>> Steve, >>>> Le 23/04/13 19:34, Stephen Sinclair a écrit : >>>> >>>>> On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: >>>>>> Hi, >>>>>> while trying to compile a fresh clone of the git repo (because you've >>>>>> made lot of work since 0.26....), it appears that a 0 is missing >>>>>> ../lo/lo_endian.h:121:5: error: expected value in expression >>>>>> #if >>>>>> ^ >>>>>> 1 error generated. >>>>> Hi, this doesn't happen for me. Can you give some system details, and >>>>> what version of git you are using? The master is currently at >>>>> 4e2f2a0. >>>> it's on a mac osX.8. >>>> lo compiled with clang >>>> I'm not sure of the good way to retrieve the git revision number... >>>> grandMaster:liblo nico$ git rev-parse --short HEAD >>>> 3b81d44 >>>> >>>> grandMaster:liblo nico$ git rev-list HEAD --count >>>> 276 >>> Okay that's quite a recent version. >>> >>> >>>>> Can you also post your config.log file? In particular, ubuntu 12.10 >>>>> on my 32-bit AMD machine reports: >>>>> >>>>> $ grep LO_BIGENDIAN config.log >>>>> LO_BIGENDIAN='0' >>>>> #define LO_BIGENDIAN "0" >>>>> >>>>> You should get something similar. >>>> here's what I've got >>>> grandMaster:liblo nico$ grep LO_BIGENDIAN config.log >>>> LO_BIGENDIAN='' >>>> #define LO_BIGENDIAN "" >>>> >>>> attached the config.log >>> Thanks, yes I see that LO_BIGENDIAN is not getting defined, but I'm >>> afraid I can't see why that would happen. >>> >>> I don't have a Mac with 10.8 right now, perhaps someone else could test? >>> There have been some autotools-related issues with 10.8. >>> >>> Steve >>> >>> ------------------------------------------------------------------------------ >>> Try New Relic Now & We'll Send You this Cool Shirt >>> New Relic is the only SaaS-based application performance monitoring service >>> that delivers powerful full stack analytics. Optimize and monitor your >>> browser, app, & servers with just a few lines of code. Try New Relic >>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >>> _______________________________________________ >>> liblo-devel mailing list >>> lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel >>> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> liblo-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/liblo-devel > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > liblo-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/liblo-devel |
From: NicoBats <sl1...@gm...> - 2013-04-24 20:52:20
|
Camille, how do you brew the git repo of liblo? ++ Nicolas Le 24/04/13 20:33, Camille Troillard a écrit : > I have been experiencing tricky issues with automake on OS X. > > Reinstalling it may help. Latest version of automake on brew worked for me. > > > On 24 avr. 2013, at 16:09, Stephen Sinclair <rad...@gm...> wrote: > >> On Tue, Apr 23, 2013 at 8:50 PM, NicoBats <sl1...@gm...> wrote: >>> Steve, >>> Le 23/04/13 19:34, Stephen Sinclair a écrit : >>> >>>> On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: >>>>> Hi, >>>>> while trying to compile a fresh clone of the git repo (because you've >>>>> made lot of work since 0.26....), it appears that a 0 is missing >>>>> ../lo/lo_endian.h:121:5: error: expected value in expression >>>>> #if >>>>> ^ >>>>> 1 error generated. >>>> Hi, this doesn't happen for me. Can you give some system details, and >>>> what version of git you are using? The master is currently at >>>> 4e2f2a0. >>> it's on a mac osX.8. >>> lo compiled with clang >>> I'm not sure of the good way to retrieve the git revision number... >>> grandMaster:liblo nico$ git rev-parse --short HEAD >>> 3b81d44 >>> >>> grandMaster:liblo nico$ git rev-list HEAD --count >>> 276 >> Okay that's quite a recent version. >> >> >>>> Can you also post your config.log file? In particular, ubuntu 12.10 >>>> on my 32-bit AMD machine reports: >>>> >>>> $ grep LO_BIGENDIAN config.log >>>> LO_BIGENDIAN='0' >>>> #define LO_BIGENDIAN "0" >>>> >>>> You should get something similar. >>> here's what I've got >>> grandMaster:liblo nico$ grep LO_BIGENDIAN config.log >>> LO_BIGENDIAN='' >>> #define LO_BIGENDIAN "" >>> >>> attached the config.log >> Thanks, yes I see that LO_BIGENDIAN is not getting defined, but I'm >> afraid I can't see why that would happen. >> >> I don't have a Mac with 10.8 right now, perhaps someone else could test? >> There have been some autotools-related issues with 10.8. >> >> Steve >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> liblo-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/liblo-devel >> > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > liblo-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/liblo-devel |
From: Camille T. <ca...@os...> - 2013-04-24 18:44:25
|
I have been experiencing tricky issues with automake on OS X. Reinstalling it may help. Latest version of automake on brew worked for me. On 24 avr. 2013, at 16:09, Stephen Sinclair <rad...@gm...> wrote: > On Tue, Apr 23, 2013 at 8:50 PM, NicoBats <sl1...@gm...> wrote: >> Steve, >> Le 23/04/13 19:34, Stephen Sinclair a écrit : >> >>> On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: >>>> >>>> Hi, >>>> while trying to compile a fresh clone of the git repo (because you've >>>> made lot of work since 0.26....), it appears that a 0 is missing >>>> ../lo/lo_endian.h:121:5: error: expected value in expression >>>> #if >>>> ^ >>>> 1 error generated. >>> Hi, this doesn't happen for me. Can you give some system details, and >>> what version of git you are using? The master is currently at >>> 4e2f2a0. >> >> it's on a mac osX.8. >> lo compiled with clang >> I'm not sure of the good way to retrieve the git revision number... >> grandMaster:liblo nico$ git rev-parse --short HEAD >> 3b81d44 >> >> grandMaster:liblo nico$ git rev-list HEAD --count >> 276 > > Okay that's quite a recent version. > > >>> Can you also post your config.log file? In particular, ubuntu 12.10 >>> on my 32-bit AMD machine reports: >>> >>> $ grep LO_BIGENDIAN config.log >>> LO_BIGENDIAN='0' >>> #define LO_BIGENDIAN "0" >>> >>> You should get something similar. >> >> here's what I've got >> grandMaster:liblo nico$ grep LO_BIGENDIAN config.log >> LO_BIGENDIAN='' >> #define LO_BIGENDIAN "" >> >> attached the config.log > > Thanks, yes I see that LO_BIGENDIAN is not getting defined, but I'm > afraid I can't see why that would happen. > > I don't have a Mac with 10.8 right now, perhaps someone else could test? > There have been some autotools-related issues with 10.8. > > Steve > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > liblo-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/liblo-devel > |
From: Stephen S. <rad...@gm...> - 2013-04-24 14:09:58
|
On Tue, Apr 23, 2013 at 8:50 PM, NicoBats <sl1...@gm...> wrote: > Steve, > Le 23/04/13 19:34, Stephen Sinclair a écrit : > >> On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: >>> >>> Hi, >>> while trying to compile a fresh clone of the git repo (because you've >>> made lot of work since 0.26....), it appears that a 0 is missing >>> ../lo/lo_endian.h:121:5: error: expected value in expression >>> #if >>> ^ >>> 1 error generated. >>> >> Hi, this doesn't happen for me. Can you give some system details, and >> what version of git you are using? The master is currently at >> 4e2f2a0. > > it's on a mac osX.8. > lo compiled with clang > I'm not sure of the good way to retrieve the git revision number... > grandMaster:liblo nico$ git rev-parse --short HEAD > 3b81d44 > > grandMaster:liblo nico$ git rev-list HEAD --count > 276 Okay that's quite a recent version. >> Can you also post your config.log file? In particular, ubuntu 12.10 >> on my 32-bit AMD machine reports: >> >> $ grep LO_BIGENDIAN config.log >> LO_BIGENDIAN='0' >> #define LO_BIGENDIAN "0" >> >> You should get something similar. > > here's what I've got > grandMaster:liblo nico$ grep LO_BIGENDIAN config.log > LO_BIGENDIAN='' > #define LO_BIGENDIAN "" > > attached the config.log Thanks, yes I see that LO_BIGENDIAN is not getting defined, but I'm afraid I can't see why that would happen. I don't have a Mac with 10.8 right now, perhaps someone else could test? There have been some autotools-related issues with 10.8. Steve |
From: Stephen S. <rad...@gm...> - 2013-04-23 23:04:43
|
On Tue, Apr 23, 2013 at 12:50 PM, Camille Troillard <ca...@os...> wrote: > Hi Steve! > > Sorry, I was overwhelmed lately. No problem :) Sounds familiar. > After some thought, I am not sure if an option API is really needed. Wouldn't an property based API (i.e. explicit accessors to properties of lo_address, lo_server) be enough? > > I understand the attractiveness of an "abstract options" API, but I wonder if it will really solve anything, other than hiding properties behind another interface. I don't want to sound negative, I am just testing the opposite idea. So here's another suggestion: get rid of the options enums and turn them into something explicit. > > On the other hand, the benefit of the abstract options approach is that it will keep the Liblo API from growing. Only on the surface, as internally new options will need to be handled and checked anyways. > Yeah okay, I actually had the exact same concern which is why I wanted to bounce the idea around before committing to it. I do admit that I find the API is getting a little out of hand, but at the same time having explicit functions for each option makes them easy to test for using autoconf. In principle it would be nice if all of these options (especially protocol selection such as SLIP) could be expressed in liblo's URL format. Steve |
From: NicoBats <sl1...@gm...> - 2013-04-23 18:50:48
|
Steve, Le 23/04/13 19:34, Stephen Sinclair a écrit : > On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: >> Hi, >> while trying to compile a fresh clone of the git repo (because you've >> made lot of work since 0.26....), it appears that a 0 is missing >> ../lo/lo_endian.h:121:5: error: expected value in expression >> #if >> ^ >> 1 error generated. >> > Hi, this doesn't happen for me. Can you give some system details, and > what version of git you are using? The master is currently at > 4e2f2a0. it's on a mac osX.8. lo compiled with clang I'm not sure of the good way to retrieve the git revision number... grandMaster:liblo nico$ git rev-parse --short HEAD 3b81d44 grandMaster:liblo nico$ git rev-list HEAD --count 276 > Can you also post your config.log file? In particular, ubuntu 12.10 > on my 32-bit AMD machine reports: > > $ grep LO_BIGENDIAN config.log > LO_BIGENDIAN='0' > #define LO_BIGENDIAN "0" > > You should get something similar. here's what I've got grandMaster:liblo nico$ grep LO_BIGENDIAN config.log LO_BIGENDIAN='' #define LO_BIGENDIAN "" attached the config.log best regards, nicolas > > Steve > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > liblo-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/liblo-devel |
From: Stephen S. <rad...@gm...> - 2013-04-23 17:34:31
|
On Tue, Apr 23, 2013 at 10:54 AM, NicoBats <sl1...@gm...> wrote: > Hi, > while trying to compile a fresh clone of the git repo (because you've > made lot of work since 0.26....), it appears that a 0 is missing > ../lo/lo_endian.h:121:5: error: expected value in expression > #if > ^ > 1 error generated. > Hi, this doesn't happen for me. Can you give some system details, and what version of git you are using? The master is currently at 4e2f2a0. Can you also post your config.log file? In particular, ubuntu 12.10 on my 32-bit AMD machine reports: $ grep LO_BIGENDIAN config.log LO_BIGENDIAN='0' #define LO_BIGENDIAN "0" You should get something similar. Steve |
From: Camille T. <ca...@os...> - 2013-04-23 10:50:24
|
Hi Steve! Sorry, I was overwhelmed lately. After some thought, I am not sure if an option API is really needed. Wouldn't an property based API (i.e. explicit accessors to properties of lo_address, lo_server) be enough? I understand the attractiveness of an "abstract options" API, but I wonder if it will really solve anything, other than hiding properties behind another interface. I don't want to sound negative, I am just testing the opposite idea. So here's another suggestion: get rid of the options enums and turn them into something explicit. On the other hand, the benefit of the abstract options approach is that it will keep the Liblo API from growing. Only on the surface, as internally new options will need to be handled and checked anyways. Best, Cam On 12 avr. 2013, at 14:13, Stephen Sinclair <rad...@gm...> wrote: > I would like some feedback on this idea, pushed as a branch called 'options' > > Currently we now have a 'flags' API for lo_address and lo_server. > Since this seems a bit inflexible as a general "options" mechanism, > for future-proofing this design decision, I propose being able to at > least provide an argument for each option, rather than only being able > to specify boolean bitflags. > > https://github.com/radarsat1/liblo/commit/06e65feb559fe729fba077a5eb998d84d20c33cd > > In the proposal, each option is set individually with an argument, eg, > > lo_address_set_option(a, LO_ADDRESS_SLIP, (void *)1); > > As you can see, a downside of reserving the argument as a void* > pointer is that it requires an ugly cast for integer/boolean > arguments. > > I haven't figured out a better way to do this. The only other > suggestion I had was to use a union called lo_option, allowing, > > typedef union { > char *s; > void *p; > int i; > } lo_option; > > lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option)1); > > But this still requires an explicit cast and depends on a GNU C > extension. Although, I believe the following is valid C99: > > lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option){1}); > > Either way it's a bit uglier than I was hoping for... > I guess another possibility would be to have two arguments, one for > integers and one for pointers: > > lo_address_set_option(a, LO_ADDRESS_SLIP, 1, 0); > > where the last argument is reserved for future use as a string or > struct pointer. > > Any opinions? Alternatively maybe this is putting the cart before the > horse, but I'd rather not be stuck with yet more inflexible functions. > In retrospect we could have used such an API for setting the > multicast TTL and interface, for example, instead of having special > lo_server constructors and special functions for those cases. > > (Another point of view is that having lots of dedicated functions is a > good thing since it allows capabilities to be easily detected by > autotools...) > > Steve > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > liblo-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/liblo-devel |
From: NicoBats <sl1...@gm...> - 2013-04-23 08:54:49
|
Hi, while trying to compile a fresh clone of the git repo (because you've made lot of work since 0.26....), it appears that a 0 is missing ../lo/lo_endian.h:121:5: error: expected value in expression #if ^ 1 error generated. ++ Nicolas |
From: Stephen S. <rad...@gm...> - 2013-04-12 12:13:57
|
Hi, I would like some feedback on this idea, pushed as a branch called 'options' Currently we now have a 'flags' API for lo_address and lo_server. Since this seems a bit inflexible as a general "options" mechanism, for future-proofing this design decision, I propose being able to at least provide an argument for each option, rather than only being able to specify boolean bitflags. https://github.com/radarsat1/liblo/commit/06e65feb559fe729fba077a5eb998d84d20c33cd In the proposal, each option is set individually with an argument, eg, lo_address_set_option(a, LO_ADDRESS_SLIP, (void *)1); As you can see, a downside of reserving the argument as a void* pointer is that it requires an ugly cast for integer/boolean arguments. I haven't figured out a better way to do this. The only other suggestion I had was to use a union called lo_option, allowing, typedef union { char *s; void *p; int i; } lo_option; lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option)1); But this still requires an explicit cast and depends on a GNU C extension. Although, I believe the following is valid C99: lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option){1}); Either way it's a bit uglier than I was hoping for... I guess another possibility would be to have two arguments, one for integers and one for pointers: lo_address_set_option(a, LO_ADDRESS_SLIP, 1, 0); where the last argument is reserved for future use as a string or struct pointer. Any opinions? Alternatively maybe this is putting the cart before the horse, but I'd rather not be stuck with yet more inflexible functions. In retrospect we could have used such an API for setting the multicast TTL and interface, for example, instead of having special lo_server constructors and special functions for those cases. (Another point of view is that having lots of dedicated functions is a good thing since it allows capabilities to be easily detected by autotools...) Steve |
From: Stephen S. <rad...@gm...> - 2013-04-08 15:20:50
|
Merged. But I am left wondering if we should think about a more generalized options mechanism... currently it's a messy combination of a variety of constructions + these binary flags. Don't know, perhaps binary flags will suffice for the future but it's hard to tell.. what if we need an integer parameter in the future, or something else? Maybe string-based option identifiers, taking a void* as parameter? Now's the time to think about this, since the lo_address_set_flags was also not in 0.26. lo_server_set_option(const char *option, void *param); where for the coercion flags, it could be called, lo_server_set_option("coercion", (void*)0); This would allow for integer or even string/struct parameters in the future. But I'm not sure what use cases it would be for, so I'm not sure whether it's necessary or not. Steve On Tue, Mar 26, 2013 at 7:11 PM, Stephen Sinclair <rad...@gm...> wrote: > On Tue, Mar 26, 2013 at 6:47 AM, Camille Troillard > <ca...@os...> wrote: >> Talking about lo_address_set_flags, I have a couple of questions ... >> >> It seems lo_address_set_flags is not public, is it intentional? > > Nope, thanks for pointing that out. > >> Also, the flags type for lo_address_set_flags is named lo_proto_flags, shouldn't we rather name it lo_address_flags? > > Yes, perhaps. I had only used it for details about the protocol (i.e. > which stream type to use) so I was calling them "protocol flags", but > you're right, perhaps they are "address flags". > >> Finally, it would be nice to provide a name for the uninitialized flag, for example LO_NOFLAG=0x00. > > Sure, I don't mind either way. > > cheers, > Steve |