[Ant] Onvolledige documentatie?

[Verwijderd]

Ik heb langdurig gezocht naar goede, complete documentatie over Apache Ant, maar ik kom niet verder dan een summier manualtje van de makers zelfs, en wat voorbeeld build.xml's....

Zie: http://ant.apache.org/manual/

Wat mis ik hier dan aan?
Een lijst met alle speciale attributes van elementen, bijv. van: <javac (...)/>, <mkdir (...)/>, etc. en bijbehorende uitleg; waarom er een 'location'-attribute bij een property is die een directory beschrijft ipv alleen een 'value' en hoe Ant dan kan bepalen of zo'n variabele een directory beschrijft, en ga zo maar door.

Veel dingen die wel enigzins vertrouwd overkomen, maar nergens een volledige technische documentatie over het format van de build.xml....

Wie weet raad, en wie kan er verklaren waarom die Ant-werkgroep zelf zo beknopt is in haar "manual"?

[T-MOB]

Net geleerd dat ANT Another Neat Tool is
Maarrem staat hier iets tussen van je gading: http://wiki.apache.org/ant/

En anders heeft dit boek een veelbelovende titel:
ANT the definitive guide

[Alarmnummer]

http://ant.apache.org/manual/

druk op ant tasks.
druk op core tasks en zie daar..

voorbeeld van javac:
http://ant.apache.org/manual/CoreTasks/javac.html

[Verwijderd]

Wat er niet in staat:

- De default waarde van een attribuut wordt regelmatig genoemd. Zo staat er soms: "defaults to: no". Maar wat zijn de mogelijke waarden? True? Yes? On?
Ik zou zeggen True, maar deze semi-boolean termen worden overal door elkaar gebruikt in Ant, zo blijkt uit de documentatie.
- Hoe zit het met de property-tags? Waarom is er een 'location'-attribute bij een property die een directory beschrijft ipv alleen een 'value', en hoe Ant dan kan bepalen of zo'n variabele een directory beschrijft of niet?
- En wat is de scope van een property tag? Ik zou zeggen een task of andere XML-hierarchie waar de tag in geplaatst is, maar ik heb nu twee keer:

XML:

<property location="classes" name="classes.dir">
             <classpath path=".;${.basedir}\lib\eenLib.jar"/>
</property>

In mijn tasks staan, te weten bij init en compile
- Hoe verhoudt dat classpath-element binnen de property die classes.dir beschrijft hierboven zich tot haar 'parent' (die property in zijn geheel)?

Ik roep nu namelijk telkens de variabele {$classpath} aan, en dit lijkt te werken. Maar waarom is dat geen aparte property? Die hele opzet van die property hierboven verwart me eigenlijk, en over dit in zijn algemeenheid kan ik niks bruikbaars terugvinden in de manual.

[ Voor 49% gewijzigd door Verwijderd op 12-05-2004 22:28 ]

[Alarmnummer]

Verwijderd schreef op 12 mei 2004 @ 22:20:
Wat er niet in staat:

- De default waarde van een attribuut wordt regelmatig genoemd. Zo staat er soms: "defaults to: no". Maar wat zijn de mogelijke waarden? True? Yes? On?
Ik zou zeggen True, maar deze semi-boolean termen worden overal door elkaar gebruikt in Ant, zo blijkt uit de documentatie.

Ik zou zeggen: probeer ze allemaal. Kijk of ant begint te zeuren of on, true, yes allemaal voor hetzelfde staan.

- Hoe zit het met de property-tags? Waarom is er een 'location'-attribute bij een property die een directory beschrijft ipv alleen een 'value', en hoe Ant dan kan bepalen of zo'n variabele een directory beschrijft of niet?

Copy paste is bij ANT je grote vriend. Ik vind ANT een strakke tool omdat ik me er nu goed mee kan reden en alles mee kan doen wat ik wil. Maar ik ga me niet verdiepen in al dit soort trivialiteiten. Ik kijk onder aan of ik een voorbeeld zie staan, copy paste.. klaar.

- En wat is de scope van een property tag? Ik zou zeggen een task of andere XML-hierarchie waar de tag in geplaatst is, maar ik heb nu twee keer:

XML:

<property location="classes" name="classes.dir">
             <classpath path=".;${.basedir}\lib\eenLib.jar"/>
