[Ns-developers] Preliminary release of NS-3 WiMAX module

[Mathieu Lacage]

On Tue, 2008-06-03 at 15:20 +0200, Jahanzeb Farooq wrote:

> > 3) After installing itpp 3.10.11, I still get the following 
> > compilation error:
> > ../src/devices/wimax/wimax-ofdm-phy/modulator80216.h:51: error:
> ‘BPSK_c’
> > does not name a type
> > I suspect that I need to get the right version of itpp to get that
> > symbol defined: which version should I get ?
> 
> This is the first time I am seeing this error. Please note that you
> also
> have to install LAPACK, ATLAS, BLASS and FFTW libraries separately. In
> my case I have installed the following: lapack (3.1.1.1), lapack-devel
> (3.1.1.1), atlas (3.6.0.11), atlas-devel (3.6.0.11), fftw (3.1.1) and
> fftw-devel (3.1.1) (BLASS was automatically installed during
> installing
> LAPACK).

yes, I have all of these libraries installed.

> 
> The IT++ version I have installed is the development version 3.99.3.1
> as
> instructed by Fabio. I downloaded it from IT++ web site.

These are unstable development versions. Is there a stable release of
itpp  which we can use ?

> > I suspect that you are in the second case above and, if I am right, 
> > you have a couple of options:
> >
> >   a) try to run "hg pull http://code.nsnam.org/ns-3-dev" in your tree,
> > deal with the conflicts if there are any, and repost a repo for review
> > 
> >   b) create a clean copy of ns-3-dev, copy your own code in there, and
> > hg add && hg ci it in the new repository. Please, make sure you do not
> > add unecessary and unwanted files. i.e., add each file separately.
> > .......
> >
> > a) might be painful and create a scary and horrible mercurial history.
> > b) will destroy all _your_ development history, c) will preserve both
> > your history and the ns-3 history correctly. Based on the issue 1)
> > outlined above (lots of unwanted files present in your
> > repository/history), I would suggest that you go with b) because we
> > really do not want to keep in our history all the files you have added
> > there.
> 
> Thanks for suggesting the solutions. I think I will go for option (b) as
> you have also suggested. However loosing the development history is
> painful therefore may be I shall try option (a) first.

I was not very clear but, from the point of view of merging your work
later in ns-3, neither a) not c) are acceptable. i.e., both of these
solutions will introduce ugly history in our tree and will increase the
size of our tree history by large amounts. So, if you are willing to
forget your history, go with b). If you do not want to lose it, you will
have to re-create a clean history by replaying all your changesets in a
clean tree and making sure you do not replay the changesets which
contain all the unwanted files you checked in by mistake. i.e., you are
going to deal with a lot of scripting pain. You might want to look at
the "convert" extension of mercurial (again, make sure you have the
latest version of mercurial if you want to use this)

> 7) It would be really helpful to know what your TODO is over the next
> > couple of months: it is hard, as-is, to figure out what is really just
> > code waiting to be implemented shortly and what is ignored because you
> > don't care about modelizing it. The end of README attempts to answer
> > that question but it would be very helpful to have a more detailed plan
> > of action about what you want to do. For example, the README seems to
> > imply that scheduling will be implemented before the dynamic creation
> > and management of service flows which seems really backward: I would
> > have expected the latter to be implemented first properly with a very
> > stupid scheduler.
> 
> May be you did not get it right here or may be I was not clear. It did
> not mean the scheduler but the scheduling services (BE, UGS, rtPS,
> nrtPS). As much I understand its implementation is not really dependant

What do you mean by "scheduling services" ? Can you outline what this
is ?

Mathieu