Release patches 7.8.2 #2065
Closed
Release patches 7.8.2 #2065
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…aSointusalo. Juha had a good point in pull-request BOINC#1860, capture the bug fix before it gets lost in the sands of time.
As requested in BOINC#1935 to add the possibility to select any text in this window.
Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
The client flushes stdout and stderr at every iteration of the main loop. On Windows, stderr is opened in commit mode and this results in a write to NTFS $Log every time the stream is flushed even if nothing was written to the stream since last flush. These unnecessary writes totals to several hundred megabytes per day. Some users are concerned that this shortens the lifespan of their hardware. Fix this by removing the flushes from main loop. stderr is unbuffered so it never needed the flush. After freopen() in diagnostics_init() stdout is fully buffered. Change stdout to line buffered mode so that log messages are visible in log files immediately. MSVCRT doesn't support line buffered streams. It treats them as fully buffered. Emulate line buffered stream by flushing stdout in logging functions when compiling with Visual C++.
If the link were max_len bytes long or longer, the null terminator would have been written one past the end of path.
Makes it easier to see which task had problems when reading logs afterwards. Also include back off time in notice and drop fractional seconds.
…in a more graceful way. Original email from Juha Sointusalo <juha.sointusalo@gmail.com>: Manager built from master 05172b8, about the same as 7.8.0. Debug build, with wxWidgets asserts directed to log file and BOINC's own crash handler disabled. I was scrolling Event Log when debugger popped up. Should it make any difference, I had gui_rpc_debug enabled and because of that the Event Log had new messages coming in all the time. Continuing from the assert would have crashed Manager. -Juha (21b4.240c): Break instruction exception - code 80000003 (!!! second chance !!!) *** WARNING: Unable to verify checksum for C:\BOINC\boincmgr.exe MSVCP120D!std::_Debug_message+0x46: 00007ffd`3e4d65d6 cc int 3 0:000> kP # Child-SP RetAddr Call Site 00 000000fb`92af9e60 00007ff7`097282d4 MSVCP120D!std::_Debug_message( wchar_t * message = 0x00007ff7`0a0a9210 "deque iterator not dereferencable", wchar_t * file = 0x00007ff7`0a0a9110 "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\deque", unsigned int line = 0x14a)+0x46 [f:\dd\vctools\crt\crtw32\stdcpp\stdthrow.cpp @ 15] 01 000000fb`92af9ea0 00007ff7`09728428 boincmgr!std::_Deque_const_iterator<std::_Deque_val<std::_Deque_simple_types<MESSAGE * __ptr64> > >::operator*(void)+0x84 [c:\program files (x86)\microsoft visual studio 12.0\vc\include\deque @ 331] 02 000000fb`92af9f00 00007ff7`0972b996 boincmgr!std::_Deque_iterator<std::_Deque_val<std::_Deque_simple_types<MESSAGE * __ptr64> > >::operator*(void)+0x28 [c:\program files (x86)\microsoft visual studio 12.0\vc\include\deque @ 604] 03 000000fb`92af9f30 00007ff7`0971baf5 boincmgr!std::deque<MESSAGE * __ptr64,std::allocator<MESSAGE * __ptr64> >::at( unsigned int64 _Pos = 0x1b)+0xa6 [c:\program files (x86)\microsoft visual studio 12.0\vc\include\deque @ 1381] 04 000000fb`92af9fc0 00007ff7`0962f734 boincmgr!CMainDocument::message( unsigned int i = 0x1b)+0x65 [c:\dev\boinc\src\clientgui\maindocument.cpp @ 2116] 05 000000fb`92afa030 00007ff7`0962df80 boincmgr!CDlgEventLog::FormatProjectName( int item = 0n27, class wxString * strBuffer = 0x000000fb`92afa0f8)+0x64 [c:\dev\boinc\src\clientgui\dlgeventlog.cpp @ 1018] 06 000000fb`92afa0d0 00007ff7`096337f0 boincmgr!CDlgEventLog::OnListGetItemText( long item = 0n27, long column = 0n0)+0xd0 [c:\dev\boinc\src\clientgui\dlgeventlog.cpp @ 965] 07 000000fb`92afa170 00007ff7`0994652d boincmgr!CDlgEventLogListCtrl::OnGetItemText( long item = 0n27, long column = 0n0)+0x130 [c:\dev\boinc\src\clientgui\dlgeventloglistctrl.cpp @ 123] 08 000000fb`92afa1c0 00007ff7`098e1a8b boincmgr!wxListCtrl::MSWOnNotify( int idCtrl = 0n6403, int64 lParam = 0n1080497781776, int64 * result = 0x000000fb`92afaa48)+0x12cd [c:\src\sdks\wx302\src\msw\listctrl.cpp @ 2511] 09 000000fb`92afa9b0 00007ff7`098db872 boincmgr!wxWindow::HandleNotify( int idCtrl = 0n6403, int64 lParam = 0n1080497781776, int64 * result = 0x000000fb`92afaa48)+0x7b [c:\src\sdks\wx302\src\msw\window.cpp @ 3832] 0a 000000fb`92afaa00 00007ff7`098dcfcb boincmgr!wxWindow::MSWHandleMessage( int64 * result = 0x000000fb`92afb408, unsigned int message = 0x4e, unsigned int64 wParam = 0x1903, int64 lParam = 0n1080497781776)+0x962 [c:\src\sdks\wx302\src\msw\window.cpp @ 3047] 0b 000000fb`92afb3d0 00007ff7`098f7d33 boincmgr!wxWindow::MSWWindowProc( unsigned int message = 0x4e, unsigned int64 wParam = 0x1903, int64 lParam = 0n1080497781776)+0x8b [c:\src\sdks\wx302\src\msw\window.cpp @ 3645] 0c 000000fb`92afb590 00007ff7`0990ce6e boincmgr!wxTopLevelWindowMSW::MSWWindowProc( unsigned int message = 0x4e, unsigned int64 wParam = 0x1903, int64 lParam = 0n1080497781776)+0x263 [c:\src\sdks\wx302\src\msw\toplevel.cpp @ 467] 0d 000000fb`92afb640 00007ff7`098e3052 boincmgr!wxDialog::MSWWindowProc( unsigned int message = 0x4e, unsigned int64 wParam = 0x1903, int64 lParam = 0n1080497781776)+0x13e [c:\src\sdks\wx302\src\msw\dialog.cpp @ 436] 0e 000000fb`92afb690 00007ffd`66151c24 boincmgr!wxWndProc( struct HWND__ * hWnd = 0x00000000`003703f8, unsigned int message = 0x4e, unsigned int64 wParam = 0x1903, int64 lParam = 0n1080497781776)+0x252 [c:\src\sdks\wx302\src\msw\window.cpp @ 2711] 0f 000000fb`92afb850 00007ffd`6615125e USER32!UserCallWinProcCheckWow+0x274 10 000000fb`92afb9b0 00007ffd`66150ff5 USER32!SendMessageWorker+0x20e 11 000000fb`92afba40 00007ffd`57d74df6 USER32!SendMessageW+0x105 12 000000fb`92afbaa0 00007ffd`57d75464 COMCTL32!CCSendNotify+0xf6 13 000000fb`92afbbb0 00007ffd`57ed1146 COMCTL32!CLVItemStore::OnGetItem+0x274 14 000000fb`92afbd80 00007ffd`57ed0fc4 COMCTL32!CLVDrawItemManager::ComputeTextWidth+0xa2 15 000000fb`92afc040 00007ffd`57dc32b3 COMCTL32!CLVIconView::IsItemUnfolded2+0x228 16 000000fb`92afca40 00007ffd`57d78a2d COMCTL32!`DuiTelemetry::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x10bf3 17 000000fb`92afdc00 00007ffd`57d765a2 COMCTL32!CListView::WndProc+0x57d 18 000000fb`92afde60 00007ffd`66151c24 COMCTL32!CListView::s_WndProc+0x72 19 000000fb`92afded0 00007ffd`661517bb USER32!UserCallWinProcCheckWow+0x274 1a 000000fb`92afe030 00007ffd`57d687e0 USER32!CallWindowProcW+0x8b 1b 000000fb`92afe080 00007ffd`57d688fa COMCTL32!CallNextSubclassProc+0xb0 1c 000000fb`92afe150 00007ffd`57d68682 COMCTL32!CallNextSubclassProc+0x1ca 1d 000000fb`92afe220 00007ffd`66151c24 COMCTL32!MasterSubclassProc+0xa2 1e 000000fb`92afe2c0 00007ffd`661517bb USER32!UserCallWinProcCheckWow+0x274 1f 000000fb`92afe420 00007ff7`098dd202 USER32!CallWindowProcW+0x8b 20 000000fb`92afe470 00007ff7`098dd129 boincmgr!wxWindow::MSWDefWindowProc( unsigned int nMsg = 0x4e, unsigned int64 wParam = 0, int64 lParam = 0n1080497794320)+0x92 [c:\src\sdks\wx302\src\msw\window.cpp @ 2270] 21 000000fb`92afe550 00007ff7`0994794b boincmgr!wxWindow::MSWWindowProc( unsigned int message = 0x4e, unsigned int64 wParam = 0, int64 lParam = 0n1080497794320)+0x1e9 [c:\src\sdks\wx302\src\msw\window.cpp @ 3651] 22 000000fb`92afe710 00007ff7`098e3052 boincmgr!wxListCtrl::MSWWindowProc( unsigned int nMsg = 0x4e, unsigned int64 wParam = 0, int64 lParam = 0n1080497794320)+0xab [c:\src\sdks\wx302\src\msw\listctrl.cpp @ 3061] 23 000000fb`92afe750 00007ffd`66151c24 boincmgr!wxWndProc( struct HWND__ * hWnd = 0x00000000`0025090c, unsigned int message = 0x4e, unsigned int64 wParam = 0, int64 lParam = 0n1080497794320)+0x252 [c:\src\sdks\wx302\src\msw\window.cpp @ 2711] 24 000000fb`92afe910 00007ffd`6615125e USER32!UserCallWinProcCheckWow+0x274 25 000000fb`92afea70 00007ffd`66150ff5 USER32!SendMessageWorker+0x20e 26 000000fb`92afeb00 00007ffd`57d74df6 USER32!SendMessageW+0x105 27 000000fb`92afeb60 00007ffd`57d9162d COMCTL32!CCSendNotify+0xf6 28 000000fb`92afec70 00007ffd`57d5624d COMCTL32!SendNotifyEx+0x6d 29 000000fb`92afece0 00007ffd`57d5613b COMCTL32!CToolTipsMgr::DoGetDispInfo+0xb9 2a 000000fb`92afee30 00007ffd`57d56018 COMCTL32!CToolTipsMgr::SetCurToolDispInfo+0x33 2b 000000fb`92afee70 00007ffd`57d55f75 COMCTL32!CToolTipsMgr::DoShowBubble+0x90 2c 000000fb`92afef50 00007ffd`57d55f17 COMCTL32!CToolTipsMgr::ShowBubbleForTool+0x35 2d 000000fb`92afef80 00007ffd`57d6a2a6 COMCTL32!CToolTipsMgr::HandleTimer+0x83 2e 000000fb`92afefb0 00007ffd`57d69be6 COMCTL32!CToolTipsMgr::ToolTipsWndProc+0x4e6 2f 000000fb`92aff1e0 00007ffd`66151c24 COMCTL32!CToolTipsMgr::s_ToolTipsWndProc+0x66 30 000000fb`92aff230 00007ffd`6615156c USER32!UserCallWinProcCheckWow+0x274 31 000000fb`92aff390 00007ffd`661542ff USER32!DispatchMessageWorker+0x1ac 32 000000fb`92aff410 00007ff7`09a1df97 USER32!IsDialogMessageW+0x10f 33 000000fb`92aff470 00007ff7`09a1deab boincmgr!wxGUIEventLoop::PreProcessMessage( struct tagMSG * msg = 0x000000fb`92aff528 {msg=0x113 wp=0x1 lp=0x0})+0xb7 [c:\src\sdks\wx302\src\msw\evtloop.cpp @ 97] 34 000000fb`92aff4c0 00007ff7`09a1e3b9 boincmgr!wxGUIEventLoop::ProcessMessage( struct tagMSG * msg = 0x000000fb`92aff528 {msg=0x113 wp=0x1 lp=0x0})+0x3b [c:\src\sdks\wx302\src\msw\evtloop.cpp @ 166] 35 000000fb`92aff4f0 00007ff7`097fb6d6 boincmgr!wxGUIEventLoop::Dispatch(void)+0x299 [c:\src\sdks\wx302\src\msw\evtloop.cpp @ 232] 36 000000fb`92aff5e0 00007ff7`097fb57d boincmgr!wxEventLoopManual::ProcessEvents(void)+0x66 [c:\src\sdks\wx302\src\common\evtloopcmn.cpp @ 173] 37 000000fb`92aff620 00007ff7`097fb06d boincmgr!wxEventLoopManual::DoRun(void)+0xbd [c:\src\sdks\wx302\src\common\evtloopcmn.cpp @ 206] 38 000000fb`92aff6c0 00007ff7`09774272 boincmgr!wxEventLoopBase::Run(void)+0x10d [c:\src\sdks\wx302\src\common\evtloopcmn.cpp @ 78] 39 000000fb`92aff750 00007ff7`09772db1 boincmgr!wxAppConsoleBase::MainLoop(void)+0xa2 [c:\src\sdks\wx302\src\common\appbase.cpp @ 334] 3a 000000fb`92aff7c0 00007ff7`099eae05 boincmgr!wxAppConsoleBase::OnRun(void)+0x31 [c:\src\sdks\wx302\src\common\appbase.cpp @ 260] 3b 000000fb`92aff7f0 00007ff7`09881347 boincmgr!wxAppBase::OnRun(void)+0x45 [c:\src\sdks\wx302\src\common\appcmn.cpp @ 305] 3c 000000fb`92aff820 00007ff7`098399e0 boincmgr!wxEntryReal( int * argc = 0x00007ff7`0a590ef0, wchar_t ** argv = 0x00000204`78683e10)+0x167 [c:\src\sdks\wx302\src\common\init.cpp @ 495] 3d 000000fb`92aff8f0 00007ff7`099ea5aa boincmgr!wxEntry( int * argc = 0x00007ff7`0a590ef0, wchar_t ** argv = 0x00000204`78683e10)+0x40 [c:\src\sdks\wx302\src\msw\main.cpp @ 188] 3e 000000fb`92aff930 00007ff7`09766bb4 boincmgr!wxEntry( struct HINSTANCE__ * hInstance = 0x00007ff7`094a0000, struct HINSTANCE__ * __formal = 0x00000000`00000000, char * __formal = 0x00000000`00000000 "", int nCmdShow = 0n1)+0x9a [c:\src\sdks\wx302\src\msw\main.cpp @ 415] 3f 000000fb`92aff9a0 00007ff7`09770351 boincmgr!WinMain( struct HINSTANCE__ * hInstance = 0x00007ff7`094a0000, struct HINSTANCE__ * hPrevInstance = 0x00000000`00000000, char * __formal = 0x00000204`78613d58 "", int nCmdShow = 0n1)+0x44 [c:\dev\boinc\src\clientgui\boincguiapp.cpp @ 58] 40 000000fb`92aff9d0 00007ff7`097700ce boincmgr!__tmainCRTStartup(void)+0x271 [f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c @ 618] 41 000000fb`92affa50 00007ffd`646d8364 boincmgr!WinMainCRTStartup(void)+0xe [f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c @ 466] 42 000000fb`92affa80 00007ffd`669f70d1 KERNEL32!BaseThreadInitThunk+0x14 43 000000fb`92affab0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 0:000> g (21b4.240c): Break instruction exception - code 80000003 (first chance) boincmgr!std::_Deque_const_iterator<std::_Deque_val<std::_Deque_simple_types<MESSAGE * __ptr64> > >::operator*+0xce: 00007ff7`0972831e cc int 3 0:000> g (21b4.240c): Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!) MSVCR120D!_invoke_watson+0x2b: 00007ffd`3396cfeb cd29 int 29h 0:000> kP 6 # Child-SP RetAddr Call Site 00 000000fb`92af9e20 00007ffd`3396cfb3 MSVCR120D!_invoke_watson( wchar_t * pszExpression = 0x00007ff7`09f03de0 ""out of range"", wchar_t * pszFunction = 0x00007ff7`0a147590 "std::_Deque_const_iterator<class std::_Deque_val<struct std::_Deque_simple_types<struct MESSAGE *> > >::operator *", wchar_t * pszFile = 0x00007ff7`0a0a9110 "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\deque", unsigned int nLine = 0x14b, unsigned int64 pReserved = 0)+0x2b [f:\dd\vctools\crt\crtw32\misc\invarg.c @ 132] 01 000000fb`92af9e50 00007ff7`0972834b MSVCR120D!_invalid_parameter( wchar_t * pszExpression = 0x00007ff7`09f03de0 ""out of range"", wchar_t * pszFunction = 0x00007ff7`0a147590 "std::_Deque_const_iterator<class std::_Deque_val<struct std::_Deque_simple_types<struct MESSAGE *> > >::operator *", wchar_t * pszFile = 0x00007ff7`0a0a9110 "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\deque", unsigned int nLine = 0x14b, unsigned int64 pReserved = 0)+0x83 [f:\dd\vctools\crt\crtw32\misc\invarg.c @ 86] 02 000000fb`92af9ea0 00007ff7`09728428 boincmgr!std::_Deque_const_iterator<std::_Deque_val<std::_Deque_simple_types<MESSAGE * __ptr64> > >::operator*(void)+0xfb [c:\program files (x86)\microsoft visual studio 12.0\vc\include\deque @ 342] 03 000000fb`92af9f00 00007ff7`0972b996 boincmgr!std::_Deque_iterator<std::_Deque_val<std::_Deque_simple_types<MESSAGE * __ptr64> > >::operator*(void)+0x28 [c:\program files (x86)\microsoft visual studio 12.0\vc\include\deque @ 604] 04 000000fb`92af9f30 00007ff7`0971baf5 boincmgr!std::deque<MESSAGE * __ptr64,std::allocator<MESSAGE * __ptr64> >::at( unsigned int64 _Pos = 0x1b)+0xa6 [c:\program files (x86)\microsoft visual studio 12.0\vc\include\deque @ 1381] 05 000000fb`92af9fc0 00007ff7`0962f734 boincmgr!CMainDocument::message( unsigned int i = 0x1b)+0x65 [c:\dev\boinc\src\clientgui\maindocument.cpp @ 2116] 0:000> g WARNING: Continuing a non-continuable exception (21b4.240c): Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!) MSVCR120D!_invoke_watson+0x2b: 00007ffd`3396cfeb cd29 int 29h Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
The function is documented to check if anything exists at the given path. The client depends on this behavior. If the function checks only for regular files the client will fail to clean up slot directories before using them for another task. Fix the function to match the documentation.
Fix text styles (font, size) and set backgroung to window default. Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
'Copy all' and 'Copy Selected' buttons added. Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
Better for the debug version to do the same thing as release. There's a #define you can change if you want GPU detection to happen in the main process.
The GPU detection code was already doing this; do for Win daemon process startup as well.
A result with a lot of failed uploads could overflow a 4K buffer. Change report_result_error() so you just pass it the error message, rather than va_args nonsense.
... none of which was a possible overrun, but doesn't hurt to check.
Originally requested in BOINC#601: Change OK button on Advanced Preferences to Save button. Button renamed in all dialogs with settings for consistency. Also now 'Cancel' button is default button. Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
Notices may have e.g. foo <br /> blah The manager replaces the newlines with <br>, resulting in three blank lines. Change this to one. TODO: the fix is a kludge.
Change text labels to remove inconsistency betweeb them and button text as described in BOINC#601 Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
|
I did shoddy job testing "client/lib: don't flush stdout and stderr in main loop" and unfortunately it is buggy. If you want it included in 7.8 I suppose I could prioritise fixing it. |
|
Hi @JuhaSointusalo - Don't worry about that, this is very much a preliminary trawl through potential candidate commits for the release: the powers-that-be will review all commits before releasing the next client. Thanks for the heads-up on the readiness status. BOINC has been described as moving towards a community-led development model, and I was using this as a teach yourself model to see just how the git and github tools interacted (I learned a lot in the process). I've been invited to sit on a working group to discuss future development models and processes for BOINC: while we're not finished yet, and have no firm proposals to report, we seem to be moving towards gitflow principles. It might be helpful to adjust (as I'm having to) to the 'commit to a development branch, seek promotion to master via a pull request and peer review' model. But perhaps like all neophytes, I'm being over-enthusiastic in proselytising the new model. |
|
@ChristianBeer, can you please comment on the following?
We need to be very careful about including any changes to localizable (translatable) strings in the client and Manager. Every such change requires updating the translation templates, and after that it can take significant time for the translators for each language to update their translations.
At the very least, any strings not in the translation files included in the public release for a language will be shown in English for that language.
It may be more serious than that. As I recall, at least in the past, if there was even a single string that had not been translated in a particular language, none of the new translations for that language would be included. In other words, a translation file would not be updated in BOINC until it was 100% complete. I don't know if this undesirable behavior of Transifex was ever corrected.
In either case, I recommend that we should not change any translatable strings in the release branch for at least a month before a public release.
|
|
Because of the translation problem? I agree about the OK / Save button - we've lived with that for years, and can change it any time. But the Daemon d73d512 is new this time: wouldn't it be better to show it properly from the beginning? |
|
d73d512 also needs to be translated. It's also not 'daemon' anymore, but 'client'. |
|
The translation system as it is setup on transifex can only handle one set of templates. Currently it uses the templates generated from Ideally we should always update translations shortly before building the next release candidate so they are most current. I'm available to do that given that I get the information when a new version will be created. |
|
The word 'daemon' was written onto the face of the Manager two years ago by 2fda7c4: it's just a pity we haven't considered client release questions since then. OK, I'll leave you guys to make a final decision in conjunction with the release manager. I think I've done my bit by attracting extra pairs of eyes to consider questions like this. |
|
This is my understanding of what @ChristianBeer meant by:
Ideally we should always update translations shortly before building the next release candidate so they are most current. I'm available to do that given that I get the information when a new version will be created.
I think he is saying that he is waiting to be told the release schedule before updating the translations, so he will know when it is "shortly before building the next release candidate." Since @davidpanderson is the current release manager, I believe David is the logical person to make this decision and to provide this scheduling information.
|
|
To correct Richards mentioning of gitflow above: The working group currently writing up a proposal for a community centered development workflow is favoring GitHub Flow which can be seen as a simpler version of gitflow. |
|
I suggest that the templates in transifex always correspond to master, not a release branch. |
I agree that this sounds like the ideal process. But that means that translations need to be up to date before the release branch is created. This means that there needs to be a freeze phase where no string changes happen in master while the volunteers translate the templates generated from master. Once the translations are done they can be imported to master, the release branch can be created and string changes can happen in master again. In this scenario the release will have the translations as they were present at the time of creating the release branch. If a beta tester finds out that something is translated wrong we have no easy way of updating translations because master may already have diverged from the release branch. I guess one can see the obvious solutions. We could extend the freeze phase to include the release testing or as we are doing now use the release branch templates until the release is done and switch back to master afterwards. |
|
File lib/filesys.cpp is in conflict because it was updated in 29747d2 |
fixes presenting problem in BOINC#2103
|
I disagree with this change. I feel you should instead change the one instance of "ignore_intel_dev" on line 414 in client/log-flags.cpp to "ignore_intel_gpu_dev" for two reasons:
[1] For backward compatibility. Since this is what has already been written to cc_config.xml, it will fix the issue for people who have selected this option with no further effort on their part.
[2] To avoid misunderstanding that it may apply to the Intel CPU which also can perform OpenCL computation. This is why I originally wrote the code with "ignore_intel_gpu_dev" and I disagreed with Rom's decision to to change it.
|
|
Is there any work in this branch that is not in master? Since we are getting closer to starting work on the 7.10 release (once the work for auto-attach is done) which will be branched from master this pull request will not be needed. However, I'd like to make sure that if there is changes here they are not lost if there are changes we need to keep. |
|
All patches mentioned in this PR have now been released to users as part of v7.10: this list is now redundant. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is intended to create a patch review list for the current release branch.
Please be kind - this is my first attempt at using git to cherry pick commits from master and turn them in to a pull request.
All these commits are already in master, but I believe should be ready for the next alpha client release test.
This list does NOT include commits targeted on Mac, Linux, or release 7.10
I failed to resolve problems with two commits I would otherwise have included:
d73d512 Manager: use "client" instead of "daemon"
3a96e95 GUI RPC client: use std::string instead of fixed-size buffer for requests