[Excel 2003/2007] Incomplete reeks tot complete reeks maken

[gambieter]

Ik weet niet of de titel de lading dekt, maar ik weet niet goed wat de benamingen zijn van de waarschijnlijk heel simpele actie is die ik wil doen. Vandaar vast een preemptive als ik dit toch echt zelf had moeten kunnen vinden

Ik heb een aantal grafieken bestanden die een bepaalde signaalsterkte koppelen aan een positie op een bacteriele chromosoom, welke 1641480 posities heeft. Het zijn gewoon platte tekstbestanden met daarin twee kolommen, de X-waarde (1-1641480) en een Y-waarde. De grafiekbestanden bevatten alleen de posities waar een positieve of negatieve waarde aanwezig was, dwz de 0 waarden welke afwezigheid van signaal betekenen zitten er niet in:

82	2
83	2
84	2
85	1
86	1
1395	7
1396	18
1397	18
1398	22

Nu wil ik dezelfde bestanden ook kunnen gebruiken in een andere viewer, en die heeft een tekstbestand nodig waar de regel de X-waarde is, en dus ook 0-waarden mee moeten worden genomen:

(85)	1
(86)	1
(87)	0
(88)	0
 |	|
 |	|
(1393)	0
(1394)	0
(1395)	7
(1396)	18
(1397)	18

De getallen tussen haakjes staan dan niet in de file, maar puur voor de visualisatie toegevoegd.

Nu kan ik wel met arrays gaan werken, maar dat lijkt me nogal overkill. Helaas heb ik geen enkele ervaring met VBS etc. Hoe kan ik de ontbrekende waarden in een cijferrij ingevuld krijgen? Ook voorzie ik een probleem met de grootte van de databestanden, want kan Excel wel omgaan met meer dan 65536 rijen?

Is er een eenvoudige truc die ik over het hoofd zie?

[ Voor 6% gewijzigd door gambieter op 18-06-2009 17:00 ]

[Verwijderd]

ach ja. mooi weer en zo. de werkmap moet opgeslagen zijn, tekstbestand word opgeslagen in zelfde map op de harde schijf. de macro wordt opgeroepen vanuit het werkblad met de waardes, waarvan de eerste zich bevindt op rij2, kolom2

Visual Basic:

Option Explicit

Public Sub SchrijfBacterieChromosoomPositieWaardes()
  Dim fnlngSchrijfWaardes As Long
  Dim BaChPo              As Range
  Dim BaChPoCel           As Range
  
  Open _
      (ActiveWorkbook.Path & "/BacterieChromosoomWaardes.txt") _
  For Output As #1
  Set BaChPo = _
      Range _
        ( _
          Range("a2"), _
          Range("a2").End(xldown) _
        )
  For _
      fnlngSchrijfWaardes = BaChPo.Cells(1).Value _
  To _
      BaChPo.Cells(BaChPo.Cells.Count).Value
    Set BaChPoCel = _
        BaChPo.Find _
          (What:=fnlngSchrijfWaardes, LookIn:=xlValues, LookAt:=xlWhole)
    If (Not (BaChPoCel Is Nothing)) Then
      Print #1, fnlngSchrijfWaardes; BaChPoCel.Offset(, 1).Value
    Else
      Print #1, fnlngSchrijfWaardes; 0
    End If
  Next
  Close #1
  MsgBox "klaar!"
End Sub

[gambieter]

Wow, dank . Ik ga er naar kijken.

Ik hoop dat ik ietwat krediet heb en een domme vraag mag stellen. Hoe start ik dit precies op?
(wat niet betekent dat ik niet zelf aan de slag ga!)

Gelukt, het is bezig.

Verwijderd schreef op donderdag 18 juni 2009 @ 18:43:
ach ja. mooi weer en zo. de werkmap moet opgeslagen zijn, tekstbestand word opgeslagen in zelfde map op de harde schijf. de macro wordt opgeroepen vanuit het werkblad met de waardes, waarvan de eerste zich bevindt op rij2, kolom2

klopt dat laatste wel? Ik moest het toch echt op A1 laten beginnen?

Ik zit trouwens wel met die 65536 rijen, als ik een tekstbestand inlaad, dan is dat het maximum (en dus veel te weinig). Is dat een Excel probleem? Zo ja, enige suggesties hoe dit te ontwijken (dwz kan het in Word? )

Edit: het is trouwens wel langzaam, en mijn laptop begon aardig heet te worden. Ik neem aan dat dit zeer processorintensief is?

(zeker niet ondankbaar bedoeld!)

[ Voor 94% gewijzigd door gambieter op 18-06-2009 23:36 ]

[Verwijderd]

gambieter schreef op donderdag 18 juni 2009 @ 23:05:
Wow, dank . Ik ga er naar kijken.

Ik hoop dat ik ietwat krediet heb en een domme vraag mag stellen. Hoe start ik dit precies op?
(wat niet betekent dat ik niet zelf aan de slag ga!)

Gelukt, het is bezig.

klopt dat laatste wel? Ik moest het toch echt op A1 laten beginnen?

met kolomtitels in eerste rij op a2 laten beginnen, in het voorbeeld zoals je gegeven hebt inderdaad op a1 (dit moet je dan in m'n code aanpassen (a2 wijzigen in a1)

Ik zit trouwens wel met die 65536 rijen, als ik een tekstbestand inlaad, dan is dat het maximum (en dus veel te weinig). Is dat een Excel probleem? Zo ja, enige suggesties hoe dit te ontwijken (dwz kan het in Word? )

ja dit is een probleem tot en met excel2k3, vanaf 2k7 heb je miljoenen rijen, maar nog steeds mogelijk te kort. iig is het niet mogelijk het tekstresultaatbestand volledig te bekijken in <2k7 indien meer dan 2^16-1 rijen.

Edit: het is trouwens wel langzaam, en mijn laptop begon aardig heet te worden. Ik neem aan dat dit zeer processorintensief is? :)[

(zeker niet ondankbaar bedoeld!)

de find is zeer intensief ja. het voorbeeldbestand dient echter binnen de seconde klaar te zijn. +-1000 records per seconde, vanaf +10000 bronrijen wordt het geheel een stuk trager. deze oplossing is zeker een van de meest trage.

[gambieter]

Verwijderd schreef op vrijdag 19 juni 2009 @ 00:25:
met kolomtitels in eerste rij op a2 laten beginnen, in het voorbeeld zoals je gegeven hebt inderdaad op a1 (dit moet je dan in m'n code aanpassen (a2 wijzigen in a1)

Ah, duidelijk

ja dit is een probleem tot en met excel2k3, vanaf 2k7 heb je miljoenen rijen, maar nog steeds mogelijk te kort. iig is het niet mogelijk het tekstresultaatbestand volledig te bekijken in <2k7 indien meer dan 2^16-1 rijen.

Ik kreeg ook maar 65536 rijen in 2007. Maar als Office2007-interface hater en anti-overstapper (wij hebben 2003 en 2007 beiden op alle PCs) realiseerde ik me toen dat 2007 bij mijn standaard op 2003-compatibiliteitsmodus staat... Ik heb het nu in een XLSX bestand gedaan, en dan is de 65536-beperking weg .

de find is zeer intensief ja. het voorbeeldbestand dient echter binnen de seconde klaar te zijn. +-1000 records per seconde, vanaf +10000 bronrijen wordt het geheel een stuk trager. deze oplossing is zeker een van de meest trage.

Ik heb momenteel 12 zulke bestanden die ik aan wil passen, en een PC op mijn werk die ik per VPN kan gebruiken. Die laat ik dan wel stampen

Thanks

---

Hm, het is wel erg langzaam. Ik had mijn desktop op het werk (Core2Duo met 2 Gb, twee jaar oud) vannacht aangezet, en na ruim 8 uur was hij pas bij 223,000 aangekomen. Dat zou toch sneller moeten kunnen, riep de ongeduldige n00b. Ik ga eens even met onze Perl-mensen praten

[ Voor 10% gewijzigd door gambieter op 19-06-2009 11:42 ]

[Reptile209]

Is het niet een stuk efficienter om de array in je sheet door te lopen met een lusje van 1 tot en met .End(xlDown)? Je waarden staan immers op volgorde, dus je hoeft niet te zoeken. Elke keer als het verschil tussen twee regels > 1 is, weet je dat je x regels met een 0 moet invoegen in je tekstbestandje. Volgens mij omzeil je zo de dure Find() functie en moet het een behoorlijk stukkie sneller lopen. Als de laatste waarde < 1641480 is, voeg je die reeks nullen uiteraard ook toe, en let even op het geval waarin bijvoorbeeld je eerste positie nummer 42 is (>1).

[onkl]

Visual Basic:

Option Explicit

Public Sub SchrijfBacterieChromosoomPositieWaardes()
'verwacht een gesorteerd bestand.
  Dim fnlngSchrijfWaardes As Long
  Dim BaChPo              As Range
  Dim BaChPoCel           As Range

  Open _
      (ActiveWorkbook.Path & "/BacterieChromosoomWaardes.txt") _
  For Output As #1
  Set BaChPo = _
      Range _
        ( _
          Range("a1"), _
          Range("a1").End(xlDown) _
        )
  Set BaChPoCel = BaChPo.Cells(1)
  For _
      fnlngSchrijfWaardes = BaChPo.Cells(1).Value _
  To _
      BaChPo.Cells(BaChPo.Cells.Count).Value
      
      If fnlngSchrijfWaardes = BaChPoCel.Value Then
          Print #1, fnlngSchrijfWaardes; BaChPoCel.Offset(, 1).Value
          Set BaChPoCel = BaChPoCel.Offset(1, 0)
      Else
          Print #1, fnlngSchrijfWaardes; 0
      End If

  Next
  Close #1
  MsgBox "klaar!"
End Sub

Mogelijke optimalisatie:
De loop blijft werken zoals de code van _heretic_ , maar de eerstvolgend te gebruiken cel in je bronbestand wordt bijgehouden. Zodra de tellerwaarde (fnlngSchrijfWaardes) gelijk is aan de waarde van die cel BaChPoCel, wordt je resultaatwaarde ook weggeschreven (en de "volgende cel" één cel naar beneden geschoven), anders alleen de teller.

[Verwijderd]

gambieter schreef op vrijdag 19 juni 2009 @ 00:34:
Dat zou toch sneller moeten kunnen, riep de ongeduldige n00b. Ik ga eens even met onze Perl-mensen praten

wel gij sen ondanckbaeren vleeghel
in ieder geval zou (gebrek aan) kennis van programmeertalen je er niet van mogen weerhouden betere algoritmes in algemene termen te formuleren (en te posten)
maar de codeaanpassingen van onkl zal het geheel wel enkele ordegroottes sneller maken.

[gambieter]

Verwijderd schreef op vrijdag 19 juni 2009 @ 16:46:
wel gij sen ondanckbaeren vleeghel

Geenszins ondankbaar, verre van dat .

in ieder geval zou (gebrek aan) kennis van programmeertalen je er niet van mogen weerhouden betere algoritmes in algemene termen te formuleren (en te posten)
maar de codeaanpassingen van onkl zal het geheel wel enkele ordegroottes sneller maken.

Ik ga kijken wat ik kan doen.

offtopic:
Vergis je niet, het is bij mij niet gebrek aan kennis met programmeren, maar gebrek aan inzicht; databases en programmeren zijn twee dingen die me nooit lukten . En toen heb ik het maar opgegeven

.

onkl schreef op vrijdag 19 juni 2009 @ 16:31:
Mogelijke optimalisatie:
De loop blijft werken zoals de code van _heretic_ , maar de eerstvolgend te gebruiken cel in je bronbestand wordt bijgehouden. Zodra de tellerwaarde (fnlngSchrijfWaardes) gelijk is aan de waarde van die cel BaChPoCel, wordt je resultaatwaarde ook weggeschreven (en de "volgende cel" één cel naar beneden geschoven), anders alleen de teller.

Thanks, die ga ik vanavond een run voor zijn geld geven!

Reptile209 schreef op vrijdag 19 juni 2009 @ 15:50:
Is het niet een stuk efficienter om de array in je sheet door te lopen met een lusje van 1 tot en met .End(xlDown)? Je waarden staan immers op volgorde, dus je hoeft niet te zoeken. Elke keer als het verschil tussen twee regels > 1 is, weet je dat je x regels met een 0 moet invoegen in je tekstbestandje. Volgens mij omzeil je zo de dure Find() functie en moet het een behoorlijk stukkie sneller lopen. Als de laatste waarde < 1641480 is, voeg je die reeks nullen uiteraard ook toe, en let even op het geval waarin bijvoorbeeld je eerste positie nummer 42 is (>1).

Ik was inderdaad van plan om met een array te gaan spelen, zoals ik ooit hier heb geleerd

[gambieter]

Spieren strekken, aanloop, KICK!

Uiteindelijk ben ik maar eens naar een bioinformaticus met Perl-ervaring gestapt en hem gevraagd een script te genereren. Dat werkt goed, is wel traag (op mijn Core2Duo E6300 met 2 Gb RAM doet het script er 4-5 uur over per file onder Windows XP in een DOS-box). Om dit topic nuttig te laten zijn hierbij het script, met dank aan collega Mark Alston.

code:

#################################################################
# This script an input file of high-throughput sequence data
# and fills in the 'gaps'
#
# USAGE:  recreateFullList.pl inputFile.txt  >  outputFile.txt
#################################################################
#!/usr/bin/perl -w
use strict ;
use warnings ;

my $firstFile = $ARGV[0] ;

my @inputArray ;

my $counter = 1 ; 

#----------------------------------------------------------
# Read the file into an array and do some clever stuff
#----------------------------------------------------------

open (F1, $firstFile) or die "$!";
while(<F1>)
{   
   my $line = $_ ; 
   chomp($line) ;

   my @fields = split( /\t/, $line ) ;

   my $element = $fields[0] ;
   my $value = $fields[1] ;


   if($element == $counter)
   {    $inputArray[$element] = $value ;  }
   

   if($element > $counter)
   {        
    for(my $count = $counter ; $count < $element ; $count++)
    {   $inputArray[$count] = 0 ;  } 

        $inputArray[$element] = $value ;

    $counter = $element ;
   }
   
   $counter++ ;
}
close(F1);

#----------------------------------------------------------
# Construct the output
#----------------------------------------------------------

my $size = @inputArray ; 
my $output = '' ;

for(my $count = 1 ; $count < $size ; $count++)
{
   $output = $output  . $count . "\t" . $inputArray[$count] . "\n" ;
} 

print $output ;

[Reptile209]

Kan je niet een voorbeeldbestandje delen, want ik kan me haast niet voorstellen dat dat langer dan een paar minuten zou moeten duren. * Reptile209 wil wel effe rommelen .

[gambieter]

Reptile209 schreef op woensdag 19 augustus 2009 @ 19:59:
Kan je niet een voorbeeldbestandje delen, want ik kan me haast niet voorstellen dat dat langer dan een paar minuten zou moeten duren. * Reptile209 wil wel effe rommelen .

Ik heb een deelbestand gemaakt, tot aan net voorbij de 300,000: link. Voor de proof-of-principle is dat genoeg, hoop ik .

Vast bedankt

[Reptile209]

gambieter schreef op donderdag 20 augustus 2009 @ 13:27:
[...]

Ik heb een deelbestand gemaakt, tot aan net voorbij de 300,000: link. Voor de proof-of-principle is dat genoeg, hoop ik .

Vast bedankt

Top, zal vanavond thuis eens kijken. Ter referentie: hoe lang doet deze (ingekorte) file er bij jou over om verwerkt te worden?

[Verwijderd]

heb ff geknoeid in delphi. 63 milliseconden voor de testfile (intel E6550 @ 2,33)
(resultaat is 302353 regels totaal), via een simpele berekening zou de volle file rond de 3 seconden komen.

360msecs, als je als resultaat
(1) 83
(2) 383
..
..
..
(3033) 20

wilt hebben.

gooi anders ff de hele file, gezipped neer.

[ Voor 80% gewijzigd door Verwijderd op 20-08-2009 14:58 ]

[Reptile209]

Verwijderd schreef op donderdag 20 augustus 2009 @ 14:38:
heb ff geknoeid in delphi. 63 milliseconden voor de testfile (intel E6550 @ 2,33)
(resultaat is 302353 regels totaal), via een simpele berekening zou de volle file rond de 3 seconden komen.

360msecs, als je als resultaat
(1) 83
(2) 383
..
..
..
(3033) 20

wilt hebben.

gooi anders ff de hele file, gezipped neer.

Kijk, dat zijn tijden die ik verwacht had. Dat moet helemaal geen uren duren!

[Verwijderd]

precies. volgens mij is er iets ernstigs aan de hand op de pc's van gambieter.
de vba-code van onkl is met het voorbeeldbestandje op mijn hoofdpc (pentium 4 1.7, 256MB (jawel)) klaar in 6,19 seconden.
mijn oorspronkelijke code is pokketraag - veel trager nog dan ik had verwacht

overigens bij een snelle blik op de perlcode moet ik toch vaststellen dat deze onefficiënt geschreven is : het oorspronkelijke bestand wordt volledig in het geheugen geladen en geparsed/verwerkt, daarna wordt deze resultaatarray uit het geheugen weggeschreven naar het tekstbestand.
dat zou wel eens problemen kunnen geven bij dergelijke resultaatbestanden.

[Reptile209]

_heretic_: da's ook nog wel een leuk puntje om te benchmarken denk ik. Bij de ene aanpak gooi je alles in (snel) geheugen, dan parsen en dan kan je het in één keer wegschrijven. Als alternatief kan je achter elkaar een regeltje inlezen, regeltje(s) wegschrijven. Bij die tweede aanpak heb je volgens mij kans op vertragingen door het om-en-om aanspreken van de twee files, maar een zeer minimaal geheugengebruik.

[Verwijderd]

Verwijderd schreef op donderdag 20 augustus 2009 @ 15:33:
precies. volgens mij is er iets ernstigs aan de hand op de pc's van gambieter.
de vba-code van onkl is met het voorbeeldbestandje op mijn hoofdpc (pentium 4 1.7, 256MB (jawel)) klaar in 6,19 seconden.
mijn oorspronkelijke code is pokketraag - veel trager nog dan ik had verwacht

overigens bij een snelle blik op de perlcode moet ik toch vaststellen dat deze onefficiënt geschreven is : oorspronkelijke bestand volledig in geheugen en geparsed/verwerkt, daarna wordt deze resultaatarray uit het geheugen wegschrijven naar bestand.
dat zou wel eens problemen kunnen geven bij dergelijke resultaatbestanden.

Principe voor dit probleem is vrij simpel, ik lees de source in, lees regel, bereken het verschil, indien verschil dan aantal keeren verschil 0 wegschrijven, regelwaarde wegschrijven, ga "terug" naar lees regel.
alleen voor de eerste regel moet je ff een uitzondering maken. Alles dus direct op de source en target file

Probleem bij dat perl script, is dat ie in de "construct output" continue string aan het concatten is, nu weet ik niet hoe Perl daar mee omgaat, maar b.v. in .Net zou je daar al een stringbuilder object gebruiken. Kans is groot dat dat concatten in Perl hier de bottleneck is.

[ Voor 13% gewijzigd door Verwijderd op 20-08-2009 15:41 ]

[Verwijderd]

Reptile209 schreef op donderdag 20 augustus 2009 @ 15:37:
_heretic_: da's ook nog wel een leuk puntje om te benchmarken denk ik. Bij de ene aanpak gooi je alles in (snel) geheugen, dan parsen en dan kan je het in één keer wegschrijven. Als alternatief kan je achter elkaar een regeltje inlezen, regeltje(s) wegschrijven. Bij die tweede aanpak heb je volgens mij kans op vertragingen door het om-en-om aanspreken van de twee files, maar een zeer minimaal geheugengebruik.

inderdaad. de laatste zin in m'n vorige post is belangrijk.
de perlcode is snel zolang alles door het ramgeheugen afgehandeld kan worden. is dat niet het geval dan zal het os beginnen swappen en zijn de kolen gaar.
dan is het omslagpunt bereikt waar om-en-om aanspreken van de bestanden sneller is.

[ Voor 46% gewijzigd door Verwijderd op 20-08-2009 15:45 ]

[Verwijderd]

Verwijderd schreef op donderdag 20 augustus 2009 @ 15:44:
[...]

inderdaad. de laatste zin in m'n vorige post is belangrijk.
de perlcode is snel zolang alles door het ramgeheugen afgehandeld kan worden. is dat niet het geval dan zal het os beginnen swappen en zijn de kolen gaar.
dan is het omslagpunt bereikt waar om-en-om aanspreken van de bestanden sneller is.

Na niet alleen memory, maar kans is groot dat dat concatten intern echt wordt afgehandeld met steeds kopieen maken , alloceren van objecten etc.


Zal de code ff posten, kan gambieter 'm zelf compileren met een of andere freewasre delphi/pascal compiler.
let op, is "grove" code, dus geen error en/of i/o checking etc.
(maak je wel 's andere code, zou een collega tegen me zeggen)

Delphi:

program gambieter;

{$APPTYPE CONSOLE}

uses
  DateUtils,SysUtils;

const
  input  = 'D:\gambieter.txt';
  output = 'D:\gambieter_out.txt';


var
  Start : TDateTime;
  linecount,
  diff,
  oldline,
  current : cardinal;
  f_in,
  f_out   : TextFile;
  value,
  line    : string;

procedure SplitLine(Line : string; var LineNr : cardinal; var Value : string);
var
  i : integer;
begin
  LineNr := 0;
  Value  := '';
  i      := pos(#9,Line);
  if i>0 then
  begin
    LineNr := StrToIntDef(Copy(Line,1,i - 1),0);
    Value  := copy(line,i + 1,length(line));
  end;
end;

begin
 Start := Now;
 linecount := 0;

 AssignFile(f_in,input);
 Reset(f_in);

 AssignFile(f_out,output);
 Rewrite(f_out);
 oldline := 0;

 while (not eof(f_in)) do
 begin
    Readln(f_in, line);
    Inc(linecount);

    SplitLine(line, current, value);

    diff := current - oldline;
    if (oldline>0) and (diff>1) then
    begin
       repeat
         writeln(f_out, '0');
         dec(diff);
       until(diff=1);
    end;

    Writeln(f_out,  value);
    oldline := current;
  end; //

 closefile(f_in);
 closefile(f_out);
 
 writeln(linecount,' Lines processed in :', MilliSecondsBetween(now,start),' msecs');
end.

[ Voor 17% gewijzigd door Verwijderd op 20-08-2009 15:59 ]

[gambieter]

Verwijderd schreef op donderdag 20 augustus 2009 @ 15:33:
precies. volgens mij is er iets ernstigs aan de hand op de pc's van gambieter.

Dat zal dan wel de user zijn .

de vba-code van onkl is met het voorbeeldbestandje op mijn hoofdpc (pentium 4 1.7, 256MB (jawel)) klaar in 6,19 seconden.
mijn oorspronkelijke code is pokketraag - veel trager nog dan ik had verwacht

overigens bij een snelle blik op de perlcode moet ik toch vaststellen dat deze onefficiënt geschreven is : het oorspronkelijke bestand wordt volledig in het geheugen geladen en geparsed/verwerkt, daarna wordt deze resultaatarray uit het geheugen weggeschreven naar het tekstbestand.
dat zou wel eens problemen kunnen geven bij dergelijke resultaatbestanden.

Ik ben inderdaad vergeten te reageren op de voorbeeldcode van onkl (excuus ), die kreeg ik niet aan het werk op dat moment. Ben zo druk geweest dat ik er toen niet meer naar heb kunnen kijken. Mijn voorbeeldbestand had op een laptop (Sempron processor, 1Gb RAM) eerder deze week iets van 20-30 minuten nodig via Perl. Op mijn E6300 doet het voorbeeldbestand het in <15 minuten; nog steeds traag.

@maui71, Reptile209: dank, ik ben benieuwd! De perl-code is een quick'n'dirty script, niemand is hier echt goed met programmeren. Ik klaag niet, ik was dankbaar voor de hulp!

Verwijderd schreef op donderdag 20 augustus 2009 @ 15:53:
Na niet alleen memory, maar kans is groot dat dat concatten intern echt wordt afgehandeld met steeds kopieen maken , alloceren van objecten etc.


Zal de code ff posten, kan gambieter 'm zelf compileren met een of andere freewasre delphi/pascal compiler.
let op, is "grove" code, dus geen error en/of i/o checking etc.
(maak je wel 's andere code, zou een collega tegen me zeggen)
code
program gambieter

. Ik ga aan de slag, mijn eerste stapjes in compilen

[ Voor 20% gewijzigd door gambieter op 20-08-2009 16:08 ]

[gambieter]

(expres als dubbelpost)

@maui71: . Het doet een file in ongeveer 1500 msec, en haalt ook nog de kolom met positiewaardes weg (wat het perl-script niet doet). Ik ben helemaal blij en onder de indruk .

[Reptile209]

gambieter schreef op donderdag 20 augustus 2009 @ 18:47:
[...]
Ik ben helemaal blij en onder de indruk .

Mag ik je dan het subforum Programming aanraden?

[gambieter]

Reptile209 schreef op donderdag 20 augustus 2009 @ 19:44:
Mag ik je dan het subforum Programming aanraden?

Ik weet het, maar dat zit er voorlopig niet in... Ik houd het echter in gedachten voor mijn pensionering.