refchecker-devel Mailing List for RefChecker
Status: Alpha
Brought to you by:
mailund
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Benno L. <ben...@id...> - 2004-05-03 07:14:15
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Thomas M. <ma...@ma...> - 2001-10-08 03:14:26
|
I am currently suffering a bit from RSI, so I've decided to take a break from hacking for a couple of weeks. I'll still be responding to emails, but won't be working on refchecker. If you are interested in hacking it, please do so, but unfortunatly I cannot participate for some time. /mailund -- If an animal is caught in a trap it will chew its leg off to escape. If a human is caught in a trap it will wait and kill the trapper and eliminate a threat to its kind. -- Frank Herbert |
From: Thomas M. <ma...@ma...> - 2001-09-25 23:05:23
|
Just a few thoughts and suggestions for possible optimizations. The hash-function used for compressed states right now hashes labels on references, and xor node-count and number of edges and some stuff like that, but doesn't look at the klasses, which I think is a mistake. This approach wont distinguish between primitive types for example, which is bad for the identifiers in the philosopher examples. Xor-ing the klass pointer in the hash-function might distributed the states some more, and we need that, because the generation time degenerates way faster than linear in the number of nodes in the state space graph. Another thing is the labels used on references. In the klass/state space protocol strings are used, which causes a lot of copying. const char* should probably be used instead, since the strings are static anyway. This is even more important in the compressed states, where the const char* solution would allow all the states to share the labels rather than having a copy each. This would potentially save a lot of memory. And if we take this approach (doable using a table to lookup strings the first time and reusing the same string after wards) hashing labels becomes a *lot* cheaper since we can use the pointer rather than calculate a value from the chars. This would really speed up calculation of hash values, I think. Adding klasses to the hash function is 10/15 minutes work, plus some benchmarking to see how well it does. Adding a table and storing strings in it is a little more work, perhaps a couple or hours. Is any of you up for one of these tasks? /mailund -- And the Lord spake unto Elvis, "Thou hast spoken against me Elvis, and I curse thee to have thy blue suede shoes trod upon for all time..." |
From: Thomas M. <ma...@ma...> - 2001-09-25 06:21:45
|
I've fixed a performance bug in the checker, and I've decided that it is time for a new release, so expect version 0.1.9 up in a couple of hours. Below is some benchmark results to justify the release ;) /mailund Legend: ----------------------------------------------------------------------- DP_n : Dining Philosophers w/id, with n philosophers Dummy_n : Dummy resetter with n philosophers RP_n : Russian philosophers with n Russians and n dining RP_n_m : Russian philosophers with n Russians and m dining Model stats: ----------------------------------------------------------------------- DP_3: ----- node_count : 26 edge_count : 51 DP_4: ----- node_count : 80 edge_count : 212 Dummy_3: -------- node_count : 30 edge_count : 58 RP_2: ----- node_count : 188 edge_count : 482 RP_2_3: ------- node_count : 1081 edge_count : 4004 RP_3_2: ------- node_count : 2586 edge_count : 9915 Models\Versions: 0.1.8 0.1.9 ----------------------------------------------------------------------- DP_3 0.420 0.380 DP_4 2.280 1.720 Dummy_3 0.590 0.550 RP_2 12.890 7.290 RP_2_3 404.290 67.950 RP_3_2 184.200 -- A computer lets you make more mistakes faster than any invention in human history - with the possible exceptions of handguns and tequila. Mitch Ratcliffe, "Technology Review" (1992) |
From: Thomas M. <ma...@ma...> - 2001-09-24 12:44:52
|
OK, I just wrote a version of Russian Philosophers, and *man* do we need optimizations! Admittedly Russian Philosophers isn't the smallest or simplest system, but it still is more or less a toy example and the minimum requirement of a checker such as RefChecker. And right now, RefChecker is failing miserably. I killed the version with three Russian philosophers thinking of three dining philosophers after ~90 min. The version with 2 RP thinking of 2 DP is more manageable, completing in ~10 secs. I don't have time to run the 2RP/3DP right now, but I imagine quite a long running time for that one. The performance degenerates *quickly*. Maybe a hash function that doesn't map *every* state to the same value would be a good place to start... Anyway, I'll add the new models to the benchmark module, and stop making benchmarks for now and concentrate on writing some documentation instead. /mailund -- When people say "I'm gonna kick your ass!", they never kick your ass, they punch you in the face. |
From: Thomas M. <ma...@ma...> - 2001-09-23 14:21:48
|
Optimization without benchmarking is shooting blind, so I've made a small benchmarking framework/suite for this purpose. It consists of a couple of models and some Perl code to analyze the benchmark results. More stuff will be added as needed. The selection of models needs to be extended so I'll write a few new models Real Soon(TM), but until then you are more than welcome to write your own...but I guess I'll have to tell you *how* first. So here's the short version of that: Objects in RefChecker are defined through "klasses" (the c->k thing to avoid keyword-errors in the implementation), where each klass describes the behavior of its objects. In the implementation this is done through some callback protocol, but I'll describe that in another mail. Now, the specification of klasses is currently done using some scripts that generates the C++ classes used in the callback protocol. (It's rather ugly, a Perl script that generates a Python script that generates a shell scripts that generates and compiles C++ files...). This isn't the long term solution, but something to get started with. A future sub-project is getting a proper specification language I guess. Anyway, the specification lanague a hacked up language based on Charles Lakos' LOOPN++, (Language for Object-Oriented Petri Nets. dunno why the ++ is there). The dynamic behavior of objects is specified using an number of Transitions that moves tokens around places and update the tokens it accesses. An example is the dining philosophers used in the test suite: class Phil // declare the klass Phil import Token // this klass depends on the klass Token trans take_left // definition of a transition lfork --- self.left // test arc tbl --- self.table e <-- self.thinking // read arc fork <-- tbl.forks [ lfork == fork ] // guard e --> self.has_left // write arc end take_left trans take_right // snip end take_right trans put_down_left // snip end put_down_left trans put_down_right // snip end put_down_right method new_object( left : op_t, right : op_t, table : op_t ) : op_t // snip end new_object end Phil If we dissect the transition description we see that there are three kinds of Arcs, that connects the transitions to the tokens they update. A Test Arc reads a token from a place, but does not remove it from the place, thus the line lfork --- self.left // test arc selects a token from the place left (self refers to the current instance of the klass), and makes the variable `lfork' refer to this token. A Read Arc selects a token from a place, and removes it, thus the line e <-- self.thinking // read arc reads a token from the place thinking and let `e' refer to this token. If the transition occurs, the token will be removed from thinking. A write Arc puts a token on a place, thus the line e --> self.has_left // write arc puts the token referenced by `e' on the place `has_left'. A Guard, something of the form [ lfork == fork ] // guard is a boolean expression that decides whether the transition is enabled. A transition is enabled if there are sufficiently many tokens to be referenced by test- and read-arcs and all guards are satisfied. When a transition is enabled in can occur and change the state. The transition take_left checks whether the Phil's left fork (known from self.left) is free (is on the place tbl.forks (where tbl refers to self.table)) and if the philosopher is thinking (there is a token on self.thinking), and if all this is true, grabs the fork and moves it own state to has_left, (moving `e' to self.has_left). To get a little more out of klasses, to do stuff like create new instances, it is possible to declare methods. This is really just a little pre-processing of C++ code, so the declaration method new_object( left : op_t, right : op_t, table : op_t ) : op_t op_t phil = Klass::new_object(); phil.add_ref(\"left\",left); phil.add_ref(\"right\",right); phil.add_ref(\"table\",table); op_t token = Token_klass->new_object(); phil.add_ref(\"thinking\",token); return phil; end new_object will just be translated into the C++ method op_t Phil::new_object (op_t left, op_t right, op_t table) const { op_t phil = Klass::new_object (); phil.add_ref ("left", left); phil.add_ref ("right", right); phil.add_ref ("table", table); op_t token = Token_klass->new_object (); phil.add_ref ("thinking", token); return phil; } Now, the models are all of the sub-class SystemKlass, special in the way that it has a method initialize that the state space tool uses to start the whole processing. This method is simply responsible for creating the initial state. After that a SystemKlass is treated just as any other klass. Examples of SystemKlasses are Simple and Philosophers in the klass_repository. OK, I guess that was the Not Too Long Introduction to the spec. language. I hope at least some of it makes sense. If not, ask me. As for the benchnarks, I don't want to add them to the core distribution so I've put the suite in a separate CVS module: benchmarks. Check it out if you want benchmarking. /mailund PS. Freeker, I've CC'ed you since as far as I can see you are not on the developer list. I suggest that you subscribe to this list since I'd like to keep all development discussion here. -- If it's called tourist season, why can't you shoot at them? |