Re: [ccp4bb] Python3 and MTZ

[Markus Gerstel]

On 7 June 2018 at 17:55, Ethan Merritt  wrote:

> My basic concern is that python language development has broken existing
> code in the past. Frequently.  They feel free to change things at any
> point,
> even fundamental things like the meaning of the arithmetic operation
> "divide".
> You may be perfectly happy with the current state of the python 3 language,
> but based on past history that state will change and change again and
> sooner
> or later your current code will stop working.  My concern is not the
> state of the language at any given point in time, but the fact that it
> has been unstable for the past two decades and the worry that this
> instability
> will continue into the future.
>

The division example was in my opinion handled rather well, as the default
behaviour was consistent in Python 2 and is consistent within Python 3, but
different between the two.
If you wanted the new (3) behaviour in the old (2) Python you would
declare *from
__future__ import division *at the top of your file, and you can migrate
one file at a time. The default Python 2.7 behaviour is the same as it was
in Python 1.0.

I gather that one cluster of recent breakage is incompatible changes to
> text handling.  I cannot speak to this issue from personal experience,
> but here is a pointer to recent complaints/arguments/counter-arguments.
>   https://lwn.net/Articles/741176/


Unicode is difficult in any language. (pun possibly intended)

It is a big thing for any 2->3 migration as you have to consciously decide
what is text and what is data and how you handle the boundaries.

I kind of agree with all of those points.
> The sticky point is if you are likely to be one of the people on the
> receiving end of that nagging.
>

I am on both sides of this argument. I try to drive Python 3 compatibility
for DIALS, which involves nagging people responsible for upstream packages
that we rely on.
However, you will help me by nagging me, because then I can point other
developers to users who want this. Otherwise the whole migration thing can
look like an academic exercise.
So please do nag.
(I don't want to end up at *another* cliff edge in 2020, having just gone
over the one in 2019.)

-Markus



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Python3 and MTZ

[Peter Keller]

On 07/06/18 17:55, Ethan Merritt wrote:

I gather that one cluster of recent breakage is incompatible changes to
text handling.  I cannot speak to this issue from personal experience,
but here is a pointer to recent complaints/arguments/counter-arguments.
   https://lwn.net/Articles/741176/


I'm not going to take sides in the Python 2 vs. 3 issue, or comment on 
how well the transition between the two is being handled (these days, I 
rarely code in Python). However this sentence from the lwn.net article:


This change could, of course, cause problems for those who are actually expecting (and wanting) to get ASCII-only behavior. 


reminds me for just how long arguments about character data have been 
going on. Also how strongly held people's opinions about it are. Here is 
what Joel Spolsky had to say back in 2003:


https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

TL;DR?


You can no longer stick your head in the sand and pretend that “plain” text is 
ASCII.

There Ain’t No Such Thing As Plain Text.


If you disagree with Joel Spolsky about this, flame him, not me ;-)

Regards,
Peter.

--
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] PhD and Postdoc vacancies in Leicester, UK

[Daniel Panne]

PhD and Postdoc vacancies in Leicester on protein complexes involved in 
chromatin in gene regulation.

PhD and postdoctoral research posts are available in the lab of Daniel Panne to 
investigate the structure and function of higher–order signalling complexes 
that are important in inflammatory/cancer signalling, innate immunity and 
gene/chromatin regulation. Recently, the Medical Research Council in 
partnership with the Universities of Leicester, Warwick, Nottingham and 
Birmingham has invested into a state-of-the-art CryoEM facility at the 
Leicester Institute for Structural and Chemical Biology (LISCB).

LISCB is a new, flagship Research Institute of the University of Leicester and 
builds upon Leicester’s existing strengths in structural biology, chemical 
biology and single molecule research to deliver major advances in both 
fundamental and translational science. LISCB brings together over 20 research 
groups in the purpose-built Henry Wellcome Building (HWB) to best promote 
interdisciplinary collaborations and provide a vibrant research environment 
with first class facilities. 

Informal enquiries can be directed to me via email (daniel.pa...@le.ac.uk 
).

For the PhD position, the closing date is midnight on 23dr July 2018. For 
further details, and to apply for the job, use the link:

https://www2.le.ac.uk/research-degrees/funding/life-sciences 
 

For the Postdoc position, the closing date is midnight 20th July 2018. For 
further details, and to apply for the job, use the University vacancy search 
site:

https://jobs.le.ac.uk/vacancies/vacancy-details.aspx?VacancyID=162 




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Python3 and MTZ

[Ethan Merritt]

