You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(14) |
Jul
(5) |
Aug
(9) |
Sep
(7) |
Oct
(4) |
Nov
(3) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(4) |
Feb
(1) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David B. <dav...@ya...> - 2015-01-01 20:48:28
|
To All,, I was wondering if anyone would be interested in helping me start a kick-starter project to develop a user friendly on-line course for development verification, and validation for use with the Event-B proof system ??? Would anyone be interested in helping me ??? Thanks, David Blubaugh Electrical Engineer ATR, llc |
From: Michael J. <mi...@ja...> - 2012-04-04 10:22:32
|
Dear all, We just put the finishing touches on the Rodin Handbook and processed some last-minute feedback, and now declare the project officially complete. The result can still be found at http://handbook.event-b.org/ We hope that you are happy with the result, and that it will benefit new and experienced Rodin-users alike. The future of the handbook The sources of the handbook and instructions on how to build it reside in the Rodin Subversion, hosted on SourceForge. Everybody is invited to help maintaining it. Don't forget that plugin authors can contribute special sections to present their work in the context of the handbook. The handbook is currently built by Düsseldorf's Jenkins server, and we will continue to do this. This means that changes to the Latex in Subversion will appear after a few minutes on the handbook site. We hope that this further encourages uses to edit the handbook (without having to create a special setup on their computers). Official releases, like this one, are tagged and offered on the update site (for Rodin integration). And last, I'd like to thank everybody involved in the project for their hard work. Best wishes, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2012-03-25 19:18:48
|
Dear all, Just a reminder that we plan on completing the handbook project by Friday (3/30). So far, we only got one minor issue from Alexei, which we will incorporate. I hope that the silence means that everybody is happy with the result. Best wishes, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Aryldo G R. Jr <ag...@ae...> - 2012-03-19 14:49:19
|
Michael, congratulations!!!!!! This handbook is very good!!!! it's a real big step on helping RODIN usage!!!! cheers Dinho Aryldo G Russo Jr Diretor de Pesquisa, Desenvolvimento e Inovação Grupo AeS ASQ/CRE - ASQ/CSSBB On 18/03/2012, at 14:10, Michael Jastram wrote: > Dear all, > > We are excited to announce the completion of the forth and last > iteration on the Rodin handbook. The focus of this iteration was > polishing and processing of feedback. You can find the result at > > http://handbook.event-b.org > > We processed all 123 feedback items that we received through the > feedback form. In addition, we analyzed the results from the user > study, a group of students who went through a B seminar (not Event-B), > who had to complete a project in Event-B. > > All this resulted in a large amount of polishing, as well as some > significant rewriting. In particular, we rewrote Chapters 2.9 and 2.10 > from the tutorial and had a student work through these chapters to > confirm that they were clear. > > The reference section still had some gaps at the end of the previous > iteration, and these have been filled. > > In addition to another editorial review of the complete handbook, we > authored more text to hold the handbook together. This also includes a > foreword by Michael Butler and a preface, as well as some artwork for > the PDF-Cover and the HTML entry page. > > The handbook is now part of the Rodin distribution. This means that the > complete handbook is available for offline use through the Eclipse Help > system. Once the iteration review is over, we will publish another > update, so that existing Rodin 2.4 installations can update their > handbook (automatically through the Eclipse update mechanism). > > We will now enter a two-week review phase until the end of March. We > encourage you to take advantage of this time. You can either use the > feedback form (the link is now less prominent), via email or by > discussing on the mailing list. > > We are proud of what we produced with the available resources, and we > hope that you are happy with the outcome. > > Best regards, > > - Michael > > -- > Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) > Geschäftsführer, Formal Mind GmbH (http://formalmind.com) > Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) > 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Rodin-b-sharp-user mailing list > Rod...@li... > https://lists.sourceforge.net/lists/listinfo/rodin-b-sharp-user |
From: Michael J. <mi...@ja...> - 2012-03-18 17:10:13
|
Dear all, We are excited to announce the completion of the forth and last iteration on the Rodin handbook. The focus of this iteration was polishing and processing of feedback. You can find the result at http://handbook.event-b.org We processed all 123 feedback items that we received through the feedback form. In addition, we analyzed the results from the user study, a group of students who went through a B seminar (not Event-B), who had to complete a project in Event-B. All this resulted in a large amount of polishing, as well as some significant rewriting. In particular, we rewrote Chapters 2.9 and 2.10 from the tutorial and had a student work through these chapters to confirm that they were clear. The reference section still had some gaps at the end of the previous iteration, and these have been filled. In addition to another editorial review of the complete handbook, we authored more text to hold the handbook together. This also includes a foreword by Michael Butler and a preface, as well as some artwork for the PDF-Cover and the HTML entry page. The handbook is now part of the Rodin distribution. This means that the complete handbook is available for offline use through the Eclipse Help system. Once the iteration review is over, we will publish another update, so that existing Rodin 2.4 installations can update their handbook (automatically through the Eclipse update mechanism). We will now enter a two-week review phase until the end of March. We encourage you to take advantage of this time. You can either use the feedback form (the link is now less prominent), via email or by discussing on the mailing list. We are proud of what we produced with the available resources, and we hope that you are happy with the outcome. Best regards, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2012-03-12 09:13:08
|
Dear all, This is just a quick reminder that we are close to finishing up the handbook project [1]. We will spend this week with some final touch-ups and will then start next week (March 19th) with the final review. We encourage you to use this week to file any issues that you are currently aware of through our feedback form [2]. Of course we will also incorporate any feedback that we might get during the official review, but the sooner we know the better. And last, we will not produce a print edition of the handbook, there is just not enough interest. We are delighted to hear that several respondents to our review considered the handbook useful for teaching, but students in particular would prefer a free online version over a paid-for printed one. Best wishes, - Michael [1] http://handbook.event-b.org/ [2] https://spreadsheets.google.com/spreadsheet/viewform?formkey=dEJmXzUydnRzZGdDVE16WFZmZmd1alE6MQ -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2012-02-15 09:22:01
|
Dear all, Would you buy a print copy of the Rodin Handbook? Please tell us via [1]. You may be aware that the Rodin Handbook project [2] is soon coming to an end. Currently, is is only available digitally. If there is enough interest, we could also make the handbook available via a print-on-demand service (probably Amazon). But we would only do this if there is enough demand. We are kindly asking you to answer a short questionnaire (1 mandatory and 3 optional questions) to help us estimate demand [1]. Thank you for taking your time! Best wishes, - The Rodin Handbook Team [1] http://kwiksurveys.com?s=LJDEOJ_58d45059 [2] http://handbook.event-b.org/ -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Lukas L. <luk...@gm...> - 2012-01-18 08:15:44
|
Hi Nicolas and Michael, Am 17.01.2012 19:29, schrieb Nicolas Beauger: > Hi Michael, > >> Thanks for the build - I just checked the handbook, and things look fine >> (except the index - but that's my problem, not yours. :-)). We now >> started to incorporate the changes since 2.3 into the handbook, >> especially regarding the editor. A Michael already mentioned, we started to incorporate the changes into the handbook regarding the new editor. As a consequence, I already marked (with marginpars) places which we have to adapt. >> Our plan is to put a new version on >> the update site on January 25th. Is that sufficient time to include it >> into the final 2.4 release? > Yes, if it's on the update site on February 1st it's OK for integrating > in the final 2.4 release. Ok I will put a new version on the update site on January 25th. >> Also, I noticed that the old handbook (wiki pages) is still included. >> Considering that all the information has been migrated, can we remove >> it? I think it will just confuse users to see two handbooks in the help >> browser. > Yes indeed, we will remove the older one. > > Cheers, > Nicolas >> On 01/17/2012 10:52 AM, Nicolas Beauger wrote: >>> Dear plug-in developers, >>> >>> Rodin 2.4RC1 is now available on sourceforge. It includes a few new >>> features and is based on Eclipse 3.7.1. >>> More details at: >>> >>> http://wiki.event-b.org/index.php/Rodin_Platform_2.4_Release_Notes >>> >>> The code freeze is from now until Monday 30th, date of the final 2.4 >>> release (public announce on February 1st). >>> >>> Please take time to complete the plug-in availability page: >>> >>> http://wiki.event-b.org/index.php?title=Rodin_Platform_2.4_External_Plug-ins >>> >>> The binary distribution on SF is at: >>> >>> http://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/2.4RC1 >>> >>> As you will probably notice, we also made 64 bit binaries for Windows >>> and Linux. This does not however means that we decided to release Rodin >>> 64 bit for these OSes, it is there more as a proposition. >>> The decision as to whether we should provide these 64 bit binaries has >>> to be taken collectively, as it would also involve more work for every >>> plug-in: >>> * generating - in particular, plug-ins that embed binary executables >>> would have to be able to provide 64 bit versions of these embedded binaries >>> * validating >>> * maintaining (with probably more platform specific bugs) >>> >>> We have already been discussing this subject in the past on the user >>> mailing list, and rejected the idea because of the extra work and the >>> lack of resources. But as time goes by, 64-bit OSes are more and more >>> widely used (as shown by the recurrence of the subject in the user list >>> discussions) and Rodin would take advantage of these releases, being >>> more easily usable and by more people. So it might be worth giving it a >>> try and see if it's nonetheless workable. >>> >>> So the code freeze time could be a test phase for 64-bit binaries, where >>> everyone tries to generate his plug-ins for all 5 platforms. In the end >>> we could make a decision as to whether or not to include them in the >>> final 2.4 release and further releases. >>> >>> Kind regards, >>> Nicolas >>> |
From: Nicolas B. <nic...@sy...> - 2012-01-17 18:29:26
|
Hi Michael, > Thanks for the build - I just checked the handbook, and things look fine > (except the index - but that's my problem, not yours. :-)). We now > started to incorporate the changes since 2.3 into the handbook, > especially regarding the editor. Our plan is to put a new version on > the update site on January 25th. Is that sufficient time to include it > into the final 2.4 release? Yes, if it's on the update site on February 1st it's OK for integrating in the final 2.4 release. > Also, I noticed that the old handbook (wiki pages) is still included. > Considering that all the information has been migrated, can we remove > it? I think it will just confuse users to see two handbooks in the help > browser. Yes indeed, we will remove the older one. Cheers, Nicolas > On 01/17/2012 10:52 AM, Nicolas Beauger wrote: >> Dear plug-in developers, >> >> Rodin 2.4RC1 is now available on sourceforge. It includes a few new >> features and is based on Eclipse 3.7.1. >> More details at: >> >> http://wiki.event-b.org/index.php/Rodin_Platform_2.4_Release_Notes >> >> The code freeze is from now until Monday 30th, date of the final 2.4 >> release (public announce on February 1st). >> >> Please take time to complete the plug-in availability page: >> >> http://wiki.event-b.org/index.php?title=Rodin_Platform_2.4_External_Plug-ins >> >> The binary distribution on SF is at: >> >> http://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/2.4RC1 >> >> As you will probably notice, we also made 64 bit binaries for Windows >> and Linux. This does not however means that we decided to release Rodin >> 64 bit for these OSes, it is there more as a proposition. >> The decision as to whether we should provide these 64 bit binaries has >> to be taken collectively, as it would also involve more work for every >> plug-in: >> * generating - in particular, plug-ins that embed binary executables >> would have to be able to provide 64 bit versions of these embedded binaries >> * validating >> * maintaining (with probably more platform specific bugs) >> >> We have already been discussing this subject in the past on the user >> mailing list, and rejected the idea because of the extra work and the >> lack of resources. But as time goes by, 64-bit OSes are more and more >> widely used (as shown by the recurrence of the subject in the user list >> discussions) and Rodin would take advantage of these releases, being >> more easily usable and by more people. So it might be worth giving it a >> try and see if it's nonetheless workable. >> >> So the code freeze time could be a test phase for 64-bit binaries, where >> everyone tries to generate his plug-ins for all 5 platforms. In the end >> we could make a decision as to whether or not to include them in the >> final 2.4 release and further releases. >> >> Kind regards, >> Nicolas >> > -- ------------------------------------------------------------------------ Nicolas BEAUGER Tél. : (+33)(0)4 42 90 65 66 Ingénieur Logiciel SYSTEREL ------------------------------------------------------------------------ Standard / Fax : (+33)(0)4 42 90 41 20 / 29 site : www.systerel.fr ------------------------------------------------------------------------ |
From: Michael J. <mi...@ja...> - 2012-01-17 15:48:50
|
Hi Nicolas, Thanks for the build - I just checked the handbook, and things look fine (except the index - but that's my problem, not yours. :-)). We now started to incorporate the changes since 2.3 into the handbook, especially regarding the editor. Our plan is to put a new version on the update site on January 25th. Is that sufficient time to include it into the final 2.4 release? Also, I noticed that the old handbook (wiki pages) is still included. Considering that all the information has been migrated, can we remove it? I think it will just confuse users to see two handbooks in the help browser. Best, - Michael On 01/17/2012 10:52 AM, Nicolas Beauger wrote: > Dear plug-in developers, > > Rodin 2.4RC1 is now available on sourceforge. It includes a few new > features and is based on Eclipse 3.7.1. > More details at: > > http://wiki.event-b.org/index.php/Rodin_Platform_2.4_Release_Notes > > The code freeze is from now until Monday 30th, date of the final 2.4 > release (public announce on February 1st). > > Please take time to complete the plug-in availability page: > > http://wiki.event-b.org/index.php?title=Rodin_Platform_2.4_External_Plug-ins > > The binary distribution on SF is at: > > http://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/2.4RC1 > > As you will probably notice, we also made 64 bit binaries for Windows > and Linux. This does not however means that we decided to release Rodin > 64 bit for these OSes, it is there more as a proposition. > The decision as to whether we should provide these 64 bit binaries has > to be taken collectively, as it would also involve more work for every > plug-in: > * generating - in particular, plug-ins that embed binary executables > would have to be able to provide 64 bit versions of these embedded binaries > * validating > * maintaining (with probably more platform specific bugs) > > We have already been discussing this subject in the past on the user > mailing list, and rejected the idea because of the extra work and the > lack of resources. But as time goes by, 64-bit OSes are more and more > widely used (as shown by the recurrence of the subject in the user list > discussions) and Rodin would take advantage of these releases, being > more easily usable and by more people. So it might be worth giving it a > try and see if it's nonetheless workable. > > So the code freeze time could be a test phase for 64-bit binaries, where > everyone tries to generate his plug-ins for all 5 platforms. In the end > we could make a decision as to whether or not to include them in the > final 2.4 release and further releases. > > Kind regards, > Nicolas > -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2012-01-04 09:14:18
|
Dear all, I hope you all had a nice holiday season, and I wish you a successful 2012. We got very little feedback during the last iteration review - I hope that this means that everybody is happy with the progress so far and with the work plan for the fourth and last iteration. Here is the link to the DoW: http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW#Forth_Iteration We will no start implementing it. If you have any comments or suggestions, please feel free to discuss it here on the list. Best regards, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2011-12-21 09:35:09
|
Dear all, This is just a friendly reminder that we are currently in the review phase of the third iteration of the Rodin Handbook project. You still have time until January 2nd to provide feedback that will influence the work packages of the fourth iteration. So... if you are still looking for inspiring reading material for the holiday season, grab yourself a copy of the Handbook (okay, just kidding). Happy holidays, and best wishes from the Rodin Handbook team, - Michael On 12/08/2011 01:53 PM, Michael Jastram wrote: > Dear all, > > We just finished the third iteration (out of four) on the handbook and > would like to invite you to the review. As we usually allocate two > weeks for the iteration review, and as the holidays are coming up, we > will have a slightly longer review period. We will begin with the > forth and last iteration on January 2nd. However, we would really > appreciate feedback sooner, to allow us to react to your comments. So > please respond before the holidays (and please respond to the handbook > mailing list for discussion). > > You can access our work so far at handbook.event-b.org > <http://handbook.event-b.org>. Note that we will continue to work on > the handbook during the review phase. Therefore, you will find two > versions on that page: A "frozen" version for the review, and the > latest build. For the review, please make sure that you access the > frozen build. > > The third iteration consists of six work packages > <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW>, which > are documented on the Rodin Wiki. Links to all deliverables can be > found on that page. They are: > > * WP3-1: Completion of the Reference Section > * WP3-2: User Tests of Tutorial > * WP3-3: Completion of the Tutorial > * WP3-4: Provide context to give the documentation a whole appearance > * WP3-5: Remove migrated content from Wiki > * WP3-6: Creation of an index > * WP3-7: Iteration Review > > > User Feedback > > So far, we got 98 pieces of feedback, most of them through the > feedback form. We also received feedback via email and the survey > form, and we transcribed those issues to the form, so that we had one > single repository to work from. All but 4 entries got resolved (the > remaining ones will be dealt with in the next iteration). > > In addition, we ran a survey that was specifically targeted at > students taking a B block course in Düsseldorf. These students > learned for a week about B (but not Event-B, and not Rodin). They > then had to complete an assignment in Event-B, with the handbook > provided as the reference text. Five Students completed the > assignment. We distributed the survey on the Rodin and Deploy mailing > lists as well, and we received seven responses in total. Here is the > Survey Result > <http://handbook.event-b.org/review-3/2011_12_08_Handbook_Survey.pdf>. The > main take-aways are: > > * The "General impression" of the handbook received 4.0 out of 5 > (Question 6). Readers were very happy with the structure (4.6) > and the text style (4.9). We believe that especially the last is > due to the terrific work of Joy Clark, our native speaking > technical editor. In this category, we scored worst on > "Helpfulness" (3.5). We interviewed the students to find out how > we could improve this (see below). > * Six users rated the tutorial, three the reference, and only one > the FAQ. We were surprised how little the reference was used. > * The tutorial got the worst rating on completeness (3.3), which we > found surprising, as the tutorial wasn't meant to be complete > (that's what the reference section is for). More pointers to the > reference section may be useful to remedy this (see WP4-3 below). > Users found the chapter well-structured (4.2) and easy to find > information (4.0). Once again, text style was leading with 4.7. > * The reference section was considered fairly complete (4.0) and > helpful (4.0), while structure (4.7) and completeness (4.7) got > even better grades. The reference section got only 4 and 5 star > ratings in all categories! > * With only one response, we don't consider the feedback on the FAQ > representative. Answers vary between completeness (2) and text > style (5), and all answers average to 3.5. > * The HTML-Version of the handbook got the best grade (4.2) and was > used by the most people (6). Four users used the PDF version and > rated it at 3.5. Only one person rated the Eclipse Help version > (3.0). > > Overall, we were content with the result, considering the resources > that we had available. From the survey we already had a few ideas on > how to improve things. We had additional discussions with the > students to hear their thoughts, and to align them with our proposed > improvements. We got two main criticisms: > > * The last two chapters of the tutorial came "out of the blue" and > didn't provide enough guidance. This was understandable, as the > first chapters were written from scratch for the tutorial, while > the last two (celebrity and location access controller) were > ported from the Wiki. We already started to build them up, and > will continue to do so in the forth iteration. > * As novices, the students spent most of their time with the > tutorial, while they used the reference relatively little or not > at all. We will address this issue by providing more pointers > from the tutorial to the reference section. > > > Next Steps > > Based on this, and based on the tasks in our backlog, we propose the > following tasks for the fourth and last iteration. These are > documented with additional detail > <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW#Forth_Iteration> > on the wiki: > > * WP4-1: Improve Tutorial Chapters 2.9 and 2.10 > * WP4-2: Completion of the Reference Section > * WP4-3: References and "Further Reading" Sections in Tutorial > * WP4-4: Coordination with Systerel to make the Rodin Handbook part > of the Distribution > * WP4-5: Polishing > * WP4-6: Final Review > > What you see here is the work of Lukas Ladenberger, Daniel Plagge and > Joy Clark, who all did a terrific job, and myself. > > We encourage you once more to provide your feedback now, as we are > about to start the final iteration on this project. > > Best, > > - Michael > > -- > Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) > Geschäftsführer, Formal Mind GmbH (http://formalmind.com) > Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) > 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) > -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Matthias S. <Mat...@in...> - 2011-12-08 13:34:35
|
Hi Daniel, > Hello Matthias, > > On 28.11.2011 14:12, Matthias Schmalz wrote: >> Hi Michael, >> >> Here is some feedback on the Rodin handbook. >> >> 1) Actually I have already used the email feedback feature. I asked for >> a confirmation that my feedback has been received, but I never got a >> confirmation. Apparently, there is a problem with the email feedback. > we have received several feedback messages from you. The feedback is > collected in a spreadsheet first and not all messages are attended to > yet. I'm sorry if you might had the impression that we do not read the > feedback. Thanks for explaining. Apparently, the problem was on my side. > First, thank you for your feedback. This is exactly the kind of feedback > I hoped for because I'm a little bit unsure regarding some topics of the > reference section. I still have some questions about what you said about > section 3: > >> 2) Proving / Provers: [...] >> 3) On Mathematical Notation / Sets: >> >> I have some feedback on how you introduce the various operators. >> I focus on the example of subset (\subseteq), but it applies to other >> definitions as well. Here is the "definition": >> >> S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T >> >> There is some room for interpretation what this actually means; here is >> what I understood: >> - It is not entirely clear whether S and T range over only well-defined >> or also over ill-defined values. I assume the latter. For, otherwise the >> statement L(S \box T) \triangleq L(S) \land L(T) would be pointless. > > My intention was this: Under the assumption that the predicate is > well-defined (as defined by the statement > "L(S \ T)<: L(S)& L(T)"), "S<: T" is logically equivalent to "!e. > e:S => e:T". > I think in this context "L(S<:T) == L(S)& L(T)" is not pointless, > because it just defines under which conditions the equivalence holds. My question is whether S and T may be ill-defined. Is this the case? Also, your intention is not obvious from what you have written. Maybe you should write "L(A) => (A \triangleq B)" instead of "A \triangleq B" >> - Then it is not entirely clear what the \triangleq means. A logic of >> partial functions has many notions of equality. I assume that A >> \triangleq B means that A is true/false/ill-defined iff B is >> true/false/ill-defined, respectively. This emphasizes that the left- and >> right-hand side of a definition are interchangeable. > I agree with you here. There is currently no definition of the operator > in the handbook yet. My understanding is that A \triangleeq B means A is > true/false iff B is true/false. There is a syntactical difference between mine and your definition of \triangleeq. ("true/false/ill-defined" vs. "true/false") On a closer look, they have the same semantics. I take that as a confirmation for my definition. > As said above, the ill-defined case is > ruled-out by the WD-condition. See above. >> With this in mind, I spotted some problems: >> >> - Did you introduce "\in"? I could not find it. I admit, it is not >> possible to define "\in". But maybe you should say at some point what >> you take as granted and what you define on your own. That prevents >> readers from searching for definitions that do not exist. > Yes, \in is defined in 3.3.2. Somewhat arbitrary, maybe it fits better > into the sets section. Okay. I have overlooked it. >> - The left- and right-hand side are actually not interchangeable. For, >> if S is the empty set and T ill-defined, then the lhs is ill-defined and >> the rhs is true. >> One may go one step further: the two equalities >> S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T >> and >> L(S \box T) \triangleq L(S) \land L(T) >> imply >> L(\forall e\qdot e \in S \limp e \in T) \triangleq L(S) \land L(T), >> which is certainly not the case. > But is this still the case if we assume S and T as well-defined? Or am I > too naive here? You are right (and not too naive). If you assume that S and T are well-defined, the problem with L(\forall e\qdot e \in S \limp e \in T) \triangleq L(S) \land L(T) disappears (both sides are true). >> - Actually you have two kinds of variables and two kinds of equalities >> in the handbook. This makes it difficult to infer what is actually >> meant. I would make the difference between the two kinds of variables >> syntactically visible, and explain the semantical difference between the >> two kinds of variables/equalities up front. > With two kinds of variables you mean > a) a variable as a placeholder for an arbitrary expression and > b) an Event-B identifier? Yes. > I'm not sure what you do mean by the second equality? Do you mean > statements like: "S \/ T = { x | x:S or x:T }"? > In that case, does that really leads to any confusion? The two equalities are "=" and "\triangleq". I see two sources of confusion: - It is not explained what "\triangleq" means. - In some definitions, \triangleq is used; in others, it is "=". >> I believe that almost every reader of the handbook has already seen the >> subset relation and will find the equation >> S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T >> rather obvious. So he will not learn anything from reading this >> definition. Instead of emphasizing what the reader already knows, the >> handbook should point out how Event-B's operators deviate from the >> reader's intuition. > I do not agree fully here. For most (if not all) it is obvious. But > where do we draw the line? Using prose everywhere just to avoid a formal > notion would make the reference much more clumsy to read. First off, I do not suggest to kick out the definition of \subseteq or to avoid formal notation altogether. Currently, it is rather clear that \subseteq is somehow the subset relation. The details on well-definedness are currently rather implicit, and on a closer look also contradictory. >> 4) Some miscellaneous comments: >> >> In Section 3.3 you refer to the Z reference manual. There was never an >> agreement how partial functions are handled in Z. I would therefore not >> try to understand Event-B from the Z reference manual. > I agree. But the note is a reference for handbook writers as an example > for a handbook for a mathematical notion, not for Z's foundations. The > note will be removed before the final release. Good. The overall problem remains: - You have to clarify whether your variables range over well-defined values or over arbitrary values. In my thesis, I need two kinds of variables: well-defined variables x, y, z, and operator variables $x, $y, $z that range over arbitrary values. - You have to clarify the definition of "\triangleq". Under the current definition "$A <: $B \triangleq ! x. x : $A => x : $B" is invalid. I see two ways out: -- Use ordinary variables, i.e., "A <: B \triangleq ! x. x : A => x : B" -- Use \sqsubseteq instead of \triangleq, where "$P \sqsubseteq $Q" iff "L($P) => ($P \triangleq $Q)". The definition is then: "$A <: $B \sqsubseteq !x. x : $A => x : $B" Good luck, Matthias |
From: Michael J. <mi...@ja...> - 2011-12-08 12:53:49
|
Dear all, We just finished the second iteration (out of four) on the handbook and would like to invite you to the review. As we usually allocate two weeks for the iteration review, and as the holidays are coming up, we will have a slightly longer review period. We will begin with the forth and last iteration on January 2nd. However, we would really appreciate feedback sooner, to allow us to react to your comments. So please respond before the holidays (and please respond to the handbook mailing list for discussion). You can access our work so far at handbook.event-b.org <http://handbook.event-b.org>. Note that we will continue to work on the handbook during the review phase. Therefore, you will find two versions on that page: A "frozen" version for the review, and the latest build. For the review, please make sure that you access the frozen build. The third iteration consists of six work packages <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW>, which are documented on the Rodin Wiki. Links to all deliverables can be found on that page. They are: * WP3-1: Completion of the Reference Section * WP3-2: User Tests of Tutorial * WP3-3: Completion of the Tutorial * WP3-4: Provide context to give the documentation a whole appearance * WP3-5: Remove migrated content from Wiki * WP3-6: Creation of an index * WP3-7: Iteration Review User Feedback So far, we got 98 pieces of feedback, most of them through the feedback form. We also received feedback via email and the survey form, and we transcribed those issues to the form, so that we had one single repository to work from. All but 4 entries got resolved (the remaining ones will be dealt with in the next iteration). In addition, we ran a survey that was specifically targeted at students taking a B block course in Düsseldorf. These students learned for a week about B (but not Event-B, and not Rodin). They then had to complete an assignment in Event-B, with the handbook provided as the reference text. Five Students completed the assignment. We distributed the survey on the Rodin and Deploy mailing lists as well, and we received seven responses in total. Here is the Survey Result <http://handbook.event-b.org/review-3/2011_12_08_Handbook_Survey.pdf>. The main take-aways are: * The "General impression" of the handbook received 4.0 out of 5 (Question 6). Readers were very happy with the structure (4.6) and the text style (4.9). We believe that especially the last is due to the terrific work of Joy Clark, our native speaking technical editor. In this category, we scored worst on "Helpfulness" (3.5). We interviewed the students to find out how we could improve this (see below). * Six users rated the tutorial, three the reference, and only one the FAQ. We were surprised how little the reference was used. * The tutorial got the worst rating on completeness (3.3), which we found surprising, as the tutorial wasn't meant to be complete (that's what the reference section is for). More pointers to the reference section may be useful to remedy this (see WP4-3 below). Users found the chapter well-structured (4.2) and easy to find information (4.0). Once again, text style was leading with 4.7. * The reference section was considered fairly complete (4.0) and helpful (4.0), while structure (4.7) and completeness (4.7) got even better grades. The reference section got only 4 and 5 star ratings in all categories! * With only one response, we don't consider the feedback on the FAQ representative. Answers vary between completeness (2) and text style (5), and all answers average to 3.5. * The HTML-Version of the handbook got the best grade (4.2) and was used by the most people (6). Four users used the PDF version and rated it at 3.5. Only one person rated the Eclipse Help version (3.0). Overall, we were content with the result, considering the resources that we had available. From the survey we already had a few ideas on how to improve things. We had additional discussions with the students to hear their thoughts, and to align them with our proposed improvements. We got two main criticisms: * The last two chapters of the tutorial came "out of the blue" and didn't provide enough guidance. This was understandable, as the first chapters were written from scratch for the tutorial, while the last two (celebrity and location access controller) were ported from the Wiki. We already started to build them up, and will continue to do so in the forth iteration. * As novices, the students spent most of their time with the tutorial, while they used the reference relatively little or not at all. We will address this issue by providing more pointers from the tutorial to the reference section. Next Steps Based on this, and based on the tasks in our backlog, we propose the following tasks for the fourth and last iteration. These are documented with additional detail <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW#Forth_Iteration> on the wiki: * WP4-1: Improve Tutorial Chapters 2.9 and 2.10 * WP4-2: Completion of the Reference Section * WP4-3: References and "Further Reading" Sections in Tutorial * WP4-4: Coordination with Systerel to make the Rodin Handbook part of the Distribution * WP4-5: Polishing * WP4-6: Final Review What you see here is the work of Lukas Ladenberger, Daniel Plagge and Joy Clark, who all did a terrific job, and myself. We encourage you once more to provide your feedback now, as we are about to start the final iteration on this project. Best, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Daniel P. <pl...@cs...> - 2011-11-28 14:40:39
|
Hello Matthias, On 28.11.2011 14:12, Matthias Schmalz wrote: > Hi Michael, > > Here is some feedback on the Rodin handbook. > > 1) Actually I have already used the email feedback feature. I asked for > a confirmation that my feedback has been received, but I never got a > confirmation. Apparently, there is a problem with the email feedback. we have received several feedback messages from you. The feedback is collected in a spreadsheet first and not all messages are attended to yet. I'm sorry if you might had the impression that we do not read the feedback. First, thank you for your feedback. This is exactly the kind of feedback I hoped for because I'm a little bit unsure regarding some topics of the reference section. I still have some questions about what you said about section 3: > 2) Proving / Provers: [...] > 3) On Mathematical Notation / Sets: > > I have some feedback on how you introduce the various operators. > I focus on the example of subset (\subseteq), but it applies to other > definitions as well. Here is the "definition": > > S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T > > There is some room for interpretation what this actually means; here is > what I understood: > - It is not entirely clear whether S and T range over only well-defined > or also over ill-defined values. I assume the latter. For, otherwise the > statement L(S \box T) \triangleq L(S) \land L(T) would be pointless. My intention was this: Under the assumption that the predicate is well-defined (as defined by the statement "L(S \ T) <: L(S) & L(T)"), "S <: T" is logically equivalent to "!e. e:S => e:T". I think in this context "L(S<:T) == L(S) & L(T)" is not pointless, because it just defines under which conditions the equivalence holds. > - Then it is not entirely clear what the \triangleq means. A logic of > partial functions has many notions of equality. I assume that A > \triangleq B means that A is true/false/ill-defined iff B is > true/false/ill-defined, respectively. This emphasizes that the left- and > right-hand side of a definition are interchangeable. I agree with you here. There is currently no definition of the operator in the handbook yet. My understanding is that A \triangleeq B means A is true/false iff B is true/false. As said above, the ill-defined case is ruled-out by the WD-condition. > With this in mind, I spotted some problems: > > - Did you introduce "\in"? I could not find it. I admit, it is not > possible to define "\in". But maybe you should say at some point what > you take as granted and what you define on your own. That prevents > readers from searching for definitions that do not exist. Yes, \in is defined in 3.3.2. Somewhat arbitrary, maybe it fits better into the sets section. > - The left- and right-hand side are actually not interchangeable. For, > if S is the empty set and T ill-defined, then the lhs is ill-defined and > the rhs is true. > One may go one step further: the two equalities > S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T > and > L(S \box T) \triangleq L(S) \land L(T) > imply > L(\forall e\qdot e \in S \limp e \in T) \triangleq L(S) \land L(T), > which is certainly not the case. But is this still the case if we assume S and T as well-defined? Or am I too naive here? > - Actually you have two kinds of variables and two kinds of equalities > in the handbook. This makes it difficult to infer what is actually > meant. I would make the difference between the two kinds of variables > syntactically visible, and explain the semantical difference between the > two kinds of variables/equalities up front. With two kinds of variables you mean a) a variable as a placeholder for an arbitrary expression and b) an Event-B identifier? I'm not sure what you do mean by the second equality? Do you mean statements like: "S \/ T = { x | x:S or x:T }"? In that case, does that really leads to any confusion? > I believe that almost every reader of the handbook has already seen the > subset relation and will find the equation > S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T > rather obvious. So he will not learn anything from reading this > definition. Instead of emphasizing what the reader already knows, the > handbook should point out how Event-B's operators deviate from the > reader's intuition. I do not agree fully here. For most (if not all) it is obvious. But where do we draw the line? Using prose everywhere just to avoid a formal notion would make the reference much more clumsy to read. > 4) Some miscellaneous comments: > > In Section 3.3 you refer to the Z reference manual. There was never an > agreement how partial functions are handled in Z. I would therefore not > try to understand Event-B from the Z reference manual. I agree. But the note is a reference for handbook writers as an example for a handbook for a mathematical notion, not for Z's foundations. The note will be removed before the final release. > In Section 3.3.2 you say that \land and \lor are "principally > commutative". It is not clear to me what that should mean. On some > internal level, \land and \lor are indeed commutative, but this is > hardly evident to the user. I would therefore simply say that \land and > \lor are not commutative. I agree. Again, thank you very much, Matthias. I'll work on the reference section and on incorporating the feedback this week. So most probably I will come back to you with several questions. :) Best regards Daniel |
From: Matthias S. <Mat...@in...> - 2011-11-28 13:12:46
|
Hi Michael, Here is some feedback on the Rodin handbook. 1) Actually I have already used the email feedback feature. I asked for a confirmation that my feedback has been received, but I never got a confirmation. Apparently, there is a problem with the email feedback. 2) Proving / Provers: I find the following statement inappropriate: "New PP is unsound. There have been several bug reports. Some have been fixed, but at this point we do not recommend New PP for inexperienced users." For two reasons: - Experience does not help to cope with NewPP's unsoundness. I would simply not use it for production. For education and alike, it makes sense to use it. (It is difficult anyway to enforce the policy "don't use NewPP" in a class of students.) - ML has been unsound as well. 3) On Mathematical Notation / Sets: I have some feedback on how you introduce the various operators. I focus on the example of subset (\subseteq), but it applies to other definitions as well. Here is the "definition": S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T There is some room for interpretation what this actually means; here is what I understood: - It is not entirely clear whether S and T range over only well-defined or also over ill-defined values. I assume the latter. For, otherwise the statement L(S \box T) \triangleq L(S) \land L(T) would be pointless. - Then it is not entirely clear what the \triangleq means. A logic of partial functions has many notions of equality. I assume that A \triangleq B means that A is true/false/ill-defined iff B is true/false/ill-defined, respectively. This emphasizes that the left- and right-hand side of a definition are interchangeable. With this in mind, I spotted some problems: - Did you introduce "\in"? I could not find it. I admit, it is not possible to define "\in". But maybe you should say at some point what you take as granted and what you define on your own. That prevents readers from searching for definitions that do not exist. - The left- and right-hand side are actually not interchangeable. For, if S is the empty set and T ill-defined, then the lhs is ill-defined and the rhs is true. One may go one step further: the two equalities S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T and L(S \box T) \triangleq L(S) \land L(T) imply L(\forall e\qdot e \in S \limp e \in T) \triangleq L(S) \land L(T), which is certainly not the case. - Actually you have two kinds of variables and two kinds of equalities in the handbook. This makes it difficult to infer what is actually meant. I would make the difference between the two kinds of variables syntactically visible, and explain the semantical difference between the two kinds of variables/equalities up front. I believe that almost every reader of the handbook has already seen the subset relation and will find the equation S \subseteq T \triangleq \forall e\qdot e \in S \limp e \in T rather obvious. So he will not learn anything from reading this definition. Instead of emphasizing what the reader already knows, the handbook should point out how Event-B's operators deviate from the reader's intuition. 4) Some miscellaneous comments: In Section 3.3 you refer to the Z reference manual. There was never an agreement how partial functions are handled in Z. I would therefore not try to understand Event-B from the Z reference manual. In Section 3.3.2 you say that \land and \lor are "principally commutative". It is not clear to me what that should mean. On some internal level, \land and \lor are indeed commutative, but this is hardly evident to the user. I would therefore simply say that \land and \lor are not commutative. Best regards, Matthias |
From: Michael J. <mi...@ja...> - 2011-10-09 19:58:45
|
Dear all, Thank you for all the feedback that your provided. We got 28 items - large and small - and will shortly start incorporating them into the handbook. As we got no objections, we will continue with the third iteration as outlined in the current version of the DoW [1]. In this iteration, we will slowly switch from content generation/migration to quality improvement. To be sure, there is still content that has to be produced: There are still a number of gaps (marked by \marginpars) that we will fill. This will take a significant amount of the iteration's time. But we will also start improving the quality: We will straighten the structure, add copy that provides continuity and build up the index. And Joy Clark, our English native editor, will continue to copy edit all completed sections. We will also get external feedback. A group of seven students just finished a 5-day class that taught B (not Event-B). We gave them an Event-B project as a term project [2] (the first milestone being in November). In other words, we have a group of smart students that barely know B and don't know Event-B at all, perfect for the job at hand. We instructed them to leave plenty of feedback, and we will follow-up with a questionnaire after they complete the first milestone. If we get no objections, then we will also soon remove the migrated content from the Rodin Wiki, and create a tighter integration between the Wiki and the handbook. We definitely want to make sure that people find the information they are looking for. Best, - Michael [1] http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW#Third_Iteration [2] http://www.stups.uni-duesseldorf.de/mediawiki/images/8/88/ST2_WS2011_projekt_eventb.pdf -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2011-10-05 13:02:44
|
Hello Rainer, Thank you for your feedback - I put your comments in our issue list. Best, - Michael On 10/05/2011 02:10 PM, Gmehlich Rainer (CR/AEA4) wrote: > Dear all. > > following some review comments. The feedback button doesn't work for me, so I post my comments here. I hope this is OK for you. > > 2.3.2 Install new plugins > > I suggest to add a comment that if you are behind a firewall you might need to change the proxy settings. Usually this doesn't work out of the box. > > 2.4 The First Machine: A Traffic Light Controller > > There is a picture of a southpark character included. This might be a copyright violation. > > 2.4.3 Building the Model > > In an example the "where" keyword is used > > 2.4.4 The Final Traffic Light Model > > In the exampe the "when" keyword is used > > I strongly suggest only to use one of these two keywords (by the way which one is the correct?) > > 2.6.2 Populate the Context > > "We mark the axiom solution as a theorem () by clicking on the not theorem button as shown in figure " > > This sentence is correct (I think) but it includes a logical contradiction "we mark ... as a theorem by clicking the not theorem button" you get the problem? > > "Theorems describe properties that are expected to be able to be derived from the axioms. " Is this true? Is the consequnece of that to prove a theorem you only use the axioms and other theorems as hypothesis? > > 2.8.3 The Actual Data Refinement > > The explanation is: > > "First we have to make the machine aware of the context by adding a sees () statement:" > > And following this machine: > > MACHINE > > mac1 > REFINES > > mac > SEES > ctx1 > > There is a explanation (or reference to the explanation) missing for the meaning of the refines keyword > > More comments later > > Best regards > Rainer > > Robert Bosch GmbH > (CR/AEY1) > Postfach 30 02 40 > 70442 Stuttgart > GERMANY > www.bosch.com <http://www.bosch.com/> > > Tel. 0711 / 811 49391 > Rai...@de... > > Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; > Aufsichtsratsvorsitzender: Hermann Scholl; Geschäftsführung: Franz Fehrenbach, Siegfried Dais; > Stefan Asenkerschbaumer, Bernd Bohr, Rudolf Colm, Volkmar Denner, Wolfgang Malchow, Peter Marks, Uwe Raschke, Wolf-Henning Scheider, Peter Tyroller > > <C:\Users\ragmehli\AppData\Local\Temp\\attf7178.gif> > > > > > > ________________________________ > > Von: Michael Jastram [mailto:mi...@ja...] > Gesendet: Freitag, 30. September 2011 13:37 > An: Rodin Handbook > Betreff: [Rodin-handbook] Rodin Handbook - Review for the second iteration > > > Dear all, > > We just finished the second iteration (out of four) on the handbook and would like to invite you to the review. We plan on starting with the third iteration on October 10th. I'd like to encourage you all to take the time to at least glance over the work we've done so far. It would also be nice to have at least one official reviewer who can "sign off" on the deliverables (Cliff: Can you do this or nominate someone?). > > You can access our work so far at handbook.event-b.org. Note that we will continue to work on the handbook during the review phase. Therefore, you will find two versions on that page: A "frozen" version for the review, and the latest build. For the review, please make sure that you access the frozen build. > > The second iteration consists of four work packages <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW> , which are documented on the Rodin Wiki. Links to all deliverables can be found on that page. Please note that we made some changes to the next two iterations, to take our progress into account. > > We generate four versions of the documentation from the same sources: HTML <http://handbook.event-b.org/review-2/html/> , PDF <http://handbook.event-b.org/review-2/pdf/rodin-doc.pdf> and Eclipse Help. We encourage you to check out all three versions. To evaluate the Eclipse Help version, you have to install the handbook plugin <http://handbook.event-b.org/review-2/plugin/org.rodinp.handbook.zip> into any Eclipse installation. More convenient, we now added the frozen version to the update site http://handbook.event-b.org/updatesite . The 2.3 RC of Rodin already includes this update site. Rodin 2.3 will not yet include the Handbook, but the inclusion of the update site allows for quick installation, if desired. > > On the HTML and Eclipse Help versions, we offer a feedback button <https://spreadsheets.google.com/spreadsheet/viewform?formkey=dEJmXzUydnRzZGdDVE16WFZmZmd1alE6MQ&entry_0=User%20Manual%20for%20Rodin%20v.2.2> that conveniently allows you to provide immediate feedback. If your organizations blocks the button, or if you are off-line, you can also provide feedback by email (there is also a link for this purpose). The feedback button is useful for error reporting, etc. For discussions, please consider using the handbook mailing list <http://lists.sourceforge.net/mailman/listinfo/rodin-b-sharp-handbook> . > > What you see here is the work of Lukas Ladenberger, Daniel Plagge and Joy Clark, who all did a terrific job, and myself. We hope you are happy with the developments so far. > > Here is a summary of this iteration's work: > > > * The tutorial is now complete, including an editorial pass of a native English speaker. > * We migrated the appropriate content from the Wiki to the Handbook, and marked the content in the Wiki accordingly. > > * We created the structure for the reference section and filled it with content. Please note that this chapter is not finished, even though all the content is there. You'll find many "marginpars" there indicating tasks that are left to do. > > * We created the FAQ and filled it with the existing and some new content. > * We processed all the feedback that we received, both through the web form and via email. > * We added some of the content that is necessary to make the book complete, like creative commons license, acknowledgements, introduction, etc. > * We were not sure initially whether our tool chain (mainly plastex) would support an index. It does, and we started to provide entries. > * We provided a way for plugin developers to include their code, and demonstrated this by adding some ProB and some Camille documentation. We invite all plugin developers to add content for their extensions in the appropriate places. > * A number of minor changes regarding appearance and tool chain. > > Best regards, > > - Michael > > -- > Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) > Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) > 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) > > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Rodin-b-sharp-handbook mailing list > Rod...@li... > https://lists.sourceforge.net/lists/listinfo/rodin-b-sharp-handbook > -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Gmehlich R. (CR/AEA4) <Rai...@de...> - 2011-10-05 12:26:51
|
Dear all. following some review comments. The feedback button doesn't work for me, so I post my comments here. I hope this is OK for you. 2.3.2 Install new plugins I suggest to add a comment that if you are behind a firewall you might need to change the proxy settings. Usually this doesn't work out of the box. 2.4 The First Machine: A Traffic Light Controller There is a picture of a southpark character included. This might be a copyright violation. 2.4.3 Building the Model In an example the "where" keyword is used 2.4.4 The Final Traffic Light Model In the exampe the "when" keyword is used I strongly suggest only to use one of these two keywords (by the way which one is the correct?) 2.6.2 Populate the Context "We mark the axiom solution as a theorem () by clicking on the not theorem button as shown in figure " This sentence is correct (I think) but it includes a logical contradiction "we mark ... as a theorem by clicking the not theorem button" you get the problem? "Theorems describe properties that are expected to be able to be derived from the axioms. " Is this true? Is the consequnece of that to prove a theorem you only use the axioms and other theorems as hypothesis? 2.8.3 The Actual Data Refinement The explanation is: "First we have to make the machine aware of the context by adding a sees () statement:" And following this machine: MACHINE mac1 REFINES mac SEES ctx1 There is a explanation (or reference to the explanation) missing for the meaning of the refines keyword More comments later Best regards Rainer Robert Bosch GmbH (CR/AEY1) Postfach 30 02 40 70442 Stuttgart GERMANY www.bosch.com <http://www.bosch.com/> Tel. 0711 / 811 49391 Rai...@de... Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Hermann Scholl; Geschäftsführung: Franz Fehrenbach, Siegfried Dais; Stefan Asenkerschbaumer, Bernd Bohr, Rudolf Colm, Volkmar Denner, Wolfgang Malchow, Peter Marks, Uwe Raschke, Wolf-Henning Scheider, Peter Tyroller <C:\Users\ragmehli\AppData\Local\Temp\\attf7178.gif> ________________________________ Von: Michael Jastram [mailto:mi...@ja...] Gesendet: Freitag, 30. September 2011 13:37 An: Rodin Handbook Betreff: [Rodin-handbook] Rodin Handbook - Review for the second iteration Dear all, We just finished the second iteration (out of four) on the handbook and would like to invite you to the review. We plan on starting with the third iteration on October 10th. I'd like to encourage you all to take the time to at least glance over the work we've done so far. It would also be nice to have at least one official reviewer who can "sign off" on the deliverables (Cliff: Can you do this or nominate someone?). You can access our work so far at handbook.event-b.org. Note that we will continue to work on the handbook during the review phase. Therefore, you will find two versions on that page: A "frozen" version for the review, and the latest build. For the review, please make sure that you access the frozen build. The second iteration consists of four work packages <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW> , which are documented on the Rodin Wiki. Links to all deliverables can be found on that page. Please note that we made some changes to the next two iterations, to take our progress into account. We generate four versions of the documentation from the same sources: HTML <http://handbook.event-b.org/review-2/html/> , PDF <http://handbook.event-b.org/review-2/pdf/rodin-doc.pdf> and Eclipse Help. We encourage you to check out all three versions. To evaluate the Eclipse Help version, you have to install the handbook plugin <http://handbook.event-b.org/review-2/plugin/org.rodinp.handbook.zip> into any Eclipse installation. More convenient, we now added the frozen version to the update site http://handbook.event-b.org/updatesite . The 2.3 RC of Rodin already includes this update site. Rodin 2.3 will not yet include the Handbook, but the inclusion of the update site allows for quick installation, if desired. On the HTML and Eclipse Help versions, we offer a feedback button <https://spreadsheets.google.com/spreadsheet/viewform?formkey=dEJmXzUydnRzZGdDVE16WFZmZmd1alE6MQ&entry_0=User%20Manual%20for%20Rodin%20v.2.2> that conveniently allows you to provide immediate feedback. If your organizations blocks the button, or if you are off-line, you can also provide feedback by email (there is also a link for this purpose). The feedback button is useful for error reporting, etc. For discussions, please consider using the handbook mailing list <http://lists.sourceforge.net/mailman/listinfo/rodin-b-sharp-handbook> . What you see here is the work of Lukas Ladenberger, Daniel Plagge and Joy Clark, who all did a terrific job, and myself. We hope you are happy with the developments so far. Here is a summary of this iteration's work: * The tutorial is now complete, including an editorial pass of a native English speaker. * We migrated the appropriate content from the Wiki to the Handbook, and marked the content in the Wiki accordingly. * We created the structure for the reference section and filled it with content. Please note that this chapter is not finished, even though all the content is there. You'll find many "marginpars" there indicating tasks that are left to do. * We created the FAQ and filled it with the existing and some new content. * We processed all the feedback that we received, both through the web form and via email. * We added some of the content that is necessary to make the book complete, like creative commons license, acknowledgements, introduction, etc. * We were not sure initially whether our tool chain (mainly plastex) would support an index. It does, and we started to provide entries. * We provided a way for plugin developers to include their code, and demonstrated this by adding some ProB and some Camille documentation. We invite all plugin developers to add content for their extensions in the appropriate places. * A number of minor changes regarding appearance and tool chain. Best regards, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2011-10-05 11:28:44
|
Dear all, This is a friendly reminder that this week we perform the review of the second iteration of the Rodin Handbook project. We already got a number of comments through the feedback form - thank you very much for your feedback! The feedback that we will receive until the end of the week can still influence our plan for the third iteration. Of course, you will continue to be able to provide feedback after the end of this review. The purpose of the review is to ensure that we are on track, that you like the direction that this work is going, and that you agree with our plan for the next iteration <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW#Third_Iteration>. If you have any questions about the Handbook project, please don't hesitate to ask. Best, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Geschäftsführer, Formal Mind GmbH (http://formalmind.com) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Michael J. <mi...@ja...> - 2011-09-30 11:36:38
|
Dear all, We just finished the second iteration (out of four) on the handbook and would like to invite you to the review. We plan on starting with the third iteration on October 10th. I'd like to encourage you all to take the time to at least glance over the work we've done so far. It would also be nice to have at least one official reviewer who can "sign off" on the deliverables (Cliff: Can you do this or nominate someone?). You can access our work so far at handbook.event-b.org <http://handbook.event-b.org>. Note that we will continue to work on the handbook during the review phase. Therefore, you will find two versions on that page: A "frozen" version for the review, and the latest build. For the review, please make sure that you access the frozen build. The second iteration consists of four work packages <http://wiki.event-b.org/index.php/Documentation_Overhaul_DoW>, which are documented on the Rodin Wiki. Links to all deliverables can be found on that page. Please note that we made some changes to the next two iterations, to take our progress into account. We generate four versions of the documentation from the same sources: HTML <http://handbook.event-b.org/review-2/html/>, PDF <http://handbook.event-b.org/review-2/pdf/rodin-doc.pdf> and Eclipse Help. We encourage you to check out all three versions. To evaluate the Eclipse Help version, you have to install the handbook plugin <http://handbook.event-b.org/review-2/plugin/org.rodinp.handbook.zip> into any Eclipse installation. More convenient, we now added the frozen version to the update site /http://handbook.event-b.org/updatesite/ . The 2.3 RC of Rodin already includes this update site. Rodin 2.3 will not yet include the Handbook, but the inclusion of the update site allows for quick installation, if desired. On the HTML and Eclipse Help versions, we offer a feedback button <https://spreadsheets.google.com/spreadsheet/viewform?formkey=dEJmXzUydnRzZGdDVE16WFZmZmd1alE6MQ&entry_0=User%20Manual%20for%20Rodin%20v.2.2> that conveniently allows you to provide immediate feedback. If your organizations blocks the button, or if you are off-line, you can also provide feedback by email (there is also a link for this purpose). The feedback button is useful for error reporting, etc. For discussions, please consider using the handbook mailing list <http://lists.sourceforge.net/mailman/listinfo/rodin-b-sharp-handbook>. What you see here is the work of Lukas Ladenberger, Daniel Plagge and Joy Clark, who all did a terrific job, and myself. We hope you are happy with the developments so far. Here is a summary of this iteration's work: * The tutorial is now complete, including an editorial pass of a native English speaker. * We migrated the appropriate content from the Wiki to the Handbook, and marked the content in the Wiki accordingly. * We created the structure for the reference section and filled it with content. Please note that this chapter is not finished, even though all the content is there. You'll find many "marginpars" there indicating tasks that are left to do. * We created the FAQ and filled it with the existing and some new content. * We processed all the feedback that we received, both through the web form and via email. * We added some of the content that is necessary to make the book complete, like creative commons license, acknowledgements, introduction, etc. * We were not sure initially whether our tool chain (mainly plastex) would support an index. It does, and we started to provide entries. * We provided a way for plugin developers to include their code, and demonstrated this by adding some ProB and some Camille documentation. We invite all plugin developers to add content for their extensions in the appropriate places. * A number of minor changes regarding appearance and tool chain. Best regards, - Michael -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Lukas L. <luk...@gm...> - 2011-09-23 06:23:08
|
Hi Nicolas, I forgot to set the handbook mailinglist on cc in my last email, as this may be useful information for others as well :-) Best regards, Lukas -------- Original-Nachricht -------- Betreff: Re: Modifying the handbook/wiki Datum: Thu, 22 Sep 2011 18:39:13 +0200 Von: Nicolas Beauger <nic...@sy...> An: Lukas Ladenberger <luk...@gm...> Hi Lukas, Le 22/09/2011 17:47, Lukas Ladenberger a écrit : > Hi Nicolas, > > I migrated the content to subversion. However, as you already saw only > as simple plain text without any formatting. The next step would be to > format and to integrate the migrated content to the new handbook. > Alright, so it was not an unintended behaviour from an automatic tool. I was not sure whether it was manual or automatic, now I understand. > Furthermore, I am currently working on the reference section 3.2 > (Rodin Platform). Especially on the sub sections3.2.1 - 3.2.4. > However, feel free to format and to edit the text :-) > That's actually what I just did :-) You're doing a great job, thanks ! Best, Nicolas > Best regards, > Lukas > > Am 22.09.2011 16:42, schrieb Nicolas Beauger: >> Michael, >> >> This is all fine to me. Better having a single source. It's just a >> bit more complicated to preview the changes than with the wiki >> (building, then finding the corresponding html file), but still >> workable. >> >> Concerning the build, I took the liberty of removing a line in the >> launch config (that specified a JRE that is not necessarily installed). >> Then after installing required libs and upgrading dvipng to 1.14, the >> build works fine. >> >> Now just a few issues about the latex sources, I'm encountering >> working with "Preferences for the automatic tactics" (wiki: >> http://wiki.event-b.org/index.php/Preferences_for_the_automatic_tactics >> LaTeX: reference-01.tex) : >> - the wiki subsections sometimes are simple text, instead of >> \subsub...section or \(sub)paragraph, and sometimes occur appended to >> the previous line ("User Documentation" in my case) >> - the wiki links become plain text ("Auto-tactic & Post-tactic" in my >> case) >> I just wanted to know if you are aware of that. Of course this is >> work in progress and we cannot expect perfect translation from the wiki. >> >> Cheers, >> Nicolas >> >> Le 22/09/2011 11:39, Michael Jastram a écrit : >>> Hi Nicolas, >>> >>> Good questions. We will definitely keep the Wiki around, as it >>> contains >>> much more than what will go into the handbook: Announcements, >>> Plugin-Documentation, etc. >>> >>> The content that gets migrated into the handbook will be removed from >>> the wiki (which is better then letting those pages become out of date). >>> But we won't do this until the next iteration review. >>> >>>> In this case, wouldn't it be good to replace the whole wiki contents >>>> of migrated pages by a link to the up-to-date html handbook >>>> (sub)section ? >>> Yes, we definitely need a link from the wiki to the handbook, and >>> such a >>> link already exists. Once the migrated pages are removed, we will make >>> it more prominent. In fact, I suggest to provide links to the top >>> level >>> chapters of the handbook in the navigation (e.g. a link to FAQ, >>> Reference and Tutorial). >>> >>>> Alternatively, could we imagine an automatic synchronization >>>> (regeneration) of the LaTeX sources from the wiki ? >>> We looked into this option before we started, but decided against it. >>> For one, it would add little value (we generate an HTML version, why do >>> we need a redundant Wiki version?). And second, going from Wiki to >>> Latex will result in a lower quality PDF version, for a number of >>> reasons. >>> >>> Now we have exactly one source (Latex) and three generated artifacts >>> (HTML, PDF, Eclipse Help). This approach seems to scale well and >>> results in decent documentation in all three formats. >>> >>> What do you think? >>> >>> Best, >>> >>> - Michael >>> >>> On 09/22/2011 10:41 AM, Nicolas Beauger wrote: >>>> Hi Michael, >>>> >>>> Thank you, that's what I was thinking. It's a bit less practical than >>>> editing the wiki but I can live with that. >>>> But thus, will the wiki pages be updated after a LaTeX build ? >>>> If not, it means that we are definitely dropping the wiki, letting >>>> pages become out of date. >>>> In this case, wouldn't it be good to replace the whole wiki contents >>>> of migrated pages by a link to the up-to-date html handbook >>>> (sub)section ? >>>> Alternatively, could we imagine an automatic synchronization >>>> (regeneration) of the LaTeX sources from the wiki ? >>>> >>>> Cheers, >>>> Nicolas >>>> >>>> Le 21/09/2011 20:37, Michael Jastram a écrit : >>>>> Hi Nicolas, >>>>> >>>>> I'll CC the handbook mailing list, as this may be useful >>>>> information for >>>>> others as well. >>>>> >>>>>> I have a question about the handbook. The wiki pages integrated >>>>>> in the >>>>>> handbook have a "Do not edit!" panel on the top: does it mean they >>>>>> cannot be modified anyhow ? or is it possible to modify them through >>>>>> subversion ? >>>>> It simply means that we converted the content to Latex and copied >>>>> it to >>>>> subversion. We added this panel to prevent content that we migrated >>>>> from being modified (thereby missing potentially important changes). >>>>> The plan is to remove content that is marked that way after a short >>>>> transition period. >>>>> >>>>> If there is content that you need to edit, we'd be grateful if you >>>>> could >>>>> do this in subversion - it's essentially plain latex. >>>>> >>>>> Best, >>>>> >>>>> - Michael >>>>> >>>>> >>>>> On 09/21/2011 06:29 PM, Nicolas Beauger wrote: >>>>>> Hi Michael, Lukas, >>>>>> >>>>>> I have a question about the handbook. The wiki pages integrated >>>>>> in the >>>>>> handbook have a "Do not edit!" panel on the top: does it mean they >>>>>> cannot be modified anyhow ? or is it possible to modify them through >>>>>> subversion ? >>>>>> >>>>>> Cheers, >>>>>> Nicolas >>>>>> >>> >> -- ------------------------------------------------------------------------ Nicolas BEAUGER Tél. : (+33)(0)4 42 90 65 66 Ingénieur Logiciel SYSTEREL ------------------------------------------------------------------------ Standard / Fax : (+33)(0)4 42 90 41 20 / 29 site :www.systerel.fr ------------------------------------------------------------------------ |
From: Nicolas B. <nic...@sy...> - 2011-09-22 14:42:21
|
Michael, This is all fine to me. Better having a single source. It's just a bit more complicated to preview the changes than with the wiki (building, then finding the corresponding html file), but still workable. Concerning the build, I took the liberty of removing a line in the launch config (that specified a JRE that is not necessarily installed). Then after installing required libs and upgrading dvipng to 1.14, the build works fine. Now just a few issues about the latex sources, I'm encountering working with "Preferences for the automatic tactics" (wiki: http://wiki.event-b.org/index.php/Preferences_for_the_automatic_tactics LaTeX: reference-01.tex) : - the wiki subsections sometimes are simple text, instead of \subsub...section or \(sub)paragraph, and sometimes occur appended to the previous line ("User Documentation" in my case) - the wiki links become plain text ("Auto-tactic & Post-tactic" in my case) I just wanted to know if you are aware of that. Of course this is work in progress and we cannot expect perfect translation from the wiki. Cheers, Nicolas Le 22/09/2011 11:39, Michael Jastram a écrit : > Hi Nicolas, > > Good questions. We will definitely keep the Wiki around, as it contains > much more than what will go into the handbook: Announcements, > Plugin-Documentation, etc. > > The content that gets migrated into the handbook will be removed from > the wiki (which is better then letting those pages become out of date). > But we won't do this until the next iteration review. > >> In this case, wouldn't it be good to replace the whole wiki contents >> of migrated pages by a link to the up-to-date html handbook >> (sub)section ? > Yes, we definitely need a link from the wiki to the handbook, and such a > link already exists. Once the migrated pages are removed, we will make > it more prominent. In fact, I suggest to provide links to the top level > chapters of the handbook in the navigation (e.g. a link to FAQ, > Reference and Tutorial). > >> Alternatively, could we imagine an automatic synchronization >> (regeneration) of the LaTeX sources from the wiki ? > We looked into this option before we started, but decided against it. > For one, it would add little value (we generate an HTML version, why do > we need a redundant Wiki version?). And second, going from Wiki to > Latex will result in a lower quality PDF version, for a number of reasons. > > Now we have exactly one source (Latex) and three generated artifacts > (HTML, PDF, Eclipse Help). This approach seems to scale well and > results in decent documentation in all three formats. > > What do you think? > > Best, > > - Michael > > On 09/22/2011 10:41 AM, Nicolas Beauger wrote: >> Hi Michael, >> >> Thank you, that's what I was thinking. It's a bit less practical than >> editing the wiki but I can live with that. >> But thus, will the wiki pages be updated after a LaTeX build ? >> If not, it means that we are definitely dropping the wiki, letting >> pages become out of date. >> In this case, wouldn't it be good to replace the whole wiki contents >> of migrated pages by a link to the up-to-date html handbook >> (sub)section ? >> Alternatively, could we imagine an automatic synchronization >> (regeneration) of the LaTeX sources from the wiki ? >> >> Cheers, >> Nicolas >> >> Le 21/09/2011 20:37, Michael Jastram a écrit : >>> Hi Nicolas, >>> >>> I'll CC the handbook mailing list, as this may be useful information for >>> others as well. >>> >>>> I have a question about the handbook. The wiki pages integrated in the >>>> handbook have a "Do not edit!" panel on the top: does it mean they >>>> cannot be modified anyhow ? or is it possible to modify them through >>>> subversion ? >>> It simply means that we converted the content to Latex and copied it to >>> subversion. We added this panel to prevent content that we migrated >>> from being modified (thereby missing potentially important changes). >>> The plan is to remove content that is marked that way after a short >>> transition period. >>> >>> If there is content that you need to edit, we'd be grateful if you could >>> do this in subversion - it's essentially plain latex. >>> >>> Best, >>> >>> - Michael >>> >>> >>> On 09/21/2011 06:29 PM, Nicolas Beauger wrote: >>>> Hi Michael, Lukas, >>>> >>>> I have a question about the handbook. The wiki pages integrated in the >>>> handbook have a "Do not edit!" panel on the top: does it mean they >>>> cannot be modified anyhow ? or is it possible to modify them through >>>> subversion ? >>>> >>>> Cheers, >>>> Nicolas >>>> > -- ------------------------------------------------------------------------ Nicolas BEAUGER Tél. : (+33)(0)4 42 90 65 66 Ingénieur Logiciel SYSTEREL ------------------------------------------------------------------------ Standard / Fax : (+33)(0)4 42 90 41 20 / 29 site : www.systerel.fr ------------------------------------------------------------------------ |
From: Michael J. <mi...@ja...> - 2011-09-22 09:39:37
|
Hi Nicolas, Good questions. We will definitely keep the Wiki around, as it contains much more than what will go into the handbook: Announcements, Plugin-Documentation, etc. The content that gets migrated into the handbook will be removed from the wiki (which is better then letting those pages become out of date). But we won't do this until the next iteration review. > In this case, wouldn't it be good to replace the whole wiki contents > of migrated pages by a link to the up-to-date html handbook > (sub)section ? Yes, we definitely need a link from the wiki to the handbook, and such a link already exists. Once the migrated pages are removed, we will make it more prominent. In fact, I suggest to provide links to the top level chapters of the handbook in the navigation (e.g. a link to FAQ, Reference and Tutorial). > Alternatively, could we imagine an automatic synchronization > (regeneration) of the LaTeX sources from the wiki ? We looked into this option before we started, but decided against it. For one, it would add little value (we generate an HTML version, why do we need a redundant Wiki version?). And second, going from Wiki to Latex will result in a lower quality PDF version, for a number of reasons. Now we have exactly one source (Latex) and three generated artifacts (HTML, PDF, Eclipse Help). This approach seems to scale well and results in decent documentation in all three formats. What do you think? Best, - Michael On 09/22/2011 10:41 AM, Nicolas Beauger wrote: > Hi Michael, > > Thank you, that's what I was thinking. It's a bit less practical than > editing the wiki but I can live with that. > But thus, will the wiki pages be updated after a LaTeX build ? > If not, it means that we are definitely dropping the wiki, letting > pages become out of date. > In this case, wouldn't it be good to replace the whole wiki contents > of migrated pages by a link to the up-to-date html handbook > (sub)section ? > Alternatively, could we imagine an automatic synchronization > (regeneration) of the LaTeX sources from the wiki ? > > Cheers, > Nicolas > > Le 21/09/2011 20:37, Michael Jastram a écrit : >> Hi Nicolas, >> >> I'll CC the handbook mailing list, as this may be useful information for >> others as well. >> >>> I have a question about the handbook. The wiki pages integrated in the >>> handbook have a "Do not edit!" panel on the top: does it mean they >>> cannot be modified anyhow ? or is it possible to modify them through >>> subversion ? >> It simply means that we converted the content to Latex and copied it to >> subversion. We added this panel to prevent content that we migrated >> from being modified (thereby missing potentially important changes). >> The plan is to remove content that is marked that way after a short >> transition period. >> >> If there is content that you need to edit, we'd be grateful if you could >> do this in subversion - it's essentially plain latex. >> >> Best, >> >> - Michael >> >> >> On 09/21/2011 06:29 PM, Nicolas Beauger wrote: >>> Hi Michael, Lukas, >>> >>> I have a question about the handbook. The wiki pages integrated in the >>> handbook have a "Do not edit!" panel on the top: does it mean they >>> cannot be modified anyhow ? or is it possible to modify them through >>> subversion ? >>> >>> Cheers, >>> Nicolas >>> >> > -- Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94) Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de) 1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de) |
From: Nicolas B. <nic...@sy...> - 2011-09-22 08:41:34
|
Hi Michael, Thank you, that's what I was thinking. It's a bit less practical than editing the wiki but I can live with that. But thus, will the wiki pages be updated after a LaTeX build ? If not, it means that we are definitely dropping the wiki, letting pages become out of date. In this case, wouldn't it be good to replace the whole wiki contents of migrated pages by a link to the up-to-date html handbook (sub)section ? Alternatively, could we imagine an automatic synchronization (regeneration) of the LaTeX sources from the wiki ? Cheers, Nicolas Le 21/09/2011 20:37, Michael Jastram a écrit : > Hi Nicolas, > > I'll CC the handbook mailing list, as this may be useful information for > others as well. > >> I have a question about the handbook. The wiki pages integrated in the >> handbook have a "Do not edit!" panel on the top: does it mean they >> cannot be modified anyhow ? or is it possible to modify them through >> subversion ? > It simply means that we converted the content to Latex and copied it to > subversion. We added this panel to prevent content that we migrated > from being modified (thereby missing potentially important changes). > The plan is to remove content that is marked that way after a short > transition period. > > If there is content that you need to edit, we'd be grateful if you could > do this in subversion - it's essentially plain latex. > > Best, > > - Michael > > > On 09/21/2011 06:29 PM, Nicolas Beauger wrote: >> Hi Michael, Lukas, >> >> I have a question about the handbook. The wiki pages integrated in the >> handbook have a "Do not edit!" panel on the top: does it mean they >> cannot be modified anyhow ? or is it possible to modify them through >> subversion ? >> >> Cheers, >> Nicolas >> > -- ------------------------------------------------------------------------ Nicolas BEAUGER Tél. : (+33)(0)4 42 90 65 66 Ingénieur Logiciel SYSTEREL ------------------------------------------------------------------------ Standard / Fax : (+33)(0)4 42 90 41 20 / 29 site : www.systerel.fr ------------------------------------------------------------------------ |