Comments on: v.sh parts 2.5 and 3: one-binary Ada solver and Ada vfilter implementation http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/ Fri, 21 Aug 2020 17:09:09 +0000 http://polimedia.us hourly 1 By: Diana Coman http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-155 Diana Coman Mon, 02 Mar 2020 22:36:40 +0000 http://bvt-trace.net/?p=72#comment-155 @bvt Right you are, that's probably the most logical solution there actually. For the press/vdiff since I made <a href="http://ossasepia.com/2020/02/05/the-v-tree-nursery-or-code-control-with-v/" rel="nofollow">those scripts for code control</a>, I just use them but your solution is even more straightforward in fact. Unrelated but since I finally remembered *before* sending the comment: the vtools still have that Makefile that just packs the gprbuild commands for the various tools - to my mind it should either be updated so at least one can build each and all of the new tools as well or possibly just ditched entirely if it's not used/useful. @Mircea Popescu Basically, I agree. So it's up to bvt now, whatever he prefers to have in there! @bvt Right you are, that's probably the most logical solution there actually. For the press/vdiff since I made those scripts for code control, I just use them but your solution is even more straightforward in fact.

Unrelated but since I finally remembered *before* sending the comment: the vtools still have that Makefile that just packs the gprbuild commands for the various tools - to my mind it should either be updated so at least one can build each and all of the new tools as well or possibly just ditched entirely if it's not used/useful.

@Mircea Popescu Basically, I agree. So it's up to bvt now, whatever he prefers to have in there!

]]> By: Mircea Popescu http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-154 Mircea Popescu Mon, 02 Mar 2020 19:08:22 +0000 http://bvt-trace.net/?p=72#comment-154 I don't think it's a very important thing tbh ; I have a slight preference for literalism as an approach to life, but in the end it costs more to try and distinguish the costs/benefits of the two approaches than the difference could ever justify. I suppose bvt's symlink solution is actually why symlinks even exist in the first place. I don't think it's a very important thing tbh ; I have a slight preference for literalism as an approach to life, but in the end it costs more to try and distinguish the costs/benefits of the two approaches than the difference could ever justify. I suppose bvt's symlink solution is actually why symlinks even exist in the first place.

]]> By: bvt http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-153 bvt Mon, 02 Mar 2020 07:43:47 +0000 http://bvt-trace.net/?p=72#comment-153 @Diana Coman: The way I solve this issue -- it arises with vdiff as well, where you have a hard requirement for having "a" and "b" directories (not in the tool, but in the work process) -- is with symbolic links. I.e. there is a directory future_vpatch_name, which gets symlinked to "b", and intended antecedent, symlinked to "a". If switching the symlinks requires too much time, a set of scripts can make this rather pleasant. @Diana Coman:
The way I solve this issue -- it arises with vdiff as well, where you have a hard requirement for having "a" and "b" directories (not in the tool, but in the work process) -- is with symbolic links. I.e. there is a directory future_vpatch_name, which gets symlinked to "b", and intended antecedent, symlinked to "a". If switching the symlinks requires too much time, a set of scripts can make this rather pleasant.

]]> By: Diana Coman http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-152 Diana Coman Sun, 01 Mar 2020 20:46:38 +0000 http://bvt-trace.net/?p=72#comment-152 @bvt That looks fine to me, re 2. I still need to look into what is wrong with the script/output on my machine - I half suspect some specific version(s)/settings, hm. @Mircea Popescu <blockquote> It seems to me however that I misunderstood what you were saying ; it had nothing to do with any of that, it was a simple "if you're going to use magic numbers, pass them by reference rather than directly please", </blockquote> Passing them by reference rather than directly is what I was saying, indeed. This being said, it possibly grew into way more than it should have, to start with - it was more of a itch rather than anything that I can't live with,otherwise. The concrete use case I have for it is mainly when I have the patches for something in a dump rather than neatly in "patches" but at all times *renaming a dir* is anyway so easy as to make it a non-issue, indeed. Looking at it though, I think you are right in that I have some increased sensitivity to the pass by reference rather than directly, due to ...exposure, let's say. It's true. <blockquote> Now we want to improve this by applying the above principle. First, we have to find names for the references ; and we want to make them good. How about "Name_Of_Directory_Holding_The_Web_Of_Trust = 'wot';" ? </blockquote> No, not really and precisely for the reason you said initially - namely that "let the names be standardized". So there's no reason for that Name_Of_Directory_etc because that whole string is indeed fixed as wot, there is already a name for it. In my view however, this standard name means in code-terms the standard name of the *variable* rather than the contained magic-string. It's true that most programming languages are shit with strings so I can see the point that it adds unnecessary potential failure modes but note that having to manually write the strings everywhere is *also* prone to error, there's no ideal way around this sort of thing. Overall, I don't think there's a huge gain/loss either way really so if you consider it to be a very important thing, I'm fine with it either way really. I don't see a real gain in not-using the pass by reference (since all the "added" stuff is really just the $ sign instead of two " " and otherwise the initial declarations + init of those variables, not at all the full blown bureaucratic angle there, no) but again, I don't see a huge loss at this point either. @bvt That looks fine to me, re 2.
I still need to look into what is wrong with the script/output on my machine - I half suspect some specific version(s)/settings, hm.

