search for: mayerhofer

2015-04-27 15:02 GMT+02:00 Charles Lepple <clepple at gmail.com>: > On Apr 27, 2015, at 2:48 AM, Nick Ma. <nick.mayerhofer at enchant.at> wrote: > > > But it still doesn't compile any executable: ~/nut/tests% ls > > cpputest.cpp example.cpp Makefile Makefile.am Makefile.in > > I think it is only intended to produce an executable when running "make > check" or the dist* target...

On 27/04/15 00:35, Charles Lepple wrote: > autoreconf has to be run from the top level directory. I did that too. > (Not related to this issue, but you might want to use the autogen.sh > script to catch any other dependencies, then add > --enable-maintainer-mode to the configure parameters so you don't need > to manually re-run the auto-tools.) Do you have cppunit installed? I

Hi, I'm trying to get the automated testcases in nut/tests/ working. But I just cant get a binary out of the build system. The nut/tests/ folder looks good% ls cpputest.cpp example.cpp Makefile Makefile.am Makefile.in and I also tried "autoreconf -i" which gave me an: autoreconf: 'configure.ac' or 'configure.in' is required Any ideas? Best

On Apr 26, 2015, at 5:05 PM, "Nick Ma." <nick.mayerhofer at enchant.at> wrote: > and I also tried "autoreconf -i" which gave me an: > autoreconf: 'configure.ac' or 'configure.in' is required autoreconf has to be run from the top level directory. (Not related to this issue, but you might want to use the autogen.sh scri...

On Apr 27, 2015, at 2:48 AM, Nick Ma. <nick.mayerhofer at enchant.at> wrote: > But it still doesn't compile any executable: ~/nut/tests% ls > cpputest.cpp example.cpp Makefile Makefile.am Makefile.in I think it is only intended to produce an executable when running "make check" or the dist* targets. -- Charles Lepple clepp...

Hi and thank you for your effort. You are very close to what I want to achieve, but I was already aware of the impossibility of querying direct from a command. I wanted the following (both would be covered by your changes): 1. preprocess an item_t in the direction: NUT->DEVICE in order to be able to support queries like ups.generated.yesterday

...Nvidia NT6x driver information. wined3d: Add AMD NT6x drivers. wined3d: Add Intel gpu and driver information. wined3d: Add legacy ATI cards. wined3d: Store amount of video memory in gpu_description_table. wined3d: Move video memory override to init_driver_info. Rudolf Mayerhofer (1): kernel32: Implement GetUserDefaultLocaleName using users default LCID. Stefan Leichter (1): setupapi: Added tests for SetupDiGetINFClassA. Sven Baars (4): ipconfig: Update the Dutch translation. shdocvw: Update the Dutch translation. shell32: Update the Dutch tr...

...EFLECTION_DATA test. d3d10: Forward D3D10GetInputSignatureBlob() to d3dcompiler. d3d10: Forward D3D10GetOutputSignatureBlob() to d3dcompiler. d3d10: Forward D3D10GetInputAndOutputSignatureBlob() to d3dcompiler. d3d10: Forward D3D10GetShaderDebugInfo() to d3dcompiler. Rudolf Mayerhofer (2): ntdll: Set CPU_FEATURE_HTT when running on a HTT capable system. include: Add information class SystemLogicalProcessorInformation. Stefan D?singer (2): ddraw: Don't try to enumerate WINED3DFMT_R8G8B8A8_SNORM. ddraw: Handle WINED3DFMT_R16G16_SNORM. Stefan Leichter...

Hi, I tested nutdrv_qx additions, introduced by @zykh, for a couple of months now and changed only small things. You can reach the repository via [1]. Please review the item_t array (starting at [2]) and give me feedback, or change it directly. Missing is the complete documentation, which I'm trying to get time for since the last six months, but I don't. Best, Nick [1]

Hi, it has been a while now since the last changes to the Voltronic Sunny code, because it's working just fine. I saw that there are a lot of changes in the master tree and my question is what I should do with the Voltronic Sunny part? Does it still make sense to try to make a pull-request out of it? Best, Nick

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional