/hydrus/ -Release Tomorrow!

Name
Email
Subject	REC STOP
Comment *
File	Select/drop/paste files here
Password	(Randomized for file and post deletion; you may also set your own.)
Archive	Archive [500 char limit]
* = required field	[▶Show post options & limits] Confused? See the FAQ.

Embed	(replaces files and can be used instead)
Options	Do not bump (you can also write sage in the email field)
Allowed file types:jpg, jpeg, gif, png, webp,webm, mp4, mov, swf, pdf Max filesize is16 MB. Max image dimensions are15000 x15000. You may upload5 per post.

File: e3d80057357881e⋯.gif (826.95 KB,500x275,20:11,e3d80057357881e6faf3fc41e3….gif)

Release Tomorrow! hydrus_dev ## Board Owner 03/06/19 (Wed) 01:34:45 099694 No.11798

I had a good week. I fixed several bugs (including I think the Linux >0 distance similar files search crash, finally!), did some neat ui work like better tag autocomplete responsivity, more stable and slightly smoother video rendering, and more 'open urls' options on multiple selections, and added some basic webp and tiff file import support.

The release should be as normal tomorrow.

____________________________

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

Anonymous 03/06/19 (Wed) 02:47:19 106813 No.11799

>uncensored handholding

>>>/d/

fucking disgusting i can't believe hdev is such a degenerate

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

Anonymous 03/06/19 (Wed) 12:43:13 254bfa No.11801

Sauce, devbro?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

hydrus_dev ## Board Owner 03/06/19 (Wed) 22:14:53 099694 No.11803

>>11801

Dunno, sorry! It was just in my inbox this week.

But perhaps source could be your life, one day.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

Anonymous 03/06/19 (Wed) 23:25:02 76ef5c No.11804

>(including I think the Linux >0 distance similar files search crash, finally!)

Was that at all related to any of my posts:

>>11736

>>11758

>>11797

Because I was having an issue on linux crashing. In the process for searching for duplicates an SQL statement similar to

SELECT phash_id, phash, radius, inner_id, outer_id FROM shape_perceptual_hashes NATURAL JOIN shape_vptree WHERE phash_id IN (1, 2, 3);

would be executed and cause a segfault, not just for hydrus but anything that could execute an sqlite statement. Apparently Sqlite 3.27.1 (and possibly some earlier versions) had a bug where if the size of a list exceeded two items it just crashed. This appears to be fixed in sqlite 3.27.2.

I imagine based on the code I looked at having a search distance greater than 0 would make it far less likely to happen if not impossible.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

hydrus_dev ## Board Owner 03/07/19 (Thu) 00:16:27 099694 No.11806

>>11804

There are quite a few places where the client fetches things with lists up to 256 items long, so if you found that just loading some files and tags was ok, I _think_ you weren't getting hit by that exact issue.

But yeah, your posts are the bug I think I fixed. Only affected some Linux users, and I could not reproduce it. I worked one on one in the week with a user who had the crash and we ultimately figured it was a problem with SQLite hanging on to the phash while I did a Hamming Distance search on it (which requires some low level C++ struct calls and then some mickey-mouse CPU-level binary counting). Something to do with memory access violation is my best guess. Python usually can't crash by itself. Previously, I was doing hamming searches interleaved with the sqlite call iterating each row, but when I separated it into completed batches, so sqlite was 'done' with the rows, no crash happened.

The 0 search distance could do a direct lookup without the hamming check, and that was running fine. It just seemed to be the combination of iterator on sql results and then low-level access on 'bytes' type response from that that caused the crash. Core dumps suggested the crash was in sqlite code, so I guess it was still hanging on to a bytes buffer or something that wasn't cleaned up. Could indeed still be a (different) bug in sqlite, or python's wrapper for it, but I dunno for real.

Let me know how 342 works for you!

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

Anonymous 03/07/19 (Thu) 20:06:24 6a00e3 No.11808

>>11801

Owarimonogatari

>>11803

wholesome

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.