#wine-staging

slackner: sheesh, looks like they forgot to block you on your d3dx9 patch

;)

puk: wow, no ack necessary ? ;)

yeah, I was shocked

for this release the commit stats for wine staging are pretty awesome :)

both the upstream stats but also the stats of newly added patches *g*

(doesn't include changes from today yet)

slackner: yeah, but you are cheating

why? xD

most of your patches wouldn't need to go to staging

;)

except d3dx

;)

xD

well, some patches for example still miss some tests

true dat

so yeah, for a quick "try this out" on bugzilla, it makes sense

puk: true, but .. if wine would have required tests for everything so far - you know what the current state would be ;)

its always a bit risky, but there is a big chance that these changes are perfectly fine xD

(especially when they are from a focht analysis)

this is the only bug i have in mind where the focht analysis was wrong: https://bugs.winehq.org/show_bug.cgi?id=27282 ;)

well it depends

for net new code tests aren't necessary needed

unless you have a behavior that isn't obviously correct

well, even then AJ often wants test, even if its just to ensure that noone breaks it again

right

but tests can be time intensive, especially when testing them on the slow testbot machines ... xD

i learned it the hard way

after somebody broke my PERFECT code for calculating the hotspot for an ImageList_Drag

and broke the app I was testing with

i wrote tests and it turned out that we both were wrong

;)

hehe, yeah, that also happens from time to time xD

in some cases (for example the LZNT1 decompression patches) i gave up reproducing the exact windows behaviour after i noticed, that its _extremely_ broken there ;)

right

sometimes you don't bother for the extreme corner cases and bugs

i mean the undefined/unspecified behavior

yup

are you really planning to get those last-minute patches in ? :P ^^

lol, no

just spoon feeding those to AJ

i have 3 more ready

;)

i read you already have a script for that ^^

sure

but some code is questionable

and I get bored at reviewing the diff

well, i would recommend to mainly concentrate on the dll code

tests don't really matter much at my opinion

not that much left

and if you ask me, they should be excluded completely from automatic code check tools

(until they are better xD)

it is just a nice cleanup

nothing else

for readability

not for the 0,00000001% performance improvement? ;)

hell no

that one doesn't matter

i think in some cases it could indeed have an effect, when the code works with use texts

*huge

right

but i agree, in most cases you'll not really notice it xD

that's why I send those in slowly ;)

can be fixed

well, nevertheless - maybe someone should really check again all the algorithms

just think about the performance improvement of replacing linked lists with hash tables and stuff xD

but AJ might react allergic if I flood him with those

THAT is my main gripe with C

no usable generic data types in the standard

lists, hashes

puk: yeah, but some of the things you can do with C-style list macros are not possible with such generic data types

e.g. I love working with sets in python

(just think about adding the same element to multiple lists and things like that)

puk: i also like python because its so easy to write down some quick code ;)

slackner: yeah, unless I need a lot of regexps

then I find python strange

and some things aren't intuitive

puk: yeah, especially some internal APIs are often a bit weird

puk: and i also hate that its not even proper multithreaded

but besides that its pretty awesome ;)

and pypy too ^^

yeah

don't get me started on join()...

i have no clue why that is a method of the separator

instead of the list

well, I know

because of the limitations of "everything is an object" to match the real world

yeah, in this case the opposite would be much more intuitive

slackner: right, but they can't do it there as the list/array might not have a "to string" method

meh

well, they could have done it

but probably didn't look "clean" to them

yeah - too bad that there is no language with all the advantages combined, noone finds a good compromise between simplicity, speed, ...

well, functional works too for the join

str.join(":", ('foo','bar'))

but until I remember that it is str and not string

sure, but thats even more ugly xD

and wasted time looking for the method in dir(array()) ...

puk: <stringfellow> julliard: 107663,107664,107665,107666,107667,107668,107669,107674

puk: thats a bit late ;)

titan38: seems like the bot works now, was only the first day that the log was truncated

slackner: yeah seems to work fine now :)

slackner: I updated https://github.com/wine-compholio/wine-staging/...

titan38: yup, got the notification mail

slackner: I will do that this week-end. Can you see for makefiles?

titan38: yup, will take a look, but would be nice to have a working example, otherwise its a bit difficult to test

DarkPlayer also pointed out that its probably not really necessary to add a testing framework globally - instead it would also be sufficient, when only the ntoskrnl tests Makefile behaves differently.

which is probably a bit easier

slackner: no problem that would be enough as a start

guys

slackner: I will send you the test case so you can modify the makefile

you're talking about testing drivers.. can the kmtests framework help ?

titan38: nice :)

AmineKhaldi: yup what is kmtests

?

AmineKhaldi: kk thx will take a look

AmineKhaldi: i fear that not a single existing test will run with the very limited wine ntoskrnl implementation

AmineKhaldi: but the framework could be useful ;)