On Friday 28 December 2001 03:07, Tavin wrote: > cvs -z3 -d:pserver:anonymous at cvs.freenet.sourceforge.net:/cvsroot/freenet > co -r new_datastore Freenet cvs -z3 > -d:pserver:anonymous at cvs.freenet.sourceforge.net:/cvsroot/freenet co > Contrib > > then: > > export CLASSPATH=.:Contrib > mkdir build > javac -d build Freenet/node/Main.java Freenet/client/*.java > Freenet/client/cli/*.java > > or: > > cd Freenet/scripts > export CLASSPATH=../../Contrib > make node client > > > You can also give 'make node client JIKES=true' or, theoretically, > 'make node client KAFFE=true' (can someone test this?). > > This builds the node and CLI client. the fproxy target cannot be built > at the moment (Freenet/client/http/*.java Freenet/client/http/filter/*.java > Freenet/support/StripedBucketArray.java) because there were some changes > made in the routing table that broke the NodeStatusServlet. i will try > to fix this as soon as i can, but i'd like to discuss it with GJ first > because there is now a much more powerful system for getting diagnostic > information out of the routing table. For the moment just delete Freenet/client/http/NodeStatusServlet.java from your local tree after you checkout. Fproxy shouldn't have any dependancies on the DataStore or RoutingTable.
Maybe there are issues with InternalClient or modified Freenet.support.* classes. It would be good to find out earlier than later. I am busy today, but I will take a look at what it takes to resurrect NodeStatusServlet later on tonight (EST). I will also be on IRC. > > > Please reply to this thread if these build instructions do not work for > you. > > > The node does not currently work; the new code does need some > debugging. I think the fastest way to do this right now is to write > unit tests for the classes that are causing problems. > > The other thing that we might want to do soon is implement > Freenet.fs.dir.NativeFSDirectory -- this is a "void" implementation of > the new datastore API that saves to individual files instead of the > single datastore file. In retrospect we probably should have done > this much earlier. One reason I think we didn't is because the > interface for doing that wasn't clear. Now it is: > Freenet.fs.dir.Directory. > > Doing this could allow the node to stabilize much more quickly at the > cost of doing without the single-file datastore. After it was perfected > (within a few weeks), we could offer both choices in the config file. > > > I'm currently working on an extensive new unit test for the red-black tree > since it was heavily modified and is core to the routing table and the > whole accounting system for the new datastore. > > > Thoughts on any of this? Could you write up short descriptions of your synchronization and rollback/commit strategies. That would help people reading the code figure out what is going on more easily. Also, there was something I didn't get in DirectoryRoot.update. It looks like you inc root_no and proceed even if there's an exception. It seems like you should be rolling back. Can't this cause you to trash the last known consistant version of the accounting data on disk? -gj -- Freesites (0.3) freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage// (0.4) freenet:SSK at npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
