De Devschuur Coffee Corner - Iteratie 4

[Douweegbertje]

Zo te horen hadden ze beter die Beta een Alfa kunnen noemen.

[Martindo]

Sinds een paar dagen Java Swing ontdekt, binnenkort maar eens mee gaan kloten, kunnen vast wel wat nuttige appjes uit komen.

Het is in ieder geval vakantie, dus dat is mooi.

[Robbiedobbie]

Martindo schreef op vrijdag 18 oktober 2013 @ 13:07:
Sinds een paar dagen Java Swing ontdekt, binnenkort maar eens mee gaan kloten, kunnen vast wel wat nuttige appjes uit komen.

Het is in ieder geval vakantie, dus dat is mooi.

Java Swing? You better start running.....

Blegh, Swing is echt een gedrocht naar mijn mening

[Verwijderd]

Martindo schreef op vrijdag 18 oktober 2013 @ 13:07:
Sinds een paar dagen Java Swing ontdekt, binnenkort maar eens mee gaan kloten, kunnen vast wel wat nuttige appjes uit komen.

Het is in ieder geval vakantie, dus dat is mooi.

Zou je in de plaats niet kijken naar Java FX?

[Martindo]

Ik zal ook eens naar JavaFX kijken. Misschien een betere optie inderdaad. Nouja, we zien wel.

Vakantie zal grotendeels toch wel met me tentamens bezig zijn.

[Ealanrian]

Ik dacht al dat het aan mij lag, de rillingen van swing... BAH wat een gedrocht. dat soort dingen + pixel perfect designers hebben mij echt weg gedreven bij al het grafische

[Caelorum]

Ik vond swing op zich niet zo erg, al geef ik zelf de voorkeur aan WPF, dan Qt, dan GTK en dan alle andere meuk. Gelukkig kom ik meestal niet verder dan WPF of Qt ^^

[PdeBie]

pffffff vrijdagmiddag dip hier. Heeft er iemand koffie?!

[Firesphere]

pdebie schreef op vrijdag 18 oktober 2013 @ 13:55:
pffffff vrijdagmiddag dip hier. Heeft er iemand koffie?!

* Firesphere sluit het koffie infuus aan.

[Ealanrian]

* Ealanrian sluit het alcohol infuus er bij aan

[Verwijderd]

Ealanrian schreef op vrijdag 18 oktober 2013 @ 14:07:
* Ealanrian sluit het alcohol infuus er bij aan

Nog 3 uurtjes wachten hier

[Ryur]

pdebie schreef op vrijdag 18 oktober 2013 @ 13:55:
pffffff vrijdagmiddag dip hier. Heeft er iemand koffie?!

Hier ook vrijdagmiddagdip. Dus maar energiedrank + goede muziek!

[Avalaxy]

Martindo schreef op vrijdag 18 oktober 2013 @ 13:07:
Sinds een paar dagen Java Swing ontdekt, binnenkort maar eens mee gaan kloten, kunnen vast wel wat nuttige appjes uit komen.

Het is in ieder geval vakantie, dus dat is mooi.

RUN FOR YOUR LIFE!

[Robbiedobbie]

Blegh, na een half jaar irritatie, maar nooit te moeite genomen om te zoeken, heb ik eindelijk gevonden hoe ik eclipse fatsoendelijk om kan laten gaan met c++0x -.-". De enige manier om dit te krijgen is door tientalle menus in de goede volgorde door te lopen, waarna je ergens een veld vind waar je custom options in kan zetten, en dan daar ook -std=c++0x erbij te pleuren....

Misschien zouden ze ook gewoon een switch kunnen maken bij de opties?

EDIT: Ter verduidelijking, die switch was niet de compiler switch, maar een of ander veld om de indexer ermee werkend te krijgen. De compiler switch had ik wel een half jaar geleden al gevonden natuurlijk

[ Voor 18% gewijzigd door Robbiedobbie op 18-10-2013 14:13 ]

[Verwijderd]

Ryur schreef op vrijdag 18 oktober 2013 @ 14:07:
[...]

Hier ook vrijdagmiddagdip. Dus maar energiedrank + goede muziek!

Dat laatste kan ik je al aanbieden, dan hoef je niet verder te zoeken:

Wat een optreden

[ Voor 4% gewijzigd door Verwijderd op 18-10-2013 14:36 ]

[serhat]

Robbiedobbie schreef op vrijdag 18 oktober 2013 @ 13:08:
[...]

Java Swing? You better start running.....

Blegh, Swing is echt een gedrocht naar mijn mening

Eens.

Als je toch iets met Java en UI wil doen kan ik je SWT aanraden. Een keertje ook een projectje erin gedaan. Ziet er allemaal lekker native uit en verder zou je eigenlijk bijna niet denken dat het onder water gewoon Java is. Al was dat al enkele jaren terug. Hoop dat dat nog steeds zo is.

AWT/Swing is een draak van een UI omgeving mijns inziens.

[CodeCaster]

Het is weer vrijdag.

[ Voor 113% gewijzigd door CodeCaster op 18-10-2013 15:28 ]

[Rutix]

Ok mensen . Ik ga op vakantie ^__^ dus tot over twee weken! Curacao here i come

[Verwijderd]

Rutix schreef op vrijdag 18 oktober 2013 @ 14:39:
Ok mensen . Ik ga op vakantie ^__^ dus tot over twee weken! Curacao here i come

Geniet er van!

[Ealanrian]

Ik lees net in een artikel, Secure Software Development by Example, dat een ontwikkelaar 1 bug per 55 regels introduceert. Zorg er dus voor dat je applicaties 54 regels max is en je heb bug vrije code

[xandie]

Ealanrian schreef op vrijdag 18 oktober 2013 @ 14:50:
Ik lees net in een artikel, Secure Software Development by Example, dat een ontwikkelaar 1 bug per 55 regels introduceert. Zorg er dus voor dat je applicaties 54 regels max is en je heb bug vrije code

elke functie opsplitsen in subfuncties van 54 regels

[ytterx]

xandie schreef op vrijdag 18 oktober 2013 @ 14:54:
[...]


elke functie opsplitsen in subfuncties van 54 regels

Elke 54 regels een nieuwe file includen

[Verwijderd]

xandie schreef op vrijdag 18 oktober 2013 @ 14:54:
[...]


elke functie opsplitsen in subfuncties van 54 regels

Daarmee los je het probleem niet op. Je schrijft in die applicatie nog steeds meer dan 54 regels code...

[Ealanrian]

Komt er nou niemand met whitespace removen?

[Verwijderd]

Verwijderd schreef op vrijdag 18 oktober 2013 @ 15:12:
[...]


Daarmee los je het probleem niet op. Je schrijft in die applicatie nog steeds meer dan 54 regels code...

Alles packen in libs die maximaal 54 regels code zijn

[SPee]

Gewoon het hele programma op 1 regel programmeren.

[Firesphere]

SPee schreef op vrijdag 18 oktober 2013 @ 15:15:
Gewoon het hele programma op 1 regel programmeren.

* Firesphere gaat refactoren.

[Ryur]

Firesphere schreef op vrijdag 18 oktober 2013 @ 15:17:
[...]



* Firesphere gaat refactoren.

Refuctoren?

[Firesphere]

Ryur schreef op vrijdag 18 oktober 2013 @ 15:17:
[...]

Refuctoren?

Da's toch hetzelfde?

[Ryur]

Firesphere schreef op vrijdag 18 oktober 2013 @ 15:18:
[...]

Da's toch hetzelfde?
[afbeelding]

Wel in mijn huidige codebase ja.
Geen unittesting en alles hangt aan elkaar vast. Dus als je een refactoring maakt, weet je bijna zeker dat je lang niet alles getest krijgt of de refactoring gelukt is.

Als er een goede code coverage is, vind ik het juist heerlijk om te refactoren.

[Douweegbertje]

Ryur schreef op vrijdag 18 oktober 2013 @ 15:21:
[...]

Wel in mijn huidige codebase ja.
Geen unittesting en alles hangt aan elkaar vast. Dus als je een refactoring maakt, weet je bijna zeker dat je lang niet alles getest krijgt of de refactoring gelukt is.

Als er een goede code coverage is, vind ik het juist heerlijk om te refactoren.

Ja dat lijkt me ook deels logisch en verkapt dubbelzinnig.
Als de code verder in orde is en logisch opgebouwd e.d. is het natuurlijk rete simpel om te gaan refactoren. In feite is het dan al gerefactored (sort of).

[Ryur]

douweegbertje schreef op vrijdag 18 oktober 2013 @ 15:24:
[...]


Ja dat lijkt me ook deels logisch en verkapt dubbelzinnig.
Als de code verder in orde is en logisch opgebouwd e.d. is het natuurlijk rete simpel om te gaan refactoren. In feite is het dan al gerefactored (sort of).

Nah hoeft niet hoor. Ik heb wel een project gehad waar netjes unittests voor werden gemaakt (vooral omdat het "moest"). Maar qua opbouw verder niet zo netjes, veel in dezelfde classes enz.
Dus ondanks dat er testen waren, was de code niet netjes

[BikkelZ]

Gisteren weer even met de nieuwe XCode aan de slag geweest. Toch een goede zet van Apple om het geheugen en CPU gebruik van je applicatie zo pontificaal in beeld te brengen, je gaat onbewust toch opletten of je CPU spikes ziet bij dingen die je doet of het RAM gebruik langzaam of snel toeneemt.

Zo zag ik toch bevestigd dat als ik één keer een path teken en dan door middel van rotatie en path stroke daar vervolgens mee werk de CPU niet meer belast wordt na de initialisatie. Sowieso denk ik dat doordat Objective-C wat meer low level is en Apple simpelweg wat meer let op performance iOS wat meer snappy aan voelt dan Android, ik denk dat dit daar ook weer bij gaat helpen.

[Scott]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 16:05:
Gisteren weer even met de nieuwe XCode aan de slag geweest. Toch een goede zet van Apple om het geheugen en CPU gebruik van je applicatie zo pontificaal in beeld te brengen, je gaat onbewust toch opletten of je CPU spikes ziet bij dingen die je doet of het RAM gebruik langzaam of snel toeneemt.

Zo zag ik toch bevestigd dat als ik één keer een path teken en dan door middel van rotatie en path stroke daar vervolgens mee werk de CPU niet meer belast wordt na de initialisatie. Sowieso denk ik dat doordat Objective-C wat meer low level is en Apple simpelweg wat meer let op performance iOS wat meer snappy aan voelt dan Android, ik denk dat dit daar ook weer bij gaat helpen.

Ik vind niet dat Objective-C low level is, denk dat het ongeveer gelijk is aan Java wat dat betreft. Dan heb ik het dus niet over libraries die C functions gebruiken, maar echt pure Objective-C.

Overigens vond ik dit een heel interessant artikel dat heel diep ingaat op de snappiness van beide platformen. Is hier al eens voorbij gekomen geloof ik.

[StM]

Dat is het mooie van Objective-C. Je werkt high level, maar je kan gewoon wat assembly toevoegen wanneer dat goed uitkomt.

[mbarie]

Kantoor is hier leeg except for me. Iedereen is naar ADE (Amsterdam Dance Event) of naar huis. En ik moet nog aan de bak tot 10 over 6. Bummer. Heb maar wat rare techno opgezet hier haha.

[.oisyn]

Gewoon naar huis gaan, no one will know

[mbarie]

I know. Niemand die het me kwalijk zou nemen als ze het wel hadden geweten. Maar heb afgesproken hier iemand op te pikken op 18u30. kwam nu eenmaal zo uit. Even naar huis en terug is niet echt een optie, is 2 uur reizen . Ik moet dus nog even.

[ Voor 16% gewijzigd door mbarie op 18-10-2013 16:29 ]

[Knutselsmurf]

Verwijderd schreef op vrijdag 18 oktober 2013 @ 14:35:
[...]


Dat laatste kan ik je al aanbieden, dan hoef je niet verder te zoeken:
[video]

Wat een optreden

Oeh, jeugdsentiment

[Gamebuster]

.oisyn schreef op vrijdag 18 oktober 2013 @ 16:26:
Gewoon naar huis gaan, no one will know

'ff een git commit schedulen in een cronjob
Dan kan je zelfs aantonen dat je er nog was

[Afvalzak]

Firesphere schreef op vrijdag 18 oktober 2013 @ 15:18:
[...]

Da's toch hetzelfde?
[afbeelding]

Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z fuck fuck fuck Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z Ctrl-z

[BikkelZ]

Scott schreef op vrijdag 18 oktober 2013 @ 16:20:
[...]

Ik vind niet dat Objective-C low level is, denk dat het ongeveer gelijk is aan Java wat dat betreft. Dan heb ik het dus niet over libraries die C functions gebruiken, maar echt pure Objective-C.

Overigens vond ik dit een heel interessant artikel dat heel diep ingaat op de snappiness van beide platformen. Is hier al eens voorbij gekomen geloof ik.

Voor zover ik het begrepen heb worden Objective-C objecten omgezet naar C structs en dan als C gecompileerd met de standaard compiler. Maar ik ben nog niet door mijn boek heen

Ik ben de laatste om te zeggen dat je gratis precies C performance krijgt ondanks dat je objecten en key value based dingen gebruikt. Daar zitten altijd kosten aan vast.

Maar het punt van mijn betoog was met name dat puur het aanwezig zijn van zo'n metertje je meer gevoelig maakt voor de performance van je code. Stel dat je iets nieuws code waarbij je je layouts handmatig managed en je ziet ineens overal CPU spikes opduiken, dan ga je toch nadenken.

[ Voor 13% gewijzigd door BikkelZ op 18-10-2013 16:51 ]

[Struikrover]

W00t! CSV import van 2 tabellen met plm 350.000 records, en een left join gebeurt nu in ruwweg een minuut. Nette performance boost en weg problematiek

[.oisyn]

Dat klinkt nog best lang.

[Korben]

Struikrover schreef op vrijdag 18 oktober 2013 @ 16:55:
W00t! CSV import van 2 tabellen met plm 350.000 records, en een left join gebeurt nu in ruwweg een minuut. Nette performance boost en weg problematiek

'Import' en 'left join'... does not compute. Bedoel je een export vanuit een database naar een CSV?

[.oisyn]

Ik vind import gevolgd door een left join een stuk meer sense maken dan een export gevolgd door een left join.

[farlane]

Verwijderd schreef op vrijdag 18 oktober 2013 @ 14:35:
[...]
Wat een optreden

Legendarisch even ...

[Alex)]

Even wat binnengehaald... Visual Studio 2013, TFS 2013, Windows 8.1, Windows Server 2012 R2

Ik ga een druk weekend tegemoet

[Verwijderd]

Aaaaargh wat wordt ik gek van VB
Ik heb wat in elkaar lopen flansen, en het werkt voor...25% misschien
Ook hier een druk weekend, want snap er geen hol van als naab

[mbarie]

Vriendin is net vertrokken naar een ver land voor een week. Geekweekend aanstaande met wat vrienden t/m maandag. Ongegeneerd feesten en zuipen, spelletjes spelen en soms wat hobbyprogrammeren. Zin in.

[ Voor 4% gewijzigd door mbarie op 18-10-2013 17:34 ]

[Caelorum]

mbarie schreef op vrijdag 18 oktober 2013 @ 17:33:
Vriendin is net vertrokken naar een ver land voor een week. Geekweekend aanstaande met wat vrienden t/m maandag. Ongegeneerd feesten en zuipen, spelletjes spelen en soms wat hobbyprogrammeren. Zin in.

En over een week denk je.. Waarom heb ik ook alweer niets gedaan aan mijn hobbyprojecten? ^^

[mbarie]

Caelorum schreef op vrijdag 18 oktober 2013 @ 17:35:
[...]

En over een week denk je.. Waarom heb ik ook alweer niets gedaan aan mijn hobbyprojecten? ^^

Als ik dat maar doe met een lach, ben ik daar helemaal ok mee

[Scott]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 16:49:
[...]


Voor zover ik het begrepen heb worden Objective-C objecten omgezet naar C structs en dan als C gecompileerd met de standaard compiler. Maar ik ben nog niet door mijn boek heen

Ik ben de laatste om te zeggen dat je gratis precies C performance krijgt ondanks dat je objecten en key value based dingen gebruikt. Daar zitten altijd kosten aan vast.

Maar het punt van mijn betoog was met name dat puur het aanwezig zijn van zo'n metertje je meer gevoelig maakt voor de performance van je code. Stel dat je iets nieuws code waarbij je je layouts handmatig managed en je ziet ineens overal CPU spikes opduiken, dan ga je toch nadenken.

Ik snap wat je bedoelt. Vanwege een gebrek aan C-kennis weet ik er het fijne ook niet van, maar Objective-C is een dynamische taal, wat zoveel betekent dat pas als de code wordt uitgevoerd, de conversie van Objective-C naar C (method call -> objc_sendMsg()) wordt gemaakt. De Objective-C objecten bestaan dan ook nog.

Maar, je hebt wel gelijk. Een metertje, of zelfs maar een indicator hoeveel je gebruikt, herinnert je er in ieder geval aan dat je te maken hebt met gelimiteerde technologie. Als jij een simpele app schrijft die 100MB geheugen gebruikt, dan wordt het misschien toch eens tijd om Instruments er bij te pakken.

[ZpAz]

Scott schreef op vrijdag 18 oktober 2013 @ 18:02:
[...]

Ik snap wat je bedoelt. Vanwege een gebrek aan C-kennis weet ik er het fijne ook niet van, maar Objective-C is een dynamische taal, wat zoveel betekent dat pas als de code wordt uitgevoerd, de conversie van Objective-C naar C (method call -> objc_sendMsg()) wordt gemaakt. De Objective-C objecten bestaan dan ook nog.

Maar, je hebt wel gelijk. Een metertje, of zelfs maar een indicator hoeveel je gebruikt, herinnert je er in ieder geval aan dat je te maken hebt met gelimiteerde technologie. Als jij een simpele app schrijft die 100MB geheugen gebruikt, dan wordt het misschien toch eens tijd om Instruments er bij te pakken.

Het

C:

[foo doeIetsAwesomeMet:eenString];

omzetten naar

C:

objc_msgSend(foo, @selector(doeIetsAwesomeMet:), eenString);

lijkt me juist iets wat compile time geregeld kan worden.

De selectors krijgen allemaal een unieke ID voor een signature en dat ID verwijst naar een bepaalde functie, het "dynamische" gedeelte zit hem er volgens mij in dat de "methode signatuur (selector)" niet "in code gelinkt is aan de objecten" maar @ runtime wordt gekeken welk "ID" bij welke selector hoort en welke functie dus moet worden aangeroepen.

De objecten bestaan inderdaad, maar dat zijn volgens mij "dictionarys" met een lijstje van welke selectors (methodes) het op reageerd en een lijstje van verwijzingen naar variabelen welke bij de betreffende instance e.d horen.

Dat is allemaal maar een vrij dun laagje en zeker niet vergelijkbaar met de complete Java Runtime.

[ Voor 11% gewijzigd door ZpAz op 18-10-2013 18:41 ]

[Douweegbertje]

Korben schreef op vrijdag 18 oktober 2013 @ 17:04:
[...]

'Import' en 'left join'... does not compute. Bedoel je een export vanuit een database naar een CSV?

Zover ik het volgde en hem een tip gaf;

2 CSV bestanden die hij in één table moest zetten maar de CSV bestanden verschilde van elkaar en er moest data van het één naar de anders als het in de eerste niet zat etc.
Daarbij gaf ik de tip om elk CSV bestand in een (tijdelijke) table te zetten en vervolgens middels een left join de data in een nieuwe table te gooien.

[Firesphere]

* Firesphere vraagt API wat voor data hij aan kan.
* Firesphere krijgt terug "associated array, string or int"

Dus ik gooi blij een assoc-array naar de api, krijg ik terug
<query type="string">Array</query>


Zeg dan niet dat je arrays ondersteund!

[ Voor 11% gewijzigd door Firesphere op 18-10-2013 18:45 ]

[Verwijderd]

Ik had een probleem met dynamische object lifeline over meerdere threads, dus ik gebruikte std::shared ptr.

Nu heb ik 2 problemen.

[BikkelZ]

ZpAz schreef op vrijdag 18 oktober 2013 @ 18:35:
[...]


Het

C:

[foo doeIetsAwesomeMet:eenString];

omzetten naar

C:

objc_msgSend(foo, @selector(doeIetsAwesomeMet:), eenString);

lijkt me juist iets wat compile time geregeld kan worden.

De selectors krijgen allemaal een unieke ID voor een signature en dat ID verwijst naar een bepaalde functie, het "dynamische" gedeelte zit hem er volgens mij in dat de "methode signatuur (selector)" niet "in code gelinkt is aan de objecten" maar @ runtime wordt gekeken welk "ID" bij welke selector hoort en welke functie dus moet worden aangeroepen.

De objecten bestaan inderdaad, maar dat zijn volgens mij "dictionarys" met een lijstje van welke selectors (methodes) het op reageerd en een lijstje van verwijzingen naar variabelen welke bij de betreffende instance e.d horen.

Dat is allemaal maar een vrij dun laagje en zeker niet vergelijkbaar met de complete Java Runtime.

Ik probeer het even uit mijn blote hoofd nu: als je zaken niet definieert in je .m file maar wel in je .h dan compileert het wel maar krijg je een unknown selector error. Je kunt geloof ik wel zo'n call opvangen en er dan alsnog iets nuttigs mee doen maar het is vrij beperkt.

Ik zou liever een compile error krijgen op zo'n moment. Volgens mij kan dat ook maar ik ben nog niet zo handig met de settings binnen XCode.

[ZpAz]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 19:13:
[...]


Ik probeer het even uit mijn blote hoofd nu: als je zaken niet definieert in je .m file maar wel in je .h dan compileert het wel maar krijg je een unknown selector error. Je kunt geloof ik wel zo'n call opvangen en er dan alsnog iets nuttigs mee doen maar het is vrij beperkt.

Dat is niet helemaal correct. De .h file is zeg maar je beschrijving van de "API" van het object naar de buitenwereld, andere objecten. Zeg maar de equivalent van public methodes in Java. Declareer / implementeer je ze enkel in de .m file zijn het "protected" methodes.

Je krijgt dan inderdaad een warning, maar hij crashed er niet op want de selector bestaat wel voor het object. Er is niet echt een notie van "public en protected / private" in Objective-C. De voorgaande beschrijving is het dichtste bij wat je daar bij komt.

Hier in XCode 5 krijg ik wel een error en gaat hij niet verder, ik dacht dat het altijd een warning was.

Via "dynamic method resolution" zou je dynamisch methodes kunnen laden voor een selector die niet gevonden kan worden. Hiermee zijn vergelijkbare constructies als __call in php.

[ Voor 20% gewijzigd door ZpAz op 18-10-2013 19:43 ]

[Verwijderd]

Verwijderd schreef op vrijdag 18 oktober 2013 @ 18:58:
Ik had een probleem met dynamische object lifeline over meerdere threads, dus ik gebruikte std::shared ptr.

Nu heb ik 2 problemen.

Fuck it. Ik gebruik mijn eigen reference counter wel.

[BikkelZ]

ZpAz schreef op vrijdag 18 oktober 2013 @ 19:29:
[...]


Dat is niet helemaal correct. De .h file is zeg maar je beschrijving van de "API" van het object naar de buitenwereld, andere objecten. Zeg maar de equivalent van public methodes in Java.

Declareer je ze enkel in de .m file zijn het "protected" methodes. Je krijgt dan inderdaad een warning, maar hij crashed er niet op want de selector bestaat wel voor het object. Er is niet echt een notie van "public en protected / private" in Objective-C. De voorgaande beschrijving is het dichtste bij wat je daar bij komt.

Via "dynamic method resolution" zou je dynamisch methodes kunnen laden voor een selector die niet gevonden kan worden. Hiermee zijn vergelijkbare constructies als __call in php.

Nee dat klopt dat gebruik ik ook uitgebreid om mijn objecten niet te veel clutter te geven naar andere objecten maar een niet geimplementeerde methode compiled wel maar werkt eigenlijk nooit.

[ZpAz]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 19:40:
[...]


Nee dat klopt dat gebruik ik ook uitgebreid om mijn objecten niet te veel clutter te geven naar andere objecten maar een niet geimplementeerde methode compiled wel maar werkt eigenlijk nooit.

Heb een wijziging in mijn bericht geplaatst, maar in dit bericht lijkt het alsof je wel iets in de .h hebt staan maar deze niet hebt geïmplementeerd in de .m. Nee dat werkt niet, je krijgt dan enkel een "incomplete implementation" warning. En bij het aanroepen van de methode zal hij wel crashen omdat hij niet bestaat.

In de .h zeg je alleen maar "ik ga dit implementeren". De implementatie moet dan uiteraard nog gedaan worden.

[BikkelZ]

ZpAz schreef op vrijdag 18 oktober 2013 @ 19:42:
[...]

In de .h zeg je alleen maar "ik ga dit implementeren". De implementatie moet dan uiteraard nog gedaan worden.

Ik weet eigenlijk niet eens hoe dat in C werkt. Loop je daar tegen het zelfde aan?

[StM]

In C zal het linken falen maar je kan wel compileren. In principe zou je bij Obj C gewoon die warnings als errors kunnen laten behandelen, maar doordat het mogelijk is om dynamisch dingen aan te passen kan die warning ten onrechte zijn.

[F.West98]

Opvallend dat VS bij dark theme een veel hoger contrast heeft dan JetBrains spul bij Darcula theme.

Twijfels. Android kloten, verder met ander project (C#) of een game spelen

[ZpAz]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 20:06:
[...]


Ik weet eigenlijk niet eens hoe dat in C werkt. Loop je daar tegen het zelfde aan?

Voor zo ver ik weet is het ook in C dat je in de .h zegt van "deze functies zijn er" en in de .m staat de daadwerkelijke implementatie. Volgens mij is daar de .h informatie voor de compiler. Als je in een bepaald bestand werkt (laten we die mijn.m noemen) en je roept een functie aan bijvoorbeeld max() dan moet je <Math.h> includen.

Tegen de compiler zeg je dan, wanneer je mijn stukje code in mijn.m compiled en je kent geen functie max() ga dan maar gewoon door want die zit in Math.m, die kom je later nog wel tegen. (In Math.h staan dan de functies die de compiler "tegen gaat komen").

In C moet namelijk de functie normaal in je code staan voordat je hem aanroept. Maar omdat dat niet overal handig is kan je zeggen in een .h bestand: "Deze functie komt nog wel, maak je geen zorgen."

---

In Objective-C maakt de volgorde van de functies niet zozeer uit en is de .h meer gewoon de "publieke beschrijving" van "deze methodes kunnen jullie aanroepen als buitenstaander op dit object". Vergelijkbaar met public in Java.

[Scott]

ZpAz schreef op vrijdag 18 oktober 2013 @ 18:35:
[...]


Het

C:

[foo doeIetsAwesomeMet:eenString];

omzetten naar

C:

objc_msgSend(foo, @selector(doeIetsAwesomeMet:), eenString);

lijkt me juist iets wat compile time geregeld kan worden.

De selectors krijgen allemaal een unieke ID voor een signature en dat ID verwijst naar een bepaalde functie, het "dynamische" gedeelte zit hem er volgens mij in dat de "methode signatuur (selector)" niet "in code gelinkt is aan de objecten" maar @ runtime wordt gekeken welk "ID" bij welke selector hoort en welke functie dus moet worden aangeroepen.

De objecten bestaan inderdaad, maar dat zijn volgens mij "dictionarys" met een lijstje van welke selectors (methodes) het op reageerd en een lijstje van verwijzingen naar variabelen welke bij de betreffende instance e.d horen.

Dat is allemaal maar een vrij dun laagje en zeker niet vergelijkbaar met de complete Java Runtime.

Ik geloof dat je inderdaad gelijk hebt.

BikkelZ schreef op vrijdag 18 oktober 2013 @ 19:40:
[...]


Nee dat klopt dat gebruik ik ook uitgebreid om mijn objecten niet te veel clutter te geven naar andere objecten maar een niet geimplementeerde methode compiled wel maar werkt eigenlijk nooit.

Klopt, dat hoor je normaal gesproken ook gewoon niet te doen. Aan de ene kant zeg je tegen anderen dat het object die methode implementeert, tegelijkertijd doe je dat niet. Dan moet je hem dus of implementeren, of niet zeggen dat je dat wel doet. Dynamig Method Resolution is een uitzondering, maar ik moet zeggen dat ik dat zelden gebruik.

[Caelorum]

ZpAz schreef op vrijdag 18 oktober 2013 @ 20:20:
[...] In C moet namelijk de functie normaal in je code staan voordat je hem aanroept. Maar omdat dat niet overal handig is kan je zeggen in een .h bestand: "Deze functie komt nog wel, maak je geen zorgen." [...]

Een functie declaren kan uiteraard ook in hetzelfde bestand. Of je het moet willen is een tweede maar ach, soms is het wel even makkelijk

[Styxxy]

Verwijderd schreef op vrijdag 18 oktober 2013 @ 17:31:
Aaaaargh wat wordt ik gek van VB
Ik heb wat in elkaar lopen flansen, en het werkt voor...25% misschien
Ook hier een druk weekend, want snap er geen hol van als naab

VB als in VB6 of VBA of VB.NET?

Indien de laatste optie, hou je aan de .NET zaken en gebruik niet de ranzige VB zaken ervan. Indien de overige 2 opties, I feel sorry for you.

F.West98 schreef op vrijdag 18 oktober 2013 @ 20:18:
Twijfels. Android kloten, verder met ander project (C#) of een game spelen

Doe waar je zin in hebt . Het is vrijdagavond en je bent nergens toe verplicht .

[BikkelZ]

ZpAz schreef op vrijdag 18 oktober 2013 @ 20:20:
[...]


Voor zo ver ik weet is het ook in C dat je in de .h zegt van "deze functies zijn er" en in de .m staat de daadwerkelijke implementatie. Volgens mij is daar de .h informatie voor de compiler. Als je in een bepaald bestand werkt (laten we die mijn.m noemen) en je roept een functie aan bijvoorbeeld max() dan moet je <Math.h> includen.

Right dus het is gewoon een stukje erfenis van C. Ik zou zeggen dat XCode daar ook wel een stukje in zou kunnen helpen, het overnemen van de zelfde regel code van .h naar .m is gewoon iedere keer handmatig een hoop werk doen. Lijkt mij dat het redelijk makkelijk in elkaar te vouwen is tot één file waarbij je simpelweg aangeeft bij een functie of hij wel of niet exposed is, of dat je (heel specifiek) hem wel in je .h wil hebben maar niet in je .m. Nu is het alleen maar een bron van fouten terwijl je 99% van de tijd niet gebruik maakt van iets wel in de .h hebben maar niet in de .m.

Scott schreef op vrijdag 18 oktober 2013 @ 20:24:
[...]

Klopt, dat hoor je normaal gesproken ook gewoon niet te doen. Aan de ene kant zeg je tegen anderen dat het object die methode implementeert, tegelijkertijd doe je dat niet. Dan moet je hem dus of implementeren, of niet zeggen dat je dat wel doet. Dynamig Method Resolution is een uitzondering, maar ik moet zeggen dat ik dat zelden gebruik.

Ik heb er echt een tijdje over na zitten denken waar ik het nou praktisch voor zou kunnen gebruiken zonder dat ik het niet leesbaarder op een andere makkelijker manier zou kunnen implementeren en ik heb echt geen idee. Misschien dat NSNotificationManager intern op die manier werkt?

[Struikrover]

.oisyn schreef op vrijdag 18 oktober 2013 @ 17:01:
Dat klinkt nog best lang.

350.000 x2, dus ongeveer 700.000 records vanaf file inlezen. Vind het wel netjes. Kanook minder lang duren, ik heb het niet geklokt

[Verwijderd]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 21:24:
het overnemen van de zelfde regel code van .h naar .m is gewoon iedere keer handmatig een hoop werk doen.

Je kan ook gewoon alles in de (C) .c/cpp file gooien. Of je IDE met een shortcut de text laten kopieren.

Mijn IDE houd gewoon een code model bij waar je met een shortcut een implementatie kunt aanmaken maken in de .cpp, of deze implementatie kan verplaatsen naar de .h (zowel in-class als buiten de class).

[ Voor 24% gewijzigd door Verwijderd op 18-10-2013 21:30 ]

[Alex)]

SSD gekocht

[Gamebuster]

Overwinning van deze avond:

Ik heb OpenCL werkend...
...met Java bindings (LWJGL)...
...in JRuby.

140 regels bagger, alleen om OpenCL code te compileren, te starten en het resultaat op te halen.
Mijn bevindingen zover:
Tijd nodig voor compileren en voorbereiden van de data: een eeuw
Tijd nodig voor de berekeningen op de videokaart: onmeetbaar snel

Toch maar mijn berekeningen complexer maken dan...

Volgende stap: Vertex objects in OpenGL manipuleren.

Uiteindelijk plan: Mini game maken met heel veel bewegende sprites waarvan vrijwel alle game logica in OpenCL draait en direct vertexes bewerkt in OpenGL met het resultaat om de beperking in drawcalls te omzeilen.

[ Voor 24% gewijzigd door Gamebuster op 18-10-2013 22:42 ]

[Scott]

BikkelZ schreef op vrijdag 18 oktober 2013 @ 21:24:
[...]


Right dus het is gewoon een stukje erfenis van C. Ik zou zeggen dat XCode daar ook wel een stukje in zou kunnen helpen, het overnemen van de zelfde regel code van .h naar .m is gewoon iedere keer handmatig een hoop werk doen. Lijkt mij dat het redelijk makkelijk in elkaar te vouwen is tot één file waarbij je simpelweg aangeeft bij een functie of hij wel of niet exposed is, of dat je (heel specifiek) hem wel in je .h wil hebben maar niet in je .m. Nu is het alleen maar een bron van fouten terwijl je 99% van de tijd niet gebruik maakt van iets wel in de .h hebben maar niet in de .m.

Ik ben het wel met je eens ja. Het simpelste op dit moment is een methode eerst toevoegen aan de interface (.h), en dan simpelweg de method signature beginnen te typen. Xcode zal hem dan automatisch voor je afmaken. Dat vind ik wel één van Xcode's sterke punten: autocompletion is echt super. VS heeft dat ook, maar die vind ik toch iets minder goed. Of misschien gebruik ik VS gewoon niet genoeg.

Ik heb er echt een tijdje over na zitten denken waar ik het nou praktisch voor zou kunnen gebruiken zonder dat ik het niet leesbaarder op een andere makkelijker manier zou kunnen implementeren en ik heb echt geen idee. Misschien dat NSNotificationManager intern op die manier werkt?

In onder andere Core Data wordt dat veel gebruikt. Kan me niet veel situaties bedenken waarbij je zegt "ik weet dat die methode niet bestaat, maar je kunt 'm toch messagen, komt goed bij runtime".

Oh, en 't is NSNotificationCenter (op iOS althans)

[BikkelZ]

Hoeveel mensenjaren aan potentieel werk zouden er vernietigd zijn puur doordat ADP zo'n baggerprogramma is? Ik dacht dat het een hier door een stagiaire in elkaar gedraaid afstudeerprojectje was puur afgaand op de interface maar blijkbaar is het een wereldwijd miljardenbedrijf.

Beste ADP: wat dacht je er van dat ik iedere week gewoon 40 uur werk behalve in de weekends en op feestdagen. Misschien dat ik daar heel uniek in ben en dat ik mezelf tot de standaard bombardeer maar ik heb zo'n donkerbruin vermoeden dat bij wel meer mensen hun werkweek er structureel het zelfde uit ziet. Ben ik een keer ziek of op vakantie? Werk ik over op uurtje factuurtje? Kom ik je met alle plezier invullen.

Scott schreef op vrijdag 18 oktober 2013 @ 23:02:
[...]

VS heeft dat ook, maar die vind ik toch iets minder goed. Of misschien gebruik ik VS gewoon niet genoeg.

Ik denk dat VS sowieso beter is, maar het is lang geleden dat ik het zonder ReSharper gebruikt heb.

Scott schreef op vrijdag 18 oktober 2013 @ 23:02:
[...]

Oh, en 't is NSNotificationCenter (op iOS althans)

Zou zomaar kunnen

[ Voor 27% gewijzigd door BikkelZ op 18-10-2013 23:04 ]

[Alex)]

Ik ken ADP alleen als 'die brakke website waar ik mijn loonstrook kan inzien', maar wat heb ik een hekel aan dat ding zeg. Mijn inlognaam is heel onlogisch (een onbestaand e-mailadres) en het wachtwoord moet periodiek gewijzigd worden...

Waarom niet gewoon modern doen en identity federation implementeren?

[BikkelZ]

Iemand bij ADP heeft kennelijk lucht gekregen van mijn vuilspuiterij, ik kreeg een melding over een lege regel op zaterdag dat de klant niet leeg mocht zijn en tijdens het editen werd ineens de hele timecard weggeflikkerd.

Way to go!

[ZpAz]

Scott schreef op vrijdag 18 oktober 2013 @ 23:02:
[...]

Oh, en 't is NSNotificationCenter (op iOS althans)

Volgens mij maakt NSNotificationCenter daar geen gebruik van. Want die doet niet meer dan registerForKey: en changeForKey: en iets in die trend.

Dat lijkt me gewoon worden bijgehouden in een key value storage wie waarop geregistreerd is.

De KVO maakt er ook geen gebruik van Scott hierboven, die subclassed blijkbaar een object @ runtime als je naar key changes wil luisteren.

[.oisyn]

Struikrover schreef op vrijdag 18 oktober 2013 @ 21:28:
[...]


350.000 x2, dus ongeveer 700.000 records vanaf file inlezen. Vind het wel netjes. Kanook minder lang duren, ik heb het niet geklokt

Stel 200 bytes per regel, dan is het dus 140MB. Dat lees je doorgaans in zo'n 2 tot 5 seconden. Waar het waarschijnlijk fout gaat is het inserten in een db voor je de join doet, kan waarchijnlijk veel sneller direct vanuit mem. Imho moet alles binnen 10s te doen zijn

[Alex)]

Maar dan heb je geen excuus meer om even koffie te gaan drinken, snap dat dan!

[Douweegbertje]

Wilde altijd een 'dev' blogje gaan bijhouden met een beetje wat ik doe; niet dat ik mij zo speciaal voel maar ik zit altijd met "uitdagingen" te werken die meestal vrij 'hacky' zijn (al noem ik het zelf ingenieus ). Leek me wel leuk om dit te gaan sharen op een eigen website in plaats van random blogs van websites zodat ik zelf kan genieten van wat schamele adsense inkomsten

anyways mijn punt; nog een domein naam gevonden die nog vrij was, ben er wel happy mee: devrant.com

[Ryur]

douweegbertje schreef op vrijdag 18 oktober 2013 @ 23:42:
anyways mijn punt; nog een domein naam gevonden die nog vrij was, ben er wel happy mee: devrant.com

Haha, ik had vannochtend juist devrants.nl besteld!

[Caelorum]

Wie gaat wie uitkopen? ^^

[Douweegbertje]

haha ach dat maakt niet veel uit, daarbij .com > nl vooral met een Engelse naam

[sig69]

Ach ach ADP Meer wil ik er niet over kwijt.
Ik ben wat met knockoutMVC aan het spelen geweest, en met m'n meest simpele usecase loop ik al tegen issues aan. Het "voelt" wat mij betreft nog niet heel volwassen aan, ik mis dingen

[Verwijderd]

pff

Ik had vanmiddag veel moeite gedaan om ervoor te zorgen dat mijn job queue fatsoenlijk werkt en voor het grootste gedeelte lock free is.

Dus ik maak een loopje om het verhaal te benchmarken.. en ik krijg meteen heap corruption all over the place. En natuurlijk alleen in release mode.

Edit: dat komt dus doordat je een zware testcase in elkaar zet, en daarbij MAX_JOBS vergeet

[ Voor 14% gewijzigd door Verwijderd op 19-10-2013 00:56 ]

[Scott]

ZpAz schreef op vrijdag 18 oktober 2013 @ 23:18:
[...]


Volgens mij maakt NSNotificationCenter daar geen gebruik van. Want die doet niet meer dan registerForKey: en changeForKey: en iets in die trend.

Dat lijkt me gewoon worden bijgehouden in een key value storage wie waarop geregistreerd is.

De KVO maakt er ook geen gebruik van Scott hierboven, die subclassed blijkbaar een object @ runtime als je naar key changes wil luisteren.

Ik bedoelde eigenlijk meer dat het niet NSNotificationManager, maar NSNotificationCenter is. Denk inderdaad niet dat die gebruik maakt van @dynamic, hoewel de callstack altijd wel interessant is om te zien als er een notificatie bij komt kijken.

[Struikrover]

.oisyn schreef op vrijdag 18 oktober 2013 @ 23:24:
[...]

Stel 200 bytes per regel, dan is het dus 140MB. Dat lees je doorgaans in zo'n 2 tot 5 seconden. Waar het waarschijnlijk fout gaat is het inserten in een db voor je de join doet, kan waarchijnlijk veel sneller direct vanuit mem. Imho moet alles binnen 10s te doen zijn

Enlighten me, please? Hintje in de goede richting? Altijd geinteresseerd in snelheidswinst . Ik doe idd eerst een insert met beide files.

EDIT: ik blijf het leuk vinden als mijn vriendin onze kat roept. "Django, kom dan!".

[ Voor 14% gewijzigd door Struikrover op 19-10-2013 10:16 ]

[Douweegbertje]

Zelf nooit gedaan maar ik gok:

code:

BULK_INSERT_BUFFER_SIZE

Dat lekker hoog zetten bij je insert (gewoon tegen je max van je geheugen aan). En vervolgens de "LOAD DATA" feature gebruiken. Grofweg gezien zou je dan inderdaad rond de 10 seconden moeten gaan zitten voor ongeveer 400k-500k records.

[Verwijderd]

Geometry generation:

C++:

_particles.reserve( veel );

for( ;; )
{
        _particles.emplace_back( a, b, c );
        _particles.emplace_back( a, b, c );
        _particles.emplace_back( a, b, c );
        _particles.emplace_back( a, b, c );
}

150-160 fps.

C++:

_particles.resize( veel ); // resize niet reserve

for( ;; )
{
        _particles[i++] = Particle( a, b, c );
        _particles[i++] = Particle( a, b, c );
        _particles[i++] = Particle( a, b, c );
        _particles[i++] = Particle( a, b, c );
}

100-105 fps

HUH?

C++:

_particles.resize( veel );

for( ;; )
{
        new (&_particles[i++]) Particle( a, b, c );
        new (&_particles[i++]) Particle( a, b, c );
        new (&_particles[i++]) Particle( a, b, c );
        new (&_particles[i++]) Particle( a, b, c );
}

170-180 fps

Nooit gedacht dat die lelijke placement new syntax nog ergens nuttig voor zou zijn. En belangrijker, dat de compiler die zinloze copy van trivial object met default-copy constructor niet wegoptimaliseert.

Edit: Die neem ik terug. Bij nader inzien blijkt het een non-trivial datatype te zijn.

[ Voor 8% gewijzigd door Verwijderd op 19-10-2013 14:29 ]

[alienfruit]

Haha, ADP dat klinkt net zo erg als SAP of Sharepoint timesheet bagger

[Ealanrian]

O joy, via TeamViewer werken op een systeem wat een 100km verder op staat. Ik had ondertussen toch iets meer performance verwacht eigenlijk...

[D-Raven]

Ealanrian schreef op zaterdag 19 oktober 2013 @ 13:05:
O joy, via TeamViewer werken op een systeem wat een 100km verder op staat. Ik had ondertussen toch iets meer performance verwacht eigenlijk...

Ligt niet aan teamviewer. Ligt aan de verbinding, en de performance van de machine waarmee je verbind (in mindere mate).

[.oisyn]

Verwijderd schreef op zaterdag 19 oktober 2013 @ 10:58:
Nooit gedacht dat die lelijke placement new syntax nog ergens nuttig voor zou zijn.

Dan heb je waarschijnlijk ook nog nooit met eigen allocators gewerkt

En je code is conceptueel broken, afgezien van de compile error

[Ealanrian]

Hmm dat is wel apart dan. Ik heb hier 100/100 daar ligt een 500/500+ lijn (geen idee wat het daadwerkelijk is.) PC daar is een i5 met 8GB ram waar momenteel alleen ik aan werk. Grootse probleem is het af en toe gewoon niet reageren, wegvallen van de verbinding en gewoon traag voelen. Maar misschien stel ik te hoge eisen.

[simon]

Zul je zien. Net als je thuis lekker je kleine appjes van Rails 3 naar 4 aan 't migreren bent is GitHub down.

[Verwijderd]

.oisyn schreef op zaterdag 19 oktober 2013 @ 14:09:
[...]

En je code is conceptueel broken, afgezien van de compile error

Die = hoort daar niet te staan nee.. copy-paste fout.

[Caelorum]

Heh, weer wat geleerd over C++ ^^ thnx @ Darkstone en .oisyn

[azerty]

Joepie... Mag leren voor een examen maandag en dinsdag