[please follow-up-to openbsc(a)lists.osmocom.org so we don't cross-post
all related mails]
Dear Osmocom community,
OsmoDevCall used to be rather successful for quite some time in recent years,
but recently has been suffering quite a bit due to insufficient people
volunteering to present. Big thanks to all who did! Interestingly,
there's no shortage of ideas of topics at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall - but then
many of the potential speakers did not have the interest or time to
follow-up.
Most recently, the last few instances have not been taking place due to a lack
of volunteers during my holidays.
Last, but not least, while during COVID lockdown winter "friday night
8pm" was a good idea, this of course is more difficult during the
summer, when people are more likely want to go out the weekend.
So, to summarize, let me ask some questions:
* would you be interested in OsmoDevCall continuing?
* which day/time/timezone would you prefer ?
* would you be able and willing to volunteer to give at talk within the
next 3 or so months?
Any other suggestions for or around OsmoDevCall are of course also welcome.
Thanks in advance,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
That compiles as well, I removed const as well for a simple reason:
The AVX version above doesn't use const and doesn't modify mulme either
Am 20.06.22 um 11:18 schrieb Patrick Welche:
> (I would just get rid of "register" and not "const" as well)
>
> P
>
> On Mon, Jun 20, 2022 at 04:41:20AM +0200, Stefan Oltmanns wrote:
>> Hello,
>>
>> gr-osmosdr currently doesn't build on macOS (probably not with clang in
>> general), because C++17 does not allow the "register storage class
>> specifier".
>>
>> The fix is quite trivial:
>>
>> --- a/lib/hackrf/hackrf_sink_c.cc
>> +++ b/lib/hackrf/hackrf_sink_c.cc
>> @@ -299,7 +299,7 @@ void convert_avx(const float* inbuf, int8_t*
>> outbuf,const unsigned int count)
>> #elif USE_SSE2
>> void convert_sse2(const float* inbuf, int8_t* outbuf,const unsigned
>> int count)
>> {
>> - const register __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f,
>> 127.0f );
>> + __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f );
>> __m128 itmp1,itmp2,itmp3,itmp4;
>> __m128i otmp1,otmp2,otmp3,otmp4;
>>
>> Could you please apply that patch and also create a new release?
>> Unfortunately gr-osmosdr was thrown out of the homebrew package earlier
>> this year, because it didn't build.
>> I would like to get it back in, because that would make things on mac a
>> lot easier (and GNURadio tutorials for mac would be correct again and
>> not cause frustration).
>>
>> I assume the easiest way to get it back in is to have a new official
>> release that builds again correctly.
>>
>> Best regards
>> Stefan
Hello,
gr-osmosdr currently doesn't build on macOS (probably not with clang in
general), because C++17 does not allow the "register storage class
specifier".
The fix is quite trivial:
--- a/lib/hackrf/hackrf_sink_c.cc
+++ b/lib/hackrf/hackrf_sink_c.cc
@@ -299,7 +299,7 @@ void convert_avx(const float* inbuf, int8_t*
outbuf,const unsigned int count)
#elif USE_SSE2
void convert_sse2(const float* inbuf, int8_t* outbuf,const unsigned
int count)
{
- const register __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f,
127.0f );
+ __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f );
__m128 itmp1,itmp2,itmp3,itmp4;
__m128i otmp1,otmp2,otmp3,otmp4;
Could you please apply that patch and also create a new release?
Unfortunately gr-osmosdr was thrown out of the homebrew package earlier
this year, because it didn't build.
I would like to get it back in, because that would make things on mac a
lot easier (and GNURadio tutorials for mac would be correct again and
not cause frustration).
I assume the easiest way to get it back in is to have a new official
release that builds again correctly.
Best regards
Stefan
