[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r23519 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r23519 - gnunet-java |
Date: |
Thu, 30 Aug 2012 08:54:32 +0200 |
Author: grothoff
Date: 2012-08-30 08:54:32 +0200 (Thu, 30 Aug 2012)
New Revision: 23519
Modified:
gnunet-java/ISSUES
Log:
answers
Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES 2012-08-30 00:49:00 UTC (rev 23518)
+++ gnunet-java/ISSUES 2012-08-30 06:54:32 UTC (rev 23519)
@@ -4,6 +4,8 @@
* illustrates using program/service, using the configuration, creating
messages
* works with os control pipe / arm (see below for problems with arm)
+RE: Great.
+
* i tried merging gnunet-testing and gunet-testing-run-service, but failed :(
* gnunet-testing-run-service uses GNUNET_TESTING_service_run
* which can't be run from within the main called by GNUNET_PROGRAM_run (as
the scheduler is already running)
@@ -12,23 +14,44 @@
* so what about the default arguments?
* does it really make sense to merge them, functionality-wise?
+RE: Hard to say; while there are ways to work around the problem you mention,
there is clearly
+no need for great hacks to force the merge; let's leave them separate. Maybe
rename gnunet-testing-run-service
+to gnunet-helper-testing-run-service to make clear that it is a "helper"
process and not something meant to be
+run by users from the command-line...
+
+
arm-4477 WARNING Configuration file `(null)' for service `greeting' not valid:
option missing
+RE: you need an entry "CONFIG = $DEFAULTCONFIG" in [greeting] in your
greeting.conf[.in]
+
+
even when not using the signal pipe, does arm really kill processes?
* arm does never seem to send a sigkill if process does not respond
* sometimes arm command hangs!
+RE: ARM waits for the child to terminate, this would seem like hanging; when
not using a signal pipe,
+ARM will send a POSIX signal and then do "wait". What happens is then up to
the child...
+
+
$ gnunet-arm -c config/greeting.conf -k greeting -LDEBUG
Aug 29 19:25:22-808046 arm-api-5971 INFO Stopping service `greeting' within
60000 ms
Service `greeting' was already not running.
+RE: might relate to the 'CONFIG' option missing above...
Aug 29 18:21:19-505909 arm-4751 ERROR Failed to start service `greeting'
Service `greeting' has been started.
+RE: Again, this might relate to the 'CONFIG' option missing above, but is the
inconsistency of
+the messages given is certainly a bit odd. Should be investigated.
+
logging with arm: what gets piped to where
* seems like service stdout->/dev/null, service stderr->arm stderr
+RE: stdout should never be used by services, especially not for logging; where
'stderr' goes (logfile, arm's stderr)
+depends on the configuration;
+
+
Construct: has gotten very complex, i'm currently trying to trace a particular
bug
* UPDATE: bug is gone!
* unit tests for construct have gotten better, still not good enough
@@ -40,6 +63,9 @@
Question: Is all this too complicated? Should I invest the time to fix things
as they are now intended, or should
we simplify?
+RE: How would you simplify it? I don't recall us having significant
unwanted/unnecessary functionality, do we?
+
+
* found some problems with timeouts in client/connection.
* should i write unit-tests for this timing-stuff?
* UPDATE: should be fixed now!
@@ -50,51 +76,79 @@
* we must use System.exit(n) instead
* how about a (Program/Service).exit(n) that does cleanup and then calls
System.exit(n)?
+RE: the user writes a 'main' function which (usually indirectly via
program/service) invokes the
+ scheduler; after that invocation returns to 'main', 'main' should call
System.exit(RV). I don't
+ see a need to integrate this call with org.gnunet.util.
+
* configuration: what is $DEFAULTCONFIG? and CONFIG=?
+RE: it is possible to pass a custom configuration file for one of the
services, instead of using the
+same configuration file for all services; rarely used feature. $DEFAULTCONFIG
== "this config".
+
+
mesh:
* we can't use multipe instances of org.gnunet.mesh.Mesh to test the API
* the local peer can't be the peer on the other end!
+RE: why not? C tests do this AFAIK.
* the C-api has practically no coverage on mesh_api.c
+RE: don't understand
* see below for a suggestion!
* LOCAL_TUNNEL_CREATE was used for two things, creating tunnels and being
notified about incoming tunnels
+RE: that sounds, eh, not great... => check with Bart?
* extending org.gnunet.testing so that multiple peers can be started and
communicate with each other!
* the C-testing-api allows to create multiple peers, but they don't seem to
be able to communicate with each
other!
+RE: Matthias said that transport was having trouble again these days...
* => the peers should somehow exchange their hellos / use a shared directory
for the hellos
+RE: yes, you'll need transport API implementations to call 'try_connect' and
to get and exchange HELLOs
testbed vs testing: is this correct?
* testbed for large-scale testing across many "real" nodes
* testing for testcases on one host
+RE: Almost right; testing is a little helper library for testbed, useful for
small-scale tests with
+ simple setups; testbed is for multi-host deployments AND for more complex
single-host setups
+ (specific network topologies, etc.)
* test coverage approaching a better state, any feedback?
+RE: buildbot integration to run against C SVN HEAD would be nice to have...
* I think there should be some documentation in addition to the source code
and the tutorial
* what would be the preferred format for such documentation? latex?
+RE: JavaDoc for API documentation; HTML on website for code overview-level
stuff, LaTeX for
+ tutorial; we might also write something more like a paper in LaTeX at some
point, but
+ I'm not sure about that yet;
* (considering that they perhaps should end up on a website / should be
browsable)
* examples:
* how do unions work in construct?
+RE: JavaDoc and a webpage on Construct in HTML
* other stuff in construct
+RE: => webpage on Construct in HTML
* how does annotation processing work?
+RE: => sub-section in webpage on gnunet-java build system
* project layout - what goes where
* as there is no standard java project layout
+RE: => code overview chapter in webpage on gnunet-java
rationale for putting org.gnunet.testing in the src/-tree, not in test/:
* when developing an extension for gnunet-java, the developers may want to
access the testing functionality from
the jar, so it should be included there!
* the code itself is tested, we want coverage etc.
+RE: both are good reasons.
* is there an effort to document what hostkeys files are etc.?
+RE: not yet, might not be a bad idea; do you want to write something? :-)
continuous integration: using Jenkins (=Hudson, forked away from Oracle)
* easier to configure than buildbot
* support for displaying JUnit reports out-of-the-box
* support for cobertura via plugin
* but not very stable
+RE: is that a suggestion or something you already finished? If not finished,
did you try it? (just asking...)
for junit reports we need ant/gradle!
+RE: I saw the gradle build file.
build system: still maintaining bash scripts, trying out gradle
* faster builds, build scripts far easier to read/write
@@ -103,17 +157,28 @@
* gradle has excellent Ant integration => Coverage (bash wrapper not very
usable)
* can generate project files for eclipse/intellij
* would make stuff like installing gnunet-java from source easier than using
izpack
+RE: As the gradle config is trivial, no harm in *also* having it; not sure
about
+ obsoleting izpack (as izpack is the template for an installer for
end-users,
+ not for eclipse integration...); maintaining two build systems (one for
cobertura,
+ one for ant/eclipse/junit/jenkins?) might be OK, but of course is not
ideal.
what's next?
* some actual stuff built with gnunet-java?
+RE: Yes. Krista is supposed to e-mail you some papers to read, then we'll
decide on some fun protocol to implement!
+
* general question: when should an api use per-connection receive, and
per-service-receive?
+RE: I don't understand the question.
does this make sense / do we need it:
* support in the scheduler for communicating asynchronously with other
processes via stdin/stdout/stderr
+RE: see util's helper API in C -- that's where we do use this; so _eventually_
we might want this.
* currently only used in testing, uses blocking i/o
+RE: blocking IO is always deadly eventually; so we should probably add async
IO for pipes to Java scheduler
* stream is implemented as a library, not as a service
* why?
+RE: various reasons, performance, KISS, statelessness of a stream, ...
* should GNUnet-java also implement it?
+RE: maybe, but certainly not yet, stream is still to experimental anyway
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r23519 - gnunet-java,
gnunet <=