</property>

In mijn tasks staan, te weten bij init en compile

XML:

<project name="Prolaw" default="dist" basedir=".">

    <!-- set global properties for this build -->
    <property name="src"                    value="src"/>
    <property name="src.core"               value="${src}/core"/>
    <property name="src.test"               value="${src}/core-test"/>
    <property name="src.parser"             value="${src}/parser"/>
    <property name="src.system"             value="${src}/system"/>
    <property name="src.parser-test"        value="${src}/parser-test"/>
    <property name="src.run-test"           value="${src}/run-test"/>
    
    <property name="jsr14.home"             value="C:\adding_generics-2_2-ea"/>
    <property name="build.compiler"         value="com.cortexeb.Jsr14CompilerAdapter"/>
        
    <property name="lib"                    value="lib"/>
    <property name="build"                  value="build"/>
    <property name="dist"                   value="${build}/dist"/>
    <property name="docs"                   value="docs"/>
    
    <property name="classes"                value="${build}/classes"/>
    <property name="classes.core"           value="${classes}/core"/>
    <property name="classes.parser"         value="${classes}/parser"/>
    <property name="classes.junit"          value="${classes}/test"/>
    <property name="classes.system"         value="${classes}/system"/>
    
    <property name="dist"                   value="${build}/lib"/>
    <property name="junit-reports"          value="junit-reports"/>
     
    
    <taskdef name="sablecc" classname="org.sablecc.ant.taskdef.Sablecc"/>
      
     <patternset id="compile.libs"> 
        <include name="lib/*.jar"/>
     </patternset>
    
    <target name="clean"
            description="verwijder alle niet noodzakelijke bestanden">
            
        <delete dir="${build}"/>
    </target>

    
    <target name="init" description="">
        <tstamp/>
    </target>

    <target name="sablecc"
            depends="init"
            description="Generated the parser">
        
        
        <uptodate   property="build-parser"
                    targetfile="${src.parser}/org/jph/prolaw/parser/sablecc/parser/Parser.java"
                    srcfile="${src.parser}/prolog.sablecc"/>

        <antcall target="sablecc.exec"/>

        <copy   file="${src.parser}/org/jph/prolaw/parser/sablecc/lexer/lexer.dat"
                todir="${classes.parser}/org/jph/prolaw/parser/sablecc/lexer/"/>

        <copy   file="${src.parser}/org/jph/prolaw/parser/sablecc/parser/parser.dat"
                todir="${classes.parser}/org/jph/prolaw/parser/sablecc/parser"/>
    </target>
    
    
    <target name="sablecc.exec"
            depends="init"
            unless="build-parser">
        
        <delete dir="${src.parser}/org/jph/prolaw/parser/sablecc/parser"/>
        <delete dir="${src.parser}/org/jph/prolaw/parser/sablecc/lexer"/>
        <delete dir="${src.parser}/org/jph/prolaw/parser/sablecc/node"/>
        <delete dir="${src.parser}/org/jph/prolaw/parser/sablecc/analysis"/>
        
        <sablecc    src="${src.parser}"
                    outputdirectory="${src.parser}">
            <include name="prolog.sablecc"/>
        </sablecc>
    </target>
    
    
    <target name="compile.core"
            depends="init"
            description="Compiles the Core">
                    
        <mkdir dir="${classes.core}"/>
        
        <javac  debug="on"
                srcdir="${src.core}"
                destdir="${classes.core}"
                source="1.5">
                
            <classpath>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>                          
            </classpath>
        </javac>
    </target>
        
    <target name="compile.parser"
            depends="compile.core,sablecc"
            description="Compiles the Parser">
        
        <mkdir dir="${classes.parser}"/>
    
        <javac  debug="on"
                nowarn="true"
                srcdir="${src.parser}"
                destdir="${classes.parser}"
                source="1.5">
                
            <classpath>
                <pathelement path="${classes.core}"/>
                <fileset dir="${lib}">
                    <include name="**/*.jar"/>
                </fileset>
            </classpath>
        </javac>
    </target>
    
    <target name="compile.system"
            depends="compile.core,compile.parser"
            description="Compiles the Gui">
        
        <mkdir dir="${classes.system}"/>
    
        <javac  debug="on"
                srcdir="${src.system}"
                destdir="${classes.system}"
                source="1.5">
                
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.parser}"/>             
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
        </javac>
    </target>
    
    
    <target name="compile.all"
            depends="compile.core,compile.parser,compile.system"
            description="Compiles everything"/>
        
    
    <target name="test.core"
            depends="clean,compile.core"
            description="Tests the Core">
        
        <mkdir dir="${classes.junit}"/>
            
        <javac  srcdir="${src.test}"
                debug="on"
                destdir="${classes.junit}"
                source="1.5">
                
            <classpath>
                <pathelement path="${classes.core}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
        </javac>

        <mkdir dir="${junit-reports}"/>

        <junit haltonerror="yes" fork="on" printsummary="on">
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.junit}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
            <formatter type="plain"/>
            <jvmarg value="-ea"/>
            <jvmarg value="-Xbootclasspath/p:${jsr14.home}/gjc-rt.jar"/>
                                
            <batchtest todir="${junit-reports}">
                <fileset dir="${src.test}">
                    <include name="**/*TestSuite.java"/>
                </fileset>
            </batchtest>
            
        </junit>
    </target>
    
    <target name="test.parser"
            depends="clean,compile.parser"
            description="Tests the Parser">
        
        <mkdir dir="${classes.junit}"/>
            
        <javac  srcdir="${src.parser-test}"
                debug="on"
                destdir="${classes.junit}"
                source="1.5">
                
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.parser}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
        </javac>

        <mkdir dir="${junit-reports}"/>

        <junit haltonerror="yes" fork="on" printsummary="on">
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.parser}"/>
                <pathelement path="${classes.junit}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
            
            <formatter type="plain"/>
            <jvmarg value="-ea"/>
            <jvmarg value="-Xbootclasspath/p:${jsr14.home}/gjc-rt.jar"/>
                                
            <batchtest todir="${junit-reports}">
                <fileset dir="${src.parser-test}">
                    <include name="**/*TestSuite.java"/>
                </fileset>
            </batchtest>
            
        </junit>
    </target>
    
    <target name="test.run"
            depends="clean,compile.core,compile.parser"
            description="Tests sourcefiles against answerfiles">
        
        <mkdir dir="${classes.junit}"/>
            
        <javac  srcdir="${src.run-test}"
                debug="on"
                destdir="${classes.junit}"
                source="1.5">
                
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.parser}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
        </javac>

        <mkdir dir="${junit-reports}"/>

        <junit haltonerror="yes" fork="on" printsummary="on">
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.parser}"/>
                <pathelement path="${classes.junit}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
            
            <formatter type="plain"/>
            <jvmarg value="-ea"/>
            <jvmarg value="-Xbootclasspath/p:${jsr14.home}/gjc-rt.jar"/>
                                
            <batchtest todir="${junit-reports}">
                <fileset dir="${src.run-test}">
                    <include name="**/*TestSuite.java"/>
                </fileset>
            </batchtest>            
        </junit>
    </target>
    
    <target name="test.all"
            depends="test.core,test.parser,test.run"
            description="Runs all the Tests"/>
            
    
    <target name="dist" 
            depends="compile.all" 
            description="Compiles the whole project, and builds all the jars.">
                
        <mkdir dir="${dist}"/>
        
        <jar    jarfile="${dist}/core.jar"  
                basedir="${classes.core}"/> 
                
        <jar    jarfile="${dist}/parser.jar"    
                basedir="${classes.parser}"/>   
                        
        <jar    jarfile="${dist}/gui.jar"       
                basedir="${classes.system}"/>   
                
        <copy todir="${dist}">
            <fileset dir="lib"/>
        </copy>
        
    </target>       
                        
    <target name="run"
            depends="compile.all"
            description="Runs an example">
        
        <java fork="true" classname="org.jph.prolaw.Main" maxmemory="512M">
            <classpath>
                <pathelement path="${classes.core}"/>
                <pathelement path="${classes.parser}"/>
                <pathelement path="${classes.system}"/>
                <fileset dir=".">
                    <patternset refid="compile.libs"/>
                </fileset>  
            </classpath>
            <arg value="examples/assert.pl"/>
            <jvmarg value="-ea"/>
            <jvmarg value="-Xbootclasspath/p:${jsr14.home}/gjc-rt.jar"/>
        </java>
    </target>
        

