Skip to content
Snippets Groups Projects
Commit 5f1621f0 authored by coolen's avatar coolen
Browse files

Newstar initial src & documentation tree

parents
No related branches found
No related tags found
No related merge requests found
Showing
with 954 additions and 0 deletions
hlp/agb.gif

14.5 KiB

This diff is collapsed.
This diff is collapsed.
Betreft:
Batch processing in Newstar
---------------------------
Waarde heren,
Ik heb wat details van DWARF opgespoord ten behoeve van automatische
processing. Hieronder volgt een voorlopig overzicht. Een aantal zaken
staat al in het Cookbook: Program Descriptions, Common.
1e. DWARF Keywords, streams
---------------------------
Een gebruiker heeft invloed op de werking van een Newstar programma via
de DWARF user-interface. Alle grootheden/parameters die een gebruiker
in principe kan specificeren corresponderen met keywords, die een
waarde hebben. Die waarde kan op een aantal niveaus bepaald worden:
1e. Interne of program defaults:
De programmeur heeft een default waarde meegegeven bij de
definitie van het keyword (in de zgn. PIN-file). In een
(beperkt) aantal gevallen staat er geen default in de PIN-file
maar geeft het programma zelf een default mee.
2e. Externe defaults:
De gebruiker heeft, buiten het programma om, een waarde
gegeven aan het keyword door een DWARF symbool te definieren
(met dwspecify, met dwrestore, of door het programma eerder
te gebruiken met de /SAVE switch)
Voor een aantal algemene keywords wordt de externe default op twee
plaatsten gezocht: eerst in een tabel met defaults voor het programma
(de "local" external default), als daar geen waarde staat in de algemene
tabel (de external default van "NGEN").
3e. Het programma prompt de gebruiker voor het keyword en krijgt
een waarde via toetsenbord of input-file.
Normaliter gaan de antwoorden die de user geeft op keyword prompts verloren
wanneer het programma wordt verlaten. Er zijn twee manieren om een keyword
te bewaren (alsof het met dwspecify was gegeven):
- Voor alle keywords de waarde bewaren: start programma met
dwe <programma> /SAVE
- Voor individuele keywords de waarde bewaren: geef na de prompt
waarde /SAVE [/[NO]ASK] (zie ook onder 3e)
Op elk niveau kan een qualifier (switch) /ASK of /NOASK worden meegegeven.
Deze bepaalt of de gebruiker voor het keyword geprompt wordt of niet
(het opgeven van /[NO]ASK bij een prompt heeft alleen zin als ook de
/SAVE switch gegeven wordt).
Met de /SAVE optie en dwspecify (= dws) kunnen vaste defaults voor een
programma worden gezet. Omdat het meestal wenselijk is verschillende
sets van defaults te gebruiken voor verschillende procedures kan een
programma in verschillende "streams" (wat was dat andere woord ook al
weer?) gestart worden. Elke "stream" heeft een eigen set defaults.
Het commando om een programma te starten in een bepaalde "stream" is
dwe <programma>$<streamname>
bv
dwe nscan$1
dwe nmap$standard
dwe nplot default: stream 1
Wanneer een keyword geen default heeft in de opgegeven stream wordt
een default in stream 0 gezocht, is daar ook niets dan blijft alleen
de default van de PIN file over. Voor NGEN keywords wordt steeds zowel
in de stream voor het programma als in de stream voor NGEN gezocht.
2e. DWARF Symbols
-----------------
DWARF slaat externe defaults op als symbolen. Alle symbolen staan
fysiek in de file $DWARF_SYMBOLS (meestal ~/SYMBOL_DIR/SYMBOL.$$).
Een DWARF keyword correspondeert met een symbool
<Programma>$<Stream>_<Keyword>
De waarde van het symbool is de character string die als default
gebruikt zal worden bij user-input, eventueel met de qualifier /ASK
of /NOASK er achter.
Wanneer achter de waarde <space>/ASK staat, vervangt de waarde de default
van het programma, maar wordt de user toch geprompt voor het keyword.
Wanneer achter de waarde <space>/NOASK staat, of wanneer er helemaal geen
qualifier staat, dan wordt de user niet meer voor het keyword geprompt.
Naast deze keyword symbolen kunnen ook algemene symbolen gezet worden,
die in antwoorden op prompts gebruikt kunnen worden, bv PI = 3.1415,
NATUURLIJK = YES en zo voorts.
De volgende utilities zijn beschikbaar om symbolen te manipuleren:
dwlet [symbol=value] [/LOG[=long|short] [/NOLOG] (= dwl)
Geef een waarde aan algemene symbolen. Kan niet gebruikt worden
om DWARF keywords te wijzigen.
Als er geen symbol=value wordt meegegeven wordt de standard input
gelezen voor regels met "symbol=value", om te stoppen: lege regel
of # of ^D.
dwspecify program[$stream] [/MENU] [/NOMENU] (= dws)
Default stream is 1, default mode is /NOMENU.
Hiermee worden externe defautls voor DWARF keywords opgegeven.
Met /menu wordt voor elk keyword geprompt met de huidige
(externe of interne) default, alleen wijzigingen worden in
een symbool gezet. Met /nomenu worden van de standard input
regels keyword=value gelezen.
dwclear [program[$stream]keyword,... [/CONFIRM] ... (= dwc)
Verwijdert de definitie van de keywords, wildcards zijn toegestaan,
erg handig is bijvoorbeeld: dwclear nscan$*_*, om helemaal schoon
te beginnen.
dwsave [program[$stream]keyword,... [/OUTPUT=file] [/CONFIRM] ...
Default file is dwarfsave.sav, default extensie is sav
Schrijft de keywords en hun waarde in de genoemde (ASCII) file,
wildcards zijn toegestaan. Default is *$*_*
dwrestore file [/CONFIRM] [/OVERWRITE]
Leest regels keyword=value van de genoemde file en definieert de
corresponderende symbolen.
dwview symbol,... [/EXTERN] [/GENERAL] [/INPUT=file] (=dwv)
Laat de waarde van symbolen zien:
Zonder /GENERAL en /INPUT:
Symbols moeten de vorm [[program]$stream_]keyword hebben,
wildcards toegestaan. Laat zowel interne als externe defaults
zien, als /EXTERN alleen de externe (zowel "local" als "NGEN").
Met /INPUT:
Leest als dwrestore van de genoemde file, laat keywords zien
die matchen met de genoemde symbols.
Met /GENERAL: (optie gemaakt 28/07/93)
Symbols mag zowel DWARF keywords als algemene symbols bevatten,
wildcards toegestaan (bv: dwv /g *).
Voor keywords: alleen externde defaults worden getoond.
Als er precies een symbool is opgegeven is de uitvoer de
waarde van dat symbool, anders regels symbol=value.
Een typische manier om standard streams te gebruiken is dus:
dwe nscan$abc /save [/norun] of dws nscan$abc /menu
dwe nplot$abc /save [/norun]
dwsave *$abc /output=abc
Tenslotte commentaar invoegen in abc.sav, eventueel nog wat keywords
van de /ask switch voorzien.
Dan bij gebruik:
dwrestore abc /override
dwe nscan$abc
dwe nplot$abc
3e. Antwoorden op prompts
-------------------------
Het programma bepaalt (via de PIN file) wat voor antwoorden geldig zijn
(character strings, numeric values). Binnen de grenzen van die geldigheid
kunnen de volgende constructies worden opgegeven:
? Geef online help
# of ^D Exit (meestal: vraag vorige keyword)
"" Empty answer (meestal: by-pass option)
* Wildcard (meestal: take all)
... ! Comment Alles na een uitroepteken is commentaar
...'Symbol'... Het symbol wordt vertaald voor alle verdere
processing
(1=2)*4 Rekenkundige expressies worden uitgewerkt
(alleen voor numerieke waarden, dus wel voor
INPUT_LABELS, niet voor LOOPS)
99 TO 120 BY 2 Reeksen worden gegeven als begin TO eind BY stap
(alleen voor numerieke waarden, dus wel voor
INPUT_LABELS, niet voor LOOPS)
... /SAVE [/[NO]ASK] Bewaar deze waarde na afloop van het programma in
een DWARF symbol. De qualifier /ASK of /NOASK
wordt in het symbool bewaard (geen qualifier
betekent in praktijk: /NOASK)
value1; value2; ... Geef een reeks waardes op, de volgende keer dat
het keyword wordt gevraagd neemt het programma
de eerstvolgende waarde
value1,value2 Geef een vector op, alle waardes worden meteen
naar het programma doorgegeven
/ASK=keyword Wanneer het programma het opgegeven keyword
nodig heeft krijgt de gebruiker een prompt;
als deze qualifier gegeven is wordt het
huidige keyword nog een keer gevraagd.
Nota Bene: er is geen snelle manier om hidden keywords te zetten als
het programma al draait. Met dws is dat wel mogelijk.
4e. Scripts en batch processing
-----------------------------------------------
Er zijn twee manieren om Newstar (of eigenlijk: DWARF) in batch mode
te gebruiken. De simpelste manier lijkt me via shell scripts, waarin
keywords worden gelezen met dwrestore en vervolgens de nodige programma's
worden gedraaid.
Er is (voor WENSS) een "Batch package" ontworpen om de interactie met
de keyword files te vereenvoudigen. Voor zover ik kan zien is de enige
functie het overnemen van de dwrestore en het zetten van /ASK achter
een aantal keywords. Dit weegt denk ik niet op tegen de extra moeite om
voor elk programma een "batch versie" te maken. Ik zal hier nog wat
beter naar kijken. Je hoort er nog van.
5e. Voorstel voor wijzigingen en uitbreidingen
----------------------------------------------
De volgende wijzigingen in het huidige systeem lijken me wenselijk:
- Alternatieve specificatie voor streams omdat $ een Unix special
character is. Ik stel voor om voor stream specificaties zowel
een $ als een . toe te staan (bv dwe nscan.test of dwe nscan$test).
- Van keywords die als symbol gedefinieerd zijn met /NOASK moet tijdens
de uitvoering van het programma het keyword en de waarde worden
afgedrukt.
Een "conditionele" batch processing kan vrij makkelijk worden gerealiseerd
door de Newstar programma's bepaalde interne waarden in een (algemeen)
symbol te laten zetten. Die waarden kunnen dan in het shell script worden
opgevraagd en getest. Bv: bij NSCAN kan het aantal Channels in symbol
NCHAN worden gezet, in het shell script kan dan een test worden gedaan
if (`dwv /General nchan` == 128) then ...
of de waarde kan in een shell variabele worden gezet
set channels=`dwv /g nchan`
of de waarde kan worden toegekend aan een keyword voor een ander programma
dws nmap\$1 /NOMENU <_EOD_
LOOPS='NCHAN',...1
#
_EOD_
Wanneer jullie doorgeven op welke parameters je wilt testen is het een
kleine moeite die waarden in een symbol te zetten. Wanneer je een
programma met /SAVE draait zijn alle antwoorden van de user in elk
geval beschikbaar in symbolen, dus daar kun je ook op testen.
----------
Tot zover maar weer even. Ik maak hier nog een fatsoenlijk (Engels) document
van, maar hiermee kunnen jullie denk ik wel even vooruit.
Hartelijk groeten,
Marco.
--
+--------------------------------------------------------------------------+
| NFRA/St. ASTRON | eMail: devoscm@astro.rug.nl / cccccccc |
| P.O. Box 2 | or: devoscm@astron.nl / c m m c |
| NL-7900 AA Dwingeloo | / c m m m c |
| | ---------------------------------+ c m m c |
| Phone: +31 5219 7244 \ "If you reinvent the wheel, | v v |
| Fax: +31 5219 7332 \ make sure yours will look | v v |
| Telex: 42043 rzm nl | different..." | v |
+--------------------------------------------------------------------------+
Newstar Bug reporting procedure
-------------------------------
bug_reports.txt 14/06/93 v1.0 CMV
bug_reports.txt 06/09/93 v1.2 CMV
JPH 940621 Add list of contents. Include bug_report.2 (=sec. 6.1)
INHOUD
======
1. Inleiding
2. Procedure
3. Revisions en Releases
4. Functionality Requests
5. Implementatie: nbug
6. Prioriteitsstelling
6.1 Update on priorities
7. Slotopmerkingen
1. Inleiding
------------
Zolang een programmapakket door een beperkte groep gebruikt wordt, is
er weinig noodzaak voor al te veel formele procedures. Naarmate het
pakket door een grotere groep, met een grotere geografische verspreiding
wordt gebruikt werkt een aantal informele overlegcircuits niet meer en
moet er een aantal afspraken over tijdschema's en rapportage gemaakt worden.
Die afspraken moeten het volgende garanderen:
1e. Gebruikers weten welke versie van het pakket voor hen draait,
en wat de (voornaamste) eigenschappen van die versie zijn.
2e. Gebruikers die een "bug" rapporteren worden regelmatig op de
hoogte gehouden van de afhandeling van die bug.
3e. Programmeurs weten aan welke programma's gewerkt wordt.
4e. Er is een duidelijke prioriteitstelling voor de verschillende
onderhouds- en ontwikkelingstaken, waardoor niet onevenredig
veel tijd wordt besteed aan minder belangrijke klussen.
5e. Er zijn duidelijke overleg momenten, waardoor er doorlopend
een optimale werkverdeling is.
6e. Er is een rapportage procedure, waardoor ervaring bij debugging
voor het nageslacht bewaard blijft.
Voor wat betreft Newstar zijn de meeste van die punten nu (informeel)
geregeld. Dit rapport probeert het geheel te structureren, uitgaande
van de afhandeling van bugs. Aangezien in mijn optiek missende
functionaliteit ook een bug is (het jeukt net zo erg...) geldt het
verhaal in hoofdlijnen ook voor functionality requests.
2. Procedure
------------
Afhandeling van een bug doorloopt de volgende fasen (tussen haakjes de
status die na deze fase aan de fout wordt toegekend, zie sectie 5):
1e. Ontvangst (Received)
2e. Prioriteitsstelling, toewijzing (Assigned)
3e. Bevestiging naar gebruiker (Confirmed)
Tussen 1e. en 3e. mag hooguit twee dagen verstijken. De bevestiging kan
ook inhouden: dit heeft lage prioriteit, we houden u op de hoogte. Een
bevestiging kan ook plaatsvinden voor prioriteitsstelling.
4e. Reproductie van de fout
Als 4e. problemen geeft, wordt teruggekoppeld naar de gebruiker:
architectuur/site specifieke problemen, kan gebruiker reproduceren?
Wanneer dit onderdeel meer dan een dag in beslag neemt, moet de
prioriteitstelling opnieuw worden bekeken.
5e. Analyse van de fout (Analysed)
Hier wordt de set van modules/bestanden waar de fout in kan zitten
afgebakend: tracen van de fout, controleren van asynchrone effecten etc.
Wanneer dit onderdeel meer dan een dag in beslag neemt, moet de
prioriteitstelling opnieuw worden bekeken. Afhankelijk van de locatie
van de fout kan de bug worden doorgeschoven naar een andere programmeur
(bv omdat die de modules geschreven of recent gewijzigd heeft).
6e. Formuleren van een oplossing of omleiding
Wanneer dit onderdeel meer dan een week in beslag neemt, moet de
prioriteitstelling opnieuw bekeken worden. Ook moet de gebruiker
een bericht krijgen dat de zaak wel eens wat langer kon duren.
7e. Implementeren van de oplossing of omleiding (Solved)
Als het implementeren van de geformuleerde oplossing langer dan een week
duurt, moeten we terug naar 6e.
8e. Validatie van de oplossing of omleiding (Tested)
Eventueel worden de wijzigingen gecontroleerd door de oorspronkelijke
auteur van de modules.
De gebruiker wordt verzocht op zijn site een test te draaien met de
gewijzigde modules (evt ftp van executable naar user systeem op die site).
9e. Afwikkeling van de fout (Released)
De wijzigingen worden in de NFRA Master geupdate, inclusief wijzigingen
van de documentatie.
De gebruiker die de bug gemeld had, wordt op de hoogte gesteld,
de master op zijn site wordt bijgewerkt.
Andere sites ontvangen een melding van de wijzigingen, en worden
eventueel bijgewerkt.
3. Revisions en releases
------------------------
Bij wijzigingen in Newstar kunnen we twee gevallen onderscheiden:
- de wijziging heeft een minimale invloed op het gebruik van de
programma's (afgezien van het ontbreken van crashes etc.);
kleine toevoegingen in functionaliteit vallen hier ook onder
- de wijziging heeft invloed op het gebruik van de programma's
(veranderde keywords, noodzaak om SCN files te converteren etc)
In het eerste geval spreken we van een revision van Newstar. Bij een
revision is het niet nodig dat elke gebruiker een melding van
dit heuglijke feit ontvangt. Ook is het niet nodig dat alle sites
een revision onmiddelijke ontvangen. Het exporteren van een revision
gebeurt door een beperkt aantal bestanden over te zenden (via een
revision groupfile: update retrieve .....grp)
In het tweede geval spreken we van een release van Newstar.
Een release wordt expliciet aangekondigd aan alle gebruikers (evt via
locale Newstar managers). Een release wordt ge\"exporteerd naar alle
sites. Voor een release wordt het volledige Master systeem van de site
gecontroleerd: update retrieve all)
4. Functionality requests
-------------------------
Voor functionality requests geldt in principe hetzelfde als voor bug,
met dien verstande dat het reproduceren van de fout vervalt, en dat de
overige stappen een langere tijdschaal hebben.
5. Implementatie: nbug
----------------------
In de NFRA Master staat een subdirectory $n_src/doc/bug waarin voor
elke bug een bestand wordt bijgehouden. Deze bestanden (project files)
kunnen met de Hypertext browser worden bekeken via een aantal indexen.
Onderlinge verbindingen zijn mogelijk.
Onafhankelijk van de manier waaop de bug binnenkomt (eMail, formulier AGB,
telefonisch, wandelgangen) wordt een project file gemaakt. Als de bug
elektronisch gerapporteerd werd, kan het betreffende bestand aan de
project file gekoppeld worden, anders moet de essentiele informatie
worden ingevoerd.
Wanneer nieuwe informatie beschikbaar komt (na toewijzing, bevestiging,
oplossing etc) wordt die toegevoegd aan de project file, eventueel met
een gekoppeld tekstbestand.
De bug-reports worden bijgehouden middels de utility "nbug", die een
hele reeks opties heeft. De meeste opties corresponderen met de diverse
stadia die een bug in zijn carriere kan doorlopen.
add Invoeren nieuwe bug (kent nummer toe, vraagt details)
confirm Ontvangstbevestiging
priority Prioriteitstelling (vraagt priority en assignment)
suspend Wordt tijdelijk niet aan gewerkt (behoudt prioriteit)
analysed Fout is gevonden
solved Fout is opgelost
tested Oplossing is getest
released Nieuwe software is vrijgegeven (priority wordt -1)
feedback Bevestiging van contact met melder
status Vraagt status op van bepaalde bug (kan beter via hypertext)
Bovenstaande opties vragen allemaal om een associated file en een
comment, en geven de optie om de project file te editen (emacs of $EDITOR).
Ze voeren ook automatisch een index commando uit. Indices kunnen op
ieder moment gemaakt worden met de index optie:
index Maakt de standard indexen voor de hypertext
- Alle bugs op volgorde van nummer
- Alle bugs op volgorde van prioriteit
- Alle actieve bugs op volgorde van prioriteit
Naast indices voor on-line toegang zijn (geprinte) lijsten vooralsnog
van groot belang. De volgende lijsten kunnen met de ndoc optie "list"
worden gemaakt:
list Maakt lijsten voor printout
full Alle bugs op volgorde van nummer
priority Alle bugs op volgorde van prioriteit
active Alle actieve bugs op volgorde van prioriteit
late Alle "vertraagde" bugs, dat is:
- ontvangen en niet binnen twee dagen bevestigd
- niet suspended en geen feedback binnen twee weken
- suspended of released en geen feedback binnen twee dagen
user Alle bugs van een bepaalde user (Pietje Puk etc)
programmer Alle bugs van een bepaalde programmeur (HjV, WNB, ...)
In de lijsten (en indices) verschijnt de bug als volgt:
ID Pr.ty Origin Worker Status Action/Feedback Description
------------------------------------------------------------------------------
0024 10 verheijen None Confirmed 930806/930823 Gridding in ..
0023 200 verheijen CMV Confirmed 930806/930823 NGIDS locks ..
:
0020 0 verheijen None Confirmed 930806/930823 NGIDS much t..
0019 300 verheijen, WHISP CMV Confirmed 930806/930823 NGIDS flaggi..
:
De volgende bestanden zijn van belang voor nbug:
$n_src/doc/bug/n????.prj Project file
$n_src/doc/bug/detail/n????.* Alle overige documenten
$n_src/doc/bug/nbug.txt "Home Page" met links naar indices
$n_src/doc/bug/nbug.idx Index op nummer
$n_src/doc/bug/npriority.idx Index op priority
$n_src/doc/bug/nactive.idx Index op priority voor actieve bugs
Al deze bestanden zijn normale ASCII file die naar believe kunnen worden
bijgewerkt voor veranderingen die niet door nbug worden ondersteund.
6. Prioriteitsstelling
----------------------
De voorlopige strategie voor de prioriteiten is als volgt:
- Prioriteiten lopen van 0 tot 900
- De honderdtallen doen dienst als grove prioriteitsklassen
Bugs uit 900-999 worden in principe het eerst aangepakt
- De tientallen doen dienst als een globaal werkschema binnen de
prioriteitsklassen. Bugs uit 990-999 worden in principe eerder
aangepakt dan bugs uit 980-989
- De eenheden zijn een kunstmatig middel om een bug omhoog te kunnen
schuiven zonder alle overige project files te moeten wijzigen.
Als een bug met prioriteit 700 zeer urgent wordt, urgenter dan
bestaande bugs met prioriteit 980, dan wordt de prioriteit gewijzigd
naar 981.
- Een tijdslimiet of schatting kan als commentaar bij de prioriteit-
stelling worden gegeven.
Een definitief systeem zal worden vastgesteld op basis van ervaringen met
het huidige voorstel.
6.1 Update on the priority system:
---------------------------------
There are now five priority classes:
100 - Critical bugs, that make it impossible to use vital programs
200 - Urgent requests or bugs
300 - Desirable things
400/500 - Pro memori
The priority scheme does not show any timeslicing, but is complemented
in this respect by the Project Plan.
The header tag Class has been added to distinguish between Bugs
and Requests, the tag Category shows the program (e.g. NSCAN, NPLOT)
with which the Bug/Request is mainly concerned.
7. Slotopmerkingen
------------------
Het moge duidelijk zijn dat een dergelijk systeem niet beperkt is tot
gebruik binnen Newstar. Met een aantal triviale wijzigingen in nbug
is het mogelijk voor een willekeurig software project een dergelijke
rapportage op te zetten.
Ook is deze strategie in principe bruikbaar voor alle processen waarbij
een "checklist" van status veranderingen moet worden bijgehouden.
Desgewenst kan de volgorde van veranderingen worden vastgelegd.
We kunnen nbug vergelijken met andere bug-reporting systemen (zoals bv het
GNATS systeem van GNU). Deze systemen hebben een grotere nadruk op
automatische interactie/responsies via electronische mail. De on-line
toegankelijkheid is kleiner dan bij nbug, evenals de centrale rapportage
mogelijkheden. Desgewenst kan meer eMail interactie worden ingebouwd in
nbug. Dit lijkt me in de huidige situatie (waar verreweg de meeste
klachten verbaal worden ingediend) nauwelijks de moeite.
Appendix A: Casus
-----------------
> _nbug add_
Creating bug-report project file with id-number 0036
Enter name of file with associated eMail: _~devoscm/tmp_
Enter origin [Pietje Puk]: __
Enter email address [Unknown]: _puk@rux.timboektoe.edu_
Enter subject [Unknown]: _Cannot make poststam images anymore_
Any comments: _Seems the same old problem again_
Please confirm the bug within two days and set a priority as soon
as possible. Indices for the bug-database will be updated.
Edit the project file (y,n)? [n] _n_
0036 0 Pietje Puk None Received 930909/000000
Cannot make poststamp images anymore
Updating indices...
After I called him back, I type...
> _nbug confirm 36_
0036 0 Pietje Puk None Received 930909/000000
Cannot make poststamp images anymore
Any comments: _Called back, Mr. Puk seems quite upset about this_
Associated file (may be -bugid or detail/...): __
Edit the project file (y,n)? [n] __
0036 0 Pietje Puk None Confirmed 930909/930909
Cannot make poststamp images anymore
Updating indices...
Then JEN decides this is quite important...
> _nbug priority_
Enter bug-id: _36_
0036 0 Pietje Puk None Confirmed 930909/930909
Cannot make poststamp images anymore
Enter (new) priority: _900_
Assign job to: _HjV_
Any comments: _Must be solved with a week_
Associated file (may be -bugid or detail/...): __
Edit the project file (y,n)? [n] __
0036 1000 Pietje Puk HjV Assigned 930909/930909
Cannot make poststamp images anymore
Updating indices...
So it is analysed immediately...
> _nbug analy 36_
0036 1000 Pietje Puk HjV Assigned 930909/930909
Cannot make poststamp images anymore
Any comments: _Missing check on array bounds in NPLSTM_
Associated file (may be -bugid or detail/...): _test.log_
Edit the project file (y,n)? [n] __
0036 1000 Pietje Puk HjV Analysed 930909/930909
Cannot make poststamp images anymore
Updating indices...
And when Dr. Puk calls me occasionally...
> _nbug feedback 36_
0036 1000 Pietje Puk HjV Analysed 930909/930909
Cannot make poststamp images anymore
Any comments: _Pietje called again, told him Henk found it_
Associated file (may be -bugid or detail/...): __
Edit the project file (y,n)? [n] __
0036 1000 Pietje Puk HjV Analysed 930909/930909
Cannot make poststamp images anymore
Updating indices...
Etc.
Appendix B: Format of project file and indices
----------------------------------------------
n0036.prj:
------------------------------------------------------------
<TITLE>Newstar Bug Report # 0036</TITLE>
<H1>Newstar Bug Report # 0036 </H1>
<DT><STRONG>Origin:</STRONG> Pietje Puk
<DT><STRONG>Address:</STRONG> puk@rux.timboektoe.edu
<DT><STRONG>Subject:</STRONG> Cannot make poststamp images anymore
<DT><STRONG>Status:</STRONG> Analysed
<DT><STRONG>Priority:</STRONG> 1000
<DT><STRONG>Worker:</STRONG> <A HREF=../html/people.html#HjV>HjV</A>
<DT><STRONG>Last action:</STRONG> 930909
<DT><STRONG>Last feedback:</STRONG> 930909
<P>
<H2>Detailed description</H2>
<P>
<H2>History</H2>
<DT>930909 18:05 - <STRONG>Received</STRONG> by Marco de Vos
<DD>Seems the same old problem again
(<A HREF=detail/n0036.1>detail</A>)
<DT>930909 18:07 - <STRONG>Confirmed</STRONG> by Marco de Vos
<DD>Called back, Mr. Puk seems quite upset about this
<DT>930909 18:07 - <STRONG>Assigned (HjV, priority 1000)</STRONG> by Jan Noordam
<DD>Must be solved with a week
<DT>930909 18:08 - <STRONG>Analysed</STRONG> by Henk Vosmeijer
<DD>Missing check on array bounds in NPLSTM
(<A HREF=detail/n0036.2>detail</A>)
<DT>930909 18:09 - <STRONG>Feedback</STRONG> by Marco de Vos
<DD>Pietje called again, told him Henk found it
------------------------------------------------------------
nbug.idx:
------------------------------------------------------------
<TITLE>Newstar Bug Index: all keys</TITLE>
<H1>Index of all bugs sorted on ID number</H1>
<P>
<LI> For an index sorted on priority, click <A HREF=npriority.idx>here</A>
<LI> For an index of active items only, click <A HREF=nactive.idx>here</A>
<P>
<TT><DT>BugID Pr.ty - Subject
<DD><STRONG>Status...</STRONG> - Action/Feedback
(<EM>Origin</EM> - Worked on)</TT><P>
<TT><DT><A HREF=n0001.prj>0001</A>: +0000 </TT> - Lines in NPLOT to ...
<TT><DT><A HREF=n0002.prj>0002</A>: +0000 </TT> - Programs stay sile...
------------------------------------------------------------
This diff is collapsed.
Beste mensen,
Op /user4/92calib staan 5 modellen voor 325 MHz
van 5 in Westerbork gebruikte calibrators (3C48, 147,
286, 295 en 345)
Ze bevatten ruim honderd componenten, voldoende voor een
nauwkeurige zelfcalibratie.
Bedenk echter het volgende:
1) Ze gelden voor 325 MHz en als je ze in NCALIB
wilt gebruiken op andere banden van het
breedband 92cm systeem moet de BEAM optie aangezet
worden. Dat corrigeert dan in eerste orde (met behulp
van een (cos**6(cfr) functie) voor de veranderende primaire
bundel (met c=0.0629 dat nu geldt voor alle
frequenties beneden 500 MHz). Echter op de laagste frequenties
is de bundel waarschijnlijk breder dan een simpele
frequentie schaling. Daar moet dan dus een nieuwe
coefficient voor worden bepaald alsmede een nieuw frequentie
interval waarvoor die constante geldt voor worden gecreeerd.
2) De calibratie bronnen zijn in werkelijkheid natuurlijk minder sterk
op de hogere frequenties. Maar om redenen uitgelegd in een
README help file in dezelfde directory wordt daar NIET voor
gecorrigeerd !! Daar moeten de astronomen zelf voor corrigeren
met behulp van de spectrale indices van die bronnen.
3) De bron 3C345 mag niet als flux calibrator gebruikt worden omdat
hij in fluxdichtheid varieert. Deze bron wordt slechts zo af en toe
gemeten om dat hij gepolariseerd is waardoor met behulp van het Stokes
U signaal het phase verschil van de XX en YY kanalen gecontroleerd
kan worden onder de aanname dat V=0 (VZERO optie in NCALIB-polar)
Deze bron heeft ook een RM van ongeveer 15-20 rad/m**2 waardoor de
Stokes Q en U percentages afhangen van frequentie.
Deze percentages staan dus ook niet in het model.
Ze zijn trouwens afhankelijk van de ionosferische Faraday draaiiing
die niet nauwkeurig bekend is.
4) Voor de bron 3C303 (die ook i.v.m. met zijn hoge lineaire
polarisatie wordt waargeneomen, net als 3C345)
wacht ik nog steeds op een aantal metingen
waaruit ik een goede kaart kan maken waaruit een model te halen is.
Verder geldt voor deze bron hetzelfde als voor 3C345 behalve dat hij
niet verandert in flux dichtheid.
Henk: Kun jij deze modellen neerzetten op de plaats waar NEWSTAR
zijn default modellen weghaalt.
Als er vragen zijn dan hoor ik het wel.
Ger
--
A.G. de Bruyn (Ger) | Internet: ger@astron.nl
NFRA |
Postbus 2 | Phone: (31)-521-595257
7990 AA Dwingeloo | Fax: (31)-521-597332
The Netherlands
hlp/cmv.gif

