From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-02-27 14:12:29
> John Morrison wrote:
> > Doug could you please put a step by step guide together.
> > Including where to get it (URLS) etc
> > any special instructions (Probably NON)
> >
> > Anyone volunteer (Jim??) to do the same for Windows ???.
>
> If you'd taken the trouble to download the ZIP file, you'd see that
> the work had already been done, or was in the process of being done.
> And, NO, I'm not going to stick my work in your folder. I'm going to
> put it up on my site where I can keep things up-to-date much more
> easily.
I did download it but haven't had the time to install everything needed yet.
Sorry!
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?
BTW the only reason I have my name on the folder is so people recognise it
as the plug-in/frame work project.
I've now removed my name from the folder now!
http://groups.yahoo.com/group/buildcheapeeg/files/NF_platform/
I have no EGO in this project at all, I just want to get a GOOD frame work
to build on a collaborative effort.
> > That will give any non-techies an easy way to get it on and compile
> > the program latter!
>
> The build instructions could well vary from release to release, so it
> is better to ship them with the release.
That WILL happen when we release the framework.
BUT this is a collection for the initial designers release so we can all get
the same environment!
> > Any comments from those that have worked with Windows??
>
> If you're using MinGW and MSYS, then you will be able to do
> "./configure; make", and maybe even "make install" (once I've learned
> 'automake'). For other Windows build environments, people will have
> to improvise their own build. This isn't too hard, so long as they
> are willing to fiddle around getting everything together. If people
> want to contribute instructions, I can add them to the archive.
> MinGW/MSYS is much easier to support as it runs UNIX ./configure
> scripts directly (as well as any other UNIX shell script).
Sounds like a good suggestion!
> John -- I'm a little worried that you're big on plans, but not so big
> on research. I mean, earlier you suggested dropping UDP packets, but
> this indicates that you still have no understanding of what effect
> this would have on the analysis. If you substituted zeros for the
> missing data, then all the filters will go crazy, with artifacts
> everywhere.
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.
ANYWAY the remote module (i.e. UDP) is only "remote" possibility and not
really an issue yet!
> Take a look at BWView and some of Jim's data packaged with it -- look
> at what happens when there is a glitch in the input data. Even some
> of the points where there was sync-loss (perhaps just one bad sample)
> cause significant artifacts.
Thanks for the advice it'll be added to the design requirements.
> I agree that planning is really important and all of that, but if
> you're not learning about the problem-space, then your plans are going
> to end up being miles off the mark.
True to true!
> If you build a big design on top of a bunch of fundamental flaws like
> dropping UDP packets, you might end up with an immense rewrite on your
> hands even before you've got something working, with stacks of wasted
> code to throw away.
I'm afraid you've assumed that I'll be the only one writing the software.
I don't intend to do that at all!!!!
We have a WIDE range of abilities here I'm hoping that all can and will
contribute to the design.
I may have brought up the initial design and I'm pushing it BUT it will have
to be a collaborative effort!!!
As I said NO EGO can enter into the project!!!
<< Snip some clever bits >> :-)
>
> However, maybe your job here is to remind me not to make "Plans"! In
> which case, don't let me stop you!
>
> Jim
Sigh.......
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!
Hell I shouldn't complain it keeps most programmers in business working out
what someone did before them! ASK any commercial programmer!
Call me a clever programmer, I've produced no results so far......hmm maybe
true but a month isn't a long time to plan is it?
AND it has stirred up a LOT of interest in the software side of things. :-)
Up till then we only had electricGuru which as Rob said he designed without
a plan and is sorry for it!!
Now you've produced your great piece of software (NO I'm not taking credit
for it !!) we have at least 3 programmers thinking about HOW to write
flexible NF software. Dave has come out of the woodwork with a similar idea
and we've discussed and decided a lot of things that had been up in the air
before. Not bad for 1 month. :-)
I applaud your work you've made an amazing program for analysis which is
great. I couldn't have written it!
BUT it can't do anything with real-time data so it is a piece of the puzzle.
What I'm proposing is the board to place ALL of the pieces on!
Lets not start a counter productive flame war you have you views about
software design and I have mine.
I have not denigrated you or your design path so please reciprocate!
It just wastes SO Much TIME. :-(
Happy Programming!!!
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST