My question is whether the semantics of () in the declaration of fields had changed in Alloy 4.2.
I read in "Software Abstractions" that
addr: (Book -> Name) -> lone Addr
means that the relation addr associates at most one address with each address book and name pair but this does not hold when running Alloy 4.2
For instance, for
sig Book, Name, Addr {}
sig AddBX {
addr : (Book -> Name) -> lone Addr
}
run XRun {
some B : Book, N : Name, X : AddBX | #X.addr[B][N] = 2
}
Alloy 4.2 finds a model instance which has for instance AddBX$2 with
Book$1 ->Name$0 ->Addr$0
Book$1 ->Name$0 ->Addr$1
Book$1 ->Name$0 ->Addr$2
If I use instead
addr : Book -> Name -> lone Addr
then no instance for the same run is found. This seems to indicate that in Alloy 4.2 this is how to declare that the relation addr associates at most one address with each address book and name pair but I would like to have a confirmation for this.
This is actually a bug in v4.2, the correct behavior is what Alloy4.1.10 implements.
I created a snapshot of v4.2 where this problem is fixed, and you can download it here:
http://alloy.mit.edu/alloy/downloads/alloy4.2_2013-01-28.jar
Thanks for reporting this bug.
Related
I am sorry for the title, I tried hard to make it as understandable as possible but I know I failed.
Here is the simple model:
sig ETHBusStation {
next: set ETHBusStation
}
one sig Polyterrasse, HaldenRight, HaldenLeft, Hoengg extends ETHBusStation {}
sig ETHBus {
station: lone ETHBusStation
}
fact {
//no (Hoengg - HaldenRight)
all s: ETHBusStation | ETHBusStation in s.^next and some s.next
all b1, b2: ETHBus | b1.station != b2.station}
run {} for 2 but 1 ETHBusStation
when I run the analyzer it finds an instance with one of each Polyterrasse, HaldenRight, HaldenLeft, Hoengg
but since these are all disjoint subsets of ETHBusStation, how can this be with the but 1 parameter?
I am expecting it to have a single station that links to itself via next.
I am grateful for any hints and tips.
If we use in instead of extends it behaves as expected, but then they also don't have to be disjoint which makes sense.
I believe the scope declaration is being overridden by the one sig decl. If it didn't do this, the expected behavior would be to find no instances, since the sig decl claims that exactly four bus stations exist, and the scope says that there is at most one bus station.
I cribbed from the hotel door lock example and came up with this MWE for vehicle doors.
enum LockState {Locked, Unlocked}
sig Door {
var state: LockState
}
sig Vehicle {
doors : disj set Door
}
//actions
pred unlock[d: Door]{
d.state' = Unlocked
}
pred lock[d: Door]{
d.state' = Locked
}
//traces
pred init{
all s: Door.state | s = Locked
}
pred trace{
init
always {
some d: Door |
unlock[d] or
lock[d]
}
}
//demonstrate
run {} for 4 but exactly 2 Vehicle, 4 Time
Which to my suprise allows the instance shown below, in which some doors are locked and some not. How do I establish the condition that all doors are locked at the earliest time?
Initial states are defined without any temporal keywords, as you did in init.
The problem is that you defined your trace as a predicate. If you define it as a fact it will always be applied. However, if you make it a predicate (my preference since it feels less global) you must include it from the run command. Pick one:
run trace for 4 but exactly 2 Vehicle, 4 Time
run { trace } for 4 but exactly 2 Vehicle, 4 Time
However, your model will then still not run well.
You provide an always but no goal. So after one state Alloy is happy. You should provide an eventually so Alloy will attempt to continue until it is satisfied.
You allow vehicles without doors, I would use some Door instead of set Door
Your init can be done cleaner like Door.state = Locked
In your trace, each step sets one Door. However, you're not specifying what the state of the other doors should be. If you do not specify a value for the next state, they can become anything. These should be explicitly set to have their old value.
So I came up with the following model:
enum LockState { Locked, Unlocked }
sig Door { var state: LockState }
sig Vehicle { doors : disj some Door }
pred Door.unlock { this.state' = Unlocked }
pred Door.lock { this.state' = Locked }
pred trace {
Door.state = Locked
always (
some d: Vehicle.doors {
(d.unlock or d.lock)
unchanged[state,d]
}
)
eventually Door.state = Unlocked
}
run trace for 4 but exactly 2 Vehicle
pred unchanged[ r : univ->univ, x : set univ ] {
(r - x->univ)' = (r - x->univ)
}
updated Added an unchanged predicate.
I am having errors in Alloy (4.2) specifications of the following kind:
You must specify a scope for sig "this/Univ"
The issue is easy to reproduce with a toy example:
open util/ordering[State]
open util/integer
sig State { value : Int }
fact {
first.value = 0
all s:State, s': s.next | s'.value = plus[s.value, 1]
}
run { } for 5 State, 3 Int
All of the above is fine. Now, when I define State in an external file and import it with an open statement, I get the "Univ scope" error:
open util/ordering[State]
open util/integer
open State
fact {
first.value = 0
all s:State, s': s.next | s'.value = plus[s.value, 1]
}
run { } for 5 State, 3 Int
I tried several variations of the above without success.
Why does this happen and how can it be solved?
In my project, it would be useful for me to define the target sig of the ordering module in a different file.
Thanks,
Eduardo
This is an Alloy "design bug".
It was decided that a Univ signature would appear when no signatures are defined in the module in order to check some property over built-in relations (e.g., unit, iden, none).
You have many ways of going around this problem, here is a selection :
You can add ",0 Univ" at the end of your run command
You can add a signature in your Alloy module
You can specify a global scope of zero (run { } for 0 but 5 State, 3 Int )
See this question for additional informations
I am working with an I2C-Device under Linux and tried to use the device interface like described under folowing Link.
So if we assume following code:
char outbuf[SIZE] = { 'e', 'b' };
struct i2c_rdwr_ioctl_data msgset;
struct i2c_msg msg[1];
msg[0].addr = 0x53; // access address 0x53
msg[0].flags = 0; // 0 means write
msg[0].len = SIZE; // size is already set to two
msg[0].buf = outbuf
msgset.msgs = msg;
msgset.nmsgs = 1;
ioctl( file, I2C_RDWR, &msgset ); // fille is already assigned, etc.
we would write one message containing two bytes to address 0x53!?
Or we could say,
S Addr Wr [A] Data [A] Data [A] P
in the way like its done here.
But when i look at my scope, i get something like this:
or a litle more detailed:
But this is not what we want and not what the specification says,
furthermore we get
S Addr Wr [A] Data P S Addr Wr [A] Data P
Does anyone know this behavior or could describe it to me?
I tried all types of calls IOCTL, SMBUS, write_block_data.
Everytime there is a new Start Condition between data-bytes and the address is also repeated!
Am I getting something wrong?
Thanks for your time and best Regards!
Befedo
I found the misalignment...
my hardware was set up like this:
Notebook -> DP/VGA -> I2C-Slave
I used an Notebook which only got an DisplayPort output, converted this via an DP-to-VGA adapter and used the I2C-Interface where a simple Slave was attached.
And it looks like the DP-to-VGA adapter only could serve with Bytewide-Access to the I2C-Bus, so I set up a 'new' Laptop which has an VGA-Interface integrated and used it directly...
Which lead to an perfectly aligned transfer, like it was expected.
Lets say I do the following:
open util/ordering[A]
open util/ordering[B]
What value does ordering/first have? Is it undefined? Do you need to use module aliases to disambiguate?
Yes, you should use aliases, e.g., like I did below
open util/ordering[A] as orda
open util/ordering[B] as ordb
sig A{}
sig B{}
sig C {
firstA: A,
firstB: B
} {
firstA = orda/first
firstB = ordb/first
}
run {one C}