8.88 KiB

Trapping control-C in Newstar programs --------------------------------------
(contributed by JPH 941005, gleaned from wndpar_x.fun, wngex.for)
INCLUDE WXH_DEF ...
XHCC(0)=1 ! inhibit ...
XHCC(0)=0 ! clear
IF (XHCC(1) .NE.0) THEN ! was a control-C caught?
XHCC(1)=0
<action, typically CALL WNGEX>
ENDIF
This code has been used to create module WNGCC with entry points
WNGCCD disable control-C
WNGCCE enable control-C
LOGICAL WNGCCC check and reset 'control-c seen' status
and several other entry points to check, count and reset the number of
interrupts seen.
The implementation is in entry point WNGEX0 in wngex.for. This routine
is declared the handler for signal SIGINT by wngsxh.fsc. Its action is very
simple:
if xhcc(0) !=0
xhcc(1)+=1
else
fall through to WNGEX
endif
This diff is collapsed.
Efficient use of the dbx debugger on the SUNs
---------------------------------------------
(contributed by JPH 940919; based on research by CMV)
For the convenience of programmers who want to use dbx with Newstar
programs, the objects in the Newstar libraries are routinely compiled with the
-g option (Newstar nsh option 'build -d') which creates objects including the
necessary symbolic information. When an executable is built with this same
option, all this information is carried over, resulting in a .exe file in which
all modules are accessible to dbx.
This is very convenient for a programmer who needs access not only to
modules that he is modifying in his own shadow system but also to other
unmodified modules in the master libraries; indeed, there is no need for him to
copy master files to his shadow system for the mere purpose of recompiling them.
The disadvantage is that the .exe file carries a huge ballast of
symbolic information (typically several hundred thousands of items) which take
a long time (many minutes) to load at the expense of a more than unmodest
consumption of machine resources.
CMV found the following simple procedure to load only those symbols
that one actually needs:
> dbx
dbx> modules select <object_1>.o, <object_2>.o, ...
dbx> debug <$n_exe/<program>.exe
dbx> <set breakpoints or whatever>
dbx> run
Should one discover in the subsequent debugging session that more modules are
needed, then one may restart the above sequence without leaving dbx.
Breakpoints and the like remain valid, but the modules selected before must
again be spelled out, - this is not nice but usually one needs only a few ...
This diff is collapsed.
<TITLE>Description of ASK (DWARF)</TITLE>
<H1>Program DWARF: private keyword ASK</H1>
<DT><EM>Prompt:</EM> YES, NO
<DT><EM>Default:</EM> NO.
<DT><EM>Expected input:</EM> Character(4).<P>
ASK=YES directs DWARF programs to always prompt for parameters, even if <P>
an external default has been defined (through SPECIFY or otherwise).
This setting can be overridden by use of the /NOASK qualifier with the
EXECUTE command or with run-time parameter input. <P>
<H3> More information: </H3> <UL>
<LI><A HREF="../dwarf/dwarf_keys.html">List of keywords</A> for DWARF
<LI><A HREF="../homepage.html">NEWSTAR Documentation Home page</A>
<LI>Description of <A HREF="../dwarf_descr/dwarf_descr.html">program DWARF</A>
<LI>The <A HREF="../common_descr/common_descr.html">DWARF User Interface</A>
</UL>
<TITLE>Description of BELL (DWARF)</TITLE>
<H1>Program DWARF: private keyword BELL</H1>
<DT><EM>Prompt:</EM> ON, OFF Terminal bell with prompts and error messages
<DT><EM>Default:</EM> OFF.
<DT><EM>Expected input:</EM> Character(4).<P>
Controls the sounding of the terminal bell with error messages and <P>
with prompts for parameters <P>
<H3> More information: </H3> <UL>
<LI><A HREF="../dwarf/dwarf_keys.html">List of keywords</A> for DWARF
<LI><A HREF="../homepage.html">NEWSTAR Documentation Home page</A>
<LI>Description of <A HREF="../dwarf_descr/dwarf_descr.html">program DWARF</A>
<LI>The <A HREF="../common_descr/common_descr.html">DWARF User Interface</A>
</UL>
<TITLE>Description of CURNODE (DWARF)</TITLE>
<H1>Program DWARF: private keyword CURNODE</H1>
<DT><EM>Prompt:</EM> Current node name
<DT><EM>Default:</EM> 0.
<DT><EM>Expected input:</EM> Character(80).<P>
This is the node name with respect to which relative node names, i.e. <P>
node specifications starting with "." or "-", will be expanded <P>
<H3> More information: </H3> <UL>
<LI><A HREF="../dwarf/dwarf_keys.html">List of keywords</A> for DWARF
<LI><A HREF="../homepage.html">NEWSTAR Documentation Home page</A>
<LI>Description of <A HREF="../dwarf_descr/dwarf_descr.html">program DWARF</A>
<LI>The <A HREF="../common_descr/common_descr.html">DWARF User Interface</A>
</UL>
<TITLE>Description of EXTENDSIZE (DWARF)</TITLE>
<H1>Program DWARF: private keyword EXTENDSIZE</H1>
<DT><EM>Prompt:</EM> Default extension size in blocks for DWARF data files
<DT><EM>Default:</EM> 64.
<DT><EM>Expected input:</EM> Integer number; min.value: 1.000000; max.value: 512.000000.<P>
Defines the minimum extension size to be applied by DWARF I/O routines. <P>
An actual extension will be the maximum of this parameter and the extension
requested by the program. <P>
<H3> More information: </H3> <UL>
<LI><A HREF="../dwarf/dwarf_keys.html">List of keywords</A> for DWARF
<LI><A HREF="../homepage.html">NEWSTAR Documentation Home page</A>
<LI>Description of <A HREF="../dwarf_descr/dwarf_descr.html">program DWARF</A>
<LI>The <A HREF="../common_descr/common_descr.html">DWARF User Interface</A>
</UL>
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment