De Devschuur Coffee Corner

[Salandur]

Het probleem van het loggen met een if constructie is dat dit erg nadelig is voor je code coverage. Op het moment dat je dit goed kan wegstoppen dan levert het een voordeel op. Door het toevoegen van varargs aan java 5 kan je het mooi wegstoppen in de aanroep van de log methode en dan is de hele if ook overbodig geworden. Ik geloof dat SLF4J daar ook al rekening mee houdt

Java:

LOG.fine("bericht %s", duurObject)

Het enige probleem is je duurObject.toString(), die toString() zou niet duur mogen zijn!

[ Voor 5% gewijzigd door Salandur op 24-01-2011 11:53 ]

[Woy]

YopY schreef op maandag 24 januari 2011 @ 11:45:
mbt loggen: doe zelf gewoon:

Java:

if (LOG.isLoggable(Level.FINE) {
   LOG.fine("bericht " + duurObject.toString());
}

Is het niet handiger om die check niet op de plek van je logging te doen, maar gewoon in je logger? Dat maakt je code wel een stuk overzichtelijker.

Wij werken gewoon met Log4Net, en dan kan je zoveel appenders aan een bepaald logobject/level hangen als je wil. En als er geen appenders zijn verdwijnt het gewoon in dev/null

De overhead van die toString lijkt me erg mee te vallen. Ik heb tenminste nooit een erg complexe toString.

@hierboven: Als de formatting inderdaad in je logging gedaan word, zou je die er inderdaad nog uitgeoptimaliseerd kunnen worden als dat logLevel niet enabled is. Maar dan nog lijkt het me een uitzondering dat een toString zo "duur" is dat het je performance in de weg gaat zitten. Het komt hooguit voor op het moment dat je een loop enorm vaak uitvoert, dan kan elk klein beetje extra al roet in het eten gooien natuurlijk

[ Voor 31% gewijzigd door Woy op 24-01-2011 12:17 ]

[Alex)]

Dan zou ik kiezen voor zoiets:

C#:

LOG.fine("Ik heb iets speciaals te melden. ", duurObject);

C#:

public static class LOG
{
    // knip
    public static void fine(string message, object relatedObject)
    {
        if(LogLevel >= LogLevel.Fine)
        {
            WriteMessage(message, relatedObject.ToString());
        }
    }
}

Eventueel nog een paar overloads zodat je ook kunt loggen zonder een object te hoeven meegeven.

Of zoiets.

[ Voor 11% gewijzigd door Alex) op 24-01-2011 12:42 ]

[MBV]

Da's leuk en aardig voor desktop-applicaties, maar als je het op (bijvoorbeeld) een telefoon wilt proppen is een #ifdef wel zo handig.

[Woy]

MBV schreef op maandag 24 januari 2011 @ 13:02:
Da's leuk en aardig voor desktop-applicaties, maar als je het op (bijvoorbeeld) een telefoon wilt proppen is een #ifdef wel zo handig.

Nou vind ik een telefoon niet zo'n heel goed voorbeeld, want die heeft tegenwoordig ook zat resources, en daar zal een check of logging enabled is waarschijnlijk ook niet zo'n impact hebben.

Maar bij andere embedded devices kan ik het me wel voorstellen. Echter zou ik dan nog steeds gewoon met een #ifdef een al dan niet lege macro definieren, zodat je wel compile time de logging uit kan schakelen, en niet overal in je code die #ifdef's neerzetten.

[Janoz]

Woy schreef op maandag 24 januari 2011 @ 12:13:
Is het niet handiger om die check niet op de plek van je logging te doen, maar gewoon in je logger? Dat maakt je code wel een stuk overzichtelijker.

Nee, wanneer je de if constructie weglaat wordt de parameter geevalueerd. Dit betekend dat in dit geval een dure toString aangeroepen wordt en deze vervolgens samen met de constante string in een nieuwe string geconcateneerd wordt en daarna wordt dit meegegeven aan de logfunctie waar besloten wordt er helemaal niks mee te doen.

[.oisyn]

Dat toString() goedkoop moet zijn is natuurlijk een non-argument voor het gebruik van de if. Je kunt ipv een toString() net zo goed een andere functie/method aanroepen die wél duur is.

[Soultaker]

Ja, áls je een kostbare methode aanroept, dán is het wenselijk om er aan de buitenkant een if-statement omheen te zetten, maar dat betekent toch niet dat je dat per se overal moet doen? Ik heb het met Woy eens dat je dat soort checks best achterwege kunt laten behalve op performance-kritische locaties.

Ik heb zelf dus ook altijd een check in de logfunctie, en los daarvan een functie om het huidige level te checken, die slechts sporadisch gebruikt wordt. De overhead van de extra check als er daadwerkelijk iets gelogt wordt is natuurlijk verwaarloosbaar, en in het grootste deel van je code kan de eerste check achterwege blijven, wat de leesbaarheid ten goede komt.

Sowieso is het context-afhankelijk wanneer de overhead van een call naar een logging functie te groot is. Een log statement ergens aan de top level zal meestal geen probleem zijn, maar hetzelfde statement ergens in een lus diep in je code misschien niet.

[Woy]

.oisyn schreef op maandag 24 januari 2011 @ 13:45:
Dat toString() goedkoop moet zijn is natuurlijk een non-argument voor het gebruik van de if. Je kunt ipv een toString() net zo goed een andere functie/method aanroepen die wél duur is.

Maar hoe vaak komt het nou voor dat je een erg dure call doet die alleen voor je logging uitgevoerd word? In de meeste gevallen is die overhead minimaal, en is het IMHO duidelijker om die if achterwege te laten. Natuurlijk zijn er altijd uitzonderingen (Maar die bevestigen de regel natuurlijk alleen maar )

[.oisyn]

Je zou ook van delegates gebruik kunnen maken.

C#:

Logger.Log(() => EenHeleDureFunctie());

[Gamebuster]

.oisyn schreef op maandag 24 januari 2011 @ 14:45:
Je zou ook van delegates gebruik kunnen maken.

C#:

Logger.Log(() => EenHeleDureFunctie());

aparte syntax. Ik ken die => operator alleen van array's in PHP.

Ik begrijp dat ^dat zoiets als _vdit is?

JavaScript:

console.log(function(){EenHeleDureFunctie();});

Even opgezocht:
http://msdn.microsoft.com/en-us/library/bb311046.aspx

Best handig. Jammer dat Java niet zoiets kan.

Hoe meer ik lees over C#, hoe leuker die taal lijkt te zijn. Helaas heb ik hier niet eens een fatsoenlijke windows computer staan; ik en Windows gaan niet samen. Heb er jaren mee gewerkt maar sinds ik over was gegaan op Linux Ubuntu vind ik Windows een ramp om mee te werken.

[ Voor 20% gewijzigd door Gamebuster op 24-01-2011 14:57 ]

[Verwijderd]

Gamebuster schreef op maandag 24 januari 2011 @ 14:53:
Hoe meer ik lees over C#, hoe leuker die taal lijkt te zijn. Helaas heb ik hier niet eens een fatsoenlijke windows computer staan; ik en Windows gaan niet samen. Heb er jaren mee gewerkt maar sinds ik over was gegaan op Linux Ubuntu vind ik Windows een ramp om mee te werken.

Het Mono Project zorgt ervoor dat je C# kan compilen op *NIX systemen

[Avalaxy]

Verwijderd schreef op maandag 24 januari 2011 @ 15:04:
[...]


Het Mono Project zorgt ervoor dat je C# kan compilen op *NIX systemen

Ja maar dan mis je Visual Studio.

Gewoon met Windows leren werken, 10x makkelijker dan Linux

[Sebazzz]

Anders draai je een Windows VM, dan kan je geniet van Visual Studio en de applicaties gewoon in Mono op Linux draaien.

Ik vind dat Microsoft wat meer zou moeten doen aan het porten van .NET naar Linux en Mac OS X. .NET is als het niet op cross-platform aankomt een enorme concurrent voor Java, ik denk zelfs dat het Java gewoon verplet, als MS dat nadeel van .NET ook weghaalt, hebben ze een echt goed concurrerend product.

[ Voor 33% gewijzigd door Sebazzz op 24-01-2011 15:24 ]

[Davio]

Ik heb in het verleden ook meerdere malen gevloekt over Windows danwel elk ander willekeurig product van Microsoft, maar Visual Studio en C# .NET werken toch echt prima voor mij.

[Gamebuster]

Ik maak ook weer wat mee: mijn macbook crasht zowaar! Nog nooit eerder meegemaakt





Beeld flikkerde, macbook werd gloeiend heet, muziek speelde nog, muis kon nog bewegen maar niets leek erop te reageren, toetsenbord reageerde niet (play/pauze van muziek werkte niet)

Het begon met een safari-venstertje met een flash-based videochat (zie 1e foto). Paar seconde later flikkerde het beeld enorm (zie 2e foto). De muis was zichtbaar over het zwarte; het hele beeld flikkerde, behalve de muis-cursor.

Het beeld was daadwerkelijk half-zwart; de zwarte balk ging snel van beneden naar boven en is dus geen bijwerking van de fotocamera.

Na reboot (uitknop ingedrukt houden...) alles weer normaal.

Wel vreemd dat ik dit nu heb meegemaakt in ieder OS:
Ik heb het gehad in Windows Vista tijdens experimenteren met CUDA
ik heb het gehad in Linux Ubuntu tijdens experimenteren met OpenGL
En ik heb het nu gehad in Mac OS X tijdens het internetten, vermoedelijk door flash

-en ook nog alle3 keren op een volledig ander systeem

[ Voor 50% gewijzigd door Gamebuster op 24-01-2011 15:40 ]

[Sebazzz]

.oisyn schreef op maandag 24 januari 2011 @ 14:45:
Je zou ook van delegates gebruik kunnen maken.

C#:

Logger.Log(() => EenHeleDureFunctie());

Of het ConditionalAttribute, en dan hoef je niet moeilijk te doen met delegates

[.oisyn]

Worden de argumenten dan niet nog steeds geëvalueerd?

[Gamebuster]

Sebazzz schreef op maandag 24 januari 2011 @ 15:21:
Anders draai je een Windows VM, dan kan je geniet van Visual Studio en de applicaties gewoon in Mono op Linux draaien.

Ik vind dat Microsoft wat meer zou moeten doen aan het porten van .NET naar Linux en Mac OS X. .NET is als het niet op cross-platform aankomt een enorme concurrent voor Java, ik denk zelfs dat het Java gewoon verplet, als MS dat nadeel van .NET ook weghaalt, hebben ze een echt goed concurrerend product.

Ik denk het ook. Als MS unix-systemen gaat supporten ga ik direct aan de slag met .NET. Ik voel me niet echt aangetrokken tot Mono; geen zin in virtual machine, puur om code te schrijven (zou VS ook via Wine o.i.d. werken?)

[Woy]

.oisyn schreef op maandag 24 januari 2011 @ 15:49:
Worden de argumenten dan niet nog steeds geëvalueerd?

Volgens mij word alleen de daadwerkelijk call niet uitgevoerd, maar worden de argumenten wel geëvalueerd.

[.oisyn]

Net even getest, de argumenten worden dus niet geëvalueerd.

C#:

namespace ConsoleApplication1
{
    class Program
    {
        [ConditionalAttribute("DEBUG")]
        static void Foo(int i)
        {
            Console.WriteLine("Foo()");
        }

        static int Bar()
        {
            Console.WriteLine("Bar()");
            return 3;
        }

        static void Main(string[] args)
        {
            Foo(Bar());
        }
    }
}

geeft helemaal geen output in release builds.

[Sebazzz]

ConditionalAttribute wordt ook gebruikt voor Debug.Assert en andere methodes in de Debug class.

Gamebuster schreef op maandag 24 januari 2011 @ 15:49:
[...]

Ik voel me niet echt aangetrokken tot Mono; geen zin in virtual machine, puur om code te schrijven

Dan gebruik je toch MonoDevelop? Werkt ook prima, al vind ik VS net wat prettiger

(zou VS ook via Wine o.i.d. werken?)

Nope.

[Woy]

.oisyn schreef op maandag 24 januari 2011 @ 15:53:
Net even getest, de argumenten worden dus niet geëvalueerd.

Ik had het idd ook even getest, en natuurlijk hetzelfde resultaat. Op zich ook de meest handige implementatie zo natuurlijk.

[Sebazzz]

C#:

internal class Program
{
    // Methods
    private static int Bar()
    {
        Console.WriteLine("Bar()");
        return 3;
    }

    [Conditional("DEBUG")]
    private static void Foo(int i)
    {
        Console.WriteLine("Foo()");
    }

    private static void Main(string[] args)
    {
    }
}

Disassembled wordt het dit in release mode, in debug mode veranderd er niets.

[Gamebuster]

Waarom haalt-ie die Foo()-method ook niet weg als die toch nooit gebruikt kan worden in de release-build?

[D-Raven]

Sebazzz schreef op maandag 24 januari 2011 @ 15:21:
Anders draai je een Windows VM, dan kan je geniet van Visual Studio en de applicaties gewoon in Mono op Linux draaien.

Ik vind dat Microsoft wat meer zou moeten doen aan het porten van .NET naar Linux en Mac OS X. .NET is als het niet op cross-platform aankomt een enorme concurrent voor Java, ik denk zelfs dat het Java gewoon verplet, als MS dat nadeel van .NET ook weghaalt, hebben ze een echt goed concurrerend product.

Valt best mee hoor. Ik wou hierop reageren met iets in de trant dat het geen prio heeft bij MS en dat achterhaalt wordt. Maar ik ben positief verrast met de compatibility list. Deze is toch best indrukwekkend. Dingen die momenteel niet ondersteund worden zijn allemaal met goede design overwegingen prima op te lossen.

Bijvoorbeeld dat WPF niet ondersteund wordt, tjah dat is jammer, maar er zijn genoeg alternatieve UI frameworks beschikbaar.
Gelimiteerde WCF, tjah vervelend, maar ook niet onoverkomelijk.
Geen WF, who cares, ik in ieder geval niet. Iedere versie is weer compleet anders, ik ga daar geen tijd meer aan verspillen in ieder geval.

[Sebazzz]

Gamebuster schreef op maandag 24 januari 2011 @ 16:13:
Waarom haalt-ie die Foo()-method ook niet weg als die toch nooit gebruikt kan worden in de release-build?

Waarom zou hij dat moeten doen? Een compiler kan niet zomaar in je codebase gaan knippen als hij denkt dat een methode niet gebruikt wordt.

[Caelorum]

Sebazzz schreef op maandag 24 januari 2011 @ 16:25:
[...]

Waarom zou hij dat moeten doen? Een compiler kan niet zomaar in je codebase gaan knippen als hij denkt dat een methode niet gebruikt wordt.

Waarom niet? Het is niet alsof je de code-files worden gewijzigd ofzo..

*edit*
och.. bedenk me nu dat dat met reflection en externe aanroepen wel eens vervelend kan worden.

[ Voor 14% gewijzigd door Caelorum op 24-01-2011 16:49 ]

[Woy]

Sebazzz schreef op maandag 24 januari 2011 @ 16:25:
[...]

Waarom zou hij dat moeten doen? Een compiler kan niet zomaar in je codebase gaan knippen als hij denkt dat een methode niet gebruikt wordt.

Ik vind het eigenlijk nog niet zo'n gek idee. Blijkbaar kan de compiler nu ook knippen aan de caller kant, waarom zou dat aan de callee kant niet kunnen? Je geeft immers expliciet aan dat die methode conditioneel is!

Ik kan me dan wel voorstellen dat er eventueel een extra optie is om aan te geven of alleen de aanroepen van de methode verwijderd moeten worden, of ook de methode zelf.

[ Voor 15% gewijzigd door Woy op 24-01-2011 16:53 ]

[Sebazzz]

Woy schreef op maandag 24 januari 2011 @ 16:52:
[...]

Je geeft immers expliciet aan dat die methode conditioneel is!

Nee, je geeft aan dat het aanroepen van de methode conditioneel is. Dat is een verschil.

[Woy]

Sebazzz schreef op maandag 24 januari 2011 @ 16:58:
[...]
Nee, je geeft aan dat het aanroepen van de methode conditioneel is. Dat is een verschil.

Zoals het nu gedefinieerd is ( zowel in de documentatie als de implementatie ) wel ja, maar als het aanroepen conditioneel is, dan zou het ook niet gek zijn om er mee aan te geven dat de methode zelf conditioneel is.

[YopY]

Salandur schreef op maandag 24 januari 2011 @ 11:53:
Het probleem van het loggen met een if constructie is dat dit erg nadelig is voor je code coverage.

Trui, ik vindt het ook best wel lelijk en zou het liever gewoon helemaal niet zien hoeven.

Op het moment dat je dit goed kan wegstoppen dan levert het een voordeel op. Door het toevoegen van varargs aan java 5 kan je het mooi wegstoppen in de aanroep van de log methode en dan is de hele if ook overbodig geworden. Ik geloof dat SLF4J daar ook al rekening mee houdt

Java:

LOG.fine("bericht %s", duurObject)

Het enige probleem is je duurObject.toString(), die toString() zou niet duur mogen zijn!

Da's niet eens zo'n verkeerd idee / concept, even onthouden.

En ja, toString() hoeft niet duur te zijn, maar het is wel een performance hit die, hoe meer je logt, hoe groter wordt. Zelfs een optimale toString heeft een objectinstantiatie, een aantal functieaanroepen en een operatie die alles aan elkaar knoopt. Een lazy-loading toString die zijn stringrepresentatie slechts éénmaal aanmaakt en onthoudt (dat kan met immutable objects) heeft geheugengebruik.

iig, punt is, hoe triviaal iets ook is, het is nog altijd beter om het niet aan te roepen dan wel en er niks mee te doen.

quote: Woy

Is het niet handiger om die check niet op de plek van je logging te doen, maar gewoon in je logger? Dat maakt je code wel een stuk overzichtelijker.

Dat gebeurt idd, echter voordat je programma op die controle binnen die functie komt heeft hij al de toString() aangeroepen en het resultaat aan het te loggen stukje tekst geplakt. Neem ik aan, tenminste, voor hetzelfde is de JIT slim genoeg om te zien dat er uiteindelijk niks met dat stukje tekst gedaan wordt en skipt hij die hele aanroep.

Wat Janoz zegt, dus .

En disclaimer, natuurlijk was het maar een voorbeeld, in de praktijk gebruik je alleen logging voor debugger-loze debugging en voor relevante informatie. Had het laatst toegepast om om een functie genaamd 'prettyPrint()' te gaan, en prettyPrint() vertrouw ik niet mbt performance .

[Woy]

YopY schreef op maandag 24 januari 2011 @ 21:00:
[...]
Da's niet eens zo'n verkeerd idee / concept, even onthouden.

En ja, toString() hoeft niet duur te zijn, maar het is wel een performance hit die, hoe meer je logt, hoe groter wordt. Zelfs een optimale toString heeft een objectinstantiatie, een aantal functieaanroepen en een operatie die alles aan elkaar knoopt. Een lazy-loading toString die zijn stringrepresentatie slechts éénmaal aanmaakt en onthoudt (dat kan met immutable objects) heeft geheugengebruik.

iig, punt is, hoe triviaal iets ook is, het is nog altijd beter om het niet aan te roepen dan wel en er niks mee te doen.

Iets met premature optimization...

Ik snap best dat er situaties kunnen voorkomen waar je het wel wil toepassen, maar doe het dan alleen in die situaties. Ik zou altijd leesbaarheid van de code voorop stellen...

Ik heb nog steeds het idee dat het een uitzondering is dat er een performance probleem ontstaat door een logging call, en de daarbij behorende formatting. Ik heb veel vaker meegemaakt dat de File IO die bij de daadwerlijke logging implementatie een bottleneck is, maar dat valt automatisch weg als je de logging uitzet.

[B-Man]

YopY schreef op maandag 24 januari 2011 @ 21:00:
[...]


Da's niet eens zo'n verkeerd idee / concept, even onthouden.

En ja, toString() hoeft niet duur te zijn, maar het is wel een performance hit die, hoe meer je logt, hoe groter wordt. Zelfs een optimale toString heeft een objectinstantiatie, een aantal functieaanroepen en een operatie die alles aan elkaar knoopt. Een lazy-loading toString die zijn stringrepresentatie slechts éénmaal aanmaakt en onthoudt (dat kan met immutable objects) heeft geheugengebruik.

iig, punt is, hoe triviaal iets ook is, het is nog altijd beter om het niet aan te roepen dan wel en er niks mee te doen.

[...]

Een van de sterke punten van SLF4J is nu juist dat die toString() alleen aangeroepen wordt als logging op het gevraagde niveau ingeschakeld is. In de javadoc zie je ook dat bijvoorbeeld Logger.error() een of twee Object argumenten accepteert. In de te loggen String gebruik je dan placeholders ({}) ipv format codes (%s), en je bespaart toString() calls. Zie ook http://www.slf4j.org/faq.html#logging_performance.

Ik heb het nooit zelf vergeleken middels een profiler, maar aangezien je hier bij gebruik van SLF4J automatisch gebruik van maakt is alle winst natuurlijk mooi meegenomen.

[Gamebuster]

JavaScript:

    this.checkPassword = function(passhash, cb)
    {
        this._database.query("SELECT COUNT(1) AS count FROM users "
                +"WHERE id = ? AND password = UNHEX(?) LIMIT 1",
        [this.getId(), passhash],
        function(results)
        {
            cb(results.length > 0);
        });
    }

Zoek de bug.

results.length is 1, zelfs als COUNT(1) 0 is. this.checkPassword zou dus iedere wachtwoord-hash accepteren.

Maar goed dat ik 'm tegenkwam voordat de code in gebruik werd genomen

[ Voor 6% gewijzigd door Gamebuster op 25-01-2011 03:45 ]

[Snake]

Ik vind het feit dat je via JavaScript SQL doorstuurt een grotere bug?

[Lye]

Snake schreef op dinsdag 25 januari 2011 @ 08:32:
Ik vind het feit dat je via JavaScript SQL doorstuurt een grotere bug?

Waarom? Als je Javascript server-side draait lijkt het me eigenlijk vrij logisch

[Alex)]

Snake schreef op dinsdag 25 januari 2011 @ 08:32:
Ik vind het feit dat je via JavaScript SQL doorstuurt een grotere bug?

Psst, Node JS

[CodeCaster]

Ik zal het wel weer niet snappen hoor... In Delphi onderhoud aan het doen aan een stuk of vijftig forms die erg veel code copypasten. Dus ik heb een base form gemaakt met enkel code aan de achterkant en een stuk code om alle forms te kunnen tonen (je geeft enkel de klasse mee van het form wat je wil tonen, de rest van de aanroepen die gecopypasted waren gebeuren verderop in deze methode):

Delphi:

procedure AanroependForm.ShowForm(InstanceClass: TComponentClass; foo, bar, baz: integer);
var
  formInstance : TBasisForm;
begin
  try
    Application.CreateForm(InstanceClass, formInstance);

En dan krijg ik tijdens het runnen een access violation om m'n oren op regel 6.

Terug de manual in maar weer.

Ah, fixed. Gewoon een (niet-geïnitialiseerde) reference meegeven van het type van de uiteindelijke form.

Delphi:

procedure AanroependForm.ShowForm(InstanceClass: TComponentClass; var Reference; foo, bar, baz: integer);
var
  baseReference: TBasisForm;
begin
  try
    Application.CreateForm(InstanceClass, Reference);
  // Knip
  baseReference := TBasisForm(Reference);
  basisForm.Foo := foo;

Werkt. Dan is Reference.Foo gelijk aan foo.

[ Voor 37% gewijzigd door CodeCaster op 25-01-2011 13:21 ]

[alienfruit]

Jeej! Delphi Ik ga maar weer verder klungelen in JavaScript

[ Voor 62% gewijzigd door alienfruit op 25-01-2011 12:27 ]

[roy-t]

Na voor de zoveelste keer gezeik met (Tortoise)SVN nu eindelijk maar eens (Tortoise)Hg (mercurial) geinstalleerd. Wert al meteen lekker met de duidelijkere ignore filter en repo browsers. Nu hopen dat ik niet weer 2 uur werk kwijt raak door wat bestanden te verplaatsen buiten het SCM systeem om .

[Woy]