On Thursday, 07 June 2018 16:55:55 Markus Gerstel wrote:
> On 6 June 2018 at 20:28, Ethan Merritt  wrote:
> 
> > On Wednesday, 06 June 2018 18:54:32 Robbie Joosten wrote:
> > > Right you are Kay. It would be very weird to start developing things on
> > Python 2.7 right now. Its days are numbered: https://pythonclock.org/
> >
> > I would take a contrarian view.
> > Given the instability of python development, the promise to leave version
> > 2.7
> > alone makes it more desirable than the current ever-changing version.
> > You can be reasonably sure that anything you write for 2.7 will continue
> > to work, since they won't change the 2.7 infrastructure underneath you.
> >
> > But in truth I would recommend staying away from python for new projects
> > altogether, precisely because it is continually unstable.  The python
> > development philosophy places low priority on backwards-compatibility.
> > Combined with the explicit philosophy that python should only support one
> > way of accomplishing any given task, that is a recipe for frequent and
> > continual breakage.
> >
> > Here's an essay from a few years back that I think is still apposite.
> > https://jakevdp.github.io/blog/2013/01/03/will-scientists-ever-move-to-
> > python-3/
> 
> 
> Your point of view may be valid in that Python 2 -> 3 breaks existing code.
> However you sound like you mean 3.3 -> 3.4 -> 3.5 -> 3.6 -> 3.7 would be an
> issue, and I think that is a rarely argued view.
> I certainly can't find anything in the essay backing this up.

My basic concern is that python language development has broken existing
code in the past. Frequently.  They feel free to change things at any point,
even fundamental things like the meaning of the arithmetic operation "divide".  
You may be perfectly happy with the current state of the python 3 language,
but based on past history that state will change and change again and sooner
or later your current code will stop working.  My concern is not the
state of the language at any given point in time, but the fact that it
has been unstable for the past two decades and the worry that this instability
will continue into the future.

I gather that one cluster of recent breakage is incompatible changes to
text handling.  I cannot speak to this issue from personal experience,
but here is a pointer to recent complaints/arguments/counter-arguments.
  https://lwn.net/Articles/741176/

> 
> For what it's worth, in my opinion:
> If you are new to Python - learn 3.
> If you are using Python2/3 compatible libaries - learn 3 and use the
> libraries from there.
> If you are using libraries that are not yet Python3 compatible - well then
> you have to use Python2 and please nag the developers to make it Python3
> compatible.

I kind of agree with all of those points.
The sticky point is if you are likely to be one of the people on the
receiving end of that nagging.

I.e. the advice to a new user may be different from the advice to
a developer embarking on a new project.

Ethan

> On 7 June 2018 at 11:43, Marcin Wojdyr  wrote:
> 
> > In other words, it's learning both Python2 and Python3 and using the
> > subset of the language that works with both interpreters.
> >
> 
> You only have to care about making your code 2/3 compatible if you are
> writing a library that someone else will import, ie. if you publish on pypi
> or elsewhere.
> Otherwise - as a newcomer - definitely do not bother with Python 2 and go
> straight to Python 3 only.
> 
> -Markus

-- 
Ethan A Merritt, Dept of Biochemistry
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Python3 and MTZ

[Markus Gerstel]

On 6 June 2018 at 20:28, Ethan Merritt  wrote:

> On Wednesday, 06 June 2018 18:54:32 Robbie Joosten wrote:
> > Right you are Kay. It would be very weird to start developing things on
> Python 2.7 right now. Its days are numbered: https://pythonclock.org/
>
> I would take a contrarian view.
> Given the instability of python development, the promise to leave version
> 2.7
> alone makes it more desirable than the current ever-changing version.
> You can be reasonably sure that anything you write for 2.7 will continue
> to work, since they won't change the 2.7 infrastructure underneath you.
>
> But in truth I would recommend staying away from python for new projects
> altogether, precisely because it is continually unstable.  The python
> development philosophy places low priority on backwards-compatibility.
> Combined with the explicit philosophy that python should only support one
> way of accomplishing any given task, that is a recipe for frequent and
> continual breakage.
>
> Here's an essay from a few years back that I think is still apposite.
> https://jakevdp.github.io/blog/2013/01/03/will-scientists-ever-move-to-
> python-3/


Your point of view may be valid in that Python 2 -> 3 breaks existing code.
However you sound like you mean 3.3 -> 3.4 -> 3.5 -> 3.6 -> 3.7 would be an
issue, and I think that is a rarely argued view.
I certainly can't find anything in the essay backing this up.

For what it's worth, in my opinion:
If you are new to Python - learn 3.
If you are using Python2/3 compatible libaries - learn 3 and use the
libraries from there.
If you are using libraries that are not yet Python3 compatible - well then
you have to use Python2 and please nag the developers to make it Python3
compatible.

On 7 June 2018 at 11:43, Marcin Wojdyr  wrote:

> In other words, it's learning both Python2 and Python3 and using the
> subset of the language that works with both interpreters.
>

You only have to care about making your code 2/3 compatible if you are
writing a library that someone else will import, ie. if you publish on pypi
or elsewhere.
Otherwise - as a newcomer - definitely do not bother with Python 2 and go
straight to Python 3 only.

-Markus



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Python3 and MTZ

[graeme.win...@diamond.ac.uk]

Hi Marcin,

I do not think that this is an unreasonable burden, given what you gain as a 
result of it - the languages are probably >> 90% identical, and you get access 
to a bucket full of tools by staying in the common ground area. I appreciate 
that rewriting cctbx could be a fun challenge, but I for one don’t have time to 
do so ;-) 

Kay, quite by chance I find myself writing a jiffy script which compares 
scaled-but-unmerged data with scaled and merged data, to look at the 
distributions about the mean value - clearly I could merge the data myself 
using cctbx tools, but the aim was to compare the reflections files as they 
came from aimless - anyway, this computes a “z” score for each reflection i.e. 
(i - ) / sig(i) for each observation & forms a histogram:

20 ish lines of code and a few minutes later:



from __future__ import print_function, division

from iotbx import mtz
from scitbx.array_family import flex
import sys

merged = mtz.object(sys.argv[1])
unmerged = mtz.object(sys.argv[2])

unique_indices = merged.extract_miller_indices()
all_indices = unmerged.extract_miller_indices()
imean = merged.extract_observations('IMEAN', 'SIGIMEAN')
iuniq = unmerged.extract_observations('I', 'SIGI')

z = flex.double(iuniq.data.size(), 0.0)

for index, i in zip(unique_indices, imean.data):
  sel = (all_indices == index)
  z.set_selected(sel, (iuniq.data - i) / iuniq.sigmas)

h = flex.histogram(z, data_min=-5, data_max=5, n_slots=100)

for c, v in zip(h.slot_centers(), h.slots()):
  print(c, v)



thought it may help the discussion. 

best wishes Graeme


> On 7 Jun 2018, at 11:43, Marcin Wojdyr  wrote:
> 
> On 7 June 2018 at 05:29, graeme.win...@diamond.ac.uk
>  wrote:
>> Dear Kay,
>> 
>> Yes, it’s writing code to be compatible with Python2 and Python3 - in real 
>> life they are largely idiomatically similar, with well documented 
>> differences e.g.
> 
> In other words, it's learning both Python2 and Python3 and using the
> subset of the language that works with both interpreters.
> It's an extra burden and if one is learning Python choosing any of the
> two versions will make it easier.


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] what's the difference between ccp4's coot and a normal coot?

[Murpholino Peligro]

Dear all.
Putting this line
(set-use-stroke-characters 1)
into
~/.coot-preferences/coot.scm
fixes the slowness.

I wonder where's the coot.scm file for ccp4's coot?

Thank you very much.



2018-06-07 1:13 GMT-06:00 Tim Gruene :

> Dear Murpholino,
>
> the slow shifting might be related to your graphics card (sorry if this
> has already been mentioned, I didn't read the entire thread).
>
> #> cat ~/.coot-preferences/coot.scm
> (set-use-stroke-characters 1)
>
> I guess that ccp4 coot set's this in their start-up script. In case you
> use your own coot and do not set this, the shifting can get very slow with
> some graphics cards, in case an atom label is displayed.
>
> Best,
> Tim
>
> On 06/06/2018 08:25 PM, Murpholino Peligro wrote:
>
>> @MW: `bzr checkout bzr+http://oisin.rc-harwell.ac.uk/bzr/series-70/trunk
>>  devtools` gives me
>> bzr: ERROR: Not a branch: "bzr+http://oisin.rc-harwell.a
>> c.uk/bzr/series-70/trunk/ > /bzr/series-70/trunk/>".
>> @PE: I mean graphically and I guess computationally.
>> Check out the videos!!
>> https://drive.google.com/file/d/17va3pKcwZs2w_ONZ5OBJ7OgfOYm
>> gpGhI/view?usp=sharing normal coot
>> https://drive.google.com/file/d/1dkS2tMHfdWedXtPs0LYyOL7TiJ3
>> 6vYlM/view?usp=sharing ccp4's coot
>>
>> 2018-06-06 10:27 GMT-06:00 Marcin Wojdyr > woj...@gmail.com>>:
>>
>> > After installing a few libraries with `sudo dnf whatprovides
>> missinglib` got
>> > coot working. But it does not feel the same as ccp4's coot. It
>> feels a
>> > little bit slow.
>>
>> It's generally the same, but CCP4 applies a few patches to the coot
>> source, uses different compiler and compilation options, different
>> versions of dependencies (as you've seen coot depends on a huge number
>> of third-party libraries), etc.
>>
>> You may try building coot in the same way as it is build by CCP4:
>>
>> first install bzr and then:
>>
>> bzr checkout bzr+http://oisin.rc-harwell.ac.uk/bzr/series-70/trunk
>>  devtools
>> cd devtools
>> export FLAGS="-O3 -fno-strict-aliasing -pipe -mtune=core2"
>> export LDFLAGS="-s -Wl,--build-id=sha1"
>> ./cj build coot
>> misc/linux-rpath.sh ./install
>>
>>
>>
>> 
>>
>> To unsubscribe from the COOT list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1
>>
>>
> --
> --
> Paul Scherrer Institut
> Tim Gruene
> - persoenlich -
> OSUA/204
> CH-5232 Villigen PSI
> phone: +41 (0)56 310 5297
>
> GPG Key ID = A46BEE1A
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Python3 and MTZ

[Rasmus Fogh]

Dear Kay,

Plus there is one Python-3-only feature that is a really big help for 
any large and complex project:
Type annotations lets you specify is a simple way the type of function 
parameters, both for documentation and so that your IDE can flag cases 
where you misuse the parameters.


But of course it does not help if yuo depend on code that is only 
available in Python 2.


Yours,

Rasmus

On 07/06/18 11:43, Marcin Wojdyr wrote:

On 7 June 2018 at 05:29, graeme.win...@diamond.ac.uk
 wrote:

Dear Kay,

Yes, it’s writing code to be compatible with Python2 and Python3 - in real life 
they are largely idiomatically similar, with well documented differences e.g.


In other words, it's learning both Python2 and Python3 and using the
subset of the language that works with both interpreters.
It's an extra burden and if one is learning Python choosing any of the
two versions will make it easier.



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1





--
Rasmus H. Fogh   Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Python3 and MTZ

[Marcin Wojdyr]

On 7 June 2018 at 05:29, graeme.win...@diamond.ac.uk
 wrote:
> Dear Kay,
>
> Yes, it’s writing code to be compatible with Python2 and Python3 - in real 
> life they are largely idiomatically similar, with well documented differences 
> e.g.

In other words, it's learning both Python2 and Python3 and using the
subset of the language that works with both interpreters.
It's an extra burden and if one is learning Python choosing any of the
two versions will make it easier.



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] Copenhagen Bioscience Conference “Protein Signaling - from pathways to networks”

[Nicholas M I Taylor]

Dear all,

I would like to bring to your attention that the abstract submission deadline 
of the Copenhagen Bioscience Conference “Protein Signaling - from pathways to 
networks” is approaching very soon, June 10, 2018.

The conference will take place September 30 – October 4 2018 and might be of 
interest to some of you - Protein structure and function is one of the 
conference topics.

The registration fee, accommodation and local costs for all approved applicants 
are covered by the Novo Nordisk Foundation. Only travel expenses to and from 
the conference venue are at your own expense.

You can find more information and an application link on the website:
http://cph-bioscience.com/en/events/protein-signaling

On behalf of the organizing committee,

Nicholas

Nicholas M. I. Taylor, PhD
Associate Professor

University of Copenhagen
Faculty of Health and Medical Sciences
Novo Nordisk Foundation Center for Protein Research
Blegdamsvej 3B, building 6.1
2200 Copenhagen N
Denmark

TEL +45 35 33 53 37
nicholas.tay...@cpr.ku.dk
http://www.cpr.ku.dk/research/protein-structure-function-program/taylor

[cid:image001.gif@01D3ADA6.1B29D8A0] [cid:image002.png@01D3ADA6.1B29D8A0] 





To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] Register for CONES 2018 (abstract deadline 8 June)

[Lorenz, Chris]

Dear Colleagues,

This is a reminder of the fast approaching international Conference on 
Non-Equilibrium Systems  (CONES 2018) to be held at King's College London, on 
25-27 June.  The abstract submission deadline is 8 June.

For any information about the conference (invited speakers,…) and to register, 
please use the website http://cones2018.com/.

We hope to see you at the conference!

With best wishes,
Alessia Annibale
Joe Bhaseen
Chris Lorenz
Peter Sollich
Jemma Trick

Dr. Chris Lorenz
Reader in Physics
Assistant Director of the EPSRC Centre for Doctoral Training in 
Cross-disciplinary Approaches to Non-Equilibrium Systems (CANES)
Biological Physics & Soft Matter Group
Department of Physics
King's College London
020 7848 2639 (phone)



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1