Project "DveGen" - database generator

Hardware, software, internetsites

Berichtdoor Snelbinder » do aug 23, 2007 10:09 am

Ik moet er nog beter naar kijken, maar er valt me direct op dat het aantal spaties (dus plusjes) in "W+US+10-00" niet klopt. Dat had "W+US+++10-00" moeten zijn. Misschien dat de nieuwe DveGen ergens die spaties weghaalt?

Trouwens, ter bevestiging: ik heb je mail ontvangen.

Trouwens2: de interface naar COA is ietsje veranderd. In plaats van
http://coa.inducks.org/coa/c1/story.php/0/W+OS+++79-01
is het nu:
http://coa.inducks.org/story.php?c=W+OS+++79-01
De oude links werken nog wel, maar zijn iets minder stabiel (en verdwijnen misschien later). Bovendien geeft de "0" in de oude URL aan dat het de Engelse pagina moet zijn, terwijl je bij de nieuwe URL je eigen taal te zien krijgt (in ons geval waarschijnlijk Nederlands).

Misschien kun je dat zelf al in de DEF-files aanpassen?
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » do aug 23, 2007 10:16 am

Dat wat ik zei van dat Engels klopt kennelijk niet, dus vergeet dat stukje maar.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » do aug 23, 2007 4:38 pm

2119:field <publicationdate> of record <bbde_ct_gl200002> not found [printing record awdrs_us0035-02 on section default]
Deze foutmelding lijkt te verschijnen als "publicationdate" onder "bbde_ct_gl200002" leeg is.
Interessant. Is dat nieuw?
Misschien kan ik het beste overal "[unknown]" invullen waar ik geen informatie heb. In plaats van velden leeg te laten.

Ik zie hem vandaag niet meer terugkomen in de logfiles.
Ik weet niet (meer) of deze melding nieuw is. Maar hij komt voor als je expliciet zo'n veld wil gebruiken (bijvoorbeeld in een %field()-opdracht).
Zoals jij kennelijk deed in je input:
#publicationdate %field(bbde_ct_gl200002,publicationdate) (%field(bbde_ct_gl200002,country))

2131:%val not possible (no current field available) [printing record text_s_1950s_model_sheets on section l_credits]
Hier snap ik niets van. Wat is waar fout en hoe?

Het probleem zit hem in dit stukje in de file dbarticles.def:
##l_credits
!
#title
<b>%link(%self,default,%val)</b>:

Bij een %link kun je als derde parameter geen %val opgeven.
Zie http://bolderbast.inducks.org/dvegen/phf_perc_link.html

(Of het logisch is dat dit niet kan, weet ik niet meer...)
Maar je kunt het eenvoudig veranderen in:

##l_credits
!
#title
<b>%namedlink(%self,default,title)</b>:

2503:page field <title> is printed nowhere! [checking usage of record perk1]
Gaat dit over "barkstree.txt"?

Ja. Dat is de enige plek waar je "perk1" gebruikt. Vanwege de "#hide YES" wordt de title kennelijk nergens gebruikt.

2503:page field <40;1942> is printed nowhere! [checking usage of record comicsos0009]
2503:page field <41;> is printed nowhere! [checking usage of record comicsos0009]

Hiervan zijn veel meer dergelijke foutmeldingen. Blijkbaar hebben ze te maken met het gebruik van een "&"-teken (HTML-code) in het veld "#longtitle". In de HTML-output van dit voorbeeld staat "0009 - 0262 &" in de lijst.
De HTML-code ( staat voor "(". Deze HTML-code is blijkbaar gebruikt als workaround die niet (meer?) werkt.

Het probleem is de '#'! In een TREE.TXT-file laat ik het toe dat een nieuw veld met een # begint, ook al is dat niet aan het begin van een regel!
Dat was vooral voor mijn eigen gemak: omdat ik overzicht wil houden in mijn TREE-files, zet ik sommige velden bijelkaar op 1 regel.
Nooit gedacht dat dat nog eens problemen zou geven met een #...

Is dat # echt nodig? Kun je in dit geval niet gewoon ( en ) gebruiken?

Het veld "#longtitle" is geen opdracht. Vanwaar deze strengheid?

Ik begrijp de vraag niet (maar misschien is het na bovenstaande niet relevant?).

2503:page field <title> is printed nowhere! [checking usage of record perk1]

2503:page field <title> is printed nowhere! [checking usage of record perk2]
2503:page field <title> is printed nowhere! [checking usage of record perk3]
2503:page field <title> is printed nowhere! [checking usage of record zzzideleap]
2503:page field <title> is printed nowhere! [checking usage of record zzzooi_cr]
2503:page field <title> is printed nowhere! [checking usage of record perk4]

Wat is de oorzaak van deze foutmelding?

Is dat niet hetzelfde als wat je eerder schreef? Die titles zullen wel nergens gebruikt worden wegens "#hide YES".
Of in het geval van zzzideleap denk ik dat de "l_lockmanheader" geen titel bevat!

1503:Fieldlayout <inducks.titlepref> is not used [checking usage of layout dbanimation.def/default]
Gaat dit om ongebruikte layouts die verwijderd kunnen worden?

Tja, kennelijk is er geen enkel Inducks-record dat in een layout van animation.def wordt afgedrukt. Terwijl die layout wel afdrukregels voor Inducks-velden bevat. Die afdrukregels zijn dus overbodig.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » do aug 23, 2007 4:48 pm

Daniel73 schreef:Nog iets over de huidige status van "dvegen.log". Er zijn Inducks-foutmeldingen over codes die eerder wel werkten.
1403:Inducks record <OS 9> not found [looking for inducks reference of bbus_cm_os0009]

Dat blijkt inderdaad een spatieprobleem te zijn. Bij het vereenvoudigen van de DveGen-sourecode heb ik er kennelijk niet aan gedacht dat jij maar een spatie gebruikt in "OS 9", terwijl Inducks de codes met meer spaties aanlevert ("OS<spatie><spatie><spatie>9").

We kunnen 2 dingen doen:

1. ik pas DveGen aan;
2. jij voegt op diverse plekken spaties toe (een Amerikaanse issuecode heeft altijd dezelfde lengte).

Puntje 1 kost mij wat tijd, puntje 2 kost jou wat tijd. Welke zullen we kiezen? :)

Ik weet trouwens niet of je mijn favoriete editor nog gebruikt. Daarin kun je de spaties zien, met de menu-opdracht Edit/Advanced/View Whitespace.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Daniel73 » do aug 23, 2007 4:51 pm

De sublist-layout is in output lelijk geworden. Vroeger werden regeleindes in lijsten aangehouden. Nu worden ze als een lange regel geplaatst.
Zie het Guidebook-voorbeeld hieronder.

Oude situatie in "index.html":
<!-- DIT IS DE DOOR DVE AANGEMAAKTE SUBLIST1-LAYOUT (IN DE FILE DBDUMMY.DEF) -->
<ul>
<li><a href="art.html">ART</a></li>
<li><a href="anim00.html">ANIMATION</a></li>
<li><a href="comics00.html">COMICS</a></li>
<li><a href="char.html">CHARACTERS</a></li>
<li><a href="qts.html">QUOTES</a></li>
<li><a href="diary.html">DIARY</a></li>
<li><a href="photos.html">PHOTOGRAPHS</a></li>
<li><a href="bibliography.html">BIBLIOGRAPHY</a></li>
<li><a href="links.html">LINKS</a></li>
<li><a href="credits00.html">SOURCES</a></li>
</ul>

Huidige situatie in "index.html":
<!-- DIT IS DE DOOR DVE AANGEMAAKTE L_SUBLIST1-LAYOUT (IN DE FILE DBDUMMY.DEF) -->
<ul>
<li><a href="art.html">ART</a><li><a href="anim00.html">ANIMATION</a><li><a href="comics00.html">COMICS</a><li><a href="char.html">CHARACTERS</a><li><a href="qts.html">QUOTES</a><li><a href="diary.html">DIARY</a><li><a href="photos.html">PHOTOGRAPHS</a><li><a href="bibliography.html">BIBLIOGRAPHY</a><li><a href="links.html">LINKS</a><li><a href="credits00.html">SOURCES</a></ul>

De "<ul>" staat wel in beide gevallen op een aparte regel. Wat volgens mij betekent dat regeleindes in principe wel herkend moeten kunnen worden.
Doe ik iets verkeerd?
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Snelbinder » do aug 23, 2007 4:53 pm

Ik ben trouwens van plan een nieuwe manier te gebruiken om data uit Inducks te krijgen.
Dat gaat via een COA-webpagina:
http://coa.inducks.org/sql.php/
Waar je dan zelf een (door mij geschreven) SQL-toverformule in kunt vullen, waarna je het resultaat kunt opslaan als headersus.ine resp. storiesCB.ins.
Met zo'n SQL-toverformule kan ik wat flexibeler zijn in de selectie van Barks-verhalen. Bijvoorbeeld de verhalen die hertekend zijn door Jippes wel meenemen, maar voorplaten door onbekende tekenaars niet.

Uiteraard moet ik die formules nog schrijven en uitproberen...
Maar dit is typisch iets wat een andere SQL-expert ook zou kunnen doen (leest Sander nog mee? :) )
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » do aug 23, 2007 5:00 pm

Daniel73 schreef:De sublist-layout is in output lelijk geworden. Doe ik iets verkeerd?

Voeg </li> en een lege regel toe in BARKSTREE.DEF. Oude code:
##l_treesub
#if(node.nexttochosen=true)
<li>%namedpagelink(%self,longtitle)

Nieuwe code:

##l_treesub
#if(node.nexttochosen=true)
<li>%namedpagelink(%self,longtitle)</li>

! Hierboven staat een lege regel die je op dit BB alleen ziet als ik er een commentaarregel achter zet
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Daniel73 » do aug 23, 2007 8:39 pm

Snelbinder schreef:Trouwens2: de interface naar COA is ietsje veranderd. In plaats van
http://coa.inducks.org/coa/c1/story.php/0/W+OS+++79-01
is het nu:
http://coa.inducks.org/story.php?c=W+OS+++79-01
De oude links werken nog wel, maar zijn iets minder stabiel (en verdwijnen misschien later). [...] Misschien kun je dat zelf al in de DEF-files aanpassen?

Ik heb de url-aanpassingen gemaakt.

issues oud: http://coa.inducks.org/coa/c1/story.php/0/
issues nieuw: http://coa.inducks.org/story.php?c=

stories oud: http://coa.inducks.org/coa/c1/issue.php/0/us/
stories nieuw: http://coa.inducks.org/issue.php/x/us/

Bij issue OS 79 krijg ik, in het Engels:
us/OS 79
Issue not found

http://coa.inducks.org/issue.php/x/us/OS+79

Bij story W OS 79-01 krijg ik, in het Nederlands:
Geen verhalen gevonden

http://coa.inducks.org/story.php?c=W+OS+79-01

Bij issue WDC 104 en story W WDC 104-02 krijg ik wel wat ik zoek.
http://coa.inducks.org/issue.php/x/us/WDC+104
http://coa.inducks.org/story.php?c=W+WDC+104-02

Snelbinder schreef:
#publicationdate %field(bbde_ct_gl200002,publicationdate) (%field(bbde_ct_gl200002,country))

2131:%val not possible (no current field available) [printing record text_s_1950s_model_sheets on section l_credits]
Hier snap ik niets van. Wat is waar fout en hoe?

Het probleem zit hem in dit stukje in de file dbarticles.def:
##l_credits
!
#title
<b>%link(%self,default,%val)</b>:

Bij een %link kun je als derde parameter geen %val opgeven.
Zie http://bolderbast.inducks.org/dvegen/phf_perc_link.html

(Of het logisch is dat dit niet kan, weet ik niet meer...)
Maar je kunt het eenvoudig veranderen in:

##l_credits
!
#title
<b>%namedlink(%self,default,title)</b>:


Probleem is dat ik twee mogelijkheden heb voor een waarde.
Het veld "title" is onderverdeeld in twee velden:
#myanimationtitle: het item heeft een eigen titel
#myanimationdesc: het item heeft geen eigen titel

Zie "dbanimation.def":
##l_credits
#always
<b>%link(%self,default,)</b>
!
#myanimationtitle
<B>%val</B>
!
#myanimationdesc
<B>%val</B>

Kan ik hier een "if"-opdracht geven?
Bijvoorbeeld:
- Als #myanimationtitle bestaat, doe dan...
- Als #myanimationdesc bestaat, doe dan...
Is zoiets mogelijk hier?

Snelbinder schreef:
2503:page field <title> is printed nowhere! [checking usage of record perk1]
Gaat dit over "barkstree.txt"?

Ja. Dat is de enige plek waar je "perk1" gebruikt. Vanwege de "#hide YES" wordt de title kennelijk nergens gebruikt.

Volgens mij zou die "#hide YES" moeten zorgen dat er niet over geklaagd wordt.

Bij Nijgh heb ik het probleem blijkbaar opgelost door de title in commentaarregels te zetten:
#code perk1
!!! #title TOBIA-NIJGH
#hide yes
#linkallowedfromoutside yes

De "title" is hier bedoeld als een omschrijving van de input zelf. Misschien kan ik beter een "nontitle" maken met een %noval-opdracht. Maar waar stel ik dat in?

De velden "#hide" en "#linkallowedfromoutside" komen alleen in txt-bestanden voor en zijn dus blijkbaar velden van DveGen zelf. Of niet?

Snelbinder schreef:
2503:page field <40;1942> is printed nowhere! [checking usage of record comicsos0009]
2503:page field <41;> is printed nowhere! [checking usage of record comicsos0009]

Hiervan zijn veel meer dergelijke foutmeldingen. Blijkbaar hebben ze te maken met het gebruik van een "&"-teken (HTML-code) in het veld "#longtitle". In de HTML-output van dit voorbeeld staat "0009 - 0262 &" in de lijst.
De HTML-code ( staat voor "(". Deze HTML-code is blijkbaar gebruikt als workaround die niet (meer?) werkt.

Het probleem is de '#'! In een TREE.TXT-file laat ik het toe dat een nieuw veld met een # begint, ook al is dat niet aan het begin van een regel!
Dat was vooral voor mijn eigen gemak: omdat ik overzicht wil houden in mijn TREE-files, zet ik sommige velden bijelkaar op 1 regel.
Nooit gedacht dat dat nog eens problemen zou geven met een #...

Is dat # echt nodig? Kun je in dit geval niet gewoon ( en ) gebruiken?

De "#" is echt nodig. Anders ben ik beperkt in het geven van, in dit geval, longtitles.
Het is bijvoorbeeld gangbaar om "#" te gebruiken bij werken waarvan meer versies zijn. (Take #1, take #2, take #3, etc.)

Snelbinder schreef:
Het veld "#longtitle" is geen opdracht. Vanwaar deze strengheid?

Ik begrijp de vraag niet (maar misschien is het na bovenstaande niet relevant?).

Ik ging er vanuit dat "#longtitle" een vrij veld was en ergens gedefinieerd stond in een DEF-bestand, met een %val.
Maar ik kan het nergens vinden in de DEF-bestanden.

Snelbinder schreef:Of in het geval van zzzideleap denk ik dat de "l_lockmanheader" geen titel bevat!

De "##header" bevat evenmin een title. En bij andere l_lockmanheaders heb ik geen foutmelding.
Dus ik snap niet waarom "zzzideleap" dan een foutmelding geeft.

Snelbinder schreef:
1503:Fieldlayout <inducks.titlepref> is not used [checking usage of layout dbanimation.def/default]
Gaat dit om ongebruikte layouts die verwijderd kunnen worden?

Tja, kennelijk is er geen enkel Inducks-record dat in een layout van animation.def wordt afgedrukt. Terwijl die layout wel afdrukregels voor Inducks-velden bevat. Die afdrukregels zijn dus overbodig.

Oke. Die ga ik opschonen of/en alsof gebruiken. Ze staan onderaan gegroepeerd in het logbestand, dus ik zal ze voorlopig even negeren.

Snelbinder schreef:
Daniel73 schreef:Nog iets over de huidige status van "dvegen.log". Er zijn Inducks-foutmeldingen over codes die eerder wel werkten.
1403:Inducks record <OS 9> not found [looking for inducks reference of bbus_cm_os0009]

Dat blijkt inderdaad een spatieprobleem te zijn. Bij het vereenvoudigen van de DveGen-sourecode heb ik er kennelijk niet aan gedacht dat jij maar een spatie gebruikt in "OS 9", terwijl Inducks de codes met meer spaties aanlevert ("OS<spatie><spatie><spatie>9").

We kunnen 2 dingen doen:

1. ik pas DveGen aan;
2. jij voegt op diverse plekken spaties toe (een Amerikaanse issuecode heeft altijd dezelfde lengte).

Puntje 1 kost mij wat tijd, puntje 2 kost jou wat tijd. Welke zullen we kiezen? :)

Het gaat mij niet om de tijd van het editen. Dat zou zo gebeurd zijn. Het gebruik van enkele spaties is echter doelbewust zo ingevoerd.
Reden waarom enkele spaties waren toegestaan is dat het veel tijd kost voor gebruikers (waaronder ik) om codes volgens een vast invoer-stramien terug te vinden. En lang niet alle editors en viewers geven de mogelijkheid om spaties te tonen.

Bij de COA-zoekmnachine is de invoer van enkele spaties toegestaan:
COA Verhaalcode: w wdc 50-02
COA Resultaat: http://coa.inducks.org/story.php?c=W+WDC++50-02&search=

Dus als je het niet heel erg vindt ga ik voor optie 1... :)

Snelbinder schreef:Ik weet trouwens niet of je mijn favoriete editor nog gebruikt. Daarin kun je de spaties zien, met de menu-opdracht Edit/Advanced/View Whitespace.

Bedoel je Microsoft Developer Studio 97? Die gebruik ik.
Tegen mijn verwachtingen in kon ik deze installeren onder Windows XP.

Wat ik momenteel nog mis is "Editpad". Met die editor kon ik regeleindes meenemen in zoek/vervang-opdrachten. Zo'n optie zou verplicht moeten zijn voor editors.

Snelbinder schreef:Ik ben trouwens van plan een nieuwe manier te gebruiken om data uit Inducks te krijgen.
Dat gaat via een COA-webpagina:
http://coa.inducks.org/sql.php/
Waar je dan zelf een (door mij geschreven) SQL-toverformule in kunt vullen, waarna je het resultaat kunt opslaan als headersus.ine resp. storiesCB.ins.
Met zo'n SQL-toverformule kan ik wat flexibeler zijn in de selectie van Barks-verhalen. Bijvoorbeeld de verhalen die hertekend zijn door Jippes wel meenemen, maar voorplaten door onbekende tekenaars niet.

Uiteraard moet ik die formules nog schrijven en uitproberen...
Maar dit is typisch iets wat een andere SQL-expert ook zou kunnen doen (leest Sander nog mee? :) )

Interessant.

In Dvegen wil ik tezijnertijd een lijst definiëren waarin alle items staan die in Inducks ontbreken. Is dat automatisch mogelijk? Zoals bijvoorbeeld in het logbestand al gebeurd?

Snelbinder schreef:
Daniel73 schreef:De sublist-layout is in output lelijk geworden. Doe ik iets verkeerd?

Voeg </li> en een lege regel toe in BARKSTREE.DEF. Oude code:
##l_treesub
#if(node.nexttochosen=true)
<li>%namedpagelink(%self,longtitle)

Nieuwe code:

##l_treesub
#if(node.nexttochosen=true)
<li>%namedpagelink(%self,longtitle)</li>

! Hierboven staat een lege regel die je op dit BB alleen ziet als ik er een commentaarregel achter zet


Resultaat in output:
<!-- DIT IS DE DOOR DVE AANGEMAAKTE L_SUBLIST1-LAYOUT (IN DE FILE DBDUMMY.DEF) -->
<ul>
<li><a href="art.html">ART</a></li>

<li><a href="anim00.html">ANIMATION</a></li>

<li><a href="comics00.html">COMICS</a></li>

<li><a href="char.html">CHARACTERS</a></li>

<li><a href="qts.html">QUOTES</a></li>

<li><a href="diary.html">DIARY</a></li>

<li><a href="photos.html">PHOTOGRAPHS</a></li>

<li><a href="bibliography.html">BIBLIOGRAPHY</a></li>

<li><a href="links.html">LINKS</a></li>

<li><a href="credits00.html">SOURCES</a></li>

</ul>

Blijkbaar gaat het om alleen "</li>".

Resultaat van "</li>" zonder lege regel:
<!-- DIT IS DE DOOR DVE AANGEMAAKTE L_SUBLIST1-LAYOUT (IN DE FILE DBDUMMY.DEF) -->
<ul>
<li><a href="art.html">ART</a></li>
<li><a href="anim00.html">ANIMATION</a></li>
<li><a href="comics00.html">COMICS</a></li>
<li><a href="char.html">CHARACTERS</a></li>
<li><a href="qts.html">QUOTES</a></li>
<li><a href="diary.html">DIARY</a></li>
<li><a href="photos.html">PHOTOGRAPHS</a></li>
<li><a href="bibliography.html">BIBLIOGRAPHY</a></li>
<li><a href="links.html">LINKS</a></li>
<li><a href="credits00.html">SOURCES</a></li>
</ul>

Ik heb vroeger(!) geleerd dat "</li>" overbodig is in HTML. Maar waar het om gaat is dat DveGen hier blijkbaar ineens HTML kan lezen.
Heb je dat zo bedoeld, of is het onverwacht?

Een HTML-code zou wat mij betreft niets uit moeten maken. Want het gaat om een txt-regeleinde.
Zou een optie als "%break" (naast het bestaande "%nobeak") misschien uitkomst kunnen bieden?
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Daniel73 » do aug 23, 2007 8:44 pm

Daniel73 schreef:(naast het bestaande "%nobeak")

No beak. Geen snavel...
Dat moet "%nobreak" zijn. :D
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Daniel73 » do aug 23, 2007 9:16 pm

Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Daniel73 » za aug 25, 2007 12:54 pm

Ga ik aan de slag met DveGen in deze hopeloos grauwe zomer, gaat de zon schijnen...

Per e-mail stuur ik je "070824_guidebook.zip" en "070824_nijgh.zip".
- In het guidebook-bestand zijn de veranderingen minimaal. Ik heb alleen de index-pagina aangepast, die ik in de output had veranderd toen ik niet bij de input kon komen.
- In het nijgh-bestand heb ik (met name) zoveel mogelijk van mijn %error-meldingen verwerkt. Op vier na.
Van zichzelf geeft DveGen geen foutmeldingen. Alleen een attenderende reeks "1504:Fieldlayout [...] is not used", maar die negeer ik nog even.

Hier de overgebleven vier %error-meldingen in Nijgh:
2103:%Error: aparte linken-sectie maken [printing record dummyformain on section l_sublist1]
2103:%Error: bibiliografie-lijst in output werkt niet goed, Zilver mag er niet zomaar bij staan [printing record lnpr00_19711108 on section default]
2103:%Error: bibiliografie-lijst in output werkt niet goed, Zilver mag er niet zomaar bij staan [printing record lnpr00_1971a on section default]
2103:%Error: brief in aparte sectie zetten [printing record lnmzrt00_19731011_00 on section default]

De eerste en de vierde zijn een herinnering voor mij om aparte secties op te zetten voor linken en correspondentie. Zoals ik die bij Barks heb:
http://www.seriesam.com/barks/qts.html
http://www.seriesam.com/barks/links.html
Dat is eenvoudig te doen voor mij. Ik kan het een en ander bij guidebook jatten.

De tweede en de derde %error-melding "bibiliografie-lijst in output werkt niet goed" is volgens mij onzin. Ik denk een vergissing van mij, of een fout die inmiddels is opgelost.
Deze twee %error-meldingen zal ik verwijderen. Mocht er later toch iets aan de hand zijn, dan zijn ze nu bij deze gedocumenteerd.

Kortom, bovenstaande %error-meldingen kan ik waarschijnlijk zelf oplossen.

Maar dan nu, een output-fout waarvan DveGen geen melding geeft:
In output-sectie 'Namen' verschijnen hier en daar items dubbel in de automatische lijsten.
Zie (bijvoorbeeld) Willem Nijholt in "lnnm_nn.html#lnnm00nijholt_w". Onder kopje "Gerelateerd werk" ("Muziek anderen") staan daar titels dubbel vermeld.
Geen idee of het komt door het omzetten van input, waar ik mee bezig was en ben. Of dat het komt door een verandering in DveGen. Of beide.

Verder lijkt Nijgh geen problemen te geven. Ik heb nog wel een flinke klus aan het doorvoeren van aanpassingen.
Maar eerst zal ik, evenals bij Guidebook, ongewenste "off-record"-informatie gaan verwijderen uit de input. Dan kan de input alvast online.
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Snelbinder » vr aug 31, 2007 12:00 pm

Daniel73 schreef:Bij issue OS 79 krijg ik, in het Engels: Issue not found
Bij story W OS 79-01 krijg ik, in het Nederlands: Geen verhalen gevonden
Bij issue WDC 104 en story W WDC 104-02 krijg ik wel wat ik zoek.

Dat klopt dus helemaal. In W WDC 104-02 hoeven geen spaties toegevoegd te worden. In OS 79 wel.
Dat sommige teksten op COA in het Engels zijn komt omdat ik nog niet alles heb vertaald.

Daniel73 schreef:Probleem is dat ik twee mogelijkheden heb voor een waarde.
Het veld "title" is onderverdeeld in twee velden:
#myanimationtitle: het item heeft een eigen titel
#myanimationdesc: het item heeft geen eigen titel

Zie "dbanimation.def":
##l_credits
#always
<b>%link(%self,default,)</b>
!
#myanimationtitle
<B>%val</B>
!
#myanimationdesc
<B>%val</B>

Kan ik hier een "if"-opdracht geven?
Bijvoorbeeld:
- Als #myanimationtitle bestaat, doe dan...
- Als #myanimationdesc bestaat, doe dan...
Is zoiets mogelijk hier?

Je kunt hier volgens mij gewoon de namedlink twee keer opnemen.
Aangezien myanimationtitle en myanimationdesc nooit allebei bestaan, komt er in de output dan maar 1 link.
Dus zoiets:
#myanimationtitle
<b>%namedlink(%self,default,myanimationtitle)</b>
#myanimationdesc
<b>%namedlink(%self,default,myanimationdesc)</b>

Daniel73 schreef:2503:page field <title> is printed nowhere! [checking usage of record perk1]
Bij Nijgh heb ik het probleem blijkbaar opgelost door de title in commentaarregels te zetten.
De "title" is hier bedoeld als een omschrijving van de input zelf.
Misschien kan ik beter een "nontitle" maken met een %noval-opdracht. Maar waar stel ik dat in?

Dan krijg je dezelfde melding als nu, namelijk "page field <nontitle> is printed nowhere!".
Het probleem is dat het hele record nooit gebruikt wordt (in de output). Dus welk veld je ook definieert, het wordt niet gebruikt.
Afgezien van enkele "standaard"-velden, zoals #code, #hide en #linkallowedfromoutside.

Daniel73 schreef:De "#" is echt nodig. Anders ben ik beperkt in het geven van, in dit geval, longtitles.
Het is bijvoorbeeld gangbaar om "#" te gebruiken bij werken waarvan meer versies zijn. (Take #1, take #2, take #3, etc.)

Dan moet ik eens serieus gaan nadenken over hoe ik dit ga oplossen.
Ik wil uiteraard wel mijn eigen websites kunnen blijven genereren met dezelfde DveGen...

Daniel73 schreef:Ik ging er vanuit dat "#longtitle" een vrij veld was en ergens gedefinieerd stond in een DEF-bestand, met een %val.
Maar ik kan het nergens vinden in de DEF-bestanden.

#longtitle is inderdaad iets bijzonders. Zie deze pagina:
http://bolderbast.inducks.org/dvegen/treefilenormaal.html

Daniel73 schreef:
Snelbinder schreef:Of in het geval van zzzideleap denk ik dat de "l_lockmanheader" geen titel bevat!

De "##header" bevat evenmin een title. En bij andere l_lockmanheaders heb ik geen foutmelding.
Dus ik snap niet waarom "zzzideleap" dan een foutmelding geeft.

Ik zie nergens een #title in dbzideleap.def (maar bijvoorbeeld wel in dbarticles.def en dbanimation.def).
Heb je een voorbeeld van een ander item die GEEN foutmelding geeft?
Dan kan ik het verschil zoeken.

Daniel73 schreef:
Snelbinder schreef:We kunnen 2 dingen doen:
1. ik pas DveGen aan;
2. jij voegt op diverse plekken spaties toe (een Amerikaanse issuecode heeft altijd dezelfde lengte).

als je het niet heel erg vindt ga ik voor optie 1... :)

Ik vind het niet heel erg.

Daniel73 schreef:In Dvegen wil ik tezijnertijd een lijst definiëren waarin alle items staan die in Inducks ontbreken.
Is dat automatisch mogelijk? Zoals bijvoorbeeld in het logbestand al gebeurt?

Lijkt me wel mogelijk.

Wist je trouwens dat op dit moment de Carl Barks Collection wordt samengesteld, in Kopenhagen?
Daar willen ze kennelijk alles wat Barks op papier heeft gezet in hebben.
We krijgen geregeld "foutmeldingen" dat bepaalde items niet in Inducks staan.
Dus als ze die toevoegen zullen er uiteindelijk veel minder items overblijven die niet in Inducks staan. :)

Daniel73 schreef:De sublist-layout is in output lelijk geworden. Doe ik iets verkeerd?
Blijkbaar gaat het om alleen "</li>".

Ja, het is een "feature" van Dvegen dat er na een haakje-sluiten geen newline komt (dat scheelt een hoop %nobreak in de DEF-files).
Als je dus </li> achter de %link(...)-opdracht zet, eindigt de regel niet meer met een ')' en wordt er dus WEL een newline gegenereerd.

Het heeft dus niks te maken met de HTML zelf. DveGen weet nog steeds niet erg veel van de HTML die het binnenkrijgt.

Daniel73 schreef:Ik heb vroeger(!) geleerd dat "</li>" overbodig is in HTML.

Ik vermoed dat het toch echt nodig is in "proper" HTML.
Net als trouwens een </p> aan het eind van een paragraaf, en het gebruik van <br/> in plaats van <br>.
Maar niet veel mensen doen dat...

Daniel73 schreef:Ga ik aan de slag met DveGen in deze hopeloos grauwe zomer, gaat de zon schijnen...

Dat is inderdaad een probleem.

Daniel73 schreef:een output-fout waarvan DveGen geen melding geeft:
In output-sectie 'Namen' verschijnen hier en daar items dubbel in de automatische lijsten.
Zie (bijvoorbeeld) Willem Nijholt in "lnnm_nn.html#lnnm00nijholt_w". Onder kopje "Gerelateerd werk" ("Muziek anderen") staan daar titels dubbel vermeld.
Geen idee of het komt door het omzetten van input, waar ik mee bezig was en ben. Of dat het komt door een verandering in DveGen. Of beide.

Het lijkt me sterk dat het komt door een verandering in DveGen.
Maar het is ook een behoorlijke klus om uit te zoeken wat hier nou eigenlijk misgaat.
En dat komt weer doordat de hele structuur van de Nijgh-data zo ingewikkeld geworden is...

Misschien wordt "Van Elsschot tot Nijgh" 2 keer genoemd, omdat Nijholt er 2 bijdragen voor geleverd heeft?

De DEF-regel die de dubbele vermelding veroorzaakt is:

%xselection(codestart=lnmzpl00ov, layout=l_pad9a_lnmz,sortfield=code)

Zie ook http://bolderbast.inducks.org/dvegen/phf_perc_xselection.html

Dat ziet er lekker ingewikkeld uit. Ik heb nu even geen tijd meer om het verder uit te zoeken...
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » wo sep 05, 2007 2:05 pm

Ik stuur je een nieuwe dvegen.exe per e-mail: versie 4.7.
Wijzigingen:

- links naar inducks-items die 2 of meer spaties hebben (W WDC 40-00 en zo) gaan nu weer goed.

- in lijstjes komen nu nooit dubbele records voor. Zie (bijvoorbeeld) Willem Nijholt in "lnnm_nn.html#lnnm00nijholt_w".

- probleem van #s in titels van pagina's opgelost. Zie
2503:page field <40;1942> is printed nowhere! [checking usage of record comicsos0009]
(die komt nu niet meer voor in de logfile)
Ik neem hierbij wel aan dat je nooit een dakje (^) in een titel nodig hebt. Of eigenlijk nergens.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Daniel73 » zo sep 09, 2007 1:37 am

Snelbinder schreef:Ik stuur je een nieuwe dvegen.exe per e-mail: versie 4.7.

Dank! Geen 4.6? :-) (Mijn laatste versie was 4.5.)

Per e-mail stuur ik je de bestanden "070909_guidebook.zip" en "070908_off-record_guidebook.zip".

Bij deze de VRAAG of je akkoord gaat met openbaar plaatsen van "070909_guidebook.zip". Er staan ook privé-commentaren van jou in. Ik zie er niets bijzonders in, maar voor de zekerheid wil ik je er wel aan herinneren.

Bedoeling is dat "070909_guidebook.zip" is gefilterd van informatie in verborgen privé-commentaren waaraan ik twijfel of die zomaar openbaar kunnen. Waaronder e-mail adressen die ik via privé-contact heb.
Ik denk (hoop) dat het bestand geschikt is om op internet te plaatsen. In eerste instantie misschien alleen als zip-bestand, om de verpakte input-bestanden voorlopig nog enigszins buiten zoekmachines te houden. Totdat de bestanden zijn opgepoetst. Waar het mij om gaat is dat er nu tenminste een begin is om de input-bestanden als open source aan te bieden. Wie persé wil, kan dan alvast een kijkje nemen in het zip-bestand.

In "070908_off-record_guidebook.zip" staat de meeste informatie die ik weggefilterd heb opgesomd. Dit bestand is in principe dus alleen voor mij en jou.


Mocht je niet akkoord gaan met openbare plaatsing van "070909_guidebook.zip", dan denk ik aan twee mogelijkheden:
- Ik verwijder op jouw aanwijzingen wat je weg wil hebben.
- Jij verwijdert wat je weg wil hebben. Bij voorkeur door die informatie te plaatsen in het "off-record"-bestand, zodat ik kan zien wat verwijderd/veranderd is.
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Snelbinder » ma sep 10, 2007 1:31 pm

Daniel73 schreef:Geen 4.6? :-) (Mijn laatste versie was 4.5.)

Kennelijk heb ik je 4.6 nooit gestuurd. Mijn logging zegt:
"version 4.6 is from 26-Jun-2007 (first attempt to generate SQL files)"
Ik geloof dat ik er na die "eerste poging" achter kwam dat ik meer informatie nodig heb...

Daniel73 schreef:Bij deze de VRAAG of je akkoord gaat met openbaar plaatsen van "070909_guidebook.zip". Er staan ook privé-commentaren van jou in.

Ik heb niet gekeken, maar ik neem aan dat er inderdaad geen staatsgeheimen in staan. Dus het ANTWOORD is: ja.

Daniel73 schreef:In "070908_off-record_guidebook.zip" staat de meeste informatie die ik weggefilterd heb opgesomd. Dit bestand is in principe dus alleen voor mij en jou.

Staan hier bestanden in die door DveGen gelezen moeten worden? Zo niet, dan is deze zip-file dus eigenlijk alleen voor jezelf.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

VorigeVolgende

Keer terug naar Computers en internet

Wie is er online

Gebruikers op dit forum: Geen geregistreerde gebruikers. en 9 gasten

cron