I remember fidonet! :) what's with the flurry of activity here recently? ehjay: You mean johnvk, or something else? Yesterday I finally gave the conference presentation about Vesta I've been working on. So I should be able to relax and refocus a bit now. thought for xorian: What about "mount /vesta @17:34-31-12-2005" (conceptually) i.e. ability to re-mount the SCM "as it was on the specified timestamp" I *think* all the required stuff to make that doable is already fundamentally in vesta It sounds quirky, but ... very powerful. Being able to say "I did something based on what the repository looked like 3 weeks ago, but it was outside vesta, can I see what the repository did look like 3 weeks ago?" and have it one effortless operation - just mount e.g. "/vesta-last-month" On a personal hard-drive, this kind of feature is a godsend: can't remember where you filed something? Or what the old version of file X looked like? ... just instantaneously prune out all the files that didn't exist, and revert all the others Came up as an idea when we were talkinga bout the repeatability of testing especially experiemtns-you-did-along-the-way-to-something-else which you didnt check in, and used whatever was around at the time Odd, perhaps. Perhaps others can think of better uses :) ? Anyone got a sample vrepl comand-line to hand that works? Trying to replicate off vestasys.org but failing I know it's getting to the host OK, because I tried some bogus hostnames, but it's just sitting there apparently doing nohting :( Also it would probably be a good idea to check-in a newer version of java, it's now on 1.5.0_04, whereas we've got _02 in beta.vestasys.org (is there an issue with checking in too many versions?) each _xx release of java fixes large numbers of bugs, sadly ircsucks: if you don't run vrepl with -v it will just appear to be sitting there. I did run with -v, and it had no effect :( vrepl -v -s vestasys.org -e+ /vesta/beta.vestasys.org/platforms/linux/sun/ ircsucks: s/vestasys.org/pub.vestasys.org/ Just sits there for ages. Eventually returned, but nothing had happened. Does -v ouptut nothing if nothing changed? Ah! that works thanks vestasys.org as a hostname gets you to the sf web farm. can't replicate from there very well... now if only we could convince them to start running vesta... ;) But no error message and a long timeout, sadly :( ircsucks: probably because they have port 21776 firewalled to drop incoming packets rather then reject them. grumblemutttercursesmumble Ah...I dont suppose anyone has a short build-ves for using the java bridge checked in as part of swig etc do they? :) there is something in swig... let me pull it up. I'm wading through swig build.ves's trying to work out how much of it I need and how much I don't and no idea whether there's some easy ves I could import and should just be importing that does most of the work for me :( basicaly, all you need to compile java is http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/beta.vestasys.org/vesta/extras/swig/latest/build.ves line 112 through 116 perhaps I can just evaluate vesta/extras/swig/6/linux_i386.main.ves and dig into that (it has a "bridges" within it that contaisn what looks like it might be a preconfigured java bridge?) OK (ignoring my last comment) But I have to import and evaluate some number of bits of swig first? you're trying to build a java program that uses the swig libs? I'm trying something I probably shouldn;t :) did you look at the vls.java example? ah, no, didn't know about it :( http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/beta.vestasys.org/vesta/extras/swig/latest/examples/java btw, you probably want to be using swig/8, not swig/6 Ah, thanks Right, idiot question: what exactly is SWIG, because I've had trouble rmembering it since inception :( simplified wrapper interface generator. it's a way of turning c/c++ libraries into libraries/modules/etc that are usable from any number of target languages. in our case, we make some of the core vesta client librareis available in perl, python, tcl, and java. Basically, I know there's a java bridge in there that I wrote, but I dont have my original copy to hand, and I was hoping to just use it, but I also know it's been improved to be less quirky and I'm struggling to see how I can use that java bridge just for plain java compilation Right. Thanks ahh. so you don't need any of the swig stuff. indded. But since I couldn't quite remember what SWIG did, I wasn't sure if I did or not :) I think you just need the lines that mention java or jdk out of the swig linux_i386.main.ves and then a build.ves that does ./java/compile(java_files); and possibly ./java/jar(class_files); but, I'm not a java programmer, so I can't give any more info then that. thanks, that's what I was heading towards. Now I just need to refresh my knowledge about ultra basics, like setting up the basic env :) once we finish getting the addon stuff setup it'll get easier... you'll just ask for the java addon and all the rest of the setup junk will get taken care of for you. trying to find that bridge tutorial :) since I recall it has the std-env-building stuff in it at the head, IIRC gah. Can't seem to find that bridge page (about lex, yacc, etc) and cant get my std-env setup. Sigh. http://www.vestasys.org/doc/sdl-ref/bridge-dissection.html - found it, solved :) Right. Finally got as far as invoking the bridge against a source file and it getting to the run_tool invocation :) Although it's failing :( Although it's failing :( oh, is that a hint for me to chime in with sage advice? :) sorry, just typing on wrong kb momentarily I'm sure it's some stupid error I'll spot in a sec... I think I'm just not getting the files in in the right way to start off with. hmm. the src files java files, I mean I have the jdk and the java_bridge all setup now, thanks :) scottven: I dont suppose you know if the source files have to "be" anywhere special in the virtual FS for the bridge tocompile them? SWIG seems to just accept them as args to the compile method (and in that vls example you gave thats seems to be the same) and that's what my original version did But, run_tool keeps complaining it cant find the source file (presumably the javac is asking for that source file, but not getting it :( ) ircsucks: I don't know anything about it. :) <-- not a java guy. About now, I'm wishing I'd coded some runtime-invokable debugging flags into that bridge This is not to do with java, it's to do with me not passing things in the right way /place for the bridge to even pick them up, I think compile(/**pk**/ sources: NamedFiles ): binding . ++= [ root/.WD = sources ]; / Put the names of the sources into a file... inputfile = generateFileListOfSources( sources ); // ...bind that file into the FS . ++= [ root/.WD = inputfile ]; (and then I pass the param to javac that means "read the list of source files you have to compile from the file "inputfile" ) so it looks like the sources param should jsut be a binding of a bunch of files... no directory structure. Ah! /me spots something No. didn't work :( rats The thing is, I wrote the bridge to basically "go through all files in the binding, work out their fully qualified relative path names, put that into the file" so that it ends up just processing the files that are in whatever binding you pass in using their relative names, e.g. if binding is [ a/b/c = aaa ] then the file would have: "a/b/c/aaaa" Although I'm confused because I dont see any line in other pkgs which work which actually puts the source files into ./anything, so I'm confused how the birdge would even be able to see them oh, unless it extracts them from what's passed in as an arg. Oops. Obvious that Odd. idiot question I need to solve this whole mess: Why is it that: . ++= [ root/.WD = jdk() ] puts the whole of jdk() in the .WD in the chroot when evaluating the javac tool but: . ++= [ root = jdk() ] puts nothign in the chroot um... it should work. it's OK, I had a typo :) And I got it all working in the end. Yay yay rather embarassing that it took so long, but... eh, it happens to the best of us. begins importing x86-64 .debs ircsucks: On that idea of mounting the repository as it was at some point in the past: That would definitely be non-trivial. The repository doesn't currently store enough information to do that. Example #1: At the requested point in time, mutable files in /vesta-work may have had contents which never became immutable and thus aren't stored anywhere. (Think rewriting a file multiple times between vadvance calls.) Example #2: If anything in the appendable directory replaced by a ghost (i.e. deleted with vrm), the repository will throw away its contents. This includes file contents and directory structure. (Actually, it will hang around until the next weeder run, but not in a way that's recoverable.) I could go on with several more, but you get the idea. ircsucks: Anyway, I'm not clear on what the point would be other than to repeat a run of some script that uses attributes or the existence/non-existence of certain versions. ircsucks: Any actual versions which the user might refer to would still be there (unless they've been ghosted, though there might be other newer versions). While I realize users sometimes just look at the latest version and don't bother to note down which specific one that was, I'm not sure how much we can really do to help them with that. Maybe a tool to tell them which version was the latest at some point in time? Well, I build Vesta for x86-64 with the make-based kit. I used that to get the repository mounted and the RunToolServer up. Now I'm building Vesta again using Vesta, which seems to be working. I've finished building for x86-64 using Vesta. Tomorrow I'll get test-vesta running on my x86-64 box.