Alex, it's one line to change in the build.xml

<exec executable="${env.PIXELBENDER_HOME}/sniffer_gpu.exe"/>

I will give it a try and we will know in 15 min.

I am sure the result will be interesting.

Anyway, it can't hurt ;-)

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 10 décembre 2013 20:29
À : dev@flex.apache.org
Objet : Re: [Builds/Jenkins] Help and advise needed

I think I'll wait to see how Gavin responds to Erik's latest request.

BTW, thanks for finding out about the tool.

-Alex

On 12/10/13 11:27 AM, "Maurice Amsellem" <maurice.amsel...@systar.com>
wrote:

>Sure, if you can ask him.
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 10 décembre 
>2013 20:26 À : dev@flex.apache.org Objet : Re: [Builds/Jenkins] Help 
>and advise needed
>
>Might be simpler just to ask Gavin to run the tool?
>
>On 12/10/13 11:12 AM, "Maurice Amsellem" <maurice.amsel...@systar.com>
>wrote:
>
>>There is a utility in pixel bender toolkit directory called 
>>"sniffer_gpu.exe" that check the presence and version of OpenGL:
>>
>>Console output on my laptop is below:
>>
>>C:\Program Files (x86)\Adobe\Adobe Utilities - CS5\Pixel Bender 
>>Toolkit
>>2>sniffer_gpu.exe
>>Device: 0058A9F4 has video RAM(MB): 512
>>Vendor string:    NVIDIA Corporation
>>Renderer string:  NVS 4200M/PCI/SSE2
>>Version string:   3.0.0
>>
>>OpenGL version as determined by Extensionator...
>>OpenGL Version 3.0
>>Has NPOT support: TRUE
>>Has Framebuffer Obeject Extension support: TRUE Completed shader test!
>>Return code: 7
>>
>>Maybe we could temporarily modify the build to run this utility and 
>>show the output on the b.a.o vm.
>>
>>WDYT ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 10 décembre
>>2013 18:15 À : dev@flex.apache.org Objet : Re: [Builds/Jenkins] Help 
>>and advise needed
>>
>>I don't think we actually know the cause of the problem.  I am going 
>>to continue to spend cycles to try to find out though.
>>
>>It would be nice to have an alternative to builds.a.o.  I'm not sure 
>>if it will cost Om money to run a builds server.
>>
>>-Alex
>>
>>On 12/10/13 2:01 AM, "Maurice Amsellem" <maurice.amsel...@systar.com>
>>wrote:
>>
>>>I understand that.
>>>
>>>Actually, my "understanding" on this issue was that pixel bender 
>>>compiler required some sort of hardware configuration (OpenGL, 
>>>etc...) that were not present on the b.a.o. new Windows Jenkins slave 
>>>node, so that's why the build was failing,  and the Apache Infra was 
>>>reluctant to let us modify anything, or even access the VM ourselves.
>>>So that's why I was proposing a "software only" solution.
>>>
>>>Now, it seems from what Om is saying that we can set up and use our 
>>>own Jenkins slave node VM.
>>>
>>>That, of course, is much preferable...
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 10 
>>>décembre 2013 10:44 À : dev@flex.apache.org Objet : Re:
>>>[Builds/Jenkins] Help and advise needed
>>>
>>>Maurice,
>>>
>>>Your help is very much appreciated!
>>>
>>>I put "legal" in quotes, the issue is not really one of the law, more 
>>>of the rules. An Apache release is supposed to be 'source only', and 
>>>we if we can produce needed binaries from source, we keep only the 
>>>source, not the artefacts themselves in the repo.
>>>
>>>
>>>EdB
>>>
>>>
>>>
>>>On Tue, Dec 10, 2013 at 10:34 AM, Maurice Amsellem 
>>><maurice.amsel...@systar.com> wrote:
>>>>>In addition to the various "legal" issues with binaries in the repo.
>>>> I understand it's not a good idea to have binaries in the repo, so 
>>>>I won't insist.
>>>> But please can you explain what are the legal issues of having 
>>>>binaries in the repo?  Is this because of Adobe, or ASF rules ?
>>>>
>>>> On a side note, I was just trying to help, with my limited 
>>>> understanding and knowledge, and because the email thread was 
>>>> titled "help and advise needed" ;-)
>>>>
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 10 
>>>> décembre 2013 09:12 À : dev@flex.apache.org Objet : Re:
>>>> [Builds/Jenkins] Help and advise needed
>>>>
>>>> In addition to the various "legal" issues with binaries in the 
>>>>repo, we'd be masking the cause of this failure. In order to prevent 
>>>>further deterioration of the build process, we need to figure out 
>>>>what went wrong and fix it.
>>>>
>>>> EdB
>>>>
>>>> PS. Thanks for leaving the keyboard on the Mustella VM set to FR...
>>>> Took me while to figure out that I hadn't gone insane or if my 
>>>> keyboard was broken ;-)
>>>>
>>>>
>>>>
>>>> On Tue, Dec 10, 2013 at 9:04 AM, Maurice Amsellem 
>>>><maurice.amsel...@systar.com> wrote:
>>>>>> someone who does use the pbj's will grab the nightly and complain.
>>>>>
>>>>> I don't understand.
>>>>> Why would someone complain if the pbj's are in the nightly?
>>>>>
>>>>> [From the other emai]
>>>>>>Apache repos aren't supposed to contain compiled code.  The pbj 
>>>>>>files were removed during the initial release audit.
>>>>>>I don't think a workaround can involve checking in the pbj files.
>>>>>>But we could borrow them from a prior release package temporarily.
>>>>>
>>>>>>So we could make the compilation conditional on a env parameter, 
>>>>>>and set that in the Jenkins job accordingly?
>>>>>>Yes but ...
>>>>>
>>>>> Alex, the conversation is getting out synch, so I am not sure that 
>>>>>I have understood what you said.
>>>>>
>>>>> So can we include the pbj in the repo, and have a parameter to 
>>>>>conditionally compile the pbj ?
>>>>> - This parameter would be set by default to do the compilation (so 
>>>>>that folks can recompile)
>>>>> - and turned off on the b.a.o vm, with pre-compiled pbj's.
>>>>>
>>>>>
>>>>> Maurice
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>
>>>
>>>
>>>--
>>>Ix Multimedia Software
>>>
>>>Jan Luykenstraat 27
>>>3521 VB Utrecht
>>>
>>>T. 06-51952295
>>>I. www.ixsoftware.nl
>>
>

Reply via email to