@Mircea Popescu

It seems to me however that I misunderstood what you were saying ; it had nothing to do with any of that, it was a simple "if you're going to use magic numbers, pass them by reference rather than directly please",

Passing them by reference rather than directly is what I was saying, indeed. This being said, it possibly grew into way more than it should have, to start with - it was more of a itch rather than anything that I can't live with,otherwise. The concrete use case I have for it is mainly when I have the patches for something in a dump rather than neatly in "patches" but at all times *renaming a dir* is anyway so easy as to make it a non-issue, indeed.

Looking at it though, I think you are right in that I have some increased sensitivity to the pass by reference rather than directly, due to ...exposure, let's say. It's true.

Now we want to improve this by applying the above principle. First, we have to find names for the references ; and we want to make them good. How about "Name_Of_Directory_Holding_The_Web_Of_Trust = 'wot';" ?

No, not really and precisely for the reason you said initially - namely that "let the names be standardized". So there's no reason for that Name_Of_Directory_etc because that whole string is indeed fixed as wot, there is already a name for it. In my view however, this standard name means in code-terms the standard name of the *variable* rather than the contained magic-string. It's true that most programming languages are shit with strings so I can see the point that it adds unnecessary potential failure modes but note that having to manually write the strings everywhere is *also* prone to error, there's no ideal way around this sort of thing.

Overall, I don't think there's a huge gain/loss either way really so if you consider it to be a very important thing, I'm fine with it either way really. I don't see a real gain in not-using the pass by reference (since all the "added" stuff is really just the $ sign instead of two " " and otherwise the initial declarations + init of those variables, not at all the full blown bureaucratic angle there, no) but again, I don't see a huge loss at this point either.

]]> By: Mircea Popescu http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-151 Mircea Popescu Sun, 01 Mar 2020 17:23:51 +0000 http://bvt-trace.net/?p=72#comment-151 @Diana What is to be gained from the user puting his wot in .berniesandals2020 rather than .wot ? By anyone, I mean, what conceivable benefit could it ever deliver ? Sure, it's the user's machine. It's also your code. If he thinks "comments should be gender neutral" because "it's his machine" what, I'ma have a gender variable in the comment parser ? It seems to me however that I misunderstood what you were saying ; it had nothing to do with any of that, it was a simple "if you're going to use magic numbers, pass them by reference rather than directly please", which is a sound principle but substantially a different thing and, importantly, I don't think it applies here. Consider the following schematic program : a = read ('./wot'); b = read ('./seals'); c = read ('./patches'); do things; Now we want to improve this by applying the above principle. First, we have to find names for the references ; and we want to make them good. How about "Name_Of_Directory_Holding_The_Web_Of_Trust = 'wot';" ? That should work ; our schematic program now becomes : Name_Of_Directory_Holding_The_Web_Of_Trust = 'wot'; Name_Of_Directory_Holding_The_Seals = 'seals'; Name_Of_Directory_Holding_The_Patchset = 'patches'; a = read ('./'.Name_Of_Directory_Holding_The_Web_Of_Trust); b = read ('./'.Name_Of_Directory_Holding_The_Seals); c = read ('./'.Name_Of_Directory_Holding_The_Patchset); do things; We've gone from four lines to seven (+75%) ; from 76 bytes to 330 (+334%) and we're also using no less than THREE string concatenation operations between an absolute and a reference, which we're both likely to fuck up, and are likely to by their nature suck. All this so the putative user is saved the (apparently notable) inconvenience of sed 's^./wot^./berniesandalstotallycouldfixtheeconomy^g' ? Because it's his machine ? What sense does this make! At no point will the references be shorter than the directory names as they stand, in which case the replacement is an increase in both brute length and code complexity. There's just nothing gained here, I can appreciate that your experience with the planeshift/creepspace insane clown possee riled you up some, but we're using directories sanely (as we regard them as namespaces, ie gns subspaces in the first place), as opposed to haphazardly. What's so wrong with doing it simply ? @Diana What is to be gained from the user puting his wot in .berniesandals2020 rather than .wot ? By anyone, I mean, what conceivable benefit could it ever deliver ?

Sure, it's the user's machine. It's also your code. If he thinks "comments should be gender neutral" because "it's his machine" what, I'ma have a gender variable in the comment parser ?

It seems to me however that I misunderstood what you were saying ; it had nothing to do with any of that, it was a simple "if you're going to use magic numbers, pass them by reference rather than directly please", which is a sound principle but substantially a different thing and, importantly, I don't think it applies here.

Consider the following schematic program :

a = read ('./wot');
b = read ('./seals');
c = read ('./patches');
do things;

Now we want to improve this by applying the above principle. First, we have to find names for the references ; and we want to make them good. How about "Name_Of_Directory_Holding_The_Web_Of_Trust = 'wot';" ? That should work ; our schematic program now becomes :

Name_Of_Directory_Holding_The_Web_Of_Trust = 'wot';
Name_Of_Directory_Holding_The_Seals = 'seals';
Name_Of_Directory_Holding_The_Patchset = 'patches';
a = read ('./'.Name_Of_Directory_Holding_The_Web_Of_Trust);
b = read ('./'.Name_Of_Directory_Holding_The_Seals);
c = read ('./'.Name_Of_Directory_Holding_The_Patchset);
do things;

We've gone from four lines to seven (+75%) ; from 76 bytes to 330 (+334%) and we're also using no less than THREE string concatenation operations between an absolute and a reference, which we're both likely to fuck up, and are likely to by their nature suck. All this so the putative user is saved the (apparently notable) inconvenience of sed 's^./wot^./berniesandalstotallycouldfixtheeconomy^g' ? Because it's his machine ? What sense does this make!

At no point will the references be shorter than the directory names as they stand, in which case the replacement is an increase in both brute length and code complexity. There's just nothing gained here, I can appreciate that your experience with the planeshift/creepspace insane clown possee riled you up some, but we're using directories sanely (as we regard them as namespaces, ie gns subspaces in the first place), as opposed to haphazardly. What's so wrong with doing it simply ?

]]> By: bvt http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-150 bvt Sun, 01 Mar 2020 13:48:13 +0000 http://bvt-trace.net/?p=72#comment-150 Re 1, I don't think there was an argument for a knob, more of a code style change (i.e. $wotdir/*.asc instead of wot/*.asc). Re 2, something I came up with looks like: <pre> patches/eucrypt_genesis.vpatch patches/ch1_mpi.vpatch patches/ch2_truerandom.vpatch patches/eucrypt_ch11_serpent.vpatch patches/eucrypt_ch6_keccak_permutations.vpatch patches/eucrypt_ch7_keccak_sponge.vpatch patches/eucrypt_ch8_bit_keccak.vpatch patches/eucrypt_ch9_keccak_endianness.vpatch patches/eucrypt_mpi_fix_copy_incr.vpatch patches/eucrypt_ch10_oaep_tmsr.vpatch patches/eucrypt_ch3_miller_rabin.vpatch patches/eucrypt_ch4_rpng.vpatch patches/eucrypt_ch5_rsa_keys.vpatch patches/eucrypt_oaep_fix_checks.vpatch patches/eucrypt_ch12_wrapper_rsa_oaep_c_ada.vpatch patches/eucrypt_keccak_bitrate_fix.vpatch patches/eucrypt_check_nread.vpatch patches/eucrypt_ch13_smg_rng.vpatch patches/eucrypt_manifest.vpatch patches/eucrypt_fix_256.vpatch patches/eucrypt_ch14_crc32.vpatch patches/eucrypt_ch15_arbitrary_e.vpatch patches/eucrypt_ch16_bytestream_keccak.vpatch patches/vtools_genesis.vpatch patches/vdiff_fixes_newline_gcc.vpatch patches/keccak.vpatch patches/vdiff_keccak.vpatch patches/vtools_fixes_bitrate_char_array.vpatch patches/vtools_vpatch.vpatch patches/vtools_fixes_static_tohex.vpatch patches/vtools_vpatch_newline.vpatch patches/vtools_ksum.vpatch patches/vtools_tempfile_standalone_notmp.vpatch patches/vdiff_blockwise_read-2.vpatch patches/vtools_fixes_rootdir_files.vpatch patches/vtools_small_fixes.vpatch patches/vtools_add_vsh.vpatch patches/vtools_add_vsh_utils.vpatch patches/vtools_vsh_utils_one_binary.vpatch patches/vtools_vsh_ada_vfilter.vpatch patches/genesis.vpatch patches/bitcoin-asciilifeform.1.vpatch patches/rm_rf_upnp.vpatch patches/bitcoin-asciilifeform.2-https_snipsnip.vpatch patches/bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch patches/bitcoin-asciilifeform.4-goodbye-win32.vpatch patches/bitcoin-v0_5_3_1-rev_bump.7.vpatch patches/bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch patches/bitcoin-v0_5_3-db_config.6.vpatch patches/asciilifeform_dnsseed_snipsnip.vpatch patches/asciilifeform-kills-integer-retardation.vpatch patches/asciilifeform_maxint_locks_corrected.vpatch patches/asciilifeform_orphanage_thermonuke.vpatch patches/asciilifeform_tx-orphanage_amputation.vpatch patches/asciilifeform_zap_hardcoded_seeds.vpatch patches/asciilifeform_zap_showmyip_crud.vpatch patches/asciilifeform_and_now_we_have_block_dumper_corrected.vpatch patches/asciilifeform_dns_thermonyukyoolar_kleansing.vpatch patches/asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch patches/mod6_fix_dumpblock_params.vpatch patches/asciilifeform_and_now_we_have_eatblock.vpatch patches/asciilifeform_lets_lose_testnet.vpatch patches/asciilifeform_add_verifyall_option.vpatch patches/programmable-versionstring.vpatch patches/malleus_mikehearnificarum.vpatch patches/mod6_der_high_low_s.vpatch patches/mod6_privkey_tools.vpatch patches/makefiles.vpatch </pre> For Eucrypt, vtools, and trb correspondingly. Re 3, I'll think about where to best put this option. Is environment variable OK, or better have as yet another CLI option? Re 4, I wonder what went wrong there: <pre> $ v.sh antecedents patches/eucrypt_ch10_oaep_tmsr.vpatch patches/eucrypt_genesis.vpatch patches/eucrypt_ch6_keccak_permutations.vpatch patches/eucrypt_ch7_keccak_sponge.vpatch patches/eucrypt_ch9_keccak_endianness.vpatch $ v.sh antecedents patches/eucrypt_oaep_fix_checks.vpatch patches/eucrypt_genesis.vpatch patches/eucrypt_ch6_keccak_permutations.vpatch patches/eucrypt_ch7_keccak_sponge.vpatch patches/eucrypt_ch9_keccak_endianness.vpatch patches/eucrypt_ch10_oaep_tmsr.vpatch </pre> Re 1, I don't think there was an argument for a knob, more of a code style change (i.e. $wotdir/*.asc instead of wot/*.asc).
Re 2, something I came up with looks like:

patches/eucrypt_genesis.vpatch
 patches/ch1_mpi.vpatch
  patches/ch2_truerandom.vpatch
 patches/eucrypt_ch11_serpent.vpatch
 patches/eucrypt_ch6_keccak_permutations.vpatch
  patches/eucrypt_ch7_keccak_sponge.vpatch
 patches/eucrypt_ch8_bit_keccak.vpatch
   patches/eucrypt_ch9_keccak_endianness.vpatch
  patches/eucrypt_mpi_fix_copy_incr.vpatch
    patches/eucrypt_ch10_oaep_tmsr.vpatch
    patches/eucrypt_ch3_miller_rabin.vpatch
     patches/eucrypt_ch4_rpng.vpatch
      patches/eucrypt_ch5_rsa_keys.vpatch
     patches/eucrypt_oaep_fix_checks.vpatch
              patches/eucrypt_ch12_wrapper_rsa_oaep_c_ada.vpatch
               patches/eucrypt_keccak_bitrate_fix.vpatch
                patches/eucrypt_check_nread.vpatch
                 patches/eucrypt_ch13_smg_rng.vpatch
                  patches/eucrypt_manifest.vpatch
                   patches/eucrypt_fix_256.vpatch
                    patches/eucrypt_ch14_crc32.vpatch
                     patches/eucrypt_ch15_arbitrary_e.vpatch
                      patches/eucrypt_ch16_bytestream_keccak.vpatch

patches/vtools_genesis.vpatch
 patches/vdiff_fixes_newline_gcc.vpatch
  patches/keccak.vpatch
   patches/vdiff_keccak.vpatch
    patches/vtools_fixes_bitrate_char_array.vpatch
     patches/vtools_vpatch.vpatch
      patches/vtools_fixes_static_tohex.vpatch
       patches/vtools_vpatch_newline.vpatch
        patches/vtools_ksum.vpatch
         patches/vtools_tempfile_standalone_notmp.vpatch
          patches/vdiff_blockwise_read-2.vpatch
           patches/vtools_fixes_rootdir_files.vpatch
            patches/vtools_small_fixes.vpatch
             patches/vtools_add_vsh.vpatch
              patches/vtools_add_vsh_utils.vpatch
               patches/vtools_vsh_utils_one_binary.vpatch
                patches/vtools_vsh_ada_vfilter.vpatch

patches/genesis.vpatch
 patches/bitcoin-asciilifeform.1.vpatch
  patches/rm_rf_upnp.vpatch
   patches/bitcoin-asciilifeform.2-https_snipsnip.vpatch
   patches/bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch
     patches/bitcoin-asciilifeform.4-goodbye-win32.vpatch
      patches/bitcoin-v0_5_3_1-rev_bump.7.vpatch
    patches/bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch
      patches/bitcoin-v0_5_3-db_config.6.vpatch
      patches/asciilifeform_dnsseed_snipsnip.vpatch
      patches/asciilifeform-kills-integer-retardation.vpatch
       patches/asciilifeform_maxint_locks_corrected.vpatch
    patches/asciilifeform_orphanage_thermonuke.vpatch
       patches/asciilifeform_tx-orphanage_amputation.vpatch
       patches/asciilifeform_zap_hardcoded_seeds.vpatch
        patches/asciilifeform_zap_showmyip_crud.vpatch
       patches/asciilifeform_and_now_we_have_block_dumper_corrected.vpatch
         patches/asciilifeform_dns_thermonyukyoolar_kleansing.vpatch
            patches/asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch
        patches/mod6_fix_dumpblock_params.vpatch
                patches/asciilifeform_and_now_we_have_eatblock.vpatch
                   patches/asciilifeform_lets_lose_testnet.vpatch
                    patches/asciilifeform_add_verifyall_option.vpatch
                     patches/programmable-versionstring.vpatch
                      patches/malleus_mikehearnificarum.vpatch
                      patches/mod6_der_high_low_s.vpatch
                       patches/mod6_privkey_tools.vpatch
                          patches/makefiles.vpatch