roy-t schreef op dinsdag 25 januari 2011 @ 12:54:
Na voor de zoveelste keer gezeik met (Tortoise)SVN nu eindelijk maar eens (Tortoise)Hg (mercurial) geinstalleerd. Wert al meteen lekker met de duidelijkere ignore filter en repo browsers. Nu hopen dat ik niet weer 2 uur werk kwijt raak door wat bestanden te verplaatsen buiten het SCM systeem om .

Klinkt meer als een user-error

[defcon84]

ik had ook al een paar keer een probleem met tortoisesvn, maar ben gewoon terug gegaan naar een vorige versie, en blijf voorlopig daarop tot ik een anders issue tegenkom

[FragFrog]

Woy schreef op dinsdag 25 januari 2011 @ 13:01:
Klinkt meer als een user-error

Sterker nog, je kan ook bestanden verplaatsen binnen een SVN repo zonder SCM, ook als je TortoiseSVN als client gebruikt. Commit doen, bij de plek waar't bestand vandaan komt het verwijderde bestand aanvinken als verwijdert, op de plek waar'ie naartoe is gegaan aanvinken als nieuw en klaar. Dat gaat alleen fout als je op die manier een bestand verplaatst waarvan je niet de laatste versie hebt, want dan krijg je inderdaad merge conflicten. Ook geen ramp, cleanup + update doen en je bestand staat er weer

Hoe je in hemelsnaam door een merge conflict twee uur werk kwijt bent geraakt is me dan ook een raadsel, of je moet al haast de .svn files mee gaan verplaatsen en het vervolgens in je repo browser weggooien oid

* FragFrog had ooit een collega die het voor elkaar gekregen heeft om .svn bestanden te comitten

[Ryur]

FragFrog schreef op dinsdag 25 januari 2011 @ 15:47:
[...]
* FragFrog had ooit een collega die het voor elkaar gekregen heeft om .svn bestanden te comitten

Hmm.. gebeurd bij ons op school wel regelmatig. Dan wordt ik echt boos.
Maar nu gebruik ik (gelukkig) Git/Hg

[Woy]

GoTCoast schreef op dinsdag 25 januari 2011 @ 16:26:
[...]


Hmm.. gebeurd bij ons op school wel regelmatig. Dan wordt ik echt boos.
Maar nu gebruik ik (gelukkig) Git/Hg

Maar Git/Hg hebben dan toch hetzelfde probleem? Als je daar de verkeerde bestanden, of te weinig, gaat versionen, dan gaat het ook mis.

[jip_86]

alienfruit schreef op dinsdag 25 januari 2011 @ 12:26:
Jeej! Delphi Ik ga maar weer verder klungelen in JavaScript

Hier is nu een traject aan de gang om in ieder geval de presentatie kant van Delphi for .Net om te zetten naar WPF.
Het is niet alles dus, maar je moet ergens beginnen

[alienfruit]

Aah, je stapt niet over naar Delphi Prism?

[defiant]

Over TortoiseSVN gesproken, ik kwam deze bug gisteren tegen:
64-bit TortoiseSVN on Windows 7 says “file or directory is corrupted and unreadable” then runs chkdsk

Bij mij is het een combinatie van Security Essentials en Windows 7 (64bit), als ik Security Essentials uitzet werkt het gewoon, maar ik heb de hotfix in de 1e comment voor de zekerheid toch maar geïnstalleerd.

[roy-t]

FragFrog schreef op dinsdag 25 januari 2011 @ 15:47:
[...]



Sterker nog, je kan ook bestanden verplaatsen binnen een SVN repo zonder SCM, ook als je TortoiseSVN als client gebruikt. Commit doen, bij de plek waar't bestand vandaan komt het verwijderde bestand aanvinken als verwijdert, op de plek waar'ie naartoe is gegaan aanvinken als nieuw en klaar. Dat gaat alleen fout als je op die manier een bestand verplaatst waarvan je niet de laatste versie hebt, want dan krijg je inderdaad merge conflicten. Ook geen ramp, cleanup + update doen en je bestand staat er weer

Hoe je in hemelsnaam door een merge conflict twee uur werk kwijt bent geraakt is me dan ook een raadsel, of je moet al haast de .svn files mee gaan verplaatsen en het vervolgens in je repo browser weggooien oid

* FragFrog had ooit een collega die het voor elkaar gekregen heeft om .svn bestanden te comitten

Ik had binnen VS een map hernoemd (even voor het verhaal van A->B) en daarna was ik verder gaan werken met bestanden in die map. Ik deed daarna een commit van de root directory van de repository. Hierop wilde SVN eerst update. Toen onstond er een conflict. Ik heb toen de map A weggegooid (kwam van update zat oud spul in) en B weer A genoemd. Toen weer gecommit. Toen zat alles in de knoop . Toirtoise had een lock dus ik kon geen nieuwe commit doen. Ook geen nieuwe update en cleanen en het lock verwijderen wilde ook al niet . Toen een nieuwe checkout gedaan en die meteen weer geprobeerd te comitten maar zelfs dat wilde niet.

Anyway hoewel dit deels user-error was natuurlijk was het voor mij wel het laatste zetje om eens naar iets anders te kijken. Ik werd ook ziek van dat je niet mappen kon c/p-en vanuit een map die onder version control stond. Elke keer exporten was gewoon onhandig. Ook kan Hg beter omgaan met dingen hernoemen in VS en dan gewoon vanaf root comitten.

Dus tsja vandaar.


Verder random dev gerelateerde link: (If VS had achievements) http://www.blog.whiletrue.com/vs-achieve.html

[Verwijderd]

Je wou dus eigenlijk een map hernoemen? Maar in jouw wereld staat dit gelijk aan copy pasten?

Hernoemen kan SVN gewoon, TortoiseSVN heeft daar ook ondersteuning voor. Zo lang je het maar via de tool doet, dus niet lomp de hele map kopieren (wat ook nooit kan werken aangezien de submappen dan niet snappen waar in de tree ze zitten).

[YopY]

FragFrog schreef op dinsdag 25 januari 2011 @ 15:47:
* FragFrog had ooit een collega die het voor elkaar gekregen heeft om .svn bestanden te comitten

* YopY ook, . Maar idd, SVN is soms best wel suboptimaal om mee te werken, je moet eigenlijk leren ermee om te gaan op een manier waar je het niet stuk mee maakt. Bestandje verwijderen? Niet gewoon delete doen, nee, SVN delete anders gaat het mis.

En bestanden verplaatsen? Rechtermuisklik-drag naar nieuwe map, loslaten, 'SVN move here'. Logisch? Nee . Had al eens voorgesteld om eens te kijken naar alternatieve systemen (git / mercurail), maar dat werd snel verworpen omdat zowel wijzelf als de derde partijen die ook eens willen kijken er geen ervaring mee hadden (en dan vooral die derde partijen).

[PrisonerOfPain]

Verwijderd schreef op dinsdag 25 januari 2011 @ 21:00:
Je wou dus eigenlijk een map hernoemen? Maar in jouw wereld staat dit gelijk aan copy pasten?

Hernoemen kan SVN gewoon, TortoiseSVN heeft daar ook ondersteuning voor. Zo lang je het maar via de tool doet, dus niet lomp de hele map kopieren (wat ook nooit kan werken aangezien de submappen dan niet snappen waar in de tree ze zitten).

TortoiseSVN zou gewoon naar de NTFS change journal kunnen luisteren en de USN_REASON_RENAME_OLD_NAME en USN_REASON_RENAME_NEW_NAME records af kunnen handelen om vervolgens een svn rename commando te doen.

[alex3305]

Verwijderd schreef op dinsdag 25 januari 2011 @ 21:00:
Je wou dus eigenlijk een map hernoemen? Maar in jouw wereld staat dit gelijk aan copy pasten?

Hernoemen kan SVN gewoon, TortoiseSVN heeft daar ook ondersteuning voor. Zo lang je het maar via de tool doet, dus niet lomp de hele map kopieren (wat ook nooit kan werken aangezien de submappen dan niet snappen waar in de tree ze zitten).

Hernoemen werkt niet volledig. Je kunt namelijk in SVN niet het hoofdlettergebruik wijzigen in de bestandsnaam.

code:

code.cs > Code.cs

gaat niet werken.

[NetForce1]

YopY schreef op dinsdag 25 januari 2011 @ 21:14:
[...]


* YopY ook, . Maar idd, SVN is soms best wel suboptimaal om mee te werken, je moet eigenlijk leren ermee om te gaan op een manier waar je het niet stuk mee maakt. Bestandje verwijderen? Niet gewoon delete doen, nee, SVN delete anders gaat het mis.

En bestanden verplaatsen? Rechtermuisklik-drag naar nieuwe map, loslaten, 'SVN move here'. Logisch? Nee . Had al eens voorgesteld om eens te kijken naar alternatieve systemen (git / mercurail), maar dat werd snel verworpen omdat zowel wijzelf als de derde partijen die ook eens willen kijken er geen ervaring mee hadden (en dan vooral die derde partijen).

Een fatsoenlijke ondersteuning in je IDE helpt al wel hoor, dan kun je gewoon naar hartelust moven, renamen, etc. (mits de target ook in svn zit). Tuurlijk kan er dan nog steeds wat mis gaan, maar het werkt wel een stuk fijner.

[Freeaqingme]

alex3305 schreef op dinsdag 25 januari 2011 @ 21:39:
[...]

Hernoemen werkt niet volledig. Je kunt namelijk in SVN niet het hoofdlettergebruik wijzigen in de bestandsnaam.

code:

code.cs > Code.cs

gaat niet werken.

Nu is 't al even geleden dat ik svn gebruikt heb (tegenwoordig alleen nog maar git/bzr), maar dat lijkt me meer een windows issue waarbij windows voor de buitenwereld caseinsensitive is dan een issue met svn?

[Verwijderd]

Inderdaad, dat is een beperking van tortoiseSVN onder Windows, niet zozeer van SVN zelf.

Onder Windows kun je ook een file niet hernoemen als je alleen een wijziging in de case hebt. Staat volledig los van SVN verder dus.

[ Voor 43% gewijzigd door Verwijderd op 25-01-2011 22:15 ]

[Snake]

Verwijderd schreef op dinsdag 25 januari 2011 @ 22:15:
Inderdaad, dat is een beperking van tortoiseSVN onder Windows, niet zozeer van SVN zelf.

Onder Windows kun je ook een file niet hernoemen als je alleen een wijziging in de case hebt. Staat volledig los van SVN verder dus.

Want hier kan ik gewoon een file renamen door enkel de case te veranderen. Windows 7. En SVN blokkeerd het. Dus SVN zelf ondersteund geen solely casing change renaming.

[FragFrog]

roy-t schreef op dinsdag 25 januari 2011 @ 20:57:
Ik heb toen de map A weggegooid (kwam van update zat oud spul in) en B weer A genoemd. Toen weer gecommit. Toen zat alles in de knoop .

dat is wel een goede manier om SVN stuk te maken ja

Overigens kun je met TortoiseSVN ook gewoon een folder renamen Al zit daar inderdaad wel de beperking in dat je niet alleen case kan veranderen, maargoed, een extra rename erbij comitten en dan is dat ook wel weer opgelost. 't blijft wel een lichtelijk bewerkelijk systeem, mits je er voorzichtig mee omgaat werkt het echt perfect, doe je zaken net even anders dan hoort gaat't nog wel eens stuk. Misschien ook maar eens kijken naar Mercurial, hoor er goede verhalen over

[Cloud]

roy-t schreef op dinsdag 25 januari 2011 @ 20:57:
[...]

Verder random dev gerelateerde link: (If VS had achievements) http://www.blog.whiletrue.com/vs-achieve.html

Daar kon ik toch wel even flink om lachen

Snake schreef op dinsdag 25 januari 2011 @ 22:26:
[...]

Want hier kan ik gewoon een file renamen door enkel de case te veranderen. Windows 7. En SVN blokkeerd het. Dus SVN zelf ondersteund geen solely casing change renaming.

Yep werkt prima onder W7, maar er staat me iets van mij dat ik er ook wel eens last van gehad heb. Onder Vista vermoed ik

FragFrog schreef op dinsdag 25 januari 2011 @ 22:57:
[...]

dat is wel een goede manier om SVN stuk te maken ja

Yep hier ook al eens meegemaakt! Ik had een webreference die ik wilde updaten, maar keek met m'n stomme hoofd voorbij de Update optie in het context menu. Dus ik dacht handig te zijn en mik die reference (is op het filesystem gewoon een folder) weg en voeg hem opnieuw toe... Uiteindelijk wel op te lossen, maar dat soort dingen gebeuren altijd ongelegen

Overigens kun je met TortoiseSVN ook gewoon een folder renamen Al zit daar inderdaad wel de beperking in dat je niet alleen case kan veranderen, maargoed, een extra rename erbij comitten en dan is dat ook wel weer opgelost. 't blijft wel een lichtelijk bewerkelijk systeem, mits je er voorzichtig mee omgaat werkt het echt perfect, doe je zaken net even anders dan hoort gaat't nog wel eens stuk.

Hier werkt TortoiseSVN ook prima maar inderdaad, je moet met sommige zaken wel een beetje rekening houden.

[alex3305]

Freeaqingme schreef op dinsdag 25 januari 2011 @ 22:01:
[...]


Nu is 't al even geleden dat ik svn gebruikt heb (tegenwoordig alleen nog maar git/bzr), maar dat lijkt me meer een windows issue waarbij windows voor de buitenwereld caseinsensitive is dan een issue met svn?

Verwijderd schreef op dinsdag 25 januari 2011 @ 22:15:
Inderdaad, dat is een beperking van tortoiseSVN onder Windows, niet zozeer van SVN zelf.

Onder Windows kun je ook een file niet hernoemen als je alleen een wijziging in de case hebt. Staat volledig los van SVN verder dus.

Snake schreef op dinsdag 25 januari 2011 @ 22:26:
[...]

Want hier kan ik gewoon een file renamen door enkel de case te veranderen. Windows 7. En SVN blokkeerd het. Dus SVN zelf ondersteund geen solely casing change renaming.

Of het nu ligt aan SVN of Windows maakt mij eigenlijk niet echt heel veel uit. Het kan af en toe wel bloody irritant zijn en vooral als je aan projecten werkt welke wel case-afhankelijk zijn.

[Woy]

alex3305 schreef op dinsdag 25 januari 2011 @ 23:19:
[...]


[...]


[...]

Of het nu ligt aan SVN of Windows maakt mij eigenlijk niet echt heel veel uit. Het kan af en toe wel bloody irritant zijn en vooral als je aan projecten werkt welke wel case-afhankelijk zijn.

Dat probleem heb ik al zo vaak onder windows gehad, dat ik al de gewoonte heb om gewoon 2 maal te renamen. Eerste gewoon naar een andere naam en dan naar de juiste case. Dat is inderdaad gewoon een windows probleem. Aan de posts hierboven te zien hebben ze dat in windows 7 eindelijk opgelost.

Verder herken ik de renaming/moving/etc. problemen wel, maar dat is volgens mij niet SCM afhankelijk want ik heb het eigenlijk bij alle SCM systemen. Een nadeel van SVN is dan alleen dat er in elke map een .svn map komt zodat je niet zo makkelijk kunt "exporten", maar als je daar eenmaal aan gewend bent heb ik er niet zo veel problemen mee. Gewoon met de rechter muisknop slepen en dan export. Of gewoon copy/paste en dan alle .svn mapjes searchen en weggooien.

[Cartman!]

De rename/delete uit tortoise herken ik niet, ik rename dit gewoon in explorer dan wel m'n IDE en tortoise pikt dit netjes op. Het enige wat idd. problemen geeft is een mapje hernoemen van A naar B en dan een nieuwe map A maken. Ik commit dan gewoon tussentijds ff en dan werkt t ook goed.

Exporten doe ik soms door een rar/zip te maken die tijdens het inpakken .svn ignored, dan extract en ben je er ook. Is meestal sneller bij mij dan een export op een of andere manier.

[Alex)]

Wie moest er hier nog gedwongen met Visual SourceScheef werken? Hier wat marketingpraat over waarom je dat zou moeten doen.

[Snake]

Woy schreef op dinsdag 25 januari 2011 @ 23:45:
[...]

Dat probleem heb ik al zo vaak onder windows gehad, dat ik al de gewoonte heb om gewoon 2 maal te renamen. Eerste gewoon naar een andere naam en dan naar de juiste case. Dat is inderdaad gewoon een windows probleem. Aan de posts hierboven te zien hebben ze dat in windows 7 eindelijk opgelost.

In Windows 7 wel. Maar SVN op zich ondersteund het niet.

[Haan]

Nieuwe workstation is besteld en zal binnenkort op m'n bureau staan
Belangrijkste specs:
- Core i7 870 processor
- Intel X25 SSD als systeemschijf (aangevuld met 2TB opslag)
- 8 GB RAM
- 2x Samsung 2443 monitor
- Radeon 6850 videokaart (geen idee waarom die er in zit, maar het scheen goedkoper te zijn dan een simpel kaartje)

In ieder geval En 100x beter dan een laptop van ruim jaar oud..

[Alex)]

Die Radeon heb je natuurlijk nodig voor de grafische performance van Visual Studio 2010

[roy-t]

Verwijderd schreef op dinsdag 25 januari 2011 @ 21:00:
Je wou dus eigenlijk een map hernoemen? Maar in jouw wereld staat dit gelijk aan copy pasten?

Hernoemen kan SVN gewoon, TortoiseSVN heeft daar ook ondersteuning voor. Zo lang je het maar via de tool doet, dus niet lomp de hele map kopieren (wat ook nooit kan werken aangezien de submappen dan niet snappen waar in de tree ze zitten).

Nee ik denk dat je twee dingen die vertelde door elkaar haalde.

FragFrog schreef op dinsdag 25 januari 2011 @ 22:57:
[...]

dat is wel een goede manier om SVN stuk te maken ja

Overigens kun je met TortoiseSVN ook gewoon een folder renamen Al zit daar inderdaad wel de beperking in dat je niet alleen case kan veranderen, maargoed, een extra rename erbij comitten en dan is dat ook wel weer opgelost. 't blijft wel een lichtelijk bewerkelijk systeem, mits je er voorzichtig mee omgaat werkt het echt perfect, doe je zaken net even anders dan hoort gaat't nog wel eens stuk. Misschien ook maar eens kijken naar Mercurial, hoor er goede verhalen over

Ah ja ik weet dat je via Tortoise gewoon bestanden kan hernoemen en zelfs de rechtermuisknop drag functie kende ik, maar ik had er even niet bij stil gestaan omdat ik dit alles in de IDE had gedaan en tsja, toen deed ik nog een paar dingen heel erg fout .

[defcon84]

jip_86 schreef op dinsdag 25 januari 2011 @ 19:37:
[...]

Hier is nu een traject aan de gang om in ieder geval de presentatie kant van Delphi for .Net om te zetten naar WPF.
Het is niet alles dus, maar je moet ergens beginnen

haha wat een vooruitgang

defiant schreef op dinsdag 25 januari 2011 @ 20:14:
Over TortoiseSVN gesproken, ik kwam deze bug gisteren tegen:
64-bit TortoiseSVN on Windows 7 says “file or directory is corrupted and unreadable” then runs chkdsk

Bij mij is het een combinatie van Security Essentials en Windows 7 (64bit), als ik Security Essentials uitzet werkt het gewoon, maar ik heb de hotfix in de 1e comment voor de zekerheid toch maar geïnstalleerd.

ik had meer problemen met de shell integratie van win7 x64 en met de folder icons..

Haan schreef op woensdag 26 januari 2011 @ 08:46:
Nieuwe workstation is besteld en zal binnenkort op m'n bureau staan
Belangrijkste specs:
- Core i7 870 processor
- Intel X25 SSD als systeemschijf (aangevuld met 2TB opslag)
- 8 GB RAM
- 2x Samsung 2443 monitor
- Radeon 6850 videokaart (geen idee waarom die er in zit, maar het scheen goedkoper te zijn dan een simpel kaartje)

In ieder geval En 100x beter dan een laptop van ruim jaar oud..

haha lijkt veel op men pctje thuis :-)
vooral die SSD ga je leuk vinden

[alex3305]

Haan schreef op woensdag 26 januari 2011 @ 08:46:
Nieuwe workstation is besteld en zal binnenkort op m'n bureau staan
Belangrijkste specs:
- Core i7 870 processor
- Intel X25 SSD als systeemschijf (aangevuld met 2TB opslag)
- 8 GB RAM
- 2x Samsung 2443 monitor
- Radeon 6850 videokaart (geen idee waarom die er in zit, maar het scheen goedkoper te zijn dan een simpel kaartje)

In ieder geval En 100x beter dan een laptop van ruim jaar oud..

Alleen ben ik benieuwd waarom je niet voor een Core i7 2600 of Core i5 2500 bent gegaan?

[.oisyn]

Ik gok dat hij het systeem niet zelf heeft uitgezocht.

[Woy]

roy-t schreef op woensdag 26 januari 2011 @ 09:13:
[...]
maar ik had er even niet bij stil gestaan omdat ik dit alles in de IDE had gedaan en tsja

Maar als je het in je IDE doet gaat het toch sowieso goed? Of heb je geen SVN plugin in VS draaien? Als ik iets in Visual Studio wijzig, dan gaat het bij mij in ieder geval automatisch goed.

@nieuwe pc: Ik moet binnenkort eigenlijk ook weer een nieuwe pc uitzoeken. Heb net een nieuwe, maar die heb ik even snel uit de voorraad getrokken. Blijkt dat deze geen hadware virtualization ondersteunt, en dat is toch wel een groot gemis als je wat virtual machines wil draaien. Zo kan ik nu geen 64 bits VM draaien, en dat is toch wel handig om te testen, dus dat doe ik nu allemaal maar in Hyper-V op onze dev server.

[ Voor 34% gewijzigd door Woy op 26-01-2011 10:40 ]

[Haan]

.oisyn schreef op woensdag 26 januari 2011 @ 10:35:
Ik gok dat hij het systeem niet zelf heeft uitgezocht.

Klopt.

Overigens lijkt het systeem verder ook erg op mijn pc thuis (alleen heb ik er dan een i5 750 in zitten), dus ik weet wat ik straks kan verwachten

[Cartman!]

Woy schreef op woensdag 26 januari 2011 @ 10:37:
[...]

Maar als je het in je IDE doet gaat het toch sowieso goed? Of heb je geen SVN plugin in VS draaien? Als ik iets in Visual Studio wijzig, dan gaat het bij mij in ieder geval automatisch goed.

Ik heb bewust geen SVN-plugin meer in NetBeans omdat de versie net iets scheef liep met die hier geinstalleerd is. Had toen 1 keer een commit gedaan via NetBeans en daarna kon ik er met windows explorer niet meer bij om te commiten etc. Ik doe alles via m'n IDE en commit gewoon in explorer nu dus, werkt zonder problemen, SVN rename oid heb ik daar echt niet voor nodig.

[creator1988]

Haan schreef op woensdag 26 januari 2011 @ 08:46:
Nieuwe workstation is besteld en zal binnenkort op m'n bureau staan
Belangrijkste specs:
- Core i7 870 processor
- Intel X25 SSD als systeemschijf (aangevuld met 2TB opslag)
- 8 GB RAM
- 2x Samsung 2443 monitor
- Radeon 6850 videokaart (geen idee waarom die er in zit, maar het scheen goedkoper te zijn dan een simpel kaartje)

In ieder geval En 100x beter dan een laptop van ruim jaar oud..

Man, ik zeik al tijden over mijn workstation, maar systeembeheer 'gelooft niet in SSD's' en mijn manager is de strijd een beetje moe geworden. Draai nu:

- Core 2 E6600
- WD Raptor
- 4 GB RAM

Hopeloos zootje. Bak is ook al 3 jaar oud ofzo. Ik neig er inmiddels naar om gewoon zelf een SSD in te hangen, en verder gewoon flink door te zeuren over processor en memory.

[MueR]

Haan schreef op woensdag 26 januari 2011 @ 08:46:
Nieuwe workstation is besteld en zal binnenkort op m'n bureau staan
Belangrijkste specs:
...

Hmm, ik moet mn baas ook eens achter zn vodden aan gaan zitten...

[FragFrog]

Cartman! schreef op woensdag 26 januari 2011 @ 00:02:
De rename/delete uit tortoise herken ik niet, ik rename dit gewoon in explorer dan wel m'n IDE en tortoise pikt dit netjes op.

Aye, ik rename / delete meuk hier doorgaans ook gewoon zonder problemen met explorer, maar dan moet je er wel op letten eerst te updaten. Eigenlijk bij alles wat je doet in mijn ervaring, update first, commit later

Exporten doe ik soms door een rar/zip te maken die tijdens het inpakken .svn ignored, dan extract en ben je er ook. Is meestal sneller bij mij dan een export op een of andere manier.

Toch wel een hint dat het niet helemaal ideaal werkt

* FragFrog gebruikte daar vroeger nog wel eens Filezilla + SVN files filter voor

[ Voor 9% gewijzigd door FragFrog op 26-01-2011 13:17 ]

[D-Raven]

FragFrog schreef op woensdag 26 januari 2011 @ 13:16:
[...]

[...]

Toch wel een hint dat het niet helemaal ideaal werkt

* FragFrog gebruikte daar vroeger nog wel eens Filezilla + SVN files filter voor

Toch nergens voor nodig. TortoiseSVN heeft gewoon een export functie. Die doet precies wat je wilt.

[roy-t]

Woy schreef op woensdag 26 januari 2011 @ 10:37:
[...]

Of heb je geen SVN plugin in VS draaien?

Klopt

[.oisyn]

If Visual Studio had achievements...

[Davio]

Ik kom niet verder dan "The Multitasker".

[.oisyn]

Ik heb denk ik wel:
- Shotgun Debugging
- The Portal
- The Multitasker
- Pasta Chef
- Steam Powered
- The Poet
- The Enterprise
- The Explainer
- The Architect
- I’m Sorry
- Just a Test
- Old School
- The Cloner
- Paying the bills
- Every Option Considered

Sommige zijn wel wat onduidelijk. Zoals bijv. The Cloner, is dat 50 regels in je leven, of 50 regels in 1 copy/paste. Ik vermoed de laatste, aangezien de eerste nogal snel gehaald wordt natuurlijk. Maar ik heb ook wel meer dan 50 regels in een keer gecopy/paste . Ik werk wel voornamelijk met C++ projecten overigens.

[ Voor 4% gewijzigd door .oisyn op 26-01-2011 16:38 ]

[Gamebuster]

.oisyn schreef op woensdag 26 januari 2011 @ 16:05:
If Visual Studio had achievements...

Ze moeten een plugin voor die achievements maken

Ik zou hebben: (geen VS; netbeans)
Shotgun Debugging
The Mathematician
Spaghetti Monster
The Multitasker
The Explainer
Rage Quit
The Architect
The Defender
Just a Test
The Cloner

[ Voor 26% gewijzigd door Gamebuster op 26-01-2011 16:51 ]

[FragFrog]

D-Raven schreef op woensdag 26 januari 2011 @ 14:26:
Toch nergens voor nodig. TortoiseSVN heeft gewoon een export functie. Die doet precies wat je wilt.

Tuurlijk, en die gebruik ik tegenwoordig ook in het unieke geval dat ik enkel de source wil. Maar als je die niet kent, en toch een aparte dev-omgeving hebt met naast een webserver ook een FTP server draaien, is het vrij simpel om de hele map die je wilt hebben te sleur-&-pleuren naar een lokale folder middels Filezilla (of een willekeurige andere FTP client die automatisch .SVN folders kan negeren). Als je niet beter weet..

Maargoed, dat is in mijn ervaring wel vrij typisch voor SVN / SCM in het algemeen. Je kan het op de goede manier doen (ergo, alles door je SCM laten regelen) of op een (handmatige) foute manier. Zo heb ik ook collega's gehad die niet branchen maar export -> import in nieuw folder deden. Of in plaats van commits van een andere branch te mergen de aanpassingen / aangepaste files copy-pasten (en daar dan weer apart winmerge voor installeren ).

Pokemon Programming – Caught all the exceptions

[Bender]

creator1988 schreef op woensdag 26 januari 2011 @ 12:57:
[...]

Man, ik zeik al tijden over mijn workstation, maar systeembeheer 'gelooft niet in SSD's' en mijn manager is de strijd een beetje moe geworden. Draai nu:

- Core 2 E6600
- WD Raptor
- 4 GB RAM

Hopeloos zootje. Bak is ook al 3 jaar oud ofzo. Ik neig er inmiddels naar om gewoon zelf een SSD in te hangen, en verder gewoon flink door te zeuren over processor en memory.

Dat is ongeveer het systeem wat ik ook heb, ook niet van 3 jaar oud.
Maar ik merk eigenlijk helemaal geen beperking in wat ik kan, het werk wat ik doe is eigenlijk hetzelfde ook als 6 jaar geleden daarin veranderd niet zoveel namelijk (alleen windows, maar Win7 draait als een zonnetje).

[sig69]

creator1988 schreef op woensdag 26 januari 2011 @ 12:57:
[...]

Man, ik zeik al tijden over mijn workstation, maar systeembeheer 'gelooft niet in SSD's' en mijn manager is de strijd een beetje moe geworden. Draai nu:

- Core 2 E6600
- WD Raptor
- 4 GB RAM

Hopeloos zootje. Bak is ook al 3 jaar oud ofzo. Ik neig er inmiddels naar om gewoon zelf een SSD in te hangen, en verder gewoon flink door te zeuren over processor en memory.

Hier snappen ze het ook niet hoor... Allemaal quad core dev machines met 8GB geheugen, en wat stoppen ze er dan aan storage in? Een of andere 80GB harddisk die ze bij het vuil gevonden hebben ofzo . Na twee maanden hing ik al aan de telefoon dat m'n disk vol zat (80GB.. kom op zeg, het is 2011 hoor!). Na veel gezeur en aandringen van m'n manager kreeg ik er toch wel nog zo'n oud 80GB klereding bij. Bedankt he, heren IT professionals! Nou ik vind het prima hoor. Een reboot duurt 20 minuten voordat ik weer normaal aan het werk kan, een build een minuut of 5. Ik heb meerdere malen uitgelegd dat een SSD zichzelf terugverdiend omdat je uiteindelijk gewoon efficienter aan het werk bent, maar ze willen er niet aan. Weet je wat ze dan zeggen? "Wat zeur je nou, je heb een onwijs snelle computer, je heb een quad core!" Best hoor, ga ik wel krantje lezen / kofie drinken / boek lezen

Poe hee, dat lucht op

[Woy]

.oisyn schreef op woensdag 26 januari 2011 @ 16:38:
- Steam Powered

Hoe moet ik die voor me zien? Ik snap dat jij wel eens wat met Steam doet, maar hoe kun je VS in Steam toevoegen als game?

Verder zijn ze inderdaad soms nogal vaag

Pokemon Programming – Caught all the exceptions

Die is nogal makkelijk. Een project waar ik nu aan werk ziet er ongeveer zo uit

C#:

static class Program
{
    static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
        try
        {
            Engine e = new Engine();
            e.Run();
        }
        catch(Exception ex)
        {
            Logger.Fatal("Program failure, exiting program", ex );
        }
    }
    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Logger.Fatal("Uncaught Exception", e.ExceptionObject);
        //Exit program
    }
}

[.oisyn]

Woy schreef op woensdag 26 januari 2011 @ 17:06:
[...]

Hoe moet ik die voor me zien? Ik snap dat jij wel eens wat met Steam doet, maar hoe kun je VS in Steam toevoegen als game?

Je kunt op je Steam client gewoon een willekeurige executable toevoegen als game. Als jij die dan opgestart hebt dan zegt Steam tegen je buddies dat je dat aan het spelen bent .

[Gamebuster]

@hierboven:
Die is inderdaad te makkelijk. -tenzij ze iets anders bedoelen.

NodeJS variant:

JavaScript:

    process.on("uncaughtException", function(exception) {
        console.log(exception.stack);
    });

En zover ik weet kan je gewoon ieder uitvoerbaar bestand als steam-game toevoegen. ("Add non-steam game" optie)

@ "Wat zeur je nou, je heb een onwijs snelle computer, je heb een quad core!"
Ik doe alles op een macbook met 2.8GHz intel core 2 duo; sinds ik daar een SSD in duwde ging alles veel sneller; compileren op mijn macbook gaat merkbaar sneller dan op mijn 2.6GHz i7 xeon server met 2 500GB samsungs in RAID1

Ik zou bijna durven zeggen dat je nog beter een SSD met een intel pentium 4 kan hebben dan een HDD met een i7 quad core (wie test er even? )

Even een testje: Compileren van NodeJS versie 0.3.6 op:
Macbook met 2.8GHz intel core 2 duo & "goedkope" 128GB kingston SSD met Mac OS X 10.6
Intel barebone server met 2.6GHz i7 xeon x3440 & 2 500GB samsung HDD's in RAID1 met Ubuntu Server 10.04 LTS 64bit:

$ ./configure
macbook: 1.729s
server: 2.084s

$ make
server: 2m44.968s
macbook: 3m53.714s

$ sudo make install
server: 0.084s
macbook: 0.142s

output:
server: http://pastebin.com/gK0WdQ8S
macbook: http://pastebin.com/SiXYsLJM

Hmm, dan toch maar een i7 met een HDD

[ Voor 83% gewijzigd door Gamebuster op 26-01-2011 17:37 ]

[farlane]

Gamebuster schreef op woensdag 26 januari 2011 @ 17:08:
Hmm, dan toch maar een i7 met een HDD

Beter, een i7 met een SSD

Mijn E6750 kan het trouwens nog behoorlijk volhouden, je moet alleen op een gegeven moment over omdat VS met iedere nieuwe versie trager wordt.

[whoami]

Ik zou zeker deze hebben:

The MultiTasker
Pasta Chef : weet ik niet zeker; zou kunnen
Highway To Hell
The Explainer
The Architect
The Right Way
The Defender
Pokemon Programming
Warm Bath

[Verwijderd]

sig69 schreef op woensdag 26 januari 2011 @ 17:02:
[...]

Hier snappen ze het ook niet hoor... Allemaal quad core dev machines met 8GB geheugen, en wat stoppen ze er dan aan storage in? Een of andere 80GB harddisk die ze bij het vuil gevonden hebben ofzo . Na twee maanden hing ik al aan de telefoon dat m'n disk vol zat (80GB.. kom op zeg, het is 2011 hoor!). Na veel gezeur en aandringen van m'n manager kreeg ik er toch wel nog zo'n oud 80GB klereding bij. Bedankt he, heren IT professionals! Nou ik vind het prima hoor. Een reboot duurt 20 minuten voordat ik weer normaal aan het werk kan, een build een minuut of 5. Ik heb meerdere malen uitgelegd dat een SSD zichzelf terugverdiend omdat je uiteindelijk gewoon efficienter aan het werk bent, maar ze willen er niet aan. Weet je wat ze dan zeggen? "Wat zeur je nou, je heb een onwijs snelle computer, je heb een quad core!" Best hoor, ga ik wel krantje lezen / kofie drinken / boek lezen

Poe hee, dat lucht op

Op het werk heb ik een SSD gekregen om eens te testen. En wat blijkt. Java projecten met IDEA IntelliJ als IDE (projecten + caches op de SSD - Ubuntu + alle software op de HDD): HD is niet de bottleneck bij het compilen, noch bij het indexeren. CPU is de bottleneck, en nog erger, het is single-threaded. Kortom, om sneller te compilen / project op te starten (waarbij hij terug begint te indexeren) heb ik gewoon een snellere single-core CPU nodig.
Dan sta je daar met je SSD

[.oisyn]

Is er geen 3rd party solution voor distributed builds voor Java? Onze C++ builds worden gedistribueerd over een stuk of 20 threads binnen het kantoor . Scheelt wel dat C++ code met z'n aparte translation units een stuk makkelijker in parallel te compilen is.

[Matis]

Wij hebben een Citrix-omgeving met daarop Ubuntu icm Hudson. Daarop bouwen wij onze software.
Dat zijn veelal OpenEmbedded Linux rootfs-en. Het mooie aan Hudson is ook dat je hem je CVS/SVN-server kunt laten monitoren en bij een update begint hij dan automagisch te bouwen.

Sinds dat wij die software hebben draaien, is allereerst de productiviteit omhoog gegaan op de afdeling. Je PC gaat in ieder geval niet meer over zijn nekje. Daarnaast kunnen ook veel meer regressie-builds en/of nightly-builds gemaakt worden.

Misschien zou je eens kunnen kijken of Hudson ook binnen jouw Java-project in te zetten valt.

[NetForce1]

Matis schreef op woensdag 26 januari 2011 @ 21:33:
Wij hebben een Citrix-omgeving met daarop Ubuntu icm Hudson. Daarop bouwen wij onze software.
Dat zijn veelal OpenEmbedded Linux rootfs-en. Het mooie aan Hudson is ook dat je hem je CVS/SVN-server kunt laten monitoren en bij een update begint hij dan automagisch te bouwen.

Sinds dat wij die software hebben draaien, is allereerst de productiviteit omhoog gegaan op de afdeling. Je PC gaat in ieder geval niet meer over zijn nekje. Daarnaast kunnen ook veel meer regressie-builds en/of nightly-builds gemaakt worden.

Misschien zou je eens kunnen kijken of Hudson ook binnen jouw Java-project in te zetten valt.

Zeker in combinatie met Maven is Hudson super! De project-dependencies worden dan door Hudson zelf uitgezocht. Helemaal leuk als je er dan nog een aantal build-slaves bij hebt waarnaar je werk kunt laten delegeren.

[H!GHGuY]

Matis schreef op woensdag 26 januari 2011 @ 21:33:
Dat zijn veelal OpenEmbedded Linux rootfs-en.

My condolences...

Toevallig een OE-based versie van een vendor of doe je het met de mainline OE?
Sinds introductie van OE bij ons (MontaVista MVL6 en nu CGE6) heb ik alweer een support case of 50 gelogged.
Op het eerste zicht lijkt alles lekker flexibel en aanpasbaar, tot je er echt mee aan de slag gaat. Dan zie je snel welke rotzooi het is op zowel technisch als juridisch vlak. Ik hoop dat poky het beter doet en dat vendors er dan ook naar migreren. OE is flawed van binnenuit en is hooguit geschikt om thuis een build voor je sheevaplug te maken.

[Avalaxy]

Rofl, kom ik tijdens het brouwsen ineens een website tegen van iemand die de Windows Vista GUI heeft nagemaakt in een website, ziet er nog goed uit ook

http://www.tweakwindows.nl/wallpapers/art/

[Verwijderd]

@hierboven: uiteraard Hudson voor CI, maar dat betekent niet dat je lokaal al eens iets zelf moet compilen, al is het maar om te debuggen . En dan zie je duidelijk dat er 1 CPU helemaal over de rooie gaat, en de rest van al je core's staat lekker niks te doen. Disk IO is er op dat moment amper.
Vandaar de bemerking dat die SSD iig ook niet 'het van het' is in alle gevallen

[.oisyn]

Avalaxy schreef op woensdag 26 januari 2011 @ 23:24:
Rofl, kom ik tijdens het brouwsen ineens een website tegen van iemand die de Windows Vista GUI heeft nagemaakt in een website, ziet er nog goed uit ook

http://www.tweakwindows.nl/wallpapers/art/

Nice. Ken je deze ook? http://www.michaelv.org.nyud.net

[Gamebuster]

Avalaxy schreef op woensdag 26 januari 2011 @ 23:24:
Rofl, kom ik tijdens het brouwsen ineens een website tegen van iemand die de Windows Vista GUI heeft nagemaakt in een website, ziet er nog goed uit ook

http://www.tweakwindows.nl/wallpapers/art/

jammer dat de pagina zo mega-groot is. Niet iedereen met een 1920x1200 heeft zijn venster op fullscreen.

.oisyn schreef op woensdag 26 januari 2011 @ 23:44:
[...]

Nice. Ken je deze ook? http://www.michaelv.org.nyud.net

Die vind ik niet echt super; zodra je een venster versleept en per ongeluk de rand raakt, moet je 'm opnieuw "oppakken". Wel grappig dat die apps zijn nagemaakt.

[ Voor 29% gewijzigd door Gamebuster op 26-01-2011 23:48 ]