Re: [Demexp-dev] XDR file compilation issue
Hello Thomas,
Thomas Petazzoni <[EMAIL PROTECTED]> writes:
> enum { b = 1, c = 1 } mytype;
Ok, let's try to match above entry with the grammar (cf. §5.3 in RFC).
specification:
definition *
definition:
type-def
type-def:
| "enum" identifier enum-body ";"
So your above "enum { b = 1, c = 1 } mytype;" is not matched by the
grammar. So I would said it is not valid.
You should write "enum mytype { b = 1, c = 1 } ;".
I suppose mytype is correctly defined for the following.
> struct blabla {
> enum mytype m;
> };
>
> struct toto {
> struct blabla meuh;
> };
specification:
definition *
definition:
type-def
type-def:
| "struct" identifier struct-body ";"
struct-body:
"{"
( declaration ";" )
( declaration ";" )*
"}"
declaration:
type-specifier identifier
type-specifier:
| enum-type-spec
enum-type-spec:
"enum" enum-body
enum-body:
"{"
( identifier "=" value )
( "," identifier "=" value )*
"}"
In the case we want do define the enum there. This is not the case in
your example.
Or, we consider we reuse an identifier.
type-specifier:
| identifier
In that case, I think you're right. We should write "mytype" instead of
"enum mytype" and "blabla" instead of "struct blabla" in the struct
declarations.
> First of all, I thought it was a bug of my RPC Generator. In fact, after
> reading RFC 1014 (http://ietf.org/rfc/rfc1014.txt), I think the problem
> is a laxism in the Ocaml RPC Generator : «struct blabla meuh» should not
> be allowed.
I think you're right within the context of a struct definition.
> The correct syntax seems to be :
> struct blabla {
> mytype m;
> };
I agree.
> In this case, the «type-specifier» is simply «identifier», and it works.
>
> Similarly, one should write :
>
> struct toto {
> blabla meuh;
> };
ditto.
> I am not completely sure of this, since I'm not a BNF expert, but it
> seems to be confirmed by the example in section 6 of the RFC. In this
> example, a «union filetype» is defined, and then used directly as
> «filetype» in the definition of «struct file».
I'm not an expert myself but applying by hand the grammar seems to match
your example.
> The attached dpatch fixes the problem. The XDR file still compiles with
> ocamlrpcgen, and DemExp still compiles with it. And my RPC Generator
> also compiles it ! ;-)
Ok, patch queued (or more exactly, your next email ;). As long as the
patch doesn't request a change for ocamlrpcgen, is fine for me.
> If I'm right, it may be a good idea to report a bug to the developers of
> ocamlrpcgen to tell them that their RPC generator is too laxist.
You'd better contact Gerd Stolpman yourself (feel free to reuse part of
my email if necessary). You'll find his email at this end of his page:
http://www.ocaml-programming.de/packages/documentation/rpc/
I would suggest tell him to print a warning if a current XDR def matches
the too laxist definition.
Yours,
d.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] [Sylvain LE GALL] [Caml-list] [ANN] ocaml-gettext v 0.2.0
Hello, For those interested in i18n and l10n of demexp, please find below a library similar to C gettext. Apparently, its behavior is not exactly the same as its C counterpart. Yours, d. --- Begin Message --- Hello, General : Ocaml-gettext is a library that enables string translation in Ocaml. The API is based on GNU gettext. It comes with a tool to extract the string which needs to be translated from Ocaml source file. This enable Ocaml program to output string in the native language of the user ( if you also provide a file containing the translation of the english string contains in the program to the one in the native language of the user ). The translation is base on string ( this means that you need to provide a string and not a unique identifier, like in some other catalog system ). This string is in english, and will be returned if the native language of the user doesn't have translation catalog. Changes: v 0.2.0 is the first public release. Former release was simple wrapper around GNU gettext. This release have a wrapper to GNU gettext AND a pure Ocaml implementation of the library ( based on Camomile ). Link : http://www.carva.org/sylvain.le-gall/ocaml-gettext.html Regard Sylvain Le Gall ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs --- End Message --- -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: *** SPAM *** Re: [Demexp-dev] xml.cd.nw patch.
Hello Serge, Serge Leblanc <[EMAIL PROTECTED]> writes: > However, this one is needed to compile version 0.5. David you can apply > the patch to version 0.5. Thank you. As thomas said, his patch similar to yours is in the wait queue for both 0.4 and 0.5 versions (definitely for 0.5, maybe for 0.4). And Thomas Grenier de Latour made also a similar remark while packaging demexp for Gentoo. So yes, I'm late, but as Thomas P. said, I'm waiting for cduce to enter debian testing : http://packages.qa.debian.org/c/cduce.html Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] demexp servers re-started
Hello, The demexp servers on tuxinette were down. I've restarted them. I don't know what has happened, there are no strange events in the logs. The tuxinette machine hasn't be rebooted. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp servers re-started
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > Maybe they have been killed by some administrator ? ;-) I'll check. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Client web news, the questions list.
Hello Serge, Serge Leblanc <[EMAIL PROTECTED]> writes: > Now you can have a look on the list of questions with : > http://217.128.128.14/demexp-cgi-client.cgi?questions Do you intend to make its source code available somewhere? Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] some thinking on the client: how to improve its usability and attract programmers
Hello, I'm thinking at the different ways to improve the current client. Here are some ideas I have, in no particular order. - programming language: Python vs. OCaml Since Thomas has made the RPC mechanism available in Python, it is now conceivable to write some user interface in Python, using e.g. PyGTK. Python is much more known than OCaml. Of course, all current code is in OCaml, so it would need a rewrite in Python. Should we invest time in a Python client? - modularity of client. The current client is one big binary, with several windows but no real links between those windows. The user might be easily lost in it. I'm thinking at making several binaries, one for each task (vote, browse database, classification). Those graphical programs would be callable from shell scripts, other programming languages, etc. Another less extrem approach would be to keep the same single demexp client but add options like --browse or --vote to open directly the requested window, using a demexp URL (demexp://server:port/question/N); My main objective: I would like to write the necessary parts so that external developers could reuse them to make a more complex demexp client. For example, I can add options to given informations in textual form that can be parsed by shell scripts (--list-questions, --print-question N). - usability of client to track changes The main issue with the current client is that it is difficult to track changes (new questions, new responses, etc.). In order to improve that, I'm thinking of a two side answer: - implement a state (i.e. caching) in the client to store seen questions and their state. Implement a timestamp mechanism to track changes (no proposal yet, I'll made a separate email on it); - implement "virtual tags" that show unseen questions, unvoted ones, etc. Your opinion? Any idea on a way to track changes efficiently? I won't be able to sustain demexp development for two more years alone. So we MUST find a way to attract new developers. :) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] [PATCH] Compatibility with CDuce 0.3
Thomas Petazzoni <[EMAIL PROTECTED]> writes:
> As previously reported by Thomas de Grenier de Latour on this
> mailing-list, the CDuce language changed between 0.2 and 0.3. The old {|
> and |} are now replaced by simple { and }.
>
> The attached patch fixes the problem. (Note: the included patch is a
> Debian patch. It can be applied by simply removing the first few lines).
Patch applied... oh well, not exactly, it failed, probably because I
have modified the file (your patch is for 0.4, right?).
No I have a compile error with:
No implementations provided for the following modules:
Expat referenced from /usr/lib/ocaml/3.08.3/cduce/cduce_lib.cmxa(Cduce_lib)
Curl referenced from /usr/lib/ocaml/3.08.3/cduce/cduce_lib.cmxa(Cduce_lib)
I suppose this is because you have compiled CDuce with expat and curl
instead of netclient and pxp.
You told me once that you had a patch that fixed this issue once and for
all. Could you sent it to me?
Sincerely yours,
d.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] XDR file compilation issue
Thomas Petazzoni <[EMAIL PROTECTED]> writes: >> The attached dpatch fixes the problem. The XDR file still compiles >> with ocamlrpcgen, and DemExp still compiles with it. And my RPC >> Generator also compiles it ! ;-) Patch applied. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Proper way to send patches to me
Hello, I you send patches to me, could you please include them as _attachement_ (and not _inline_ attachement in the email) or directly in the body of the email (if you email reader don't cut long lines). I have a issue with my current email reader (Gnus) where I cannot save inline attached text file in a separate file. The issue is probably between the keyboard and the chair. ;) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] some thinking on the client: how to improve its usability and attract programmers
[EMAIL PROTECTED] writes: > -Finding a large amount of money by "seducing" a rich person/institution > and pay developpers (we have not really tried that yet) As underline by Thomas Petazzoni on another list, even in that case this won't help long term development because as soon as cash will dry, most of paid developers will quit the project. I'm afraid that despite all of our efforts (announces, call for developers, first running release) we are stuck to have a usable version, a user community then to maybe obtain a developer community. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] some thinking on the client: how to improve its usability and attract programmers
Hi Félix, [EMAIL PROTECTED] writes: > I would rather see it the other way around: maybe we can first find some > people ready to invest time in demexp development and ask them what > they would like to use as language. Yes, it would be wiser. Just show me an external demexp developer. ;) > Here you are mentionning two different issues > > 1/ The 'single executable' may confuse the user because of the number of > windows and options. > > 2/ There is an advantage for multiple executables (or the option approach) > because external developper can call the programs in accordance with their > needs. > > Concerning 1/, I'm not sure it's that confusing. Too me, at the moment, the > most confusing thing is the impossibility to immediately view the status of > each question: > -old question on which I have voted > -old question on which I have not voted > -new question Yes. Everybody is telling me that. :) > Concerning 2/, I agree with your approach, but if it requires a substantial > amount of development time, one should probably check if there are some > developpers out ther ready to use the functionality. Sure. It is a kind of chicken & egg issue: develop modules and functionalities to attract developers to develop new modules and functionalities. I need to bootstrap the process, however I don't know how. I'm just trying to make a guess. >> - usability of client to track changes >> >> The main issue with the current client is that it is difficult to >> track changes (new questions, new responses, etc.). In order to >> improve that, I'm thinking of a two side answer: >> >> - implement a state (i.e. caching) in the client to store seen >> questions and their state. >> >> Implement a timestamp mechanism to track changes (no proposal yet, >> I'll made a separate email on it); >> >> - implement "virtual tags" that show unseen questions, unvoted ones, >> etc. >> >> Your opinion? Any idea on a way to track changes efficiently? > > I'm rather in favor of the client caching approach (mainly because I > do not fully understand the other approaches:-) In fact, I need both options to implement full change track as perceived by user. :) The caching is used as a back-end, to follow changes. The "virtual tags" can be used to present information to the user. I've been suggested to use bold/italic on tags, similar to email readers, as a way to see new/unvoted questions. > Storing this kind of info in the client makes sense at this stage > because most people will always access from the same computer. This > approach does not create additional burden in the server. Yes, I try to add most functionalities in the client, i.e. the server does hardly nothing, except providing raw data. It is probably more complicated if someone wants to code a new client but is probably more scalable (time will tell). Many thanks for the feedback. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Which timestamp at each modification?
Hello, For the caching mechanism, I will need to store a timestamp each time a question is modified on the server. This timestamp is communicated to the client, that uses it internally to determine if something has changed since last time it connected. I'm thinking of three way to store and communicate this timestamp: 1. as a date in an ASCII string, e.g. 2005-06-07T12:00; 2. as a 32 or 64 bits integer, incremented each time something is modified, e.g. 165778, 165779, 165780; 3. as a float storing time since 00:00:00 GMT, Jan. 1, 1970, in seconds, as given by OCaml's gettimeofday[1]. Solution 1 seems overcomplicated to me. Solution 2 is quite efficient to handle in CPU and size (on both the server and client side) but solution 3 provides the advantage to give an absolute time of last modification that might be useful later. The main issue against solution 3 is that comparison of floating point numbers is unprecise and vary from processor to processor (i.e. strange bug might occur). Any advice? Any other scheme I might have missed? Yours, d. [1] http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html val time : unit -> float Return the current time since 00:00:00 GMT, Jan. 1, 1970, in seconds. val gettimeofday : unit -> float Same as Unix.time, but with resolution better than 1 second. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Ok for not displaying author of questions?
Hello, I can't remember if we have taken a decision on this point or not: should I remove the display of author of each question or not in the client (and of course underlying protocol)? Personally, I would *not* display author of questions, as the important act is to think on the question and not its author. Your advice? Yours, d. PS: for the record, the latest client no longer display author of _responses_. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Ok for not displaying author of questions?
[EMAIL PROTECTED] writes: > As far as I can remember we agreed on *not displaying* the author of > the question because even the question itself can be quite a sensitive > matter. Ok, so I won't display it. But if we want that all clients do not display it, there is no use to also give it to the client over the wire. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Fwd: Re: [Demexp-dev] Which timestamp at each modification?]
Hello Félix, Felix HENRY <[EMAIL PROTECTED]> writes: > Why not storing the number of seconds since 01/01/1970 > as an integer? If 2 events happen within the same second, it > is not a problem because this number is just used to > inform about the last "date" when an event occured. Higher > resolution than the second is not really useful. That's a good idea. I'll go for it. Thanks, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Fwd: Re: [Demexp-dev] Which timestamp at each modification?]
Hello, luna <[EMAIL PROTECTED]> writes: > number of seconds : TAI or UTC ? OCaml time returns the current time since 00:00:00 GMT, Jan. 1, 1970, in seconds. I suppose GMT equals UTC. What does TAI means? >From Unix man page time(2) : POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of seconds between a specified time and the Epoch, according to a formula for conversion from UTC equivalent to conversion on the naïve basis that leap seconds are ignored and all years divisible by 4 are leap years. This value is not the same as the actual number of seconds between the time and the Epoch, because of leap seconds and because clocks are not required to be synchronised to a standard refer- ence. The intention is that the interpretation of seconds since the Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further rationale. Yours, d. (optional) PS: does I know you? -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Ok for not displaying author of questions?
Hello, luna <[EMAIL PROTECTED]> writes: > There is even quite no use to store the information. I don't know. But maybe if a participant exhibits a very pathological behavior (e.g. DoS attack with excessive number of questions) it would be useful to know its name under a special procedure. It is true this is sensitive information that would be protected once security is done. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Fwd: Re: [Demexp-dev] Which timestamp at each modification?]
luna <[EMAIL PROTECTED]> writes: > This link [2] describe well the difference between Epoch, UTC and TAI. > But the difference is perhaps not relevant for demexp. > It's easier to rely on UNIX sub-system. Thanks for the pointer. In fact, after reading it, I suppose the number of seconds given by OCaml time should not take into account leap seconds, as given by unix time(2). Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] multiple server in client & demexp urls
Hello, For your information, latest developer version of demexp supports multiple server simultaneously and can use demexp URLs. I find those features quite nice. :) >From changelog: 2005-06-12 19:51:25 GMT David MENTRE <[EMAIL PROTECTED]> patch-25 Summary: preferences now support multiple servers and is put in HOME/.demexp/ Revision: demexp--dev--0.5--patch-25 * Makefile: brown paper bag fix: set warning as error for all compiled programs! * gtk2-clnt/Pref: rewrite Pref module: - it can now handle serveral servers simultaneously; - it saves configuration information in $HOME/.demexp/ directory; - login information is saved in $HOME/.demexp/logins. * gtk2-clnt/Browser gtk2-clnt/demexp-gtk2-client: use new Pref module. Modify code so that each browser window has its preference filed, configured for its server. All server:port information is now passed through a pref object. modified files: Makefile gtk2-clnt/browser.ml.nw gtk2-clnt/clntflags.ml.nw gtk2-clnt/demexp-gtk2-client.ml.nw gtk2-clnt/pref.ml.nw 2005-06-12 17:05:38 GMT David MENTRE <[EMAIL PROTECTED]> patch-24 Summary: handle demexp URLs in client Revision: demexp--dev--0.5--patch-24 * gtk2-clnt/Url: new URL format "demexp://server[:port]/stop_server" to request a server to be put on halt. * gtk2-clnt/Clntflags gtk2-clnt/demexp-gtk2-client.ml.nw: - remove options: -q and --stop-server, they are now handled by a demexp URL; - for each URL given in the command line, open a demexp browser on it. Code modified to handle several browsers simultaneously. modified files: gtk2-clnt/browser.ml.nw gtk2-clnt/clntflags.ml.nw gtk2-clnt/demexp-gtk2-client.ml.nw gtk2-clnt/url.ml.nw 2005-06-12 16:12:16 GMT David MENTRE <[EMAIL PROTECTED]> patch-23 Summary: new module Url to parse demexp URLs Revision: demexp--dev--0.5--patch-23 * Makefile gtk2-clnt/Url: new module Url to parse demexp URLs (with autotests). Recognized URLs are: demexp://server[:port] demexp://server[:port]/browse/question/78 demexp://server[:port]/vote/question/78 new files: gtk2-clnt/.arch-ids/url.ml.nw.id gtk2-clnt/url.ml.nw modified files: Makefile gtk2-clnt/demexp-gtk2-client-book.tex Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] A protocol proposal to track modifications on server
Hello, I'm currently trying to design the protocol, data structures and algorithms needed to imlement caching in the client. The main idea is quite simple: To each object in the server (participant, question or tag) associate a 64 bits timestamp (following the scheme suggested by Félix). Each time an object is modified, its timestamp is updated with latest modification real time. When the client needs to know whether its cache is synchronized or not with the server, it only needs to check the object timestamp on the server. If the client's local value is the same, it has latest version, otherwise it needs to fetch the latest one from server. My only concern is regarding timestamp fetching. How to optimize it in such a way that the client won't request timestamp of *all* objects on the server? I'm thinking at the following solution: - the server keeps the highest timestamp for groups of 10, 100, 1000, ... objects in a tree, the bigger the group, higher it is in the tree. For example, highest timestamps for questions from 0 to 9, 10 to 19, ..., highest timestamp for questions from 0 to 99, etc.; - the client keeps the same data structure for its cache; - when the client needs to check its local cache validity, it requests the highest timestamp for questions from 0 to the maximum number of questions. For example, highest timestamp for questions from 0 to 99. If the timestamp given by server does not match the highest timestamp localy stored, the client requests the 10 sub-timestamps. For example, timestamps for questions from 0 to 9, 10 to 19, ..., 90 to 99. For each one of them, the client check if it has the same value. If not, get individual question info for unmatching timestamp. On the server or client side, when an object is modified, e.g. question 18, it is only needed to update a limited amount of timestamps, e.g. from 10 to 19, from 0 to 99, from 0 to 999, ... Obviously, the algorithm has an logarithmic complexity and is scalable to a large amount of objects. What do you think of it? Any suggestion of suitable data structures? Any pitfalls to avoid? Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] A protocol proposal to track modifications on server
Hi Félix, Many thanks for the feedback. Overall, I find your approach quite interesting. From a programming point of view, it is quite simple to implement, except that it will add once more new dependencies to the code (zlib) and I need to find suitable binding. And I need to figure how to handle endianness in OCaml. I'll go for your approach. Some comments on your comments: [EMAIL PROTECTED] writes: > 1/ Concerning your proposed approach > -I think that it is probably most efficient in terms of bandwidth. > I would recommend using a binary tree (instead of 10-tree you seemed > to suggest in your mail) because I would intuitively > guess it is optimal in terms of bandwidth needed to check the > timestamps (but not optimal in terms of server workload, see below). > -I may put some heavy worldload on the server because each time an > object is modified (mainly questions and tags), all timestamps > hierarchically "above" the said object are to be modified. In this > case a non-binary tree is better because the larger the order of the > tree, the less parents to update. If I would keep my algorithm, I would implement it with the tree width defined as a constant that could be changed. And I would probably keep the 10-tree approach. > -I may be complex to implement (as compared to brute method, see below) > because of the recursive nature of the algorithm and because the server > and client trees do not have the same shape (there are always more > objects on the server due to new questions etc.) OCaml helps a lot when one need to encode algorithms. But that's true that this is more complex than your approach. > 2/ Possible other approach: brute force > That's 210 timestamps. Now, obviously, the time resolution of > the timestamps should not be higher than the time resolution of the > file update on the server. With 24 bits for a timestamp, > your system can last for 2^24=16777216 and 1216/(30*24*365)=63,8 years. > The uncompressed file would be: > 210 timestamps * 24 bits /(8*1024)=6 MB I prefer a 32 bits timestamp (easier to code). With 31 bits (signed integer), starting from 2005-01-01, it will allow timestamp until about 2068 if we keep the 1s resolution and until about 1 if we keep the 2mn resolution. I'll probably use 2s resolution (until about 2130). At 32 bits, it gives about 8 MB uncompressed. > You would need a file format to be able to assign each timestamp to its > corresponding object but that should be easy. Proposed format: 32 bits int: number of questions (Q) 32 bits int: number of tags (T) 32 bits int: number of participants (P) 32 bits int: question timestamp * N 32 bits int: tags timestamp * T 32 bits int: participant timestamp * P All integers encoded in big endian format. The tree first integers could be encoded in the XDR format separately. Do you think it is an issue if the three timestamp zones (for questions, tags and participants) are gzipped separately? > Let me know what you thing. I like it. :-) So I'm going to implement it. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] demexp 0.5.1 (aka 0.6pre1) released
Hello, I'm quite pleased to announce the availability of version 0.5.1 of demexp. This release features an improved client (caching of network requests, tracking of question changes, etc.), modification of the network protocol and a slightly modified server. I consider 0.5.1 a candidate release for 0.6. I intend to setup yet another alpha server to do some remote testing. For package maintainers, you can consider this release as a typical source tree for 0.6 package. The compilation system is still a mess, patches welcomed. ;) Special note to thomas (petazzoni): thomas, as Gulliver's CA is currently using version 0.4, it would be nice if we could have simultaneously v0.4 and v0.6. Can you make 0.6 packages so that they can be installed in parallel with 0.4? As usual, comments and feedback are welcomed. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: [demexp-en] demexp 0.5.1 (aka 0.6pre1) released
David MENTRE <[EMAIL PROTECTED]> writes: > I'm quite pleased to announce the availability of version 0.5.1 of > demexp. This release features an improved client (caching of network > requests, tracking of question changes, etc.), modification of the > network protocol and a slightly modified server. Oops, forgot to URL: http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-0.5.1.tar.gz > I intend to setup yet another alpha server to do some remote > testing. A new server is available on tuxinette.linux-france.org:50065. This is the same base as the :5, so you should reconfigure the client with same login/password. To launch the client on this base: demexp-gtk2-client demexp://tuxinette.linux-france.org:50065 A binary of the client is available: http://www.linux-france.org/~dmentre/demexp/binaries/demexp-gtk2-client-0.5.1 > As usual, comments and feedback are welcomed. Still valid. :) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] demexp 0.5.2
Hello, I've just released yet another beta of demexp, v0.5.2. New from 0.5.1: - on the server, a tag specific to each question "question NN" is created for each new question; - the browser display has been updated with flags New/Voted/Updated: - New: the question has never been seen or has been updated on the server; - Voted: the user has voted on the question; - Updated: the user has voted on the question and it has been updated on the server. Those two points should fulfil Fred and Félix requests at last demexp meeeting. The last one, having all questions selected if no tag is selected, is more difficult to implement. Binary: http://www.linux-france.org/~dmentre/demexp/binaries/demexp-gtk2-client-0.5.2 Tests on demexp://tuxinette.linux-france.org:50065 and comments welcomed. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Opinions on announcement message for 0.6?
ngnu.org/demexp/ Democratic experience political project: http://www.demexp.org Have fun! David MENTRE -- demexp lead developer Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp 0.5.2
David MENTRE <[EMAIL PROTECTED]> writes: > Binary: > > http://www.linux-france.org/~dmentre/demexp/binaries/demexp-gtk2-client-0.5.2 This is now: http://www.linux-france.org/~dmentre/demexp/binaries/demexp-gtk2-client-0.5.2-x86 Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp 0.5.2
Hello Thomas, Many thanks for the update of the Gentoo package. As usual, if you find something the burden you as a package maintainer, don't hesitate to warn upstream. ;) The next 0.5.3 version is going to have a ./configure script. Right now, it does not do anything special compared to the old Makefile but it might do more complicated things in the future. BTW, I've updated the dev web page at http://www.nongnu.org/demexp/ , mainly with new screenshots and an index at the beginnng of the page. Once again, if you want to add Gentoo specific information on this page, let me know (or send me a patch against web CVS ;). Thomas de Grenier de Latour <[EMAIL PROTECTED]> writes: > Also added a "gnome" > USE flag which triggers installation of a GConf schema for > "demexp://" URI handling... Obviously completly useless, but i > was curious about how it was working, and happy to find it out :) As fred, I'm also interested about that. How does it work? Can it trigger the opening of the client if we have demexp:// URI (URL?) inside a Gnome application? Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp 0.5.2
Hi Thomas, Thomas de Grenier de Latour <[EMAIL PROTECTED]> writes: > - I had to change "equeue" into "equeue-core" for the EQUEUEDIR > declaration in the Makefile, since that's where the module > contents actually is here (with equeue-2.0.1). > In /usr/lib/ocaml/equeue, all I have is a META file, with > "equeue-core" in the requires. I'm not sure exactly, but there is > probably something here that ocamlfind could solve automagically. > Something like this should follow the requires and output in > "-I /path/to/equeue -I /path/to/equeue-core" format: > EQUEUEFLAGS:=$(shell ocamlfind query -i-format -recursive equeue) > I think that in general, it would be a good idea to switch to > such recursive queries in the Makefile or future configure > script, cause it would also solve issue where some modules deps > are missing (like in a previous version where i had to add expat > or curl to the Makefile depending how cduce was compiled). Yes, using -i-format -recursive options to ocaml find is a good idea. In fact, I've never digged into ocamlfind documentation. I have added this to my TODO list. About equeue-core, it does not seem to be needed on my debian system. Equeue version is 2.1. I can't tell more. > - I've had to add "-I /usr/lib/ocaml/site-packages/stublibs" to > the CLNT_OCAMLINC, otherwise compilation was failing with: [...] > Error on dynamically loaded library: dllmlgz.so: cannot open > shared object file: No such file or directory > make: *** [gtk2-clnt/demexp-gtk2-client.bc] Error 2 > > It sounds strange to explicitly include this dir, i would have > thought it was in some kind of default path or something. I don't > know what would be the clean fix here, maybe that's also > something where ocamlfind could help, or maybe it's a > Gentoo/Ocaml issue. On Debian, is this directory in the > /etc/ld.so.conf or something like that? Once again, I don't have such issues on my debian system. Maybe a Gentoo/OCaml issue. > If you really want improvement requests, one item i would add to > your TODO is a logging system for the server: it would be nice if > it could have at least a "--logfile /path/to/logfile" option > (because right no, to get a logfile while launching it via > start-stop-daemon, i must use a wrapper shell script to make the > stdout/stderr redirection, and that's not really beautiful). Ok, I've added this to my TODO. > And sure, all the other features of a unix daemon (taking care > of its pid file, a new file "bases.pid" is now created in latest dev version. > dropping privileges, No need for this as the server does not use any privilege. However, it might be useful to have a "demexp" account specific for the server and to give appropriate rights to the server files. I leave this to package maintainers. :) > detaching to background, I have added this to my TODO. > Oh, and one last very simple request: there is much valuable info > in your 0.6 announcement text, so don't forget to include it > somewhere in the source tarball so that packages can install a > copy in /usr/share/doc :) Yes, it is already in the source tree. :) > Maybe you could put the .schemas file and this short explanation > in the misc/ directory, it may be useful for other packagers. Yep, good idea. One more TODO item. > As for the URI vs. URL distinction, eh, i don't really know what > the difference is, so i randomly use one or the other. > `wtf` doesn't help much here: > % wtf url > url [uri](7) - uniform resource identifier (URI), > including a URL or URN > > Go figure... According to http://www.w3.org/Addressing/URL/uri-spec.html , an URI is a name in a namespace. On the contrary, an URL gives more concrete information to use a given protocol (e.g. server name and port). So, currently demexp:// are URL. When we will have distributed and interconnected servers, we will have URI (or URN ? ;). Thank you for your feedback. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp 0.5.2
Thomas de Grenier de Latour <[EMAIL PROTECTED]> writes: > Ok, i've just `man tla` and checked out the dev tree a few > minutes ago, so from now i should stop asking for things you've > already done :) So you should see that I have implemented you --logfile option. ;) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
About change notification (was: Re: [Demexp-dev] demexp 0.5.2)
Hi, David MENTRE <[EMAIL PROTECTED]> writes: > Thomas de Grenier de Latour <[EMAIL PROTECTED]> writes: > >> Ok, i've just `man tla` and checked out the dev tree a few >> minutes ago, so from now i should stop asking for things you've >> already done :) And by the way, if you prefer push than pull, an email is sent on demexp-cvs@ mailing list (historical name ;) each time I make a tla commit. And the latest tarball (without ChangeLog) is updated at: http://www.linux-france.org/~dmentre/demexp/latest-src/demexp--dev--0.5.tar.gz Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp 0.5.2
Hello, David MENTRE <[EMAIL PROTECTED]> writes: > Yes, using -i-format -recursive options to ocaml find is a good idea. In > fact, I've never digged into ocamlfind documentation. I have added this > to my TODO list. Ok, done. >> If you really want improvement requests, one item i would add to >> your TODO is a logging system for the server: it would be nice if >> it could have at least a "--logfile /path/to/logfile" option >> (because right no, to get a logfile while launching it via >> start-stop-daemon, i must use a wrapper shell script to make the >> stdout/stderr redirection, and that's not really beautiful). > > Ok, I've added this to my TODO. Done: --logfile option. >> detaching to background, > > I have added this to my TODO. Done. Use new --daemon option (with --logfile option). >> Maybe you could put the .schemas file and this short explanation >> in the misc/ directory, it may be useful for other packagers. > > Yep, good idea. One more TODO item. Your documentation has been added to source tree. I'll release a 0.5.3 soon. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] 0.5.3 out
Hello, I've just released 0.5.3. Client binary: http://www.linux-france.org/~dmentre/demexp/binaries/demexp-gtk2-client-0.5.3-x86 Sources: http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-0.5.3.tar.gz http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.5.3.pdf What's new: - announcement for 0.6; - saving of PID in a file; - ./configure script; - update of man pages; - --logfile and --daemon options on server; - documentation of demexp URL handling in Gnome (Thomas dGdL); - use ocamlfind recursively to find package dependencies. Just test it! ;) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Client design: list of things a user would like to do
Hello, With Jean-Marie, we are currently thinking at the design of the next demexp client and its ergonomics. In order to build user cases, I have made a list of things a user would probably like to do with his/her demexp client. Could you complete the following Wiki page if you think about other things? http://jm.trivial.free.fr/wiki/wakka.php?wiki=ErgonomieDemexp Thanks, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] [Robert Roessler] Re: New lablgtk2 snapshot
Following post could be relevant for windows porter of demexp. Yours, d. --- Begin Message --- Jacques Garrigue wrote: > There is a new snapshot of lablgtk2 at >http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html >ftp://ftp.kurims.kyoto-u.ac.jp/pub/lang/olabl/lablgtk2-20050701.tar.gz > > It contains only bug fixes for windows. Well, might there be more than just Windows-only fixes? :) Speaking of Windows (for those who might want to reach 90-plus percent of the world's users and developers), I have had good luck so far with the GTK+ runtime (currently @ 2.6.7) from http://gimp-win.sourceforge.net/ It has a complete Windows installer package, which is surely easier to use for many of the end-users we would like to target with our cool LablGTK-based OCaml apps. :) Robert Roessler [EMAIL PROTECTED] http://www.rftp.com --- End Message --- -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] building demexp
Hello John,
John Skaller <[EMAIL PROTECTED]> writes:
> Gerd's rpc builds fine .. but gz doesn't. That C code is broken,
> reported to oliv (admin of the project).
>
> ocamlc.opt -ccopt "-D BZ_PREFIX " -c c_gz.c
> []
> c_gz.c:203: error: invalid lvalue in assignment
Could you try this patch?
diff -ru gz-0.5.6/c_bz.c gz-0.5.6-dm1/c_bz.c
--- gz-0.5.6/c_bz.c 2002-05-29 10:47:57.0 +0200
+++ gz-0.5.6-dm1/c_bz.c 2005-07-06 19:58:32.868034896 +0200
@@ -70,6 +70,9 @@
#define Bzfile_val(v) ((BZFILE*)(Field((v), 1)))
#define Bz_eof(v) (Bool_val(Field((v), 2)))
+#define Cfile_lval(v) ((Field((v), 0)))
+#define Bzfile_lval(v) ((Field((v), 1)))
+
static void set_eof_flag(value chan)
{
Field(chan, 2) = Val_true ;
@@ -141,8 +144,8 @@
int bzerror ;
BZ_P(bzReadClose)(&bzerror, Bzfile_val(chan)) ;
fclose(Cfile_val(chan)) ;
- Cfile_val(chan) = NULL;
- Bzfile_val(chan) = NULL;
+ Cfile_lval(chan) = 0;
+ Bzfile_lval(chan) = 0;
/* mlbz_error(bzerror, "Bz.close_in", chan, 1); */
return Val_unit ;
}
@@ -197,8 +200,8 @@
int bzerror ;
BZ_P(bzWriteClose)(&bzerror, Bzfile_val(chan), 0, NULL, NULL) ;
fclose(Cfile_val(chan)) ;
- Cfile_val(chan) = NULL;
- Bzfile_val(chan) = NULL;
+ Cfile_lval(chan) = 0;
+ Bzfile_lval(chan) = 0;
/* mlbz_error(bzerror, "Bz.close_out", chan, 0); */
return Val_unit ;
}
diff -ru gz-0.5.6/c_gz.c gz-0.5.6-dm1/c_gz.c
--- gz-0.5.6/c_gz.c 2002-05-29 10:41:35.0 +0200
+++ gz-0.5.6-dm1/c_gz.c 2005-07-06 19:56:35.127934112 +0200
@@ -65,6 +65,7 @@
/* extract the gzFile from the Caml value */
#define Gzfile_val(v) ((gzFile)(Field((v), 0)))
+#define Gzfile_lval(v) ((Field((v), 0)))
/* get library version */
value mlgz_zlibversion(value unit)
@@ -200,7 +201,7 @@
res = gzclose(str);
if(res<0)
mlgz_error(str);
- Gzfile_val(chan) = NULL ;
+ Gzfile_lval(chan) = 0 ;
return Val_unit;
}
Yours,
d.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] building demexp
Hello John, 2005/7/7, John Skaller <[EMAIL PROTECTED]>: > I seem to change Camels often .. ;( A temporary solution for your issues (until AMD64 bugs are fixed in upstream releases) is to use a 32 bits chroot environment. At least you could try demexp! ;-) https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274293 Apparently, there is even a simpler way: apt-get install ia32-libs Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] 0.5.3 out
Hi John, John Skaller <[EMAIL PROTECTED]> writes: > OK .. it works .. Cool! > hehe .. voted on the only question I could find in English .. :) Well, you probably noticed that most demexp people are French. :) But i18n is on the todo list for next releases. > The startup is a bit messy: I had to edit preferences, > then when i restarted it forgot the server. Started again > with server name, had to edit account .. quit and start > again for the login to take effect. Yep. I know. I should at least automatically reconnect to the server after each login change. But, on the long term, appropriate dialogs to edit multiple server preferences should be provided. If only programming those GUI dialogs would not take such a lng time. > Also had some glitches with the /tmp/test-demexp file, > i initially started up as root, when I changed to > my user account I got permission errors. > > Per user connection info should go in the users > home? In fact, user info go in .demexp/ directory. Those /tmp/test-demexp files are related to non regression autotests that should be disabled for user release. I'll update the ./configure script. Thanks for the test. Don't hesitate to let us know what do you think about current features, even if they are negative. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] 0.5.3 out
David MENTRE <[EMAIL PROTECTED]> writes: > Those /tmp/test-demexp files are related to non regression autotests > that should be disabled for user release. I'll update the ./configure > script. Ok, that one is fixed in --patch-63. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] About bytecode binary in demexp packages
Hello Thomas, You're pretty responsive regarding demexp packaging. :) When looking at you changelog, I noticed that entry: * 20050706: Minor cleanups [...] - changed make targets in demexp-gtk2-client and demexp-server to avoid unnecessary compilation of the static and bytecode versions. I would prefer that you keep bytecode version of the client around (you can throw the static one, I'm the only one to use it). In OCaml, only the bytecode version allows to have a precise diagnosis (backtrace) in case an exception is raised. So, in case of issue, I could ask somebody to rerun the bytecode client with the appropriate parameters. I admit that the size overhead is not minor (3 MB, but 1 MB compressed). We are currently *developing* demexp. :) In the long-term, of course, only the native version should be kept. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: About bytecode binary in demexp packages
Hello Thomas, 2005/7/7, Thomas de Grenier de Latour <[EMAIL PROTECTED]>: > user have some issues with demexp-gtk2-client, then he could: > # USE="debug" emerge demexp-gtk2-client > And then he would get a "demexp-gtk2-client.bc" to produce the > traceback. That's what we do, for instance, to install a C program > with its debug symbols, so it's pretty standard. Does it sounds > fine? Yep, it's ok for me. However, could you document this somewhere in your doc? I'm not sure to remember this next time a Gentoo user will have an issue. :-) Well, there is still a minor annoyance for the user as the client should be launched with a specific option (--exception or something like that). Moreover the client should be launched from a terminal and some environment variable be set. Well, maybe a wrapper script would be useful (demexp-gtk2-client-debug or something like that). Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] 0.5.3 out
Hi John, 2005/7/8, John Skaller <[EMAIL PROTECTED]>: > 'You' are not the only programmer here .. one reason I was trying > to build from source. :-) Wonderful! What a lovely day today! > However, a monolithic solution isn't the only answer. > If the command line went > > demexp URL account > > with a popup for the password, the main GUI wouldn't need > to worry about switching connections. It could be managed > by another program, possibly written in a scripting language, > and thus customisable for the political arena. Well, I'm not sure about that. I though at one point to implement demexp://[EMAIL PROTECTED]:port/ kind of URL but I wasn't sure it would be that much useful. Command line URL doesn't integrate well with GUI. For the long term, more thinking is needed. If you consider that user will have strong authentication using crypto keys, the user will probably have to drag and drop some config file (sent by the authority managing the server) in its client. This config file would contained server info (server:port) and login info (account + private key). Once this config file is dropped into the client, the user would only have to point its client to the server and enter its password. Of course, you might want to generate the private/public key pair on the client side for obvious security reasons, so the config file might only contain some server side cookie for one time client authentication. Well, all that to just say that we should not focus too much on current client behaviour. The current code should allow us to have a wider set of testers and users. But the client (or another kind of client) could change a lot in the future. For example, I'm wondering if we could not just let the client be the usual file browser of the desktop (IE on Windows, Nautilus or Konqueror on Linux, ...) with just a few pluggins to vote, delegate, ... On all those interface issues, we have open a Wiki page (in English ;-): http://jm.trivial.free.fr/wiki/wakka.php?wiki=ErgonomieDemexp > On thing I think you will need to do: when you connect to > a server, the client should download an icon and display it. I don't understand. An icon for what? To show that the client is connected to the server? A kind of progress bar? Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] 0.5.3 out
John, 2005/7/8, John Skaller <[EMAIL PROTECTED]>: > To show WHICH server A client is connected to. Ah, ok. This info is displayed in the client title bar. However, this can only be done once needed information has been loaded from server. During initial loading, the Gtk.main has not been called so the GUI cannot display anything. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
demexp questions on demo server (was: Re: [Demexp-dev] 0.5.3 out)
John, 2005/7/8, John Skaller <[EMAIL PROTECTED]>: > > > hehe .. voted on the only question I could find in English .. :) And before I forget, feel free to enter new questions and classification tags on the demo server, in English or any other language that suites you. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] [RFC] Using a file browser as demexp GUI?
[RFC stand for Request For Comments] Hello, I would like to have your advice on following point. I'm thinking seriously at using the native file browser of the desktop machine as a client for demexp. That would enable easy integration with LFS (Logical File System) and would relieve us of most GUI issues (the hard graphical parts is done by the OS and desktop applications, we only write generic parts emulating files and folders). The details are on the Wiki and reproduced below. What do you think of it? http://jm.trivial.free.fr/wiki/wakka.php?wiki=ErgonomieDemexp * use directly a filesystem and an OS browser to navigate through the position base. Technically, we can do that if the client appears locally as a WebDAV server. Files types ensure we can vote and/or see needed information, with appropriate helper applications. o the classification (tags and questions) appears as a set of folders and files o when double-clicking on a question file, we can vote on a question The main issue is how to differentiate between seeing a question and voting on it. How to display it? As two different files? And how to display information specific to a question? Into a sub-folder? And how to delegate? Put the question in a delegation folder inside the folder of the delegate? And how to classify? Move a question into a tag folder? Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] [RFC] Using a file browser as demexp GUI?
Hi Thomas, 2005/7/8, Thomas de Grenier de Latour <[EMAIL PROTECTED]>: > LFS is definitly very cool, but last time i've checked it was > still not usable on a modern Linux system (because of perlfs not > beeing usable on >=2.4.somethinglow kernels). IIRC, the idea of > porting it to FUSE was in the air though, and that would solve > the issue, at least for Linux users. Latest version of LFS is using fuse. I got it from its author and ran it on my Debian with kernel 2.6 without major issue. This version will be released soon. > That said, i think it would be more interesting to aim > integration with an OS-independent LIS, like Camelis: > http://www.irisa.fr/lande/ferre/camelis/index.html > This one would give a cross-platform questions browser component > for almost free once the glue for questions metadata and the > demexp-specific logic are written. Well, at least that is my > optimistic understanding after a quick look on it :) Yes, I also had a look at Camelis pages. But I still fear that using Tree View will be unmanageable if the tree is too big, i.e. we have too many tags and questions. But if you read carefully my previous post, my intent is to provide an OS agnostic part, which is interconnected to the OS through WebDAV. As far as I know, this works on Linux (through Nautilus or Konqueror), Windows and MacOS X. And LFS core can be integrated into an OCaml application (I've checked with LFS author). Graphically: OS Browser <--(WebDAV)--> WebDAV server/demexp client <--(demexp RPC)--> demexp server The only OS specific part is to play with file types (MIME types?) and file extensions so that the right helper application is called when the user double-click on a file. Of course, some application need to be written (for vote, ...), but those a just subsets of the current client. And for the die hard command liner, one could write a fuse plugin to access the demexp client through cp and mv on Linux. :-) Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] v0.5.4 is out
Hello, I've just made another 0.6-pre4 aka 0.5.4. Differences from 0.5.3: * new option --for-developer in ./configure. By default, production binaries (i.e. without autotests) are produced; * doc/demexp-book.tex: latex compilation with hyperref now works. Apparently the debian bugs I filed (#231324) is still not fixed but now latex and pdflatex work. I don't know why! :( * minor code and doc cleanups. Binaries and src are available at the usual places, starting from: http://www.linux-france.org/~dmentre/demexp/ Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Why not a single hierarchy (was: Re: [Demexp-dev] [RFC] Using a file browser as demexp GUI?)
Hello, On the GUI side, jean-marie and myself have made some progresses, I'll do a separate post on it. echarp <[EMAIL PROTECTED]> writes: > To me, the tags/keywords seem like a strange kludge. Why this > bottleneck? Why use them for delegations? Why not a simpler hierarchy > that would/could map to a simple text (/part/chapter/section/...)? Having a single hierarchy was our original idea and was implemented in 0.2, with delegation. However, there is a fundamental flaw in it: how do you set the order between hierarchy levels? E.g.: between New York and Ecology, which one should be put upper in the hierarchy? That's why we have decided to use a flat space, with tags (aka labels) on questions. "Normalizing" tags allow us to hope to have a single keyword (aka tag) behind a concept. But as underlined many times, that does not preclude others to build more elaborated classifications or event their own classification (no Serge, I haven't said ontology ;-). That should be a FAQ. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] yet another release: 0.5.5
Yop, Here is for you latest demexp version, 0.5.5. Because a good release is not without at least five pre-releases. :) In 0.5.5: fix a bug: new added answer was not displayed. Available at usual stores. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Server changed / serveur modifié
[ français en dessous] Hello, To help testing of latest pre-release of demexp, I have upgraded demo server to version 0.5.5. To try it: 1. get latest client : http://www.linux-france.org/~dmentre/demexp/binaries/ 2. start it on tuxinette : ./demexp-gtk2-client-0.5.5-x86 demexp://tuxinette.linux-france.org:5 3. configure preferences with your account parameters 4. quit client and restart it Yours, d. == Bonjour à tous, Pour favoriser le test de la nouvelle version du client, j'ai mis le serveur de démo en version 0.5.5 (contre ancienne 0.4). Pour l'utiliser : 1. Récupérer le dernier client : http://www.linux-france.org/~dmentre/demexp/binaries/ 2. Le lancer sur tuxinette : ./demexp-gtk2-client-0.5.5-x86 demexp://tuxinette.linux-france.org:5 3. configurer dans Preferences avec vos paramètres de login 4. quitter le client et le relancer Amicalement, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] yet another release: 0.5.5
Hello Sylvain, 2005/7/11, Sylvain Collilieux <[EMAIL PROTECTED]>: > I try your binary. I run ./demexp-gtk2-client-0.5.5-x86, > Edit->Preferences, I put my login, password, server, etc., I close > demexp and when I run it again all preferences are empty. *Each time* you launch the client, are you using the demexp URL? ./demexp-gtk2-client-0.5.5-x86 demexp://tuxinette.linux-france.org:5 Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] yet another release: 0.5.5
Hello Sylvain, I have checked that the server is correctly running. And moreover, there is a login issue in the server logs: <0>2005-07-11T23:52:19+0200 RPC login(1, "SylvainCollilieux", **passw**) <0>2005-07-11T23:52:19+0200 => participant 'SylvainCollilieux' failed to log in , remains Anonymous (cookie:919698105) Could you check that your login name and password are indeed correct? Apparently, your login name is incorrect. It is "sylvain.collilieux" and not "SylvainCollilieux". You have probably mixed with a Wiki login. ;) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] yet another release: 0.5.5
Hello Sylvain, Glad to see that the client is working for you. Sylvain Collilieux <[EMAIL PROTECTED]> writes: > IS it a bug or maybe a feature ? When you change something in the > preferences (serveur name, port, etc.), demexp doesn't change the > parameter but create a new group of paramaters in the logins files. A feature, the current client is able to store préférences for several servers. In the following file, you have preferences for two different servers (port 5 and 50001). > $ less .demexp/logins > 2 > tuxinette.linux-france.org > 50001 ^ > sylvain.collilieux > > sylvain.collilieux > > tuxinette.linux-france.org > 5 ^ > sylvain.collilieux > > sylvain.collilieux Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Should I release demexp 0.6?
Hello, I haven't seen much reports on 0.5.* versions. Do you think I can release demexp 0.6? Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] A new wiki is available to ease demexp development
Hi all, Fred and myself have set up a Wiki for demexp, for both the development and ideas related to the political project. Feel free to edit it and add new pages. We would prefer to have wiki pages in English, to ease communication. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] DemExp 0.4 compilation issue with CDuce 0.3.9
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > I traced down the issue a bit further, and I come to the conclusion that > cdo2ml doesn't work the way it worked, or it is buggy. Trying to > manually run cdo2ml doesn't work (it waits forever). Running it with If I understood CDuce release notes correctly, cdo2ml is no longer used. >From release notes: http://sympa.cduce.org/wws/arc/users/2005-07/msg00025.html - Tools: * The functionality of cdo2ml is now assured by cduce itself, with the --mlstub option. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] DemExp 0.4 compilation issue with CDuce 0.3.9
Thomas, A simple solution seems to avoid that path handling at all, assuming cdo2ml is in the PATH. So we would have: Thomas Petazzoni <[EMAIL PROTECTED]> writes: > I grepped in cduce source code, and I think the call to cdo2ml is in > ocamliface/mlstub.ml, around line 550 : > > let exe = Filename.concat (Filename.dirname Sys.argv.(0)) "cdo2ml" in let exe = "cdo2ml" in > print_endline prolog; > let oc = Unix.open_process_out exe in > Marshal.to_channel oc str_items []; > flush oc; > ignore (Unix.close_process_out oc) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] DemExp 0.4 compilation issue with CDuce 0.3.9
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > As I said in the other e-mail, the problem was that the preprocessor to > use is "cduce --mlstub" instead of "cdo2ml --static". > > However, running "cduce --mlstub" doesn't work, because it looks for > cdo2ml in the current directory. I have found a simple work around: > using -pp "/usr/bin/cduce --mlstub". > > I've debugged the thing a bit, and came to the conclusion that when > "cduce" is run directly (assuming it's in the PATH), then Sys.argv.(0) > doesn't return the full path, and then "cdo2ml" path is incorrect. A possible explanation: when you run "cduce" directly, the calling process cd to the directory where cduce lives and starts ./cduce, which does not happen if you give the absolute path. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] DemExp 0.4 compilation issue with CDuce 0.3.9
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > If the process calling cduce cd'ed into the cduce directory (i.e > /usr/bin), then calling ./cdo2ml should work, because cdo2ml is in > /usr/bin ;-) Ok. Which process is calling "./cdo2ml"? cduce? Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Testing latest CDuce (was: Re: [Demexp-dev] DemExp 0.4 compilation issue with CDuce 0.3.9)
Thomas, Thomas Petazzoni <[EMAIL PROTECTED]> writes: > For those who want to try the compilation with CDuce 0.3.9, Debian > packages for stable, testing and unstable are available on my Debian > repository (http://thomas.enix.org/pub/debian/packages, as usual). I > have two Lintian warnings left after what CDuce 0.3.9 might get uploaded > into Debian. Well, if I upgrade my cduce package to latest one (0.3.9) I won't be able to compile current demexp source tree. Can you leave somewhere the old cduce package so I can roll back my cduce version to 0.3.2? Well, a simpler way would probably to compile CDuce locally. I'll do that. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] DemExp 0.4 compilation issue with CDuce 0.3.9
David MENTRE <[EMAIL PROTECTED]> writes: > Which process is calling "./cdo2ml"? cduce? Ok, I've seen your post en CDuce mailing list. This cduce which is calling cdo2ml. Quite strange indeed. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: Testing latest CDuce
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > CDuce 0.3.2 is available in sarge, etch and sid on all official mirrors, > so it shouldn't be much of a trouble to roll back to this version ;-) Ok, thanks. I forgot that. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] CDuce 0.3.9 vs DemExp 0.4: next issue
Hello Thomas, Thomas Petazzoni <[EMAIL PROTECTED]> writes: > As I have no clue about how CDuce works or what it precisely does, I'm a > bit stuck. Any idea ? No. I have redone carefully needed steps following CDuce documentation and I arrived to the same error. I've asked on the cduce-users@ mailing list. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: [demexp-fr] demexp 0.6 Debian package available
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > Packages for the older version of demexp (0.4) are still available. They > have been renamed demexp0.4-client-gtk2 and demexp0.4-server. They might I've installed package for 0.4 and it works with tuxinette/gulliver-ca server. Regarding 0.6 package, I've also launched it and it seems to work. I noticed that the client prints timers when exiting, I should disable that for production client and server. Many thanks thomas for the packages. I know it is not that easy. ;) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp utilisability
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > Currently, when one installs and runs the demexp 0.6 client, it faces > with a "Connection refused" error. I think it would be nice if the > client could connect to a test server out-of-the-box, directly after > installation, without any need to tune preferences. Yes. I thought about it but forgot. It should be somewhere in my todo lists. :) > ? Or maybe, simpler, would it be possible to hard-code a default, > server, login and password in the server that would be used by default ? I prefer this approach. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp utilisability
Hello John, 2005/8/1, skaller <[EMAIL PROTECTED]>: > Connection to a demexp server should be the same: > I should choose the server, and be assured a connection > can't ever be made without knowing which server is > being connected to .. and also can't proceed without > my password. Other people may prefer auto connect > without password .. the main thing that this should > not *silently* default. Well, to be honest, I haven't put a lot of thought at those issues. Right now, I trying to make a useable client for people willing to test the concept (and the software). But more emphasis should be put on the concept than on the current client, with is very bad from a GUI point of view. BTW, I'm discovering the hard way how time consuming and difficult is it to make a user interface. :( That's said, I have registered your sensible remarks, John, and I'll try to follow them /in the future/. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] demexp utilisability
Hello Thomas, 2005/8/1, Thomas Petazzoni <[EMAIL PROTECTED]>: > There's however a minor issue: I don't program in Ocaml ;-) A good pretext to learn it. ;-) Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] New stable version 0.6 is out!
site: http://www.nongnu.org/demexp/ Democratic experience political project: http://www.demexp.org Web site and ideas to improve client design: http://www.demexp.org/dokuwiki/doku.php?id=client:client_ergonomics Have fun! David MENTRE -- demexp lead developer -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] And now, what for demexp--dev--0.7?
Hello, Now that stable 0.6 is out, we can focus on next development version 0.7. Currently, I plan following items for next stable 0.8: - implement delegation *in the server*, i.e. all the server and network code, without user related code; - internationalisation and localisation, if the wanabee demexp hacker wakes up. ;) Now, there is also a hard point that I would like to improve for 0.8: the client. I'm *very* unsatisfied with the current client[1]: I think the user interface is pretty complicated (i.e. bad) and, more importantly, it is difficult for newcomers to "be into the loop", i.e. install the client and use it. Even core project members have issues to setup the client[2]. >From the beginning, we (or rather I :) have chosen to implement a graphical client from scratch in order to not limit ourselves in terms of user interaction. But this freedom has a price: it is hard and time consuming to build a client from scratch. While I still believe that this choice is a good one for the long term (Jean-Marie Favreau and myself have some ideas on how we could improve the client[3]), it is still necessary to facilite the entry of new people. A new client from scratch was probably too ambitious. The obvious way is to use a standard web browser as client. So, once again, I'm considering a way to have a web interface to demexp. - At one point, I considered implementing a Firefox plugin for demexp, but as I would like to keep the RPC protocol between client and server, it would make a complicated plugin (XPCOM component, biding between C++ and OCaml) or would be a Javascript nightmare. And the task of installing a plugin would lost us users; - Another approach would be to implement a module on the server side that makes the link between the web server and the demexp server; - The last approach would be to implement an HTTP server into the current demexp server. I'm in favor of the second approach, that still forces us to keep the RPC protocol and separate the server issues from client issues. Now, how to proceed? OCaml code for writing web server side code exists (Gerd Stolpmann's libraries come to mind). The main issue is to implement a statefull demexp binding with HTTP stateless protocol. I don't know if it is easy or not. However, I don't think it would be difficult to imlement current user interface as web pages. The other important issues are to see if it could be possible: - to implement the new ideas developed by Jean-Marie and myself in the web interface. I think this can be done, maybe with a little less nice graphical layout (but Jean-Marie is good at CSS, XHTML and graphics, so that could be a big plus. Having fancy graphics is important for users... and developers ;-) ; - to implement user side delegation (no idea how to do that, we need to think about it). Ok, I already hear Frédéric crying on the insanity of doing a web interface ;) but if we want to reach a critical mass by 2007, with a polished client and users on Windows, MacOS X and the various Linux distributions, only the web interface seems affordable to me from a software engineering point of view[4]. As soon as the web interface works, we have a client on *all* platforms. As usual, the discussion is open and I would be glad to hear your comments. Yours, d. [1] As it is my own code, I'm free to criticize it. ;) [2] Names concealed to keep them in the project. :) [3] http://www.demexp.org/dokuwiki/doku.php?id=client:client_ergonomics [4] Or find packagers like Thomas and Thomas for all linux distribs and full time developers like Christophe Gisquet for Windows and Mac ports, plus a full time developer to improve the client. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] And now, what for demexp--dev--0.7?
David MENTRE <[EMAIL PROTECTED]> writes: > OCaml code for writing web server side code exists (Gerd Stolpmann's > libraries come to mind). I'm think of http://wdialog.sourceforge.net/ This library seems quite interesting: - separation of concern between page layout and application logic code, the web application is considered as successive dialogs; - support of i18n (http://wdialog.sourceforge.net/manual/page-17.html); - application code is programmed in OCaml (think web application with a GC and compiled natively!); - Gerd's Excellent Quality Code Inside(tm). :) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] And now, what for demexp--dev--0.7?
Hello John, skaller <[EMAIL PROTECTED]> writes: > It is not as bad as you think. Do not assume 'newbie' users > are dumb people :) Yes, but as I don't specially find the current interface particularly user friendly and as I am the main developer of it, I assume that a new user would be lost in front of it. A good UI doesn't need a user manual. > I would also love to say "Hey, can you install a server > for my project please" to another friend -- he has access > to a machine that can be used as a host (i.e. he can > configure it to allow a server to run on various ports). Installing a server is not that difficult (but the binary somewhere and launch it). It is just that I never had time to write a doc. > [me :] >> - At one point, I considered implementing a Firefox plugin for demexp, >>but as I would like to keep the RPC protocol between client and >>server, it would make a complicated plugin (XPCOM component, biding >>between C++ and OCaml) or would be a Javascript nightmare. And the >>task of installing a plugin would lost us users; >> >> - Another approach would be to implement a module on the server side >>that makes the link between the web server and the demexp server; >> >> - The last approach would be to implement an HTTP server into the >>current demexp server. > > Why?? What's wrong with a CGI script which acts as the client > and talks to the server? Why do you need to implement a whole > HTTP server when you can just plug into Apache or some other > server? In fact, I underlined that I'm in favor of the 2nd approach, which is the CGI one (this is what I called "implement a module on the server side..."). > Surely all you need is that the CGI process has permission > to connect to the real demexp server? Yep. > To maintain session state, php may be the way to go, > since most web sites have Apache with php_mod installed: > this is better than CGI. I'm not fond of PHP, despite I recognize it is quite easy to develop web apps with it. However, as underlined in a parallel post, I'm in favor of WDialog, mainly because it is written in OCaml and is intendeed to be programmed in OCaml. > The downside of the server side demexp interface is: > > * loss of security -- may not matter for some applications Anyway, we don't have much security right now. We won't lose anything. :) > * loss of sophisticated navigation techniques That was the main reason behind using an autonomous client. However we have failed to build sophisticated navigation techniques until now. > but what you gain is a half a billion potential clients, > without having to distribute ANYTHING to them: everyone > everywhere with web access can 'just vote, right now'. Yes, exactly. > Maintaining state isn't hard (use cookies as a session key) > but accounting for server load, denial of service attacks, > and other security issues may not be so easy: it requires > real world experience .. so I'd be looking to see how > php does it, simply because it the most widely used system. WDialog has some facilities that seem interesting: Session management and security http://wdialog.sourceforge.net/manual/page-26.html > The way delegation should work is this: a proxy *offers* to > vote a certain way on certain kinds of issues for anyone > that registers with them. A voter can then *subscribe* > to their platform. This permits that proxy to vote for > the client. This is an option. The other option is to let the client informs the server of the user delegations and the server takes care of updating vote counts accordingly. We are currently in favor of the second one. > What are the Concordant rules on this? AFAIK, description of Cordorcet voting never speak about delegation. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] And now, what for demexp--dev--0.7?
Hello, David MENTRE <[EMAIL PROTECTED]> writes: > I'm think of http://wdialog.sourceforge.net/ > > This library seems quite interesting: > > - separation of concern between page layout and application logic code, >the web application is considered as successive dialogs; > > - support of i18n (http://wdialog.sourceforge.net/manual/page-17.html); > > - application code is programmed in OCaml (think web application with a >GC and compiled natively!); > > - Gerd's Excellent Quality Code Inside(tm). :) I have browsed the documentation. I recommend to take a look at the Architecture part to grasp the main idea of the library. http://wdialog.sourceforge.net/manual/page-2.html If nobody is vocally against WDialog, I'll probably give it a try in next dev tree. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] And now, what for demexp--dev--0.7?
Hello Thomas, 2005/8/10, Thomas Petazzoni <[EMAIL PROTECTED]>: > Actually, I'm not sure that any of the demexp GUI will be usable without > reading a manual. That's a challenge I would like to respond. It does not mean I will succeed. :) > Demexp has various concepts unknown to many people, > and one can't really use a software without understanding the underlying > concepts. It's even more important for a voting software, in which your > actions are important, as they "engage" yourself. You have a good point of underlying the importance of understanding the concepts behind demexp (delegation, Condorcet vote, ability to change vote). But we should design a system where such concepts can be easily grasped. For example, delegation could be represented in a graphical form to the user. I admit I haven't clear ideas neither proposals. > I think the primary goal could be an *efficient* GUI rather than a > *intuitive* GUI. I'm sure some hackers will provide scripting facilities to improve efficiency. ;-) > Take Blender as an example again: for the newcomer, > it's not really intuitive. However, once one understood the idea of the > tool, it's use is getting more and more efficient. So should demexp be ;-) (arrrgghh) I won't deny the idea of Blender having an efficient interface. However, I'm amongst those people that have never succeeded in using it, mainly due to its interface. The goal of demexp is to provide *wide scale* direct democracy. So the interface should seem intuitive to most people. That's said, I still hope that by having a easy enough interface, new developers will come, interested by demexp, but with new ideas and improvements. But you raise an interesting point: intuitive vs. efficient interface. I vote for intuitive interface at first. But I'm ready to hear, now or latter, your arguments about how to improve efficiency. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] And now, what for demexp--dev--0.7?
Hi Félix, 2005/8/10, Felix HENRY <[EMAIL PROTECTED]>: > If I understand correctly, this means a solution where a web client "talks" > to a web server and then the web server access the demexp server, but the > demexp server does not see the difference between this type of access and > a regular binary client? I have no objection but I just want to confirm I > understood it. Yes exactly. This architecture forces me to keep the current RPC protocol, that would be available to develop a secure voting protocol (as underlined by John), for scripting facilities (as with Thomas's Python scripts) and, when a legion of coders will improve the 1.0 client and server, to develop a better user interface. :-) > Given your arguments and the other ones discussed on the mailing list > I certainly support the development of a web interface. Great! Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] OS X demexp compilation
Hello FX, François-Xavier Ponscarme <[EMAIL PROTECTED]> writes: > that's my first post on this list, I'll try to help for demexp development. > Well there's some troubles during compilation but finally it works. Great! > Many of these troubles comes from software versions that are not updated > as early as on Linux either with fink or godi. > Linking with crt0.o is also a problem, fixed by getting extra package > from Darwin (Csu). Could you write a small doc on the way you successfully compiled demexp on MacOS X? You can put it on your web page or on the page on the demexp wiki. In the same way, do you plan to provide MacOS X binaries? > Another problem is due to incompatible option of compilation, actually > it seems that OSX does not support the static linking of users binaries. > So "-dynamic" be used instead of "-static". Is this issue appearing when compiling srv/demexp-server.static? This binary is probably of no use except for myself[1]. I should probably remove it from default: target, and maybe the all: one. > Do you think we must modify configuration file configuration, or just > add a test in the Makefile to fix linking issues? It would be better to add all configuration tests into the ./configure shell script. Yours, d. [1] It is easier for me to put this binary on tuxinette machine. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Quick notes to install WDialog on Debian Sarge
Hello, Please find below some notes to install WDialog on a Debian Sarge. I've not done much except checking that WDialog basic adder works. I'm used to have write rights on /usr/local/ for my account. You might need to be root to make installs in the following. Quick notes to install WDialog on a Debian Sarge 1. Install dependencies # apt-get install ocaml-native-compilers ocaml-nox \ ocaml-findlib libpcre-ocaml-dev \ libocamlnet-ocaml-dev ocaml-ulex libpxp-ocaml-dev \ librpc-ocaml-dev 2. Install Inifiles $ wget -c http://www.csun.edu/~eric/inifiles-1.1.tar.gz $ tar zxvf inifiles-1.1.tar.gz $ cd inifiles-1.1 $ make && make opt $ make install 3. Install WDialog $ wget -c http://ovh.dl.sourceforge.net/sourceforge/wdialog/wdialog-2.1.tar.gz $ tar zxvf wdialog-2.1.tar.gz $ cd wdialog-2.1 $ ./configure $ make all && make opt $ make install [ Note: note getting inifiles and using ./configure -without-wd-session-daemon is probably sufficient for normal install. I don't know what this wd-session-daemon is. :) ] 4. Test that it works [ I suppose that you have apache configured and running on localhost. ] $ vi /etc/apache/httpd.conf Modify section to execute CGI scripts in /usr/local/lib/cgi-bin/. ScriptAlias /cgi-bin/ /usr/local/lib/cgi-bin/ # # "/usr/lib/cgi-bin" could be changed to whatever your ScriptAliased # CGI directory exists, if you have that configured. # AllowOverride None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all $ mkdir /usr/local/lib/cgi-bin/ # /etc/init.d/apache restart $ cp -a wdialog-2.1/examples/adder /usr/local/lib/cgi-bin/ $ vi /usr/local/lib/cgi-bin/adder/index.cgi Modify the exec line into: exec /usr/bin/ocaml "$0" "$@" Point your browser to: http://localhost/cgi-bin/adder/index.cgi You should be able to run the wonderful Ultimative Adder. :) Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Mockup of a web interface for demexp
Hello, You'll find at http://demexp.dyndns.org/ a mockup of a web interface for demexp that is done with WDialog. Use demo/demo as login/password (default ones). Most buttons should work. You'll find also pointers to source files used to make this interface. The used machine is my own one, so it won't be available at all time. Some warnings: - the layout is pretty basic, I'm more interested in the logic right now. But if you have suggestion for fundamental things (not page layout, but functionalities) you can give them anyway; - there is no connection to the server, all the displayed data is fake. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[François-Xavier Ponscarme] Re: [Demexp-dev] OS X demexp compilation
François-Xavier has forgotten demexp-dev. d. --- Begin Message --- David MENTRE a écrit : > Hello FX, > Hi David, > Could you write a small doc on the way you successfully compiled demexp > on MacOS X? You can put it on your web page or on the page on the demexp > wiki. > > In the same way, do you plan to provide MacOS X binaries? > > I've took some notes, I'll write complete Install notes for OSX. Concerning binaries I can provide its but I don't have any web site yet ... > Is this issue appearing when compiling srv/demexp-server.static? Yes, changing static option by dynamic one solve the problem. > Thisbinary is probably of no use except for myself[1]. I should probably > remove it from default: target, and maybe the all: one. > > But I think that this linking issue(actually it's the policy of Apple) is generic on OSX, libraries have to be linked dynamically. It's possible to make static linking but with special versions of libraries, which are not provided by Apple in OSX. Here is an example : http://developer.apple.com/qa/qa2001/qa1118.html > > Yours, > d. FX --- End Message --- -- [EMAIL PROTECTED] ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: [Wdialog-users] Quick notes to install WDialog on Debian Sarge
Hello Eric, Eric Stokes <[EMAIL PROTECTED]> writes: > This is nice :-) would you consider allowing us to put it up somewhere, > or doing so yourself? In fact, the email is archived on demexp-dev mailing list: http://lists.gnu.org/archive/html/demexp-dev/2005-08/msg00030.html But feel free to include this doc into wdialog tarball if you feel it might help. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: [Wdialog-users] How to slice an application into dialogs and pages?
Hello Eric, Eric Stokes <[EMAIL PROTECTED]> writes: [ About the way to cut a WDialog application into several dialogs ] > The general idea is that you create a dialog with no user > interface, and put all the variables you would like to share between > sessions in it. You then create a variable in each of your dialogs with > type "dialog", I usually call it session, and then when you switch > dialogs you need to remember to set the session in the new > dialog. Within dialogs you can access session variables using the . > notation, eg. session.somevar. Many thanks for the clear explanations. I'm going to implement my app following this approach. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: [Wdialog-users] How to slice an application into dialogs and pages?
Hello Gerd, Gerd Stolpmann <[EMAIL PROTECTED]> writes: > The other method is to stack dialogs. [...] > This method is a good choice if your dialogs are designed using > metaphors like "sub dialogs". You can find an example in the "GODI > Administration Tool": > > https://gps.dynxs.de/svn/godi-bootstrap/godi-admin/trunk/src/www/ Thank you for the second approach. I'll stick with Eric's session approach for now but I'll remember you "stacked" approach if I ever have to code sub-dialogs. BTW, it might be worth to mention that somewhere in the wdialog doc, maybe with just a link to your post in the mailing list archive. I'll let you know of it works. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Emacs configuration to edit noweb files
Hello,
For those wanting to edit .nw files in demexp source, I'm using
following code in my .emacs. I'm also including a setting to be under
text-mode for editing Arch log files.
;; many thanks to Hubert Canon <[EMAIL PROTECTED]> for this code
(add-hook 'noweb-mode-hook 'my-noweb-set-mode-code)
(defun my-noweb-set-mode-code ()
(let* ((filename (file-name-nondirectory buffer-file-name))
(mode (cond ((string-match "^Makefile" filename) 'makefile-mode)
((string-match "\\.lisp\\.pamphlet$" filename) 'lisp-mode)
((string-match "\\.lsp\\.pamphlet$" filename) 'lisp-mode)
((string-match "\\.clisp\\.pamphlet$" filename) 'lisp-mode)
((string-match "\\.c\\.pamphlet$" filename) 'c-mode)
((string-match "\\.h\\.pamphlet$" filename) 'c-mode)
((string-match "\\.ml\\.nw$" filename) 'caml-mode)
((string-match "\\.mli\\.nw$" filename) 'caml-mode)
((string-match "\\.cd\\.nw$" filename) 'caml-mode)
((string-match "\\.c\\.nw$" filename) 'c-mode)
((string-match "\\.h\\.nw$" filename) 'c-mode)
((string-match "\\.xdr\\.nw$" filename) 'c-mode)
((string-match "\\.dtd\\.nw$" filename) 'sgml-mode)
((string-match "\\.ui\\.nw$" filename) 'nxml-mode)
(t 'fundamental-mode
(noweb-set-code-mode mode)))
;; to have text mode on Arch log files
(setq auto-mode-alist
(append '(("\\+\\+log\\..*$" . text-mode)
) auto-mode-alist))
Yours,
d.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Short doc to install ocamlgraph on Debian Sarge
Hello, I'm considering using ocamlgraph to make code relative to delegation. Here is a short doc on how to install it. More info about ocamlgraph: http://www.lri.fr/~filliatr/ocamlgraph/ Installing ocamlgraph on Debian Sarge = 1. Dependencies # apt-get install ocaml-findlib [optionally:] # apt-get install graphviz graphviz-doc 2. Getting, compiling and installing ocamlgraph $ wget -c http://www.lri.fr/~filliatr/ftp/ocamlgraph/ocamlgraph-0.94a.tar.gz $ tar zxf ocamlgraph-0.94a.tar.gz $ cd ocamlgraph-0.94a $ ./configure $ make $ make doc # in fact, the doc is NOT installed with the library $ make ocamlfind-install $ make install-findlib 3. check that it works [I recommend to install ledit when using ocaml interactively. It provides readline-like facilities. gv is needed to display graphs. ] # apt-get install ledit gv $ ledit ocaml -I ocamlgraph Objective Caml version 3.08.3 [then at ocaml prompt #] # #load "graph.cma";; # open Graph.Pack.Digraph;; # let show = display_with_gv;; val show : Graph.Pack.Digraph.t -> unit = # let g = Rand.graph ~v:10 ~e:20 () let () = show g;; val g : Graph.Pack.Digraph.t = [A graph should be displayed] Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Short doc to install ocamlgraph on Debian Sarge
David MENTRE <[EMAIL PROTECTED]> writes: > [I recommend to install ledit when using ocaml interactively. It > provides readline-like facilities. gv is needed to display graphs. ] Both graphviz and gv are needed to display graphs. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Short doc to install ocamlgraph on Debian Sarge
Hello Thomas, 2005/8/19, Thomas Petazzoni <[EMAIL PROTECTED]>: > FWIW, a libocamlgraph-ocaml-dev package is available in Debian Sarge, > Etch and Sid. Why do you need to compile it ? Because I'm stupid and did not checked if ocamlgraph was available in Sarge. :) > Because the Sarge version > is too old ? But it is true that the Sarge version is quite old. I'll stick to my compiled version for now. BTW, I'm still evaluating its use. I'm not sure at all it fulfills our requirements. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Delegation and ocamlgraph: an example and a list of issues
as lists *) module SCC = Components.Make(G) let sccl = SCC.scc_list g (* Use of Graphviz *) module Display = struct let vertex_name v = match G.V.label v with V.Individual(n) -> "indiv"^(string_of_int n) | V.Delegate(n) -> "deleg"^(string_of_int n) | V.Question(n,l) -> "Quest_n"^(string_of_int n)^"_tags_"^List.fold_right (^) l "" let graph_attributes _ = [] let default_vertex_attributes _ = [] let vertex_attributes _ = [] let default_edge_attributes _ = [] let edge_attributes e = match G.E.label e with E.Delegation t -> [`Style `Bold; `Label t] | E.Vote -> [`Style `Dotted; `Label "vote"] include G end module Dot = Graphviz.Dot(Display) let _ = Dot.output_graph stdout g end Using dot of graphviz, we can represent it in a picture: ocamlgraph is not very well documented for beginners but once that basic data structures are layed out, it should be pretty easy to apply its algorithms. And having facilities to draw delegation graphs could be useful. Going back to demexp delegation system, issues to solve in above graph are: - there is a conflict for Individual(4) as he delegates on tag "t" to Delegate(2) that makes a vote on Question(1) and as he votes directly on the same Question(1). This conflict is due to the fact that Question(1) has two tags "t" and "u". This conflict should be solve by asking Individual(4) to give a preference between "t" and "u", and taking into account only one of the two votes; - there is a conflict for Individual(1) as he delegates on tag "t" to Delegate(2) and also delegates on tag "u" to Delegate(5). Both delegations are leading to a vote on Question(1). In the same way, as previously, using a preference of Individual(1), one should take only one of the two votes into account. If we assume that (i) Individual(1) prefers "t" over "u" and (ii) Individual(4) prefers "u" over "t", we have following weights: - Delegate(3)->Question(1): weight 1 as only delegation from Individual(1) (through Delegates 2 and 3) is taken into account as Individual(1) prefers "t" over "u"; - Individual(4)->Question(1): weight 1, as per choice of Individual(4); - Delegate(5)->Question(1): weight 0 as Individual(1) prefers "t" over "u"; - Delegate(5)->Question(2): weight 1, as there is no conflict for Individual(1) for Question(2) (only tag "u"). I hope this example makes the delegation system more clear. See an old email for an attempt to formalize all of this in a more rigorous way[1]: http://lists.gnu.org/archive/html/demexp-dev/2004-11/msg5.html I don't know yet how to use ocamlgraph to solve thoses issues, and even if it is possible. I started to look at algorithms that remove edges in case of conflicts but, as hopefully showed in above example, removing an edge would make the vote counting invalid. The problem is open. ;) As usual, feel free to ask questions (no pun intended). Yours, d. Footnotes: [1] There are small errors in the paper, but the overall descritpion should be valid. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Delegation and ocamlgraph: an example and a list of issues
Hello Thomas, Thomas Petazzoni <[EMAIL PROTECTED]> writes: > First of all, I'm not sure, as a demexp user that I'd be able to tell > whether I would like to prefer tag "A" over tag "B". As a citizen, I > really don't know how I could make an absolute decision to tell whether > "Ecology" is more important than "Transport" for example. So, the tag > preference mechanism solves the algorithmic problem, but does it really > solves the political decision problem behind it ? You could also have a different point of view on the issue by considering which of the two delegates (the one of "Ecology" and the one of "Transport") you trust the most for the questions having both tags. Would you find the decision easier to take? Of course, taking a decision is blured by the transitivity of delegation. > On a more general point of view, I think that the biggest issue the > demexp experience will face is the "human scalibility" problem. I heartily agree. > The delegation mechanism system is supposed to solve the human > scalibility problem generated by the number of questions in the > base. However, this pushes back the problem to the number of tags, the > management of the delegations, and possibly the management of the tag > preferences (to solve the delegation conflicts discussed > previously). Even if the tag set is supposed to be far smaller than > the question set, I think it'll still be big enough to be hardly > managed by an human person. And hope that the meaning of tags is obvious enough! I agree that we have pushed back a lot of issues into the classification system. Keeping the number of tags under a reasonnable number is probably the most obvious thing to do. For example, in Gulliver's experiment of demexp, Frédéric has created a lot of tags. I think the classifiers should agree on a basic classification, only creating new tags when only absolutely necessary. Orthogonality of tags is also important. We should probably think about a "code of tagging". But maybe we should think about the structure of tagging related to the real world. For example, if you have a tag for each city in the world, you are probably only interested to see, at first, tags related to Toulouse and France, maybe not Doha or Canberra. Regarding management of preferences, we (Frédéric, Félix and myself) assume a transitivity of preferences. So if you prefer "A" over "B" and "B" over "C", then you prefer "A" over "C". You should also consider that conflicts are solved only when they arise in a lazy way. I _hope_ it will reduce the number of conflicts to solve after a cold start period. Regarding management of delegation, I have no real answer to provide. But maybe the most sensible answer to give is to admit that most people won't vote on the majority of questions, because they are not concerned (e.g. Doha). Overall, I think we lack the "experiment" phase of demexp. I have not used demexp much to vote and navigate. So it is difficult to tell if the issues you underline are real issues or not. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Delegation and ocamlgraph: an example and a list of issues
Hello John,
skaller <[EMAIL PROTECTED]> writes:
> I would have thought it should work like this:
>
> I can delegate to A,B,C in that order to vote for me
> on issues, but I can vote too.
>
> If I vote, my vote is final, otherwise if A votes
> their vote is final, otherwise B then C, if no votes
> then there is no vote.
>
> Simple. A linear sequence, and tags are irrelevant:
> a delegate can vote on ALL issues for me.
Yes. But we wanted to be able to delegate different domains (i.e. tags)
to different delegates. Certain domains are not comparable, e.g. Justice
and Ecology.
> If you want to make it more complex, you can have
> me nominate delegates with tag restrictions, so they
> can only vote on certain issues with the tags I
> authorise. This changes nothing: there is still
> a single unique linear global ordering of delegates,
> just that some cannot vote on some issues.
Interesting suggestion. So you propose to have:
me > A("u") > B("u","t") > C(all)
A can only vote on questions with tag "u" for me.
However, I'm wondering if our proposed scheme of manual conflict
resolution (cf. my answser to Thomas) does not produce the same result:
a (linear?) ordering of delegates and their associated tags.
> The key point is: a linear order is easy to program
> and easy for voters, and anything more complex will
> be hard to program and totally impossible for voters
> to manage.
Having a system easy for voters is of crucial importance. So I'm reading
your proposal with great interest.
Yours,
d.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Re: [RFC] Using a file browser as demexp GUI?
Hello Christophe, 2005/8/31, GISQUET Christophe <[EMAIL PROTECTED]>: > > [me:] > > I'm thinking seriously at using the native file browser of the desktop > > machine as a client for demexp. That would enable easy integration > > with LFS (Logical File System) and would relieve us of most GUI issues > > (the hard graphical parts is done by the OS and desktop applications, > > we only write generic parts emulating files and folders). > > I'm not sure to understand. Is it really a file browser, like mc, > nautilus, and so on? Or is it a web browser? The second was probably > considered (would be neat), but I guess there are too many security > problems. Yes. At that time, I was thinking at a file browser. But this option was discarded because most people were thinking it would not be very natural. This then, I'm seriously considering writting a web interface to demexp. That way, no need to fight against library versions. ;-) Of course, we also open the Pandora box of web security issues. :-( > As you quote LFS, I wonder how much it restricts the supported platforms. The core of LFS is pure OCaml, so it shouldn't bring any restriction. I think it depends on an external library (ndbm or gdbm) but that one should be fairly easy to find on Windows and MacOS platforms. And if not, we might consider using another backend. > I have a hard time to grasp how most voters would work it out. I mean, it > seems very unnatural, so it's also about how to make it obvious to those > voters. That's what a lot of people are also thinking. > Have you any example of a LFS test example used in such a way, and being > still practical? LISFS still seems in the research and experimentation > side. And I still think this is going to narrow audience even more. Ok, right now LFS won't be used in following releases. I have more important things to integrate first. I still do believe that LFS could be integrated nicely without the user even noticing it but that must be proven. Thank you for the feedback, Yours, d. PS: And thank you also for compiling demexp-0.6 on Windows! ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Win32 binary for demexp 0.6
Hello,
2005/8/31, GISQUET Christophe <[EMAIL PROTECTED]>:
> Good news: it still builds
> Bad news: it exits with a fatal exception (stdout follows)
> Connecting to server tuxinette.linux-france.org:5...
> Connected to server. Try to login with ""...
> Fatal error: exception Invalid_argument("String.sub")
>
> It could be an improper installation or config file(s) from 0.4 version, I
> don't know.
The config file of 0.4 is not used. But it should not crash however. I
haven't the source at hand so I can't research more but, if you can,
you should try to run the byte code version (demexp-client.bc) with
the following environment variable set with this value:
OCAMLRUNPARAM="b"
This should gives a backtrace with function calls and line numbers.
> Could the developpers also have a --help option to configure script so as
> to list the options and their meaning?
Ok. But notice that the README provides documentation of the options.
> Also, please make some missing
> libs/progs non-fatal, or at least explain why it is fatal or what option
> it depends on. latex for instance is not a requirement, yet the configure
> will state it is missing and will not help anymore on the matter.
Well, the configure script was a first attempt and I was expecting
people like you to point out issues. I'll modify the script so that it
provides hint on option to use to avoid issues.
> This
> sounds to me too much like "read the 'fine' code" which I'd prefer not to
> comment.
You don't like my code? ;-)
> And because I guess it should alleviate either native compilation,
> cross-compiling or running under wine, you may find at the old dump site a
> binary tarball demexp-0.6.tar.bz2 and tarballs of some dependancies in
> ./deps
>
> I 'updated' compiling instructions to demexp-0.6-howto.txt
>
> Good luck with the debugging
Many many thanks for the try. From the error message I suspect the
error is in my code.
Yours,
d.
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Bug fix release: 0.6.1
Hello,
I've just released 0.6.1 version of demexp. This stable release is a bug
fix release for two annoying bugs in the client:
- the client cache was not invalidated after a vote;
- the client crashed when trying to format an empty ("") tag.
You'll find sources at:
http://www.linux-france.org/~dmentre/demexp/latest-src/
Christophe, it should fix the issue you had with release 0.6.0 when
executing it on windows.
In fact, the issue you had is quite unfortunate: you tested the client
and at the same time Philippe COVAL added an empty tag ("") in the
server. It made crashing all clients, including yours.
More details:
http://news.gmane.org/find-root.php?group=gmane.politics.organizations.demexp.fr&article=355
I have removed the offending tags on the server, so your 0.6.0 client
should work (cross fingers).
Yours,
d.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Win32 binary for demexp 0.6
Thomas Petazzoni <[EMAIL PROTECTED]> writes: > Frederic Lehobey a écrit : > >> It does not come from the client, but as explained on the demexp-fr >> list, an invalid tag '*' has been introduced in the database. I >> think only David can fix that. The invalid tag is "". > Yes, but it's still a bug if the client crashes with an exception when > it encounters an invalid tag. And yes, the bug was in the client (now fixed). However, I've also fixed the server base so current should work now. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Réunion de projet demexp / demexp meeting
Bonjour à tous, Nous comptons faire une réunion demexp le mardi 6 septembre, 19h, chez Félix Henry <[EMAIL PROTECTED]> (contactez-le pour savoir comment aller chez lui). Est-ce que cela convient à tout le monde ? Amicalement, d. --- English --- Hello, We plan to make a demexp meeting next Tuesday, 6th of Septembre, at Félix Henry <[EMAIL PROTECTED]> home (in Rennes, contact him for details on how to go there). Does it suits you? Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Win32 binary for demexp 0.6
Hello Christophe, GISQUET Christophe <[EMAIL PROTECTED]> writes: > It creates a folder .demexp in the user homedir. This folder isn't > deleted when uninstalling under win32, which is probably good. Yes. In the long term, it would be probably preferable to create this directory according to Windows rules but I don't want to dig in this right now. > Thanks for having saved me the time of doing this ;) Your welcome. :) I suppose that the 0.6.1 version is working correctly now? > I could probably strip demexp client then, as the debug symbols are > probably useless. Hmmm. You cannot strip bytecode version. And I think you cannot strip native code version neither (well, at least on Linux, due to ELF use of OCaml. Don't now for Windows PE(?)). > Patches attached. Fixed also latex quoted as required which is not > really the case. Patch applied in dev branch. > I wonder what is now my rank in direct code > contributors to demexp project :-) Your pretty close to the top. :) > I've put online an installer available here: > http://christophe.gisquet.free.fr/demexp-0.6.1.exe > > A new NSIS script was needed; it is at the same dump site. Ok, I'll update web site and update the copy of your doc in the source. Many thanks for the patch. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] cygwin latex package: tetex
Christophe, You say in your howto: Fails at latex (don't know the cygwin package) The cygwin package of latex is tetex. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Re: cygwin latex package: tetex
Hello Christophe,
2005/9/1, GISQUET Christophe <[EMAIL PROTECTED]>:
> So I installed all of those, ran almost out of space but manage to build
> the doc files. Could you check whether they look OK to you? Same place,
> files demexp-book.{dvi,pdf}
The PDF looks right. Very nice! \o/
> It also spams stdout while building files: doc/demexp-book.log is 51K big
Yep. Latex is particularly verbose but the hyperref package adds a lot
of errors. As it is only messages for developers, I don't mind a lot.
And I don't know LaTeX enough to fix those kind of issues.
Yours,
d.
___
Demexp-dev mailing list
Demexp-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Re: cygwin latex package: tetex
Fred, 2005/9/1, Frederic Lehobey <[EMAIL PROTECTED]>: > latex -interaction=batchmode whatever.tex Have you any pointer on more information about latex command line option (what is eaxctly doing -interaction=batchmode)? I'm unable to find any documentation, either localy or through google. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Re: cygwin latex package: tetex
GISQUET Christophe <[EMAIL PROTECTED]> writes: > OK. Is there any need for the file to be added to the installer ? I don't think so. It is a developer document. > btw, I guess you recently read the howto to make such a comment. Are you > going to try something ? Sorry no. I just integrated you document in my Arch tree. > Anyway, If a win32 maintainer/packager steps up and he lives in the > area of Rennes, France, I could offer him some direct help with > setting up cygwin and co. Thank you. You efforts are highly appreciated. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Misc. stuff about win32 demexp
GISQUET Christophe <[EMAIL PROTECTED]> writes: > first, I've moved all files up one level. New base URL: > http://christophe.gisquet.free.fr/demexp/ I have updated the web page on Savannah. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
Re: [Demexp-dev] Ubuntu Hoary Packages
Hello John, 2005/9/8, skaller <[EMAIL PROTECTED]>: > BTW: in case it isn't clear, I'd be more than happy to > build amd64 binaries for this project. If I can actually > build the dang dependencies, I'll build from the repository > next (and hope the amd64 code generation bug doesn't strike: > I have ocaml-3.08.4 which fixes the problem, but not the > Debian package ..:) Maybe you can start by building only the client. It relies only on labgtk2 and, unfortunately, ocamlgz, but not cduce, etc. Use --no-server at configure step. And before trying to automate the building as Thomas has done, maybe you can simply build it in your Godi AMD-64 environment. Regarding ocamlgz, the simplest way is probably to look at the code (or even the ./configure) to find what is going wrong and to fix it. As building compiler producing C++ code, I suppose you know enough about data structures and C to sort out the issue. Yours, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