For Eucrypt, vtools, and trb correspondingly.
Re 3, I'll think about where to best put this option. Is environment variable OK, or better have as yet another CLI option?
Re 4, I wonder what went wrong there:

$ v.sh antecedents patches/eucrypt_ch10_oaep_tmsr.vpatch
patches/eucrypt_genesis.vpatch
patches/eucrypt_ch6_keccak_permutations.vpatch
patches/eucrypt_ch7_keccak_sponge.vpatch
patches/eucrypt_ch9_keccak_endianness.vpatch
$ v.sh antecedents patches/eucrypt_oaep_fix_checks.vpatch
patches/eucrypt_genesis.vpatch
patches/eucrypt_ch6_keccak_permutations.vpatch
patches/eucrypt_ch7_keccak_sponge.vpatch
patches/eucrypt_ch9_keccak_endianness.vpatch
patches/eucrypt_ch10_oaep_tmsr.vpatch
]]> By: Diana Coman http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-149 Diana Coman Sun, 01 Mar 2020 12:56:05 +0000 http://bvt-trace.net/?p=72#comment-149 @Mircea Popescu <blockquote> I believe this is the wrong kind of knob, like "redefining the value of 4". There's no possible legitimate use for it (besides, perhaps, some crude attempt at republic-with-serials-filed-off, and there's a very certain cost of sifting through options. Let the names be standardized, what's the big deal. </blockquote> I don't agree here at all. For one thing, it's something on the *user's machine* so wtf and what sifting through options?? The point is not to give some "options" but simply to write the code so that if one wants to change a fucking name of a dir (and it IS just that, nothing more), it's only ONE place to do the change, not 100. And for that matter I see it quite conversely - basically writing "wot" and "patches" everywhere in the code sounds like some crude attempt at windows-style-copywriting-of-names or dunno. I just can't begin to see the case (or how it would actually even *work* because fuck, if I want to change it, I WILL CHANGE IT anyway) for having strings repeated in the code instead of having a variable with that text. @bvt Good that you mentioned your comment as it had gotten in the spam queue somehow, I just fished it out now. No idea how & why that happened exactly but possibly some IP mess, sorry about it. Re 3 - yes, I'd very much like to have the *option* of verbose. Re 4 - honestly, I tried *both* with and without patches/ because yes, indeed, I actually prefer it with patches exactly as you say because of auto-complete. But in both cases I got nothing out of it. Is it somehow working for you? @Mircea Popescu

I believe this is the wrong kind of knob, like "redefining the value of 4". There's no possible legitimate use for it (besides, perhaps, some crude attempt at republic-with-serials-filed-off, and there's a very certain cost of sifting through options. Let the names be standardized, what's the big deal.

I don't agree here at all. For one thing, it's something on the *user's machine* so wtf and what sifting through options?? The point is not to give some "options" but simply to write the code so that if one wants to change a fucking name of a dir (and it IS just that, nothing more), it's only ONE place to do the change, not 100. And for that matter I see it quite conversely - basically writing "wot" and "patches" everywhere in the code sounds like some crude attempt at windows-style-copywriting-of-names or dunno. I just can't begin to see the case (or how it would actually even *work* because fuck, if I want to change it, I WILL CHANGE IT anyway) for having strings repeated in the code instead of having a variable with that text.

@bvt
Good that you mentioned your comment as it had gotten in the spam queue somehow, I just fished it out now. No idea how & why that happened exactly but possibly some IP mess, sorry about it.
Re 3 - yes, I'd very much like to have the *option* of verbose.
Re 4 - honestly, I tried *both* with and without patches/ because yes, indeed, I actually prefer it with patches exactly as you say because of auto-complete. But in both cases I got nothing out of it. Is it somehow working for you?

]]> By: Mircea Popescu http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-148 Mircea Popescu Sun, 01 Mar 2020 11:40:49 +0000 http://bvt-trace.net/?p=72#comment-148 > 1. why not make the set-dir names (ie patches, wot, seals) also variables in the script at the beginning I believe this is the wrong kind of knob, like "redefining the value of 4". There's no possible legitimate use for it (besides, perhaps, some crude attempt at <a href="http://trilema.com/2018/the-republic-without-mp/" rel="nofollow">republic-with-serials-filed-off</a>, and there's a very certain cost of sifting through options. Let the names be standardized, what's the big deal. Re 2, a purely ascii alternative would be great, esp for perceived portability. No ? Re the silence, it seems evident there should be a silent and a verbose mode. This is not something we've invented, it comes from good historical precedent (not just because different sorts of outputs are useful when the reader's another script further down the pipe versus when the reader's an actual human), and perhaps we should actually build around it ? Have a "human" mode where shit's spelled out, and a "machine" mode where it mostly stfu's ? DWIM seems a terrible idea in this context, and no doubt exactly the path to hell paved with good intentions people ended up traveling with eg gpg. > 1. why not make the set-dir names (ie patches, wot, seals) also variables in the script at the beginning

I believe this is the wrong kind of knob, like "redefining the value of 4". There's no possible legitimate use for it (besides, perhaps, some crude attempt at republic-with-serials-filed-off, and there's a very certain cost of sifting through options. Let the names be standardized, what's the big deal.

Re 2, a purely ascii alternative would be great, esp for perceived portability. No ?

Re the silence, it seems evident there should be a silent and a verbose mode. This is not something we've invented, it comes from good historical precedent (not just because different sorts of outputs are useful when the reader's another script further down the pipe versus when the reader's an actual human), and perhaps we should actually build around it ? Have a "human" mode where shit's spelled out, and a "machine" mode where it mostly stfu's ?

DWIM seems a terrible idea in this context, and no doubt exactly the path to hell paved with good intentions people ended up traveling with eg gpg.

]]> By: bvt http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-147 bvt Sun, 01 Mar 2020 10:15:12 +0000 http://bvt-trace.net/?p=72#comment-147 Thanks! 1. Yes, this can be done rather easily. Would be an improvement in style with an added benefit of allowing easy fitting for ones taste. 2. For no good reason really, see comment to <a href="http://ossasepia.com/2020/02/29/a-basic-requirement-for-the-literate-introducing-of-new-tools/" rel="nofollow">your article</a> (still in the queue). This command can be added, indented printing as well. 3. Indeed, I like it silent more. Do you prefer to see invocations of vpatch and/or output of the vpatch as well? 4. The breaking UI change is that I relied more on command line completion than on full manual retyping and copy-paste availability. So antecedents/descendants also require vpatch name input in the form of patches/eucrypt_oaep_fix_checks.vpatch, not just eucrypt_oaep_fix_checks.vpatch. This can be changed back to the standard way of passing argument, if there is a significant dislike of the new style. Alternatively, a bit if DWIMming can be added with a basename in the right place, but I am quite suspicious of DWIM, so not sure I'd like that myself. Thanks!

1. Yes, this can be done rather easily. Would be an improvement in style with an added benefit of allowing easy fitting for ones taste.
2. For no good reason really, see comment to your article (still in the queue). This command can be added, indented printing as well.
3. Indeed, I like it silent more. Do you prefer to see invocations of vpatch and/or output of the vpatch as well?
4. The breaking UI change is that I relied more on command line completion than on full manual retyping and copy-paste availability. So antecedents/descendants also require vpatch name input in the form of patches/eucrypt_oaep_fix_checks.vpatch, not just eucrypt_oaep_fix_checks.vpatch. This can be changed back to the standard way of passing argument, if there is a significant dislike of the new style. Alternatively, a bit if DWIMming can be added with a basename in the right place, but I am quite suspicious of DWIM, so not sure I'd like that myself.

]]> By: A Basic Requirement for the Literate Introducing of New Tools « Ossa Sepia http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/#comment-146 A Basic Requirement for the Literate Introducing of New Tools « Ossa Sepia Sat, 29 Feb 2020 20:44:19 +0000 http://bvt-trace.net/?p=72#comment-146 [...] started as a comment1 on bvt's very useful work building up the vtools suite. As I really liked his approach2 and I would really prefer to have just one suite (vtools) with [...] [...] started as a comment1 on bvt's very useful work building up the vtools suite. As I really liked his approach2 and I would really prefer to have just one suite (vtools) with [...]

]]>