Re: [boinc_dev] Status of BOINC Ver 7.9.0 for Windows 64-bit

[Richard Haselgrove]

Hi Art (and everyone else)
The outgoing chair of BOINC's PMC (David Anderson), and the incoming chair 
(Kevin Reed) have jointly asked me to act as Release Manager for the next 
public release of BOINC. That will be version 7.10.x, and will be released for 
Windows, Mac OS X and Linux - Android will be a different kettle of fish 
entirely. I'm a Windows specialist, so I'll be relying on the good offices of 
Charlie Fenton, Laurence Field, and Gianfranco Costamagna to help me out. Plus 
all you good developers and testers out there, of course.
You've slightly bounced me into a premature announcement, but it was coming 
anyway - no problem with that. We've been doing some preparatory testing 
already, and one or two things came to light just yesterday: we're having 
another conference call tomorrow night, and the details should be sorted out 
then.
Any files you see in http://boinc.berkeley.edu/dl/ will be private drops being 
tested as part of this preliminary process. Please be careful to note the 
datestamp as well as the version number: v7.9.0 came into use shortly after the 
public release of v7.8.3, and can cover a significant variation in features. By 
all means start trying to tear any recent build to shreds, but the formal 
process won't start for a day or two: I think we're waiting to get the updated 
translations (thanks, Christian) merged into the master branch so that they can 
be reviewed at the same time.
Further details of the process and timetable will be released after our meeting 
tomorrow.
I hope that makes it clearer.
Richard Haselgrove

  From: Art Masson <artmas...@gmail.com>
 To: boinc_dev email List <boinc_dev@ssl.berkeley.edu>; boinc_alpha email list 
<boinc_al...@ssl.berkeley.edu> 
 Sent: Wednesday, 24 January 2018, 19:07
 Subject: [boinc_dev] Status of BOINC Ver 7.9.0 for Windows 64-bit
   
Hi all,

    What is the status of BOINC 7.9.0 for Windows 64-bit?  It is 
available on the http://boinc.berkeley.edu/dl/ download site, but not 
yet listed as "ready for development testing" on the BOINC public 
download site.

     1.  Should any users be testing this release at this time since 
it's "available" to those who are aware of the alternative site?

    2.  Also is there a preliminary list of changes available from 7.8.3 
for the 7.9.0 version?

Art Masson


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Ability to use optimized application based on available set of CPU extensions

[Richard Haselgrove]

Many projects do have feature-specific application versions, and the plan_class 
mechanism supports it already.
Unfortunately, the rule under RuntimeEstimation seems to prioritise "forbid 
sending incompatible version" (which is important, of course). The scheduler 
tests the full range of compatible apps, like SSE2/SSE3/SSSE3/SSE4.1/AVX/AVX2 
for CPUs, CUDA 3/4/5/6/7/8/9 for GPUs, and records the speed of each. 
Sometimes, some other variable transient in task runtime causes the scheduler 
to latch onto a less-optimised version thinking it is fastest, and it is 
difficult to break out of that misapprehension - which slightly reduces the 
effectiveness of the whole concept. 

On Tuesday, 16 January 2018, 9:52, Vitalii Koshura 
 wrote:
 

 Hello @all,

As far as I know there is no possibility for boinc client to ask project
server for the most optimized application based on available set of
instructions (e.g. AVX), am I right?

This feature can decrease the time necessary to make calculations of the
work unit on new CPUs because of using more optimized code.
>From another hand this will not break backward compatibility for older CPUs
that have no such extensions and can run less optimized code only.

Also this feature can be extended to GPUs (probably).

>From my POV this is rather good feature. What do you think, guys?

Best regards,
Vitalii Koshura
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] server stable release issues

[Richard Haselgrove]

That's particularly sensible advice because the forthcoming 'next' client and 
server releases are precisely one of the rare cases where synchronised client 
and server upgrades are both needed before we can even begin to test the full 
communications interoperability for Science United. 

On Sunday, 14 January 2018, 22:04, Juha Sointusalo 
 wrote:
 

 On 11 January 2018 at 21:59, David Anderson  wrote:

> 3) Assuming the cycles are independent, how should we number server
> releases?
> We could use the same numbering for both, but this has problems:
> - A sequence of releases in one part would cause gaps in the release
> numbers
>  of the other part.
> - It would create the false impression that there's a connection or
>  dependency between client and server releases with the same number.
> So my recommendation is that we start with 1.1.1 for the server version
> number.
>

Since you are going to include building apps in server release that
includes API_VERSION but you can't rewind API_VERSION without breaking
everything. The client also checks scheduler version when deciding if it's
going to accept preferences from the server. I don't know if there is any
third party code that is checking server version for, say, feature checking
or something else.

The version number is also used in various forms as library version, either
embedded in the library or in its filename. I don't know what happens when
you rewind those version numbers. Maybe break all Debian packages?

If you add a new version number that is only used for tagging the release
and internally the code uses something else I think that will only end up
being confusing.

So I think that either it would be best to stay with only one version
number or that you need to break all BOINC components apart and even in
that case you can't rewind version numbers.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] BOINC 7.8.5 for Mac

[Richard Haselgrove]

Click twice (two separate single clicks) on the words 'Last modified' above the 
date column. That will bring the most recent items - the two files that Charlie 
prepared today - to the very top of that very long page. 

On Friday, 12 January 2018, 19:33, Bill Barber 
 wrote:
 

 Your link goes to a very long page.
Bill
> On Jan 12, 2018, at 6:38 AM, Charlie Fenton  wrote:
> 
> I have built BOINC 7.8.5 for the Mac and uploaded it to 
> . This is a release for Macintosh only; there 
> are no changes from 7.8.3 or 7.8.4 affecting the code for any other platform.
> 
> Please promote it to recommended version when appropriate.
> 
> This allows older project graphics apps to be displayed by the Mac 
> screensaver under OS 10.13 High Sierra, though at a slower frame rate than 
> project graphics apps which have been relinked with the BOINC graphics 
> libraries version 7.8.3 or later. The slower frame rate can make animations 
> appear less smooth.
> 
> There is no change in the way the screensaver displays project graphics apps 
> on versions of Mac OS X prior to OS 10.13, whether or not the graphics apps 
> have been relinked.
> 
> Cheers,
> --Charlie
> 
> ___
> boinc_alpha mailing list
> boinc_al...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.

___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] BOINC 7.8.4 for Mac

[Richard Haselgrove]

One report of 'cannot connect to client' with the new v7.8.4 on Mac OS X 
10.12.6 (Darwin 16.7.0)
Host has a HD 5750 which showed 1024MB under BOINC v7.8.3
Details at 
http://boinc.berkeley.edu/dev/forum_thread.php?id=11884=82924#82924 

On Friday, 10 November 2017, 22:27, Charlie Fenton 
 wrote:
 

 I have built BOINC 7.8.4 for the Mac and uploaded it to 
. This fixes the calculation of GPU memory when 
running under OS 10.13 High Sierra.

Cheers,
--Charlie

___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Small tweak to next release would be appreciated

[Richard Haselgrove]

I think it's better to think of Simple View and Advanced View as being two 
different programs, which don't inherit each others screen attributes. 

On Saturday, 4 November 2017, 19:32, Juha Sointusalo 
 wrote:
 

 On 4 November 2017 at 21:11, Chris Raisin  wrote:

> All other switches of view keep the BOINC Manager on the screen currently
> in use, only switching to either
>
> “Simple View” or “Advanced View” sends the Manager careering back to the
> Main Screen. If this switch of views does
> that, why don’t all changes of views (such as changing to Statistics or
> back to Tasks) also do this?
>

 Technicalities I think: the Simple View and Advanced View are different
windows and the Manager checks window's position when it's just about to
show it.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: BOINC Mac problem

[Richard Haselgrove]

Do we know if this person has updated to BOINC v7.8.3 ? 

On Saturday, 4 November 2017, 4:14, David Anderson  
wrote:
 

 FYI


 Forwarded Message 
Subject:     BOINC
Date:     Fri, 3 Nov 2017 21:15:00 -0500
From:     Aaron Shipley 
To:     da...@ssl.berkeley.edu



Dave,

I’ve updated my MacBook Pro to macOS 10.13.2 (it installed a beta release) and 
BOINC 
no longer works. I have no ability to open preferences or lots of other menu 
options 
that are grayed out.

I don’t know if this is a known issue, but maybe it will correct itself with a 
future update to macOS.

aaron.ship...@gmail.com 

Q: Why is this email five sentences or less?
A: http://five.sentenc.es

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Small tweak to next release would be appreciated

[Richard Haselgrove]

Thanks Vitali - that might do it.

Although it isn't clear from the way that Chris worded the original request, 
BOINC does already remember the position of the Manager window between 
sessions: all that would be needed is to provide controls to over-rule the 
'automatic re-home to display 1 at startup' code. Window location is stored in 
registry keys like

[HKEY_CURRENT_USER\Software\Space Sciences Laboratory, U.C. Berkeley\BOINC 
Manager]
"WindowIconized"=dword:
"WindowMaximized"=dword:
"Width"=dword:05ba
"Height"=dword:040e
"XPos"=dword:01c6
"YPos"=dword:
"GUISelection"=dword:0001 

On Thursday, 2 November 2017, 9:38, Vitalii Koshura 
<lestat.de.lion...@gmail.com> wrote:
 

 Hello Richard,

Thank you for you comments.
In this case, I guess, we can make this configurable and let user decide
whether he or she wants to keep BOINC window position or to see it always
of the first display.

Thanks

Best regards,
Vitalii Koshura

2017-11-02 11:30 GMT+02:00 Richard Haselgrove <r.haselgr...@btopenworld.com>
:

> I think we should be a little cautious about changing this: I think the
> original decision to make all windows appear first on display 1 may have
> been deliberate, and done for a purpose. Check the code for comments first.
>
> I use dual displays as well (1920x1200 and 1600x1200): I also have
> multiple computers set up to use both those displays, via two separate KVM
> switches. It gets quite complicated, especially because the machines have
> three GPUs each, one an intel running headless. It can get confusing.
>
> The problem is, from experience: if a hardware display becomes unavailable
> for any reason, but an application is set to start up on it, it can be
> extremely difficult to restore the application to the visible primary
> monitor. Software which is designed to 'always start on display 1', like
> BOINC, is intended to be easily recoverable during hardware failure or
> configuration changes. Remember that in some failure modes (e.g. backlight
> failure), the monitor firmware can report 'all is well and usable' to
> Windows during hardware detection at startup.
>
>
> On Wednesday, 1 November 2017, 23:39, Vitalii Koshura <
> lestat.de.lion...@gmail.com> wrote:
>
>
> Hello Chris,
>
> Thank you.
> I'll try to reproduce and fix it.
>
> Best regards,
> Vitalii Koshura
>
> 2017-11-01 23:56 GMT+02:00 Chris Raisin <crai...@optusnet.com.au>:
>
> > Hi Vitalii,
> >
> > I run under Windows 10 (Latest public release)
> >
> >
> >
> > Cheers
> >
> > Chris
> >
> >
> >
> > *From:* Vitalii Koshura [mailto:lestat.de.lion...@gmail.com]
> > *Sent:* Thursday, 2 November 2017 8:36 AM
> > *To:* Chris Raisin
> > *Cc:* BOINC Developers Mailing List
> > *Subject:* Re: [boinc_dev] Small tweak to next release would be
>
> > appreciated
> >
> >
> >
> > Hello Chris,
> >
> >
> >
> > Just wondering which OS do you use to run BOINC?
> >
> >
> >
> > Thanks
> >
> >
> > Best regards,
> >
> > Vitalii Koshura
> >
> >
> >
> > 2017-11-01 23:05 GMT+02:00 Chris Raisin <crai...@optusnet.com.au>:
> >
> > I have been a user of BOINC Manager for many years, but one thing
> > continually "bugs" me.
> >
> >
> >
> > I run a system on which I have multiple screens, and I keep BOINC on
> > screen
> > 2
> >
> > (away from my general "Work Area" on Screen 1).
> >
> >
> >
> > Every time I start up my system (albeit not often since it is normally
> > running 24 hours per day)
> > I have to manually move the BOINC screen from screen 1 to screen 2.
> >
> > (Screen 2 is really an extension of screen 1 since moving things to the
> far
> > left of screen 1 moves
> > them on to Screen 2.)
> >
> >
> >
> > It would be great if BOINC could have a setting stored in the registry
> that
> > stores the screen
> > location of the BOINC Manager every time it is moved. Upon start-up of
> > BOINC, it could then read
> > in the last stored location and move to that location initially.
> >
> >
> >
> > Just an idea. J
> >
> >
> >
> > Cheers to all
> >
> >
> >
> > Chris Raisin
> >
> > Australia
> >
> >
> >
> >
> >
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> 

Re: [boinc_dev] Small tweak to next release would be appreciated

[Richard Haselgrove]

I think we should be a little cautious about changing this: I think the 
original decision to make all windows appear first on display 1 may have been 
deliberate, and done for a purpose. Check the code for comments first.
I use dual displays as well (1920x1200 and 1600x1200): I also have multiple 
computers set up to use both those displays, via two separate KVM switches. It 
gets quite complicated, especially because the machines have three GPUs each, 
one an intel running headless. It can get confusing.
The problem is, from experience: if a hardware display becomes unavailable for 
any reason, but an application is set to start up on it, it can be extremely 
difficult to restore the application to the visible primary monitor. Software 
which is designed to 'always start on display 1', like BOINC, is intended to be 
easily recoverable during hardware failure or configuration changes. Remember 
that in some failure modes (e.g. backlight failure), the monitor firmware can 
report 'all is well and usable' to Windows during hardware detection at 
startup. 

On Wednesday, 1 November 2017, 23:39, Vitalii Koshura 
 wrote:
 

 Hello Chris,

Thank you.
I'll try to reproduce and fix it.

Best regards,
Vitalii Koshura

2017-11-01 23:56 GMT+02:00 Chris Raisin :

> Hi Vitalii,
>
> I run under Windows 10 (Latest public release)
>
>
>
> Cheers
>
> Chris
>
>
>
> *From:* Vitalii Koshura [mailto:lestat.de.lion...@gmail.com]
> *Sent:* Thursday, 2 November 2017 8:36 AM
> *To:* Chris Raisin
> *Cc:* BOINC Developers Mailing List
> *Subject:* Re: [boinc_dev] Small tweak to next release would be
> appreciated
>
>
>
> Hello Chris,
>
>
>
> Just wondering which OS do you use to run BOINC?
>
>
>
> Thanks
>
>
> Best regards,
>
> Vitalii Koshura
>
>
>
> 2017-11-01 23:05 GMT+02:00 Chris Raisin :
>
> I have been a user of BOINC Manager for many years, but one thing
> continually "bugs" me.
>
>
>
> I run a system on which I have multiple screens, and I keep BOINC on
> screen
> 2
>
> (away from my general "Work Area" on Screen 1).
>
>
>
> Every time I start up my system (albeit not often since it is normally
> running 24 hours per day)
> I have to manually move the BOINC screen from screen 1 to screen 2.
>
> (Screen 2 is really an extension of screen 1 since moving things to the far
> left of screen 1 moves
> them on to Screen 2.)
>
>
>
> It would be great if BOINC could have a setting stored in the registry that
> stores the screen
> location of the BOINC Manager every time it is moved. Upon start-up of
> BOINC, it could then read
> in the last stored location and move to that location initially.
>
>
>
> Just an idea. J
>
>
>
> Cheers to all
>
>
>
> Chris Raisin
>
> Australia
>
>
>
>
>
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_4063138380773232668_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] release 7.8.3?

[Richard Haselgrove]

Presumably it would be worth enquiring into the coverage offered by the 
distribution-specific packaged versions, before committing any resources. What 
proportion of our Linux volunteers (both current and potential) are running a 
dialect of Linux for which there is an active package maintainer?

SETI@Home used to maintain a list of client versions used at their project. The 
script hasn't been maintained for several years, but 
https://setiathome.berkeley.edu/client_types.php shows what was being used as 
at March 19 2013 (considerably earlier than the last Berkeley compatibility 
packages). If that script could be tickled into life again for one last hurrah, 
we might get a snapshot of the balance between Linux versions 7.2.42/7.4.22 
(presumed Berkeley) and versions 7.6.33/7.8.3 (presumed distro maintainer).

We ought also to mention security. As I understand it, the distro maintainers 
tend to implement restricted-user sandboxing, whereas the Berkeley 
static-linked .sea packages ran in user space. Volunteers who like to tinker 
with their installations sometimes find the latter approach easier to work 
with. 

On Sunday, 22 October 2017, 15:49, Steffen Möller <steffen_moel...@gmx.de> 
wrote:
 

 Hello,

On 17.10.17 00:15, David Anderson wrote:
> Our policy for a long time was:
>
> - provide a .sea release (including manager) for current Ubuntu/x86,
>   with no effort to make it run anywhere else.
> - provide a client-only (no manager) release built on an old Linux
> system,
>   everything static, for maximum compatibility.
>   We have a "compatability VM" in which to build this.
Close to nothing on Ubuntu is statically linked. And for BOINC there is
not need to be statically linked, either - when shipping as as part of the
distribution, this is.
> At some point (maybe when Rom left) we stopped doing this.
> I suggest that we start again.
> Maybe change to 64 bit.

Of course you can just go and do that. And for the "competition is
always good"
mantra or as a reference for bug reports I am also embracing that. A
complementary strategy could be to just embrace all those volunteer
packagers out there and call them a part of BOINC.

I have not talked back to Gianfranco about it, but I have some confidence
that he does not mind to move the Debian/Ubuntu-package build instructions
from git.debian.org to github for easier accessibility, if that is of
any help.

Best,

Steffen


>
> On 10/16/2017 7:46 AM, Steffen Möller wrote:
>> On 16.10.17 15:07, Laurence wrote:
>>> Hi Jord,
>>>
>>> On 16/10/17 12:24, Jord van der Elst wrote:
>>>> On Mon, Oct 16, 2017 at 12:06 PM, Richard Haselgrove
>>>> <r.haselgr...@btopenworld.com <mailto:r.haselgr...@btopenworld.com>>
>>>> wrote:
>>>>
>>>>  Berkeley has outsourced the distribution of Linux clients to the
>>>>  package maintainers for individual distributions, for several
>>>>  years now.
>>>>
>>>>
>>>> Laurence is the release manager for Linux, I suspect he knows about
>>>> all of that. :-)
>>> No I didn't, so thanks.  Only stepped forward after the September
>>> workshop.
>>>> But even if the distro package maintainers release these versions,
>>>> they also do so first for testing and can then still ask people to
>>>> report their results on the Alpha project. Their source code is still
>>>> coming from github as well.
>>> Even if the package maintainers build and release, as you pointed out
>>> the versioned upstream code still comes from the project. I have just
>>> discovered that Gianfranco is doing daily builds (every 4h) and
>>> creating packages for Debian from the git master. This is a nice step
>>> towards CI.
>> And he also builds the complete packages together with the server side
>> components afterwards that go to the experimental section of Debian -
>> see the boinc-server-maker package
>> https://packages.qa.debian.org/b/boinc/news/20171005T094923Z.html.  It
>> would help a lot if the server bits in master are always be at a stage
>> that it could be released.
>>
>> In my mind this goes as far as that for automated testing we could have
>> dummy project set up in an automated fashion and do few workunits on
>> those.
>>
>> Cheers,
>>
>> Steffen
>>
>> ___
>> boinc_dev mailing list
>> boinc_dev@ssl.berkeley.edu
>> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>> To unsubscribe, visit the above URL and
>> (near bottom of page) enter your email address.
>
> ___

Re: [boinc_dev] release 7.8.3?

[Richard Haselgrove]

Berkeley has outsourced the distribution of Linux clients to the package 
maintainers for individual distributions, for several years now.

The latest versions endorsed by Berkeley and offered on 
http://boinc.berkeley.edu/download_all.php are:

Recommended version: 7.2.42 (28 February 2014)
'Development' version: 7.4.22 (17 September 2014)

Releases of the 7.4 branch stopped well before development was deemed complete: 
that branch reached 7.4.42 for Windows and Mac on 9 March 2015. 

On Monday, 16 October 2017, 10:29, Jord van der Elst  
wrote:
 

 Start here: https://boinc.berkeley.edu/alpha/index.php
There's an absence of Linux entries, because we do not have a 7.8.3
available for testing 'from Berkeley', but only via people like Gianfranco
from his personal PPA. If he (or you) were to request that the people
testing that version would add their outcome to that page, we (read David)
can add Linux options to the Test Form (
https://boinc.berkeley.edu/alpha/test_form.php) page.

As David explained in the past meeting a set of requirements are needed for
a version to pass testing.
I can't find so quickly that these are documented on this page, but that
can always be added.


-- Jord van der Elst.

On Mon, Oct 16, 2017 at 11:16 AM, Laurence  wrote:

> Thanks,  I did not know about this. Is this documented anywhere? How are
> the results collected? I notice that there is an absence for the Linux
> operating system but as 3/4 of the resources are from Windows user, the
> Windows client is obviously more important.
>
> Laurence
>
>
> On 16/10/17 10:47, Jord van der Elst wrote:
>
> Laurence, the test number comes from https://boinc.berkeley.edu/
> alpha/test_summary.php with no red reports at all:
> https://boinc.berkeley.edu/alpha/test_details.php?version=7.8.3
>
> The only (major) problem still there is for the Spanish person, but I
> think that's either a missing character and thus easily fixed, or it
> requires a major Spanish translation of everything and that's then a
> slightly bigger problem. But this problem will continue until it's been
> fixed in Transifex and tested.
>
>
> -- Jord van der Elst.
>
> On Mon, Oct 16, 2017 at 10:17 AM, Laurence  wrote:
>
>> On 16/10/17 00:49, David Anderson wrote:
>>
>>> 7.8.3 has 90% test coverage and it looks good.
>>>
>> Where does the 90% come from?
>>
>>> Any objections to releasing it?
>>>
>> A few issues need to be addressed before releasing on Linux. There is no
>> reason why this should block the Windows and Mac releases though. We can
>> skip 7.8.3 for Linux and release 7.8.4.
>>
>> Cheers,
>>
>> Laurence
>> ___
>> boinc_dev mailing list
>> boinc_dev@ssl.berkeley.edu
>> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>>
>> To unsubscribe, visit the above URL and
>> (near bottom of page) enter your email address.
>>
>
>
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] release 7.8.3?

[Richard Haselgrove]

None from me either.
The only showstopper is in the Spanish language translation - perhaps we should 
warn about that in the release announcement. 

On Sunday, 15 October 2017, 23:51, Jord van der Elst  
wrote:
 

 Non from me.

On Monday, October 16, 2017, David Anderson  wrote:
> 7.8.3 has 90% test coverage and it looks good.
> Any objections to releasing it?
> -- David
> ___
> boinc_alpha mailing list
> boinc_al...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>

-- 
Jord.
___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 7.8.3 client released for testing

[Richard Haselgrove]

Commit a3b75f4 is the only difference between the two possible source tarballs. 
That commit updates the Windows Installshield files, and is correctly atomic: 
there are no changes to the delivered BOINC code, only to the delivery 
mechanism. Outside the Windows Installer environment, there should be no 
differences in the code. I hope that helps you to start testing while it's 
still night-time in David's timezone. 

On Friday, 6 October 2017, 11:05, Laurence  wrote:
 

 Hi David,

In order test, please could you confirm exactly what we should be 
testing? From my understanding the 'Tag' is client_release/7.8/7.8.3/ 
and this results in the following URL for the source tarball.

https://github.com/BOINC/boinc/archive/client_release/7.8/7.8.3/boinc-7.8.3.tar.gz

This tag represents commit efcd392 but I see that the latest commit on 
the 'branch' client_release/7.8/7.8.3/ is a3b75f4 and would result in 
the following URL for the source tarball.

https://github.com/BOINC/boinc/archive/a3b75f4184e8f86516d5f892accab0a32de6b913/boinc-a3b75f4.tar.gz

Which should I test?

Regards,

Laurence


On 06/10/17 08:50, David Anderson wrote:
> The 7.8.3 client is now being tested.
> This is a release candidate, so please test soon and thoroughly.
>
> The changes since 7.8.2.:
>
> - fixed bug where slot directories aren't cleaned out
> - fixed possible buffer overflow when a task fails with
>  lots of file transfer failures
> - fixed bug involving repeated account manager requests every 10 sec
>
> The Mac version includes changes that will enable the screensaver
> to work with Mac OS 10.13.
> This will require projects to rebuild their graphics apps.
> I believe that SETI@home plans to do this in the next few days.
>
> Thanks -- David
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Bug lets manager connect to BAM! repeatedly.

[Richard Haselgrove]

Use it where? 

On Monday, 2 October 2017, 21:41, David Anderson  
wrote:
 

 That looks right; I'll use it.

On 10/2/2017 1:33 PM, Jord van der Elst wrote:
> Isn't that https://github.com/BOINC/boinc/pull/2128 ??
>
>
> -- Jord van der Elst.
>
> On Mon, Oct 2, 2017 at 10:23 PM, David Anderson  > wrote:
>
>    Is this fixed in master?
>    Does anyone know what commit fixed it?
>    -- David
>
>
>    On 10/2/2017 2:15 AM, Willy wrote:
>
>        Hi,
>
>        A bug introduced in (I think) version 7.8.2 let's the manager ignore 
>the
>        repeat_sec in the AMS response XML and it connects repeatedly without 
>delay.
>
>        So far my server seems to be able to keep up but as more hosts upgrade 
>to
>        7.8.2 or higher I may run into problems.
>
>        Since I pay for every byte transferred (even from my web server to the
>        database server) I would appreciate a speedy fix, as do users with a
>        metered internet connection I think.
>
>        Thanks,
>
>        Willy.
>        ___
>        boinc_dev mailing list
>        boinc_dev@ssl.berkeley.edu 
>        https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>        
>        To unsubscribe, visit the above URL and
>        (near bottom of page) enter your email address.
>
>
>    ___
>    boinc_dev mailing list
>    boinc_dev@ssl.berkeley.edu 
>    https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>    
>    To unsubscribe, visit the above URL and
>    (near bottom of page) enter your email address.
>
>

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Increase in errors on Windows clients related to shared memory

[Richard Haselgrove]

It should be pointed out that the fix for this problem 
(eaf200e54d4d0bb0ce2ea84ec4f21409d7a80eb6) was available and drawn to David's 
attention before v7.8.2 was even built, let alone made the recommended version. 

On Wednesday, 27 September 2017, 21:52, Juha Sointusalo 
 wrote:
 

 On 27 September 2017 at 23:39, David E Kim  wrote:

> Thanks for running these tests!
>
> So is it a windows only issue?  It appears so for R@h.
>

Yep.

Who is responsible for the BOINC client releases?
>

David Anderson.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 7.10 client release

[Richard Haselgrove]

The non-starting client problem seems to have been caused by a batch of CPDN 
simulations - specifically WAH2 PNW - with 51 upload files. First report of a 
successful restart with that task removed. So, provided the under-sized buffer 
fix is included in the build - that's "client: eliminate possible buffer 
overflow in reporting result errors", Aug 16, 8e78576 and b355a13, already 
merged into master - we should be good for a test. 

On Monday, 18 September 2017, 12:15, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:
 

 We are getting a few sporadic reports, so far with inadequate details, of both 
Linux and OS X client crashes using v7.8.2, which leave even older clients 
(after re-installation) unable to start. It appears that the crashes are 
possibly triggered by an application crash, but as yet it's unclear why that 
should take out BOINC as well - my working hypothesis is file corruption, but I 
have no direct evidence yet.
It might be worth holding off on new releases while this issue is still 
unexplained. 

    On Sunday, 17 September 2017, 23:50, Charlie Fenton 
<charl...@ssl.berkeley.edu> wrote:
 

 As I wrote earlier, I'm working on screensaver fixes for compatibility with 
Mac OS 10.13 High Sierra. But it will be a few more days or a week before that 
is ready for testing, so don't hold off on 7.10 for that. I'll merge it into 
both master and the branch after the pull request is approved.

I likely will also want to merge these into a hot-fix version 7.8.3 for Mac 
only with the screensaver changes before 7.10 is ready for public release, 
since OS 10.13 is set for public release on September 25.

At the same time, I will be submitting a tech support request tonight with 
Apple asking if there is a better way to fix the problem than the one I have 
been working on. Ideal of course would be a fix that does not require any 
changes to the project graphics apps, but I'm not too hopeful for that. 

(As I wrote before, I expect the fix I am currently working on to only require 
the projects to rebuild their existing graphics apps with the new libraries 
that I will supply; no changes to the project's code should be needed. It will 
of course also involve changes to the BOINC screensaver coordinator included 
with the BOINC Mac installer.)

Cheers,
--Charlie

On Sep 17, 2017, at 2:47 PM, David Anderson <da...@ssl.berkeley.edu> wrote:
> Master has a number of improvements relative to 7.8.2,
> so I'd like to make a release branch and start testing soon.
> 
> Is there any work in progress that I should wait for?
> 
> Thanks -- David
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 7.10 client release

[Richard Haselgrove]

We are getting a few sporadic reports, so far with inadequate details, of both 
Linux and OS X client crashes using v7.8.2, which leave even older clients 
(after re-installation) unable to start. It appears that the crashes are 
possibly triggered by an application crash, but as yet it's unclear why that 
should take out BOINC as well - my working hypothesis is file corruption, but I 
have no direct evidence yet.
It might be worth holding off on new releases while this issue is still 
unexplained. 

On Sunday, 17 September 2017, 23:50, Charlie Fenton 
 wrote:
 

 As I wrote earlier, I'm working on screensaver fixes for compatibility with 
Mac OS 10.13 High Sierra. But it will be a few more days or a week before that 
is ready for testing, so don't hold off on 7.10 for that. I'll merge it into 
both master and the branch after the pull request is approved.

I likely will also want to merge these into a hot-fix version 7.8.3 for Mac 
only with the screensaver changes before 7.10 is ready for public release, 
since OS 10.13 is set for public release on September 25.

At the same time, I will be submitting a tech support request tonight with 
Apple asking if there is a better way to fix the problem than the one I have 
been working on. Ideal of course would be a fix that does not require any 
changes to the project graphics apps, but I'm not too hopeful for that. 

(As I wrote before, I expect the fix I am currently working on to only require 
the projects to rebuild their existing graphics apps with the new libraries 
that I will supply; no changes to the project's code should be needed. It will 
of course also involve changes to the BOINC screensaver coordinator included 
with the BOINC Mac installer.)

Cheers,
--Charlie

On Sep 17, 2017, at 2:47 PM, David Anderson  wrote:
> Master has a number of improvements relative to 7.8.2,
> so I'd like to make a release branch and start testing soon.
> 
> Is there any work in progress that I should wait for?
> 
> Thanks -- David
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] Possible bug concerning cc_config.xml

[Richard Haselgrove]

Charlie, we probably need to do a systematic check that the terminology is 
consistent throughout.

You committed most of the intel (or intel_gpu) code in a 'first pass' on Dec 5, 
2012: Rom changed a large number of instances when hooking it up to the server 
on Dec 8, 2012, but I'm guessing this one got missed.

https://github.com/BOINC/boinc/commit/ce87ec9848643a094337f67f78a1d5077cf7f772

https://github.com/BOINC/boinc/commit/516eff60b045a1d916f2be3e47e0857c1efbe364
 

On Thursday, 24 August 2017, 8:10, Charlie Fenton 
 wrote:
 

 A quick look at the code makes me believe it is a bug. looking at GIT Master, 
in client/log_flags.cpp, CC_CONFIG::parse_options_client() has on lines 414-415:
        if (xp.parse_int("ignore_intel_dev", n)) {
            ignore_gpu_instance[PROC_TYPE_INTEL_GPU].push_back(n);


but in lib/cc_config.cpp, CC_CONFIG::write() has on lines 626-630:
    for (i=0; i I don't know if this is an actual bug or not, but it is something that has
> been happening for a couple of years through various versions of the BOINC
> manager/client.  If one explicitly ignores the Intel iGPU via the
> cc_config.xml (0), said option will
> disappear from the file after several days.  I haven't been able to pin down
> exactly how long the option exists in the file prior to removal.  The option
> last appeared in the event log on 19 Aug.  I was in the event log this
> evening to look at something else and noticed that the option is no longer
> being logged.  I've reinserted the option and will keep a closer eye on it. 
> 
> Even though the Intel iGPU is ignored implicitly via the global preferences,
> I choose to also have it explicitly in the cc_config.xml.  My question is
> this a bug and should this be investigated? 

___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Drupal post trimming

[Richard Haselgrove]

Thanks Oliver, that was exactly the situation - but I think it must have been 
the first post I had made on Einstein since the trimming process was introduced 
(I hadn't seen it before).
I just wanted to be certain that the trim was correct, and I just happened (by 
coincidence) to go over the limit by exactly one line. The alternative (since I 
had my bug-hunting hat on this morning) might have been a bug in the algorithm 
which removed the last line of every post, no matter how long.
Anyway, the full version appeared on your website, so somebody can have a look 
in due course.
Richard 

On Monday, 21 August 2017, 12:33, Oliver Bock <oliver.b...@aei.mpg.de> 
wrote:
 

 Hi Richard,

On 21/08/17 12:02 , Richard Haselgrove wrote:
> Could somebody explain - or possibly review - "post trimming" on a
> drupal message board, please? I was wondering why my final sentence
> was removed from the attached screenshot.

Please note that this is a trimmed preview, not a trimmed post (yet).

Your screenshot seems incomplete as you should have seen a green
notification bubble above the preview which read: "The trimmed version
of your post shows what your post looks like when promoted to the main
page or when exported for syndication." That said, it's simply visually
truncated in certain aspects where space is limited.

Does that answer your question?

Cheers,
Oliver

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] User web notice

[Richard Haselgrove]

Reported and confirmed at SETI:

Notice: Undefined property: BoincWorkunit::$keywords in 
/disks/carolyn/b/home/boincadm/projects/sah/html/user/workunit.php on line 53
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [BOINC/boinc] project preference to set number of used cpu's (#1414)

[Richard Haselgrove]

Yes, indeed. But we should do both.
Protect users from interference with their daily work by finding and 
eliminating disruptive bugs.
But also allowing knowledgeable users to select settings, both when 'in use' 
and also when 'idle', which allow maximum scientific output compatible with 
their known and understood work patterns. 

On Thursday, 17 August 2017, 23:00, David Anderson  
wrote:
 

 There have been many cases where the BOINC client caused a problem,
such as running too many VMs and bogging down the system.
Volunteers then ask for a preference that lets them manually fix the problem.

In such cases it's better to figure out the root cause of the original problem
(e.g. that VM memory usage isn't being accounted correctly)
and change BOINC so it doesn't happen.
BOINC should compute invisibly without fiddling with preferences.

Also, job scheduling and work fetch are intertwined.
The work fetch algorithm does a simulation of job scheduling
in deciding how much work to request for the various resources (CPU, GPU).
Changes to the job scheduling policy (e.g. by new prefs)
typically lead to problems with work fetch (e.g. starved resources).

-- D


 Forwarded Message 
Subject:     Re: [BOINC/boinc] project preference to set number of used cpu's 
(#1414)
Date:     Thu, 17 Aug 2017 21:43:57 + (UTC)
From:     Jord 
Reply-To:     BOINC/boinc 

 

To:     BOINC/boinc 
CC:     Subscribed 



Is this still being asked for?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub 
, or mute 
the 
thread 
.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Change OK button on Advanced Preferences to Save button (#601)

[Richard Haselgrove]

And presumably the same applies to the forthcoming v7.10 release, too? 
Especially if I'm right in understanding that the new 'keywords' addition will 
contain elements visible to end-users via BOINC Manager. Since I understand 
that there's a rush on to get v7.10 available so that two new projects can come 
on stream, it night be helpful to make and circulate a visual mock-up of any 
new Manager elements, so that translators can prepare in advance while we tidy 
up the final loose ends for v7.8 

On Wednesday, 16 August 2017, 13:07, Charlie Fenton 
 wrote:
 

 Note that if this is ported to the 7.8 branch, it will require another update 
to the localization template BOINC_Manager.pot. It is important that any 
changes to localizable strings be done long enough before public release to 
give the translators for the various languages sufficient time to update their 
translations.  

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] Time for version 7.8.1?

[Richard Haselgrove]

In the Win 7 / non standard internet connection / can't connect to client case:
Can you see (using Task Manager or similar) whether the client - boinc.exe - is 
running?
If not running, can you find any evidence that it ever started up, or 
alternatively that it started but crashed?

The first and easiest things to look at are the files
stdoutdae.txt

stderrdae.txt

- check the timestamps on the files, as well as the contents. 

On Tuesday, 15 August 2017, 11:03, Filip Rydlo  
wrote:
 

 Hi, all  Boinc-ALPHAs and boic-Devs!


        I have *successfuly* tested the  official (downloaded from
BOINC-download-all  page) -  *release* *7.8.1  x64 (BETA)      under
current stable branch (non-insider)  of Windows 10 Home x64  ..*
*        HURRAY,  no major issues detected on Win10! :-)*

        From those 10 restarts and 2 cold starts (Shut down PC and  ON
again),  it was  ALL  12  successful starts  on startup of Win10
(eventhough on AMD Ryzen 7 1800X !)    - it continues to compute from
checkpoints , it never stayed disconnected from the client  and it  *NEVER
has failed  any WU*!  So, this is really COOL! :-)



        But,  now on vacation  I have found *another* completelydifferent
bug ... in *7.8.1 x64*  , on *Win7*! :

        - when  I am  connected to the internet in  a special  *NON-STANDARD
WAY  (* for example: using  USB-cable to *Android 6.0* phone... using the
USB-option (on the phone)  "*USB connection*" (they mean    *PC to the
internet, of course :-) )*...      , so I appear to have multiple "LAN" /
virtual networks in Windows,
                then the *Manager will NEVER connect* to the client and the
client will  *never start the computations!!!*
        (and it happens in 100 percent of all tries!)  so,  *very well
 reproducible! :O*



            Please, *can someone test and confirm this?    :-)*

*Namaste*
Filip
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] Time for version 7.8.1?

[Richard Haselgrove]

I thought BOINC was under community development now.
Why is this "your" release plan? 

On Saturday, 12 August 2017, 23:14, David Anderson  
wrote:
 

 My release plan is:
- test and release 7.8
- test and release 7.10, which will include keyword features and other recent 
fixes.
Ideally each of these should take about 2 weeks.

Anything else we should try to put in 7.10?

-- David

On 8/12/2017 2:36 PM, Vitalii Koshura wrote:
> Hello all,
>
>
>> Further, "Run daemon?"... is it wise to put it like that? Does the general
>> public know what a daemon is?
> I see the fundamental problem here: we have a lot of open issues but they
> are not reviewed and clarified. If I'll take a look at the issue with 'Run
> daemon' enhancement request I'll see just the request with this parameter
> name. And nothing more. No one owner left a comment with a better name. And
> also there was no questions about the name when this pull request was
> merged. It's not a problem to change the title, it will take 5 minutes to
> do this. The problem is that issues are not really reviewed and no release
> plans are made (I'm aware about the releases on GitHub but they are too
> abstract and do not contain real plans for release). I think this should be
> changed also.
>
> Thanks
>
> Best regards,
> Vitalii Koshura
>
> 2017-08-12 14:30 GMT+03:00 Jord van der Elst :
>
>> I have a couple of niggles about the Options->More Options... menu, and
>> then in particular the mouse-overs. In this menu the mouse-over text only
>> works when mousing over the input boxes. Everywhere else in BOINC Manager's
>> menus the mouse-over works over the text as well.
>>
>> Further, "Run daemon?"... is it wise to put it like that? Does the general
>> public know what a daemon is?
>> For us translators, it's even more difficult. Should we just use the word
>> 'daemon' if it also exists in our language, or immediately describe what it
>> means, like "background running program"?
>>
>>
>> -- Jord van der Elst.
>> ___
>> boinc_alpha mailing list
>> boinc_al...@ssl.berkeley.edu
>> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
>> To unsubscribe, visit the above URL and
>> (near bottom of page) enter your email address.
>>
> ___
> boinc_alpha mailing list
> boinc_al...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.

___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

[Richard Haselgrove]

I built from the v7.8.1 tag earlier today - successfully to binaries only (I 
don't have the tools to build the installer), with only the usual number of 
compiler warnings under VS2013.

I didn't have time to test it, because the build machine was busy with other 
work, but I intend to explore the issues we discussed in 
https://lists.ssl.berkeley.edu/pipermail/boinc_alpha/2017-July/021908.html 
('Starting BOINC from command line'), and see if I can reduce them down to an 
issue suitable for a bugfix now we've been alerted to the problem. 

On Friday, 11 August 2017, 22:54, David Anderson  
wrote:
 

  From looking at the VirtualBox change log,
it looks like 5.1.26 has a lot of bug fixes relative to 5.1.22.
I'll use it unless I hear otherwise.

-- David
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords

[Richard Haselgrove]

The major problem here (in my head at least) is how to treat bugfixes during 
the pre-release / test / full release interval.
Clearly they need to be in the codebase which is being prepped for release: but 
they also need to be in the core development line which will form the basis for 
the next round of development. And we don't want to allow new features to creep 
into the release branch untested.
We want a form of trapdoor: bugfixes are applied in two places, features are 
only applied in one.
In my inexperienced mind, the easiest way to achieve that seems to be to bugfix 
in master, develop in branches. Then tag master for the release, and re-allow 
pulls from branches to master.
What am I missing? 

On Tuesday, 8 August 2017, 8:36, Oliver Bock  wrote:
 

 Hi Laurence,

On 07/08/17 23:11 , Laurence Field wrote:
> On 07/08/17 09:55, Oliver Bock wrote:
>>
>> As Laurence pointed out: release branches are to stabilize
>> and fix releases.
>>
> This is not what I intended to communicate. When the master (which
> should be stable) has the required features and been tested, a release
> is made and a branch version major.minor is created. Any important bug
> fixes can then be applied (by merging) and released with version
> major.minor.release.  No new features should be applied to that branch.

I understood and I do agree with your description. This could just be a
matter of wording here.

There could, however, be a minor difference between my and your
approach. Do you intend to actually publish the major.minor release
right after branching off? If that's true than consider this: given that
master is used for integration it, without further measures (see below),
might be unstable at the point where the release branch is created due
to a silently failed integration. Thus I'd create the branch, then first
make sure it's indeed stable ("stabilize") and only then tag
major.minor.0 and publish it. After that the release branch is used for
bug fixes and subsequent major.minor.revision releases only ("fix
releases"). This is roughly (!) in line with what's done in BOINC right
now. And yes, of course there are no new features added to that branch.

Alternatively, one could use your way but that would require a stricter
stability of master. In such a scenario master would have to be frozen
(no more integration) for a short period before a new release branch is
created. It would then be thoroughly tested and after that the release
branch is created and the release build right away. I think that can
have a negative impact on velocity and requires more coordination
between people due to the lockdown of master. Thus I'm slightly in favor
of my approach.

Anyhow, we're already discussing little (yet important) details here and
we should really be focusing on master first.

Cheers,
Oliver





___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

[Richard Haselgrove]

Provided the local clone has "origin: master"?
Which I take it, it should - unless you have a specific disentanglement task to 
perform. 

On Friday, 4 August 2017, 13:10, Vitalii Koshura 
 wrote:
 

 @Laurence,
>
> Is my understanding correct that when we do git clone we get everything?
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?

Correct

Best regards,
Vitalii Koshura

2017-08-04 15:01 GMT+03:00 Laurence :

> Hi,
>
> On 04/08/17 13:31, Oliver Bock wrote:
>
>>
>> To create an offsite archival backup in case of disaster
>>>
>> No. If you want your local repo backed up, just push it to a remote of
>> your choice. Typically that's your personal fork on GitHub.
>>
> Is my understanding correct that when we do git clone we get everything?
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?
>
> Cheers,
>
> Laurence
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

[Richard Haselgrove]

In that case, the workflow document linked by David earlier - 
https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement - contains totally 
unnecessary extra work steps:

* Clone branch: clone ​https://github.com/boinc/boinc.git into new dir w/ 
version num
* Right-click on dir; switch to new branch
* set version numbers in
* /: configure.ac, version.h, version.h.in, version.log
* in version.h, version.h.in: comment out pre-release with C syntax
* android: TODO; Oliver: textual representation, numerical value (increment) in 
7.6, it's 146, so use 147
* commit
* create tag client_release/7.8/7.8.0
* git push, check "include tags"

The only reasons I can see for creating a new directory are:

To create clean build folders for the development tools to work in
To create an offsite archival backup in case of disaster

and both of those should be done *after* the version number updates and tagging 
have taken place. 

On Friday, 4 August 2017, 10:54, Charlie Fenton <charl...@ssl.berkeley.edu> 
wrote:
 

 Hi Oliver,

Perhaps I'm not understanding what you meant by "contains", but if I create a 
new branch named "newbranch" from an existing branch named "oldbranch", then 
any commits made to oldbranch after that are not included in a build I make 
using newbranch unless I specifically port them over, such as by cherry picking 
them from oldbranch into newbranch or by merging one branch into the other. Is 
that not so?

I agree that your local repository always does contain all commits made to all 
branches as of the last time you synced with the remote repository, so you can 
"check out" any branch or tag you wish. As I understand it, checking out a 
branch or tag simply "hides" from your development tools anything that is not 
considered part of that branch or tag, while "revealing" to your developer 
tools everything that is considered part of the branch or tag. 

This allows us to perform a build at any time from exactly the same source 
files as were originally used to build the version represented by the tag. And 
it allows us to build from a feature branch without including subsequent 
changes made outside that branch, which can be useful while developing a 
feature.

Since the client_release/7/7.8 branch was created from master and was then 
immediately tagged as client_release/7/7.8.0, Richard is correct that, as a 
result of the way the branch was created, all the Drupal source code up to that 
time became available in the branch and under that tag, along with everything 
else in master at that point. I believe that is what he meant by "included".

Cheers,
--Charlie

On Aug 4, 2017, at 12:45 AM, Oliver Bock <oliver.b...@aei.mpg.de> wrote:
> On 03/08/17 17:03 , Richard Haselgrove wrote:
>> it also means that the whole of the Drupal source code was included in the 
>> v7.8.0 'client' tag.
> 
> Just to avoid potential confusion: we're not using SVN anymore. A git
> branch always "contains" the whole repo, not some copy of specific parts
> of it.
> 
> Best,
> Oliver
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

[Richard Haselgrove]

I think those last two messages expose the nub of the confusion. Are we, or are 
we not, using Git in the way that Git was designed to be used?
Oliver, have you reviewed the release management paper that David has just 
linked? 

On Friday, 4 August 2017, 9:50, David Anderson  
wrote:
 

 
On 8/4/2017 1:41 AM, Oliver Bock wrote:
> hype, but because of its blatant advantages for what we do. Sadly BOINC
> is still barely making use of it.
Actually we are.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

[Richard Haselgrove]

Indeed. I'm slowly getting my head round the other differences that affect our 
workflow.

Is there also a change in the definition of a 'tag'? In SVN days, a tag - which 
we used to identify client code, nothing else - included only:

code which was used to build the client-related parts
code which Rom deemed fit and ready for use

If that selectivity is no longer available, does that mean we have to be 
careful to clear all client-related issues and bugs, before the 'tag-and-build' 
process for the next release? That we can't leave behind any unfinished 
business for the next cycle? 

On Friday, 4 August 2017, 8:45, Oliver Bock <oliver.b...@aei.mpg.de> wrote:
 

 On 03/08/17 17:03 , Richard Haselgrove wrote:
> it also means that the whole of the Drupal source code was included in the 
> v7.8.0 'client' tag.

Just to avoid potential confusion: we're not using SVN anymore. A git
branch always "contains" the whole repo, not some copy of specific parts
of it.

Best,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

[Richard Haselgrove]

I was using "git show" yesterday to find out how David had made the v7.8.0 tag 
(and how Rom had made the v7.6.33 tag, come to that). Both outputs attached: it 
appears that some sort of script was used. That sort of rules out Rom's old 
cherrypicking of individual commits: it also means that the whole of the Drupal 
source code was included in the v7.8.0 'client' tag.
I was looking because I was worried that a wholesale tagging might incorporate 
commits which Rom might have deliberately excluded - with unexpected effects 
that might need to be specially tested for. But I think that if that was going 
to happen, it probably happened well before v7.6.33, and we survived the 
experience. 

On Thursday, 3 August 2017, 15:38, Charlie Fenton 
 wrote:
 

 I almost forget: I believe that the translations need to be updated in the 7.8 
branch before tagging 7.8.1. 

@Christian: Can you take care of this? I believe you have been working on the 
Transifex stuff. 

Cheers,
--Charlie

On Aug 1, 2017, at 7:11 PM, Charlie Fenton  wrote:
> I just merged my July 21 fix for the Windows 10 Manager crashes into the 
> client_release/7/7.8 branch. If we want to get a new public version released, 
> we need to keep moving alpha testing forward. 
> 
> Are there any other changes in GIT master that should be ported into the 7.8 
> branch before we tag and build BOINC 7.8.1 and release it for alpha testing? 
> (The way Rom and I have always ported individual commits is to cherry pick 
> from master into the 7.8 branch.)
> 
> Should the new keyword stuff be included in the 7.8.1 builds? If so, it is 
> important that the Windows projects be updated for all supported versions of 
> Visual Studio and ported to the 7.8 branch before tagging 7.8.1, as well as 
> my commits 039fd90 (7/16/17) and 11b6ccc (7/31/17). Is anyone other than me 
> still using VS 2010 for local Windows builds?
> 
> Opinions? Thoughts? Volunteers to do the porting and tagging?
> 
> Cheers,
> --Charlie
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   commit 3e6998e7cef71d2042c2b6585db51d2ed5d8ada2
Author: David Anderson 
Date:   Sun Jun 18 15:22:59 2017 -0700

update version #s, create tag client_release/7.8/7.8.0

diff --git a/configure.ac b/configure.ac
index e7d8e00..16b702d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,7 +6,7 @@ dnl not sure exactly what the minimum version is (but 2.13 wont 
work)
 AC_PREREQ(2.58)
 
 dnl Set the BOINC version here.  You can also use the set-version script.
-AC_INIT(BOINC, 7.7.0)
+AC_INIT(BOINC, 7.8.0)
 AC_CONFIG_MACRO_DIR([m4])
 LIBBOINC_VERSION=`echo ${PACKAGE_VERSION} | sed 's/\./:/g'`
 AC_SUBST([LIBBOINC_VERSION])
diff --git a/version.h b/version.h
index d8ef9cb..0d94688 100644
--- a/version.h
+++ b/version.h
@@ -7,10 +7,10 @@
 #define BOINC_MAJOR_VERSION 7
 
 /* Minor part of BOINC version number */
-#define BOINC_MINOR_VERSION 7
+#define BOINC_MINOR_VERSION 8
 
 /* Release part of BOINC version number */
-#define BOINC_RELEASE 2
+#define BOINC_RELEASE 0
 
 /* Release part of wrapper version number */
 #define WRAPPER_RELEASE 26016
@@ -19,10 +19,10 @@
 #define VBOXWRAPPER_RELEASE 26197
 
 /* String representation of BOINC version number */
-#define BOINC_VERSION_STRING "7.7.2"
+#define BOINC_VERSION_STRING "7.8.0"
 
 /* Package is a pre-release (Alpha/Beta) package */
-#define BOINC_PRERELEASE 1
+/* #define BOINC_PRERELEASE 1 */
 
 #if (defined(_WIN32) || defined(__APPLE__))
 /* Name of package */
@@ -35,13 +35,13 @@
 #define PACKAGE_NAME "BOINC"
 
 /* Define to the full name and version of this package. */
-#define PACKAGE_STRING "BOINC 7.7.2"
+#define PACKAGE_STRING "BOINC 7.8.0"
 
 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "boinc"
 
 /* Define to the version of this package. */
-#define PACKAGE_VERSION "7.7.2"
+#define PACKAGE_VERSION "7.8.0"
 
 #endif /* #if (defined(_WIN32) || defined(__APPLE__)) */
 
diff --git a/version.h.in b/version.h.in
index bc0e367..feefc44 100644
--- a/version.h.in
+++ b/version.h.in
@@ -22,7 +22,7 @@
 #define BOINC_VERSION_STRING "@BOINC_VERSION_STRING@"
 
 /* Package is a pre-release (Alpha/Beta) package */
-#define BOINC_PRERELEASE 1
+/* #define BOINC_PRERELEASE 1 */
 
 #if (defined(_WIN32) || defined(__APPLE__))
 /* Name of package */
diff --git a/version.log b/version.log
index 18bb418..09a6d30 100644
--- a/version.log
+++ b/version.log
@@ -1 +1 @@
-7.5.0
+7.8.0
commit 6f6c8b7eb5a3066171757ef162d72ca084cd3230
Author: Rom Walton 
Date:   Sun Jun 5 12:39:54 2016 -0700

- Tag for 7.6.33 release
client_release/7.6/7.6.33

diff --git a/android/BOINC/AndroidManifest.xml 
b/android/BOINC/AndroidManifest.xml
index 363b4b1..07f93aa 

Re: [boinc_dev] keyword.cpp, .h build breaks on Mac

[Richard Haselgrove]

I pointed out the Travis build error report almost 12 hours ago, on a mailing 
list which I know David reads.

I don't have your expertise in tracking down the cause of the error (and I 
don't think I have access to the Travis error messages), but in a case like 
this, shouldn't the developer temporarily revert the commit, and come back to 
it later with a fresh pair of eyes to make a second attempt? 

On Sunday, 30 July 2017, 10:40, Charlie Fenton  
wrote:
 

 The latest commit for keyword.cpp and keyword.h broke the builds on the Mac. 

[1] Adding #include  after #include "parse.h" fixes the compiler errors 
for keyword.h, but I don't know if this needs to be guarded by #ifdef __APPLE__ 
or if it is OK (and perhaps even necessary) to include it for all platforms, so 
I have not checked it in.

[2] After making that change in keyword.h, I get these compiler errors in 
keyword.cpp:
> /lib/keyword.cpp:47:9: error: cannot pass object of non-POD type 
> 'std::string' (aka 'basic_string') through variadic method; call will 
> abort at runtime [-Wnon-pod-varargs]
>        name, description, parent, level, category
>        ^
> /lib/keyword.cpp:47:15: error: cannot pass object of non-POD type 
> 'std::string' (aka 'basic_string') through variadic method; call will 
> abort at runtime [-Wnon-pod-varargs]
>        name, description, parent, level, category
>              ^

According to 
:
> POD stands for Plain Old Data - that is, a class (whether defined with the 
> keyword struct or the keyword class) without constructors, destructors and 
> virtual members functions. Wikipedia's article on POD goes into a bit more 
> detail and defines it as:
> 
> A Plain Old Data Structure in C++ is an aggregate class that contains only 
> PODS as members, has no user-defined destructor, no user-defined copy 
> assignment operator, and no nonstatic members of pointer-to-member type.


 explains it this way:
> The problem you have is that variable argument functions do not work on 
> non-POD types, including std::string. That is a limiation of the system and 
> cannot be modified. What you can, on the other hand, is change your code to 
> pass a POD type (in particular a pointer to a nul terminated character array):


And 

 explains a similar case this way:
> snprintf knows nothing about std::string. In this case, it expects 
> null-terminated C strings, that is, pointers to char which are the beginning 
> of a sequence of characters that ends in a null character. You can obtain the 
> underlying null terminated string held by a std::string object via its 
> c_str() method:

Cheers,
--Charlie

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] keywords

[Richard Haselgrove]

I think this sort of discussion is exactly what I was thinking of when I asked 
in my initial working group paper (Christian, please copy to Bernd and Oliver, 
and explain the background - if you haven't already), when I asked something 
like:

What is the current status of BOINC? Is it a computer science experiment, or is 
it mature scientific infrastructure?

To me, as a relative outsider and not a technical expert at your levels, it 
feels as if "throw everything into master and see if it floats" is the 
experimentalist's answer. I hope I'm not distorting your words too much if I 
suggest that the 'mature infrastructure' approach - if it is to survive the 
next 15 years - needs pre-release development branches for each of client, 
server, and API, all with their own distinct version control; and a separate 
branch for major direction changes like the NSF-funded TBD (which I suspect - 
though it wasn't made explicit at the time of the commit - is what really 
sparked this thread off).

On Thursday, 20 July 2017, 16:12, Oliver Bock  
wrote:
 

 On 20/07/17 11:11 , Oliver Bock wrote:
> If you don't adapt and progress it
> can only get worse, in particular from the point of view of newly
> interested scientists and contributors.

Just in case this came across in an offending way: the "you" wasn't
meant personally, it was meant as in "one" or referring to BOINC as a
project. Sorry if I phrased this ambiguously in my non-native tongue.

Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] keywords

[Richard Haselgrove]

Details of the project I described are no longer available on the web, but they 
can be explored here:

https://web.archive.org/web/19961221214555/http://www.funderfinder.org.uk/
 

On Monday, 17 July 2017, 11:44, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:
 

 That intervention has prompted me to look more closely at the 'Job and Project 
Keywords' design document.
It reminds me very much of a project I was involved in between 1990 and about 
2005. I was the sole coder on the team, but the philosophy and design were led 
by a project leader above me.
Our project was called 'FunderFinder', and was intended to help UK community 
groups raise funds from UK charitable trusts, some of which had trust deeds 
dating back to the seventeenth century - so the terminology was arcane, to say 
the least. Our matching had to be more precise, so we did develop a 'complete 
taxonomy of charity funding' (with the help of a cataloguing expert from the 
British Library), but in general terms our solution was very similar to yours.
I would identify two differences - the first trivial, the second perhaps 
significant.
We used a three-way classification: People, Subjects, Places - that enabled us 
to distinguish between, for example, medical research into cancer (a subject), 
and the care of patients with cancer (people).
More importantly, instead of your integer to represent a keyword, we used an 
alphanumeric code: to keep the structure clear in our own minds, we used lower 
case letters for people, upper case letters for subjects, and numerals for 
places.
I can't match your examples exactly, but we had
H        Medicine and HealthHM      Diseases and disordersHMW    Tumours 
(including cancer)HMWC  CancerHMWL  LeukaemiaHMWM  Melanoma
and for the patients,
jdgwc  Cancer
We found that seven-character codes were sufficient to cover the worst case, 
from 2 (UK) / 5 (rest of the world) down to a single historic parish council 
via the modern local government administrative structure.
The advantage of using a hierarchical coding was that I could use sub-string 
pattern matching to include and exclude higher or lower level matches. That's 
probably overkill for the current proposal, but it seems to be a shame to 
design out the possibility of a hierarchical search at this stage. 

    On Monday, 17 July 2017, 9:04, Christian Beer <christian.b...@aei.mpg.de> 
wrote:
 

 I just want to voice my disagreement with the process in which this
proposal was handled. There was barely time to comment and so far no one
did but implementation into the master branch has already started for
what seems to be a major change to Client and Server code.

As a volunteer contributor and committer to BOINC and as a BOINC PMC
member this proposal and the process in which it is done does not have
my approval.

Regards
Christian

P.S.: Although this mail is sent from my AEI email the opinion expressed
above is my personal one.

On 14.07.2017 01:04, David Anderson wrote:
> I propose adding a mechanism for associating keyword attributes
> (such as science area) with jobs and projects.
> https://boinc.berkeley.edu/trac/wiki/DesignKeywords
> Comments welcome.
> -- David
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


  
___
boinc_projects mailing list
boinc_proje...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] keywords

[Richard Haselgrove]

That intervention has prompted me to look more closely at the 'Job and Project 
Keywords' design document.
It reminds me very much of a project I was involved in between 1990 and about 
2005. I was the sole coder on the team, but the philosophy and design were led 
by a project leader above me.
Our project was called 'FunderFinder', and was intended to help UK community 
groups raise funds from UK charitable trusts, some of which had trust deeds 
dating back to the seventeenth century - so the terminology was arcane, to say 
the least. Our matching had to be more precise, so we did develop a 'complete 
taxonomy of charity funding' (with the help of a cataloguing expert from the 
British Library), but in general terms our solution was very similar to yours.
I would identify two differences - the first trivial, the second perhaps 
significant.
We used a three-way classification: People, Subjects, Places - that enabled us 
to distinguish between, for example, medical research into cancer (a subject), 
and the care of patients with cancer (people).
More importantly, instead of your integer to represent a keyword, we used an 
alphanumeric code: to keep the structure clear in our own minds, we used lower 
case letters for people, upper case letters for subjects, and numerals for 
places.
I can't match your examples exactly, but we had
H        Medicine and HealthHM      Diseases and disordersHMW    Tumours 
(including cancer)HMWC  CancerHMWL  LeukaemiaHMWM  Melanoma
and for the patients,
jdgwc  Cancer
We found that seven-character codes were sufficient to cover the worst case, 
from 2 (UK) / 5 (rest of the world) down to a single historic parish council 
via the modern local government administrative structure.
The advantage of using a hierarchical coding was that I could use sub-string 
pattern matching to include and exclude higher or lower level matches. That's 
probably overkill for the current proposal, but it seems to be a shame to 
design out the possibility of a hierarchical search at this stage. 

On Monday, 17 July 2017, 9:04, Christian Beer  
wrote:
 

 I just want to voice my disagreement with the process in which this
proposal was handled. There was barely time to comment and so far no one
did but implementation into the master branch has already started for
what seems to be a major change to Client and Server code.

As a volunteer contributor and committer to BOINC and as a BOINC PMC
member this proposal and the process in which it is done does not have
my approval.

Regards
Christian

P.S.: Although this mail is sent from my AEI email the opinion expressed
above is my personal one.

On 14.07.2017 01:04, David Anderson wrote:
> I propose adding a mechanism for associating keyword attributes
> (such as science area) with jobs and projects.
> https://boinc.berkeley.edu/trac/wiki/DesignKeywords
> Comments welcome.
> -- David
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] bug if missing all_projects_list.xml

[Richard Haselgrove]

Summarising my observations with BOINC v7.8.0 and Windows 10 Creators Edition 
build 15063.413

I have seen two separate startup behaviours since completing those updates.

1) BOINC Manager starts normally (minimised) with icon in notification area. On 
mouseover, the icon disappears. Checking with task manager, I see that the 
client is running and managing science apps normally, but the Manager is not 
running. (Re-)Starting the Manager, it opens normally and remains running.

2) BOINC Manager opens to Notices tab, launches 'attach to project' wizard but 
with no projects available to attach. Cancelling the wizard populates both the 
Event Log and the Task tab, and processing proceeds normally with the existing 
projects.

I have not (yet) seen a full normal startup with the Manager starting minimised 
and continuing running.

Notes:
There is an 'all_projects_list.xml' file in the data folder, dated 28 November 
2016There is NO stderrgui.txt or stdoutgui.txt file in the data folder.
 

On Wednesday, 5 July 2017, 4:30, David Anderson  
wrote:
 

 If the Manager and client start up and there is no all_projects_list.xml file,
the client starts an HTTP op to get it.
But before it's done, the Manager does an RPC to get the project list.
The RPC returns an empty list,
and the Manager brings up a Wizard with empty project list.

This is a bug in the Manager.
If it gets an empty project list it should try again in 10 sec or so.
It should never bring up an empty wizard.

(this may not have anything to do with the problem people are seeing).

-- David
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] Disappearing BOINC Icon in System Tray (7.7.2) Requiring Manual Restart on Boot-Up

[Richard Haselgrove]

No, I hadn't reached Creator's update yet - I'm still on 14393, whatever that's 
called.
But I'm downloading Creator's now - that'll be 15xxx. Give it a try in the 
morning. 

On Tuesday, 4 July 2017, 19:57, Juha Sointusalo <juha.sointus...@gmail.com> 
wrote:
 

 On 4 July 2017 at 19:33, Richard Haselgrove <r.haselgr...@btopenworld.com>
wrote:

> Yes, as just reported - but you need to be running a build later than .479
> for that to work.
>
>
> On Tuesday, 4 July 2017, 17:19, Juha Sointusalo <juha.sointus...@gmail.com>
> wrote:
>
> These days Windows hides notification icons rather aggressively.
>

Missed the part about Creators Update, still on Anniversary Update here.
Sorry.

I figured I'd go and test how the Manager behaves with Anniversary Update
and to my surprise it actually crashes.

I rebooted the computer and logged in. Manager is set to start
automatically, minimized to notification icon. At first the icon said
Connecting to client (or whatever the precise wording is) and I waited
until it said it was connected. I clicked the icon which promptly
disappeared. I verified with Task Manager that it was crash, no
boincmgr.exe anywhere. Crash log attached, good luck getting anything
useful out of it. To others: Manager's logs are in
C:\Users\you\AppData\Roaming\BOINC.

On related note. The client sometimes takes a very long time to start up,
20+ seconds. The following is with most of the logging options enabled:

04-Jul-2017 21:21:44 [---] Starting BOINC client version 7.8.0 for
windows_x86_64
...
04-Jul-2017 21:21:46 [---] [cpu_sched_debug] Request CPU reschedule: Prefs
update
04-Jul-2017 21:21:46 [---] [cpu_sched_debug] Request CPU reschedule: Startup
04-Jul-2017 21:21:46 [ATLAS@home] Task
YMzLDmXegrpnDDn7oo6G73TpABFKDmABFKDmIPMKDmABFKDmSd7sNm_0 is 142.90 days
overdue; you may not get credit for it.  Consider aborting it.
04-Jul-2017 21:21:46 [---] [gui_rpc] Local control only allowed
04-Jul-2017 21:21:46 [---] [gui_rpc] Listening on port 31416
04-Jul-2017 21:22:05 [---] [http] HTTP_OP::init_get():
http://boinc.berkeley.edu/project_list.php
04-Jul-2017 21:22:05 [---] [http] HTTP_OP::libcurl_exec(): ca-bundle
'C:\BOINC\ca-bundle.crt'
04-Jul-2017 21:22:05 [---] [http] HTTP_OP::libcurl_exec(): ca-bundle set
04-Jul-2017 21:22:05 [---] [proxy] HTTP_OP::no_proxy_for_url():
http://boinc.berkeley.edu/project_list.php
04-Jul-2017 21:22:05 [---] [proxy] returning false
...
04-Jul-2017 21:22:05 Initialization completed

(Ignore the Atlas task.)

There are really no messages between 21:21:46 and 21:22:05. I've seen this
multiple times but it is not reliably reproducible. This delay could be
what is triggering the Add project dialog in Manager.

-Juha
___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] Disappearing BOINC Icon in System Tray (7.7.2) Requiring Manual Restart on Boot-Up

[Richard Haselgrove]

Yes, as just reported - but you need to be running a build later than .479 for 
that to work. 

On Tuesday, 4 July 2017, 17:19, Juha Sointusalo <juha.sointus...@gmail.com> 
wrote:
 

 On 4 July 2017 at 17:54, Richard Haselgrove <r.haselgr...@btopenworld.com>
wrote:

> I'm working through the same tests - currently downloading June '17
> cumulative security patch.
> But I'm seeing no BOINC Manager icon in the system tray - either with a
> previous homebuild, or with v7.8.0
> But BOINC *does run* after restart, as can be confirmed in Task Manager -
> all three components (BOINC.exe, BoincMgr, BoincTray) are running. But I
> haven't (yet) found a way of restoring the auto-start copy of BOINC Manager
> to the screen. The best I can do is to launch a second instance to control
> the beast. Still looking.
>

These days Windows hides notification icons rather aggressively. You can
tell if it's hidden by clicking the "up arrow" near the clock, the same
since, about, XP. If it's hidden you can unhide it by right clicking task
bar, selecting Settings and selecting Select which icons appear on the
taskbar in Notification area.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] Disappearing BOINC Icon in System Tray (7.7.2) Requiring Manual Restart on Boot-Up

[Richard Haselgrove]

Yes, I think it's a Windows 10 issue.

I started with:

Windows 10 Professional
Version 1607
OS Build 14393.479

That displayed missing icons, unable to re-display autorun copy of Manager, 
etc. as we've been discussing.

After a very long update session, I have all as above EXCEPT

OS build 14393.1358

Now, the icon displays as you might expect: normally hidden in the Notification 
Area, but can be moved to the taskbar by drag'n'drop or by personalization. I 
had to work through 
http://www.howto-connect.com/customize-system-tray-on-windows-10-on-your-own-preference/
   to work out all the options. Let's say that M$ have fixed it in build 1358 
(and, hopefully, later).

Another problem: after the big update session, Windows started BOINC v7.8.0, 
and BOINC displayed the BOINC notices tab and the 'attach project' wizard: 
which was blank, no projects available. However, once I'd dismissed all that 
and gone back to the tasks tab, all projects were present and crunching as 
normal. Haven't worked out why that happened yet. 

On Tuesday, 4 July 2017, 16:40, Art Masson <artmas...@gmail.com> wrote:
 

 After reboot I see the icon in the system tray, but as soon as I click on it, 
it disappears.  Is that what you are seeing too?  It does look like the app is 
actually running and stays running however -- and when I relaunch manually it 
seems to simply restore the tray icon.  I do think this behavior occurred prior 
to 7.8 however ... still wondering if this isn't really  a Windows 10 issue 
that's been there awhile.  
Art


Sent from my iPhone 6s

> On Jul 4, 2017, at 10:54 AM, Richard Haselgrove 
> <r.haselgr...@btopenworld.com> wrote:
> 
> I'm working through the same tests - currently downloading June '17 
> cumulative security patch.
> 
> But I'm seeing no BOINC Manager icon in the system tray - either with a 
> previous homebuild, or with v7.8.0
> 
> But BOINC *does run* after restart, as can be confirmed in Task Manager - all 
> three components (BOINC.exe, BoincMgr, BoincTray) are running. But I haven't 
> (yet) found a way of restoring the auto-start copy of BOINC Manager to the 
> screen. The best I can do is to launch a second instance to control the 
> beast. Still looking.
> 
> 
> On Tuesday, 4 July 2017, 15:37, Art Masson <artmas...@gmail.com> wrote:
> 
> 
> WowI stand corrected.  This morning I restarted two machines running 
> Windows 10 Creator and BOINC 7.8.0.  Both machines experienced the 
> "disappearing" icon in the system tray problem. No idea why I didn't 
> experience this yesterday when I tested this.  What was strange is that 
> when I restarted BOINC manually, it came up instantly on both machines 
> and the event log timing showed it had actually restarted on the 
> reboot...and was apparently already running (without the system try 
> icon).  After I forced the BOINC launch, the system tray icon reappeared 
> and everything seems fine.
> 
> By the way, I'm also testing the Mac BOINC version 7.8.0 on a machine 
> running MacOS Sierra 10.12.16 (Beta Release 5) with no problems so far.
> 
> Art Masson
> 
> 
> 
> 
> On 7/3/2017 6:16 PM, Art Masson wrote:
> >
> > I had a heck of a time getting Windows 10 Creator to load on this 
> > machine.  The problem ultimately was that my Windows "system reserved 
> > partition" was only 100MB and was full/too small.  After I increased 
> > the hidden partition size, Windows 10 Creator upgrade run 
> > successfully.  However, I don't think my upgrade problems are directly 
> > replaced to the "disappearing icon" issue.  I did see this problem 
> > consistently on another machine which had the previous version  of 
> > Windows 10 on it -- where I had to manually restart BOINC each time 
> > the machine started or rebooted.  I had done some research on the 
> > "startup" problem with applications on Windows 10, so frankly I've 
> > assumed that the problem was fixed in the latest release.  However 
> > I've not upgraded the machine where I had the problem (will not be 
> > back home until next week to try it).  Sorry I don't have more info, 
> > but the Windows 10 fails to startup application problem was referenced 
> > I believe (see link) and the various fixed suggested never worked for 
> > me..some apps started but some did not...
> >
> > https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-programs-do-not-launch/bae62ab1-b938-4c71-bfce-d5f1ee170f8f
> >
> > Not sure if this is related to the problem or a blind alley.  When I 
> > get back home, I will confirm this behavior on my other Windows 10 
> > machine, then do the Creator upgrade and see if the launch problem 
> > resolves itself.  I

Re: [boinc_dev] [boinc_alpha] Disappearing BOINC Icon in System Tray (7.7.2) Requiring Manual Restart on Boot-Up

[Richard Haselgrove]

I'm working through the same tests - currently downloading June '17 cumulative 
security patch.
But I'm seeing no BOINC Manager icon in the system tray - either with a 
previous homebuild, or with v7.8.0
But BOINC *does run* after restart, as can be confirmed in Task Manager - all 
three components (BOINC.exe, BoincMgr, BoincTray) are running. But I haven't 
(yet) found a way of restoring the auto-start copy of BOINC Manager to the 
screen. The best I can do is to launch a second instance to control the beast. 
Still looking. 

On Tuesday, 4 July 2017, 15:37, Art Masson  wrote:
 

 WowI stand corrected.  This morning I restarted two machines running 
Windows 10 Creator and BOINC 7.8.0.  Both machines experienced the 
"disappearing" icon in the system tray problem. No idea why I didn't 
experience this yesterday when I tested this.  What was strange is that 
when I restarted BOINC manually, it came up instantly on both machines 
and the event log timing showed it had actually restarted on the 
reboot...and was apparently already running (without the system try 
icon).  After I forced the BOINC launch, the system tray icon reappeared 
and everything seems fine.

By the way, I'm also testing the Mac BOINC version 7.8.0 on a machine 
running MacOS Sierra 10.12.16 (Beta Release 5) with no problems so far.

Art Masson




On 7/3/2017 6:16 PM, Art Masson wrote:
>
> I had a heck of a time getting Windows 10 Creator to load on this 
> machine.  The problem ultimately was that my Windows "system reserved 
> partition" was only 100MB and was full/too small.  After I increased 
> the hidden partition size, Windows 10 Creator upgrade run 
> successfully.  However, I don't think my upgrade problems are directly 
> replaced to the "disappearing icon" issue.  I did see this problem 
> consistently on another machine which had the previous version  of 
> Windows 10 on it -- where I had to manually restart BOINC each time 
> the machine started or rebooted.  I had done some research on the 
> "startup" problem with applications on Windows 10, so frankly I've 
> assumed that the problem was fixed in the latest release.  However 
> I've not upgraded the machine where I had the problem (will not be 
> back home until next week to try it).  Sorry I don't have more info, 
> but the Windows 10 fails to startup application problem was referenced 
> I believe (see link) and the various fixed suggested never worked for 
> me..some apps started but some did not...
>
> https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-programs-do-not-launch/bae62ab1-b938-4c71-bfce-d5f1ee170f8f
>
> Not sure if this is related to the problem or a blind alley.  When I 
> get back home, I will confirm this behavior on my other Windows 10 
> machine, then do the Creator upgrade and see if the launch problem 
> resolves itself.  I do not have this problem on this machine running 
> Windows 10 Creator -- but then I don't think I ever saw that "launch" 
> problem on this machine either...
>
> Sorry I can't be of more help
> Art Masson
>
>
> On 7/3/2017 5:36 PM, David Anderson wrote:
>> Rom:
>> Any ideas on how to debug this problem?
>> -- David
>>
>> On 7/3/2017 2:24 PM, Jacob Klein wrote:
>>>
>>> This doesn't make sense to me. I had the problems with Windows 10 
>>> Creator’s update, and continue to have problems with Windows 10 
>>> Insider builds newer than that. My hunch is that Art has a scenario 
>>> that masks/hides the issue. I still show it as broken.
>>>
>>> *From: *David Anderson 
>>> *Sent: *Monday, July 3, 2017 5:14 PM
>>> *To: *Art Masson ; boinc_alpha email 
>>> list 
>>> *Subject: *Re: [boinc_alpha] Disappearing BOINC Icon in System Tray 
>>> (7.7.2) Requiring Manual Restart on Boot-Up
>>>
>>> Thanks.
>>> Jacob Klein, is this compatible with what you're seeing?
>>> -- D
>>>
>>> On 7/3/2017 11:23 AM, Art Masson wrote:
>>> >
>>> > I've just tested this with BOINC 7.8.0 and the application starts 
>>> correctly when
>>> > Windows reboots or starts up on my machine.  From my standpoint 
>>> this incorrect
>>> > behavior appears to have been fixed with Windows 10 Creators 
>>> release and was not a
>>> > BOINC application problem.
>>> >
>>> > Art Masson
>>> >
>>> >
>>> >
>>> > On 7/3/2017 12:04 PM, Art Masson wrote:
>>> >> REF: Disappearing BOINC Icon in System Tray (7.7.2)  Requiring 
>>> Manual Restart on
>>> >> Boot-Up
>>> >>
>>> >> Hi...I'm not seeing this problem with BOINC 7.7.2 now that I've 
>>> upgraded to
>>> >> Windows 10 Creators version (10.00.15063.00) (newest release).  I 
>>> did see this
>>> >> problem with 7.7.2 and 7.6.33 with the previous Windows 10 release
>>> >> (10.00.14393.00).  This appeared to be a problem with Windows 
>>> startup actions
>>> >> because there were other apps that didn't start as well with the 
>>> older Windows 10
>>> >> release -- this was a 

Re: [boinc_dev] master branch broken?

[Richard Haselgrove]

That's what the Travis failure marker is for - it's been showing all day.


 

On Wednesday, 7 June 2017, 22:06, David Anderson  
wrote:
 

 Oops!  Fixed.
-- D

On 6/7/2017 8:52 AM, Gianfranco Costamagna wrote:
> Hello, latest commits are not building anymore
> libtool: link: /usr/bin/g++ -Wall -Wextra -Wshadow -Wredundant-decls 
> -Wdisabled-optimization -Wpointer-arith -Wstrict-aliasing -Wcast-align -g -O3 
> "-fdebug-prefix-map=/<>/boinc-7.7.0+dfsg~git20170607+r23753~r7~ubuntu17.04.1=."
>  -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 
> -funroll-loops -fforce-addr -ffast-math -flto -Wall -Wl,-Bsymbolic-functions 
> -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -flto -g -O3 
> "-fdebug-prefix-map=/<>/boinc-7.7.0+dfsg~git20170607+r23753~r7~ubuntu17.04.1=."
>  -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 
> -funroll-loops -fforce-addr -ffast-math -flto -o .libs/cgi credit.o edf_sim.o 
> handle_request.o hr.o hr_info.o plan_class_spec.o sched_array.o 
> sched_assign.o sched_check.o sched_customize.o sched_files.o sched_hr.o 
> sched_limit.o sched_locality.o sched_main.o sched_nci.o sched_resend.o 
> sched_result.o sched_score.o sched_send.o sched_timezone.o sched_vda.o 
> sched_ve
 rs
>  ion.o sched_types.o time_stats_log.o  ../sched/.libs/libsched.so 
>../lib/.libs/libboinc_crypt.so ../lib/.libs/libboinc.so 
>-L/usr/lib/powerpc64le-linux-gnu -lmysqlclient -lpthread -lz -lm -lrt -latomic 
>-ldl -L/usr -L/usr/lib -lssl -lcrypto -pthread
> /tmp/ccrjyqlW.ltrans0.ltrans.o: In function `log_request':
> ./sched/handle_request.cpp:1139: undefined reference to 
> `SCHED_MSG_LOG::set_indent_level(int)'
> /tmp/ccrjyqlW.ltrans3.ltrans.o: In function `handle_request(_IO_FILE*, 
> _IO_FILE*, char*)':
> ./sched/handle_request.cpp:1496: undefined reference to 
> `SCHED_MSG_LOG::set_indent_level(int)'
> collect2: error: ld returned 1 exit status
>
> https://launchpadlibrarian.net/322962429/buildlog_ubuntu-zesty-ppc64el.boinc_7.7.0+dfsg~git20170607+r23753~r7~ubuntu17.04.1_BUILDING.txt.gz
>
> thanks
>
> G.
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   ___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] An additional preference to prevent downloading when on WiFi, to enable downloading only on when connected to cable

[Richard Haselgrove]

The trouble is, there are too many networking variables to easily boil down to 
a single parameter.
NIC to router - WiFi (802.11n) is pretty good these days.Router to internet - 
depends on locationInternet to project server - I think the example Charles was 
thinking of was GPUGrid in Barcelona, which went through a bad connectivity 
patch last year, but is communicating properly again now. Doesn't affect their 
reliance on high-performance GPUs, which is a different question.
I've just run speedtest on my six year old Windows 7 laptop, and got 48.34 
Mbits download and 9.28 Mbits upload over WiFi - that's very close to my home 
broadband connection of 50.33 Mbps / 9.765 Mbps. But the results might be very 
different in my local cafe / pub / seminar room / public hotspot. We can't 
equate connection *type* with connection *speed*. 

On Thursday, 30 March 2017, 13:28, David Wallom 
 wrote:
 

 Hi Charles,

With the increasing prevalence of mobile computing devices then having the 
system (scheduler) doing the test is not really scalable as people move their 
devices.

It would be much easier if the clients did this. My Mac for example is able to 
tell me the latest network bandwidth if has for any of its interfaces.

David

From: boinc_dev [boinc_dev-boun...@ssl.berkeley.edu] on behalf of Charles 
Elliott [elliott...@comcast.net]
Sent: 30 March 2017 13:10
To: 'Nicolás Alvarez'; Andy Bowery
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

Boinc could just download a test file from the Oxford website 5 times and 
average the times.  If the average was above a limit deemed the minimum 
acceptable speed, the user would be permitted to proceed.  OW, the Oxford 
website would post a very polite, very detailed, and very well written message 
to Boinc/the user explaining why a high bandwidth connection is necessary for 
the user's progress and enjoyment of Oxford's project.

One of the Boinc GPU projects, as I recall in Spain, does this now WRT the 
capacity of the user's GPU(s).  It is no fun for, or use to, anyone if the user 
processes a work unit on an older GPU, the GPU overheats, and the WU fails 3/4 
of the way through.  It is annoying though.

Charles Elliott

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Nicolás Alvarez
Sent: Wednesday, March 29, 2017 3:40 PM
To: Andy Bowery
Cc: BOINC Developers Mailing List ‎[boinc_dev@ssl.berkeley.edu]‎
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

2017-03-29 14:45 GMT-03:00 Andy Bowery :
> Hi,
>
> We would be interested in an additional BOINC preference, a tickbox on the 
> 'Network' tab, with something like 'Download only when connected to a high 
> bandwidth connection'. Ticking the box of this preference would prevent 
> download of the application and supporting files when the machine (for 
> example: a laptop) was connected only to WiFi and not connected to a higher 
> bandwidth networking cable. Would it be possible for this to be scheduled to 
> be added as an item to be included in a later release?
>
> With regards,
>

What does "high bandwidth connection" mean, how could BOINC know if it's 
connected to one?

--
Nicolás
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

Hi Oliver,
I'm taking about an intermediate level between 'cruncher' and 'developer'. I'm 
accredited as a 'Help desk expert' on the BOINC message boards, but I don't 
have the skills needed to be a full-blown developer in the versions of the 
various languages used within BOINC. Instead, I can (I hope) contribute by 
helping analyse symptoms, to make life easier for the real developers.
Two examples:
Even the best resourced projects - like Einstein! - can benefit from external 
diagnosis. A few months ago, I was pleased to be able to help Christian with a 
long-standing (multi-year, it turned out) BOINC preference propagation problem. 
Christian found the actual code at fault and committed the solution, but I like 
to think that this helped:
https://einsteinathome.org/content/invalid-global-preferences-problem?page=1#comment-150509

That example didn't depend on version control, but this next one did.
A few years ago, David added some extra (and very useful) exit status and error 
codes in 72368a6b205b521691af23ca65815b2ec4ac3008 (SVN 25601)
Unfortunately, the web code wasn't updated to reflect the new codes until 
f3c8ab83e91a430611bbb25ce714f5fd43b8c915 (SVN 25858) - over two months later, 
as is easier to deduce from the SVN than SHA references.
Not every project updated (or updates) their BOINC servers synchronously, and 
http://boinc.berkeley.edu/dev/forum_thread.php?id=7704=45186#45186 shows 
how I was able to demonstrate that - even after the project said they had 
updated their server code - a missed include file was still responsible for 
misleading task outcome information on their website. That diagnosis would not 
be possible today. 

On Wednesday, 29 March 2017, 14:55, Oliver Bock <oliver.b...@aei.mpg.de> 
wrote:
 

 On 29/03/2017 13:22 , Richard Haselgrove wrote:
> I'm talking about the information visible to volunteers outside the core
> project staff.

I know, but what exactly do you mean by "public-facing page" and
"diagnosis"? Of what? The version of the web code or the daemons used by
a project?

> Small science projects don't have the resources (or the
> inclination) to follow every twist and turn.

I don't see how that's related to our discussion.

> Unless you support and
> enable volunteer contributions too, you lose a potentially valuable
> resource for community computing in general.

Again, I don't see how using SHA1s precludes any volunteer
contributions. I mean, we're talking about code contributions here, not
cycles, right? That means we're talking about developers, even if only
casual ones. They have to deal with git and GitHub anyway to provide
their contributions ans SHA1s shouldn't pose any hurdle to that target
audience.

Cheers,
Oliver

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

Since David has said that v7.7.2 was essentially a test build to verify that he 
had all the build tools available for use, it might be best to regard that one 
as a pre-alpha private build, and re-start the 7.7/7.8 development branch cycle 
with proper version control from the outset. 

On Wednesday, 29 March 2017, 15:00, Oliver Bock  
wrote:
 

 On 29/03/2017 13:17 , Vitalii Koshura wrote:
> but currently we have another situation:
> master branch can not be a start point for new release branch.

It's not a matter of whether it should or even can be. It's a matter of
fact that the latest release (7.7.2) was build from master if I'm not
mistaken. Thus the release branch needs to reflect that, otherwise the
release and its branch would simply be inconsistent.

Best,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

I'm talking about the information visible to volunteers outside the core 
project staff. Small science projects don't have the resources (or the 
inclination) to follow every twist and turn. Unless you support and enable 
volunteer contributions too, you lose a potentially valuable resource for 
community computing in general. 

On Wednesday, 29 March 2017, 12:11, Oliver Bock <oliver.b...@aei.mpg.de> 
wrote:
 

 On 29/03/2017 12:44 , Richard Haselgrove wrote:
> I agree that the SHAs would be more precise, but they'd be ugly to
> display on a public-facing page,

Not sure why the public would need to know that at all anyway :-)

> and less easy to do diagnosis

The admin should have no problem with SHA1s.

> human brain can read five digits from a monotonic sequence, and get an
> idea of vintage at a glance, but it can't do that with non-sequential SHAs.

True, but the above notwithstanding, you could always show the latest
tag in your local repo's history (and how many commits you lack) for
instance. Sure, you'd need proper server release for that but that's a
requirement for BOINC's open source ambitions anyway. There are many
ways to improve readability, if that's needed at all.

> But we would need the latest SHA
> included in the server daemon compilation, not just the user web sources.

Most daemons already have that IIRC.

Best,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

I agree that the SHAs would be more precise, but they'd be ugly to display on a 
public-facing page, and less easy to do diagnosis - the human brain can read 
five digits from a monotonic sequence, and get an idea of vintage at a glance, 
but it can't do that with non-sequential SHAs.
Perhaps it could be embedded as a comment in the page source, in the same way 
as the other php includes? But we would need the latest SHA included in the 
server daemon compilation, not just the user web sources. 

On Wednesday, 29 March 2017, 11:11, Oliver Bock <oliver.b...@aei.mpg.de> 
wrote:
 

 On 29/03/2017 11:55 , Richard Haselgrove wrote:
> Would there be a way to keep the auto-generation of the date and
> author fields, even though the Git SHA isn't helpful in this
> situation?

Yes, use "git log" (see man page for tons of tailoring options).

> Projects also used to show a single SVN number on their server status
> pages, which gave a glimpse of the state of their operational server
> code.

The SHA1s do exactly that, even more precisely.

Best,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

(copying my private replies to the list)


I was thinking of things like 

 
 
 
 
 
 
 
 
 
 

(from https://setiathome.berkeley.edu/forum_index.php) 

We used to be able to see exactly which SVN patches had been applied by any 
given project, and advise accordingly. 

Would there be a way to keep the auto-generation of the date and author fields, 
even though the Git SHA isn't helpful in this situation? 

Projects also used to show a single SVN number on their server status pages, 
which gave a glimpse of the state of their operational server code.

On Wednesday, 29 March 2017, 9:32, David Anderson  
wrote:



The server code was never versioned per se.
It has a change log that is not up to date:
http://boinc.berkeley.edu/trac/wiki/ServerUpdates
-- David
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

And these particular change logs -

http://boinc.berkeley.edu/wiki/Release_Notes_for_BOINC_7.6

https://boinc.berkeley.edu/dev/forum_thread.php?id=10204


are for the Client and GUI only - the server code isn't versioned any longer. 
Sadly. 

On Wednesday, 29 March 2017, 9:09, David Anderson  
wrote:
 

 The change logs are for volunteers,
so that they can see a summary of functional changes and decide whether to 
upgrade.
People who want to see commit notes can read them easily enough.
-- David

On 3/29/2017 1:04 AM, Oliver Bock wrote:
> On 29/03/2017 9:40 , Vitalii Koshura wrote:
>>  From my POV the the most hard part of this is to select important
>> commits only.
> As long as you ignore merge commits, which is easy given their common
> commit message prefix, EVERY commit is important. Changelogs are for
> *various* user groups and thus should be complete (you won't know what's
> "important"!). Sure, this all depends on having proper commits (atomic,
> message prefixes) in the first place, but that's a different problem.
>
> tl;dr: given our scarce resources changelogs should be created
> automatically, as part of a proper release process. Proper commit
> discipline is needed to facilitate that but it's easy to come by.
> Disregarding commit discipline "in favor of" manual changelog harvesting
> would be ridiculous.
>
> Cheers,
> Oliver
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

Using TortoiseGit on a clone, I found that viewing the log from the client and 
clientgui folders only - effectively filtering to select commits which touched 
files in those folders only - generated a shortlist which might be helpful. 

On Wednesday, 29 March 2017, 8:40, Vitalii Koshura 
 wrote:
 

 Hello Oliver,

Thank you for advice.
>From my POV the the most hard part of this is to select important commits
only.

Best regards,
Vitalii Koshura

2017-03-29 9:36 GMT+03:00 Oliver Bock :

> Hi Vitalii,
>
> On 28/03/2017 9:34 , Vitalii Koshura wrote:
> > I can do the hard job and prepare the list of commits for 7.7 release and
> > also prepare the list of fixes with issue numbers.
>
> That doesn't need to be hard. Just use git (log) and generate the
> changelog. All you need to know to do that are the start and end points
> (SHA1s) of the range of commits - but you have to know those as well to
> it manually.
>
> Best,
> Oliver
>
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] Bootstrap

[Richard Haselgrove]

David,
Could you please look at the 'numbered list' format used for messages in both 
search results and user posting history?
At SETI, there is a single visible horizontal rule between the message header 
and the text, and no divider at all between the end-of-text and the header for 
the next message.
At BOINC, it's slightly better with heavier rules between messages and lighter 
rules between header and body - but the distinction is very slight. 

On Thursday, 8 December 2016, 8:45, Jord van der Elst  
wrote:
 

 This doesn't look good on my mobile browser, Dolphin. The main index is now
all squashed together, with the Threads, Posts and Last Post columns are
super imposed over each other, even when I zoom out.
The individual forum indexes do look good.
But then all text in posts are now squashed into a single one-word column,
that I cannot resize.
(Attached for those that can see them, some images)

Even in Chrome the Threads, Posts and Last Post columns are right up
against each other, and here I can only zoom in, not out.
The same post column is now slightly broader, allowing for as many as four
words in the column.


-- Jord van der Elst.

On Thu, Dec 8, 2016 at 3:58 AM, David Anderson 
wrote:

> Thanks; that solved the problem.
> I committed it and deployed on SETI@home.
> I used a slightly wider author column (10em) to accommodate strings like
> "Volunteer moderator".
>
> -- David
>
> On 12/1/2016 1:47 PM, Juha Sointusalo wrote:
>
>>
>> Ok, pre-formatted text stretching table cells and allowing other text to
>> go off-screen.
>>
>> Tables that have pre-formatted text need to be fixed to 100% width:
>>
>> width: 100%;
>> table-layout: fixed;
>>
>> These tables are in Thread view, Post to thread, PM Inbox, Forum search
>> results, Posts by user and Profile: user (the inner table). The theme used
>> in Seti website seems to have tables set to 100% width already but it
>> doesn't hurt to make sure the width stays that even if the theme is changed.
>>
>> When table layout is fixed browser doesn't adjust column widths based on
>> their content any more. Instead the browser divides the available space
>> evenly across the columns unless the browser is told otherwise.
>>
>> Thread view and Post to thread needs width: 8em; set for the author
>> column, PM Inbox needs width: 8em; set for subject and sender columns. The
>> previous style used width: 136px; but that is not exactly responsive to
>> font size changes. I chose 8em because it looks good on my screen.
>>
>> Team search results and Team display are a bit harder. Both could use
>> fixed layout but I'm not sure what to do next. If I limit column widths in
>> Team search results the page looks bad on narrow displays; if I don't it
>> looks bad on wide displays. On Team display page the header that spans the
>> entire table seems to prevent setting width to columns. Anyway, I guess
>> it's rare enough to have very long lines in these two pages so they could
>> probably be left as they are now.
>>
>> The theme used on Seti has black on light grey for  blocks which
>> makes large blocks of text to stand out quite a lot on dark theme. I think
>> monospace font would be enough and would use normal text colour for it.
>>
>> You changed [code] BBcode element to render to  with white-space:
>> pre-wrap;. For some reason the previous style had made  a block level
>> element. Normally it's an inline element, that is, it can be used within
>> text like I have done throughout this message. I would like [code] to be
>> rendered to  with slight adjustment. To keep compatibility with
>> existing uses of [code],  needs white-space: pre-wrap; set. (There's
>> a small snag with using  for multiple lines; the first line is
>> slightly indented.) The colour used for  in Seti theme is... eh,
>> eye-catching, so same treatment as with .
>>
>> Putting those two together:
>>
>> code {
>>    color: inherit;
>> background-color: inherit;
>>    white-space: pre-wrap;
>> }
>>
>> pre {
>>    color: inherit;
>> background-color: inherit;
>>    white-space: pre;
>> }
>>
>> That leaves borders for theme designers to decide.
>>
>> -Juha
>>
>
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Update recommended client to latest available development?

[Richard Haselgrove]

I would agree with making v7.6.33 the recommended download - after all, it is 
now over six months since it was made available for testing.
But that also raises a major question about future client development and 
deployment - a question which is perhaps better addressed to the Project 
Management Committee as a whole, rather than to David as an individual.
How are any future changes found to be necessary or desirable in the BOINC 
client going to be made available to volunteers - I'm thinking specifically in 
the Windows case.
That's a three-stage process:1) Build new binaries2) Package them into an 
installer3) Distribute them via a trusted channel
At the moment, even the build stage is problematic: despite Christian's 
assistance on the BOINC message boards a month ago, none of the build 
dependency sets listed on 
http://boinc.berkeley.edu/trac/wiki/SourceCodeGit#Windowsbuilddependencies is 
currently accessible.
I don't think the tools for updating the Windows installer have ever been 
exposed for community use (there are ISM files in the 'installerv2' folder 
available from github, but I have never found any documentation for how they 
might be maintained and used by the community).
For  many years - see for example github issue 792 and its predecessor trac 
ticket 815 - windows installer issues have been deferred to 'the new open 
source installer'. I would suggest that the PMC should look at all issues - 
including funding - relating to recruiting and empowering somebody with the 
necessary skills to re-invigorate and manage the build/deployment section of 
the development process. 

On Tuesday, 6 December 2016, 10:47, Filip Rydlo  
wrote:
 

 Hi, David and all.
      No objections here too. :-)

      Running *7.6.33* (x64) for *lng* time
 a) on *Windows 10* (at work)  and
 b) on *Windows 7* *Prof.* (home)
    both: without any problems.



Filip R.
P.S. What is the specialization  of Rom?  I could learn it and then do it!
        More specifically  FROM date:  *2017-04-02    .. **indefinitely,
till I'll be alive. :-)*




2016-12-06 1:15 GMT+01:00 David Anderson :

> Anyone object to making 7.6.33 the recommended version?
> It has 96% test coverage, and the only significant reported bug is a
> problem with GPU detection
> with new NVIDIA drivers, which I think is independent of client version.
> -- David
>
>
>  Forwarded Message 
> Subject:        Update recommended client to latest available development?
> Date:  Fri, 18 Nov 2016 11:31:51 +0100
> From:  Jord van der Elst 
> To:    David Anderson 
>
>
>
> Hi David,
>
> Can we have the latest available recommended client from the Download
> pages be set to 7.6.33 for both Mac and Windows, please? As this solves
> quite a bit of problems for users out there with Windows 10 and Mac OS X
> Sierra.
>
> And I'd rather have that version available than the slightly more broken
> ones before that.
> Especially since I doubt we'll have a new client in the foreseeable future
> anyway, with Rom having moved out.
>
> Should I leave Rom as moderator/project developer on the boards?
>
> Thanks,
>
>
> -- Jord van der Elst.
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] Bootstrap

[Richard Haselgrove]

Actually, please check the font used on a variety of browsers and operating 
systems before making a final choice. Here, using Windows 7 and Chrome, the 
SETI font is much clearer than the BOINC message board font, which is still 
rendered using the first iteration of the Bootstrap changes. 

On Wednesday, 30 November 2016, 12:06, Raistmer the Sorcerer 
<raist...@mail.ru> wrote:
 

 Please revert font of SETI main project boards to readable one.
Current font has very bad readability.
Need to say that font of Russian translated text parts remains good one. 
So, please, just revert English font change.




 Вторник, 29 ноября 2016, 21:27 +03:00 от Eric Korpela 
<korp...@ssl.berkeley.edu>:
 
 
We're cancelling this week's outage because of that.


On Tue, Nov 29, 2016 at 8:50 AM, Richard Haselgrove <
r.haselgr...@btopenworld.com> wrote:

> With SETI now down for maintenance, both the main page and the server
> status page show the barest minimum information - much less than before the
> changes.
>
> On Tuesday, 29 November 2016, 15:50, Jord van der Elst <
> els...@gmail.com> wrote:
>
>
> When editing the (Custom) project preferences at Seti (
> https://setiathome.berkeley.edu/prefs.php?subset=project), the Graphics
> Preferences, Text style, Graph style and Color preferences boxes are empty,
> while when selected only the presently selected option is showing because
> the selection colour is blue, the rest are invisible and only show when you
> actually scroll through them. Both the background- and font colours are
> white.
>
> button, input, optgroup, select, textarea {
> color: inherit;
> font: inherit;
> margin: 0;
> }
>
> "The *inherit* keyword specifies that a property should *inherit* its value
> from its parent element. The *inherit* keyword can be used for any *CSS*
> property, and on any HTML element."
> http://www.w3schools.com/cssref/css_inherit.asp
>
>
> -- Jord van der Elst.
>
> On Tue, Nov 29, 2016 at 12:31 AM, David Anderson <da...@ssl.berkeley.edu>
> wrote:
>
> > - I fixed the link appearance issue.
> > Part of the problem was that if you load a http:// stylesheet
> > from a https:// page, it has no effect
> >
> > - I fixed the problems below.
> > The question of what button styles to use (default, primary, danger
> etc.)
> > and when to use buttons instead of links needs to be thought through;
> > I'm not going to do this now. Suggestions welcome.
> >
> > - Yes, we could make the style user-selectable, but I'm not going to do
> > this now.
> >
> > -- David
> >
> > On 11/28/2016 1:58 PM, Juha Sointusalo wrote:
> >
> > On 11 November 2016 at 23:10, David Anderson <da...@ssl.berkeley.edu
> >> <mailto:da...@ssl.berkeley.edu>> wrote:
> >>
> >>
> >> Please send me comments/feedback.
> >>
> >>
> >> Here's a few more:
> >>
> >> - Buttons have various styles. If we decide Reply and Quote buttons to
> be
> >> what all buttons should be then at least these have different style:
> >>
> >> Sort (thread order) (larger font)
> >> Preview and Post reply in Post to thread
> >> Preview and OK in Edit post
> >> Preview and Send Message in Send private message
> >> Create/edit profile in Create a profile
> >>
> >> I think some of the other buttons are different on purpose. There's
> >> small, primary, default and dangerous buttons and maybe some more. I'm
> >> trusting those are the way they should be.
> >>
> >> - Edit post has "Forum" as title
> >>
> >> - In thread view, avatar and Send message button touch each other
> >>
> >> - And the above makes it easy to notice that avatar is a bit to the left
> >> of the button. Maybe both of them could be centred with a small empty
> space
> >> between them.
> >>
> >> As for the colour scheme, here's a quick sketch on how to make it work:
> >> First you or project admins pre-selects a few themes, adding custom
> >> overrides to them if necessary.
> >> Users select their theme from the pre-selected list.
> >> In page_head you link to the CSS file corresponding to the user's
> >> selection, or since themes seem to require fixing, link to a list of CSS
> >> files.
> >>
> >> -Juha
> >>
> >
> > ___
> > boinc_projects mailing list
> > boinc_proje...@ssl.berkeley.edu
> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> > To unsubscribe, visit the above

Re: [boinc_dev] [boinc_projects] Bootstrap

[Richard Haselgrove]

With SETI now down for maintenance, both the main page and the server status 
page show the barest minimum information - much less than before the changes. 

On Tuesday, 29 November 2016, 15:50, Jord van der Elst  
wrote:
 

 When editing the (Custom) project preferences at Seti (
https://setiathome.berkeley.edu/prefs.php?subset=project), the Graphics
Preferences, Text style, Graph style and Color preferences boxes are empty,
while when selected only the presently selected option is showing because
the selection colour is blue, the rest are invisible and only show when you
actually scroll through them. Both the background- and font colours are
white.

button, input, optgroup, select, textarea {
    color: inherit;
    font: inherit;
    margin: 0;
}

"The *inherit* keyword specifies that a property should *inherit* its value
from its parent element. The *inherit* keyword can be used for any *CSS*
property, and on any HTML element."
http://www.w3schools.com/cssref/css_inherit.asp


-- Jord van der Elst.

On Tue, Nov 29, 2016 at 12:31 AM, David Anderson 
wrote:

> - I fixed the link appearance issue.
>  Part of the problem was that if you load a http:// stylesheet
>  from a https:// page, it has no effect
>
> - I fixed the problems below.
>  The question of what button styles to use (default, primary, danger etc.)
>  and when to use buttons instead of links needs to be thought through;
>  I'm not going to do this now.  Suggestions welcome.
>
> - Yes, we could make the style user-selectable, but I'm not going to do
> this now.
>
> -- David
>
> On 11/28/2016 1:58 PM, Juha Sointusalo wrote:
>
> On 11 November 2016 at 23:10, David Anderson > > wrote:
>>
>>
>>    Please send me comments/feedback.
>>
>>
>> Here's a few more:
>>
>> - Buttons have various styles. If we decide Reply and Quote buttons to be
>> what all buttons should be then at least these have different style:
>>
>> Sort (thread order) (larger font)
>> Preview and Post reply in Post to thread
>> Preview and OK in Edit post
>> Preview and Send Message in Send private message
>> Create/edit profile in Create a profile
>>
>> I think some of the other buttons are different on purpose. There's
>> small, primary, default and dangerous buttons and maybe some more. I'm
>> trusting those are the way they should be.
>>
>> - Edit post has "Forum" as title
>>
>> - In thread view, avatar and Send message button touch each other
>>
>> - And the above makes it easy to notice that avatar is a bit to the left
>> of the button. Maybe both of them could be centred with a small empty space
>> between them.
>>
>> As for the colour scheme, here's a quick sketch on how to make it work:
>> First you or project admins pre-selects a few themes, adding custom
>> overrides to them if necessary.
>> Users select their theme from the pre-selected list.
>> In page_head you link to the CSS file corresponding to the user's
>> selection, or since themes seem to require fixing, link to a list of CSS
>> files.
>>
>> -Juha
>>
>
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_projects mailing list
boinc_proje...@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] Bootstrap

[Richard Haselgrove]

I'm using Chrome, and that shows the active decoration at the top of the stack 
on inspection, too.
Plus, on mouseover it shows a checkbox which you can use to deselect the 
decoration: all underlines on the page clear when you toggle that.
The 
table a:not(.btn), .table a:not(.btn) {
    text-decoration:  
appears (a very long way down) in bootstrap.min.css 

On Monday, 28 November 2016, 19:38, Juha Sointusalo 
 wrote:
 

 On 28 November 2016 at 21:20, David Anderson  wrote:

> I noticed that, and was unable to fix it.
>
> The Bootstrap css (both the standard one and the dark one I'm using)
> indicate links by making them bold (no underline).
> I don't know why we're getting underlines.
>
> Can anyone figure this out?
>

Both Opera and Firefox shows a stack of styles and their source when you
inspect an element. Styles that are overridden by later ones are
crossed-out. The underlines come from

table a:not(.btn), .table a:not(.btn) {
    text-decoration: underline;
}

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] Bootstrap

[Richard Haselgrove]

The current (since about 24 hours ago) iteration at SETI@Home is showing 99% of 
links underlined, whereas SETI Beta and BOINC show none underlined that I can 
find. I'd like to see consistency - certainly within any one single site, and 
ideally across the BOINC family as a whole, and the current internet fashion 
seems to be to rely on color alone (and sometimes not even that) to identify a 
hyperlink. SETI is currently looking old-fashioned in that respect. 

On Monday, 28 November 2016, 9:14, David Anderson  
wrote:
 

 Thanks for compiling the list.
I dealt with all of these except the signature images not being side by side.
I couldn't figure this out.
In some cases I had to use custom CSS (see custom.css).

Bootstrap sometimes works in mysterious ways.
For example, the grid system resizes columns discretely rather than 
continuously - why?

The code does some things the Bootstrap way, some things the old way
(like ).
I'm not going to change these, but if anyone wants to do so feel free
(as long as the results are an actual improvement).

Are there any remaining showstoppers?
If not I'd like to merge the bootstrap branch.

-- David


On 11/27/2016 1:40 PM, Juha Sointusalo wrote:
> On 11 November 2016 at 23:10, David Anderson  > wrote:
>
>    I revised the BOINC web code (PHP) to use Bootstrap CSS
>
>    Please send me comments/feedback.
>
>
> Collected from forums:
>
> - Font size of quoted text is larger than normal text. I see that you 
> adjusted it 
> for Seti Main but it's still one notch larger.
>
> - If author panel is taller than message panel the message and buttons are 
> kinda 
> vertically centred or something. It would look better if message text was top 
> aligned and buttons bottom aligned.
>
> - Task list's Application column has two rows even when there would enough 
> room to 
> put it all in one row. (I'm not sure what prompted that request - it doesn't 
> look 
> like you changed anything there.)
>
> - Pre-formatted text appears to be always black on light grey. It doesn't 
> work too 
> well on dark themes.
>
> - Seti server status page links to custom.css and sah_logo_wb.png are 
> hardcoded to 
> use HTTP even when the page itself is retrieved over HTTPS.
>
> Also, links to RSS feed, Seti home page, BOINC addons page and BOINC home use 
> HTTP 
> always. I'd rather have them use the same protocol that was used for the 
> status page.
>
> Now realising that it's a static HTML page, maybe just use HTTPS everywhere.
>
> - Two images in signature used to be side by side. Now they are one above the 
> other.
>
> - Menus don't open on mouse hover. (I suppose whether they open by clicking 
> or 
> hover is a matter of personal preference. I don't mind clicking.)
>
> - Post to thread page is apparently not so responsive and on phones in 
> portrait 
> mode the text box is pretty narrow.
>
> - Top participants, Top teams, Team membership lists and some more (ask 
> Richard) 
> have some column heading aligned differently from the actual data.
>
> - Stats site icons and dark theme don't work well together, Free-DC icon is 
> barely 
> visible.
>
> - Post to thread text box is still black on white on dark themes.
>
> - In private message preview the word "Preview" and the message are merged.
>
> - Stock server status page (Seti Beta) doesn't render correctly at widths 
> ~770 to 
> ~990.
>
> - Text wrapping and colours, which will get their own posts tomorrow.
>
> Apart from the usual "Changes? Over my dead body!" you did get some positive 
> feedback too.
>
> -Juha

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: 'client_state.xml' : GPU info for workunit/result

[Richard Haselgrove]

Juha is right -  has to match , NOT to 
 - my mistake. 

On Sunday, 27 November 2016, 15:38, Juha Sointusalo 
 wrote:
 

 On 27 November 2016 at 17:20, Jean Philippe EIMER  wrote:

>
> I agree, I also noticed  has the info.
> But, the  info is not in  or .
>

You need to use app_name, app_version, platform and plan_class quadruplet
to identify an app version.

Workunit has app_name and app_version, result has platform, version_num and
plan_class and a reference to workunit.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_projects] Bootstrap status

[Richard Haselgrove]

I'm seeing a problem with the {sticky,read} flag at SETI. 

On Friday, 25 November 2016, 22:05, David Anderson  
wrote:
 

 I'm pretty much done with changing the BOINC web code to use Bootstrap.
Examples:

http://boinc.berkeley.edu/test/
    uses standard bootstrap theme

http://setiathome.berkeley.edu/
    uses a theme called "Slate" that I found on the web.

Notes:
- I changed the sample index.php to have a graphic at the top,
  and to have a "Join" button rather than a lot of text
  (thanks to E@h for suggesting this).
- The default banner consists of a navbar, which you can customize.
- It's "responsive", i.e. it works on phones

---

This is on Github in a branch called "bootstrap".
Any objections to merging this into master?
This will mean that the next time you upgrade your BOINC web code,
you'll have to do a bit of work on your home page and banner.
For SETI@home, this conversion took about 30 minutes.
I'm happy to help other projects with this.

-- David
___
boinc_projects mailing list
boinc_proje...@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: Bootstrap

[Richard Haselgrove]

Also, the new message board format has removed the highlighting of search hits 
in forum search results. 

On Tuesday, 15 November 2016, 14:31, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:
 

 I don't think that code boxes have ever wrapped, and I would plead against 
them doing so. But they certainly did have their own horizontal scroll bar, so 
that they didn't affect the plain text wrapping elsewhere in the thread.
A few years ago, we had the same problem of over-size images rendering other 
text posts in the same thread unreadable for lack of wrapping: it would be wise 
to check that case too, plus the use of [pre] tags to preserve tabular 
formatting. 

    On Tuesday, 15 November 2016, 14:05, Jord van der Elst <els...@gmail.com> 
wrote:
 

 Something else, similar.
In Firefox, when someone uses the [code][/code] tags, these do not wrap
long sentences. This means that text inside and outside the code box runs
off the right side of the screen.
It also means text in previous and later posts can run of the right side of
the screen.

Example thread:
https://boinc.berkeley.edu/dev/forum_thread.php?id=11290=74082 has a
code box with the processor features running off the side of the screen.
This affects the post previous to that one and also earlier posts in that
thread.
The solution we had in BOINC, was I think that the text in code boxes
wrapped at the end of screen, or that the code box had its own horizontal
scroll bar. We do need something similar here.


-- Jord van der Elst.

On Mon, Nov 14, 2016 at 11:41 PM, David Anderson <da...@ssl.berkeley.edu>
wrote:

> I noticed (as Jord did) that with the recent Bootstrap changes,
> some pages have absurdly large text the first time you view them
> in a particular browser.
> Once you shrink it (e.g. with ctrl-minus) it's OK after that.
> I don't know why this is - any guesses?
> -- David
>
>
>
>  Forwarded Message 
> Subject:        Re: [boinc_dev] Bootstrap
> Date:  Mon, 14 Nov 2016 23:01:38 +0100
> From:  Jord van der Elst <els...@gmail.com>
> To:    David Anderson <da...@ssl.berkeley.edu>
>
>
>
> Hi David,
>
> Attached a couple of screen shots from my phone with the latest settings
> of the forums.
> Dolphin, image 1 to 5, shows how one of the threads looks like from my
> viewpoint. 1 to 4 show the thread at 'normal' size, when I zoom in (pinch),
> I get what image 5 shows: a long thin thread that doesn't auto-fill the
> window.
>
> The other image is that of Chrome, the index of the forums. Initially I
> could not zoom in, or resize it in any way.
> My accessibility settings were for text-scaling to be 107%, which I take
> is the default as I never changed it. Only after I changed it to 135%, and
> double-tapped the index, could I zoom in. But that just does that, it zooms
> in, but leaves everything in proportion on the screen, so lots of scrolling
> going on.
>
>
> (It also shows that Chrome recognizes the page as not being true https)
>
> -- Jord van der Elst.
>
>
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Fwd: Re: Bootstrap

[Richard Haselgrove]

I don't think that code boxes have ever wrapped, and I would plead against them 
doing so. But they certainly did have their own horizontal scroll bar, so that 
they didn't affect the plain text wrapping elsewhere in the thread.
A few years ago, we had the same problem of over-size images rendering other 
text posts in the same thread unreadable for lack of wrapping: it would be wise 
to check that case too, plus the use of [pre] tags to preserve tabular 
formatting. 

On Tuesday, 15 November 2016, 14:05, Jord van der Elst  
wrote:
 

 Something else, similar.
In Firefox, when someone uses the [code][/code] tags, these do not wrap
long sentences. This means that text inside and outside the code box runs
off the right side of the screen.
It also means text in previous and later posts can run of the right side of
the screen.

Example thread:
https://boinc.berkeley.edu/dev/forum_thread.php?id=11290=74082 has a
code box with the processor features running off the side of the screen.
This affects the post previous to that one and also earlier posts in that
thread.
The solution we had in BOINC, was I think that the text in code boxes
wrapped at the end of screen, or that the code box had its own horizontal
scroll bar. We do need something similar here.


-- Jord van der Elst.

On Mon, Nov 14, 2016 at 11:41 PM, David Anderson 
wrote:

> I noticed (as Jord did) that with the recent Bootstrap changes,
> some pages have absurdly large text the first time you view them
> in a particular browser.
> Once you shrink it (e.g. with ctrl-minus) it's OK after that.
> I don't know why this is - any guesses?
> -- David
>
>
>
>  Forwarded Message 
> Subject:        Re: [boinc_dev] Bootstrap
> Date:  Mon, 14 Nov 2016 23:01:38 +0100
> From:  Jord van der Elst 
> To:    David Anderson 
>
>
>
> Hi David,
>
> Attached a couple of screen shots from my phone with the latest settings
> of the forums.
> Dolphin, image 1 to 5, shows how one of the threads looks like from my
> viewpoint. 1 to 4 show the thread at 'normal' size, when I zoom in (pinch),
> I get what image 5 shows: a long thin thread that doesn't auto-fill the
> window.
>
> The other image is that of Chrome, the index of the forums. Initially I
> could not zoom in, or resize it in any way.
> My accessibility settings were for text-scaling to be 107%, which I take
> is the default as I never changed it. Only after I changed it to 135%, and
> double-tapped the index, could I zoom in. But that just does that, it zooms
> in, but leaves everything in proportion on the screen, so lots of scrolling
> going on.
>
>
> (It also shows that Chrome recognizes the page as not being true https)
>
> -- Jord van der Elst.
>
>
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

[Richard Haselgrove]

On Monday, 15 August 2016, 19:55, "McLeod, John"  wrote:


 

 A few notes.
...3)  How do we handle failed / late / invalid tasks?  Ones that have used 
resources, but are not going to generate credit?  Projects with a large % of 
failed / late / invalid tasks on this compute?

Ideally, by having a far more robust than current quota restriction system. 
There's no point in permitting continued 'participation' in a scientific 
research project by a host which is no longer contributing valid science (if it 
ever did) - and whose owner shows no willingness to engage with the project 
administrators or the rest of the volunteer community. We all know who they are 
and where they can be found.
Projects where the scientific administrators show no willingness to engage with 
the rest of the volunteer community are a different kettle of fish entirely.



  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] BOINC exit status numbers

[Richard Haselgrove]

OK, so the 

Re: [boinc_dev] BOINC exit status numbers

[Richard Haselgrove]

Following on from
0xC26B


STATUS_DLL_INIT_FAILED_LOGOFF{DLL Initialization Failed}
The application failed to initialize because the window station is shutting 
down.

David, thanks for cleaning the exit status formatting - that will make it much 
easier to track down the true meaning of these messages.
Rom - I've made a private build to see if catching the 0xC26B case with a 
'will_restart' exit helps. The exit status isn't new - Google searches find 
tasks at sztaki dated January 2014, and CPDN dated August 2013, still unpurged. 
Both those machines are currently running Windows 7, as were the majority of 
the machines discussed in the SETI message board thread.
One additional problem reveals itself in my build from Head - every Event Log 
message is escaped, like

02/06/2016 14:00:54 |  |   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC exit status numbers

[Richard Haselgrove]

BOINC reports and displays exit status on the user web, typically, in a 
negative 64-bit hexadecimal format. Today's trending number is

0xc26b


as in http://setiathome.berkeley.edu/result.php?resultid=4947399120:

Exit status -1073741205 (0xc26b) Unknown error number


If you Google the 64-bit Hex version of the error number, the results you get 
are, exclusively, BOINC task pages or BOINC message board discussions, like 
http://setiathome.berkeley.edu/forum_thread.php?id=79695. But Windows error 
numbers are conventionally represented as 32-bit positive Hex numbers, which 
leads us to a very simple understanding.

0xC26BSTATUS_DLL_INIT_FAILED_LOGOFF{DLL Initialization Failed}
The application failed to initialize because the window station is shutting 
down.

Unless other operating systems require 64-bit error numbers (or Microsoft has 
indicated an intention to switch to 64-bit numbers in the future), could we use 
a 32-bit reporting format, please?
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Astonishing effect of Link Time Optimisation on BOINC client

[Richard Haselgrove]

Doesn't the formal definition of the benchmarks (both Dhrystone and Whetstone) 
attempt to exclude compiler optimisations?
OK, so we've already broken that principle by allowing optimisation in the 
Android benchmark code, but I think that it would be wise to evaluate the 
effect of LTO on a sample Linux project science applications, before distorting 
the x86 operating system balance in this way.
You raise the dread word "credit". It is possible to distort the supposed 
definition of the cobblestone in various ways, by optimising or dis-optimising 
either the benchmark code, the scientific application code, or both. Rather 
than making unilateral changes, wouldn't it be better to have a proper review 
of the now rather elderly CreditNew framework? 

On Monday, 9 May 2016, 11:07, Steffen Möller  wrote:
 

 Dear all,

some of you may be aware of the BOINC client shipping with Debian,
Ubuntu, Mint and the other .deb-based Linux distributions [1]. While
updating to 7.6.32 we have revised our invocation of the Link Time
Optimisation (LTO) [2]. This had the effect of a notable reduction
of the disk-space occupied by the (stripped) binaries:

previous revised change
 7.6.31  7.6.32  
1292528  932032  -28%  /usr/bin/boinc
  34904    30864  -16%  /usr/bin/boinccmd
3657424  2292936  -37%  /usr/bin/boincmgr
  26464    26464    0%  /usr/lib/x86_64-linux-gnu/libboinc_crypt.so.7.6.32
 665960  665960    0%  /usr/lib/x86_64-linux-gnu/libboinc.so.7.6.32
 467392  467392    0%  /usr/lib/x86_64-linux-gnu/libboinc_zip.so.7.6.32

We cannot assess the effect on BOINC. But we reckon that the effort to
quickly bring BOINC functionality into action and then hide it again is
likely proportional to the reduction of the code base. LTO is also know
to help the computation - not surprisingly so since less code needs to be
processed for the same functionality. Completely ignorant of the complexity
of the BOINC benchmark, we just went and checked *boinccmd --run_benchmarks*
with the following results:

v7.6.31 (prior to revision)

09-May-2016 03:39:53 [---]    3973 floating point MIPS (Whetstone) per CPU
09-May-2016 03:39:53 [---]    17322 integer MIPS (Dhrystone) per CPU
09-May-2016 03:42:22 [---]    4087 floating point MIPS (Whetstone) per CPU
09-May-2016 03:42:22 [---]    17774 integer MIPS (Dhrystone) per CPU
09-May-2016 03:43:17 [---]    4069 floating point MIPS (Whetstone) per CPU
09-May-2016 03:43:17 [---]    17988 integer MIPS (Dhrystone) per CPU

v7.6.32 (after revision)
09-May-2016 03:45:18 [---]    3961 floating point MIPS (Whetstone) per CPU
09-May-2016 03:45:18 [---]    78155 integer MIPS (Dhrystone) per CPU
09-May-2016 03:46:35 [---]    4057 floating point MIPS (Whetstone) per CPU
09-May-2016 03:46:35 [---]    76289 integer MIPS (Dhrystone) per CPU
09-May-2016 03:48:42 [---]    3962 floating point MIPS (Whetstone) per CPU
09-May-2016 03:48:42 [---]    76374 integer MIPS (Dhrystone) per CPU

We tried two different computers with equivalent quadruplication of the
integer performance only. The change is the same as for v7.6.32 without
the LTO corrections, which vividly demonstrates how sensitive the LTO
compiler flags are. The -flto flags we had first added one or two years
ago.

Expected was to observe a 20% speedup that is frequently reported for
LTO. Without further investigation, the 300% we consider to be somehow
explainable - with hindsight - such that the application could be optimised
in a way that it is also faster for regular compilation. But why bother
if LTO has become so usable. And helpful. And controllable by merely 
looking at what it does to the disk footprint.

This email has two messages:
 * If using the Debian client already, please update to 7.6.32 that is now
  in Debian unstable and comes to you any time soon. It reduces the memory
  footprint, which helps the scientific app, a bit, and because of an
  astonishing effect on the benchmark, this also helps your RAC. (This is
  until BOINC developers adopt LTO also for their publicly offered builds.)
 * It hopes to be an eye opener. The scientific applications are the ones
  that should all adopt LTO. It is working, also for static binaries. But
  expect a 20% speedup, not as much as with the client's benchmarks. 

Keep crunching

Gianfranco and Steffen


[1] https://wiki.debian.org/BOINC
[2] https://gcc.gnu.org/onlinedocs/gccint/LTO.html#LTO

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] client in master is broken

[Richard Haselgrove]

Um. Would you mind if I let someone else test that one?  :P

(I've just spent some time re-updating from an old client_state file, and 
getting my projects running cleanly again. A few tasks lost, but no point in 
worrying about those. Fortunately, this was a new machine, recently attached: I 
was setting up and testing the build system because David suggested he might 
need to remote in to debug the strange "additional CPU scheduling problem" I 
reported about 10 days ago. David, we'd better let the Head code settle for a 
day or two before we try that.)



On Tuesday, 16 February 2016, 15:11, Rom Walton <r...@romwnet.org> wrote:
I believe I've just fixed that issue.

- Rom


-Original Message-----
From: Richard Haselgrove [mailto:r.haselgr...@btopenworld.com] 
Sent: Tuesday, February 16, 2016 9:45 AM
To: Rom Walton <r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

Ouch. Big, big problems.

Client built OK, no errors or warnings. And it runs OK - I can see the client, 
and project science apps, running in Process Explorer.

BUT:

Nothing can connect to it - not local Manager, not remote Manager, not my 
faithful old BoincView. Even this fails:

D:\BOINC>D:\BOINC\boinccmd.exe --quit 
Authorization failure: -102 

D:\BOINC>

And I see

16-Feb-2016 14:25:01 [---] Creating new client state file

The new state file has, in many places but not everywhere, a [nul] character 
after a closing tag where I would expect to see a newline

Significant files attached.


On Tuesday, 16 February 2016, 13:55, Rom Walton <r...@romwnet.org> wrote:
I've fixed the issue created by switching over to strlcat.

The warnings have, more or less, always been there.  We just suppressed them in 
Visual Studio 2005.

Unfortunately, what they suggest we use is not cross-platform.  So we are 
having to hunt down the cross platform equivs.

- Rom


-Original Message-
From: McLeod, John [mailto:john.mcl...@sap.com] 
Sent: Tuesday, February 16, 2016 8:25 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] client in master is broken

The _s functions do a better job of avoiding buffer overruns.  IIRC, they force 
the programmer to tell the function the size of the target buffer.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Tuesday, February 16, 2016 8:18 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

And the resulting client failed with "A buffer overrun has occurred in 
boinc.exe which has corrupted the program's internal state. Press Break to 
debug the program or Continue to terminate the program."

Pressing Break dropped me into the source at 


>boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers) 
> Line 85C 
boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241C 
boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
DispatcherContext) Line 91C 
ntdll.dll!775b8bbd()Unknown 
ntdll.dll!775a875f()Unknown 
ntdll.dll!775dd348()Unknown 
msvcr120.dll!07fef313c3f9()Unknown 
()Unknown 
0080()Unknown 
boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 78  
  C++ 
boinc.exe!get_processor_features(char * vendor, char * features, int 
features_size) Line 1198C++ 
boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
p_model, int p_model_size, char * p_features, int p_features_size, double & 
p_cache, int & p_ncpus) Line 1305C++ 


On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:



Rom,

The fix you made last night solved the build problem in VS2013 - thanks.

But your overnight work on the 'low hanging fruit' has triggered a huge number 
of VS2013 warnings - 469 when building boinccmd, which includes the client 
build as part of the solution.

All seem to be C4996 - sample below. In each case, the 'consider using' 
suggestion seems to be to replace the function (several different functions are 
named) with function_s

e.g.

Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
Consider using ctime_s instead. To disable deprecation, use 
_CRT_SECURE_NO_WARNINGS. See online help for details.

D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd


On Monday, 15 February 2016, 20:29, Rom Walton <r...@romwnet.org> wrote:



Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkel

Re: [boinc_dev] client in master is broken

[Richard Haselgrove]

Ouch. Big, big problems.

Client built OK, no errors or warnings. And it runs OK - I can see the client, 
and project science apps, running in Process Explorer.

BUT:

Nothing can connect to it - not local Manager, not remote Manager, not my 
faithful old BoincView. Even this fails:

D:\BOINC>D:\BOINC\boinccmd.exe --quit 
Authorization failure: -102 

D:\BOINC>

And I see

16-Feb-2016 14:25:01 [---] Creating new client state file

The new state file has, in many places but not everywhere, a [nul] character 
after a closing tag where I would expect to see a newline

Significant files attached.


On Tuesday, 16 February 2016, 13:55, Rom Walton <r...@romwnet.org> wrote:
I've fixed the issue created by switching over to strlcat.

The warnings have, more or less, always been there.  We just suppressed them in 
Visual Studio 2005.

Unfortunately, what they suggest we use is not cross-platform.  So we are 
having to hunt down the cross platform equivs.

- Rom


-Original Message-
From: McLeod, John [mailto:john.mcl...@sap.com] 
Sent: Tuesday, February 16, 2016 8:25 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] client in master is broken

The _s functions do a better job of avoiding buffer overruns.  IIRC, they force 
the programmer to tell the function the size of the target buffer.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Tuesday, February 16, 2016 8:18 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

And the resulting client failed with "A buffer overrun has occurred in 
boinc.exe which has corrupted the program's internal state. Press Break to 
debug the program or Continue to terminate the program."

Pressing Break dropped me into the source at 


>boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers) 
> Line 85C 
boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241C 
boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
DispatcherContext) Line 91C 
ntdll.dll!775b8bbd()Unknown 
ntdll.dll!775a875f()Unknown 
ntdll.dll!775dd348()Unknown 
msvcr120.dll!07fef313c3f9()Unknown 
()Unknown 
0080()Unknown 
boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 78  
  C++ 
boinc.exe!get_processor_features(char * vendor, char * features, int 
features_size) Line 1198C++ 
boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
p_model, int p_model_size, char * p_features, int p_features_size, double & 
p_cache, int & p_ncpus) Line 1305C++ 


On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:



Rom,

The fix you made last night solved the build problem in VS2013 - thanks.

But your overnight work on the 'low hanging fruit' has triggered a huge number 
of VS2013 warnings - 469 when building boinccmd, which includes the client 
build as part of the solution.

All seem to be C4996 - sample below. In each case, the 'consider using' 
suggestion seems to be to replace the function (several different functions are 
named) with function_s

e.g.

Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
Consider using ctime_s instead. To disable deprecation, use 
_CRT_SECURE_NO_WARNINGS. See online help for details.

D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd


On Monday, 15 February 2016, 20:29, Rom Walton <r...@romwnet.org> wrote:



Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Monday, February 15, 2016 3:09 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

I also found that the Windows VS2013 solution failed to build the client from 
tags 7.6.24, 7.6.25, and head.
Managed to fix it by adding references to '..\lib\project_init.cpp' and 
'..\lib\project_init.h' to the  lists in both 
boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj

With that adjustment, head (debug) seems to be running. 

  

On Tuesday, 9 February 2016, 13:31, Oliver Bock <oliver.b...@aei.mpg.de> wrote:


On 09/02/16 14:10 , Rom Walton wrote:
> Should be fixed now.

Please, please, please. It's been about three years since we migrated to git. 
BOINC moved to GitHub just recently and tries to adopt a community governance 
model. It should really be possible by now that devs start using feature 
branches for development and save everyone else from periodic head

Re: [boinc_dev] client in master is broken

[Richard Haselgrove]

And the resulting client failed with "A buffer overrun has occurred in 
boinc.exe which has corrupted the program's internal state. Press Break to 
debug the program or Continue to terminate the program."

Pressing Break dropped me into the source at 


>   boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * 
> ExceptionPointers) Line 85  C 
boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241 C 
boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
DispatcherContext) Line 91 C 
ntdll.dll!775b8bbd()Unknown 
ntdll.dll!775a875f()Unknown 
ntdll.dll!775dd348()Unknown 
msvcr120.dll!07fef313c3f9() Unknown 
()  Unknown 
0080()  Unknown 
boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 78  
C++ 
boinc.exe!get_processor_features(char * vendor, char * features, int 
features_size) Line 1198   C++ 
boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
p_model, int p_model_size, char * p_features, int p_features_size, double & 
p_cache, int & p_ncpus) Line 1305   C++ 


On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:



Rom,

The fix you made last night solved the build problem in VS2013 - thanks.

But your overnight work on the 'low hanging fruit' has triggered a huge number 
of VS2013 warnings - 469 when building boinccmd, which includes the client 
build as part of the solution.

All seem to be C4996 - sample below. In each case, the 'consider using' 
suggestion seems to be to replace the function (several different functions are 
named) with function_s

e.g.

Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
Consider using ctime_s instead. To disable deprecation, use 
_CRT_SECURE_NO_WARNINGS. See online help for details.

D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd


On Monday, 15 February 2016, 20:29, Rom Walton <r...@romwnet.org> wrote:



Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Monday, February 15, 2016 3:09 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

I also found that the Windows VS2013 solution failed to build the client from 
tags 7.6.24, 7.6.25, and head.
Managed to fix it by adding references to '..\lib\project_init.cpp' and 
'..\lib\project_init.h' to the  lists in both 
boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj

With that adjustment, head (debug) seems to be running. 

  

On Tuesday, 9 February 2016, 13:31, Oliver Bock <oliver.b...@aei.mpg.de> wrote:


On 09/02/16 14:10 , Rom Walton wrote:
> Should be fixed now.

Please, please, please. It's been about three years since we migrated to git. 
BOINC moved to GitHub just recently and tries to adopt a community governance 
model. It should really be possible by now that devs start using feature 
branches for development and save everyone else from periodic headaches. It's 
not hard by any means and it comes with huge incentives for everyone involved.

So please, use feature branches for development; merge to master when you're 
done with testing; don't break master; be happy; make everyone else happy...

THANKS!


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] client in master is broken

[Richard Haselgrove]

I also found that the Windows VS2013 solution failed to build the client from 
tags 7.6.24, 7.6.25, and head.
Managed to fix it by adding references to '..\lib\project_init.cpp' and 
'..\lib\project_init.h' to the  lists in both 
boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj

With that adjustment, head (debug) seems to be running. 

   

 On Tuesday, 9 February 2016, 13:31, Oliver Bock  wrote:
 

 On 09/02/16 14:10 , Rom Walton wrote:
> Should be fixed now.

Please, please, please. It's been about three years since we migrated to
git. BOINC moved to GitHub just recently and tries to adopt a community
governance model. It should really be possible by now that devs start
using feature branches for development and save everyone else from
periodic headaches. It's not hard by any means and it comes with huge
incentives for everyone involved.

So please, use feature branches for development; merge to master when
you're done with testing; don't break master; be happy; make everyone
else happy...

THANKS!


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Default process priority

[Richard Haselgrove]

Thanks - that at least keeps the previous values, and I see that the two groups 
can be set (or not set) independently. I've updated the Wiki to match.

Does anybody know whether either Daniel Hendrycks (original trac request) or 
Aen Bleidd (patch contributor) is in a position to follow this discussion - I 
can't match either of them to an email address on the subscriber list, and I 
don't know which project(s) they might be active at.

We might be able to mention that Daniel's original problem could have been 
solved by using Process Lasso - that's what I use for the one and only 
Einstein@Home application version which runs best at REALTIME priority (I 
wouldn't wan't to switch the whole of BOINC to that, for obvious reasons).



> On Wednesday, 30 September 2015, 6:35, David Anderson 
> <da...@ssl.berkeley.edu> wrote:
> > How about if you can specify two priorities in cc_config.xml:
>  for CPU-intensive apps,and
> for others (GPU, NCI, wrapper).
> -- David
> 
> 
> On 9/29/2015 2:32 PM, Richard Haselgrove wrote:
>>  The trouble with this global starting point is that - if selected - it 
> knocks out the subtle, planned, evolved behaviour which BOINC already has for 
> managing priority.
>> 
>>  We currently have special priority cases (in the sense of OS run priority - 
> point taken, and well made) for NCI apps, GPU apps, and wrapper apps. All of 
> those go out of the window if the user chooses a Default Process Priority. 
> This 
> feels like a special case for the benefit of users who run one project only 
> under BOINC, and as such rather mitigates against the vision of BOINC as a 
> project-neutral (and multi-project) infrastructure.
>> 
>> 
>> 
>>>  On Tuesday, 29 September 2015, 21:00, David Anderson 
> <da...@ssl.berkeley.edu> wrote:
>>>>  We could increase the resolution;
>>>  a global setting is a good starting point.
>>> 
>>>  Just so everyone knows:
>>>  this involves the OS priority at which tasks run,
>>>  not BOINC's prioritization of tasks (i.e. which ones run first).
>>> 
>>>  -- David
>>> 
>>>  On 9/29/2015 1:10 AM, Richard Haselgrove wrote:
>>>>Is it really appropriate for the new Default process priority 
> switch to
>>>  operate at the cc_config level?
>>>>I'd have thought it was a more natural fit for app_config, so 
> that the
>>>  user could adjust the relative priority of different projects, 
> different
>>>  applications, and even different app_versions.
>>>>___
>>>>boinc_dev mailing list
>>>>   boinc_dev@ssl.berkeley.edu
>>>>   http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>>>>To unsubscribe, visit the above URL and
>>>>(near bottom of page) enter your email address.
>>> 
>>>  ___
>>>  boinc_dev mailing list
>>>  boinc_dev@ssl.berkeley.edu
>>>  http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>>>  To unsubscribe, visit the above URL and
>>>  (near bottom of page) enter your email address.
>>> 
> 
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] When using HTTPS in image container tag, image doesn't show.

[Richard Haselgrove]

I'm not sure it's as simple as that. Trying a few random image urls directly in 
my browser (Chrome) address bar, some rendered differently when accessed via 
HTTPS - e.g. protobucket switched to an html frame. But even when I found an 
image which rendered normally in https, and pasted the url into a message board 
post at a project I was accessing via https, it still just displayed the 
'broken image link' icon.



On Wednesday, 2 September 2015, 15:06, Rom Walton  wrote:


>
>
>I do believe that is a browser setting.
>
>For instance, Internet Explorer has two different advanced settings dealing 
>with warning/blocking mixed protocol content.
>
>- Rom
>
>From: boinc_ad...@googlegroups.com [mailto:boinc_ad...@googlegroups.com] On 
>Behalf Of Jord van der Elst
>Sent: Wednesday, September 02, 2015 5:42 AM
>To: BOINC Dev Mailing List 
>Cc: boinc_ad...@googlegroups.com
>Subject: [boinc_admin] When using HTTPS in image container tag, image doesn't 
>show.
>
>Any images that use HTTPS in their URL do not show in the BOINC forums. The 
>image URL needs HTTP at the moment to work correctly.
>
>-- Jord van der Elst.
>--
>You received this message because you are subscribed to the Google Groups 
>"boinc_admin" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to 
>boinc_admin+unsubscr...@googlegroups.com.
>To post to this group, send email to 
>boinc_ad...@googlegroups.com.
>To view this discussion on the web visit 
>https://groups.google.com/d/msgid/boinc_admin/CAEXjb0eETQfkTJyoBG4tOr9ctDyCw%2BFGy2W8gm5_Z8ys2A14-A%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.
>
>___
>boinc_dev mailing list
>boinc_dev@ssl.berkeley.edu
>http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>To unsubscribe, visit the above URL and
>(near bottom of page) enter your email address.
>
>
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] make Github repo the master?

[Richard Haselgrove]

I think we need some consequential changes on 
http://boinc.berkeley.edu/trac/wiki/SourceCodeGit - which is linked directly 
from the from the front page. In particular, the link in the very first bullet 
point no longer contains the actual source code - I presume all these various 
sundry sub-gits will be migrated in due course. 


 On Monday, 27 July 2015, 18:32, Rom Walton r...@romwnet.org wrote:
   
 

 Here is the URL you would use on github:
https://github.com/BOINC/boinc/commits/master
https://github.com/BOINC/boinc/commits/client_release/7/7.6

- Rom

-Original Message-
From: Jord van der Elst [mailto:els...@gmail.com] 
Sent: Monday, July 27, 2015 1:28 PM
To: David Anderson da...@ssl.berkeley.edu
Cc: Rom Walton r...@romwnet.org; BOINC Dev Mailing List 
boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

The only other question is, where have these gone to?

https://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=log
https://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=log;h=refs/heads/client_release/7/7.6

At least not to, e.g.
https://github.com/BOINC/gitweb/?p=boinc.git;a=log;h=refs/heads/client_release/7/7.6

-- Jord van der Elst.


On Mon, Jul 27, 2015 at 7:23 PM, Jord van der Elst els...@gmail.com wrote:
 I did it like this for the GUI:
 Right click on my local repository, Git-Pull In the window that opens, 
 click Manage remotes.
 Either add BOINC as a remote, or change the URL from what it was to 
 https://github.com/BOINC/boinc.git
 Click Apply.
 Next in the Git Pull window, choose BOINC, check that the branch is 
 still correct, then click OK.


 -- Jord van der Elst.


 On Mon, Jul 27, 2015 at 7:17 PM, David Anderson da...@ssl.berkeley.edu 
 wrote:
 How do we do that?
 -- David

 On 27-Jul-2015 10:15 AM, Rom Walton wrote:


 As of now, the authoritative BOINC repo is on github.

 Please change your origin repo to point to github.

 Thanks.

 - Rom

 *From:*Rom Walton
 *Sent:* Thursday, July 23, 2015 11:30 AM
 *To:* 'Eric J Korpela' korp...@ssl.berkeley.edu; David Anderson 
 da...@ssl.berkeley.edu
 *Cc:* boinc_ad...@googlegroups.com; BOINC Dev Mailing List 
 boinc_dev@ssl.berkeley.edu
 *Subject:* RE: [boinc_admin] make Github repo the master?

 I plan on doing the changeover on the 27^th .

 After the change, everybody should only need to change the git 
 origin repo configuration to https://github.com/BOINC/boinc.git within 
 their local repo.

 - Rom

 *From:*boinc_ad...@googlegroups.com 
 mailto:boinc_ad...@googlegroups.com
 [mailto:boinc_ad...@googlegroups.com] *On Behalf Of *Eric J Korpela
 *Sent:* Wednesday, July 22, 2015 8:51 PM
 *To:* David Anderson da...@ssl.berkeley.edu 
 mailto:da...@ssl.berkeley.edu
 *Cc:* boinc_ad...@googlegroups.com 
 mailto:boinc_ad...@googlegroups.com
 *Subject:* Re: [boinc_admin] make Github repo the master?

 Be sure to give a shout out when this happens.

 On Mon, Jul 20, 2015 at 10:00 PM, David Anderson 
 da...@ssl.berkeley.edu mailto:da...@ssl.berkeley.edu wrote:

    I propose making the BOINC repo on Github the master repo
    (rather than the one on the UCB server).

    This will make it easier to control who has commit access,
    and will make this info publicly visible.

    Any objections or comments?
    If not we'll do this in a couple of days.

    -- David

    --    You received this message because you are subscribed to the
 Google Groups
    boinc_admin group.
    To unsubscribe from this group and stop receiving emails from 
 it, send an
    email to boinc_admin+unsubscr...@googlegroups.com
    mailto:boinc_admin%2bunsubscr...@googlegroups.com.
    To post to this group, send email to boinc_ad...@googlegroups.com
    mailto:boinc_ad...@googlegroups.com.
    To view this discussion on the web visit

 https://groups.google.com/d/msgid/boinc_admin/55ADD1DD.7020809%40ssl.berkeley.edu.
    For more options, visit https://groups.google.com/d/optout
    https://groups.google.com/d/optout.

 --
 You received this message because you are subscribed to the Google 
 Groups boinc_admin group.
 To unsubscribe from this group and stop receiving emails from it, 
 send an email to boinc_admin+unsubscr...@googlegroups.com
 mailto:boinc_admin+unsubscr...@googlegroups.com.
 To post to this group, send email to boinc_ad...@googlegroups.com 
 mailto:boinc_ad...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/boinc_admin/CAKFuvzbSNhTMGc5y7Ft-G
 -5T2MXrw_A4g-ZS3%3DUAPoGZkA9HLA%40mail.gmail.com
 https://groups.google.com/d/msgid/boinc_admin/CAKFuvzbSNhTMGc5y7Ft-G-5T2MXrw_A4g-ZS3%3DUAPoGZkA9HLA%40mail.gmail.com?utm_medium=emailutm_source=footer.
 For more options, visit https://groups.google.com/d/optout.


 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev

 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email 

Re: [boinc_dev] [boinc_admin] make Github repo the master?

[Richard Haselgrove]

Does anyone know whether it's possible to display the Github web interface in 
most recent change first order? (so far, I've failed). For active developers, 
you know which area of code you'll be working in. But for users and amateur 
bughunters, the question is what areas of code have changed recently - have 
they fixed the problem I've reported, or where might the next glitch show up 
and need testing? 


 On Monday, 27 July 2015, 22:58, Rom Walton r...@romwnet.org wrote:
   
 

 Even better.

- Rom

-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: Monday, July 27, 2015 5:21 PM
To: Rom Walton r...@romwnet.org
Cc: boinc_ad...@googlegroups.com; BOINC Dev Mailing List 
boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

2015-07-27 18:17 GMT-03:00 Rom Walton r...@romwnet.org:
 The git (cli) commands to redirect origin to the github site are:
 git remote rm origin
 git remote add origin https://github.com/BOINC/boinc

 - Rom

git remote set-url origin https://github.com/BOINC/boinc

-- 
Nicolás
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 
  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Client: race condition on stderr.txt invalidates Milkyway tasks

[Richard Haselgrove]

I've finally managed to capture an orphaned stderr.txt file on disk, and marry 
it up with the 'Validate error' task report at Milkyway.
The copied file on my hard disk has the final few lines that were missing from 
the version reported to the project.
It'll be easiest to read the full report, with embedded screenshots, at 
http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3662postid=63799#63799 


 On Saturday, 11 July 2015, 22:44, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:
   
 

 Here's a double 'Error 32' with both slot debug and task debug active 
throughout.
This one resulted in a completely blank stderr.txt being reported to the 
project.Task is de_modfit_sum_fast_15_3s_136_sim1Jun1_4_1434554402_8900923_1, 
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=1184736496 


    On Saturday, 11 July 2015, 21:35, Jason Groothuis 
jason_grooth...@hotmail.com wrote:
  
 

 Trial correction, this part of boinc_api.cpp, line 778: // various platforms 
have problems shutting down a process    // while other threads are still 
executing,    // or triggering endless exit()/atexit() loops.    //    
BOINCINFO(Exit Status: %d, status);    fflush(NULL);
#if defined(_WIN32)    // Halt all the threads and clean up.    
TerminateProcess(GetCurrentProcess(), status);    // note: the above CAN 
return!    Sleep(1000);    DebugBreak();#elif defined(__APPLE_CC__)

Becomes // various platforms have problems shutting down a process    // while 
other threads are still executing,    // or triggering endless exit()/atexit() 
loops.    //    BOINCINFO(Exit Status: %d, status);    fflush(NULL);#if 
defined(_WIN32)    // JG: Buffered IO is not committed to disk on flush, so 
commit it, add other file descriptors if needed    _commit(stderr);    // Halt 
all the threads and clean up.    TerminateProcess(GetCurrentProcess(), status); 
   // note: the above CAN return!  [JG: It does, it's asychronous, system 
dependant this thread runs on some time so    
WaitForSingleObject(GetCurrentProcess(), INFINITE); // That's why you do this   
 Sleep(1000);  //JG: Will never be reached    DebugBreak();  //JG: Will never 
be reached#elif defined(__APPLE_CC__)


--
Jason Richard Groothuis 
bSc(compSci)

--


 From: jason_grooth...@hotmail.com
 To: r.haselgr...@btopenworld.com; da...@ssl.berkeley.edu; 
 boinc_dev@ssl.berkeley.edu
 Date: Sun, 12 Jul 2015 05:47:37 +0930
 Subject: Re: [boinc_dev] Client: race condition on stderr.txt invalidates 
 Milkyway tasks
 
 Comparing versions at leisure, but this same issue dates back in slight 
 variations to since I started crunching back in 2007, with different symptoms 
 depending on build characteristics and afflicted system ( OS version,  
 #cores, and GPU or CPU).  You be looking for a history on the boinc_exit() 
 function.  Don;t think it ever had the wait after terminateprocess, so IO 
 cancellations are likely depending on timing/chance.
 
 --
 Jason Richard Groothuis 
 bSc(compSci)
 
 --
 
 
 Date: Sat, 11 Jul 2015 20:07:56 +
 From: r.haselgr...@btopenworld.com
 To: jason_grooth...@hotmail.com; da...@ssl.berkeley.edu; 
 boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Client: race condition on stderr.txt invalidates 
 Milkyway tasks
 
 The Milkyway application we are mostly observing this with is 
 milkyway_separation__modified_fit_1.36_windows_x86_64__opencl_nvidia_101.exe, 
 which was deployed to their server on 6 Oct 2014, 20:18:34 UTC - the internal 
 signature says API_VERSION_6.13.0
 
  
 
 
      On Saturday, 11 July 2015, 20:55, Jason Groothuis 
jason_grooth...@hotmail.com wrote:
      
 
  Perhaps the exit process has been invoked in the Milkyway app, but not all 
consequent OS functions have completed in time.Correct, since the 
TermnateProcess() call, which is asynchronous and so returns immediately 
without necessarily doing anything,  is missing the WaitForSingleObject() on 
the Current process after it.  The process resources will cleanup as part of 
OS garbage collection *sometime* down the road.Doubting the accuracy of the 
MSDN documentation on these functions  is fine, but wondering why it doesn;t 
work as expected when you ignore it, is just odd.      On Saturday, 11 July 
2015, 20:09, Jason Groothuis jason_grooth...@hotmail.com wrote:      Not 
sure how much detail you'd like on the situation. (Can provide much more)  
It's a result of buffered IO implemented in multithreaded C Runtimes, in some 
situations using deferred procedure calls.  Internal helper threads are being 
killed before commits are completed.least desirable partial workaround

Re: [boinc_dev] Client: race condition on stderr.txt invalidates Milkyway tasks

[Richard Haselgrove]

Thanks Rom. I'm about to go out for the evening, and I've started a long (~17 
hour) GPUGrid task on that host. But I'll switch back to Milkyway with the new 
drop in the morning. The tasks run through quickly enough to get even a 
statistical view of the error rate very quickly - I was up to about 2% errors 
in the end. 


 On Tuesday, 14 July 2015, 19:02, Rom Walton r...@romwnet.org wrote:
   
 

 I've built a new version of 7.6 with David's latest change to address this 
issue.

http://boinc.berkeley.edu/dl/boinc_7.6.6_windows_intelx86.exe
http://boinc.berkeley.edu/dl/boinc_7.6.6_windows_x86_64.exe

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Tuesday, July 14, 2015 11:55 AM
To: Jason Groothuis jason_grooth...@hotmail.com; Dave A 
da...@ssl.berkeley.edu; BOINC Dev Mailing List boinc_dev@ssl.berkeley.edu; 
William Stilte william.sti...@gmail.com
Subject: Re: [boinc_dev] Client: race condition on stderr.txt invalidates 
Milkyway tasks

I've finally managed to capture an orphaned stderr.txt file on disk, and marry 
it up with the 'Validate error' task report at Milkyway.
The copied file on my hard disk has the final few lines that were missing from 
the version reported to the project.
It'll be easiest to read the full report, with embedded screenshots, at 
http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3662postid=63799#63799 


    On Saturday, 11 July 2015, 22:44, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:
  
 

 Here's a double 'Error 32' with both slot debug and task debug active 
throughout.
This one resulted in a completely blank stderr.txt being reported to the 
project.Task is de_modfit_sum_fast_15_3s_136_sim1Jun1_4_1434554402_8900923_1, 
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=1184736496 


    On Saturday, 11 July 2015, 21:35, Jason Groothuis 
jason_grooth...@hotmail.com wrote:
  
 

 Trial correction, this part of boinc_api.cpp, line 778: // various platforms 
have problems shutting down a process    // while other threads are still 
executing,    // or triggering endless exit()/atexit() loops.    //    
BOINCINFO(Exit Status: %d, status);    fflush(NULL); #if defined(_WIN32)    
// Halt all the threads and clean up.    TerminateProcess(GetCurrentProcess(), 
status);    // note: the above CAN return!    Sleep(1000);    
DebugBreak();#elif defined(__APPLE_CC__)

Becomes // various platforms have problems shutting down a process    // while 
other threads are still executing,    // or triggering endless exit()/atexit() 
loops.    //    BOINCINFO(Exit Status: %d, status);    fflush(NULL);#if 
defined(_WIN32)    // JG: Buffered IO is not committed to disk on flush, so 
commit it, add other file descriptors if needed    _commit(stderr);    // Halt 
all the threads and clean up.    TerminateProcess(GetCurrentProcess(), status); 
   // note: the above CAN return!  [JG: It does, it's asychronous, system 
dependant this thread runs on some time so    
WaitForSingleObject(GetCurrentProcess(), INFINITE); // That's why you do this   
 Sleep(1000);  //JG: Will never be reached    DebugBreak();  //JG: Will never 
be reached#elif defined(__APPLE_CC__)


--
Jason Richard Groothuis
bSc(compSci)

--


 From: jason_grooth...@hotmail.com
 To: r.haselgr...@btopenworld.com; da...@ssl.berkeley.edu; 
 boinc_dev@ssl.berkeley.edu
 Date: Sun, 12 Jul 2015 05:47:37 +0930
 Subject: Re: [boinc_dev] Client: race condition on stderr.txt 
 invalidates Milkyway tasks
 
 Comparing versions at leisure, but this same issue dates back in slight 
 variations to since I started crunching back in 2007, with different symptoms 
 depending on build characteristics and afflicted system ( OS version,  
 #cores, and GPU or CPU).  You be looking for a history on the boinc_exit() 
 function.  Don;t think it ever had the wait after terminateprocess, so IO 
 cancellations are likely depending on timing/chance.
 
 --
 
 Jason Richard Groothuis
 bSc(compSci)
 
 --
 
 
 
 Date: Sat, 11 Jul 2015 20:07:56 +
 From: r.haselgr...@btopenworld.com
 To: jason_grooth...@hotmail.com; da...@ssl.berkeley.edu; 
 boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Client: race condition on stderr.txt 
 invalidates Milkyway tasks
 
 The Milkyway application we are mostly observing this with is 
 milkyway_separation__modified_fit_1.36_windows_x86_64__opencl_nvidia_101.exe, 
 which was deployed to their server on 6 Oct 2014, 20:18:34 UTC - the internal 
 signature says API_VERSION_6.13.0
 
  
 
 
      On Saturday, 11 July 2015, 20:55

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Richard Haselgrove]

OK, here's the first GPUGrid - GPUGrid handover with the 100615 private drop. 
Slightly different task type from before, but same observed behaviour - Tasks 
pane in BOINC manager stops updating for several seconds. I didn't time it 
exactly, but subjectively it felt like the gap
11/06/2015 18:20:14 | GPUGRID | [slot] assigning slot 7 to 
e2s204_e1s360f20-NOELIA_ETQunboundx1-1-2-RND7857_0
...
11/06/2015 18:20:27 |  | [slot] removed file slots/7/init_data.xml
 Again subjectively, I'd say that the delay happened when cleaning up the 
previous task, rather than when starting the new one: the progress% column 
hadn't even updated to the full 100% before it froze.
Slot debug log in attached text file.


 On Wednesday, 10 June 2015, 18:16, Rom Walton r...@romwnet.org wrote:
   
 

 Here is a private drop:
http://boinc.berkeley.edu/dl/boinc.100615.x64.zip

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Wednesday, June 10, 2015 3:34 AM
To: David Anderson; Jacob Klein; Seke Rob
Cc: BOINC Development
Subject: Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without 
ensuring they're empty

Rom, if you could build a private drop, I'll report what the log says. 


    On Wednesday, 10 June 2015, 4:28, David Anderson da...@ssl.berkeley.edu 
wrote:
  
 

  I added a log message that may help a bit.
 I'd like to track this down, even though it's minor.
 -- David
 
 On 19-May-2015 12:15 PM, Richard Haselgrove wrote:
  
  OK, the delay happened again, and I captured a procmon log. 
  Copy of the BOINC log attached (period of interest is 19:35:30 to 19:35:41): 
also a simple extract of ProcMon for the same period. It has to be said, 
boinc.exe was doing surprisingly little. 
  I have kept the full ~200 MB native ProcMon log, which can be re-filtered to 
look for anything else of interest, if you can suggest some likely targets. 
 
 
      On Monday, 18 May 2015, 20:57, David Anderson da...@ssl.berkeley.edu 
wrote:
  
 
 
 That looks like what's needed.
 Richard, if you can repro the inter-job delay,  you could try using Process 
Monitor to capture as much  as possible from the client during that period.
 -- David
 
 On 18-May-2015 11:12 AM, Jacob Klein wrote:
  Process Monitor can be used to watch the things a process does (you have 
  to set   up correct filters, etc.)... but I'm not sure if that includes 
  sleeps. But if the   process is waiting on a file or something, though, it 
  should be able to tell you. 
  Worth looking into.
 
  https://technet.microsoft.com/en-us/library/bb896645.aspx
 
  Regards,
  Jacob
 
 
 
  Date: Mon, 18 May 2015 10:41:16 -0700   From: da...@ssl.berkeley.edu   To: 
  r.haselgr...@btopenworld.com; onec...@hotmail.com; jacob_w_kl...@msn.com   
  CC: boinc_dev@ssl.berkeley.edu   Subject: Re: [boinc_dev] [boinc_alpha] 
  BOINC re-using slot directories without   ensuring they're empty     I 
  looked at this and couldn't figure out the source of the 12-sec delay.
  In general, delays could happen because   1) the client does something that 
  takes a long time (like copying a 5 GB file)   2) the client sleeps (i.e. 
  calls boinc_sleep()).
     It does this in a few situations,
     like backing off and retrying a file system operation.
  But there's no indication that either of these is happening here.
 
  Does Windows have a way of logging the system calls that a process makes   
  (like strace on Unix)?
  If so that might reveal what the client is doing during those 12 seconds.
 
  -- David
 
  On 16-May-2015 8:01 AM, Richard Haselgrove wrote:
 
     Here is the message log file for a GPUGrid task finish. The 12-second 
 delay      appears again between 14:26:35 and 14:26:47 - that's after the 
 slot directory      has been cleared, and the exiting task has changed state 
 from 'running' to      'uploading'. Two new tasks have been assigned to the 
 GPU, but their (small)      startup files have not yet been linked to their 
 respective slot directories.
 
     I also attach directory listings for the slot and GPUGrid project folders 
 at      various stages of the cleanup: the slot held 34 files totalling 
 44,186,727      bytes, which doesn't sound excessive: the largest file 
 deletion (94,783,960      bytes) occurred several minutes later, when that 
 file finished uploading.
 
     I'll enable similar logging and watch what happens when the next GPUGrid 
 task      starts up, but from memory, the disruption to BOINC is less severe 
 at startup.
 
 
 
     On Tuesday, 12 May 2015, 23:29, David Anderson da...@ssl.berkeley.edu  
     mailto:da...@ssl.berkeley.edu wrote:
 
 
 
         BTW: the client isn't completely single-threaded;          it uses a 
 separate thread to do CPU throttling.
         It would be feasible to also use separate threads          for 
 serving GUI RPC connections

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Richard Haselgrove]

Rom, if you could build a private drop, I'll report what the log says. 


 On Wednesday, 10 June 2015, 4:28, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 

  I added a log message that may help a bit.
 I'd like to track this down, even though it's minor.
 -- David
 
 On 19-May-2015 12:15 PM, Richard Haselgrove wrote:
  
  OK, the delay happened again, and I captured a procmon log. 
  Copy of the BOINC log attached (period of interest is 19:35:30 to 19:35:41): 
also a simple extract of ProcMon for the same period. It has to be said, 
boinc.exe was doing surprisingly little. 
  I have kept the full ~200 MB native ProcMon log, which can be re-filtered to 
look for anything else of interest, if you can suggest some likely targets. 
 
 
   On Monday, 18 May 2015, 20:57, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 
 
 That looks like what's needed.
 Richard, if you can repro the inter-job delay,
 you could try using Process Monitor to capture as much
 as possible from the client during that period.
 -- David
 
 On 18-May-2015 11:12 AM, Jacob Klein wrote:
  Process Monitor can be used to watch the things a process does (you have 
  to set 
  up correct filters, etc.)... but I'm not sure if that includes sleeps. But 
  if the 
  process is waiting on a file or something, though, it should be able to tell 
  you. 
  Worth looking into.
 
  https://technet.microsoft.com/en-us/library/bb896645.aspx
 
  Regards,
  Jacob
 
 
 
  Date: Mon, 18 May 2015 10:41:16 -0700
  From: da...@ssl.berkeley.edu
  To: r.haselgr...@btopenworld.com; onec...@hotmail.com; jacob_w_kl...@msn.com
  CC: boinc_dev@ssl.berkeley.edu
  Subject: Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories 
  without 
  ensuring they're empty
 
  I looked at this and couldn't figure out the source of the 12-sec delay.
  In general, delays could happen because
  1) the client does something that takes a long time (like copying a 5 GB 
  file)
  2) the client sleeps (i.e. calls boinc_sleep()).
     It does this in a few situations,
     like backing off and retrying a file system operation.
  But there's no indication that either of these is happening here.
 
  Does Windows have a way of logging the system calls that a process makes
  (like strace on Unix)?
  If so that might reveal what the client is doing during those 12 seconds.
 
  -- David
 
  On 16-May-2015 8:01 AM, Richard Haselgrove wrote:
 
     Here is the message log file for a GPUGrid task finish. The 12-second 
 delay
     appears again between 14:26:35 and 14:26:47 - that's after the slot 
 directory
     has been cleared, and the exiting task has changed state from 'running' to
     'uploading'. Two new tasks have been assigned to the GPU, but their 
 (small)
     startup files have not yet been linked to their respective slot 
 directories.
 
     I also attach directory listings for the slot and GPUGrid project folders 
 at
     various stages of the cleanup: the slot held 34 files totalling 44,186,727
     bytes, which doesn't sound excessive: the largest file deletion 
 (94,783,960
     bytes) occurred several minutes later, when that file finished uploading.
 
     I'll enable similar logging and watch what happens when the next GPUGrid 
 task
     starts up, but from memory, the disruption to BOINC is less severe at 
 startup.
 
 
 
     On Tuesday, 12 May 2015, 23:29, David Anderson da...@ssl.berkeley.edu
     mailto:da...@ssl.berkeley.edu wrote:
 
 
 
         BTW: the client isn't completely single-threaded;
         it uses a separate thread to do CPU throttling.
         It would be feasible to also use separate threads
         for serving GUI RPC connections,
         which would allow client to remain responsive even while
         e.g. copying thousands of files to a slot dir.
         -- David
 
         On 12-May-2015 2:40 AM, Seke Rob wrote:
          Reminds me of the Clean Energy Project, Phase 2 and why we have
         app_config and
          max_concurrent and a default control of allowing 1 'In Progress' 
 on a
         host. This
          project sets up in slot copying near 6700 files [symlinking proposed
         long ago as
          is done on several other WCG projects for the static files]. If more
         than one CEP2
          is started the machine feels at times like a snail, responsiveness 
 of
         the BOINC
          manager is poor, many a time the less powerful systems incurring 
 error
         zero status
          exits or total fail. On an 8 core observed it could take over an 
 hour
         before
          actual computing commenced [CPU time logged]. Boot cycle requires 
 manually
          starting of tasks one by one. Kevin Reed few years ago raised a 
 ticket for
          staggered starting, where the models can reach several GB and 
 bigger in the
          coming. At any rate, as much as these 6700 files are copied

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Richard Haselgrove]

I'll give that a try. The job delay seems reproducible - I was expecting it 
from previous experience, which was why I set up logging in the first place. 
Two problems: with these big 11-hour to 17-hour jobs, they don't always finish 
at convenient times - the next one is due around 2 in the morning. And I'm not 
experienced enough with the process tools to be sure of getting the right 
filter at the first attempt. If any lurkers on this thread have any suggestions 
on what capture to enable, that would help - my personal suspicion is that we 
may have to watch the CUDA/driver runtime processes too, but maybe we'll try 
that later.
(I don't personally suspect DNS/libcurl, because it doesn't happen with jobs 
from all projects) 


 On Monday, 18 May 2015, 20:57, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 

  That looks like what's needed.
 Richard, if you can repro the inter-job delay,
 you could try using Process Monitor to capture as much
 as possible from the client during that period.
 -- David
 
 On 18-May-2015 11:12 AM, Jacob Klein wrote:
  
 #yiv7469427494 #yiv7469427494 --.yiv7469427494hmmessage 
P{margin:0px;padding:0px;}#yiv7469427494 
body.yiv7469427494hmmessage{font-size:12pt;font-family:Calibri;}#yiv7469427494  
Process Monitor can be used to watch the things a process does (you have to 
set up correct filters, etc.)... but I'm not sure if that includes sleeps. But 
if the process is waiting on a file or something, though, it should be able to 
tell you. Worth looking into.
 
 https://technet.microsoft.com/en-us/library/bb896645.aspx
 
 Regards,
 Jacob
 
 
  Date: Mon, 18 May 2015 10:41:16 -0700
 From: da...@ssl.berkeley.edu
 To: r.haselgr...@btopenworld.com; onec...@hotmail.com; jacob_w_kl...@msn.com
 CC: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without 
ensuring they're empty
 
 I looked at this and couldn't figure out the source of the 12-sec delay.
 In general, delays could happen because
 1) the client does something that takes a long time (like copying a 5 GB file)
 2) the client sleeps (i.e. calls boinc_sleep()).
    It does this in a few situations,
    like backing off and retrying a file system operation.
 But there's no indication that either of these is happening here.
 
 Does Windows have a way of logging the system calls that a process makes
 (like strace on Unix)?
 If so that might reveal what the client is doing during those 12 seconds.
 
 -- David
 
 On 16-May-2015 8:01 AM, Richard Haselgrove wrote:
  
  Here is the message log file for a GPUGrid task finish. The 12-second delay 
appears again between 14:26:35 and 14:26:47 - that's after the slot directory 
has been cleared, and the exiting task has changed state from 'running' to 
'uploading'. Two new tasks have been assigned to the GPU, but their (small) 
startup files have not yet been linked to their respective slot directories. 
  I also attach directory listings for the slot and GPUGrid project folders at 
various stages of the cleanup: the slot held 34 files totalling 44,186,727 
bytes, which doesn't sound excessive: the largest file deletion (94,783,960 
bytes) occurred several minutes later, when that file finished uploading. 
  I'll enable similar logging and watch what happens when the next GPUGrid task 
starts up, but from memory, the disruption to BOINC is less severe at startup.  
 
 
   On Tuesday, 12 May 2015, 23:29, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 
 
 BTW: the client isn't completely single-threaded;
 it uses a separate thread to do CPU throttling.
 It would be feasible to also use separate threads
 for serving GUI RPC connections,
 which would allow client to remain responsive even while
 e.g. copying thousands of files to a slot dir.
 -- David
 
 On 12-May-2015 2:40 AM, Seke Rob wrote:
  Reminds me of the Clean Energy Project, Phase 2 and why we have app_config 
  and 
  max_concurrent and a default control of allowing 1 'In Progress' on a 
  host. This 
  project sets up in slot copying near 6700 files [symlinking proposed long 
  ago as 
  is done on several other WCG projects for the static files]. If more than 
  one CEP2 
  is started the machine feels at times like a snail, responsiveness of the 
  BOINC 
  manager is poor, many a time the less powerful systems incurring error zero 
  status 
  exits or total fail. On an 8 core observed it could take over an hour before 
  actual computing commenced [CPU time logged]. Boot cycle requires manually 
  starting of tasks one by one. Kevin Reed few years ago raised a ticket for 
  staggered starting, where the models can reach several GB and bigger in the 
  coming. At any rate, as much as these 6700 files are copied, they also then 
  are 
  needing of deletion at completion [physical or symlink references]. The 
  effect of 
  starting 1 CEP2 and finishing / packaging / zipping and transmitting can 
  easily 
  lead to several minutes of there not being any

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Richard Haselgrove]

I missed the exact moment the next GPUGrid task started, but this log reveals 
no undue delay.
16/05/2015 21:02:08 | SETI@home | Computation for task 
07ja12ab.4384.12351.438086664202.12.213_0 finished
16/05/2015 21:02:08 | GPUGRID | [async] started async copy of 
projects/www.gpugrid.net/cufft32_65.dll
16/05/2015 21:02:08 | GPUGRID | Starting task 
e15s10_e4s3f73-GERARD_FXCXCL12_LIG_15359942-0-1-RND9760_0
16/05/2015 21:02:08 | GPUGRID | [cpu_sched] Starting task 
e15s10_e4s3f73-GERARD_FXCXCL12_LIG_15359942-0-1-RND9760_0 using acemdlong 
version 847 (cuda65) in slot 6
16/05/2015 21:02:08 | GPUGRID | [async] async copy of slots/6/cufft32_65.dll 
finished
16/05/2015 21:02:10 | SETI@home | Started upload of 
07ja12ab.4384.12351.438086664202.12.213_0_0
16/05/2015 21:02:13 | SETI@home | Finished upload of 
07ja12ab.4384.12351.438086664202.12.213_0_0
 



 On Saturday, 16 May 2015, 16:08, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:
   
 

 Forget to attach attachments...  


    On Saturday, 16 May 2015, 16:01, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:
  
 

 Here is the message log file for a GPUGrid task finish. The 12-second delay 
appears again between 14:26:35 and 14:26:47 - that's after the slot directory 
has been cleared, and the exiting task has changed state from 'running' to 
'uploading'. Two new tasks have been assigned to the GPU, but their (small) 
startup files have not yet been linked to their respective slot directories.
I also attach directory listings for the slot and GPUGrid project folders at 
various stages of the cleanup: the slot held 34 files totalling 44,186,727 
bytes, which doesn't sound excessive: the largest file deletion (94,783,960 
bytes) occurred several minutes later, when that file finished uploading.
I'll enable similar logging and watch what happens when the next GPUGrid task 
starts up, but from memory, the disruption to BOINC is less severe at startup. 


    On Tuesday, 12 May 2015, 23:29, David Anderson da...@ssl.berkeley.edu 
wrote:
  
 

 BTW: the client isn't completely single-threaded;
it uses a separate thread to do CPU throttling.
It would be feasible to also use separate threads
for serving GUI RPC connections,
which would allow client to remain responsive even while
e.g. copying thousands of files to a slot dir.
-- David

On 12-May-2015 2:40 AM, Seke Rob wrote:
 Reminds me of the Clean Energy Project, Phase 2 and why we have app_config 
 and 
 max_concurrent and a default control of allowing 1 'In Progress' on a host. 
 This 
 project sets up in slot copying near 6700 files [symlinking proposed long ago 
 as 
 is done on several other WCG projects for the static files]. If more than one 
 CEP2 
 is started the machine feels at times like a snail, responsiveness of the 
 BOINC 
 manager is poor, many a time the less powerful systems incurring error zero 
 status 
 exits or total fail. On an 8 core observed it could take over an hour before 
 actual computing commenced [CPU time logged]. Boot cycle requires manually 
 starting of tasks one by one. Kevin Reed few years ago raised a ticket for 
 staggered starting, where the models can reach several GB and bigger in the 
 coming. At any rate, as much as these 6700 files are copied, they also then 
 are 
 needing of deletion at completion [physical or symlink references]. The 
 effect of 
 starting 1 CEP2 and finishing / packaging / zipping and transmitting can 
 easily 
 lead to several minutes of there not being any computing, just whirring, for 
 minutes, just elapsed being logged. The more run the more the issue 
 compounds, 
 with the effect of what many incur, the exit zero status series, resetting to 
 start or last checkpoint with often hours of computing time lost.

 Maybe you'd like to get in touch with your confederates at WCG [Keith 
 Uplinger], 
 to discuss the issue further as this is now nearing a 5 year continues 
 frustration 
 [June 2010 launch, and a huge limitation on the speed of progress on this 
 project].

 --SekeRob.

 On 12-5-2015 1:55, David Anderson wrote:
 That delay looks like it's caused by deleting files or by process cleanup.
 Does GPUGrid make lots of (non-output) files in the slot dir?

 Please try to repro it with slot_debug, task_debug, and heartbeat_debug set
 (gui_rpc_debug not needed).

 -- David

 On 11-May-2015 10:54 AM, Richard Haselgrove wrote:
 Here's another example of a case where BOINC finds that it can't walk and 
 chew 
 gum at the same time. The event of interest is

 11/05/2015 18:35:34 | GPUGRID | Computation for task 
 e10s9_e7s6f4-GERARD_FXCXCL12_LIG_6282622-0-1-RND7898_0 finished

 Following that, there's a 12-second interval where neither heartbeats nor 
 GUI 
 RPC traffic was logged: during that time, the Task tab of the Manager was 
 unchanging, not showing the regular update of elapsed time for running 
 tasks.

 async_file_debug was active at the time, but found no events to log.

 These particular GPUGrid tasks generate around

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Richard Haselgrove]

Forget to attach attachments...  


 On Saturday, 16 May 2015, 16:01, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:
   
 

 Here is the message log file for a GPUGrid task finish. The 12-second delay 
appears again between 14:26:35 and 14:26:47 - that's after the slot directory 
has been cleared, and the exiting task has changed state from 'running' to 
'uploading'. Two new tasks have been assigned to the GPU, but their (small) 
startup files have not yet been linked to their respective slot directories.
I also attach directory listings for the slot and GPUGrid project folders at 
various stages of the cleanup: the slot held 34 files totalling 44,186,727 
bytes, which doesn't sound excessive: the largest file deletion (94,783,960 
bytes) occurred several minutes later, when that file finished uploading.
I'll enable similar logging and watch what happens when the next GPUGrid task 
starts up, but from memory, the disruption to BOINC is less severe at startup. 


 On Tuesday, 12 May 2015, 23:29, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 

 BTW: the client isn't completely single-threaded;
it uses a separate thread to do CPU throttling.
It would be feasible to also use separate threads
for serving GUI RPC connections,
which would allow client to remain responsive even while
e.g. copying thousands of files to a slot dir.
-- David

On 12-May-2015 2:40 AM, Seke Rob wrote:
 Reminds me of the Clean Energy Project, Phase 2 and why we have app_config 
 and 
 max_concurrent and a default control of allowing 1 'In Progress' on a host. 
 This 
 project sets up in slot copying near 6700 files [symlinking proposed long ago 
 as 
 is done on several other WCG projects for the static files]. If more than one 
 CEP2 
 is started the machine feels at times like a snail, responsiveness of the 
 BOINC 
 manager is poor, many a time the less powerful systems incurring error zero 
 status 
 exits or total fail. On an 8 core observed it could take over an hour before 
 actual computing commenced [CPU time logged]. Boot cycle requires manually 
 starting of tasks one by one. Kevin Reed few years ago raised a ticket for 
 staggered starting, where the models can reach several GB and bigger in the 
 coming. At any rate, as much as these 6700 files are copied, they also then 
 are 
 needing of deletion at completion [physical or symlink references]. The 
 effect of 
 starting 1 CEP2 and finishing / packaging / zipping and transmitting can 
 easily 
 lead to several minutes of there not being any computing, just whirring, for 
 minutes, just elapsed being logged. The more run the more the issue 
 compounds, 
 with the effect of what many incur, the exit zero status series, resetting to 
 start or last checkpoint with often hours of computing time lost.

 Maybe you'd like to get in touch with your confederates at WCG [Keith 
 Uplinger], 
 to discuss the issue further as this is now nearing a 5 year continues 
 frustration 
 [June 2010 launch, and a huge limitation on the speed of progress on this 
 project].

 --SekeRob.

 On 12-5-2015 1:55, David Anderson wrote:
 That delay looks like it's caused by deleting files or by process cleanup.
 Does GPUGrid make lots of (non-output) files in the slot dir?

 Please try to repro it with slot_debug, task_debug, and heartbeat_debug set
 (gui_rpc_debug not needed).

 -- David

 On 11-May-2015 10:54 AM, Richard Haselgrove wrote:
 Here's another example of a case where BOINC finds that it can't walk and 
 chew 
 gum at the same time. The event of interest is

 11/05/2015 18:35:34 | GPUGRID | Computation for task 
 e10s9_e7s6f4-GERARD_FXCXCL12_LIG_6282622-0-1-RND7898_0 finished

 Following that, there's a 12-second interval where neither heartbeats nor 
 GUI 
 RPC traffic was logged: during that time, the Task tab of the Manager was 
 unchanging, not showing the regular update of elapsed time for running 
 tasks.

 async_file_debug was active at the time, but found no events to log.

 These particular GPUGrid tasks generate around 90 MB of upload files, but I 
 think they are generated directly in the project folder and don't need to 
 be 
 copied anywhere.

 Main log as attached file only.

 I'll catch a CMS-dev log later this evening, but after that, I'll be away 
 for a 
 few days and I'll have to leave the bug-chase until the weekend.




 On Monday, 11 May 2015, 9:42, Jacob Klein jacob_w_kl...@msn.com wrote:



    I have seen this problem before, where the UI becomes unresponsive. If I
    recall, it happens when a T4T task is being set up (ie: after everything 
was
    downloaded). For me, I don't recall the problem ever screwing over other
    tasks, though.

    Try this to reproduce it: Attach to T4T, and get a task. It may take a 
while
    to do that download, so you can step away for a bit. Then, once that 
task
    is going, abort it. Downloading the 2nd task should be instantaneous
    (nothing really to download), but instantiation of that 2nd task should

[boinc_dev] Client: Event Log enhancement

[Richard Haselgrove]

For Windows only. It's been a long time since the use of GPUs was disabled when 
running BOINC as a service, but people keep getting caught out - most recently 
in http://setiathome.berkeley.edu/forum_thread.php?id=76849

Either, people upgrading earlier versions of BOINC don't notice the inherited 
selection in the installer, or (as this time) people install new hardware in a 
computer already running BOINC.

Could the mode line in the event log be enhanced to read something like

Running as a daemon (GPUs not available)

Running as a daemon (GPU computing disabled)


under Windows, please? The phrase No usable GPUs found does occur a few lines 
later in the log, but there's nothing to associate the one as the cause of the 
other. The restriction is mentioned in the installer and in 
http://boinc.berkeley.edu/wiki/GPU_computing, but both of those are likely to 
be far distant in time and space in the user's mind when they discover the 
problem.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Web documentation and HTTPS

[Richard Haselgrove]

The https request seems to work consistently and reliably when I'm logged in 
for wiki editing, but loses the stylesheet info if I'm visiting anonymously. 
Don't know if that's a clue or not.




 From: David Anderson da...@ssl.berkeley.edu
To: boinc_dev@ssl.berkeley.edu 
Sent: Thursday, 5 March 2015, 20:58
Subject: Re: [boinc_dev] Web documentation and HTTPS
 

The different seems to be how Mediawiki is including its own stylesheet.
On the one that works, it uses HTTPS:
link rel=stylesheet href=https://boinc.berkeley.edu/w/load.php? ...

On the one that doesn't, it uses HTTP, and the browser ignores it.

I can't figure out why it does this.

-- David

On 05-Mar-2015 12:28 PM, Richard Haselgrove wrote:
 Some pages of the user manual - most notably the front page - don't display
 properly when requested over a secure connection.

 https://boinc.berkeley.edu/wiki/Anonymous_platform


 loads correctly, but

 https://boinc.berkeley.edu/wiki/User_manual

 https://boinc.berkeley.edu/wiki/Client_configuration


 say This page is trying to load scripts from unauthenticated sources 
 (Google
 Chrome) or Only secure content is displayed (Internet Explorer 11).

 Both browsers do allow the user to display the proper formatting by clicking
 'Load unsafe scripts' or 'Show all content' respectively, but that isn't 
 really
 encouraging best practice. ___
 boinc_dev mailing list boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, 
 visit
 the above URL and (near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] web: make code and pre BBCode text word-wrap

[Richard Haselgrove]

From my private message archive at SETI@Home, it appears that we had a first 
attempt at solving the private message layout problem in a three-way 
conversation involving myself, David Anderson, and Mark Sattler on and around 
14 February 2011: David and I on boinc_alpha, Mark and I by PM. We found a 
workable compromise, which survived until about 27 August 2011, when some more 
code changes submitted by Christian Beer - to do with the translation 
framework - broke the February fix. And there, I think, exhaustion set in and 
we collectively agreed it isn't all that important after all.




 From: Jord van der Elst els...@gmail.com
To: Juha juha.sointus...@gmail.com 
Cc: BOINC Developers Mailing List boinc_dev@ssl.berkeley.edu 
Sent: Wednesday, February 11, 2015 9:54 PM
Subject: Re: [boinc_dev] web: make code and pre BBCode text word-wrap
 

Sorry, I only posted this to David yesterday.
the problem only happens in Private Messages.
E.g. this post at Seti
https://setiathome.berkeley.edu/forum_thread.php?id=76697postid=1639743
has a start log that scrolls separately from the rest of the text in
the thread, and does so both on my phone and my PC.

So we'll probably have to figure out why it won't do that then in
private messages.
Some different CSS used there?

-- Jord van der Elst.


On Wed, Feb 11, 2015 at 9:03 PM, Juha juha.sointus...@gmail.com wrote:
 On 11 February 2015 at 00:24, Jord van der Elst els...@gmail.com wrote:

 All my text
 now scrolls way off to the side on there. ALL of the text now no
 longer wraps.

 Here an example of how my PM folder looks from my phone:
 http://img.photobucket.com/albums/v289/Ageless/mobile_pm_folder_boinc.png
 Highly annoying, totally unusable now.

 So please, make a change so the pre and code containers can be
 scrolled, but the rest of the text wraps.


 Did the forums work on your phone?

 I tested a bunch of stuff and this is what I came up with:

 forum thread view works ok
 forum post and pm preview works ok
 uotd on the front page and user search page works ok

 front page news not ok
 forums post search not ok
 user post list not ok
 pm list not ok
 profile not ok
 team description on both team page and search results not ok

 If I missed anything let me know so I can test them too.

 I think all the post or message like content should use the same styling.
 Maybe it would be as easy as making a CSS class and using that everywhere.

 -Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] set app priority

[Richard Haselgrove]

Maybe we're simply using the wrong discriminant to choose which priority to set.

You note that some GPU apps perform poorly at idle priority.

But at present we're determining their GPU-ness, not directly, but indirectly 
by their fractional CPU assignment.

There are other GPU apps, apart from the POEM example, where a full 1.00 CPU 
assignment makes a significant difference in processing time - the 
Einstein@Home OpenCL application for imtel_gpu is a case in point.

Would it not be possible to determine the required priority directly from the 
'use GPU' definition instead, and ignore the CPU fraction?




 From: David Anderson da...@ssl.berkeley.edu
To: Jacob Klein jacob_w_kl...@msn.com 
Cc: BOINC Development boinc_dev@ssl.berkeley.edu 
Sent: Thursday, January 29, 2015 8:42 PM
Subject: Re: [boinc_dev] set app priority
 

Jacob:
BOINC runs CPU jobs at idle priority to avoid impacting
the performance of non-BOINC programs.
The rationale for running jobs that use  1 CPU at higher priority is that
- because they use little CPU time, running them at higher priority
   won't have much impact on other programs
- some apps (like QCN, and GPU apps) perform poorly if run at idle priority

We could change the policy to run coprocessor apps at higher priority,
regardless of how much CPU they use.
But that would impact system performance in some cases.
I'd hesitate to make this the default.
Maybe it could be a cc_config.xml option.

-- David

On 26-Jan-2015 2:23 PM, Jacob Klein wrote:
 Hi David,

 I've been running POEM@Home GPU tasks, with an app_config.xml file, with 
 cpu_usage
 set to 1.000, since each of their GPU tasks uses a full core, and I want to
 appropriately budget resources on my system.

 However, when I do that, the task's process runs at Idle priority, instead 
 of Below
 Normal.

 Martin (a dev at Poem@Home) is researching the issue, here:
 http://boinc.fzk.de/poem/forum_thread.php?id=1105postid=10200
 And I replied here:
 http://boinc.fzk.de/poem/forum_thread.php?id=1105postid=10201

 ... but I think it's being caused by your changes below.
 Is your logic below, possibly incorrect? I mean, to my knowledge, there are 
 some GPU
 apps (especially OpenCL) which require a full CPU core, and we'd still want 
 their
 priorities to be kept at Below Normal, to keep the GPU fed with kernels, as a
 priority over other CPU jobs. I could even imagine non-GPU coprocessor jobs 
 that
 would also require a full CPU core.

 Thoughts?

 Thanks,
 Jacob Klein




   Date: Thu, 9 Oct 2014 14:49:49 -0700
   From: da...@ssl.berkeley.edu
   To: jacob_w_kl...@msn.com; boinc_dev@ssl.berkeley.edu
   Subject: Re: [boinc_dev] set app priority
  
   Currently, when the client runs an app:
  
   - if the app version uses  1 CPU or has the is_wrapper flag set,
   set the priority to BELOW_NORMAL_PRIORITY_CLASS
   - otherwise set the priority to IDLE_PRIORITY_CLASS
  
   So GPU apps (if they use  1 CPU), non-CPU-intensive apps, and wrappers
   are run at Below Normal.
  
   When the BOINC wrapper runs an app:
  
   - if no_priority_change/ is set in the job description file,
   the process inherits the priority of the wrapper
   (normally BELOW_NORMAL_PRIORITY_CLASS)
   - otherwise set the priority to IDLE_PRIORITY_CLASS
  
   There's no provision for anything other than Idle and Below Normal.
  
   (The above is Windows, of course; it's analogous on Unix).
  
   -- David
  
   On 09-Oct-2014 1:26 PM, Jacob Klein wrote:
    Does this support running the task's process at a priority that is 
neither Normal
    (8) nor Idle (4)?
    GPU apps, for instance, are best run at Below Normal (6) (which GPUGrid 
somehow
    does)... and I feel that ASIC apps also should run at Below Normal (6).
   
   
   
 Date: Thu, 9 Oct 2014 12:38:16 -0700
 From: da...@ssl.berkeley.edu
 To: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] set app priority
    
 To address this problem, I added a no_priority_change/ option
 in the wrapper's job description file:
 http://boinc.berkeley.edu/trac/wiki/WrapperApp
    
 This tells the wrapper to not lower the priority of the tasks' 
process.
    
 -- David
    
 On 09-Oct-2014 1:45 AM, Rebirther wrote:
  The is_wrapper/ option doesnt work for me, the wrapper is still 
in normal
  priority as before and the app in lowest priority running BOINC 
client 7.4.22
 
  -Reb ___ boinc_dev 
mailing list
  boinc_dev@ssl.berkeley.edu
  http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To 
unsubscribe, visit
  the above URL and (near bottom of page) enter your email address.
 
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.

[boinc_dev] User web: feature request: subscribed threads

[Richard Haselgrove]

The BOINC message board system allows users to 'subscribe' to a thread - to 
receive automatic notification of new posts in threads of interest. It appears 
that the subscription notification is triggered only by a direct post into a 
thread, and is not triggered by a moderator moving an existing post into the 
thread. Could both 'post' and 'move' be made into equivalent event triggers, 
please?

I maintain two threads at SETI@Home

http://setiathome.berkeley.edu/forum_thread.php?id=71867

http://setiathome.berkeley.edu/forum_thread.php?id=74238


which by agreement with the moderators are kept 'locked and sticky' as pure 
information sources - discussion takes place in general threads. It is easier 
for both me and the moderation team if we perform updates asynchronously - I 
post in an 'open' thread, and moderators move the post into a 'locked' thread 
when convenient. But I have received a complaint that this procedure fails to 
trigger the subscription feature - although the thread does display the 'yellow 
pages' unread post notification.

The alternative synchronous procedure - I request the moderators to unlock, 
they tell me when they've done it, I make the new post, the moderator locks the 
thread again - is clumsier for all of us, but does generate a notification to 
subscribed readers.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] OpenCL apps orphaned on BOINC client crash/kill

[Richard Haselgrove]

Today's commit f0c39bdf5117d8f7dd5092033971d7f700bd22dc




 From: Raistmer the Sorcerer raist...@mail.ru
To: David Anderson da...@ssl.berkeley.edu 
Cc: boinc_dev@ssl.berkeley.edu; Boinc Projects 
boinc_proje...@ssl.berkeley.edu 
Sent: Friday, October 31, 2014 10:22 PM
Subject: Re: [boinc_dev] OpenCL apps orphaned on BOINC client crash/kill
 

Thanks. I added additional check for that flag but orphaned state remained. 
Could you specify in what BOINC API version that bug was fixed, please ?


Fri, 31 Oct 2014 11:24:26 -0700 от David Anderson da...@ssl.berkeley.edu:
There was a bug in the API that caused apps that use critical sections
(like most GPU apps)
to sometimes not exit when the client exits or crashes.
I checked in a fix.

BTW, for apps that handle status events themselves,
the flag indicating the client has died is status.no_heartbeat.

-- David

On 26-Oct-2014 11:30 AM, Raistmer the Sorcerer wrote:

 If BOINC client stopped unexpectedly (crashed or killed via task manager 
 for example) CPU apps exit after some time. But SETI OpenCL apps continue 
 to run to completion.
 Such behavior can and (was demonstrated) will result in subsequent result 
 computation error with some BOINC message like result file too long or 
 smth alike.

 OpenCL apps working in BOINC's critical section and poll flags 
 periodically to see if exit required.

 Currently I use next poll function to check exit condition:

 inline void ExitCheck(){
 check_repeat:
 if (boinc_status.quit_request || boinc_status.abort_request || !canRun) {
 /* fprintf(stderr,DEBUG: polled for exit/suspend request: exit needed. 
 Flags are: boinc_status.quit_request=%d, \
 boinc_status.abort_request=%d, canRun=%d\n,
 boinc_status.quit_request,boinc_status.abort_request,canRun);*/
 DoSyncExit();
 }else if(boinc_status.suspended){
 Sleep(100); //R:await in sleep 100ms
 /* fprintf(stderr,DEBUG: polled for exit/suspend request: sleep needed. 
 Flags are: boinc_status.quit_request=%d, \
 boinc_status.abort_request=%d, canRun=%d\n,
 boinc_status.quit_request,boinc_status.abort_request,canRun);*/
 goto check_repeat;//R: check again if exit required or sleep continues
 }else{
 /* fprintf(stderr,DEBUG: polled for exit/suspend request: exit NOT needed. 
 Flags are: boinc_status.quit_request=%d, \
 boinc_status.abort_request=%d, canRun=%d\n,
 boinc_status.quit_request,boinc_status.abort_request,canRun);*/
 }
 } What another flags should be checked if any to prevent orphaned state for 
 GPU apps? Does BOINC API have measures to properly end task running in 
 critical section in case of BOINC client crash?

 wbr

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Documentation: server_stable

[Richard Haselgrove]

Documentation file http://boinc.berkeley.edu/trac/wiki/SourceCodeGit contains 
the text

For all software other than the client (i.e., server, web, and API) a stable 
version is kept in a branch, server_release.


That wording has remained unchanged since 
http://boinc.berkeley.edu/trac/wiki/SourceCodeGit?version=1 : so far as I can 
tell, it wasn't true then, and it certainly isn't true now. Searching through 
the Tortoise Git Revision Graph, I can only find three references to 
server_release tags, all from 2008 and 2009.

Unfortunately, this confusion is leading certain developers to ignore the 
second part of the sentence:

Don't use the server software in a client tag or branch; it probably isn't 
stable.

Could we possibly re-phrase this page, and attach some testing confidence level 
to potential sources of the Server and API components of the BOINC code?
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Boinc fails to build from source

[Richard Haselgrove]

I assume Jenkins is only doing client builds? It didn't pick that up.




 From: Gianfranco Costamagna costamagnagianfra...@yahoo.it
To: Rom Walton r...@romwnet.org; boinc_dev@ssl.berkeley.edu 
boinc_dev@ssl.berkeley.edu 
Sent: Sunday, October 5, 2014 11:37 AM
Subject: [boinc_dev] Boinc fails to build from source
 

Hi Rom and all, 


I don't think this is an issue, but reporting anyway :)

After your commit [1], boinc seems to be failing to build from source [2].


Adding ProjectWelcomePage.cpp into clientgui/Makefile.am should fix the isue 
(didn't test it).


[1] 
http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commitdiff;h=d549682e87e625d0b5382d8334f030f475544533


[2] 
https://launchpadlibrarian.net/186581486/buildlog_ubuntu-trusty-amd64.boinc_7.5.0~nightly1~~git20141005%2Br22056~r186~ubuntu14.04.1_FAILEDTOBUILD.txt.gz


cheers,

Gianfranco 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] High priority status message removed.

[Richard Haselgrove]

Just observe. I'm currently running two SIMAP tasks which were issued with a 
two-day deadline (additional replications required for validation - they must 
be using

reliable_reduced_delay_boundX/reliable_reduced_delay_bound
When a need-reliable result is sent to a reliable host, multiply the delay 
bound by reliable_reduced_delay_bound (typically 0.5 or so).

Set a two day queue, and BOINC panics.

Don't judge every BOINC operation by the relaxed timings used at SETI.



 From: Charles Elliott elliott...@comcast.net
To: 'McLeod, John' john.mcl...@sap.com; jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.com; boinc_dev@ssl.berkeley.edu 
Sent: Saturday, October 4, 2014 1:37 PM
Subject: Re: [boinc_dev] High priority status message removed.
 

 You can still easily get into deadline trouble with either large queues,
or multiple projects and an occasional tight deadline



Proof?



From: McLeod, John [mailto:john.mcl...@sap.com] 
Sent: Friday, October 3, 2014 10:54 PM
To: jacob_w_kl...@msn.com; r.haselgr...@btopenworld.com;
boinc_dev@ssl.berkeley.edu; elliott...@comcast.net
Subject: RE: [boinc_dev] High priority status message removed.



You can still easily get into deadline trouble with either large queues, or
multiple projects and an occasional tight deadline.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message- 
From: Charles Elliott [elliott...@comcast.net]
Received: Friday, 03 Oct 2014, 10:10PM
To: 'Jacob Klein' [jacob_w_kl...@msn.com]; 'Richard Haselgrove'
[r.haselgr...@btopenworld.com]; McLeod, John [john.mcl...@sap.com];
boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: RE: [boinc_dev] High priority status message removed.

On my computer, which is allocated about 300 AP WUs at a time, in late 
September Boinc was running AP WUs due in late October.  Then when October 
1 came it seemingly panicked and stopped doing anything but processing AP
WUs 
due October 17.  That behavior was useful when we could download thousands 
of WUs, but I think it should be questioned now.

Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.
 
 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.
 
 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edu
mailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edu
mailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.
 
 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John that it would be
 good if the reason for non-FIFO running could be marked in some way -
 if we can find a less-frightening word.
 
 
 
 
  From: McLeod, John john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.
 
 
 OK, High Priority made it sound like it was running at High OS
 Scheduler Priority, but some tag that it is not in the normal RR
 schedule might be good for helping diagnose problems.
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.
 
 
 
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom

Re: [boinc_dev] High priority status message removed.

[Richard Haselgrove]

The removal followed a question and answer session at the BOINC workshop in 
Budapest earlier this week. The OS scheduler mis-interpretation was one that I 
highlighted, but there was also a problem with users thinking that High 
Priority was a project-chosen queue-jumping facility. I think we're much better 
off without those confusions over terminology, but I agree with John that it 
would be good if the reason for non-FIFO running could be marked in some way - 
if we can find a less-frightening word. 




 From: McLeod, John john.mcl...@sap.com
To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu 
Sent: Friday, October 3, 2014 2:01 PM
Subject: [boinc_dev] High priority status message removed.
 

OK, High Priority made it sound like it was running at High OS Scheduler 
Priority, but some tag that it is not in the normal RR schedule might be good 
for helping diagnose problems.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] High priority status message removed.

[Richard Haselgrove]

Some permutation of 'deadline', 'risk', 'miss' ?

(At) risk of deadline miss ?
Risk of missing deadline ?




 From: Jord van der Elst els...@gmail.com
To: McLeod, John john.mcl...@sap.com 
Cc: BOINC Dev Mailing List boinc_dev@ssl.berkeley.edu 
Sent: Friday, October 3, 2014 5:24 PM
Subject: Re: [boinc_dev] High priority status message removed.
 

On Fri, Oct 3, 2014 at 6:13 PM, McLeod, John john.mcl...@sap.com wrote:
 I know the dictionary meanings.  Precedence tends to carry a connotation of 
 permanent.
From BOINC's point of view, it runs these tasks before anything else,
preferably until BOINC calculates that they can meet their deadline
and otherwise until they're finished.
That's preceding any of the other tasks, and only during the time of
the new condition.

At least in Dutch that would make perfect sense, 'met voorrang'.

I can't help it that English is so rigid, inelastic. :P

  Preference t (in computers at least) tends to mean settable by the user.

 -Original Message-
 From: Jord van der Elst [mailto:els...@gmail.com]
 Sent: Friday, October 03, 2014 12:10 PM
 To: McLeod, John
 Cc: David Anderson; BOINC Dev Mailing List
 Subject: Re: [boinc_dev] High priority status message removed.

 Priority: a thing that is regarded as more important than another.
 or: the fact or condition of being regarded or treated as more important.
 or: the right to take precedence or to proceed before others. ** ---

 Precedence: the condition of being considered more important than
 someone or something else; priority in importance, order, or rank.
 I'd say it's second to (high) priority.

 Preference: a greater liking for one alternative over another or others.
 or: a prior right or precedence, especially in connection with the
 payment of debts.

 We want to step away from priority, but do we still want it to have
 the same meaning? As then you look at synonyms, which is what I did:
 http://www.thesaurus.com/browse/priority

 -- Jord van der Elst.


 On Fri, Oct 3, 2014 at 6:03 PM, McLeod, John john.mcl...@sap.com wrote:
 Neither preference nor precedence has the quite right meaning in English 
 though.

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
 Jord van der Elst
 Sent: Friday, October 03, 2014 11:53 AM
 To: David Anderson
 Cc: BOINC Dev Mailing List
 Subject: Re: [boinc_dev] High priority status message removed.

 Task xx_yy_zz running as preference, trying to meet the deadline.
 Task xx_yy_zz running in precedence, trying to meet the deadline.

 Seeing how we do want to tell that it's a status in order of
 importance or urgency, we may want to go for the second one.

 -- Jord van der Elst.


 On Fri, Oct 3, 2014 at 4:44 PM, David Anderson da...@ssl.berkeley.edu 
 wrote:
 I think anything containing priority will create confusion
 with OS priority.

 The other problem with showing this info is that it creates the
 erroneous impression that the job's project will get more than
 its fair share of computing.
 Several projects report that when they use short job deadlines
 (which create high priority jobs) they get lots of user complaints.

 So I'm in favor of not showing this in the GUI;
 maybe we can show it in the event log in some better way.

 -- D

 On 03-Oct-2014 3:24 PM, Jacob Klein wrote:

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC workshop
 in Budapest earlier this week. The OS scheduler mis-interpretation was one
 that I highlighted, but there was also a problem with users thinking that
 High Priority was a project-chosen queue-jumping facility. I think we're
 much better off without those confusions over terminology, but I agree 
 with
 John that it would be good if the reason for non-FIFO running could be
 marked in some way - if we can find a less-frightening word.



 
 From: McLeod, John john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.


 OK, High Priority made it sound like it was running at High OS Scheduler
 Priority, but some tag that it is not in the normal RR schedule might be
 good for helping diagnose problems.
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.



 ___
 boinc_dev mailing list
 

Re: [boinc_dev] High priority status message removed.

[Richard Haselgrove]

I don't think we'll ever have space to fit all that in, until we implement 
tooltip technology in BOINC Manager for full information boxes, rather than 
just completing truncated cells.




 From: McLeod, John john.mcl...@sap.com
To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu; 
juha.sointus...@gmail.com juha.sointus...@gmail.com 
Sent: Friday, October 3, 2014 7:44 PM
Subject: Re: [boinc_dev] High priority status message removed.
 

That misses the detail that the time is borrowed, and will be paid back.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Juha [juha.sointus...@gmail.com]
Received: Friday, 03 Oct 2014, 2:22PM
To: BOINC Development [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

Skipping queue to meet deadline ?

-Juha


On 3 October 2014 19:15, Jacob Klein jacob_w_kl...@msn.com wrote:

 I still would like to see Prioritized to meet deadline in the UI, next
 to Running, despite David's logic against it.

 The user's interpretations are not something we can control.
 Providing the feedback, using as meaningful description as possible, is
 something we can control.
 And I haven't heard anything that beats my proposal, hence why I'd still
 like to see it.
 :)



  From: john.mcl...@sap.com
  To: els...@gmail.com
  Date: Fri, 3 Oct 2014 16:13:11 +
  CC: boinc_dev@ssl.berkeley.edu
  Subject: Re: [boinc_dev] High priority status message removed.
 
  I know the dictionary meanings.  Precedence tends to carry a connotation
 of permanent.  Preference t (in computers at least) tends to mean settable
 by the user.
 
  -Original Message-
  From: Jord van der Elst [mailto:els...@gmail.com]
  Sent: Friday, October 03, 2014 12:10 PM
  To: McLeod, John
  Cc: David Anderson; BOINC Dev Mailing List
  Subject: Re: [boinc_dev] High priority status message removed.
 
  Priority: a thing that is regarded as more important than another.
  or: the fact or condition of being regarded or treated as more important.
  or: the right to take precedence or to proceed before others. ** ---
 
  Precedence: the condition of being considered more important than
  someone or something else; priority in importance, order, or rank.
  I'd say it's second to (high) priority.
 
  Preference: a greater liking for one alternative over another or others.
  or: a prior right or precedence, especially in connection with the
  payment of debts.
 
  We want to step away from priority, but do we still want it to have
  the same meaning? As then you look at synonyms, which is what I did:
  http://www.thesaurus.com/browse/priority
 
  -- Jord van der Elst.
 
 
  On Fri, Oct 3, 2014 at 6:03 PM, McLeod, John john.mcl...@sap.com
 wrote:
   Neither preference nor precedence has the quite right meaning in
 English though.
  
   -Original Message-
   From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jord van der Elst
   Sent: Friday, October 03, 2014 11:53 AM
   To: David Anderson
   Cc: BOINC Dev Mailing List
   Subject: Re: [boinc_dev] High priority status message removed.
  
   Task xx_yy_zz running as preference, trying to meet the deadline.
   Task xx_yy_zz running in precedence, trying to meet the deadline.
  
   Seeing how we do want to tell that it's a status in order of
   importance or urgency, we may want to go for the second one.
  
   -- Jord van der Elst.
  
  
   On Fri, Oct 3, 2014 at 4:44 PM, David Anderson da...@ssl.berkeley.edu
 wrote:
   I think anything containing priority will create confusion
   with OS priority.
  
   The other problem with showing this info is that it creates the
   erroneous impression that the job's project will get more than
   its fair share of computing.
   Several projects report that when they use short job deadlines
   (which create high priority jobs) they get lots of user complaints.
  
   So I'm in favor of not showing this in the GUI;
   maybe we can show it in the event log in some better way.
  
   -- D
  
   On 03-Oct-2014 3:24 PM, Jacob Klein wrote:
  
   I'd like to see Prioritized to meet deadline in the UI, next to
   Running.
  
   
   From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
   Sent: ‎10/‎3/‎2014 9:19 AM
   To: McLeod, Johnmailto:john.mcl...@sap.com;
   boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
   Subject: Re: [boinc_dev] High priority status message removed.
  
   The removal followed a question and answer session at the BOINC
 workshop
   in Budapest earlier this week. The OS scheduler mis-interpretation
 was one
   that I highlighted, but there was also a problem with users thinking
 that
   High Priority was a project-chosen queue-jumping facility. I think
 we're
   much better off without those confusions over terminology, but I
 agree with
   John that it would be good if the reason for non-FIFO running could
 be
   marked in some way - 

Re: [boinc_dev] boinc_get_opencl_ids() returns -33 while own app enumeration found device

[Richard Haselgrove]

Yes, got the file you need - still 4h45m to run on the task (I could interrupt 
it if you wish?)

The source code is stored in the main SETI@Home project SVN repository at 
Berkeley, in branches\sah_v7_opt\AP_BLANKIT\client. The app we're looking at 
was compiled at revision 2690.




 From: Charlie Fenton charl...@ssl.berkeley.edu
To: Richard Haselgrove r.haselgr...@btopenworld.com 
Cc: Raistmer the Sorcerer raist...@mail.ru; boinc_dev email List 
boinc_dev@ssl.berkeley.edu 
Sent: Thursday, September 18, 2014 11:32 AM
Subject: Re: [boinc_dev] boinc_get_opencl_ids() returns -33 while own app 
enumeration found device
 

Hi Richard,

Thank you.  Just to clarify, as I just posted to TBar on the SETI Beta forum:
 I need the init_data.xml file information from the slot directory of a task 
 which has the Invalid OpenCL GPU index problem, captured before that task 
 finishes; those from other slots won't help.

I assume you already understood that, but it never hurts to make sure.

 warningNVIDIA library reports 2 GPUs/warning
This is really a message for debugging; it's not really a warning despite 
what it says!

It would be helpful to confirm that this app uses the API of 
boinc_get_opencl_ids() which takes 5 arguments, as described in 
http://boinc.berkeley.edu/trac/wiki/OpenclApps.  Is the source code for this 
build of SETI@home beta available somewhere I can examine it?

Cheers,
--Charlie

--
Charlie Fenton                        charl...@ssl.berkeley.edu
BOINC / SETI@home Macintosh  Windows Programmer
Space Sciences Laboratory
UC Berkeley



On Sep 18, 2014, at 2:29 AM, Richard Haselgrove r.haselgr...@btopenworld.com 
wrote:

 I can start you off with some of that now.
 
 OpenCL detection:
 
 16-Sep-2014 19:35:29 [---] Starting BOINC client version 7.4.21 for 
 windows_x86_64
 16-Sep-2014 19:35:29 [---] log flags: file_xfer, sched_ops, task, cpu_sched, 
 sched_op_debug, work_fetch_debug
 16-Sep-2014 19:35:29 [---] Libraries: libcurl/7.33.0 OpenSSL/1.0.1h 
 zlib/1.2.8
 16-Sep-2014 19:35:29 [---] Data directory: D:\BOINCdata
 16-Sep-2014 19:35:29 [---] Running under account 
 16-Sep-2014 19:35:29 [---] CUDA: NVIDIA GPU 0: GeForce GTX 670 (driver 
 version 337.88, CUDA version 6.0, compute capability 3.0, 2048MB, 1950MB 
 available, 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] CUDA: NVIDIA GPU 1: GeForce GTX 670 (driver 
 version 337.88, CUDA version 6.0, compute capability 3.0, 2048MB, 1958MB 
 available, 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL: NVIDIA GPU 0: GeForce GTX 670 (driver 
 version 337.88, device version OpenCL 1.1 CUDA, 2048MB, 1950MB available, 
 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL: NVIDIA GPU 1: GeForce GTX 670 (driver 
 version 337.88, device version OpenCL 1.1 CUDA, 2048MB, 1958MB available, 
 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL: Intel GPU 0: Intel(R) HD Graphics 4000 
 (driver version 10.18.10.3621, device version OpenCL 1.2, 990MB, 990MB 
 available, 154 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL CPU: Intel(R) Core(TM) i7-3770K CPU @ 
 3.50GHz (OpenCL driver vendor: Intel(R) Corporation, driver version 
 3.0.1.10878, device version OpenCL 1.2 (Build 76413))
 
 I'd forgotten I loaded a CPU driver too!
 
 init_data.xml will have to follow when the GPUGrid task has finished.
 
 There is no app_info.xml file in this case - I'm not running anonymous 
 platform while Beta testing. So we can exclude that theory. Likewise, no 
 app_config.xml file for the project either.
 
 There's no coproc specification. The only non-standard GPU entry in 
 cc_config.xml is
 
     exclude_gpu
         urlhttp://www.gpugrid.net//url
         device_num0/device_num
         typeNVIDIA/type
     /exclude_gpu
 
 - restricting GPUGrid to device 1
 
 I attach coproc_info.xml, datestamped for the same startup as the log 
 messages above. I see
 
 warningNVIDIA library reports 2 GPUs/warning
 
 - which is absolutely true, I paid for both and installed them myself!
 
 You'll have to ask Raistmer about the code which generates the 'wrong 
 platform' warning - that's not my department. I think it's unlikely to be 
 ATI-related, but might be Intel-related. I'll have a better idea when I can 
 explore more fully this afternoon.
 
 More to follow.
 
 From: Charlie Fenton charl...@ssl.berkeley.edu
 To: Richard Haselgrove r.haselgr...@btopenworld.com 
 Cc: Raistmer the Sorcerer raist...@mail.ru; boinc_dev email List 
 boinc_dev@ssl.berkeley.edu 
 Sent: Thursday, September 18, 2014 9:39 AM
 Subject: Re: [boinc_dev] boinc_get_opencl_ids() returns -33 while own app 
 enumeration found device
 
 Hi Richard,
 
 Please send me the following when you see this problem again:
 
 * What does the BOINC client report about its detection of GPUs near the 
 beginning of BOINC's Event Log (in stdoutdae.txt a few lines after Starting 
 BOINC client version 7.2.42 )?  
 
 * The init_data.xml file from the slot directory with the problem

Re: [boinc_dev] boinc_get_opencl_ids() returns -33 while own app enumeration found device

[Richard Haselgrove]

In branches\sah_v7_opt\src\GPU_lock.cpp, line 685ff, I see

#if USE_OPENCL
//R: use BOINC ability to provide OpenCL device for execution. If BOINC fails 
to do that - use embedded enumeration scheme
if(err=boinc_get_opencl_ids(argc,argv,
#if USE_OPENCL_NV
PROC_TYPE_NVIDIA_GPU
#elif USE_OPENCL_INTEL
PROC_TYPE_INTEL_GPU
#else
PROC_TYPE_AMD_GPU
#endif
,boinc_device_id, boinc_platform_id)){
no_boinc_device_id=true;
//OCL_LOG_ERR(boinc_get_opencl_ids);
if(err==ERR_NOT_FOUND)fprintf(stderr,WARNING: BOINC was unable to find GPU 
device, using own enumeration\n);
else if(err==ERR_FOPEN)fprintf(stderr,WARNING: init_data.xml missing\n);
else fprintf(stderr,WARNING: boinc_get_opencl_ids failed with code %d\n,err);
}

That enumerates to five parameters, by my reckoning.




 From: Charlie Fenton charl...@ssl.berkeley.edu
To: Richard Haselgrove r.haselgr...@btopenworld.com 
Cc: boinc_dev email List boinc_dev@ssl.berkeley.edu 
Sent: Thursday, September 18, 2014 11:32 AM
Subject: Re: [boinc_dev] boinc_get_opencl_ids() returns -33 while own app 
enumeration found device
 

Hi Richard,

Thank you.  Just to clarify, as I just posted to TBar on the SETI Beta forum:
 I need the init_data.xml file information from the slot directory of a task 
 which has the Invalid OpenCL GPU index problem, captured before that task 
 finishes; those from other slots won't help.

I assume you already understood that, but it never hurts to make sure.

 warningNVIDIA library reports 2 GPUs/warning
This is really a message for debugging; it's not really a warning despite 
what it says!

It would be helpful to confirm that this app uses the API of 
boinc_get_opencl_ids() which takes 5 arguments, as described in 
http://boinc.berkeley.edu/trac/wiki/OpenclApps.  Is the source code for this 
build of SETI@home beta available somewhere I can examine it?

Cheers,
--Charlie

--
Charlie Fenton                        charl...@ssl.berkeley.edu
BOINC / SETI@home Macintosh  Windows Programmer
Space Sciences Laboratory
UC Berkeley



On Sep 18, 2014, at 2:29 AM, Richard Haselgrove r.haselgr...@btopenworld.com 
wrote:

 I can start you off with some of that now.
 
 OpenCL detection:
 
 16-Sep-2014 19:35:29 [---] Starting BOINC client version 7.4.21 for 
 windows_x86_64
 16-Sep-2014 19:35:29 [---] log flags: file_xfer, sched_ops, task, cpu_sched, 
 sched_op_debug, work_fetch_debug
 16-Sep-2014 19:35:29 [---] Libraries: libcurl/7.33.0 OpenSSL/1.0.1h 
 zlib/1.2.8
 16-Sep-2014 19:35:29 [---] Data directory: D:\BOINCdata
 16-Sep-2014 19:35:29 [---] Running under account 
 16-Sep-2014 19:35:29 [---] CUDA: NVIDIA GPU 0: GeForce GTX 670 (driver 
 version 337.88, CUDA version 6.0, compute capability 3.0, 2048MB, 1950MB 
 available, 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] CUDA: NVIDIA GPU 1: GeForce GTX 670 (driver 
 version 337.88, CUDA version 6.0, compute capability 3.0, 2048MB, 1958MB 
 available, 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL: NVIDIA GPU 0: GeForce GTX 670 (driver 
 version 337.88, device version OpenCL 1.1 CUDA, 2048MB, 1950MB available, 
 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL: NVIDIA GPU 1: GeForce GTX 670 (driver 
 version 337.88, device version OpenCL 1.1 CUDA, 2048MB, 1958MB available, 
 2915 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL: Intel GPU 0: Intel(R) HD Graphics 4000 
 (driver version 10.18.10.3621, device version OpenCL 1.2, 990MB, 990MB 
 available, 154 GFLOPS peak)
 16-Sep-2014 19:35:29 [---] OpenCL CPU: Intel(R) Core(TM) i7-3770K CPU @ 
 3.50GHz (OpenCL driver vendor: Intel(R) Corporation, driver version 
 3.0.1.10878, device version OpenCL 1.2 (Build 76413))
 
 I'd forgotten I loaded a CPU driver too!
 
 init_data.xml will have to follow when the GPUGrid task has finished.
 
 There is no app_info.xml file in this case - I'm not running anonymous 
 platform while Beta testing. So we can exclude that theory. Likewise, no 
 app_config.xml file for the project either.
 
 There's no coproc specification. The only non-standard GPU entry in 
 cc_config.xml is
 
     exclude_gpu
         urlhttp://www.gpugrid.net//url
         device_num0/device_num
         typeNVIDIA/type
     /exclude_gpu
 
 - restricting GPUGrid to device 1
 
 I attach coproc_info.xml, datestamped for the same startup as the log 
 messages above. I see
 
 warningNVIDIA library reports 2 GPUs/warning
 
 - which is absolutely true, I paid for both and installed them myself!
 
 You'll have to ask Raistmer about the code which generates the 'wrong 
 platform' warning - that's not my department. I think it's unlikely to be 
 ATI-related, but might be Intel-related. I'll have a better idea when I can 
 explore more fully this afternoon.
 
 More to follow.
 
 From: Charlie Fenton charl...@ssl.berkeley.edu
 To: Richard Haselgrove r.haselgr...@btopenworld.com 
 Cc: Raistmer the Sorcerer raist...@mail.ru; boinc_dev email List 
 boinc_dev@ssl.berkeley.edu 
 Sent: Thursday, September 18, 2014 9:39 AM
 Subject

Re: [boinc_dev] Credit AMD CPU vs Intel CPU.

[Richard Haselgrove]

The BOINC message board thread needs to be read in parallel with the matching 
NumberFields thread 
http://numberfields.asu.edu/NumberFields/forum_thread.php?id=209

In the project thread, the project administrator confirms that the project is 
using 'credit from runtime' (the task lengths are indeterminate).

Given that, the credit formula is (from l461 of validator.cpp)

credit = result.flops_estimate * runtime * COBBLESTONE_SCALE;


From what people have told me, the variable result.flops_estimate in that 
context contains a value closely tied to the Whetstone benchmark for the host. 
Numberfields is, I believe, a largely integer math project. In that case, 
could the disparity in credit boil down to the relative integer and floating 
point strengths of AMD and Intel CPUs?

In particular, if AMD has a low runtime (because its integer math unit is 
strong), and has a low result.flops_estimate (because its FP unit is weak), 
credit from runtime suffers on both parameters.




 From: Jord van der Elst els...@gmail.com
To: David Anderson da...@ssl.berkeley.edu 
Cc: BOINC Dev Mailing List boinc_dev@ssl.berkeley.edu 
Sent: Friday, August 29, 2014 4:45 PM
Subject: [boinc_dev] Credit AMD CPU vs Intel CPU.
 

Hi David,

In https://boinc.berkeley.edu/dev/forum_thread.php?id=9569 user
Grandpa reports that he has found a big discrepancy between credit
given out to AMD CPUs versus credit given out to Intel CPUs, at the
Numberfields project.

I'll quote his last post on this:


AMD Opteron(TM) Processor 6276 [Family 21 Model 1 Stepping 2]
(64 processors)
Total runtime 100 WU's 1810010.65 Total points 100 WU's 26128.8 Grandma 6276 
AMD
Avg runtime per WU sec. 18100.1065 avg points per WU 261.288 3042Mhz
Avg runtime per WU min. 301.6684416667
Avg runtime per WU hr. 5.0278073611 avg points per hr runtime 51.9685781959

Genuine Intel(R) CPU @ 2.70GHz [Family 6 Model 45 Stepping 5]
(64 processors)
Total runtime 100 WU's 1839477.54 Total points 100 WU's 38003.75 Musky
4650 Intel
Avg runtime per WU sec. 18394.7754 avg points per WU 380.0375 3134Mhz
Avg runtime per WU min. 306.57959
Avg runtime per WU hr. 5.1096598333 avg points per hr runtime 74.3762818653

OK but it still does not change the fact that this type of credit
system has a pretty big flaw in it. According to the developer at
Numberfields each of the machines above are doing the same amount of
work and lets say that each WU is worth 1 FLOPS since the numbers were
averaged over 100 WU's each and all things being equal those 2
machines should have received roughly the same amount of credit with a
slight advantage going to the AMD, but in actuality AMD is receiving
30% less.

I do not really see this as being a fair credit system to the AMD
users when it come to certain types of work.

AMD 100 WU's = 100 FLOPS = 502.78 hrs of runtime = 26706.79 points of
credit for 100 theoretical FLOPS

Intel 100 WU's = 100 FLOPS = 510.96 hrs of runtime = 38003.74 points
of credit for 100 theoretical FLOPS

So in plain simple terms AMD gets less credit for doing the same
amount of work as Intel does. I am just pointing out a pretty big flaw
in the current credit system, from everything I have read and been
told this system was set up to promote equality between all work done
and to try and discourage cheating, It appears to me that it may have
missed it's mark when in the equality field and they may need to go
back to the drawing board and try and fix the problem or at least let
people know that the credit system has a problem with some projects.


I seem to remember that Seti has a similar problem, but the finer
details escape me.

Perhaps that (more) knowledgeable people can explain the 
discrepancy/difference?

Thanks,

-- Jord van der Elst.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Documentation - server updates

[Richard Haselgrove]

There was a request on the BOINC message board earlier today:

http://boinc.berkeley.edu/dev/forum_thread.php?id=9562
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] astropulse robustness / abandonned tasks

[Richard Haselgrove]

The abandoning of tasks happens when the BOINC server 'thinks' that it has 
'evidence' that the client has detached from the project and then re-attached 
again. This has affected a number of users in the past, but has proved 
extremely tricky to diagnose and resolve: not least, because most of the 
evidence resides in the server logs.

We did investigate one suspected case at Albert during credit testing, but that 
turned out to be a genuine 'detach' caused by hard disk failure - it is 
distinguished from reports like this one because no running tasks were left on 
the host computer (they were on the drive that failed...) to waste time and 
electricity.

I would certainly welcome it if we could pair up a developer and a project 
administrator with access to server logs to investigate this problem and cure 
it at source.

The checkpointing question is a matter for the project developers, and I'll 
leave it to them to respond via this list.




 From: Luc A. Germain l...@lucg.net
To: boinc_dev@ssl.berkeley.edu 
Sent: Friday, 8 August 2014, 9:41
Subject: [boinc_dev] astropulse robustness / abandonned tasks
 

Hi,
Two things:
1) A suggestion here for you develloppers ;-) As atropulse tasks take some 
time to complete they are more prone to power failure as we have in the third 
world. When it happens most of the time the task restarts computing from start 
(this is even more frustrating when the task reaches near completion). Could 
it be possible to introduce regular checkpoints by saving intermediate data, 
or work files, where the task computing could restart from, saving so a lot of 
computing time ? Maybe this could be an option in the user profile as I guess 
not everyone needs this.

2) Two days ago I sent a message about abandonned tasks. Since, all my 
computing goes to the garbage bin as they are not taken into account. Which 
procedure should/could I try to solve this problem ? Could 
uninstalling/reinstalling the application from my computers be a solution? 
Should I wait till the problem solves by itself (and would this not take ages) 
?

An answer would be highly appreciated.

Best regards and thanks for your work,
Luc
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] astropulse robustness / abandonned tasks

[Richard Haselgrove]

The same user appears to have suffered another 'abandon' event today:

http://setiathome.berkeley.edu/results.php?hostid=6960982state=6


The reasons mentioned by Eric are all valid, but there appears to be an 
irreducible core of sporadic events which cannot be ascribed to user 
malfeasance. In earlier reports like this, many (but not all) of the cases 
appeared to be associated with long-distance and/or poor quality internet 
connections - again, like this one.



 From: Eric J Korpela korp...@ssl.berkeley.edu
To: McLeod, John john.mcl...@sap.com 
Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu; Richard 
Haselgrove r.haselgr...@btopenworld.com 
Sent: Friday, 8 August 2014, 16:56
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks
 

Astropulse does checkpoint quite frequently, and restarts without problem
most of the time.  Abandoned is definitely a server side decision that
indicates a client detach or a reset or some sort of confusion as to the
identity of a host and whether it was working on those results.  (Other
possibilities include multiple hosts using a copied or shared BOINC
directory, multiple copies of BOINC on one host using the same BOINC client
directory, deletion or corruption or bad permissions on files in the BOINC
client directory, any of which could confuse client or server).


Which client version and OS are you using?


On Fri, Aug 8, 2014 at 5:55 AM, McLeod, John john.mcl...@sap.com wrote:

 BOINC has a checkpointing mechanism built in, but it requires that the
 project developers write checkpoint code.  Some projects can checkpoint
 almost any time, and others can checkpoint only every few minutes, and some
 cannot checkpoint at all.  SETI can checkpoint frequently (and instigated
 the mechanism to NOT do every possible checkpoint, but only once every X
 minutes).  CPDN always checkpoints every time it can (typically this is
 several minutes).  I cannot remember an example of one that cannot
 checkpoint at all, but they exist.

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
 Richard Haselgrove
 Sent: Friday, August 08, 2014 4:48 AM
 To: Luc A. Germain; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

 The abandoning of tasks happens when the BOINC server 'thinks' that it has
 'evidence' that the client has detached from the project and then
 re-attached again. This has affected a number of users in the past, but has
 proved extremely tricky to diagnose and resolve: not least, because most of
 the evidence resides in the server logs.

 We did investigate one suspected case at Albert during credit testing, but
 that turned out to be a genuine 'detach' caused by hard disk failure - it
 is distinguished from reports like this one because no running tasks were
 left on the host computer (they were on the drive that failed...) to waste
 time and electricity.

 I would certainly welcome it if we could pair up a developer and a project
 administrator with access to server logs to investigate this problem and
 cure it at source.

 The checkpointing question is a matter for the project developers, and
 I'll leave it to them to respond via this list.



 
  From: Luc A. Germain l...@lucg.net
 To: boinc_dev@ssl.berkeley.edu
 Sent: Friday, 8 August 2014, 9:41
 Subject: [boinc_dev] astropulse robustness / abandonned tasks
 
 
 Hi,
 Two things:
 1) A suggestion here for you develloppers ;-) As atropulse tasks take
 some time to complete they are more prone to power failure as we have in
 the third world. When it happens most of the time the task restarts
 computing from start (this is even more frustrating when the task reaches
 near completion). Could it be possible to introduce regular checkpoints by
 saving intermediate data, or work files, where the task computing could
 restart from, saving so a lot of computing time ? Maybe this could be an
 option in the user profile as I guess not everyone needs this.
 
 2) Two days ago I sent a message about abandonned tasks. Since, all my
 computing goes to the garbage bin as they are not taken into account. Which
 procedure should/could I try to solve this problem ? Could
 uninstalling/reinstalling the application from my computers be a solution?
 Should I wait till the problem solves by itself (and would this not take
 ages) ?
 
 An answer would be highly appreciated.
 
 Best regards and thanks for your work,
 Luc
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.
 
 
 
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL

Re: [boinc_dev] astropulse robustness / abandonned tasks

[Richard Haselgrove]

In probably the fullest message board description on the last circuit round 
this merry-go-round,

http://setiathome.berkeley.edu/forum_thread.php?id=70946


we observed a number of occasions where client message logs contained lines like

22.05.2013 13:45:56 | SETI@home | Not sending work - last request too recent: 
76 sec


at times not unadjacent to the times when abandonments were recorded for user 
tasks. That led us into 'clutching at straws' mode: was another computer 
sending out-of-sequence RPC requests with duplicate credentials? (the users 
swore not). Were entire RPC requests being delayed in a transit queue and 
arriving out of sequence? Unlikely. Was the server receiving the RPCs in a 
timely fashion, but processing them out of order - perhaps delaying one because 
of incomplete packets?

And so on. Most of this was happening before the server move to CoLo, when the 
SETI data line was heavily congested - we thought the problem might diminish 
with the higher-quality internet service at the bottom of the hill, and so it 
seems to have transpired. But doesn't help our friends outwith the continental 
USA.

Incidentally, I reported seeing one 'last request too recent' in my own logs, 
and traced it back to an internet time update changing the computer clock. But 
I didn't suffer any abandoned tasks in that event.



 From: Eric J Korpela korp...@ssl.berkeley.edu
To: Richard Haselgrove r.haselgr...@btopenworld.com 
Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu 
Sent: Friday, 8 August 2014, 17:47
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks
 

His host seems to be losing track of RPC sequence numbers.  Loss of cached
writes on restart?

2014-08-08 07:13:53.1883 [PID=28339]   [HOST#6960982] [USER#8522684] RPC
seqno 59642 less than expected 59643; creating new host
2014-08-08 07:13:53.1896 [PID=28339]   [HOST#6960982] [USER#8522684] Found
similar existing host for this user - assigned.
2014-08-08 07:13:53.1932 [PID=28339] [CRITICAL]  [HOST#6960982]
[RESULT#3670788988] [WU#1562416658] changed CPID: marking in-progress
result 03se08ad.16169.8252.438086664200.12.220_0 as client error!
2014-08-08 07:13:53.1932 [PID=28339]   Request: [USER#8522684]
[HOST#6960982] [IP 41.79.224.134] client 7.2.42



On Fri, Aug 8, 2014 at 9:17 AM, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:

 The same user appears to have suffered another 'abandon' event today:

 http://setiathome.berkeley.edu/results.php?hostid=6960982state=6

 The reasons mentioned by Eric are all valid, but there appears to be an
 irreducible core of sporadic events which cannot be ascribed to user
 malfeasance. In earlier reports like this, many (but not all) of the cases
 appeared to be associated with long-distance and/or poor quality internet
 connections - again, like this one.

   --
  *From:* Eric J Korpela korp...@ssl.berkeley.edu
 *To:* McLeod, John john.mcl...@sap.com
 *Cc:* boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu; Richard
 Haselgrove r.haselgr...@btopenworld.com
 *Sent:* Friday, 8 August 2014, 16:56

 *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks

 Astropulse does checkpoint quite frequently, and restarts without problem
 most of the time.  Abandoned is definitely a server side decision that
 indicates a client detach or a reset or some sort of confusion as to the
 identity of a host and whether it was working on those results.  (Other
 possibilities include multiple hosts using a copied or shared BOINC
 directory, multiple copies of BOINC on one host using the same BOINC client
 directory, deletion or corruption or bad permissions on files in the BOINC
 client directory, any of which could confuse client or server).


 Which client version and OS are you using?


 On Fri, Aug 8, 2014 at 5:55 AM, McLeod, John john.mcl...@sap.com wrote:

  BOINC has a checkpointing mechanism built in, but it requires that the
  project developers write checkpoint code.  Some projects can checkpoint
  almost any time, and others can checkpoint only every few minutes, and
 some
  cannot checkpoint at all.  SETI can checkpoint frequently (and instigated
  the mechanism to NOT do every possible checkpoint, but only once every X
  minutes).  CPDN always checkpoints every time it can (typically this is
  several minutes).  I cannot remember an example of one that cannot
  checkpoint at all, but they exist.
 
  -Original Message-
  From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
  Richard Haselgrove
  Sent: Friday, August 08, 2014 4:48 AM
  To: Luc A. Germain; boinc_dev@ssl.berkeley.edu
  Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks
 
  The abandoning of tasks happens when the BOINC server 'thinks' that it
 has
  'evidence' that the client has detached from the project and then
  re-attached again. This has affected a number of users in the past, but
 has
  proved

Re: [boinc_dev] astropulse robustness / abandonned tasks

[Richard Haselgrove]

That is certainly true, but in the cases that I investigated - which started 
with posts in various degrees of indignation on the message boards - the users 
were adamant that copying of data directories had *not* taken place.




 From: McLeod, John john.mcl...@sap.com
To: Eric J Korpela korp...@ssl.berkeley.edu; Richard Haselgrove 
r.haselgr...@btopenworld.com 
Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu 
Sent: Friday, 8 August 2014, 18:47
Subject: RE: [boinc_dev] astropulse robustness / abandonned tasks
 

One technique used to create a new host that is attached to everything that an 
old host is attached to is to copy the entire data directory from old to new 
and install BOINC on the new host.  This would tend to preserve the sequence 
number.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric 
J Korpela
Sent: Friday, August 08, 2014 1:44 PM
To: Richard Haselgrove
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

The other possibility is the sender doesn't think the prior RPC completed
and didn't update the sequence number (although I haven't looked at the
code to see if this is possible).  With a mismatch of one out of 59643
seems like the server is reaching exactly the wrong conclusion (this is a
new host) rather than the right one (there was a communications problem on
the prior contact).  If it were a new host, shouldn't the sequence number
be near 0?


On Fri, Aug 8, 2014 at 10:19 AM, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:

 In probably the fullest message board description on the last circuit
 round this merry-go-round,

 http://setiathome.berkeley.edu/forum_thread.php?id=70946

 we observed a number of occasions where client message logs contained
 lines like

 22.05.2013 13:45:56 | SETI@home | Not sending work - last request too
 recent: 76 sec

 at times not unadjacent to the times when abandonments were recorded for
 user tasks. That led us into 'clutching at straws' mode: was another
 computer sending out-of-sequence RPC requests with duplicate credentials?
 (the users swore not). Were entire RPC requests being delayed in a transit
 queue and arriving out of sequence? Unlikely. Was the server receiving the
 RPCs in a timely fashion, but processing them out of order - perhaps
 delaying one because of incomplete packets?

 And so on. Most of this was happening before the server move to CoLo, when
 the SETI data line was heavily congested - we thought the problem might
 diminish with the higher-quality internet service at the bottom of the
 hill, and so it seems to have transpired. But doesn't help our friends
 outwith the continental USA.

 Incidentally, I reported seeing one 'last request too recent' in my own
 logs, and traced it back to an internet time update changing the computer
 clock. But I didn't suffer any abandoned tasks in that event.

   --
  *From:* Eric J Korpela korp...@ssl.berkeley.edu
 *To:* Richard Haselgrove r.haselgr...@btopenworld.com
 *Cc:* boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 *Sent:* Friday, 8 August 2014, 17:47

 *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks

 His host seems to be losing track of RPC sequence numbers.  Loss of cached
 writes on restart?

 2014-08-08 07:13:53.1883 [PID=28339]  [HOST#6960982] [USER#8522684] RPC
 seqno 59642 less than expected 59643; creating new host
 2014-08-08 07:13:53.1896 [PID=28339]  [HOST#6960982] [USER#8522684] Found
 similar existing host for this user - assigned.
 2014-08-08 07:13:53.1932 [PID=28339] [CRITICAL]  [HOST#6960982]
 [RESULT#3670788988] [WU#1562416658] changed CPID: marking in-progress
 result 03se08ad.16169.8252.438086664200.12.220_0 as client error!
 2014-08-08 07:13:53.1932 [PID=28339]  Request: [USER#8522684]
 [HOST#6960982] [IP 41.79.224.134] client 7.2.42



 On Fri, Aug 8, 2014 at 9:17 AM, Richard Haselgrove 
 r.haselgr...@btopenworld.com wrote:

  The same user appears to have suffered another 'abandon' event today:
 
  http://setiathome.berkeley.edu/results.php?hostid=6960982state=6
 
  The reasons mentioned by Eric are all valid, but there appears to be an
  irreducible core of sporadic events which cannot be ascribed to user
  malfeasance. In earlier reports like this, many (but not all) of the
 cases
  appeared to be associated with long-distance and/or poor quality internet
  connections - again, like this one.
 
   --
   *From:* Eric J Korpela korp...@ssl.berkeley.edu
  *To:* McLeod, John john.mcl...@sap.com
  *Cc:* boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu; Richard
  Haselgrove r.haselgr...@btopenworld.com
  *Sent:* Friday, 8 August 2014, 16:56
 
  *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks

 
  Astropulse does checkpoint quite frequently, and restarts without problem
  most of the time.  Abandoned

Re: [boinc_dev] Deleting your project account

[Richard Haselgrove]

Only two requests may have reached your inbox, but there are 12 message board 
threads (over 8 BOINC years) at SETI asking how it could be done. That's just 
looking at the thread titles - I haven't read them all to see how serious the 
intention to delete was.




 From: David Anderson da...@ssl.berkeley.edu
To: Bernd Machenschalk bernd.machensch...@aei.mpg.de; 
boinc_dev@ssl.berkeley.edu 
Sent: Thursday, 7 August 2014, 8:18
Subject: Re: [boinc_dev] Deleting your project account
 

This functionality is there, but it's commented out (see user.inc).
I anticipate that it could lead to lots of
I accidentally deleted my account, can you restore it? emails.
I've received only 1 or 2 requests for deleting SETI@home accounts in 15 years.
-- David

On 06-Aug-2014 10:58 PM, Bernd Machenschalk wrote:
 Actually deleting a user account (row in user table) would harm the 
 consistency of
 the database, these are referenced everywhere. As BOINC (web) code is not 
 really
 good in handling unexpected results of DB queries this would cause visible 
 problems
 all over the place.

 However a standard procedure (function) for invalidating accounts that is 
 made
 known to users as well as project admins would certainly be of value, and 
 nowadays
 would actually be required by the laws of an increasing number of countries.

 I would add a button delete account that sets the name to the predefined 
 string
 (account deleted),.does.something similar with the email address and 
 modifies the
 authenticator such that it becomes invalid, but the original value can still 
 be
 derived if necessary (e.g. append _deleted).

 A project admin then can still restore (access to) the account when he gets 
 mailed
 the original authenticator for verification.

 Best,
 Bernd

 On 7. August 2014 06:30:08 MESZ, David Anderson da...@ssl.berkeley.edu 
 wrote:

     I'm not sure a delete account function is needed.
     A use can effectively remove his account by setting
     the name and email address to random strings.
     -- David


     On 06-Aug-2014 3:14 PM, Jord van der Elst wrote:

         Hi developers,

         I've taken a longer look at deleting the account at BOINC projects.
         The option is there in the code, but it's at present disabled, as it
         isn't fool proof.
         Now, I'm not saying I can make it fool proof, but...

         What if when I wanted to delete my account, I press the key to do so,
         I get the warning pop-up asking me if I really want to do so, I click
         Yes.
         That at that time, all that really happens is that the account's
         authentication key gets removed from the database, that the
         authentication key is emailed to me --the deleting user-- and to the
         project administrator (special email address?) but that the account 
is
         still in the database just not accessible by me? The email to the
         project administrator will hold the date and time of removal, the
         authentication key, my email address, my IP address (?) and my
         (nick)name.

         Then if I think the next day or week that I want to have my account
         back, that I can email the administrator, give him the details on the
         account and the authenticator key, and that all he has to do is add 
it
         back in the database, and presto everything works again? Of course, 
by
         also (silently) sending this to the project administrator, we make
         sure that if someone malicious managed to get his hands on my 
account,
         and deleted it, that the project administrator is able to put it back
         without much trouble.



         -- Jord van der Elst.
         


         boinc_dev mailing list
        boinc_dev@ssl.berkeley.edu
        http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
         To unsubscribe, visit the above URL and
         (near bottom of page) enter your email address.


     


     boinc_dev mailing list
    boinc_dev@ssl.berkeley.edu
    http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
     To unsubscribe, visit the above URL and
     (near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.