remove .prf, .ext and .axs dependency

[PieterTack]

@tschoonj Tom, kan jij even kijken naar die AppVeyor build fail? Er staat iets omtrent een pointer seed die niet werkt in windows ofzo (is een warning), en het failen van de build zelf gebeurt omdat hij bepaalde functies niet lijkt te herkennen, al zouden die voor zover ik begrijp deel moeten zijn van de gsl library (vb gsl_matrix_free). De respectievelijke code haalde ik van https://rosettacode.org/wiki/Polynomial_regression#C

[tschoonj]

Hey Pieter,

De failures hebben te maken met gsl dat nu een harde dependency is geworden. De oplossing is configure.ac aan te passen zodat gsl altijd moet gevonden worden, en niet enkel als easyRNG niet aanwezig is op het systeem. Wil je dit zelf eens proberen of moet ik het doen?

Groetjes,

Tom

[PieterTack]

Kzal eens proberen :)

[tschoonj]

Vergeet niet autoreconf uit te voeren in de map waar configure.ac is na elke wijziging aan dat bestand. Veel succes 👍

[tschoonj]

ok, ik zie wat het probleem is... zal even proberen te fixen van hier.

[tschoonj]

Ik heb een commit op je branch bijgeduwd met een fix voor de buildbots. Om deze commit ook bij jou te krijgen zou een git pull voldoende moeten zijn. Laat weten als er een foutmelding is.

[PieterTack]

letterlijk "git pull" in mijn terminal? Dat doet niet echt iets :(

Misschien moet ik toch eerst alles mergen en dan pullen? Of moet ik nog een of andere optie meegeven met de git pull? (vb om te pushen moet ik git push origin pcshapeinp meegeven)

[tschoonj]

Je branch moet eerst geassocieerd worden met zijn upstream (Github) tegenhanger:

git branch --set-upstream-to=origin/pcshapeinp

Dan:

git pull

Je kan dit in de toekomst vermijden door wanneer je een nieuwe branch voor de eerste keer naar Github pusht door de optie -u mee te geven:

git push -u origin my-new-branch

[PieterTack]

Nog steeds niet functioneel helaas :(

Eerst gaf hij fout bij easyRNG dat er een syntax error was met unexpected token 'else'. Heb dan configure.ac nog minimaal beetje aangepast (else voorwaarde geopend en gesloten op zelfde lijn ipv op volgende lijn) waardoor hij niet meer die syntax error ziet, maar zegt dat Package requirements (easyRNG) not met zijn, en daar compilatie onderbreekt.

Nog ideeën?

[PieterTack]

Homoustly, kdenk da het gewoon makkelijker is om de EasyRNG dependency weg te halen, daar we nu toch sowieso gsl nodig hebben? Het doet te lastig in die configure.ac naar mijn mening (en ik snap gewoon niet waarom een lege else clausule zo problematisch is :P )

[tschoonj]

ok, gefixed denk ik met een vuile hack...

[PieterTack]

Yup, seems fixed :) Was ook al aant denken om zoiets uit te steken. Nu eens uitzoeken waar mijn programma de mist in gaat dat het niets meer berekend :P

[tschoonj]

Unit tests! 😄

[PieterTack]

Yup, de unit tests komen er nu aan :) Was heel eenvoudige fix ivm input file aanpassing. Nu werkt alles in principe weer als van ouds :)

[tschoonj]

Btw, aangezien ge toch in C99 mode compileert kan je de loop variabele declareren binnen de loop zelf:

for (int i = 0 ; i < n ; i++) {
  ...
}

Niet dat je nu alle for loops moet gaan aanpassen, maar misschien geen slecht idee om vanaf nu daar mee te werken...

[PieterTack]

Good hint. Zal eraan proberen denken.

Voor de unit tests: dat waren gewoon kleine programmaatjes die deeltjes van de code controleren, en waar dan de uitkomst ervan wordt gecontroleerd (in bvb if clausules) en adhv de respons de functie exiten (met bepaald getal, vb exit(3) ofzo) of niet he? Ik vermoed dat het dan best is om de huidige code nog zo veel mogelijk in aparte functies op te splitsen, en dan de unit test die functies te laten oproepen en uitkomst controleren?

[tschoonj]

Yep dat klopt.

Best is daarvoor een aparte directory tests te maken. Een voorbeeld daarvan kan je vinden in xmi-msim. Voor je daar kan mee beginnen moet je wel de functies verplaatsen naar een shared library, want je tests kunnen niet linken tegen een file die al een main bevat. Je zal dan ook een header moeten maken met de functies die je exporteert, en die zal moet geimporteerd worden door de tests met een #include statement. Die plaats je best in een folder genaamd include, gelijkaardig aan hoe xmi-msim of xraylib dat doet. Vergeet niet dat elke nieuwe folder een nieuwe Makefile.am nodig heeft die ook moet worden toegevoegd in configure.ac evenals de toplevel Makefile.am.

Dit is redelijk wat werk: laat maar weten als je hulp nodig hebt.

[PieterTack]

Zal beginnen met polycap.c in logischere functies op te splitsen, en dan vertrek ik van daaruit met header files etc :) Ik laat het idd niet na je hulp te vragen wanneer ik weer eens vast zit ;)

[tschoonj]

Makkelijkst is eigenlijk gewoon de main in polycap.c te verplaatsen naar een eigen nieuwe file main.c. Vervolgens schrijf je de header, die dan ook moet geimporteerd worden in main.c. Pas daarna src/Makefile.am zodat je een shared library libpolycap.la hebt evenals een executable polycap, die dan moet linken tegen libpolycap.la.

[tschoonj]

Als je trouwens een goede introductie wil lezen over autotools, kijk dan eens naar https://www.lrde.epita.fr/~adl/dl/autotools.pdf

[PieterTack]

Goh, kheb die str_current_size nu op 128 gezet van int begin, dan zou de routine wel goed moet werken (heb ze van stackoverflow gehaald uiteindelijk, had enkel die waarde vergeten aanpassen omdat ik eerst iets anders aan het foefelen was) Grootste verschil met jouw functionaliteit is dus dat ik in blokken memory van 128 bits spring, en jij per bit als ik het zo goed zie. Je mag zelf kiezen of je kan leven met de manier waarop ik het deed, of je het toch veel beter vindt je eigen methode te volgen (mss zijn er paar zaken die mijn methode over het hoofd ziet en de jouwe niet).

[tschoonj]

De implementatie die ik voor Windows gebruik bij XMI-MSIM start met een blok van 120. Wanneer deze vol is, wordt er verdubbeld plus 1.

Ik heb geen idee wat er op Linux en macOS gedaan wordt bij die functie maar ik veronderstel iets gelijkaardig. In ieder geval wordt er best niet te veel gerealloced want dat is een relatieve trage operatie.

[PieterTack]

ok, header file en source code aangepast zodat ze geen dubbeltjes meer hebben, die guard ingevoegd en C++ functionaliteit ingebracht (althans in header file. Doe ik ook best in polycap.c ook zeker?)

[tschoonj]

Al beter maar ik denk dat al die includes in de header ook mogen verhuizen naar polycap.c.

Voeg ook enkel functies toe aan de publieke header polycap.h waarvan je denkt dat ze nuttig zijn voor de third-party gebruiker. Anders verhuis je ze best naar een private header, die je nog altijd kan gebruiken in je unit tests.

Die C++ name mangling truuk is enkel nodig in de header, aangezien polycap.c zelf gecompileerd wordt met een gewone C compiler.

[tschoonj]

Laat maar weten als ik iets kan doen trouwens: deze namiddag kan ik hier wel een uur of twee aan werken...

[PieterTack]

Van includes in header: Sommige includes zijn wel echt nodig om die functies te laten lopen, zoals de complex.h voor complexe berekening bij Fresnel vergelijking en xraylib in mumc om attenuatie coefficienten te bepalen tc. Andere zijn idd meer algemene includes, maar op zich ook nodig in die zin dat bijvoorbeeld sqrt() enzo wel moet gekend zijn.

Als trouwens een functie in mijn public library een andere functie gebruikt die enkel in polycap.c staat (het geval bij de polycap_shape, die de fitting doet in geval van parabole shape), moet ik dan die gebruikte functie ook in de publieke header zetten? Of lost dat zichzelf wel op? Uiteindelijk staat alle code zelf nog in polycap.c, dus ik vermoed dat als iemand mijn header zou gebruiken ze nog steeds moeten linken naar polycap.c ook? En mss is dat dan ook direct de reden waarom die includes toch weg mogen uit de header en enkel in polycap.c staan?

Van wat je kan doen als je zin hebt eraan te werken:

• Mijn grootste prioriteit is natuurlijk de huidige code incorporeren in xmimsim, daar de code nu op zich wel werkt. De laatste week ben ik het vooral aan het opkuisen naar mijn mening, maar de uitkomst blijft dezelfde (gelukkig ;) ). Dus mss een duidelijk overzicht van hoe het programma er moet gaan uitzien om in xmimsim te kunnen passen zou handig zijn, zodat ik het dan kan omvormen naar die concrete vorm (e.g. de gegevens die xmimsim meegeeft en wil ontvangen).
• de test functies kunnen nog gedaan worden, maar mss ben ik daar meer geschikt voor om beter in te schatten wat de concrete uitkomsten zouden moeten zijn etc?
• de do loops in main kunnen mss nog naar for omgezet worden, al is dat mss meer dan een paar uur werk ;)

[tschoonj]

Van includes in header: Sommige includes zijn wel echt nodig om die functies te laten lopen, zoals de complex.h voor complexe berekening bij Fresnel vergelijking en xraylib in mumc om attenuatie coefficienten te bepalen tc. Andere zijn idd meer algemene includes, maar op zich ook nodig in die zin dat bijvoorbeeld sqrt() enzo wel moet gekend zijn.

Die headers zijn nodig in de implementatie (polycap.c) want daar worden ze ook gebruikt, niet in de publieke header. Probeer eens al die includes te verhuizen naar polycap.c en je zal zien dat alles nog perfect compileert. De third party gebruiker van polycap hoeft niet te weten welke headers nodig waren in de polycap.c implementatie. Als hij een van die headers nodig heeft omdat hij er een functie zal uit gebruiken in zijn code zelf dan pas zal hij er een include voor moeten toevoegen. Publieke headers moeten enkel de absolute minimum bevatten: vergeet niet dat elke #include de inhoud van die header zal plakken in het bestand wat de compilatie alleen maar gaat vertragen. Nutteloze includes zijn dus te vermijden. Je zal dit beter inzien wanneer je je unit tests schrijft.

Als trouwens een functie in mijn public library een andere functie gebruikt die enkel in polycap.c staat (het geval bij de polycap_shape, die de fitting doet in geval van parabole shape), moet ik dan die gebruikte functie ook in de publieke header zetten? Of lost dat zichzelf wel op? Uiteindelijk staat alle code zelf nog in polycap.c, dus ik vermoed dat als iemand mijn header zou gebruiken ze nog steeds moeten linken naar polycap.c ook? En mss is dat dan ook direct de reden waarom die includes toch weg mogen uit de header en enkel in polycap.c staan?

Nee dat hoeft niet, je implementatie mag zoveel andere functies bevatten als jij wil. Als het niet nodig is ze in de publieke header te zetten, dan is het best dat niet te doen. Je kan ze wel altijd in een private header zetten, die dan kan gebruikt worden in unit tests om die functies te testen. De third party gebruiker zal trouwens linken tegen de shared library (libpolycap.la), niet de source code. De linker controleert enkel dat de polycap functies die de third party gebruikt uit jouw publieke header ook effectief aanwezig zijn in de shared library.

Van wat je kan doen als je zin hebt eraan te werken:

Mijn grootste prioriteit is natuurlijk de huidige code incorporeren in xmimsim, daar de code nu op zich wel werkt. De laatste week ben ik het vooral aan het opkuisen naar mijn mening, maar de uitkomst blijft dezelfde (gelukkig ;) ). Dus mss een duidelijk overzicht van hoe het programma er moet gaan uitzien om in xmimsim te kunnen passen zou handig zijn, zodat ik het dan kan omvormen naar die concrete vorm (e.g. de gegevens die xmimsim meegeeft en wil ontvangen). de test functies kunnen nog gedaan worden, maar mss ben ik daar meer geschikt voor om beter in te schatten wat de concrete uitkomsten zouden moeten zijn etc? de do loops in main kunnen mss nog naar for omgezet worden, al is dat mss meer dan een paar uur werk ;)

Eerst moeten we de interface in de publieke header vastleggen. Ik zal hier vanmiddag naar kijken op basis van jouw laatste commits. Als we hierover akkoord zijn kan dan de implementatie hieraan aangepast worden. Belangrijk is ook dat de code nu herschreven wordt zodat er effectief een shared library kan van gemaakt worden. Dit betekent eerst en vooral dat de main wordt verhuisd naar zijn eigen bestand. Wil jij dit proberen of zal ik dat doen? Dit is essentieel vooraleer je kan beginnen met unit tests te schrijven.

Mijn excuses als ik wat verwarrend/pedant/ambetant overkom. Dat is echt niet mijn bedoeling. C is geen eenvoudige taal en het is al zeker geen eenvoudige taak om een open source project te gaan schrijven met een deftige interface. Dit is mij bijvoorbeeld niet helemaal gelukt met xraylib en XMI-MSIM door een gebrek aan kennis en ervaring, maar wel met latere projecten als easyRNG en gtkmm-plplot. Mijn ambitie is dit om dit van de eerste keer goed te krijgen met polycap zodat we zeker kunnen zijn dat anderen het vlot kunnen gebruiken, wat zich dan hopelijk ook zal vertalen in citaties...

[PieterTack]

Eerst moeten we de interface in de publieke header vastleggen. Ik zal hier vanmiddag naar kijken op basis van jouw laatste commits. Als we hierover akkoord zijn kan dan de implementatie hieraan aangepast worden. Belangrijk is ook dat de code nu herschreven wordt zodat er effectief een shared library kan van gemaakt worden. Dit betekent eerst en vooral dat de main wordt verhuisd naar zijn eigen bestand. Wil jij dit proberen of zal ik dat doen? Dit is essentieel vooraleer je kan beginnen met unit tests te schrijven.

Als je hiermee bedoelt dat er bijvoorbeeld een apart bestand main.c (mss slechte naam, maar gaat om principe) wordt gemaakt, met daarin de functie main(), die dan bijvoorbeeld een functie polycap() oproept, die het echte rekenwerk uitvoert (middenste deel van de huidige main dus eigenlijk, basically de pragma omp for loop met alles erin), wil ik dat gerust eens proberen. En dan zouden we die polycap functie kunnen porten naar xmimsim uiteindelijk. Of ben ik nu helemaal fout met het opzet van die shared library?

En je komt helemaal niet pedant of ambetant over hoor. Kzit gewoon nogal hard buiten mijn comfort zone (zoals je merkt ben ik geen programmeur, maar eerder een chemist die voldoende kan programmeren om een programma te maken dat doet wat ik wil. En mijn eer zegt dan dat ik mss nog net iets mooier programmeer dan sommige proffen wiens code we allebei kennen, maar kan me daarin vergissen :P ), waardoor ik het gevoel heb echt super langzaam vooruit te gaan, maar mss valt het eigenlijk wel mee hoe het programma aan het ontwikkelen is. In elk geval ben ik ook voorstander van alles direct goed doen hoor. Ik heb er gewoon geen benul van wat "goed" is, en hoe dat er dan uitziet in ons geval :P

[PieterTack]

Alsook, de build is nu aan falen omdat hij in polycap.c bij #include "polycap.h", polycap.h niet vindt. Moet er iets verandert worden aan de configure of moet ik toch gebruiken ipv "polycap.h"? Ik meende dat "" voldoende was daar het in dezelfde directory staat als polycap.c...

[tschoonj]

Als je hiermee bedoelt dat er bijvoorbeeld een apart bestand main.c (mss slechte naam, maar gaat om principe) wordt gemaakt, met daarin de functie main(), die dan bijvoorbeeld een functie polycap() oproept, die het echte rekenwerk uitvoert (middenste deel van de huidige main dus eigenlijk, basically de pragma omp for loop met alles erin), wil ik dat gerust eens proberen. En dan zouden we die polycap functie kunnen porten naar xmimsim uiteindelijk. Of ben ik nu helemaal fout met het opzet van die shared library?

main.c is absoluut geen slechte naam hiervoor. Eerder zelfs een vaak gebruikte conventie. In de regel hou je de main() best zo kort mogelijk. Wat je er typisch in gaat doen is bijvoorbeeld de meegegeven opties te analyseren (aantal threads!), de input-files in te lezen (met functies uit de shared library) en hun inhoud te steken in structs. Vervolgens kan je dan de OpenMP loop uitvoeren en dan uiteindelijk de resultaten wegschrijven. Deze loop zit misschien best ook in een functie uit de shared library.

En je komt helemaal niet pedant of ambetant over hoor.

Danku 😄

Kzit gewoon nogal hard buiten mijn comfort zone (zoals je merkt ben ik geen programmeur, maar eerder een chemist die voldoende kan programmeren om een programma te maken dat doet wat ik wil. En mijn eer zegt dan dat ik mss nog net iets mooier programmeer dan sommige proffen wiens code we allebei kennen, maar kan me daarin vergissen :P ), waardoor ik het gevoel heb echt super langzaam vooruit te gaan, maar mss valt het eigenlijk wel mee hoe het programma aan het ontwikkelen is. In elk geval ben ik ook voorstander van alles direct goed doen hoor. Ik heb er gewoon geen benul van wat "goed" is, en hoe dat er dan uitziet in ons geval :P

Je doet het goed en maakt snel vooruitgang, maak je daar geen zorgen over. Maar maak je geen illusies: we zijn nog vele weken verwijderd van dit effectief ook aan de praat te krijgen in XMI-MSIM. Tevens: als je dit wil integreren in de GUI van XMI-MSIM, zal je merken dat die C code een pak ingewikkelder is dan wat je tot nu toe gezien hebt... 😄

[tschoonj]

De build faalt in de make distcheck fase waarin eerst een tarball gemaakt wordt van de code waarna deze wordt gebruikt om alles nog eens te builden. Het probleem is dat src/Makefile.am geen instructie heeft om polycap.h te gaan verpakken in de tarball waardoor de built faalt. Voeg polycap.h gewoon toe aan polycap_SOURCES achter polycap.c (spaties, geen kommas) en het zou moeten lukken.

Je kan dit lokaal ook testen door zelf make distcheck uit te voeren.

[PieterTack]

Oke, kga wat eten en dan begin ik aan die main.c Klinkt als iets wat ik plezant en uitdagend ga vinden zonder om de haverklap te moeten googlen hoe het precies moet :D

En uiteraard ben ik akkoord met vele weken verwijdert te zijn van echte implementatie. Volgens mijn FWO schedule zou ik tegen oktober beginnen met simulaties ivm confocale kwantificatie, dus we hebben nog wel tijd ;) En in IDL ben ik heel goed met gui's, dus wie weet ben ik een gui-guru ofzo ;) #wishfulthinking

[tschoonj]

Oke, kga wat eten en dan begin ik aan die main.c

Smakelijk!

Klinkt als iets wat ik plezant en uitdagend ga vinden zonder om de haverklap te moeten googlen hoe het precies moet :D

Ik raad u aan eens die autotools introductie te lezen. Daar staat alles redelijk goed in uitgelegd.

En uiteraard ben ik akkoord met vele weken verwijdert te zijn van echte implementatie. Volgens mijn FWO schedule zou ik tegen oktober beginnen met simulaties ivm confocale kwantificatie, dus we hebben nog wel tijd ;) En in IDL ben ik heel goed met gui's, dus wie weet ben ik een gui-guru ofzo ;) #wishfulthinking

Oktober zou wel moeten lukken. Misschien zelfs al eerder. IDL guis zijn in niets te vergelijken met Gtk+ 😄 Het probleem is vooral ook dat het deel in de XMI-MSIM Gui waarin gij zult moeten werken heel slecht geschreven is. De bedoeling is dat ik dat herschrijf maar dat zal nog redelijk wat tijd in beslag nemen...

[PieterTack]

Oke, ben begonnen aan main.c. Echter ik merkte zonet dat in de versie die nu op github staat, als ik valgrind run die compleet begint door te slaan. Ben niet helemaal mee waarom want het gaat precies allemaal mis in de functie segment, maar in die functie heb ik helemaal niks aangepast :S Kan dus te maken hebben met de memory allocation dingen die ik aanpaste. Enerzijds waren dit cap.iz, cap.wi (gewone malloc) en cap.prf, cap.ext,cap.axs en cap.out filenames (met die functie met realloc). Misschien wil jij dat eens uitpluizen?

[tschoonj]

ok

[tschoonj]

Geen probleem hier, op een paar memory leaks na als ik --leak-check=full meegeef als optie maar dat is minder belangrijk. Krijgt ge een crash als je polycap laat lopen zonder valgrind?

[PieterTack]

Nee, zonder valgrind loopt normaal, en uitkomst ziet er ook juist uit. Maar met valgrind krijg ik "Conditional jump or move depends on uninitialised value(s)" (telkens hij sqrt, cos, atan, ... doet. Heb nochtans math.h included. Soms doet hij het ook gewoon ergens in segment, zonder melding van cos e.d. maar kan nergens lijnnr zien waarop fout zou gebeuren)

[tschoonj]

Vreemd... zijn er wijzigingen in uw xos1 input-files die ik niet heb?

[PieterTack]

ah, oke, maar niet met xos1.inp. Die stapt immers uit het programma voor hij echt moet rekenen omdat hij die andere .prf, .ext etc files niet vindt op de juiste locatie. Best de input file ellip_l9.inp gebruiken (da's met de nieuwe functies die de code zelf een PC laten simuleren) Sorry, vergeten vermelden

[tschoonj]

Ik heb het gevonden denk ik. Op lijnen 992, 1016 en 1032 moet uw for loop gaan tot en met profile->nmax.

Dus:

for(i=0;i<=profile->nmax;i++)

[tschoonj]

oh en op 1049 moeten die -1s daar dan ook weg

[PieterTack]

alright, geimplementeerd :) Thanks!

Kan even niet controleren of beter is, want mijn code gaat wss niet compileren nu (met herschikken functies etc) en moet nu weg naar PhD defence :) Een vriendin die werkte omtrent rode fosforen ivm LED toepassingen. Ben benieuwd. Met een beetje geluk zit er wat XAS in, want hun groep gaat ook af en toe op beamtime :) (Filip Smet z'n groep, mss zegt die naam nog iets)

[tschoonj]

ok cool

Btw je kijkt best ook eens naar git stash. Wanneer je dit gebruikt worden al je uncommitted wijzigingen tijdelijk opgeslagen in een soort commit waardoor je working tree terug gebracht wordt naar de laatste commit. git stash pop brengt je wijzigingen terug naar de working tree.

Kan handig zijn als je even snel iets moet fiksen en committen dat niet gerelateerd is aan waar je momenteel aan het werken bent.

[tschoonj]

Ik heb een eerste draft voor de interface geschreven. Herschrijf eerst de code tot een shared library en merge dan deze pull request. Daarna zal ik een nieuwe openen met de draft.

Groetjes en goed weekend!

Tom

[PieterTack]

Oke, kheb dus een aparte main.c gemaakt en de functies in polycap.c wat herschreven (althans sommige) zodat iets logischere structures doorgegeven worden. (zodat we meer op deze code kunnen baseren wanneer we dan incorporeren in xmimsim). Hoe dan ook, compileren faalt. Hij doet lastig bij elke functie die een structure of pointer naar structure returned. Dit werkte vroeger wel, dus ik vermoed dat ik gewoon ergens een Makefile.am ofzo correct moet aanpassen, maar zoals ik het probeerde lukt het niet. Kan jij eens kijken waar ik de mist in ga?

[tschoonj]

ok

[tschoonj]

Heb de boel beetje gefikst.

Heb struct definities verplaatst naar nieuwe private header polycap-private.h. Struct declaraties blijven in publieke header polycap.h.

Ik heb gezien dat je een paar keer een pointer probeerde mee te geven aan een functie en er daar iets aan te gaan malloc'en. Dat werkt niet. Als je zoiets wil doen (zie mijn changes), moet je een referentie nemen naar die pointer, en dan ge malloc'te pointer daaraan toewijzen na dereferentie. Dat deel werkt nu wel, maar een echte propere manier van werken is het niet. Ik denk dat ik dat beter gedaan heb in de interface die ik geschreven heb en ik in een volgende pull request zal tonen.

Zie ook dat je altijd configure draait als:

../configure CFLAGS="-g -O0 -Wall"

Veel van die warnings die je dan krijgt zijn bijzonder nuttig aangezien ze dikwijls ernstige problemen met de code aantonen.

Ik heb mijn wijzigingen getest met xos1.inp en ellip_l9.inp. Bij deze laatste was er wel een error bij het schrijven van het output bestand (Trouble...). Best eens te controleren.

[tschoonj]

Hey Pieter,

Zoals je kan zien geeft mijn laatste commit build problemen bij sommige configuraties omdat int64_t niet gekend is. De oplossing is

#include <stdint.h>

toe te voegen in polycap-private.h. Kan jij dit even doen?

Btw: jij ging ook gaan EXRS right? Plannen om over dit project een presentatie te doen?

[PieterTack]

Included. Kzit nu met compilatie fout die zegt In function 'main': lijn 130 in main.c: Warning: control reaches end of non-void function

Kvermoed dus ergens een haakje kwijt gespeeld te zijn, maar voorlopig nog niks gevonden :P

EXRS ga ik inderdaad heen normaal. Dit voorstellen zou wel cool zijn, maar kvrees dat we nog niet echt veel concreet zullen hebben. Gewoon een herwerkte versie van Laszlo zijn oude code lijkt me wat weinig. Maar kzal het er eens met hem over hebben. En tegen dan hebben we natuurlijk al een stuk meer...

[tschoonj]

Warning: control reaches end of non-void function betekent dat je een functie hebt die alhoewel ze een bepaalde variabele moet returnen, ze dat toch niet doet. In dit geval gebeurt dit in je main functie die een int moet returnen. Simpelst is dus gewoon ervoor te zorgen dat de laatste lijn in deze functie return 0; is.

Dit zal dan trouwens ook de exit status zijn van je programma: de conventie hier is dat 0 wil zeggen dat het programma normaal beëindigd is, terwijl andere waarden op een fout wijzen.

In het algemeen moet je deze warning altijd zien te vermijden. Als dit een andere functie zou geweest zijn en je zou de return value gebruiken alhoewel er geen gereturned wordt krijg je waarschijnlijk een segfault. Recent heb ik gemerkt dat in gevallen waar je de return value toch niet zou gebruiken, je toch nog een segfault kan krijgen...

Voor EXRS kan een poster misschien al voldoende zijn... een paar mooie grafiekjes kan al interessant zijn. Ik verwacht dat polycap zelve tegen dan al klaar zal zijn hoe dan ook. De XMI-MSIM integratie zelf zal waarschijnlijk wat langer duren...