</project>

Misschien doe je hier wat ideeen mee op.

[ Voor 51% gewijzigd door Alarmnummer op 12-05-2004 22:38 ]

[Verwijderd]

Idd, dat is over het algemeen ook mijn tactiek.
Ik kijk gewoon naar voorbeelden bij dat soort zaken, en zorg dat ik het redelijk beheers door er een beetje logica in te leren zien.

Echter als ik iets wil controleren - in plaats van enkel beheersen - zal ik het volledig moeten begrijpen, hoe triviaal het ook mag ogen. Ik verwachtte een antwoord van de meesten in de geest van: "Kaart die punten dan aan, en help zelf mee aan het schrijven van die manual.".

Als iemand een softwareproduct releast vind ik echter dat men toch minstens een fatsoenlijke manual ter beschikking moet stellen. Anders heeft niemand wat aan je product, en dat zou zonde zijn bij zo'n krachtige tool als Ant.

Het probleem is dat die manual te vaag, ongestructureerd en onvolledig is. Zeg nou zelf: vindt jij dat je goed bezig bent als jij bij een attribute gewoon maar ff alle mogelijke waarden uitprobeert omdat het nergens staat beschreven?
Dat is op de korte termijn misschien afdoende, maar ik prefereer een lange-termijnoplossing.

Daarom vind ik het echt triest dat men zo weinig aandacht besteed aan het goed documenteren van dit soort softwareproducten (en dat terwijl de Ant API wel uitgebreid aan bod komt...).

Ik zal je build.xml (van een Prolog-tool, zowaar ) doorsnuffelen, maar ik zie op het 1e gezicht niets nieuws. Oude wijn, in nieuwe (iets grotere ) zakken.

Enfin, bedankt voor je hulp!
Waar heb ik dat aan te danken...
Ik had de verwachting dat dit weer één van mijn topics werd die een zachte dood sterven.. .
Maar iig, thx for your help!

[Alarmnummer]

Verwijderd schreef op 12 mei 2004 @ 23:43:
Idd, dat is over het algemeen ook mijn tactiek.
Ik kijk gewoon naar voorbeelden bij dat soort zaken, en zorg dat ik het redelijk beheers door er een beetje logica in te leren zien.

Het probleem is dat die manual te vaag, ongestructureerd en onvolledig is. Zeg nou zelf: vindt jij dat je goed bezig bent als jij bij een attribute gewoon maar ff alle mogelijke waarden uitprobeert omdat het nergens staat beschreven?
Dat is op de korte termijn misschien afdoende, maar ik prefereer een lange-termijnoplossing.

lange termijn oplossing voor ant: dumpen en kijken of ze iets beters kunnen maken zonder die nare xml syntax.

Ik zal je build.xml (van een Prolog-tool, zowaar ) doorsnuffelen

Ik ben bezig met een prolog compiler op basis van WAM (Warrens Abstract Machine). Ik wil deze uitbreiden met data driven regels (ipv alleen goal driven) zodat ik ook kan reageren op events van buiten af. Hierdoor valt Prolog ook in te zetten als advies systeem. Verder wil ik het systeem zo maken dat er een centrale server komt waar alle prolog meta-interpreters/meta-programma`s staan en waar clients instanties hiervan kunnen ophalen. Hierdoor kun je bv businesslogic uit applicaties trekken, applicaties voorzien van expertsysteem en adviessysteem functionaliteit. Verder wil ik ook meteen een aantal kant en klare componenten klaar hebben voor oa webpagina`s en voor Swing, zodat het toevoegen van rulebased systemen niets anders gaat worden dan wat componenten aan de praat te slingeren, en de daadwerkelijke prolog programma`s te schrijven. Ik hoop in de nabije toekomst dit commercieel interessant te kunnen maken. Er zijn voor zover ik weet geen bedrijven in nederland die dit soort producten leveren, en verder moet er ook een stuk maatwerk geleverd worden (het prolog verhaal). Dit kan ik doen, maar eventueel kunnen ook kunstmatige intelligentie mensen van het bedrijf zelf hiermee aan de slag, want tenslotte.. het is allemaal prolog based Boeken genoeg dus.

maar ik zie op het 1e gezicht niets nieuws. Oude wijn, in nieuwe (iets grotere ) zakken.

Er zitten wel een paar leuke dingen in. De parser wordt alleen gecompileerd als er iets aan de grammatica is veranderd. En alle TestSuites worden automatisch toegevoegd (dus niet meer met de hand). Er wordt namelijk gescanned op bestanden die eindigen op TestSuite.

Enfin, bedankt voor je hulp!

np. Ik heb in het begin ook liggen worstelen met ANT.

[ Voor 36% gewijzigd door Alarmnummer op 13-05-2004 08:48 ]

[ari3]

Ant is ingehaald door Maven. Maven is goed gedocumenteerd en maakt voor de meeste applicaties het gebruik van Ant-tags overbodig.

[Verwijderd]

Alarmnummer schreef op 13 mei 2004 @ 08:39:
[...]

lange termijn oplossing voor ant: dumpen en kijken of ze iets beters kunnen maken zonder die nare xml syntax.

Niks mis mee toch? XML is niet perfect, maar het voldoet prima voor dit soort doeleinden en de syntax is redelijk simpel. Alleen niet hoe Ant die xml-file interpreteerd.

[...]

Ik ben bezig met een prolog compiler op basis van WAM (Warrens Abstract Machine). Ik wil deze uitbreiden met data driven regels (ipv alleen goal driven) zodat ik ook kan reageren op events van buiten af. Hierdoor valt Prolog ook in te zetten als advies systeem. Verder wil ik het systeem zo maken dat er een centrale server komt waar alle prolog meta-interpreters/meta-programma`s staan en waar clients instanties hiervan kunnen ophalen. Hierdoor kun je bv businesslogic uit applicaties trekken, applicaties voorzien van expertsysteem en adviessysteem functionaliteit. Verder wil ik ook meteen een aantal kant en klare componenten klaar hebben voor oa webpagina`s en voor Swing, zodat het toevoegen van rulebased systemen niets anders gaat worden dan wat componenten aan de praat te slingeren, en de daadwerkelijke prolog programma`s te schrijven. Ik hoop in de nabije toekomst dit commercieel interessant te kunnen maken. Er zijn voor zover ik weet geen bedrijven in nederland die dit soort producten leveren, en verder moet er ook een stuk maatwerk geleverd worden (het prolog verhaal). Dit kan ik doen, maar eventueel kunnen ook kunstmatige intelligentie mensen van het bedrijf zelf hiermee aan de slag, want tenslotte.. het is allemaal prolog based Boeken genoeg dus.

Maar het item bij functionele talen is juist dat men goal-driven werkt waaruit de benodigde dataoperaties logsich voortvloeien...
Dat events van buitenaf dan niet werken, omdat ze dus niet in het logische systeem passen, betekent dat er geen (adequate) interface naar de buitenwereld is, of dat de buitenwereld eigenlijk ook binnen het totale logische systeem hoort. Dat laatste is hoe ik het eigenlijk bekijk. Maar goed, ik ben niet bekend met Prolog, die beperking zit er dus helaas in zo lijkt het. Maar jij maakt natuurlijk weer je eigen Prolog-compilers...
Het doel dat je er mee voor ogen hebt is idd wél interessant (en daarnaast een gat in de markt ), ik wil ook een systeem ontwikkelen dat strategieen voor generieke situaties kan aanmaken en desgewenst processt (afzetten verschillende strategieen tegen elkaar). Maar zit nu nog op de HIO () dus ik heb nog geen tijd om me daar serieus in te verdiepen.
Helaas is het bedrijfsleven niet altijd in staat om herbruikbare systematieken voldoende te waarderen, want ze kijken alleen naar de vraag of ze kunnen doen wat ze willen, niet ofdat het een mooi systeem is dat herbruikbaar is dmv inzet van eigen KI-medewerkers, en zo bruikbaar voor werkelijk alles zonder dure specialistische software.
Hoe dan ook, veel succes. Interessante materie doch ietwat () offtopic.

[...]

Er zitten wel een paar leuke dingen in. De parser wordt alleen gecompileerd als er iets aan de grammatica is veranderd. En alle TestSuites worden automatisch toegevoegd (dus niet meer met de hand). Er wordt namelijk gescanned op bestanden die eindigen op TestSuite

Idd, maar de basis is hetzelfde. Je zou eens moeten weten wat een uber build.xml ik nu in elkaar aan het sleutelen ben...

[...]

np. Ik heb in het begin ook liggen worstelen met ANT.

Dat geloof ik best. Ik heb zelf al het een en ander bedacht. Die classpath-tag is zo inconsistent met de (andere) properties, omdat dit gewoon runtime aangepast kan worden (variabelen wellicht ook). Het is dus bedoeld als een property van Ant, niet van jezelf - ten behoeve van de build.xml. Niet erg consistent dus, maar ik heb van het classpath weer lekker een normale property gemaakt, en nu kan ik die value op dezelfde wijze bereiken (${classpath}).
Dat verklaart ook de ogenschijnlijke redundantie in de build.xml, door bij meerdere tasks dezelfde classpath constructie te vermelden, terwijl je zou zeggen dat die variabele toch al eerder zou moeten zijn toegewezen...
Zo kun je gewoon afhankelijk van de gekozen task het classpath setten, whatever might be the use...
Dat path kan je idd dmv pathelement-subelementen construeren, maar ook gewoon via een attribute van het element zelf instellen. Weer erg vreemd dat men het niet uniformer aanpakt, maar ja gemak dient de mens...
Het is een beetje als non-strict HTML... andere data wordt hetzelfde geinterpreteerd...

Maar als iemand meer weet hoor ik het graag.

[ Voor 4% gewijzigd door Verwijderd op 13-05-2004 14:57 ]

[Verwijderd]

ari3 schreef op 13 mei 2004 @ 14:38:
Ant is ingehaald door Maven. Maven is goed gedocumenteerd en maakt voor de meeste applicaties het gebruik van Ant-tags overbodig.

Dat is meer geent op projectbeheer, dat is in mijn geval niet nodig.

[Alarmnummer]

ari3 schreef op 13 mei 2004 @ 14:38:
Ant is ingehaald door Maven. Maven is goed gedocumenteerd en maakt voor de meeste applicaties het gebruik van Ant-tags overbodig.

Mijn grootste probleem aan maven is dat het niet 'de' standaard is.

[ari3]

Verwijderd schreef op 13 mei 2004 @ 14:53:
[...]

Dat is meer geent op projectbeheer, dat is in mijn geval niet nodig.

Ben ik niet met je eens. Maven geeft je een structuur om je project in te hangen. Als je jouw project in deze structuur plaatst kun je gewoon jars, wars, ears en documentatie genereren zonder Ant scripts te schrijven.

[Alarmnummer]

Verwijderd schreef op 13 mei 2004 @ 14:51:
[...]
Maar het item bij functionele talen is juist dat men goal-driven werkt waaruit de benodigde dataoperaties logsich voortvloeien...

Functionele talen zijn gewoon datadriven hoor. Functionele talen zijn in principe procedureel, dwz: jij zit in de drivers seat. Bij declaratieve talen zeg je wat je wilt, maar niet hoe. In de praktijk komt hier niet zo heel veel van terecht omdat je sowieso zit met allerlei performance problemen en sommige dingen gewoon procedureel opgelost moeten worden (bv io).

Dat events van buitenaf dan niet werken, omdat ze dus niet in het logische systeem passen, betekent dat er geen (adequate) interface naar de buitenwereld is, of dat de buitenwereld eigenlijk ook binnen het totale logische systeem hoort. Dat laatste is hoe ik het eigenlijk bekijk. Maar goed, ik ben niet bekend met Prolog, die beperking zit er dus helaas in zo lijkt het. Maar jij maakt natuurlijk weer je eigen Prolog-compilers...

Ze passen zeker wel in logische systemen. Prolog is van huis uit goaldriven, hij probeert bepaalde goals te bewijzen en doet dit door rules op te zoeken die voldoen, en eventueel gaat hij hier een hele lange tijd mee door.

code:

if meerderjarig en moordgepleegd then schuldig

if leeftijd > 17 then meerderjarig.

Als ik wil weten of iemand schuldig is, zal ik moeten bepalen of jij meerderjarig bent en moordgepleegd. Om te bepalen of jij meerderjarig bent moet ik jouw leeftijd bepalen. Je probeert dus het goal (schuldig) te bewijzen en daarvoor ga je dus terug zoeken om dit voor elkaar te krijgen.

