Comments (19)
OK. I will rename to remove lib_.
from lib_dsp.
I see the point about consistency but have a few remarks:
IIRC the prefix was introduced to create a name space and avoid clashes with header files in other code bases. Without the prefix we'd end up with filenames like dsp.h, math.h, matrix.h. math.h would already be a clash. So a using a prefix makes sense. CMSIS uses the arm_ prefix (e.g. arm_math.h)
lib_voice uses lib_voice_doa_naive.h
from lib_dsp.
The tests and examples are inconsistent too. It would be really nice if they followed the convention of everything else. It makes things difficult for maintenance of the build and release system.
from lib_dsp.
Please don't use lib_voice as a reference, it's yet to be productised or reach version 1. It's still very much in the hands of the technology team.
On 10 Jun 2016, at 08:19, Thomas Gmeinder <[email protected]mailto:[email protected]> wrote:
I see the point about consistency but have a few remarks:
IIRC the prefix was introduced to create a name space and avoid clashes with header files in other code bases. Without the prefix we'd end up with filenames like dsp.h, math.h, matrix.h. math.h would already be a clash. So a using a prefix makes sense. CMSIS uses the arm_ prefix (e.g. arm_math.h)
lib_voice uses lib_voice_doa_naive.h
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/52#issuecomment-225111097, or mute the threadhttps://github.com/notifications/unsubscribe/AAnPXma5B2U6aJ0Q_qcxc872kq2b2pKrks5qKRBDgaJpZM4IyIMa.
from lib_dsp.
Comments from Thomas -
removing the lib_dsp_ prefix will cause other issues (lib_dsp_math.h will be turned into math.h which will clash)
I think Andrews request boils down to:
Rip AN00209_xCORE-200_DSP_Library apart and create a separate appnote for all 10 app_ applications.
If we implemented these requests the effort would be much higher than the benefit. Especially for Andrew's request.
I agree with both points.
John
from lib_dsp.
The request was to remove the lib_ prefix, leaving it as dsp_math.h, so there should be no conflict.
from lib_dsp.
I realised that changing all header files from lib_dsp....h to dsp_.....h
will then cause inconsistency in the library itself with the filenames in the src directory as well as all the functions.
All of the above have prefix lib_dsp_
What shall we do with those?
It's not a big effort to search/replace "lib_dsp" with "dsp" but any user code to date would have to be changed because all the function names changed.
from lib_dsp.
Just a left field observation.
We started with one minor change that required a major version bump (something to do with matrices - not sure how many people use that), but by the sound of it this becomes a rather big set of major inconsistencies that will required everybody to change their code.
If that is the case - is that a necessary evil, or isn't it worth it?
from lib_dsp.
Based on the feedback this seems to be the consensus:
Moving to 3.0.0 is an opportunity for radical API changes like changing all function names.
Changing prefixes of all functions and source file names from "lib_dsp" to "dsp" would bring consistency.
All user code will have to change but we think it's worth it because it increases consistency within the library and across libraries.
Unless somebody shouts I will make it so.
from lib_dsp.
while you are at it could we rename
lib_dsp_fft_complex_t -> dsp_complex_t
and
lib_dsp_fft_complex_short_t -> dsp_complex_short_t
as they don't really belone to ffts. This was my mistake but we might as well fix it in one commit. thanks
from lib_dsp.
I urge a rethink
We do not need opportunities to change everything. We need to make sure our customers are happy.
On 15 Jun 2016, at 15:34, Andrew Stanford-Jason <[email protected]mailto:[email protected]> wrote:
while you are at it could we rename
lib_dsp_fft_complex_t -> dsp_complex_t
and
lib_dsp_fft_complex_short_t -> dsp_complex_short_t
as they don't really belone to ffts. This was my mistake but we might as well fix it in one commit. thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/52#issuecomment-226206786, or mute the threadhttps://github.com/notifications/unsubscribe/AAmJB_zNWUndQMpXMbtiChxoaW1tN8qSks5qMA3EgaJpZM4IyIMa.
from lib_dsp.
One option is to leave the old API in place along side any new API
It would be good practise to mark as appropriate e.g.
#ifdef XC
#define xscope_probe(id) _Pragma("warning "xscope_probe is deprecated, use xscope_char instead"") xscope_char(id, 0)
#else
attribute((deprecated)) static inline void xscope_probe(unsigned char id)
{
xscope_char(id, 0);
}
#endif
On 15 Jun 2016, at 15:39, Henk Muller <[email protected]mailto:[email protected]> wrote:
I urge a rethink
We do not need opportunities to change everything. We need to make sure our customers are happy.
On 15 Jun 2016, at 15:34, Andrew Stanford-Jason <[email protected]mailto:[email protected]mailto:[email protected]> wrote:
while you are at it could we rename
lib_dsp_fft_complex_t -> dsp_complex_t
and
lib_dsp_fft_complex_short_t -> dsp_complex_short_t
as they don't really belone to ffts. This was my mistake but we might as well fix it in one commit. thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/52#issuecomment-226206786, or mute the threadhttps://github.com/notifications/unsubscribe/AAmJB_zNWUndQMpXMbtiChxoaW1tN8qSks5qMA3EgaJpZM4IyIMa.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/52#issuecomment-226207952, or mute the threadhttps://github.com/notifications/unsubscribe/AAnPXlY8A9Y-K46o8cx0-ckVnGkJnwbdks5qMA6sgaJpZM4IyIMa.
from lib_dsp.
Making it deprecated is actually more work than just changing the interface. Clearly it would be a requirement for libraries that have a lot of users and a long history. How many users of the library are there? We need to be pragmatic given we have limited resource to spend on this.
from lib_dsp.
More work for us, less work for the users - just addressing Henk’s point.
On 15 Jun 2016, at 15:52, Peter Hedinger <[email protected]mailto:[email protected]> wrote:
Making it deprecated is actually more work than just changing the interface. Clearly it would be a requirement for libraries that have a lot of users and a long history. How many users of the library are there? We need to be pragmatic given we have limited resource to spend on this.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/52#issuecomment-226212051, or mute the threadhttps://github.com/notifications/unsubscribe/AAnPXtjEIHBFoCubKM2vUX7-bQSpf_tPks5qMBGQgaJpZM4IyIMa.
from lib_dsp.
Having discussed this with Henk and Ross we have come to the conclusion that at the moment it is still ok to make this major change to the API without adding the deprecated step. There are not enough external users of the library to prevent us from making the change. So, Thomas, go ahead and make the change.
Thanks,
Peter
from lib_dsp.
Done in latest Pull Request #53
from lib_dsp.
I don’t have access to the lib_dsp repo, so please can someone replace all instances of “accumulater" with “accumulator” in the lib_dsp app note. I think there are six instances
Thanks,
Huw
On 15 Jun 2016, at 16:07, Peter Hedinger [email protected] wrote:
Having discussed this with Henk and Ross we have come to the conclusion that at the moment it is still ok to make this major change to the API without adding the deprecated step. There are not enough external users of the library to prevent us from making the change. So, Thomas, go ahead and make the change.
Thanks,
Peter
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
from lib_dsp.
Thanks Huw
Fixed 24 instances of “accumulater" and pushed.
Commit Fixed typohttps://github.com//pull/53/commits/3caa5ea9ccfd9fe53219f1d36d54fde53dab7460 was added to the latest pull request #53
Cheers, /T
From: huwg59 <[email protected]mailto:[email protected]>
Reply-To: xmos/lib_dsp <[email protected]mailto:[email protected]>
Date: Friday, 17 June 2016 10:06
To: xmos/lib_dsp <[email protected]mailto:[email protected]>
Cc: thomas <[email protected]mailto:[email protected]>, Comment <[email protected]mailto:[email protected]>
Subject: Re: [xmos/lib_dsp] Header files shouldn't use "lib_" prefix to match other XMOS libraries (#52)
I don’t have access to the lib_dsp repo, so please can someone replace all instances of “accumulater" with “accumulator” in the lib_dsp app note. I think there are six instances
Thanks,
Huw
On 15 Jun 2016, at 16:07, Peter Hedinger <[email protected]mailto:[email protected]> wrote:
Having discussed this with Henk and Ross we have come to the conclusion that at the moment it is still ok to make this major change to the API without adding the deprecated step. There are not enough external users of the library to prevent us from making the change. So, Thomas, go ahead and make the change.
Thanks,
Peter
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/52#issuecomment-226706991, or mute the threadhttps://github.com/notifications/unsubscribe/AAqhhnaup2syDLBMksZrMRBoCPLVxzUYks5qMlVugaJpZM4IyIMa.
from lib_dsp.
Resolved by pull request #53
from lib_dsp.
Related Issues (20)
- FFT testing
- dsp_bfp documentation missing from rst
- dsp_bfp.h causes error when included by a C file HOT 2
- dsp_vector_abs often outputs negative numbers HOT 3
- dsp_vector_{muls_addv, muls_subv, mulv_addv, mulv_subv} do not give correct outputs for vector lengths > 7.
- Double-word alignment of inputs HOT 3
- xmake fails for app_vector HOT 1
- dsp_adaptive_nlms error when the input source_sample is a very low value
- DCT overflows rather than saturates
- Standardise naming convention + add regex regression tests
- Remove `_bfp` from functions that aren't BFP specific
- Add missing docstrings to api/dsp_bfp.h
- Simulator time-out in app_math tests
- Convert legacy tests to run with axe
- Extend non-XS1 processing to XS3 HOT 2
- tests/test_biquad does not build for xcore.ai
- tests/test_fft_forward does not build for xcore.ai HOT 1
- Some tests require autogenerated files and do not build for xcore.ai HOT 1
- tests/dsp_unit_tests cannot run under xcore.ai
- examples/AN00209 Application Note fails to build HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lib_dsp.