6800+ entries in 0.02s
mod6: from_ffa: sorry I missed ya on here. but for now, yeah, that behavior is intended.
mod6: if this behaviour should be changed, before next release, now is the time to get your opinions heard.
mod6: thread begins here ^
mod6: based upon some commentary (going by memory here) lead us to the decision to delete the press directory even if it existed and then create a new directory even with the same name and re-press.
☟︎ mod6: <+ben_vulpes> at least ~/workspace << i gotta dig this up from the logs. but older versions of v.pl actually *would not* over-write the original dir, would fail and say 'dir exists' or something.
mod6: i like the bot idea
mod6: ugh, yeah. i'd just put it down/shoot it if it was suffering.
mod6: yeah, no sense in letting a good dog go to waste
mod6: mircea_popescu: aha.
mod6: but yah, anyway, was pretty unreal. haha.
mod6: can't shoot those here.
mod6: na. i saw it get up, had it in my sight picture, could have pounded it. was only like 10 yds from me. but when i saw the tail feathers fan out, i let off.
mod6: mircea_popescu: ah, yeah, that'd be great
mod6: i went hunting on sunday and the dog flushed up what I thought was a hen. was a hawk, eating a hen!
mod6: <+shinohai> mod6 would be proud of me, I managed a pair of quail the other weekend when it snowed. << niiiiice!
mod6: <+mircea_popescu> if mod6 came by all nonchalant like and was "hey, i shot a 350 lb shrimp today" what i;d expect the steak to taste like would be ~alligator. << yeah, probably would!
mod6: or did i hallucinate that?
mod6: i may be mis-remembering this, just thought there was a plan to take the disassembly and produce asm that you would then fabricate possibly?
mod6: asciilifeform: you're gonna do the asm unroll with the bounds checks tho right/
mod6: mircea_popescu: hey, ok! way behind on things, but otherwise good.
mod6: i did just press & compile up through chapter 6 successfully. so that works at least.
mod6: i use that adacore version fwiw
mod6: ok. i've not seen any error like that for sometime now, definitely predates the recent loper-os posts.
mod6: everything pressed ok right esthlos ?
mod6: then ill dig into the tmpdir thing. i want to ensure that the bug fix i've made is correct before I proceed.
mod6: Ok, will look into a better way to handle this. I appreciate your passionate want to make this better.
mod6: in the case of failure, i could try to remove the tmpdir during the 'Death()' call or something. But with interrupted execution, there's no way to know when the interrupt is coming. Nothing to do about it here.
mod6: So here's what I'll do: I'll revisit this, and try to come up with a unique tempdir. This tempdir is to be used exactly once. Created at run time. Removed at the end of run time. If execution fails or is interrupted, nothing will be done. It'll be left hanging there until the user removes it manually.
mod6: And I've taken a bit of a different direction, perhaps because of 'File::Tempdir' or some nonsense.
mod6: It seems that asciilifeform has been saying the same thing all along.
mod6: lemme break off here for a minute, i'll keep digging up the logs to prove we talked this over.
mod6: anyway, i appreciate all the feedback. its obvious that there is passion to get this part of my vtron right.
mod6: i gotta find these logs. im actually now convinced that we've discussed this very item not just once, but maybe even 3 or 4 times.
mod6: and here's where we come full circle. :]
mod6: and i don't think people want 1Mb of shit dumped to stdout
mod6: it sounds like my idea of "have something of a corpus to look at after failure" isn't as handy as simply just throwing it out.
mod6: anyway, we'll figure something out. that part im not worried about.
mod6: the good news is, hopefully, your pgptron will be built into any new vtrons
mod6: <+asciilifeform> mod6: afaik this dun actually happen on any known unix << this the rub tho. have to make sure that it actually /NEVER/ happens. i can't have people failing in anyway with this thing.
mod6: sorry, lemme read back here. was just trying to type there.
mod6: which worries me about /tmp being flushed mid, or at anytime during execution.
mod6: maybe mktmpdir is sound for that. however, i remember discussing that before as well..and one fear that i had is that if you use mktmpdir, then you have a /tmp/23429adfsew32 dir.
mod6: before i ever 'green light' that kinda use of my vtron, i'd certainly like to test it myself etc. and ya, that dir would have to be unique.
mod6: now, for the concurrent part... now that's something I never did consider.
mod6: anyway, if you see a .gnupgtmp, something failed. either the software failed, or the user interrupted the thing. either way, the responsibility has been on the user to determine if he should delete ~/.gnupgtmp or not.
mod6: i shouldn't say a lot. from time to time, one of alf's previous key ones would creep into ones flow or whatever, and you may want to check for yourself weather it verifies or not. or what gnupg might have been up to while executing v.
mod6: and if it did fail, then perhaps one can go and look at what went on -- at the time, there were a lot of seals that didn't verify for instance.
mod6: its basically a failure state -- .gnupgtmp should only be around if something FAILED.
mod6: the idea behind leaving the .gnupgtmp around after execution, is there because i wanted it to be there. not weather this is the Right Thing or not.
mod6: so previously, and im still digging in the logs...
mod6: i hope you're not trying to say that im simply making this up
mod6: my vtron has been discussed very much over the last 2+ years. i remember many disucssions where rules popped out.
☟︎ mod6: <+ben_vulpes> logs save us from the "but i thought we agreed" floppy meatsack memory. << i feel ya. if you wanna help me dig, that'd be awesome.
mod6: and the details of what the change is to do are clear so I can implement them as such.
mod6: anyway, im fine with changing whatever, just as long as we all agree.
mod6: i know, i haven't had a chance to look yet.
mod6: <+asciilifeform> second , as in the case discussed in the thread, if a run aborts, it creates a mine for next run to step on. << try to realize that this is on-purpose. im certain that we've had this discussion before and what exists is the outcome of that discussion.
mod6: <+asciilifeform> no good. first of all suppose there are 2 concurrent runs of the vtron ( say this is a cuntoo pressing itself ) << yeah, concurrent runs of my vtron are a no-go.
mod6: asciilifeform picture scene from film 'idiocracy', where hero gets 'his name', 'Not Sure', tattooed on forehead << his arm, but yeah, great movie.
mod6: my $tdir = get_homedir() . "/.gnupgtmp";
mod6: the keyring that gpg needs to run
mod6: sub remove_tmpdir { my ($dir) = @_; `rm -rf $dir` if -d $dir;
mod6: sub make_tmpdir { my ($dir) = @_; `mkdir -p $dir && chmod 0700 $dir` if !-d $dir or die "$dir exists! $!";
mod6: i don't have a chance right this moment to do that, will look tho when i can
mod6: now, i can add an attempt to remove the thing before we even begin main(), but i thought we had discussed this. i'll have to dig up the old thread.
mod6: and if you ^C the thing mid-way through the execution, you'll never hit remove_tmpdir
mod6: that's basically what happens ^
mod6: remove_tmpdir($tdir);
mod6: make_tmpdir($tdir);
mod6: <+asciilifeform> mod6: an aborted run of vtron should not be able to put a caltrop for subsequent run to die on. this is imho elementary.
mod6: im getting pulled off here... i'ma try to circle back to this but...
mod6: im pretty sure we all had this discussion once upon a time, and it's only doing now, what we agreed to do before. I can go and dig for that.
mod6: otherwise, my vtron handles the creation and deletion of that .gnupgtmp dir on its own.
mod6: <+ben_vulpes> mod6: while you're in there can you get your vtron to cleanup its tmp gnupg directory when it catches a ctrl-c? << if you CTRL+C the thing, it really can't get rid of it. you're expected to clean this up on your own so the vtron doesn't remove something it wasn't suppoesd to.