Coding projects (by others)

This page lists a few projects that I've cloned from elsewhere.

Some of them still sync with the original repository, and in some cases I keep a local (private) branch with my own tweaks and additions.

**"Override project code"** option does not have any effect while creating new fossil repo at *chiselapp.com*. It should supposed to set project ID/code specified by user in `"Override project code"` option, but different project ID is assigned to newly created repo at *chiselapp.com*. Existing local repo cannot be pushed into remote repo at *chiselapp.com* because of different project ID. **Login failure** error occures. ## Work around method here is workaround method for one who interested to upload existing repo to *chiselapp.com* till this issue resolves. * clone remote repo from *chiselapp.com* ` fossil clone https://chiselapp.com/user/xxx/repository/myrepo myrepo.fossil` * get project ID of remote repo `fossil info -R myrepo.fossil` * modify existing local repo project ID to match remote repo ID ``` fossil sql -R <local-repo> UPDATE config SET value='<project-code-from-remote-repo>' where name='project-code'; .exit ```

Tap the "Plain Text" ticket view to see the full/untruncated ticket report.

(What follows is part of the ticket's body but is truncated due to the bug being reported...) However, this is very dependent on the other content in the document. e.g. adding a literal 0x7d character to this text _before_ the above block somehow inexplicably fixes it. This exact same text works fine in the wiki and forum. Since _this_ comment gets truncated by this bug, it will be copy/pasted into a separate comment on the ticket after submitting it.

Accidentally discovered while writing a ticket a while ago: This code block gets truncated at a 0x7d character (but that problem is inexplicably fixed if this sentence adds a literal character of that value): ``` a b c } = { d e ``` However, this is very dependent on the other content in the document. e.g. adding a literal 0x7d character to this text _before_ the above block somehow inexplicably fixes it. This exact same text works fine in the wiki and forum. Since _this_ comment gets truncated by this bug, it will be copy/pasted into a separate comment on the ticket after submitting it.

What follows is copy/pasted directly from code comments in src/diff.c, reformatted slightly to account for markdown/ticket system quirks: An annoying cosmetic bug: the libf diff builders will sometimes render two directly-adjecent chunks with a separator, e.g.: ``` $ f-vdiff --format u 072d63965188 a725befe5863 -l '*vdiff*' | head -30 Index: f-apps/f-vdiff.c ================================================================== --- f-apps/f-vdiff.c +++ f-apps/f-vdiff.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36 36 fsl_buffer fname; 37 37 fsl_buffer fcontent1; 38 38 fsl_buffer fcontent2; 39 39 fsl_buffer fhash; 40 40 fsl_list globs; 41 + fsl_dibu_opt diffOpt; 42 + fsl_diff_builder * diffBuilder; 41 43 \} VDiffApp = { 42 44 NULL/*glob*/, 43 45 5/*contextLines*/, 44 46 0/*sbsWidth*/, 45 47 0/*diffFlags*/, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46 48 0/*brief*/, 47 49 fsl_buffer_empty_m/*fname*/, 48 50 fsl_buffer_empty_m/*fcontent1*/, ``` Note now the chunks before/after the second `~~~` line are consecutive lines of code. In fossil(1) that case is accounted for in the higher-level diff engine, which can not only collapse adjacent blocks but also does the rendering of chunk headers in that main algorithm (something we cannot do in the library because we need the fsl_dibu to be able to output to arbitrary destinations). We can currently only _partially_ account for it, eliminating the extraneous `~~~` line only when we're in line-number mode. (Note that the current code does so, so does not show the chunk separator for the above case, but it will if the `-l` flag is elided.) In non-line-number mode we _have_ to output the chunk header as-is. If we skip it then the _previous_ chunk header, if any, will contain incorrect numbers for the chunk, invaliding the diff for purposes of tools which import unified-format diffs. It would seem that the only workaround for that, within the current API, is to always look ahead one chunk before sending the previous chunk to the diff builder. That would allow the diff algo to retroactively adjust the chunk line numbers/counts before passing them on to the builder for rendering. It would, however, add a significant amount of complexity to that algo.

Theme: "Small Business" by Blackrock Digital

Background: "A beautiful day" by Jason Blackeye