[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] packages for nesC: why/etc [shortish so you canglance through it this morning]

[Kristin Wright]

I'm not stating a position either way on packages, but if someone else
mentions the issue, we should make sure they know about nesdoc. nesdoc
doesn't fully address the problem, but it helps, and the path to the
source is in the upper right-hand corner (a pseudo-package name).

-kw

On 6/1/05, Buonadonna, Phil <phil.buonadonna at intel.com> wrote:
> Coming from EmNets, the biggest (and most concrete) complain from nesc
> users is the surmounting difficulty of navigating the TOS
> directory/namespace.  Answering the question "which component is my
> program using" is becoming increasingly complex.
> 
> I assume the package system would help address this problem? If yes,
> then this is a much needed thing.
> 
> Going from #include back to 'includes' isn't to hard.  However, it
> sounds like integrating a C-preprocessor in nesC quite a bit of work.
> 
> would the package system impact source-line debugging?
> 
> pb
> 
> 
> 
> > -----Original Message-----
> > From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU
> > [mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On
> > Behalf Of David Gay
> > Sent: Wednesday, June 01, 2005 9:32 AM
> > To: tinyos2
> > Subject: [Tinyos-2.0wg] packages for nesC: why/etc [shortish
> > so you canglance through it this morning]
> >
> > Name space for tinyos components and interfaces is getting complex:
> >
> >   - similar names needed for functionality at many layers:
> >     hpl, hal, hil, oski
> >   - similar names needed across platforms / chips
> >   - some components are "private": not intended for independent use
> >     (lookup, e.g., at tos/lib/FS in 1.x)
> >
> > Prefixing is not a good solution: names become very awkward,
> > prefixes are not
> > used consistently, etc.
> >
> > ------------
> >
> > Proposal: add a package system to nesC
> >
> >   packages contain component and interface files, and other packages
> >   issue: what about C names and include files? (see below)
> >
> >   packages must be imported in a file before use
> >   packages can be imported with a "private" name
> >    (something like import "tinyos.lib.adc as foo", followed by uses
> >     like foo.SomeAdcInterface)
> >   some set of packages are automatically imported
> >
> > --------------
> >
> > Major issues:
> > - how to deal with C names?
> > - how to deal with C files, preprocessor macros?
> > i.e., are they part of the package system, which means that:
> >   - C file inclusion should either include the package name, or
> >     be searched for in imported packages
> >   - C names/preprocessor names would be searched for in imported
> >     packages (and support the importedasname.name syntax)
> >
> > Reasons to include them:
> > - same as for components and interfaces: the packages will
> > need to organise
> >   their type names, etc
> >
> > Reasons not to include them:
> > - how does #include work within a package system?
> >   (short answer: it doesn't, we would need to go back to
> > "includes foo;")
> >   (long answer on request)
> > - macroprocessing currently handled by external gcc invocation
> >   --> cannot handle macros in packages
> >       solution: integrate preprocessing into nesC compiler
> >                 this allows "includes" and macros to work together...
> > - more changes from C, possible syntax issues
> >
> > _______________________________________________
> > Tinyos-2.0wg mailing list
> > Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/
> > tinyos-2.0wg
> >
> 
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg