|»|10 guest@cc 2020-03-03T04:49:11
>If it still contains code from the original GPL'd 4taba codebase, you are forced to also use the GPL.
Not necessarily. So long as the not-otherwise-GPL'd code is defined as a separate (albeit proximate) thing (even if it's meant to interact closely with GPL'd things), it's a separate thing, and not a modification of the GPL'd thing. The absurdity goes so far that, a patch that would modify a GPL'd thing, need not be GPL, but the results of applying that patch to the GPL'd thing would. So.. if you have a bunch of GPL'd things, and some not-otherwise-GPL'd things, you can still sell them for commercial purposes, so long as the GPL'd parts (and any their modifications,,) are given away for free (i.e you sell your modifications and at the same time have your customers get the GPL'd things ``separately''; you can even have a thing that, whether it's GPL'd or not, applies such non-GPL'd patches. Then, the result that is a modification, would be in your customers', but never in your, posession); the argument that you would need to apply those patches in order to know that they work the way you mean them to work is bunkum: it's all in your head. (Literally, do the math. You know the languages, you know the grammars, you know how particular grammatical constructions correspond to reality..)
|»|28 guest@cc 2020-03-05T11:29:44 [ImgOps] [iqdb]
(text/plain, 1.85KB, #f)
Here is a solution to the code tag issue as well. The regex module is still used because, in addition to fixing greediness, a new feature is added. Code blocks can start with either [ codeblock ], [ code ] or [ c ], without the spaces, and will end on the first matching closing tag. This means that if the code you want to post happens to include [ /code ] somewhere, without the spaces, you can wrap it in [ codeblock ] instead and it will work. Previously a [ /code ] in a code block would end it with reluctant matching. The precomputation is performed once and stored in a closure, because this is faster than redoing it on each invocation. The strategy for dealing with unbalanced tags is chosen to be the same one that would be in effect if the library had reluctant iteration support. This basically means that unbalanced tags stay as plain text. It's written and tested in Guile Scheme so, while the structure will work elsewhere, a small porting effort may be required with e.g. the names of hashmap procedures.
To integrate it in imageboard.scm find the "; Code matching" lambda in comment-filter, comment it out and put reluctant-code-tags in its place -- it is already a lambda of the appropriate signature.
|»|39 guest@cc 2020-03-07T11:19:24
> This is only a partial fix
This is the standard solution for regular parsing as opposed to context-free parsing, and without resorting to MIME boundaries, which is what your [code:hvfui] is.
> This wouldn't be too surprising either; somebody might post the code related to parsing code tags.
The "code related to parsing code tags" from >>28 does not contain literal tags. They are computed once in the closure.
> I think anon meant
That is not compatible with the current imageboard.scm:comment-filter, and the first [/code] would close the block. This is because the admin's comment-filter is a lambda fold, so each transformation is applied to the output of the chain of preceding transformations, without any semantic information being passed between transformation steps.
If you want to rewrite comment-filter from regular parsing to context-free parsing, and the admin is interested, you are welcome to it. My interest was fixing >>18, which >>28 accomplishes.
Also, for the admin: to fix your "Webm and Webp data are 8stream #9" issue go to mime.scm inside artanis and add "(video/webm (webm))" to mime-list, and another entry for webp, then for completeness go to your init-server in ENTRY and add all the missing media extensions that you are serving to #:statics.
|»|42 guest@cc 2020-03-07T12:55:24
have you read
your sicp today