Avisynth+

[Reel.Deel]

Adding this causes the x86 script to freeze on start.

Hmm, if I set your shader filters to mode 3 and SVP to mode 1 it doesn't freeze, tested with 32 and 64-bit. Both perform about the same. I see that pinterf has to set SVSmoothFps to mode 3 to get it to work, something is really odd here.

One thing I did notice while testing is that performance is about the same with MT and with it disabled. Just out of curiosity, what's the performance of your script when you run it with MT disabled?


I myself have decided not to bother with AviSynth 64-bit any more. Last time I did (which, granted, was a while back; but your data doesn't look promising), it was crashing all over the place. We got VapourSynth now. :)

I don't think MysteryX's result are a proper depiction of AviSynth+ MT. With QTGMC I get better performance with AVS+ than with VS.

[MysteryX]

what's the performance of your script when you run it with MT disabled?
With MT I get 9.1fps
Without MT I get 2.2fps

That's because I have 8 cores. Without MT, only 1/8th of my computing power is used. Plus with AviSynthShader, the CPU has to wait for the GPU to finish processing so the CPU is idle a lot of the time; alternating between the CPU and the GPU working but not both simultaneously.

I don't think MysteryX's result are a proper depiction of AviSynth+ MT. With QTGMC I get better performance with AVS+ than with VS.
I do get slightly better performance with AviSynth+ than AviSynth 2.6 MT, and considerably lower memory usage, but only with the x86 version.

However, my results aren't very representative of the effectiveness of CPU frame processing because the bottleneck is GPU memory transfers. It does, however, test the memory usage, effectiveness and stability of memory transfers. I agree that a script where the CPU is the bottleneck would be a better representation of the computing effectiveness of AviSynth+.

[MysteryX]

I had posted benchmark results of x64 which were not good, however x86 works well. It would be more fair to show the good results with x86.

Curiously enough, after updating SVPFlow to the latest version, it started crashing in AVS+. After reverting back to the version that comes with InterFrame, it works again (??)

AND, after reverting back to that version of SVPFlow, I'm no longer getting freezes when seeking. That's odd because SVP itself is working perfectly fine with AVS+.

AviSynth 2.6

Frames processed: 304 (0 - 303)
FPS (min | max | average): 1.391 | 1000000 | 9.087
Memory usage (phys | virt): 823 | 1200 MiB
Thread count: 139
CPU usage (average): 11%


AviSynth+ r1849

Frames processed: 303 (0 - 302)
FPS (min | max | average): 1.032 | 1000000 | 9.121
Memory usage (phys | virt): 544 | 992 MiB
Thread count: 155
CPU usage (average): 13%

AviSynth+ is very slightly faster and the speed is more consistent. Memory usage is clearly lower.

Again, running it in x64 is a whole other story.

[pinterf]

Ok, MysteryX, check PM.
It works in x64, with your plugins in mode 2 and spvflow in mode 1 (spv version 4.0.0.128)
(but only one test is not a test)

[Chikuzen]

When a temporal filter calls child->GetFrame() more than one times, the speed of the filter will be changed by the order of that calls on MT mode.

I noticed this when I rewrote ReduceFlicker for avs2.6/avs+.

my repository (https://github.com/chikuzen/ReduceFlicker/blob/master/avisynth/src/ReduceFlicker.cpp#L68)
binary(32bit) (https://dl.dropboxusercontent.com/u/19797864/forum/ReduceFlicker26.dll)


LoadPlugin("ReduceFlicker26.dll")
SetFilterMTMode("ReduceFlicker", MT_NICE_FILTER)
ColorBars(1920, 1080, "YV12").Spline36Resize(1280, 720)
ReduceFlicker(strength=3, aggressive=true, grey=false, opt=1, raccess=true)
prefetch(4)


When I set raccees(I added this option to confirm this behavor) to false, almost all prefetch loses its power.
(490fps -> 175fps on my i7-4790 desktop)

Probably, it'll be also same as this that prefetch doesn't work for TemporalSoften().

[pinterf]

First I wanted to say that hmmm, interesting phenomenon. If someone would develop a filter chain visualizer I would be grateful.

Then a memory came to mind, from times when I was bothering with the cache problem thingy.

I've seen an adaptive pattern matching in the prefetch code. As I recall that the algorithm tries to guess the request pattern, e.g. frames are requested by one (1-2-3-4...), two (2-4-6-8... what is it used for, I don't know, SelectEven?), or backward(100-99-98-97...), etc.
If there is enough data for a rule, it "locks" on this pattern and continues the prefetch using this prediction.

(And I noticed that Frame 0 is not prefetched, prefetching starts with frame 1 .... Tried to fix it for the sake of perfectness but did not have the knowledge and patience for this)

[LigH]

Long, long time ago, I remember a project named "AVE AviSynth Visual Editor". I doubt it ever reached practical relevance...

[kypec]

Could any moderator be so kind and include link to pinterf's Git repo with latest Avisynth+ builds on the first page of this thread, please? It took me quite some time to dig those information from his posts scattered across dozens of the last pages...

[pinterf]

Maybe I could use a signature line

[MysteryX]

Maybe I could use a signature line
I'd see something more simple for you, such as

> Me :) (https://github.com/pinterf/AviSynthPlus/tree/MT-pfmod)

[tebasuna51]

Could any moderator be so kind and include link to pinterf's Git repo with latest Avisynth+ builds on the first page of this thread, please? It took me quite some time to dig those information from his posts scattered across dozens of the last pages...

Done.
Let me know if it is OK.

[yup]

pinterf!
Please advice how install your 64 build.
I am try first install stable release
http://github.com/AviSynth/AviSynthPlus/releases/download/Rel-r1576/AviSynthPlus-r1576.exe
and after replace Avisynth.dll in windows\system32 directory, but I can not use commands SetFilterMTMode and #Prefetch.
yup.

[kypec]

Done.
Let me know if it is OK.

Excellent, :thanks::thanks::thanks:

[LigH]

@ yup:

If you ran the installer, I would expect it having already put the DLLs in place. I heavily doubt you should still replace DLLs in system directories after running the installer.

[kypec]

@ yup:

If you ran the installer, I would expect it having already put the DLLs in place. I heavily doubt you should still replace DLLs in system directories after running the installer.
Replacing DLLs manually is the only way at the moment since pinterf's builds do not have installer.

[LigH]

Then I misinterpreted the existence of *.exe downloads...

[luigizaninoni]

Staxrip test builds https://github.com/stax76/staxrip/blob/master/md/test-build.md include avisynth+ installer with pinterf mods (perhaps not the very latest)

[yup]

kypec You are right I ant install pinterf's build.
When I see simple script in Virtualdub64
Version()
I see version Avisynth+ 0.1 r1576 64, not r1849.
Where my fault? I am only replace dll after install r1576.
yup.

[Groucho2004]

kypec You are right I ant install pinterf's build.
When I see simple script in Virtualdub64
Version()
I see version Avisynth+ 0.1 r1576 64, not r1849.
Where my fault? I am only replace dll after install r1576.
yup.
The easiest way to troubleshoot your Avisynth install is to run "AVSMeter64 -avsinfo -log" and post "avsinfo.log". Use the latest AVSMeter version.

[yup]

I am uninstall Avs+ and install StaxRip test build.
Avsmeter message can not load avisynth.dll.
May be need some Microsoft redistributable?
yup.

[Groucho2004]

May be need some Microsoft redistributable?
Yes, you do (2015).

[yup]

Yes, you do (2015).

Groucho2004 :thanks:
Now all work.
yup.

[Groucho2004]

Avsmeter message can not load avisynth.dll.
Was that the whole error message?

[yup]

Was that the whole error message?
Now all work (after install VS2015), no error.
yup.

[Groucho2004]

Now all work (after install VS2015), no error.
yup.
Yes, I understand. My question was about the AVSMeter error message you got before.

[yup]

Yes, I understand. My question was about the AVSMeter error message you got before.

I can not read first time (not readable symbol) , I am under Windows 10 Russian.
yup.

[Reel.Deel]

Could any moderator be so kind and include link to pinterf's Git repo with latest Avisynth+ builds on the first page of this thread, please? It took me quite some time to dig those information from his posts scattered across dozens of the last pages...

Just for future reference, the AviSynth+ wiki page has all of this information: http://avisynth.nl/index.php/AviSynth%2B#Downloads

[pinterf]

I hope, this week I release a new version including that rgb resizer crop fix. Then I think we should create a version with real installer. Volunteer needed for this task.

After this I think I will clean the code a bit and merge back all my modifications to my master branch and get rid of the pfmod suffix.
Clean code is a big advantage of this project. Without it I would not understand and reverse engineer the core in such a short time (my first debug logs were created two month ago).

There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?). Or playing with preparing the core for 16bit/float support, this will require an extended interface later.

Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future? Can we expect a more dynamic development cycle there or we can experiment with it freely? I could ask them (who?) directly but maybe you, old guys here with broader knowledge on the avs history and developers can give some informations about it.

[MysteryX]

@Everyone using MT

Small update to the MT modes list (http://avisynth.nl/index.php/AviSynth%2B#Help_filling_MT_modes). Added a handful of source filters, SVPflow, and a few corrections. Hopefully more to come.
Someone recently added LanczosResize to the list. I thought all the internal filters already register themselves?

Perhaps it would be good to post this list on the first page of this thread? It's difficult to find.

I tried this list and this showed up corrupt

nnedi3_rpow2(2)


Adding this doesn't help

SetFilterMTMode("nnedi3_rpow2", MT_MULTI_INSTANCE)


So the problem must be in one of the other filters being called by NNEDI3; kind of hard to debug.

SVSuper, SVAnalyse and SVSmoothFps also has issues with MT=1 right now; better leave to MT=2 until it is fixed and the fixed DLLs are released with an update to InterFrame. They said there was a weird memory leak, and in either case, whether using MT=1 or MT=2, there is still a single SVP core running so it doesn't change much.

You can add this to the list.
ConvertToShader, ConvertFromShader and Shader support MT=1. ExecuteShader supports MT=2.

Just released AviSynthShader v1.4 (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.4) with Pinterf's code corrections and a few other fixes and improvements.

[MysteryX]

Then I think we should create a version with real installer. Volunteer needed for this task.
Why not use the existing installer? Who produced it? Is the source code available? Ideally we'd have an open source Inno Setup project file that anyone can edit and build. I'd put that Inno Setup file in the same repository as AviSynth+.

There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?).
Isn't AviSynth supposed to be written with plain C to work with various compilers?


Or playing with preparing the core for 16bit/float support, this will require an extended interface later.

System architecture starts to get more in my field. If an extended interface needs to be done, this has to be well-planned. This would also mean that all plugins written for it won't work with previous versions, but previous filters will be compatible with this version. Such an upgrade to the interface has to be done right the first time. And then, none of the filters will support it yet as they have to be adapted for 16-bit support.

Here's some information about 16-bit support
http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth
Previous efforts
http://forum.doom9.org/showthread.php?t=162436

and what would be the advantages over using Stack16 format? 16-bit processing can be done right now with Stack16 format and AviSynthShader.

In terms of major features, there are 2 options for next steps:

1. Getting x64 to work as expected

2. Implementing 16-bit support

Which one is most important?

I believe that fixing the code for x64 might uncover a few hidden issues affecting the x86 build. Working on 16-bit support is definitely more exciting to program.

[MysteryX]

Honestly, I wouldn't try to convince the community to rebuild all plugins with AviSynth+ 16-bit support until AviSynth+ itself is good enough to convince the majority of users to use it instead of v2.6

Which brings this question: are there still reasons for people to keep using AviSynth 2.6 at this point?

[pinterf]

Isn't AviSynth supposed to be written with plain C to work with various compilers?

There are intrinsics, the problem was mentioned recently.


and what would be the advantages over using Stack16 format? 16-bit processing can be done right now with Stack16 format and AviSynthShader.

Ugly and slow. Dead end but exists because of Avisynth limitations.


In terms of major features, there are 2 options for next steps:
1. Getting x64 to work as expected

I think this point now depends on plugin writers.


2. Implementing 16-bit support
Which one is most important?
I believe that fixing the code for x64 might uncover a few hidden issues affecting the x86 build. Working on 16-bit support is definitely more exciting to program.

The second point is more entertaining for me. Personally I don't like coding if there is no fun in doing it.

I wouldn't convince anyone. We are still in the phase of convincing plugin writers to support the avs 2.6 color spaces as a minimum.

[Reel.Deel]

Then I think we should create a version with real installer. Volunteer needed for this task.


stax76 made installers for r1779 and r1825, maybe he can help out.

Perhaps it would be good to post this list on the first page of this thread? It's difficult to find.

I tried this list and this showed up corrupt

nnedi3_rpow2(2)


Adding this doesn't help

SetFilterMTMode("nnedi3_rpow2", MT_MULTI_INSTANCE)


So the problem must be in one of the other filters being called by NNEDI3; kind of hard to debug.

It seems the output for nnedi3_rpow2 is corrupt for all colorspaces except YV24 and Y8. nnedi3_rpow2 uses the turning functions and resizers (for correcting center shift, only when cshift is enabled). Maybe jpsdr can help out.

SetFilterMTMode("nnedi3", 2)
SetFilterMTMode("nnedi3_rpow2", 2)

ColorBars()
ConvertToRGB24()
nnedi3_rpow2(2)
Prefetch(4)

You can add this to the list.
ConvertToShader, ConvertFromShader and Shader support MT=1. ExecuteShader supports MT=2.
I'll add it, better yet, maybe you can make your plugin self-register the appropriate MT mode. Take a look here: http://forum.doom9.org/showthread.php?p=1667529#post1667529

Why not use the existing installer? Who produced it? Is the source code available? Ideally we'd have an open source Inno Setup project file that anyone can edit and build. I'd put that Inno Setup file in the same repository as AviSynth+.
Line0 made the installer and it's already in the repository: https://github.com/pinterf/AviSynthPlus/tree/MT-pfmod/distrib

[yesmanitsbearman]

Just a random note, I have done a first full 64 bit encode with
sanimebob()
srestore(omode=4, cache=10).srestore(frate=23.976)
smam()

Only thing that was missing really is GrunT plugin x64 build. I have made one and posted in appropriate thread. Perhaps someone can add it to the wiki.

[qyot27]

After this I think I will clean the code a bit and merge back all my modifications to my master branch and get rid of the pfmod suffix.
The better way would be to open a pull request for your changes (not with the fixes from Chizuken, etc.) on the upstream git repo, just to keep things clean. Upstream doesn't use master for the MT stuff yet, so it could potentially create all sorts of headaches when/if ultim shows up again.

I have no clue if anyone else (tp7?) has commit privileges to the main repo; because it would make things a lot easier if more than one person had the ability to push and were more easily contacted, just in case. Worse comes to worst, a new organization and repo setup would be needed to make sure there's always someone to commit (I could do that, I just would prefer not to until there's no other choice).

And remember when cleaning up that AviSynth+ uses four white spaces for indentation, not tabs.

There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?). Or playing with preparing the core for 16bit/float support, this will require an extended interface later.
ultim started adding stubs for a newer AviSynth+-specific API, but it's never stabilized. High bit depth likely would have been part of that.

The non-MSVC compiler thing would mostly be when targeting non-Windows. Linux and OSX support in particular (clang is OSX's and FreeBSD's default compiler).

Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future? Can we expect a more dynamic development cycle there or we can experiment with it freely? I could ask them (who?) directly but maybe you, old guys here with broader knowledge on the avs history and developers can give some informations about it.
Generally, we've been caring less and less about what classic AviSynth does, if only for the fact that the entire reason Plus exists is because Classic (or rather, IanB, who is pretty much the only active dev to classic aside from Wilbert occasionally fixing things) was resistant to ultim's changes - partly because there were so many of them at the time*. But 2.6 development has been moving at a snail's pace for years; last I checked, the CVS for it hasn't been touched since last September.

*somewhere around 56 commits; but after the fork happened, Plus development rocketed forward with several hundreds of commits in a very short timeframe. And then Plus entered a hiatus for about a year, then another sprint of activity in March 2015, and that's more or less where we are today.

In the wake of 2.6's RC1 and RC2/RC3/Final updates, I've taken the CVS history, compared it against AviSynth+, determined to the best of my ability what can be merged, and opened a pull request containing those changes. The RC1 integration was what started things up again in March 2015, which eventually left off at r1825. RC2/RC3/Final was so meager that it still hasn't been merged (also, there was a bit of a back-and-forth about the issues of Plus' changes to avisynth.h during the restricted license era and moving them up into the restored-clause header; the C interface header, avisynth_c.h, never had this problem - it's completely unique to the C++ interface AviSynth traditionally focused on).

Isn't AviSynth supposed to be written with plain C to work with various compilers?
AviSynth is written in C++. AviSynth+ moved this requirement to C++11. It's only ever been expected to be compiled on MSVC or MSVC-compliant compilers (like ICL), so things like portability weren't that big of a concern.

The problem isn't actually the code, it's the fact that the main AviSynth API was written in C++ as well, which means that C++ plugins have to be built with the same compiler as the core or else they'll fail to load. This stems from VC++ and g++ not being compatible with each other's addressing and name mangling and all sorts of other things. For plain C, cl and gcc are [mostly?] compatible, and is why the C interface exists.

At least what I hoped (and the talk seemed to be leaning toward) was that any new AviSynth+ APIs would be written in C or the C interface would be mainlined and focused on (especially with a potential move to Linux/OSX), which would erase the portability problem from the start. The C++ problem doesn't matter on non-Windows, though, since they don't have the VC++/g++ divide to worry about.

There are intrinsics, the problem was mentioned recently.
The intrinsics issue has less to do with whether it will build and far more to do with not causing grief for users with even slightly older computers to use them. It was also specifically in regard to building with GCC; if Clang truly does not require the same 'intrinsics must be split' nonsense, then dealing with them is not the dealbreaker for cross-platform support that it is with GCC.

The intrinsics themselves are portable; in fact, they replaced the extremely non-portable SoftWire assembly that classic AviSynth relies on (and improved performance over SoftWire in most cases as well).

[TheFluff]

Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future?

Isn't AviSynth supposed to be written with plain C to work with various compilers?

The current Avisynth 2.6 development effort (alpha release earlier today!) is dedicated to making it possible to build Avisynth with any Microsoft Visual C++ version newer than 6.0. Up until now, it was not possible to build "official" Avisynth builds with any compiler other than VC6. Microsoft Visual C++ 6.0 was released in 1998. I don't call Avisynth software for the previous millennium only to provoke people - it's the literal truth.

Official Avisynth development is as dead as a doornail. You don't need to care about what happens with it. You don't even need support its plugins if you don't want to (but you can if you want to; if VS can fake the plugin interface so can you). Fork away - there are already like five commonly used variants competing for attention so one more can hardly hurt.

[MysteryX]

Official Avisynth development is as dead as a doornail. You don't need to care about what happens with it. You don't even need support its plugins if you don't want to (but you can if you want to; if VS can fake the plugin interface so can you). Fork away - there are already like five commonly used variants competing for attention so one more can hardly hurt.
To be honest, the advantage of AviSynth over VapourSynth is mainly the vast library of available plugins.

If you create a custom interface for AviSynth+, I think it is very unlikely that plugin developers will get back in the game years after they wrote their plugin to support the new interface. Working on porting those plugins to VapourSynth would be a better path for them.

But then VapourSynth has these limitations:
- No ffdshow support for SVP
- No audio support yet
- Limited library of plugins

In which cases AviSynth+ comes to the rescue.

[MysteryX]

btw, AviSynth 2.6 requires DevIL. Does AviSynth+ depend on that same library?

[MysteryX]

Bug: NNEDI3 simply doesn't work with MT. It causes image corruption.


SetFilterMTMode("DEFAULT_MT_MODE", 3) #neither 2 nor 3 works
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3_rpow2(2, Threads=1)
Prefetch(8)


So this looks like a bug in AviSynth+. Without MT, it works.

[TurboPascal7]

I have no clue if anyone else (tp7?) has commit privileges to the main repo; because it would make things a lot easier if more than one person had the ability to push and were more easily contacted, just in case.

I have full repository rights and unless something unexpected happens will be there to (at least lazily) review the changes and merge the PR, assuming debug/blogging commits (https://github.com/pinterf/AviSynthPlus/commit/7e0ae85b9e00b4a405f86bc4aeca6ced69732b22) will be cleaned up.

[Groucho2004]

Bug: NNEDI3 simply doesn't work with MT. It causes image corruption.


SetFilterMTMode("DEFAULT_MT_MODE", 3) #neither 2 nor 3 works
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3_rpow2(2, Threads=1)
Prefetch(8)


So this looks like a bug in AviSynth+. Without MT, it works.

Try this:
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3(dh = true, Threads=1)
fturnleft()
nnedi3(dh = true, Threads=1)
fturnright()
Prefetch(8)

[pinterf]

I have full repository rights and unless something unexpected happens will be there to (at least lazily) review the changes and merge the PR, assuming debug/blogging commits (https://github.com/pinterf/AviSynthPlus/commit/7e0ae85b9e00b4a405f86bc4aeca6ced69732b22) will be cleaned up.
Yes, that's why I still left my original master branch untouched, did not want to mess it up with excessive comments that were important for me at that time.

[MysteryX]

Try this:
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3(dh = true, Threads=1)
fturnleft()
nnedi3(dh = true, Threads=1)
fturnright()
Prefetch(8)

This one is working; and with turnleft instead of fturnleft it works too. Strange that the standard function is failing.

edi_rpow2 works though.

[jpsdr]

Maybe jpsdr can help out.

Sorry, but not realy. I don't see anything suspcious in the code, but and all the MT thing is not realy my stuff.
I think the code for nnedi3_rpow2 is linear (and clear i hope...) enough to reproduce all the steps/functions used in an avs script, if someone want to investigate.

[pinterf]

This nnedi_rpow2 thing happens in YV12 and YV16. No Prefetch and Prefetch(1) is OK. Nice task.

[jpsdr]

In that case, it probably also happen in YV411 and YUYV.
As it can easely be seen in the code, there is two paths : (RGB24,YV24,Y8) and (YV16,YV12,YV411,YUYV).
The only major difference between them it's that in case of YV16 and others, planes are extracted and processed separately.
But again, i see absolutely nothing wrong.
If the MT mode is not happy with the way i do things, you'll have to explain me where and why. :confused:
The code is avaible on github, so anyone is free to take a look.

[MysteryX]

If MT doesn't like it, the question remains: why does it work with AviSynth 2.6 and not in AviSynth+?

[Groucho2004]

In that case, it probably also happen in YV411 and YUYV.
As it can easely be seen in the code, there is two paths : (RGB24,YV24,Y8) and (YV16,YV12,YV411,YUYV).
The only major difference between them it's that in case of YV16 and others, planes are extracted and processed separately.
But again, i see absolutely nothing wrong.
The problem is the same in the original nnedi3 from tritical. I don't think your changes have anything to do with it.

[Chikuzen]

Interesting information was written on comment space of this page by Takuan (Oh, he is my internet friend:D).
http://archive.fo/DvrEB

Takuan 2014/3/22 05:37

DGDecode_MPEG2Source returns 'env->Invoke(“crop”, AVSValue(CropArgs,5));' when crop is needed.
avs+ recognizes this filter as Crop(), not MPEG2Source() in this case.
avs+ tries to make MPEG2Source() work as MT_NICE_FILTER because Crop() is set as MT_NICE_FILTER internally.
This is why MPEG2Source crash on avs+'s MT mode.

Thus, you should set SetFilterMTMode("Crop", MT_SERIALIZED, force=true) when MPEG2Source requires Crop().

Probably, nnedi3_rpow2 will be recognized as internal resizer(MT_NICE_FILTER).
So you should use user script function instead of nnedi3_rpow2 when you want to set prefetch() if my guess is correct.

[Reel.Deel]

Interesting information chikuzen. I saw that too when I asked about the force parameter in SetFilterMTMode, I didn't quite understand it though. The MPEG2Source issue was fixed so maybe there's hope for nnedi3_row2. More information here: https://github.com/AviSynth/AviSynthPlus/issues/37