From A.M.Gimblett at swansea.ac.uk Fri Dec 14 23:32:11 2007 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Fri, 14 Dec 2007 22:32:11 +0000 Subject: [Hets-devel] Problem dealing with diagnostic messages in static analysis Message-ID: <20071214223211.GA18589@cspcag2.swan.ac.uk> Dear Hets developers, I wonder if anyone can help me understand how to collect diagnosis messages during static analysis in hets. I thought I understood it, but now that I've started doing something non-trivial, it's not behaving as I expected. In CspCASL/StatAnaCSP.hs we have the function anaChannel to check a CHANNEL_DECL, which contains a number of channel names and a sort. The bulk of the work is done by the function checkChannelName which, given a (CHANNEL_NAME, SORT) pair and a ChanNameMap (Just a Map from CHANNEL_NAME to SORT), checks if the CHANNEL_NAME is already a key in the map. If it is, and the corresponding value is a _different_ sort, we have an error. If it isn't a key already, then we add the pair. If that key/value pair is already there, we leave the map unchanged. Now, everything's working OK except that I'm not seeing any diagnosis messages! No debug or error messages from this function appear. CspCASL/test/chanClash.cspcasl is an example spec which I would expect to trigger these messages; in particular we should get an error because the channel x is declared twice with different sorts. Unfortunately, running hets (even with -v5) on this file shows no diagnostic messages at all. Furthermore - and this is where it gets weird for me - if we comment out line 93 in StatAnaCSP.hs, which reads: put sig { extendedInfo = ext { chans = newChanMap } } then we _do_ see the diagnosis messages, including debug ones in checkChannelName. We _don't_ see the error (the thing I want to test!) because without that line, we don't update the ChanNameMap in the signature so it's impossible to have multiple channel declarations with clashing sorts. It seems to me that there's some interaction between the State and Result monads which I'm not grasping. Any light which anyone can shed on this would be appreciated. Best regards, -Andy -- Andy Gimblett Computer Science Department Swansea University http://www.cs.swan.ac.uk/~csandy/ From Till.Mossakowski at dfki.de Sat Dec 15 12:31:10 2007 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Sat, 15 Dec 2007 12:31:10 +0100 Subject: [Hets-devel] Problem dealing with diagnostic messages in static analysis In-Reply-To: <20071214223211.GA18589@cspcag2.swan.ac.uk> References: <20071214223211.GA18589@cspcag2.swan.ac.uk> Message-ID: <4763BAFE.7010805@dfki.de> Dear Andy, you have to save the diagnostic messages beforehand and then restore them explicitly when putting a new signature. I have corrected this in CspCASL/StatAnaCSP.hs, and now you get your error. However, I am not happy at all with the current use of the state and result monad in the static analysis. Basically, currently they are used in an ad-hoc intermixed way, where you have always to care about their interaction manually. I think it would be far more elegant to use ResulT in combination with the state monad. I will disucss this with Christian next week. Greetings, Till Andy Gimblett schrieb: > Dear Hets developers, > > I wonder if anyone can help me understand how to collect diagnosis > messages during static analysis in hets. I thought I understood it, > but now that I've started doing something non-trivial, it's not > behaving as I expected. > > In CspCASL/StatAnaCSP.hs we have the function anaChannel to check a > CHANNEL_DECL, which contains a number of channel names and a sort. > > The bulk of the work is done by the function checkChannelName which, > given a (CHANNEL_NAME, SORT) pair and a ChanNameMap (Just a Map from > CHANNEL_NAME to SORT), checks if the CHANNEL_NAME is already a key in > the map. If it is, and the corresponding value is a _different_ sort, > we have an error. If it isn't a key already, then we add the pair. > If that key/value pair is already there, we leave the map unchanged. > > Now, everything's working OK except that I'm not seeing any diagnosis > messages! No debug or error messages from this function appear. > > CspCASL/test/chanClash.cspcasl is an example spec which I would expect > to trigger these messages; in particular we should get an error > because the channel x is declared twice with different sorts. > Unfortunately, running hets (even with -v5) on this file shows no > diagnostic messages at all. > > Furthermore - and this is where it gets weird for me - if we comment > out line 93 in StatAnaCSP.hs, which reads: > > put sig { extendedInfo = ext { chans = newChanMap } } > > then we _do_ see the diagnosis messages, including debug ones in > checkChannelName. We _don't_ see the error (the thing I want to > test!) because without that line, we don't update the ChanNameMap in > the signature so it's impossible to have multiple channel declarations > with clashing sorts. > > It seems to me that there's some interaction between the State and > Result monads which I'm not grasping. Any light which anyone can shed > on this would be appreciated. > > Best regards, > > -Andy > -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From A.M.Gimblett at swansea.ac.uk Sat Dec 15 12:58:10 2007 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Sat, 15 Dec 2007 11:58:10 +0000 Subject: [Hets-devel] Problem dealing with diagnostic messages in static analysis In-Reply-To: <4763BAFE.7010805@dfki.de> References: <20071214223211.GA18589@cspcag2.swan.ac.uk> <4763BAFE.7010805@dfki.de> Message-ID: <20071215115809.GA13358@cspcag2.swan.ac.uk> Dear Till, > you have to save the diagnostic messages beforehand and then > restore them explicitly when putting a new signature. > I have corrected this in CspCASL/StatAnaCSP.hs, and now you > get your error. Ah, superb - thank you. Many thanks - now I will continue (and if it needs refactoring later, so be it.) Thanks again! -Andy -- Andy Gimblett Computer Science Department Swansea University http://www.cs.swan.ac.uk/~csandy/ From A.M.Gimblett at swansea.ac.uk Mon Dec 17 00:47:01 2007 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Sun, 16 Dec 2007 23:47:01 +0000 Subject: [Hets-devel] Autogenerating PosItem instance declarations with drift? Message-ID: <20071216234701.GA10793@cspcag2.swan.ac.uk> Dear Hets developers, Me again... Please can I get some advice on creating PosItem instances. I'd like to make the types declared in CspCASL/AS_CspCASL_Process.hs and CspCASL/AS_CspCASL.hs PosItems so I can include them meaningfully in diagnostic messages. Now, looking at CASL/AS_Basic_CASL.hs, it appears that these can be generated automatically by drift (AS_Basic_CASL.der.hs doesn't contain any PosItem instance declarations, whereas AS_Basic_CASL.hs does) - so I was hoping that drift just does it for you. So I tried: 1. Rename AS_CspCASL_Process.hs to AS_CspCASL_Process.der.hs 2. Add the "{-! global: UpPos !-}" seen in CASL/AS_Basic_CASL.der.hs to AS_CspCSAL_Process.der.hs 3. Add CspCASL/AS_CspCASL_Process.hs to the drifted_files target in the root Makefile. All of which does result in AS_CspCASL_Process.hs being autogenerated by drift - but without, alas, any new content. So, not _quite_ as magic as I was hoping for. :) What am I missing? Thanks! -Andy -- Andy Gimblett Computer Science Department Swansea University http://www.cs.swan.ac.uk/~csandy/ From Christian.Maeder at dfki.de Mon Dec 17 10:51:13 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 17 Dec 2007 10:51:13 +0100 Subject: [Hets-devel] Autogenerating PosItem instance declarations with drift? In-Reply-To: <20071216234701.GA10793@cspcag2.swan.ac.uk> References: <20071216234701.GA10793@cspcag2.swan.ac.uk> Message-ID: <47664691.1020201@dfki.de> Andy Gimblett wrote: > So I tried: > > 1. Rename AS_CspCASL_Process.hs to AS_CspCASL_Process.der.hs > > 2. Add the "{-! global: UpPos !-}" seen in CASL/AS_Basic_CASL.der.hs > to AS_CspCSAL_Process.der.hs > > 3. Add CspCASL/AS_CspCASL_Process.hs to the drifted_files target in > the root Makefile. > > All of which does result in AS_CspCASL_Process.hs being autogenerated > by drift - but without, alas, any new content. That is quite the right procedure! But all your datatypes do not contain any Pos component, so no PosItem instance is generated. A more sophisticated derivation might extract positions from other types, but that is not implemented. Christian From Christian.Maeder at dfki.de Mon Dec 17 11:08:04 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 17 Dec 2007 11:08:04 +0100 Subject: [Hets-devel] Autogenerating PosItem instance declarations with drift? In-Reply-To: <47664691.1020201@dfki.de> References: <20071216234701.GA10793@cspcag2.swan.ac.uk> <47664691.1020201@dfki.de> Message-ID: <47664A84.7070308@dfki.de> Christian Maeder wrote: > That is quite the right procedure! But all your datatypes do not contain > any Pos component, so no PosItem instance is generated. A more In fact, our datatype carrying position information is called "Range". C. From Christian.Maeder at dfki.de Mon Dec 17 11:35:17 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 17 Dec 2007 11:35:17 +0100 Subject: [Hets-devel] Problem dealing with diagnostic messages in static analysis In-Reply-To: <4763BAFE.7010805@dfki.de> References: <20071214223211.GA18589@cspcag2.swan.ac.uk> <4763BAFE.7010805@dfki.de> Message-ID: <476650E5.3080802@dfki.de> Till Mossakowski wrote: > Dear Andy, > > you have to save the diagnostic messages beforehand and then > restore them explicitly when putting a new signature. > I have corrected this in CspCASL/StatAnaCSP.hs, and now you > get your error. The actual problem is the use of separated/distant calls of get and put. It's better to only use these two function within an auxiliary function like updateChanMap. Before "put" you have to make sure to "get" the most recent state (and not an old one). > However, I am not happy at all with the current use of the > state and result monad in the static analysis. Basically, > currently they are used in an ad-hoc intermixed way, where > you have always to care about their interaction manually. The choice of a proper monad is not easy and for CASL I also only use the state monad that does not fail, but only collects all the errors, where many errors may only be consequences of earlier ones. The combination of Result and State to "ResultT (State CspSign)" will always stop after the first error encountered (unless I handle failing results explicitly again). I final remark to CspCASL.StatAnaCSP: ProcVarMap should also be a part of CspProcSign, like CASL variables are stored within signatures during the static analysis. Cheers Christian From Christian.Maeder at dfki.de Mon Dec 17 12:39:40 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 17 Dec 2007 12:39:40 +0100 Subject: [Hets-devel] ghc-6.8.2 Message-ID: <47665FFC.50707@dfki.de> Hallo, I'll switch our default glasgow haskell compiler from ghc-6.8.1 to ghc-6.8.2 under /home/linux-bkb/ All packages for hets (and gtk2hs) are pre-compiled, but do not forget to set a new link to /home/linux-bkb/uni/linux-ghc-6.8.2/uni. An error-message like: ghc-6.8.2: unknown package: base-3.0.0.0 (dependency of uni-davinci-1.1) indicates that the uni link is wrong. Cheers Christian http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html From A.M.Gimblett at swansea.ac.uk Wed Dec 19 14:33:38 2007 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Wed, 19 Dec 2007 13:33:38 +0000 Subject: [Hets-devel] Autogenerating PosItem instance declarations with drift? In-Reply-To: <47664691.1020201@dfki.de> References: <20071216234701.GA10793@cspcag2.swan.ac.uk> <47664691.1020201@dfki.de> Message-ID: <20071219133338.GE21497@cspcag2.swan.ac.uk> On Mon, Dec 17, 2007 at 10:51:13AM +0100, Christian Maeder wrote: > > > > All of which does result in AS_CspCASL_Process.hs being autogenerated > > by drift - but without, alas, any new content. > > That is quite the right procedure! But all your datatypes do not contain > any Pos component, so no PosItem instance is generated. A more > sophisticated derivation might extract positions from other types, but > that is not implemented. Got it - now implemented. Many thanks, -Andy -- Andy Gimblett Computer Science Department Swansea University http://www.cs.swan.ac.uk/~csandy/ From A.M.Gimblett at swansea.ac.uk Wed Dec 19 14:42:07 2007 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Wed, 19 Dec 2007 13:42:07 +0000 Subject: [Hets-devel] Problem dealing with diagnostic messages in static analysis In-Reply-To: <476650E5.3080802@dfki.de> References: <20071214223211.GA18589@cspcag2.swan.ac.uk> <4763BAFE.7010805@dfki.de> <476650E5.3080802@dfki.de> Message-ID: <20071219134207.GF21497@cspcag2.swan.ac.uk> On Mon, Dec 17, 2007 at 11:35:17AM +0100, Christian Maeder wrote: > > I final remark to CspCASL.StatAnaCSP: ProcVarMap should also be a > part of CspProcSign, like CASL variables are stored within > signatures during the static analysis. I don't think so. There is not one ProcVarMap per signature. Rather, there are two ProcVarMaps per process: one containing its so-called "global variables" (ie its arguments, for a parameterised process), and one containing its so-called "local variables" (variables arising "inside" the process as a result of, for example, receiving a communication across a channel). For example, in: P(a) = C?x:s -> SKIP - a is a process-global variable. Its sort is determined by the declaration of P, not shown. Its scope is the entire RHS of the equation. - x is a process-local variable, received across channel C; Its sort is s It is in scope only to the right of that declaration, and can fall out of scope if a "sequential process" is encountered there. As such, these ProcVarMaps don't really "belong to" the signature; they exist, rather, as decorations of the tree of sentences produced by the static analysis. A complication there is that I'm not actually producing any sentences at this stage of development: just performing checks - so right now they're just passed around in support of that. Does that make sense/sound reasonable? -Andy -- Andy Gimblett Computer Science Department Swansea University http://www.cs.swan.ac.uk/~csandy/ From Till.Mossakowski at dfki.de Wed Dec 19 15:20:19 2007 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Wed, 19 Dec 2007 15:20:19 +0100 Subject: [Hets-devel] Problem dealing with diagnostic messages in static analysis In-Reply-To: <20071219134207.GF21497@cspcag2.swan.ac.uk> References: <20071214223211.GA18589@cspcag2.swan.ac.uk> <4763BAFE.7010805@dfki.de> <476650E5.3080802@dfki.de> <20071219134207.GF21497@cspcag2.swan.ac.uk> Message-ID: <476928A3.5090800@dfki.de> Dear Andy, yes, this sound reasonable. ProcVar behave like locally quantified variables. Greetings, Till Andy Gimblett schrieb: > On Mon, Dec 17, 2007 at 11:35:17AM +0100, Christian Maeder wrote: >> I final remark to CspCASL.StatAnaCSP: ProcVarMap should also be a >> part of CspProcSign, like CASL variables are stored within >> signatures during the static analysis. > > I don't think so. There is not one ProcVarMap per signature. Rather, > there are two ProcVarMaps per process: one containing its so-called > "global variables" (ie its arguments, for a parameterised process), > and one containing its so-called "local variables" (variables arising > "inside" the process as a result of, for example, receiving a > communication across a channel). > > For example, in: > > P(a) = C?x:s -> SKIP > > - a is a process-global variable. > Its sort is determined by the declaration of P, not shown. > Its scope is the entire RHS of the equation. > > - x is a process-local variable, received across channel C; > Its sort is s > It is in scope only to the right of that declaration, and can fall > out of scope if a "sequential process" is encountered there. > > As such, these ProcVarMaps don't really "belong to" the signature; > they exist, rather, as decorations of the tree of sentences produced > by the static analysis. A complication there is that I'm not actually > producing any sentences at this stage of development: just performing > checks - so right now they're just passed around in support of that. > > Does that make sense/sound reasonable? > > -Andy > -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313