From: Jim Peters (jim_at_uazu.net)
Date: 2002-02-27 16:19:10
John Morrison wrote:
> I'm just trying to collect the necessary documents so that module
> authors had access to it! And we can start with the same
> environment and reduce wasted time form inconsistencies! Do I have
> permission to use your document?
Okay, so you're talking about getting the SDL and FFTW libraries
installed, rather than the specifics of building BWView ? In that
case, the best thing would be to look at the docs on those two sites:
http://www.fftw.org/
http://www.libsdl.org/
For MinGW and MSYS, look here:
If there is anything that is of any use within the build instructions
or build scripts within BWView, please use it. If Doug is going to
give it a try, he can probably come up with some hints too.
> I understand that, it was just a suggestion it would all depend on HOW we
> send the data and what is on the other end analysing it.
> With the proper receiving system a single packet loss could be "guessed"
> from the previous packet and it maybe quicker to do this then to ask for a
> resend!
> THIS IS ONLY A POSSIBILITY........it all depends on how the system shapes
> up.
It isn't a possibility, sorry! No guessing of packets is going to
work reliably. Perhaps, for another solution, each packet could be 4
times the length, and transmit the current data and the previous 3
packet's data as well. That way we could lose 3 packets without
noticing. The amount of data we are transmitting is tiny, so this is
no big deal. However, if your networking experience tells you this
wouldn't work, forget that idea.
Why not stick to TCP/IP ? I was piping data sampled at 5kHz over my
ethernet via TCP/IP between my laptop and desktop without problems.
Why make it more complex if the simple option works ? It would be
better to delay the analysis than to try and patch up a stream with
holes in it.
Either that or have the user end do the analysis, and just send
packets of analysis data over the network. It might be more
permissible to drop packets of analysis data.
> I've just Graduated (with distinction) a bachelor of information technology
> majoring in "Data Communications" and "Software Engineering" backed by 17
> years working for a Telecommunication company working on Computerised
> exchanges and the network data that connects them. One of the major things
> they teach for bigger projects is to plan first and hack latter or never.
> Sure you can jump right in and get a program that looks great in a short
> space of time. BUT 6 months down the track when you've added 20 more
> features to the system you find that it's a hoch poch of code and no-one
> including you knows how it works anymore!
Take a look at my code. There are two parts with a strong
object-oriented well-defined interface: "analysis.c" and "file.c".
The other parts are clearly segmented, but the interface to those
parts has not become well-defined yet because I didn't know exactly
how I wanted them. Now I'm more aware of how things have turned out,
those areas are probably going to get some reorganization.
My memory span is zero -- I have to document my code or else I would
never be able to work on it again. Just because it is a hack doesn't
mean it's sub-standard!
> Lets not start a counter productive flame war you have you views
> about software design and I have mine.
Agreed.
> I have not denigrated you or your design path so please reciprocate!
> It just wastes SO Much TIME. :-(
No problem. I think it's best that I let you get on with your plans,
whilst continuing with my own research and development. If you try to
pull me into your "plan", it is asking for problems, so better let me
work independently.
Jim
-- Jim Peters (_)/=\~/_(_) jim_at_uazu.net (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST