De Devschuur Coffee Corner

[whoami]

Dit topic gaat veel te hard.

[XWB]

AtleX schreef op maandag 07 september 2009 @ 11:04:
Zat dat erin? Nooit gezien eerlijk gezegd, maar na 1998 heb ik nooit Frontpage meer opgestart.

Frontpage Volgens mij had ik dat programma tien jaar geleden ook eens een kans gegeven en daarna maar weer verwijderd. Ik gebruikte toen Dreamweaver, dat waren nog eens tijden Nouja, nog hiervoor begon het met notepad Ook Ultraedit is jarenlang mijn favoriete editor geweest, vooral omdat je hiermee erg vlot over sftp kon werken.

Na een tip van .oisyn gebruik ik nu VS.php in Visual Studio, en dat bevalt me erg uitstekend

[ Voor 3% gewijzigd door XWB op 07-09-2009 21:41 ]

[.oisyn]

KoW schreef op maandag 07 september 2009 @ 18:44:
Qua programmeren heb ik me van school weinig aangetrokken. Bij de lessen was ik meestal niet eens aanwezig, en bij de practica hielp ik meer anderen en deed dan zelf ook nog wat tussendoor. Daar zat voor mij weinig uitdaging in.

Tja, op een HTS-E opleiding leer je natuurlijk ook niet echt bepaald programmeren in de zin van software engineering.

Hacku schreef op maandag 07 september 2009 @ 21:39:
Na een tip van .oisyn gebruik ik nu VS.php in Visual Studio, en dat bevalt me erg uitstekend

\o/
Ik moet zeggen dat ik er ook wel over verbaasd was. Toen ik het ging proberen verwachtte ik een halfbakken add-in, zeg maar alleen een beetje syntax coloring en natuurlijk project management en evt. deployment, maar de integratie is zeer goed. De debugger werkt volledig zoals je van VS zou verwachten. Het enige waar ik aan moet wennen is dat als je een 'step over' op een if-statement oid doet dat hij dan ook over de volledige inhoud van de if heen springt, of het blok erbinnen nou wordt uitgevoerd wordt of niet. Dat is niet zoals het werkt in de overige VS talen, waarbij het slechts bepaalt of je een functie in springt of niet.

[ Voor 48% gewijzigd door .oisyn op 07-09-2009 23:04 ]

[3V3RT]

De mensen achter mixriot.com hebben het gore lef om geld te vragen voor normaliter gratis (of in ieder geval copyrighted) livesets van dj's. Na wat speurwerk heb ik met een stukje javascript icm greasemonkey een scriptje geschreven die de download link gewoon tevoorschijn tovert. Vooral een leermoment wat betreft javascript in deze.

code:

data = window.document.getElementsByTagName('param')[4].value;

number = (data.charAt(data.length-4) + data.charAt(data.length-3) + data.charAt(data.length-2) + data.charAt

(data.length-1));



var divCollection = document.getElementsByTagName("a");
for (var i=0; i<divCollection.length; i++) {
            if(divCollection[i].className == "adl") {
        divCollection[i].href = "http://www.mixriot.com/audio/play/" + number;
                divCollection[i].innerHTML = "Download for free";
                
            }
    
}

i know, ugly as hell, but working like a charm!

[.oisyn]

MLM schreef op maandag 07 september 2009 @ 19:56:
Daarna een HBO (game programming) begonnen, en daar ben ik nog steeds mee bezig (met veel plezier, daarnaast).

Welke opleiding? Ik heb nog steeds een hard hoofd in game opleidingen, zeker voor programmeurs.

[prototype]

Beah, 'k moet die laatste paar puntjes ook maar 's binnenkort erin tikken voor m'n WO-BSc Tech Inf (UTwente), maar kom er elke keer niet aan toe door m'n onderneming Niet dat ik daar over klaag trouwens, werk nu voor enorm inspirerende bedrijven (Twitter, Pixar, the new york times, symantec, de nederlandse publieke omroep etc...) en heb eind dit jaar samen met m'n vennoot een google tech talk. Dat helpt echter niet de ouders van m'n dak af te houden om bij elke gelegenheid te zeuren dat ik m'n diploma's maar 's een keer moet halen... :-\

Ergens hebben ze uiteraard wel gelijk, maar ik kan op de voorhand al zeggen dat ik enorm veel geleerd heb buiten school om en kan ook iedereen aanraden om gewoon in deze tijd een onderneming te overwegen. Ja recessie, daar kan ik je nog wel een paar dingen over vertellen (niks zo pijnlijk als deals die daardoor niet doorgaan), maar het biedt ook kansen :-). Bovendien is het ook niet leuk meer zonder een beetje uitdaging toch? ;-)

[curry684]

.oisyn schreef op maandag 07 september 2009 @ 22:54:
[...]

Ik moet zeggen dat ik er ook wel over verbaasd was. Toen ik het ging proberen verwachtte ik een halfbakken add-in, zeg maar alleen een beetje syntax coloring en natuurlijk project management en evt. deployment, maar de integratie is zeer goed.

Hmm ik heb VS.php een jaar of 2 geleden serieus bekeken en getest en ik vond het maar een halfbakken broddelpartijtje... is het zoveel vooruit gegaan sindsdien of lagen mijn eisen te hoog? Ik gebruik nu consequent Zend Studio for Eclipse.

[MLM]

.oisyn schreef op maandag 07 september 2009 @ 23:19:
[...]

Welke opleiding? Ik heb nog steeds een hard hoofd in game opleidingen, zeker voor programmeurs.

IGAD aan de NHTV in breda Ik zou zeggen, kom eens langs...
Stel eens wat eisen die jij aan een game-programming HBO zou stellen, en dan zal je waarschijnlijk positief verbaasd zijn... (volgens mij is de opleiding vrij uniek, je leert eindelijk iets nuttigs )

[Guillome]

Ik snap het verschil niet:
obj.style != "block" werkt wel, en !obj.style == "block" niet

Niet dat ik het zo toepas, maar kwam het per ongeluk tegen, en vroeg het me af wat er onderhuids gebeurt

[ Voor 37% gewijzigd door Guillome op 08-09-2009 10:49 ]

[momania]

obj.style lijkt mij geen boolean waarde, en dus niet met de ! operator te switchen

[Erkens]

momania schreef op dinsdag 08 september 2009 @ 10:49:
obj.style lijkt mij geen boolean waarde, en dus niet met de ! operator te switchen

Als je het echt zo wilt doen dan moet je haakjes gaan gebruiken.

code:

!(obj.style == "block")

En daarna natuurlijk direct door naar dit topic

[Janoz]

Guillome schreef op dinsdag 08 september 2009 @ 10:48:
Ik snap het verschil niet:
obj.style != "block" werkt wel, en !obj.style == "block" niet

Niet dat ik het zo toepas, maar kwam het per ongeluk tegen, en vroeg het me af wat er onderhuids gebeurt

Operator precedence

Javascript ziet de eerste als

(obj.style) != ("block")

en de tweede als

(!obj.style) == ("block")

[.oisyn]

MLM schreef op dinsdag 08 september 2009 @ 08:30:
[...]

IGAD aan de NHTV in breda Ik zou zeggen, kom eens langs...
Stel eens wat eisen die jij aan een game-programming HBO zou stellen, en dan zal je waarschijnlijk positief verbaasd zijn... (volgens mij is de opleiding vrij uniek, je leert eindelijk iets nuttigs )

Feitelijk doet dat er niet zo toe. De vraag is of je opleiding serieus wordt genomen door normale softwarebedrijven die niets met games doen. Want het aantal arbeidsplaatsen in de gamesindustrie is nou eenmaal zeer gering, dus de kans is groot dat je iets anders moet zoeken. En dan kun je maar beter een opleiding hebben die je veel meer kansen biedt, zoals een reguliere software engineering opleiding, waarmee je net zo goed aan de bak kunt in de gamesindustrie

[Guillome]

Cool, thanks voor de uitleggen

[MLM]

.oisyn schreef op dinsdag 08 september 2009 @ 11:31:
[...]

Feitelijk doet dat er niet zo toe. De vraag is of je opleiding serieus wordt genomen door normale softwarebedrijven die niets met games doen. Want het aantal arbeidsplaatsen in de gamesindustrie is nou eenmaal zeer gering, dus de kans is groot dat je iets anders moet zoeken. En dan kun je maar beter een opleiding hebben die je veel meer kansen biedt, zoals een reguliere software engineering opleiding, waarmee je net zo goed aan de bak kunt in de gamesindustrie

Mja, dat is een valide punt, waar ik zelf ook niet heel blij mee ben. Het is niet dat ik bang ben niet gekwalificeerd te zijn voor "gewoon" software-development, het is meer dat ik bang ben dat potentiele werkgevers mijn CV al voor een sollicitatiegesprek eruit filtert omdat ze een langharige kerel in spijkerboek verwachten...

Maar goed, tot nu toe is de enige "grote" gamedeveloper (~60 man team) in de buurt blij met de kwaliteit van onze opleiding en de stagiares die worden geleverd (er zijn nog geen afgestudeerden, de opleiding start net pas het 4e jaar), wat toch wel een positieve indicatie is Hoe dan ook, ik ben nu "gelukkig" met mijn opleiding, en een beetje competitie bij de sollicatatie voor je "droombaan" is ook niet slecht

[R4gnax]

Pff... Even een bakkie en uitpuffen.

Net de laatste hand gelegd aan een een nieuwe javascript rich-client component. Eigen datagrid gebouwd op basis van JQuery (UI), maar dan wel ééntje met een twist: niet als één monolitische widget, maar opgebouwd als verschillende widgets in een 'pipeline'. Dus een datasource, die data doorstuurt naar een datafilter, naar een datasorter, naar een datapager, en uiteindelijk naar een datagrid voor weergave. (Met nog wat anderen er tussen in ook.)

E.e.a. moest ook goed werken op idioot grote hoeveelheden rijen: een paar duizend volledig clientside in te laden datarows, bijvoorbeeld. Dan loop je al heel snel tegen limieten van javascript in de web browser aan. Script timeout meldingen, enzo. Terloops dus ook maar even meteen een time-sliced versie van JQuery's $.each() functie gemaakt die collecties ophakt in partities en asynchroon (in aparte executie paden, dus geen script timeout meldingen meer!) afhandelt.

Nog wat custom 'progress' events er bij gebruiken en de hele datagrid pipeline kan voortgang van het asynchroon processen van de data naar boven borrelen voor weergave. Ziet er beter uit dan menig 'professionele' datagrid control die gewoon blijft 'hangen', want je browser geeft echt voortgang aan en 'lockt' zichzelf niet tijdens het draaien v/h script.

Gisteren al even wat performance tests gedraaid. Uiteraard vloog Chrome de competitie voorbij: 40 sec. op 2000 rows uit een statische HTML inladen, stylen, filteren, sorteren, subrows in-/uitklappen en pagineren.
Firefox rondde de operatie af in een respectable 1:35 minuten. IE deed er ca. 4 minuten over. Da's wat minder, maar IE's javascript VM is dan ook behoorlijk gaar.

Vandaag nog even bezig geweest met profilen via Firebug. Een paar resterende bottlenecks gevonden en verholpen (Hoofdzakelijk jQuery selectors die véél te duur waren) en zie daar: een factor 26 (!) sneller in de twee bottlenecks die alles vertraagden. Onder IE laden diezelfde 2000 rijen nu in Chrome's oude 40 seconden. Firefox doet er 25 seconden over. Chrome heb ik niet eens meer een performance test op gedraaid.


Hmm.. Zijn er überhaupt datagrids die ditzelfde ook volledig clientside (dus geen serverside paging!) kunnen presteren, of is dit een 'world's first'?

[compufreak88]

Dat ziet er goed uit.

[creator1988]

Waarom in vredesnaam álles op de clientside?

[Guillome]

en laat es wat zien

[Erkens]

creator1988 schreef op dinsdag 08 september 2009 @ 12:38:
Waarom in vredesnaam álles op de clientside?

Wellicht omdat je niet altijd een connectie hebt met een server? Denk aan offline webapplicaties etc

[curry684]

Erkens schreef op dinsdag 08 september 2009 @ 12:56:
[...]

Wellicht omdat je niet altijd een connectie hebt met een server? Denk aan offline webapplicaties etc

Soms verdedigbaar, maar dit gaat nergens over Klinkt echt alsof er een manager zonder enig ICT-inzicht wat beslissingen heeft genomen. Als je een desktopapp wil moet je een desktopapp schrijven, niet een idiote webbased oplossing hacken die vervolgens niet webbased is

Los daarvan absoluut indrukwekkend overigens dat het kan en zulke optimalisaties lukken

[ Voor 9% gewijzigd door curry684 op 08-09-2009 13:06 ]

[R4gnax]

Guillome schreef op dinsdag 08 september 2009 @ 12:53:
en laat es wat zien

Deze grid is gemaakt om ingebouwd te worden in een beheer-interface van een product van mijn werkgever. Javascript is uiterst jatbaar, dus je zult begrijpen dat ik het dus niet zomaar ergens neer kan zetten om te demo-en.

Hmm.. binnenkort eens even iemand met een filmcamera in een telefoon aanstoten (ik heb nog zo'n oude brick waarmee je alleen kunt bellen en SMSen, maar voor mij is dat normaal gesproken functioneel goed genoeg. ) om eens een filmpje er van te maken.

creator1988 schreef op dinsdag 08 september 2009 @ 12:38:
Waarom in vredesnaam álles op de clientside?

Omdat de hele pipeline modulair is, is het ook (bijna) triviaal om de datasource die statische in-page HTML uitparsed te vervangen door een datasource die XML of JSON binnentrekt. Clientside is soms alleen heel handig.

curry684 schreef op dinsdag 08 september 2009 @ 13:04:
Soms verdedigbaar, maar dit gaat nergens over Klinkt echt alsof er een manager zonder enig ICT-inzicht wat beslissingen heeft genomen. Als je een desktopapp wil moet je een desktopapp schrijven, niet een idiote webbased oplossing hacken die vervolgens niet webbased is

Die conclusie kun je niet echt trekken wanneer je niet meer af weet van de ontstaansgeschiedenis van deze grid, laat staan de applicatie waarbinnen deze gebruikt moet worden. Deze applicatie draait voor een groot deel nog op het klassieke asp.net postback model. (Geen MVC, geen AJAX-Toolkit.) Dit script is ontstaan om gebruikt te worden met kleinere hoeveelheden data waar volledig clientside laden en sorteren/filteren de beste oplossing was die het meest onderhoudbaar op te zetten was.

Echter, voor één bepaalde klant moest er ineens véél meer data in kunnen worden gepompt dan eerdere usage scenario's aan toonden. I.p.v. de serverside logica om te gooien is het grid script omgebouwd om data asynchroon, gepartitioneerd in te gaan laden en zo script timeouts te omzeilen. Laad tijden zouden dan op de koop toe zijn, totdat de serverside logica omgebouwd kon worden naar op ajax gebaseerde serverside processing.

Tijdens het opzoeken van script-timeout bottlenecks in het opzetten van die eerste asynchrone versie was het nodig om het hele, toen nog monolitische, script op te delen in makkelijker te testen componenten. Van daar uit was het een kleine stap om dan ook maar een echte 'pipeline' te maken waar je componenten in en uit kon schuiven en versies uit kon wisselen. (Ten slotte: zodra de serverside logica omgebouwd kòn worden, zou ook het script omgebouwd moeten worden om daar op aan te sluiten.)

De performance was een halve side-benefit: ook ons verbaasde het dat we iets hadden wat nog best rap draaide. Uiteindelijk hebben we gewoon gekeken of we ook voor grote hoeveelheden data deze nog werkbaar konden houden. En naar nu blijkt kan dat dus inderdaad.

curry684 schreef op dinsdag 08 september 2009 @ 13:04:
Los daarvan absoluut indrukwekkend overigens dat het kan en zulke optimalisaties lukken

Dank. Het verbaasde mij eigenlijk nog het meeste hoe zeer een impact het direct uitschrijven van jQuery selectors naar harde traversal functies uit maakte. Het verschil tussen $(tr).find("> td:first") en $(tr).children("td").get(0) was 25 milliseconden!

[dev10]

R4gnax schreef op dinsdag 08 september 2009 @ 13:36:
Hmm.. binnenkort eens even iemand met een filmcamera in een telefoon aanstoten (ik heb nog zo'n oude brick waarmee je alleen kunt bellen en SMSen, maar voor mij is dat normaal gesproken functioneel goed genoeg. ) om eens een filmpje er van te maken.

Je kunt toch ook een screencast maken? Is over het algemeen wat duidelijker dan een mobiele telefoon.

[ValHallASW]

R4gnax schreef op dinsdag 08 september 2009 @ 13:36:
Dank. Het verbaasde mij eigenlijk nog het meeste hoe zeer een impact het direct uitschrijven van jQuery selectors naar harde traversal functies uit maakte. Het verschil tussen $(tr).find("> td:first") en $(tr).children("td").get(0) was 25 milliseconden!

op?

[AtleX]

R4gnax schreef op dinsdag 08 september 2009 @ 13:36:
[...]
Deze grid is gemaakt om ingebouwd te worden in een beheer-interface van een product van mijn werkgever. Javascript is uiterst jatbaar, dus je zult begrijpen dat ik het dus niet zomaar ergens neer kan zetten om te demo-en.

Hmm.. binnenkort eens even iemand met een filmcamera in een telefoon aanstoten (ik heb nog zo'n oude brick waarmee je alleen kunt bellen en SMSen, maar voor mij is dat normaal gesproken functioneel goed genoeg. ) om eens een filmpje er van te maken.

http://camstudio.org/ Iesse Gratiesss!!!

ValHallASW schreef op dinsdag 08 september 2009 @ 14:06:
[...]

op?

Da's op zich niet echt relevant zolang je de context niet weet. Ik heb een paar maanden geleden een methode 18ms (gemiddeld) sneller gemaakt, maar die methode werd wel ongeveer 1,5 miljoen keer aangeroepen bij een synchronisatie. Dat scheelde dus zo'n 27.000.000 milliseconden, ofwel 7.5 uur op een complete synchronisatie. Ok, ik gebruikte daarna wel 40% meer geheugen maar een upgrade van 2 naar 4 GB geheugen in de server loste het op. De applicatie is nu CPU-bound ipv I/O-bound en bij een snellere server profiteert de applicatie nog meer.

[ Voor 35% gewijzigd door AtleX op 08-09-2009 14:25 ]

[R4gnax]

AtleX schreef op dinsdag 08 september 2009 @ 14:15:
[...]

http://camstudio.org/ Iesse Gratiesss!!!

Bedankt.

Dat zijn 2000 rows (4x 500 rows, eigenlijk. Originele testcase had 500 lines en ik ben lui, dus 4x copy&paste werkte net zo goed als een constante aanpassen en de generator hercompileren en draaien...)

[ValHallASW]

En het is weer tijd voor een hyves-API-juweeltje:

code:

{"whitespace":[{"whitespacekey":"Religion:","whitespacevalue":"Geen"}]}

Anders gebruik je JSON even hoe het bedoeld is

[R4gnax]

ValHallASW schreef op dinsdag 08 september 2009 @ 15:40:
En het is weer tijd voor een hyves-API-juweeltje:

code:

{"whitespace":[{"whitespacekey":"Religion:","whitespacevalue":"Geen"}]}

Anders gebruik je JSON even hoe het bedoeld is

Je bedoelt dat je itereert over de properties van een object en de values direct daar aan koppelt?

Dus:

code:

{"whitespace": { "Religion": "Geen" }}

Kwestie van smaak, denk ik dan. Kan al te maken hebben met andere al geschreven code die hier op aan moet sluiten. Het is soms makkelijker om een loop te schrijven die over alle elementen van een array itereert en daar de key en value properties van op haalt. Kan al gebeuren door een serialization framework die dat op deze manier doet (zoals de JSON serialization van .NET).

Daarnaast: hoe ga je garanderen dat de naam van de key geen illegale tekens bevat? Wat wanneer je niet een simpele key-value map aan het maken bent, maar een multi-map waar keys niet gegarandeerd uniek zijn? Dit hoeft dus helemaal niets stoms te zijn.

(Hyves kennende zal het alleen wel niet op zo een weloverwogen besluit gestoeld zijn. Daar is al eerder troep vandaan gekomen...)

[ Voor 5% gewijzigd door R4gnax op 08-09-2009 16:04 ]

[ValHallASW]

Of een string nou als key of value wordt gebruikt maakt niet zoveel uit. De mogelijkheid van een set waar meerdere dezelfde keys kunnen voorkomen is er wellicht wel, daar had ik niet aan gedacht. Dan nog zijn er logischere manieren dan dit.

Ik snap ook wel waar het vandaan komt. De JSON is min of meer een 1-op-1-afspiegeling van de XML-output, waar een dergelijke opbouw logischer is. Hoewel ik daar, als XML-leek, toch eerder

code:

<whitespace key="Religion">Geen</whitespace>

zou verwachten dan

code:

<whitespace>
  <whitespacekey>Religion:</whitespacekey>
  <whitespacevalue>Geen</whitespacevalue>
</whitespace>

- hoewel dat misschien weer een kwestie van smaak is.

[AtleX]

Waar slaat dat "whitespace" in al je code-voorbeelden dan op

[D-Raven]

* D-Raven was bezig met het helpen van een collega.

Dus ik laat hem wat normale OO oplossingen zien als alternatief voor de if en while bananen die hij normaal schrijft.

Krijg ik in een stevige discussie daarover te horen: "Ja maar met zoveel method calls is dat kei slecht voor de performance, dat komt allemaal op de stack terecht!" ..

* D-Raven :

* D-Raven geeft op..

Ga maar lekker doorprutsen dan..

[Sebazzz]

Alsof een stack nog lekker boeit bij de processorkrachten dezer dagen. Je wilt niet weten hoe diep het .NET framework gaat wat dat betreft. Bekijk de source van een checkbox maar, of nog erger: Een listview control.

[AtleX]

Een ListView is sowieso dramatisch qua performance, daar heb ik een paar dagen terug nog iets over gepost,

[D-Raven]

AtleX schreef op dinsdag 08 september 2009 @ 19:10:
Een ListView is sowieso dramatisch qua performance, daar heb ik een paar dagen terug nog iets over gepost,

De reden waarom ListView.Items.Add() zo langzaam is en AddRange zo snel is omdat hij bij Add de UI ververst.
Bij AddRange gebeurt dat maar 1x.

Je had je code best kunnen laten hoe het was, al is het op dit moment netter natuurlijk. Als je de for loop gewrapped had in ListView.BeginUpdate() en ListView.EndUpdate(). Dan had je hoogstwaarschijnlijk grofweg zoniet exact, dezelfde performance gehad als dat je nu had

Pin me er niet op vast maar volgende mij doet AddRange achter de schermen precies hetzelfde

[Sebazzz]

D-Raven schreef op dinsdag 08 september 2009 @ 20:30:
[...]
gewrapped had in ListView.BeginUpdate() en ListView.EndUpdate().

Je bedoeld StopLayout en ResumeLayout?

[dcm360]

Ligt aan de taal Sebazzz Ik moet er iig BeginUpdate; en EndUpdate; op afvuren, StopLayout; en ResumeLayout; worden geweigerd door de compiler.

[AtleX]

D-Raven schreef op dinsdag 08 september 2009 @ 20:30:
[...]


De reden waarom ListView.Items.Add() zo langzaam is en AddRange zo snel is omdat hij bij Add de UI ververst.
Bij AddRange gebeurt dat maar 1x.

Dat weet ik. Neemt niet weg dat een redraw van de control nog steeds ranzig langzaam is. Zelfs met minder dan 100 items moet je al flink op je performance gaan letten.

[farlane]

AtleX schreef op woensdag 09 september 2009 @ 08:25:
Dat weet ik. Neemt niet weg dat een redraw van de control nog steeds ranzig langzaam is. Zelfs met minder dan 100 items moet je al flink op je performance gaan letten.

Ik dacht dat .NET zo ongelooflijk snel (of zelfs sneller) was dan wat voor een taal ook omdat er @runtime wordt geoptimaliseerd?

Marketing. ... pfff

[R4gnax]

farlane schreef op woensdag 09 september 2009 @ 08:41:
[...]

Ik dacht dat .NET zo ongelooflijk snel (of zelfs sneller) was dan wat voor een taal ook omdat er @runtime wordt geoptimaliseerd?

Marketing. ... pfff

De standaard Windows.Forms controls renderen m.b.v. native win32 code, voor zover ik weet. Net zoals, pak 'em beet; de oude Delphi VCL? En verrek; die had exact hetzelfde probleem! Dus zou het heel misschien kunnen dat het niet aan .NET ligt maar aan de standaard drek uit WinAPI?

[Anoniem: 142961]

Ik weet niet welke oetlul bij ons de naming conventions bepaald, maar om een klasse nu zo te noemen:

C#:

ServiceLeaseApplicationProposalInvestmentInvestmentService

Gaat m.i. te ver om de hele hiërarchie van objecten in de klassenaam weer te geven.


Leuk bij het instantiëren:

C#:

ServiceLeaseApplicationProposalInvestmentInvestmentService 
  serviceLeaseApplicationProposalInvestmentInvestmentService = 
    new  ServiceLeaseApplicationProposalInvestmentInvestmentService();

[ Voor 32% gewijzigd door Anoniem: 142961 op 09-09-2009 09:36 ]

[jip_86]

Lol, ik kom wel eens aan twee regels, maar 3 gaat wel heel ver. Benieuwd in welke namespace die klasse staat

[momania]

Ach, liever en duidelijke omschrijvende naam, dan een te korte niets zeggende naam

[Anoniem: 313723]

momania schreef op woensdag 09 september 2009 @ 09:37:
Ach, liever en duidelijke omschrijvende naam, dan een te korte niets zeggende naam

Inderdaad, je hebt toch IntelliSense, dus zo'n probleem is het toch niet?

[momania]

CamelCase auto-complete in IntelliJ ftw!

[sorted.bits]

Eerste keer dat ik hier wat post, het is wel grappig om te lezen dat er veel mensen zijn die dezelfde "school-carriere" hebben. HAVO/VWO -> MAVO -> MBO -> HBO.

Zit op dit moment tegen een deadline aan te hikken, die gesteld is door een verkoper (why... o why?). Het komt er op neer dat ik vandaag en morgen nog 40 uur per dag moet maken, om het te halen. Erg handig..

[Anoniem: 142961]

Anoniem: 313723 schreef op woensdag 09 september 2009 @ 09:41:
[...]

Inderdaad, je hebt toch IntelliSense, dus zo'n probleem is het toch niet?

Het gaat ook wel, maar stel dit eens voor in een UML diagram. Er ligt er nu één voor me en dit is niet de enige naam

Ik hou alles wel binnen dezelfde namespace, dus de bedoeling is dat dit alles verborgen blijft. (Het is een aanroep naar een webservice, dus dat moet achter een facade zitten.)

[jbdeiman]

sorted.bits schreef op woensdag 09 september 2009 @ 09:51:
Eerste keer dat ik hier wat post, het is wel grappig om te lezen dat er veel mensen zijn die dezelfde "school-carriere" hebben. HAVO/VWO -> MAVO -> MBO -> HBO.

Zit op dit moment tegen een deadline aan te hikken, die gesteld is door een verkoper (why... o why?). Het komt er op neer dat ik vandaag en morgen nog 40 uur per dag moet maken, om het te halen. Erg handig..

Dit gebeurt te vaak omdat een developer niet wordt meegenomen in het verkoopproces. Een koper stelt (logisch ook) scherpe deadlines, maar soms gewoon te scherp, omdat hij/ zij geen weet heeft van de precieze moeilijkheid en tijdsduur.

Ik ken het zelf ook met die deadlines, klanten willen ook altijd zo snel mogelijk aan de beurt zijn, terwijl ze weten dat er meerdere klanten zijn en ik (in mijn geval) alles alleen doe. En toch verwachten ze altijd dat ze de belangrijkste klant zijn, wat ik gelukkig nu nog prima kan managen.

[momania]

sorted.bits schreef op woensdag 09 september 2009 @ 09:51:
Eerste keer dat ik hier wat post, het is wel grappig om te lezen dat er veel mensen zijn die dezelfde "school-carriere" hebben. HAVO/VWO -> MAVO -> MBO -> HBO.

Bij mij liep het wel een beetje anders:
* HAVO (3e klas blijven zitten, dus 6 jaar in totaal)
* HTS Civiele Techniek *fail* (na half jaar mee gestopt)
* HTS Hogere Informatica *fail* (ook na half jaar mee gestopt)

Nu nog steeds naast een aantal niets zeggende certificaatjes dus m'n HAVO als hoogste opleiding

[farlane]

R4gnax schreef op woensdag 09 september 2009 @ 09:18:
[...]


De standaard Windows.Forms controls renderen m.b.v. native win32 code, voor zover ik weet. Net zoals, pak 'em beet; de oude Delphi VCL? En verrek; die had exact hetzelfde probleem! Dus zou het heel misschien kunnen dat het niet aan .NET ligt maar aan de standaard drek uit WinAPI?

Zou het kunnen zijn dat het niet aan de Win32 drek ligt maar aan .NET en de VCL? Je kunt wel zeggen dat het rendert met native code maar hoe snel het wordt is natuurlijk wel afhankelijk van hoeveel lagen je er tussen bouwt.

[ Voor 12% gewijzigd door farlane op 09-09-2009 10:26 ]

[.oisyn]

De visual styles van Win XP (common controls versie 6) gooien ook behoorlijk wat roet in het eten. Onze GUI app was ook ineens baggertraag nadat we comctl6 gingen gebruiken (goed, die redrawde op zich ook meer dan nodig, maar dat was een bewuste keuze omdat het de code simpeler maakte en het voorheen geen merkbaar performance issue opleverde). Het lijkt alsof ie eerst door tig lagen aan theme meuk heen moet.

[ Voor 26% gewijzigd door .oisyn op 09-09-2009 10:52 ]

[Canaria]

Anoniem: 142961 schreef op woensdag 09 september 2009 @ 09:34:
Leuk bij het instantiëren:

C#:

ServiceLeaseApplicationProposalInvestmentInvestmentService 
  serviceLeaseApplicationProposalInvestmentInvestmentService = 
    new  ServiceLeaseApplicationProposalInvestmentInvestmentService();

Gelukkig hebben we daarvoor nu vars

[MTWZZ]

Volgens mij is het gewoon een kwestie van goed gebruik van je controls of het nou .Net of Win32 is.
Met Win32 kun je net zulke langzame applicaties bouwen als met welke andere control toolkit dan ook.

[farlane]

.oisyn schreef op woensdag 09 september 2009 @ 10:51:
De visual styles van Win XP (common controls versie 6) gooien ook behoorlijk wat roet in het eten. Onze GUI app was ook ineens baggertraag nadat we comctl6 gingen gebruiken (goed, die redrawde op zich ook meer dan nodig, maar dat was een bewuste keuze omdat het de code simpeler maakte en het voorheen geen merkbaar performance issue opleverde). Het lijkt alsof ie eerst door tig lagen aan theme meuk heen moet.

Ik moet zeggen dat ik daar geen last van heb gehad, maar ik gebruikte dan ook niet de common controls. Geen idee hoeveel overhead je daarbij meeneemt overigens.

MTWZZ schreef op woensdag 09 september 2009 @ 11:35:
Volgens mij is het gewoon een kwestie van goed gebruik van je controls of het nou .Net of Win32 is.
Met Win32 kun je net zulke langzame applicaties bouwen als met welke andere control toolkit dan ook.

Misschien wel maar als je plain Win32 zit te werken en het is dan traag, ligt het iig niet aan de extra lagen die er omheen zitten want die zijn er niet. Plain Win32 controls zijn in mijn ervaring niet langzaam oid, ook niet als ik 512+ items in een listview heb zitten. ( Wel een pain om mee te werken trouwens )

[ Voor 31% gewijzigd door farlane op 09-09-2009 11:58 ]

[.oisyn]

farlane schreef op woensdag 09 september 2009 @ 11:53:
[...]

Ik moet zeggen dat ik daar geen last van heb gehad, maar ik gebruikte dan ook niet de common controls.

Maar dat is nou juist de hele issue. De standaard controls, die je krijgt als je niet in je manifest zet dat je comctl6 wilt gebruiken, renderen prima. Maar zodra je de XP look and feel wilt gebruiken, dan worden redraws e.d. ineens een heel stuk duurder.

[farlane]

Grrrr waarom vernaggelt een terminal sessie mijn dual monitor bureablad layout?

.oisyn schreef op woensdag 09 september 2009 @ 11:56:
Maar zodra je de XP look and feel wilt gebruiken, dan worden redraws e.d. ineens een heel stuk duurder.

Ah ok, dat wist ik niet.

[ Voor 65% gewijzigd door farlane op 09-09-2009 12:04 ]

[Anoniem: 142961]

Canaria schreef op woensdag 09 september 2009 @ 11:31:
[...]

Gelukkig hebben we daarvoor nu vars

Ow nee die discussie weer

Zit dat eigenlijk ook in .NET 1.1? Wat? Ja wij zitten nog in 1.1, financiële sector.. je kent het wel. Alhoewel we nu toch maar gaan upgraden, gelijk ook maar naar 3.5.... dat dan weer wel!

[Haan]

anonymous types (vars) zijn geïntroduceerd in .Net 3.0

[Creepy]

farlane schreef op woensdag 09 september 2009 @ 10:24:
[...]

Zou het kunnen zijn dat het niet aan de Win32 drek ligt maar aan .NET en de VCL? Je kunt wel zeggen dat het rendert met native code maar hoe snel het wordt is natuurlijk wel afhankelijk van hoeveel lagen je er tussen bouwt.

Een list o.i.d. in VCL valt qua aantal lagen echt wel mee. Ik heb zelf nooit een performance test gedaan met het vullen van een list control in Delphi vs C maar ik denkt eerlijk gezegd niet dat dat een merkbaar performance verschil oplevert als je 1 voor 1 items blijft adden en dus een redraw blijft veroorzaken. .beginUpdate en .endUpdate (in Delphi in elk geval) en het was echt enorm veel sneller.

[creator1988]

farlane schreef op woensdag 09 september 2009 @ 12:02:
Grrrr waarom vernaggelt een terminal sessie mijn dual monitor bureablad layout?

UltraMon voorkomt dit.

[.oisyn]

Anoniem: 142961 schreef op woensdag 09 september 2009 @ 13:15:
[...]


Ow nee die discussie weer

Die hele discussie was zinloos wegens gebrek aan kennis bij Niemand_Anders over wat 'var' nou eigenlijk doet . Overigens heeft ie niet meer gereageerd sinds whoami en ik dat getracht hebben recht te zetten

Haan schreef op woensdag 09 september 2009 @ 13:17:
anonymous types (vars) zijn geïntroduceerd in .Net 3.0

C# 3.0 dan, .Net zelf heeft er vrij weinig mee van doen. 't Is compile time syntactic sugar.

[ Voor 26% gewijzigd door .oisyn op 09-09-2009 13:41 ]

[curry684]

creator1988 schreef op woensdag 09 september 2009 @ 13:38:
[...]


UltraMon voorkomt dit.

Ultramon heb ik afgelopen jaar hoofdzakelijk op lopen vloeken - Windows 7 is een veel betere remedie tegen monitorproblemen

[.oisyn]

Heeft die nou eindelijk eens een taakbalk per monitor? Want die feature is eigenlijk de enige reden dat ik ultramon gebruik

[ Voor 100% gewijzigd door .oisyn op 09-09-2009 13:52 ]

[curry684]

Nee da's het enige wat Win7 nog niet heeft, maar gezien de wijzigingen in Win7 in het concept 'taskbar' waarbij er niet meer een directe relatie is tussen taskbar icons en windows lijkt me dat sowieso tricky in de praktijk. Voornaamste wat Windows 7 nu foutloos doet is de positie van specifieke externe monitoren onthouden binnen verschillende situaties. Ik werk doorlopend met en zonder dockingstation om de beurt, en voorheen had ik continu gezeik met verneukte resoluties of dat m'n monitor ineens rechts zat van de laptop (hij hoort links). Windows 7 nog geen enkele keer iets aan verziekt

[Anoniem: 142961]

.oisyn schreef op woensdag 09 september 2009 @ 13:47:
Heeft die nou eindelijk eens een taakbalk per monitor? Want die feature is eigenlijk de enige reden dat ik ultramon gebruik

Ja die gebruik ik ook.... alleen hebben mijn dual monitors af en toe de neiging om de boel om te draaien ... dan ziet je taakbalk ineens op het rechter scherm....

[Guillome]

En dat je gemaximaliseerde schermen kan slepen naar je andere scherm natuurlijk

[matthijsln]

Aaarggh. Wat een stomme bug. Ik maar denken dat 't aan mijn code lag...

[BtM909]

3V3RT schreef op maandag 07 september 2009 @ 23:08:
De mensen achter mixriot.com hebben het gore lef om geld te vragen voor normaliter gratis (of in ieder geval copyrighted) livesets van dj's. Na wat speurwerk heb ik met een stukje javascript icm greasemonkey een scriptje geschreven die de download link gewoon tevoorschijn tovert. Vooral een leermoment wat betreft javascript in deze.

code:

data = window.document.getElementsByTagName('param')[4].value;

number = (data.charAt(data.length-4) + data.charAt(data.length-3) + data.charAt(data.length-2) + data.charAt

(data.length-1));



var divCollection = document.getElementsByTagName("a");
for (var i=0; i<divCollection.length; i++) {
            if(divCollection[i].className == "adl") {
        divCollection[i].href = "http://www.mixriot.com/audio/play/" + number;
                divCollection[i].innerHTML = "Download for free";
                
            }
    
}

i know, ugly as hell, but working like a charm!

Weet je zeker dat hij werkt? Elke link verwijst naar de eerste downloadlink van de pagina

edit:

Oh wacht, je doet het natuurlijk vanaf 't begin, dus ff zorgen dat ik op de aparte mix pagina sta

[ Voor 4% gewijzigd door BtM909 op 09-09-2009 14:57 ]

[OkkE]

Goh, al weer een tijdje niet in /13 geweest, maar het ziet er hier gezellig uit!

[BtM909]

Hij blijft leuk:

[sorted.bits]

Guillome schreef op woensdag 09 september 2009 @ 14:07:
En dat je gemaximaliseerde schermen kan slepen naar je andere scherm natuurlijk

SHIFT+WIN+Pijltje, om een venster naar een andere monitor te plaatsen.. Inderdaad ook erg handig . Nog geen 2 taakbalken jammer genoeg en Ultramon in Windows 7 is irritant. De tweede taakbalk is niet echt een ECHTE taakbalk.

[.oisyn]

BtM909 schreef op woensdag 09 september 2009 @ 15:41:
Hij blijft leuk:

[afbeelding]

Geh
En natuurlijk deze bekende:

[Ryur]

.oisyn schreef op woensdag 09 september 2009 @ 16:47:
[...]


Geh
En natuurlijk deze bekende:
[afbeelding]

Lol, ga ik ook op school gebruiken.

Btw: mijn schoolopleidingen:

- VMBO-T (gewoon 4 jaar)
- Havo (2 jaar toen nog; net gehaald, als de vernieuwde Tweede fase niet was ingevoerd had ik het niet gehaald).
- HBO-Informatica (huidige opleiding, net een 1,5 week gestart; maar ik verveel me als de dood).

[Creepy]

@.oisyn: Daar heb ik laatst een shirt van besteld via de XKCD shop

[ Voor 7% gewijzigd door Creepy op 09-09-2009 16:55 ]

[Remus]

Boeboe schreef op maandag 07 september 2009 @ 17:00:
[...]


VInd het alleen spijtig dat het allemaal zo waanzinnig duur is. UGent biedt dit ook aan. Bachelor informatica is 42 modules. Prijs per module is 263 euro, doe zelf maar de rekensom

Ik studeer zelf aan de Open Universiteit (informatica) en 263 euro per module (100 uur) is best goedkoop als je bedenkt dat het inclusief studiemateriaal is (boeken, software ed). Daarnaast krijg je korting als je 3 of meer vakken tegelijk besteldt (wordt dan 223 euro). Per behaald vak krijg je een credit en bij zes credits kan je die credits omruilen voor een gratis vak.

Diezelfde vakken worden buiten de reguliere studie (dus als je een enkel vak bestudeert) ook aangeboden voor bedragen tussen de 1200 en 2100 euro (afhankelijk van het vak). Ik laat mijn werkgever overigens al een paar jaar betalen. Als je vergelijkt dat een gemiddeld jaar (6 vakken) bij de OU +/- 1400 euro kost, terwijl ik binnenkort een 3 daagse cursus + examen ga doen dat mijn werkgever 2100 euro kost terwijl de informatie en kennis die je opdoet bij de OU toch meer diepgang heeft... dan is de value for money al snel duidelijk.

Op zich bevalt de Open Universiteit mij prima, maar het grote probleem is toch dat je minder contact hebt met medestudenten en zelf verantwoordelijk bent voor je studietempo. Ik zelf ben in 2001 begonnen en hoop in de loop van volgend jaar mijn bachelor te halen; ik weet nog niet of ik door ga voor de master, maar volgend jaar is vroeg genoeg om daar over na te denken.

BTW: Ik ben zonder problemen door VWO gestoomd, de problemen begonnen eigenlijk pas tijdens mij eerste studie (Technische Natuurkunde), waar eigenlijk bleek dat ik nooit echt hard studeren had geleerd. Dan val je toch behoorlijk door de mand. Op advies van de studieadviseur nog een paar weekjes electrotechniek aan de TH Rijswijk geprobeerd en vervolgens maar gaan werken. Toen in 2001 toch maar weer eens aan een studie begonnen

[Matis]

Even een quickfix scriptrequest:

HTML:

<a href="index.php?page=0&dir=">« Vorige</a>

W3C zegt: Line 15, Column 210: general entity "dir" not defined and no default entity.

HTML:

<a href="index.php?page=0&fol=">« Vorige</a>

W3C zegt: Line 15, Column 210: general entity "fol" not defined and no default entity.

Maar dat is toch valide html 4.01 strict?

/edit; lol, de parser vind ook van niet

&

[ Voor 9% gewijzigd door Matis op 09-09-2009 19:58 ]

[Bozozo]

Down schreef op zondag 06 september 2009 @ 19:43:
[...]

(...)

Thread.Sleep(1) is trouwens vaak een signaal dat er iets aan je ontwerp niet klopt

Dat dacht ik zelf eigenlijk ook. Inmiddels heb ik mn app omgebouwd en het loopende draadje met sleep(1) eruit geknikkerd... en nu gebruikt ie méér CPU

[Creepy]

@matis: Anders klik je even op de link die bij de foutmelding staat? De tekst "Ampersands in URLs" linkt je naar een stuk tekst waar het direct in uitgelegd wordt.

Another common error occurs when including a URL which contains an ampersand ("&"):

<!-- This is invalid! --> <a href="foo.cgi?chapter=1&section=2&copy=3&lang=en">...</a>

This example generates an error for "unknown entity section" because the "&" is assumed to begin an entity reference. Browsers often recover safely from this kind of error, but real problems do occur in some cases. In this example, many browsers correctly convert &copy=3 to ©=3, which may cause the link to fail. Since ⟨ is the HTML entity for the left-pointing angle bracket, some browsers also convert &lang=en to 〈=en. And one old browser even finds the entity §, converting &section=2 to §ion=2.

To avoid problems with both validators and browsers, always use & in place of & when writing URLs in HTML:

<a href="foo.cgi?chapter=1&section=2&copy=3&lang=en">...</a>

Note that replacing & with & is only done when writing the URL in HTML, where "&" is a special character (along with "<" and ">"). When writing the same URL in a plain text email message or in the location bar of your browser, you would use "&" and not "&". With HTML, the browser translates "&" to "&" so the Web server would only see "&" and not "&" in the query string of the request.

Daarnaast heb je zelf ook al door dat de vraag te lam is voor woorden omdat je geen eigen topic opent. Dude, kom op zeg

offtopic:
En nee, daar is dit topic dus ook niet voor bedoelt. En zeker jammer voor iemand die zelf ook graag met links met uitleg rondsmijt

[ Voor 4% gewijzigd door Creepy op 09-09-2009 20:13 ]

[pedorus]

Het schijnt trouwens dat je ook op Tweakers &amp; moet gebruiken om een & te maken...

[Matis]

pedorus schreef op woensdag 09 september 2009 @ 20:23:
Het schijnt trouwens dat je ook op Tweakers &amp; moet gebruiken om een & te maken...

_{Je kan m ook excapen met het nohtml code}

Haha, ja daar ben ik met php tegenaan gelopen;

strreplace("&ndash;","-",$str);

En hij deed het maar niet, totdat ik me ineens bedacht
&amp;ndash


Niet meer boos zijn, gij almachtige creepy

[ Voor 5% gewijzigd door Matis op 09-09-2009 20:30 ]

[curry684]

Bozozo schreef op woensdag 09 september 2009 @ 20:03:
[...]


Dat dacht ik zelf eigenlijk ook. Inmiddels heb ik mn app omgebouwd en het loopende draadje met sleep(1) eruit geknikkerd... en nu gebruikt ie méér CPU

Lees curry684 in "De Devschuur Coffee Corner" eens, daar heb ik uitgelegd waarom je dit effect ziet.

[pedorus]

Matis schreef op woensdag 09 september 2009 @ 20:28:
_{Je kan m ook excapen met het nohtml code}

Bij zo'n langere quote met veel &-en is nohtml inderdaad een nog betere optie.

[Bozozo]

curry684 schreef op woensdag 09 september 2009 @ 20:32:
[...]

Lees curry684 in "De Devschuur Coffee Corner" eens, daar heb ik uitgelegd waarom je dit effect ziet.

Niet precies. Ik heb nu helemaal geen while(true) loop meer.

Toelichting:

Oude situatie

C#:

public override void onPaint(PaintEventArgs e)
{
  e.Graphics.DrawImage(offscreenBitmap,0,0);
}

public void setData(double[] data)
{
  this.xyData = data;
  somethingToDraw = true;
}

//Looping Thead
private void pollingThread() {
  while(true)
  {
    if(somethingToDraw)
    {
      somethingToDraw = false;
      
      // Paint this.xyData to offscreenBitmap
      // ...

      this.Invalidate()
    }
    Sleep(1);
  }
}

Nieuwe situatie

C#:

public override void onPaint(PaintEventArgs e)
{
  if(newData)
  {
    newData = false;

    // Paint this.xyData to offscreenBitmap
    // ...

  }
  e.Graphics.DrawImage(offscreenBitmap,0,0);
}

public void setData(double[] data)
{
  this.xyData = data;
  newData = true;
  this.Invalidate();
}

Die nieuwe code lijkt mij netter maar zorgt voor meer cpu load (zonder merkbaar sneller te draaien).

[whoami]

En waar komt threading hier bij kijken ?

[Bozozo]

whoami schreef op donderdag 10 september 2009 @ 11:36:
En waar komt threading hier bij kijken ?

Uiteraard wordt die pollingthread functie in een aparte thread gedraaid.

[whoami]

* whoami ziet geen pollingThread method in 2de codevoorbeeld...

(Maar, dit topic is ook geen helpdesktopic dacht ik zo)

[Bozozo]

Nee maar ik vermoed dat curry dacht dat ik alleen de sleep(1) had verwijderd, waardoor zijn eerdere verklaring voor hogere cpu load zou opgaan. Dat wilde ik even corrigeren.

En ik heb geen hulp nodig, ik post alleen iets wat me opvalt. Voor zover ik weet mag dat in dit topic.

[whoami]

Resharper werkt op mijn zenuwen.

- Als ik new SomeClass type, dan plaatst ie er altijd de haakjes automatisch bij, terwijl ik in de opties heb gedefinieerd dat ie dat niet mag doen.

- Ik zorg altijd voor curly braces bij m'n for / if / whathever statements, ook al beslaat de then tak van dat if statement maar één statement bv. Dan nog tipt ie me altijd dat ik die haakjes kan weglaten. En ik vind nergens hoe ik dat kan afzetten. Ik type dat er niet voor niets hé, rukker.

[AtleX]

Bozozo schreef op donderdag 10 september 2009 @ 11:32:
Die nieuwe code lijkt mij netter maar zorgt voor meer cpu load (zonder merkbaar sneller te draaien).

Invalidate() zorgt voor een redraw wat een best kostbare operatie is en je roept 'm nu een stuk vaker aan.

[Canaria]

whoami schreef op donderdag 10 september 2009 @ 11:45:
Resharper werkt op mijn zenuwen.

Mij ook, vind het maar irritant. Ik heb liever de standaard Intellisense van VS, maar het zit standaard op m'n managed dev omgeving
Locaal draai ik het natuurlijk niet en dat maakt het alleen nog maar verwarrender.

[whoami]

Je kan wel in de opties bepalen welke intellisense je nu eigenlijk wil (die van resharper, of die van vs.net).

[Canaria]

whoami schreef op donderdag 10 september 2009 @ 11:58:
Je kan wel in de opties bepalen welke intellisense je nu eigenlijk wil (die van resharper, of die van vs.net).

Ja dat is waar maar de Resharper config file hangt hier in TFS

[Bozozo]

Aaah shoot me!

Ik compilede op debug terwijl ik eerst release deed. Als ik nu ook release gebruik is de cpu load ongeveer hetzelfde als met de extra thread.

[Creepy]

*schiet*

[AtleX]

Hm, ondanks dat het aanroepen van GC.Collect() volgens sommigen zo ongeveer het slechtste is dat je kan doen heb ik het schijnbaar toch nodig. Binnen één van mijn applicaties heb ik na een bepaalde actie (die op een instelbare interval wordt uitgevoerd) zo'n 100MB aan dode objecten die de automatisch garbage collector zelfs na een uur nog niet opruimt terwijl GC.Collect() ze wel weg kiepert Ben benieuwd waar dat door komt.

[ Voor 4% gewijzigd door AtleX op 10-09-2009 13:03 ]

[curry684]

Er is niets mis met GC.Collect() aanroepen als je er een specifieke goede reden voor hebt. In 99% van de gevallen waar men het gebruikt is het echter stomweg niet nodig.

De GC werkt gewoon met thresholds, als ie nog geen reden ziet om op te schonen of er geen tijd/resources voor heeft doet ie het gewoon niet. Dus zolang je niet wild aan het swappen bent en er nog genoeg physical is, waarom zou ie?

[AtleX]

Bij mij loopt het lekker op, na 5 runs zit ik met 500MB aan dode objecten en dat gaat door tot ik zo'n 1,5GB gebruik. Dan pas ruimt de GC het op terwijl de VM waar de tool in draait maar 1GB geheugen heeft. Door GC.Collect() zijn de latere runs, als er dus al veel dode objecten zijn, veel sneller en hoef ik eigenlijk niet te swappen.

Ik ben enigzins bekend met de werking van de garbage collector, maar eerlijk gezegd zou ik verwachten dat 'ie op een gegeven moment toch wel een complete clean-up doet. Zeker bij een applicatie die tussen de runs door gewoon staat te idlen. Ik vermoed dat die dode objecten op generation 2 staan en die wordt theoritisch niet vaak bezocht door de GC, maar bij mij lijkt hij er nooit langs te komen. Gen.0 clean-ups heb ik volgens CLRprofiler namelijk genoeg, per uur zo'n 20-30.

[ Voor 43% gewijzigd door AtleX op 10-09-2009 13:47 ]

[OkkE]

Wat is het stijlen van formulieren op websites toch een ramp! Het moet ook altijd in elke browser op de pixel precies staan...

[.oisyn]

Gebruik flash

[Sebazzz]

.oisyn schreef op donderdag 10 september 2009 @ 15:24:
Gebruik flash

Nee Silverlight duh

[NMe]

Nee joh, schrijf gewoon je eigen browser en dwing al je bezoekers die te gebruiken.