Miguel wrote:
'connect' seems logical to me because you are setting it to a value that
you explicitly want ... I don't care what it currently is, make it DOUBLE
'increment' seems illogical because you are setting it to one bigger than
it was, even though there is no way to find out what the
Bob Hanson wrote:
Jan, do you know of specific Chime/Rasmol scripts currently in use
that use "bond" in this way?
What if you just replaced
bond 23 45 +
with the following?
select (atomno=23 or atomno=45);connect (selected)
or, maybe:
select (atomno=23 or atomno=45);connect DOUBLE (selecte
>> So, to my 'computer science' way of thinking, it makes no sense to have
>> increment and decrement operations for bond order.
>>
>
> By that logic, in that world, there is no "connect" then, either, right?
'connect' seems logical to me because you are setting it to a value that
you explicitly w
Miguel wrote:
Miguel wrote:
It *might* make sense in a world where one could read and test bond
order,
but it does not make any sense in a 'write-only' scripting world.
What's a "write-only scripting world"?
You cannot read bond orders in the scripting world.
The scripting language d
Jan, do you know of specific Chime/Rasmol scripts currently in use
that use "bond" in this way?
What if you just replaced
bond 23 45 +
with the following?
select (atomno=23 or atomno=45);connect (selected)
or, maybe:
select (atomno=23 or atomno=45);connect DOUBLE (selected)
Would it really
Bob Hanson wrote:
Jan,
1) Certainly INCREMENT (and DECREMENT?) could be implemented, though
it's more involved.
2) Where would you see it being utilized? (where simple SINGLE or
DOUBLE would not suffice?)
Yes, this (0->1->2->3) would be sufficient and only INCREMENT is needed
for script tra
Miguel wrote:
It *might* make sense in a world where one could read and test bond order,
but it does not make any sense in a 'write-only' scripting world.
What's a "write-only scripting world"?
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
> Miguel wrote:
>
>> It *might* make sense in a world where one could read and test bond
>> order,
>> but it does not make any sense in a 'write-only' scripting world.
>>
>
> What's a "write-only scripting world"?
You cannot read bond orders in the scripting world.
The scripting language does not
> Jan,
>
> 1) Certainly INCREMENT (and DECREMENT?) could be implemented, though
> it's more involved.
> 2) Where would you see it being utilized? (where simple SINGLE or DOUBLE
> would not suffice?)
I do not want INCREMENT/DECREMENT added.
I think that it is fundamentally flawed and I see no reas
Jan,
1) Certainly INCREMENT (and DECREMENT?) could be implemented, though
it's more involved.
2) Where would you see it being utilized? (where simple SINGLE or DOUBLE
would not suffice?)
Bob
Jan wrote:
Bob Hanson wrote:
...
I thought about adding "+" or some "INCREMENT" but for the life
De: Jan <[EMAIL PROTECTED]>
>I have problems updating Jmol:
>
>$ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/jmol up -dP
>cannot mkdir /tmp/cvs-serv25069/./CVS
>No space left on device
>
>but there are 9 GB left on device /tmp
>any idea?
>Regards, Jan
Probably no space left on sourceforge server fo
On Wednesday 08 February 2006 08:41, Jan wrote:
> I have problems updating Jmol:
>
> $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/jmol up -dP
> cannot mkdir /tmp/cvs-serv25069/./CVS
> No space left on device
>
> but there are 9 GB left on device /tmp
> any idea?
It's the /tmp on the SF server that
Bob Hanson wrote:
...
I thought about adding "+" or some "INCREMENT" but for the life of me
I can't imagine why you would want to do that --- increment a bond
order without already knowing what it is. We can talk about that later.
$RasMol2Jmol=~s/bond (\d+) (\d+) \+/select atomno=$1; connect
> Miguel, I'd like to commit this tonight and move on. It's really a
> very simple commit.
Go ahead and commit your changes.
> Leaves bondorder so that IF you like the 00.48
> funtionality, you can certainly still have it (I do, and would like to
> still have it). Removes nothing; completely con
Miguel, I'd like to commit this tonight and move on. It's really a
very simple commit. Leaves bondorder so that IF you like the 00.48
funtionality, you can certainly still have it (I do, and would like to
still have it). Removes nothing; completely consistent with 00.48
select/connect; only add
Miguel wrote:
We can talk about that later.
The current-but-soon-to-be-history mode of
connect DOUBLE
which DOES depend upon BONDMODE will continue in the form of
bondorder 2
for those who like that idea.
No, we are going to delete the 'bondorder' command.
I'd like to leave it. It DO
> The loud silence of discussion re connect suggests that I can go ahead
> and implement my option -- which defaults to the same as current
> behavior for
Well it might mean that the two of us should now talk about it :-)
> select (atom set)
> connect (target atom set)
>
> but doesn't depend up
17 matches
Mail list logo