Zoekresultaat: 163 berichten gevonden

Je mag gewoon statisch linken met bibliotheken die onder de LGPL licentie worden vrijgegeven. De software hoeft dan niet onder de GPL licentie vrijgegeven te worden. De broncode zul je nooit zien, hoor. Er is een degelijk verschil tussen LGPL en GPL.

Statische libs is meestal een zeer goede reden waarom een executable enorm groot wordt. Ik maak zelf gebruik van wxWidgets libs en die zijn static gelinked met mijn sourcecode.

Executable grootte
---------------------------

Static: 2.5 MB
Dynamic: (hooguit) 100 KB

Dit zijn mappen (NL):



Dit is een map (EN, meervoud maps):

quote:

The return value of glRenderMode is determined by the render
mode at the time glRenderMode is called, rather than by
mode. The values returned for the three render modes are as
follows:

GL_RENDER 0.

GL_SELECT The number of hit records transferred to the
select buffer.

GL_FEEDBACK The number of values (not vertices)
transferred to the feedback buffer.

Ik denk dat je met de call glRenderMode(GL_RENDER) altijd een nul terug krijgt. Misschien is het handig om te checken wat voor waarde glRenderMode(GL_SELECT) geeft.

Grub 15 krijg je meestal als bepaalde bestanden niet gevonden kunnen worden. Ik weet niet of het moglijk is, maar misschien is het verstandig om even geen RAID config te gebruiken en te gaan installeren op een enkele harde schijf en checken of dat goed draait. Dan kan je wel proberen om de zaak te "schalen" over meerdere disks.

Moet dat stukje code niet in een soort actionPerformed/commandAction eventhandler?

Volgens mij is het een beetje te lastig voor de leerlingen. Het is voor hen een beetje te dieppgaand. Ze gaan nu waarschijnlijk iets met Lego Mindstorms doen.

De infraroodzender en -ontvanger zijn echt. De infraroodzender is een apart apparaat en de ontvanger is een USB dongle. Ik zal wel even kijken of er een API aanwezig is en zo ja, wat ik er mee kan doen.

Hallo,

een aantal informaticaleerlingen hebben de opdracht gekregen om een fietscomputer te simuleren op een pc. Nu wil ik graag weten of het te maken programma gemaakt kan worden met VB.NET. Het is de bedoeling dat er een event afgegeven wordt zodra de infraroodzender contact maakt met de ontvanger. Dat event moet dan worden afgevangen en verwerkt worden. Het event verwerken zal waarschijnlijk niet zo'n groot probleem zijn, maar het detecteren van de verbinding hoogstwaarschijnlijk wel. Ik heb zelf al wat rondgekeken en ik kwam zaken zoals dit uit. Het gaat me eigenlijk niet om het tot stand brengen van een verbinding, maar om het signaal zelf. Een domme infraroodzender werkend op een batterijtje is niet echt een device om verbinding mee te maken. Het moet dus allemaal veel lager. Weten jullie zo of het eigenlijk wel kan met VB.NET of is C/C++ toch een betere taal is voor dit soort doeleinden?

PS. Ik beloof te zeggen hoe het gegaan is en wat de resultaten waren nadat het programma werkend is gekregen.

Ik heb net de nieuwe 8.04 beta geinstalleerd en ik moet zeggen dat ik behoorlijk onder de indruk ben. Alles doet het gewoon zeer goed. Zelfs alle grafische effecten werken perfect met mijn Radeon 9200. Beat that Vista

Dat probleem heb ik ook hoor
Je moet gewoon wachten totdat Mozilla en/of Adobe de boel fixt.

Hey wat gaaf zeg dat hier een topic is dat compleet over duurzame energie gaat. Hehe, ik kijk ff bij Electronica... ff kijken hoe het daar is....

Ik had het topic eigenlijk verwacht in W&L, maar okee....

Ik ben zelf 1 van de beheerders van dit forum en ik heb ook nog dit programmaatje geschreven.

Wat je doet is gewoon het volgende:

- Je moet sowieso iets van een Event Handler schrijven die dingen van de muis opvangt.
- Je moet het volgende checken wanneer de muisknop in wordt gedrukt:
Check of de aanwijzer boven een lijntje hangt, zoja, dan ga je gewoon steeds de coordinaten van de muis opvragen en ga je aan de hand daarvan steeds opnieuw het verandere figuur tekenen en dan de zaak repainten.

Details ken ik zo niet, want ik heb al een paar jaar niet meer in Java geprogrammeerd.

Ik heb alles voor elkaar gekregen. Mijn shell ondersteunt nu ook pipes. Ik ga niet zeggen wat ik precies gedaan heb om er voor te zorgen dat niet iedereen klakkeloos mijn code gaat overnemen, maar ik kan wel zeggen dat de bovenstaande code redelijk fout is.

Hallo,

ik ben momenteel bezig met het schrijven van een shell onder Linux welke binnenkort wordt getest onder Minix 3.

Ik heb veel zaken al aan de praat, zoals I/O redirection, backgrounding ("&"), etc, maar het enige wat ik niet goed aan de praat krijg is het opzetten van een pijplijn tussen n processen. Ik krijg namelijk bij het herleiden de volgende foutmelding:

*** glibc detected *** double free or corruption (!prev): 0x0804b108 ***

Hieronder staat het voorbeeld in het boek Operating Systems van Tanenbaum:
C:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#define STD_INPUT 0 #define SD_OUTPUT 1 pipeline(process1, process2) char *process1, *process2 int fd[2]; pipe(&fd[0]); if (fork() != 0) {   close(fd[0]);   close(STD_OUTPUT);   dup(fd[1]);   close(fd[1]);   execl(process1, process1, 0); } else {   close(fd[1]);   close(STD_OUTPUT);   dup(fd[0]);   close(fd[0]);   execl(process2, process2, 0); }

Hierboven staat een beetje code voor communicatie tussen twee processen middels een pipe, maar dit is niet wat ik wil hebben, want het moet werken voor n processen zonder de exec in de parent process, omdat de shell dan vervangen wordt door een ander proces (je bent je shell kwijt). Wat ik dus doe is het volgende. Ik maak een char pointer array die naar alle commando's wijzen die 1 voor 1 in het child gedeelte worden uitgevoerd. Ik maak sowieso gebruik van een filedescriptor array die 2 maal zo groot is als het aantal commando's, zodat tussen de processen door wel alles gebuffered blijft met het pipe commando waarna alles weer afgesloten wordt en zowel stdin als stdout gedupt wordt zodat het alles weer teruggezet wordt naar het oude situatie.

Hieronder staat mijn code:
C:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

if (commandIndex == 0) {                         pipe(&fd[0]);                         pipe(&fd[2]);                         stdoutfd = dup(STDOUT);                         stdinfd = dup(STDIN);                 }                 else {                         pipe(&fd[(commandIndex + 1) * 2]);                 }                                                  if (fork() != 0) {                         close(fd[commandIndex * 2]);                         close(STDOUT);                         dup(fd[(commandIndex * 2) + 1]);                         close(fd[(commandIndex * 2) + 1]);                         if ((background == 0) && (commandIndex == (maxPipe + 1))) {                                 waitpid(-1, &status, 0);                         }                 }                 else {                         close(fd[(commandIndex * 2) + 1]);                         close(STDIN);                         dup(fd[commandIndex * 2]);                         close(fd[commandIndex * 2]);                         if (commandIndex < (maxPipe + 1)) {                                 close(fd[(commandIndex + 1) * 2]);                                 close(STDOUT);                                 dup(fd[((commandIndex + 1) * 2) + 1]);                                 close(fd[((commandIndex + 1) * 2) + 1]);                         }                         else {                                 close(fd[((commandIndex + 1) * 2) + 1]);                                 dup(stdoutfd);                             }                         execve(command, parameters, NULL);                 }                 close(fd[((commandIndex + 1) * 2)]);                 dup(stdinfd);

De foutmelding treedt op zodra de close functie direct onder de fork aangeroepen wordt.

EDIT:

ik kom er net achter dat close niks veroorzaakt. De foutmelding treedt direct na de fork op. Waarschijnlijk gaat er dan iets mis in het child gedeelte.

EDIT2:

De parameterlijst wordt dubbel gealloceerd. Waarschijnlijk gaat er dan iets fout als het gefreed wordt.

quote:

microsofty710 schreef op woensdag 05 december 2007 @ 08:32:
En nu wat Ubuntu doet:
Eens per half jaar maken ze een kopie van Debian's unstable tak. Makeup wordt gedaan, wat rekwisieten toegevoegt en er komt een fluffer langs. Daarna kunnen de DVD's naar de persen.

Ik heb niks tegen Ubuntu, sterker nog heb hier alle desktops en laptop erop draaien. Zelfs mijn thuis servertje draait Ubuntu (omdat de mythtv packages wat nieuwer zijn). Maar in een proffesionele omgeving zou ik het niet als server durven inzetten.

Wat vind je nou eigenlijk van de LTS tak van Ubuntu?

quote:

ecteinascidin schreef op maandag 19 november 2007 @ 20:04:Het is natuurlijk een of/of situatie, niet de hele checklist hoeft afgegaan te worden maar bepaalde facetten daarvan. Dat lijstje beschrijft IMHO meer een profiel waarmee je een +2 kan herkennen. Intern zou ik dus zoiets ook opschrijven.

Ik bedoelde eigenlijk "1 of meer". Mijn excuses voor deze vergissing.

Hallo,

volgens mij kunnen de woorden recursion en recursive gewoon vertaald worden naar recursie en recursief

Ik denk dat je je eerst moet afvragen of er uberhaupt wel meer aggresiever gemod moet worden.

Weet je toevallig ook hoeveel reacties voldoen aan (1 van) de volgende kwalificaties?

- De reactie mag niet gemist worden.
- De reactie is een belangrijke aanvulling op de informatie in het artikel
- De reactie is een uitgebreid omschreven ervaring uit eigen hand
- De reactie is een goed gefundeerde kritiek
- De reactie is een uitgebreide antwoord op een andere reactie.
- De reactie bevat veel inzichten en kennis die niet bij het grote publiek aanwezig is.

Als het getal van de reacties niet overeenkomt met het aantal reacties dat op +2 gemod is, dan moet er inderdaad agressiever gemod worden en anders niet.

quote:

Olaf van der Spek schreef op vrijdag 09 november 2007 @ 18:25:
Niet volledig, bij sommige compilers kun je gewoon kiezen.

Okee, dat wist ik niet

Het is erg lastig om dat te voorkomen, want de compiler geeft namelijk geen waarschuwingen over het type char dat wordt gebruikt (signed of unsigned). Het is volledig afhankelijk van de processor. Het enige snelle manier om er achter te komen dat je niet in de 'val' bent getrapt is om gewoon het programma te runnen en kijken hoe het zich gedraagt.

Ik zou niet weten waarom isspace onveilig zou zijn. Laat ik een gok doen: het gedrag is ongedefinieerd wanneer je geen int voert aan de functie die een unsigned char representeert?

Ow

Mijn excuses