sexy Nico,

i dunno how active tabamin is around here anymore after I came around, but to keep everything together I forked off of his python software before he left github.

I believe by the way the GNU license works this project is forced under the same rules as GNU Artanis.

https://github.com/ECHibiki/Kotatsu

Which one is the codebase actually running on the deployed site?

https://github.com/4taba/4taba
GPLv3

https://gitlab.com/ison2/kotatsu
proprietary

https://github.com/ECHibiki/Kotatsu
GPLv3

Are you the only author of the code? You need the permission of every contribution to release their code under a different license.

If it still contains code from the original GPL'd 4taba codebase, you are forced to also use the GPL. GNU Artanis is available under both the GPL and LGPL, the latter can be mixed with proprietary code.

Well, tabamin made the code and I've been fixing bugs in it. 4taba/4taba is probably close to the concept of a prototype for his rewrite on ison/kotatsu and ECHibiki/kotatsu is the version that's working on current versions of Guile and Scheme with various bug fixes.

Guile and Artanis.

>>4
last
but I suppose i ought to make a gitlab remote so i can make PRs to Tabamin's since it's the more official one and people would go to that if he comes back

>>5
>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..)

>>10
Also, if it was at any point a modification of a GPL'd, even if the original GPL'd things are no longer anywhere in it, so long as it's a modification of a modification of a ... (you get the idea), then it'd have to be GPL'd.

>>9
I've done that already.
https://gitlab.com/ison2/kotatsu/issues/2

>By default, software is proprietary
By default, software is WTFPL

License file added. Thanks for pointing it out.

>>14
Thank you! I'll try it and report back.

>>13
Sadly that's not how copyright laws work. The default is "all rights reserved". Which means that you cannot use source code unless the author grants you the right to. If you find unlicensed code on the Internet, you start using it and the author finds out, they can sue you for copyright infringement.

>>14

https://github.com/ECHibiki/Kotatsu/issues/3
> Webm thumbnailing inconsistent #3
> Some webm's don't get thumbnails
> might be result of imagemagic, not sure

The code doesn't use ImageMagick for video thumbnails. It uses ffmpeg in prv/modules/utils.scm:make-video-thumbnail and the command works.

$ ffmpeg -i goodjob.webm -vf 'thumbnail,scale=w=200:h=200:force_original_aspect_ratio=decrease' '-frames:v' 1 -f singlejpeg thumb.jpg[/code]
The problem with webm thumbnails is that prv/modules/utils.scm:get-mimetype uses:
[code]$ file -b --mime-type goodjob.webm
video/webm

to get the mimetype but there is no video/webm branch in "case mime", so the 'else' is taken in prv/modules/imageboard.scm:save-post -> "case mimetype" instead of the video branch. You need to add "((video/webm) 'WEBM)" to get-mimetype -> "case mime" and add WEBM to save-post -> "case mimetype" -> "(FLAC M4A MKV MP3 MP4 OCTET OGG WAV WMA)".

Also, your code tag regex is broken and needs to use reluctant iteration between the code tags instead of greedy iteration.

I see that this is already present in the TODO of prv/modules/imageboard.scm and that you are using (ice-9 regex). Unfortunately (ice-9 regex) does not seem to have reluctant iteration, or it would have been an easy fix.

scheme@(guile-user)> (use-modules (ice-9 regex))
scheme@(guile-user)> (regexp-substitute/global #f "\\[code\\](.*?)\\[/code\\]" "a [code]1[/code] [code]2[/code] b" 'pre 1 'post)
$1 = "a 1[/code] [code]2 b"

The documentation agrees:
https://www.gnu.org/software/guile/manual/html_node/Regexp-Functions.html
"""By default, Guile supports POSIX extended regular expressions. That means that the characters ‘(’, ‘)’, ‘+’ and ‘?’ are special, and must be escaped if you wish to match the literal characters and there is no support for “non-greedy” variants of ‘*’, ‘+’ or ‘?’."""

"This regular expression interface was modeled after that implemented by SCSH, the Scheme Shell. It is intended to be upwardly compatible with SCSH regular expressions."
I see, regex isn't something they care about aside from compatibility

>>18
>video/webm
I see. I think the output of the file command may be different depending on distro.
The file command that comes with Guix outputs mimetype "application/octet-stream" for webms, which corresponds to the 'OCTET symbol, and is in the list for creating video thumbs. The changes you suggested should fix it.

As for regex, yeah that's basically the exact same difficulty I remember facing. Can't use non-greedy, lookbehinds, or lookaheads.

>>18
nice, I added webp thumbnailing as a bonus

Stacks instead of regex I'm thinking.

>>24
>nice, I added webp thumbnailing as a bonus
OK, but you should reference the commit in the closed issue.

>Stacks instead of regex I'm thinking.
I'm leaning towards stack + regex, in case a tag itself has structure. If not, the compiled regexp-exec will run as fast as string searching.

What the hell is a webp?

like webmovie except it's a webpicture
it's like a compressed png that's used in wiki sites.

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.

https://github.com/ECHibiki/Kotatsu/blob/f5fe83b57f147d146a4cc544e92ff3d3c8bd418b/prv/modules/imageboard.scm#L665

>>28
I don't know if I like multiple different tags, that feels like a last resort if there's really no other way to do it.
Couldn't the match just be filtered a 2nd time for [ /code ] ... [ code ]?

>>29
>Couldn't the match just be filtered a 2nd time for [ /code ] ... [ code ]?
If the code block starts with [ code ], the first [ /code ] will end it. That's the whole point of reluctant iteration.

>>30
Oh, nevermind I misunderstood. I thought the multiple different tags was the solution to the greediness, but you're just making it an option so people can write [ code ] inside their code.
I guess that works, although traditionally that problem is solved by having another set of tags that disables parsing. Like [noparse] [ code ] [/noparse]

>>31
>[noparse] [ code ] [/noparse]
Either noparse provides all the benefits of a code block like monospacing, in which case it is just another alias like in my fix, or it does not, in which case "that problem is" not "solved" because you do not get a proper code block.

Running on the server, but put on separate branch because it should be applied to all the tags.

Added unit test cases, but I'm not sure how testing is properly handled in guile so it's an SCM testing for boolean string equality outputting results as #f #t with a test description.

You can use SRFI-64 for testing:
https://www.gnu.org/software/guile/manual/html_node/SRFI_002d64.html
https://srfi.schemers.org/srfi-64/srfi-64.html

>>28
This is only a partial fix since it's possible the code could contain all three end tags. This wouldn't be too surprising either; somebody might post the code related to parsing code tags. You could make it work by having the opening and closing tags contain a user-supplied string known not to occur in the code; that is, something like [ code:hvfui ][ /code:hvfui ].

>>32
I think anon meant
[ code ]
some code
some code
line with the end tag [noparse][ /code ][/noparse] more on the line
some code
[/ code ]
where the [noparse] and [/noparse] are removed from the displayed code.
This would additionally solve the problem of someone wanting to use "[ code ]" in normal conversation without creating a code block or adding in those funny-looking spaces.
A disadvantage is you have to make edits to the code wherever a tag appeared, but that could be automated.

>>36
And with the [noparse] approach you'd also need to escape [noparse] tags if they occurred in the code, but you could do that with something like [noparse][nop[/noparse]arse]. Kind of ugly though.

testing

print ("[code]")
print ("test")
print ("[/code]")

more text

>>36
> 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.

>>37
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.

When I said "only a partial fix" I meant what the multiple code tags are trying to solve. Didn't mean to imply it didn't fix >>18.

>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.

It may be a good idea to rewrite this just from a security perspective. I worry that one filter might generate some HTML and a subsequent filter, by treating the HTML as if it were ordinary text, might alter the HTML in a way that allows a poster to inject arbitrary Javascript into the page.

more testing

(display "[code]")
(display 'sicp)
(display "[/code]")

(display "[codeblock]")
(display 'sicp)
(display "[/codeblock]")

have you read

(display "[c]")
(display 'sicp)
(display "[/c]")

(display "[codeblock]")
(display 'sicp)
(display "[/codeblock]")

your sicp today

(display "[c]")
(display 'sicp)
(display "[/c]")

(display "[code]")
(display 'sicp)
(display "[/code]")

more text

> Open issues drop to 0 by deleting the issues.
☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻☺☻

I don't know what this subpost/subthread nonsense is but the content can be made visible with:

.computer .subthread {
width: auto;
height: auto;
}

I see that the polite term for this is "transferred".
https://4taba.net/contact -> https://github.com/ECHibiki/kotatsu -> https://github.com/ECHibiki/Kotatsu-V-archived -> https://github.com/ECHibiki/Kotatsu-V/

>>44
> Enter the post number you want to reply to in the options field to start/reply to a subthread
Or you could just use >>44 like a sane person.

test1

test2[/code]test3[code]test4

test5

Switching the .code to display: inline; gives you nonsensical per-line borders: >>42 >>44.

It is, but if the code tag is used inline it fills up an entire line that looks poor to read.

I'll see which rule sets width to be sized to all contents