Bij een datadriven systeem ben je niet geinteresseerd in de goal. De goal is een bijproduct:

code:

if broodrooster_in_kar then message "weet u dat er korting is op de broodroosters?"

Jij bent niet geinteresseerd in de message, die message is een bij product. Er komt een event binnen (broodrooster_in_kar) en daarop neem jij weer actie.

Goaldriven en datadriven zijn elkaar tegenovergestelde. En datadriven systemen kunnen erg handig zijn voor advies systemen.

Verder is er een groot probleem bij goaldriven systemen als er een groot aantal rules in het systeem komen. Iedere keer moet voor een groot gedeelte onnodige hoeveelheden rules worden gechecked en dit moet dus geoptimaliseerd worden (dat kan mbv het Rete algoritme).

Maar zit nu nog op de HIO () dus ik heb nog geen tijd om me daar serieus in te verdiepen.

Ik doe ook 'maar' de HIO hoor (alhoewel ik wel het een en ander aan zelfstudie heb gedaan in de loop van de jaren )

Helaas is het bedrijfsleven niet altijd in staat om herbruikbare systematieken voldoende te waarderen, want ze kijken alleen naar de vraag of ze kunnen doen wat ze willen, niet ofdat het een mooi systeem is dat herbruikbaar is dmv inzet van eigen KI-medewerkers, en zo bruikbaar voor werkelijk alles zonder dure specialistische software.

Het ligt eraan hoe je het gaat verkopen. Het bedrijfleven hoeft in veel gevallen geen kont te weten van alle technische poeha, dat is voor de developers. Jij moet hun duidelijk maken wat voor economisch voordeel zij door gebruikmaking van dat product kunnen behalen. In mijn geval is dat beter op klanten inspelen (adviezen geven), snelle aanpassingen maken zonder hiervoor developers aan te spreken, en kennis van experts beschikbaar stellen voor een breder publiek, bv een hypotheekbepaler, huursubsidie bepaler etc. Verder hebben redelijk veel bedrijven ook ai`ers in dienst als programmeur. Zij zijn zelf in staat om de prolog content op te bouwen (eventueel wil ik wel wat advies geven aangezien expertsystemen ed niet een onderdeel is van hun studie waar erg veel aandacht aan wordt besteed).

[ Voor 10% gewijzigd door Alarmnummer op 13-05-2004 15:53 ]

[Verwijderd]

Om on-topic te blijven, zal ik slechts kort ingaan op je...

Functioneel <> Imperatief heb ik altijd geleerd. Jij hebt het over declarativiteit als tegenhanger, maar ik heb het dus over Functioneel als tegenhanger van Imperatief, en zie goal-driven als functioneel, en data-driven als imperatief. Dat klopt vast niet altijd, maar als je het zo ziet is Prolog niet data-driven.

[Verwijderd]

Aaargh.
Waarom werkt dit niet:

code:

<property name="cl" refid="test"/>
        <fileset dir="C:\" id="test">
            <type dir="dir"/>
        </fileset>
 <echo message="Mappen: ${cl}"/>

Als ik het type "file" specificeer werkt het daarentegen wel...

[ Voor 56% gewijzigd door Verwijderd op 16-05-2004 23:52 ]

[Verwijderd]

code:

Adding reference: non.test
fileset: Setup scanner in dir C:\Windows with patternSet{ includes: [] excludes: [] }
Setting project property: cl -> 
Overriding previous definition of reference to non.test
Adding reference: non.test
Mappen:

C:\ geeft een fout in C:\System Volume Information\, dat is dan ook een systeemmap.
Maar hij scant dus weldegelijk...

Alleen vaag dat hij aangeeft: includes[]

[Verwijderd]

En wat werkt er weer wél?

code:

<property name="cl" refid="non.test"/>
        <path id="non.test">
         <dirset dir="C:\Windows">
            <!--<type type="dir"/>-->
            <include name="*"/>
          </dirset>
        </path>
<echo message="Mappen: ${cl}"/>

Waarom voeg je dit soort functionaliteit dan toe, vraag je je op zo'n moment af. Ook omdat ze het eerste voorbeeld zelf al gaven (in iets andere vorm uiteraard).

Bovendien werkt het 1e voorbeeld wel als je type="file" definieert.