Dub broken for compilers older than 2.084 (std.net.curl does not understand http2)

I was going to raise a PR with the following patch:
diff --git a/lib/compiler.js b/lib/compiler.js
index 9daff27..839716c 100644
--- a/lib/compiler.js
+++ b/lib/compiler.js
@@ -73,7 +73,9 @@ function dmd(version) {
             `http://downloads.dlang.org/nightlies/dmd-master/dmd.${version}`
             : beta ? `http://downloads.dlang.org/pre-releases/2.x/${folder}/dmd.${version}`
                 : `http://downloads.dlang.org/releases/2.x/${folder}/dmd.${version}`;
-        const download_dub = minor !== undefined && minor < 72;
+        // Dub versions shipped with dmd older than 2.084 have broken HTTP/2 support.
+        // See: https://github.com/dlang/phobos/pull/6752
+        const download_dub = minor !== undefined && minor < 84;
         switch (process.platform) {
             case "win32": return {
                 name: "dmd",
diff --git a/src/compiler.ts b/src/compiler.ts
index f7f63be..5b11eed 100644
--- a/src/compiler.ts
+++ b/src/compiler.ts
@@ -78,7 +78,9 @@ async function dmd(version: string): Promise<CompilerDescription> {
         : beta ? `http://downloads.dlang.org/pre-releases/2.x/${folder}/dmd.${version}`
             : `http://downloads.dlang.org/releases/2.x/${folder}/dmd.${version}`;

-    const download_dub = minor !== undefined && minor < 72;
+    // Dub versions shipped with dmd older than 2.084 have broken HTTP/2 support.
+    // See: https://github.com/dlang/phobos/pull/6752
+    const download_dub = minor !== undefined && minor < 84;

     switch (process.platform) {
         case "win32": return {

However, looking at the download_dub logic, I see the following comment:
export async function legacyDub(): Promise<DubDescription> {
    // download some dub version for legacy compilers not shipping dub
    // this is the last version on the old download page from September 2018

The HTTP/2 fix was applied to Phobos in November 2018, so the legacy dub is useless as well.

I thought the registry was not using HTTP/2 because of this ?

It seems that someone forgot and switched over to http2 only anyway. I ran into this earlier in the year and had to backport the patch to gcc-10 (gdc is used to build dub on many distros).

The fix happened May 15th: https://github.com/dlang/dub/issues/1928#issuecomment-628798265

I myself forgot about it until I ran into it again using 2.081 compiler here.
https://github.com/sociomantic-tsunami/neptune/pull/258

sociomantic-tsunami/neptune#258

The failure looks completely unrelated to me, this is using Travis, not the Github Action.

Look in the actions tab. ;-)

Yeah it's trying to look up https://github.com/sociomantic-tsunami/neptune/blob/v0.x.x/src/internal/dub.sdl on the registry, no wonder it gets a 404

So you think that it's a coincidence that 2.084 works?  Maybe there was another change in dub that fixed a dependency resolver bug?

So you think that it's a coincidence that 2.084 works? Maybe there was another change in dub that fixed a dependency resolver bug?

Yep I think it's a coincidence. But I don't know how it didn't work before, because 2.084 was released in January 2019, long after those scripts were written. I would just go with the latest version and call it a day.

If you're on Travis, you can manually opt-in to the latest dub with the little known dmd-<version>,dub. It's also possible to specify a specific dub version this way, but by default it should download the latest one.

So you think that it's a coincidence that 2.084 works? Maybe there was another change in dub that fixed a dependency resolver bug?

Yep I think it's a coincidence. But I don't know how it didn't work before, because 2.084 was released in January 2019, long after those scripts were written. I would just go with the latest version and call it a day.

I don't think it's the scripts that have changed, but the upstream dependencies.

If you're on Travis, you can manually opt-in to the latest dub with the little known dmd-<version>,dub. It's also possible to specify a specific dub version this way, but by default it should download the latest one.

Doesn't seem to work with the actions script.
https://github.com/sociomantic-tsunami/neptune/pull/258/checks?check_run_id=1002789543

I'll close this for now then, as the original claim seems to have been fictitious.
Though maybe a new feature request should be opened to allow choosing an alternative version of dub that is not supplied with the compiler (i.e: fetch the latest 1.22 release).

Doesn't seem to work with the actions script.
https://github.com/sociomantic-tsunami/neptune/pull/258/checks?check_run_id=1002789543

Yes, it only works with the installer script which is used by Travis.

Though maybe a new feature request should be opened to allow choosing an alternative version of dub that is not supplied with the compiler (i.e: fetch the latest 1.22 release).

https://github.com/dlang-community/setup-dlang/issues/30


Need Error Handlers

At the moment whenever the server encounters an error the default error page is shown and that is messy.

Two commits on June 16 2020 solve this


the argument of C&W attack API

Hi, I have a question in the advtest_other.py
row 283:  adv_x = att.generate(x_place, is_MMC=is_MMC, **att_params)
But the att is from the cleverhans library. the official API doesn't have this argument. So I think you modify the source code of cleverhans a bit.
Can you upload the modified source file? I hope it's just one file.

Our evaluation is based on cleverhans: 2.1.0. To perform adaptive attack, please manually modify the function model_loss of the file utils_tf.py (in the source code of cleverhans) by substituting the softmax cross-entropy loss with other adaptive objectives, e.g., out=-tf.reduce_sum(logits * y, axis=-1). The API of the att function can simply add an argument to activate the adaptive loss


Refactoring Marcin's FASTA file creation example

JIRA KBASE-3037:

Current coverage is 53.90%

Merging #109 into develop will increase coverage by +0.07% as of 4d76994

@@            develop   #109   diff @@
======================================
  Files            15     14     -1
  Stmts          2370   2354    -16
  Branches          0      0
  Methods           0      0
======================================
- Hit            1276   1269     -7
  Partial           0      0
+ Missed         1094   1085     -9

Review entire Coverage Diff as of 4d76994

Powered by Codecov. Updated on successful CI builds.

OK, thanks. The protein_to_fasta test suceeded while the GFF example had
some import problems.
I'm vague on what was not working (aside from the import I reported on
Friday for the GFF example) -- and what you did to fix it ...  Well, you
probably didn't fix that one problem I was aware of because it has no edits
in the commit :)
The major change seems to be adding the example directly to
genome_annotation_api.py
which originally did a test more like my GFF example. The GFF example is
actually a better test of multiple related API methods and the underlying
data structure, so my thinking is we actually want to keep that one (or a
modified version of it, perhaps based on my new GFF example). Also my
understanding was that all files with prefix 'test_' were run as part of
the global test but now its unclear whether I should be adding more
examples named with test_.
And you prefer the collapsed style of function calls? Its harder to test
and not really great practice I thought ;)
temp_files.append(proteins_to_fasta(url))
On Mon, Nov 9, 2015 at 5:41 PM, Dan Gunter<EMAIL_ADDRESS>wrote:

JIRA KBASE-3037:
You can view, comment on, or merge this pull request online at:
https://github.com/kbase/data_api/pull/109
Commit Summary

Create plot_genome_data.ipynb
improved GC distribution plot, still missing legend
a series of small improvements
Create future_Genom_Landing_Page_features.md
Merge remote-tracking branch 'upstream/master'
added scaling of poits by number of genes on contig
all scatterplots scaled by number of contig features
Nx plot now reflects contig length steps
create another wrapper function so now in last code cell a user can
just provide a genome id and the analysis and plots will execute
scatterplots for different feature count vs contig length
moved legend
common scale for scatterplot points
Merge remote-tracking branch 'upstream/develop' into develop
Merge remote-tracking branch 'upstream/develop' into develop
Merge remote-tracking branch 'upstream/develop' into develop
more advanced API examples inspired by Ranjan's narrative
removed doc which moved to another repo
Merge remote-tracking branch 'upstream/develop' into develop
added instructions for data install in README.md
added test to fasta file dump example
Merge remote-tracking branch 'marcin-examples/develop' into
marcin-examples
renamed and got marcins code to work

File Changes

M README.md
https://github.com/kbase/data_api/pull/109/files#diff-0 (34)
M docs/annotation_api.rst
https://github.com/kbase/data_api/pull/109/files#diff-1 (7)
M lib/doekbase/data_api/tests/examples/genome_annotation_api.py
https://github.com/kbase/data_api/pull/109/files#diff-2 (106)
A lib/doekbase/data_api/tests/examples/get_mRNAs_for_gene_to_GFF.py
https://github.com/kbase/data_api/pull/109/files#diff-3 (84)
M
lib/doekbase/data_api/tests/examples/test_genome_annotation_api.py
https://github.com/kbase/data_api/pull/109/files#diff-4 (14)

Patch Links:

https://github.com/kbase/data_api/pull/109.patch
https://github.com/kbase/data_api/pull/109.diff

—
Reply to this email directly or view it on GitHub
https://github.com/kbase/data_api/pull/109.

@realmarcin, you were not setting up the WS URL using the 'shared' module and you stuck run() at the top level of the file so it ran on import. we can keep GFF but I wasn't sure what it was doing so I commented it out for now.
I feel it's easier to just have one set of examples per API, since that is how they are going to be included into the docs (see docs/annotation_api.rst). So, as I did with taxon I made it into a function inside the most appropriate API file.

On Mon, Nov 9, 2015 at 6:09 PM, Dan Gunter<EMAIL_ADDRESS>wrote:

@realmarcin https://github.com/realmarcin, you were not setting up the
WS URL using the 'shared' module and you stuck run() at the top level of
the file so it ran on import. we can keep GFF but I wasn't sure what it was
doing so I commented it out for now.

Fine by me -- note that the fasta dump limits it to three proteins.

I feel it's easier to just have one set of examples per API, since that is
how they are going to be included into the docs (see
docs/annotation_api.rst). So, as I did with taxon I made it into a function
inside the most appropriate API file.

OK but now if I add other examples, which I'm developing as a separate
scripts, it would be added to the monolithic test code? Somewhere else? Or
do you mean just a single example per API period? I discussed additional
examples with Matt, particularly ones that used multiple method calls and
APIs. Let me know if we have any naming/structuring preferences there.

I think there is some confusion -- we are looking at different files
or versions. It looks like something happened with the PRs. I
submitted PR 104 which was closed due to being against master -- but
then I made a new PR against develop and it sounded like Keith saw
that (on slack). Also it looks like PR 102 is still open -- I'll
repost this puzzle on slack.
Also I didn't create genome_annotation_api.py or
test_genome_annotation_api.py. And the two examples I PRed didn't have
the issues you listed below (note that the GFF example test isn't
committed yet).

@realmarcin, you were not setting up the WS URL using the 'shared' module

I mirrored the Taxon API example exactly -- so whatever shared module
use there was, is there:
###test_proteins_to_fasta.py
def setup():
shared.setup()
def test_examples():
url = shared.services['workspace_service_url']
proteins_to_fasta.run()

and you stuck run() at the top level of the file so it ran on import.

Do you mean in proteins_to_fasta.py?
This is the end of that file (in the GFF example i also have the
execution code at the end of the file):
def run():
genomeref = "PrototypeReferenceGenomes/kb|g.3899"
genome = ObjectAPI(services, token=token, ref=genomeref)
genome_annotation = GenomeAnnotationAPI(services, token, ref=genomeref)
proteins= genome_annotation.get_proteins()
fasta = get_protein_fasta(proteins)
outfile = '3899_prot.fasta'
print outfile
with open(outfile, 'w') as f:
f.write(fasta)
run()

we can keep GFF but I wasn't sure what it was doing so I commented it out for now.

git history shows you were the last editor of
genome_annotation_api.py


MAINT: get orsopy working in 3.12. Closes #115

Adds a whole bunch of boilerplate in init functions, but would get orsopy working on 3.12.

HI @andyfaff ,
coult you explain your idea behind this changes a bit. For me this looks like making the Header classes much harder to extend and adding a lot of code to all classes doing init routines that should actually be handled by the dataclass meta functionality.
What do we gain from using dataclass at all, if we need a custom init function for bascially every class?

Unfortunately the stdlib dataclasses (from lib/dataclasses.py) aren't designed to accept extra keyword arguments to create attributes that aren't listed on the class. e.g. one can't have HeaderDerivedClass(attr1, extra_attr=5), where attr1 is specified in the class definition, but extra_attr isn't. Because one of our use cases was to allow these unknown attributes we had modify how the dataclasses worked. This was done by creating the orsodataclass decorator.
orsodataclass required a knowledge of how dataclasses worked internally, together with the creation of _custom_init_fn and _create_fn, as well as several private attributes/functions from the dataclasses module. Unfortunately cp312 altered how some of these functions worked internally. Before cp312 various variables were created in our version of _init_fn using:
locals = {f"_type_{f.name}": f.type for f in fieldsarg}
However, in cp312 the stdlib _init_fn creates them like:
locals = {f'__dataclass_type_{f.name}__': f.type for f in fields}
This means that our _custom_init_fn works with cp<312, but not with cp312 because the rest of lib/dataclasses.py is incompatible with the variable naming scheme.
It may be possible to make a shim for this particular use case, but it's a fragile solution. I don't think we should be depending on our knowledge of the internals of dataclasses, or on private functions/attributes, because it's inherently subject to change outside our control. Every time a new Python version comes out we have to hope that nothing has changed (e.g. look at orsopy.dataclasses to see how one has to do various meddling for different Python versions. Speaking of which I could probably delete that file).
So, how is a solution reached? The first solution could be to vendor the lib/dataclasses.py file from stdlib. In that way we could keep our existing customised dataclass operation. However, I actually find the existing code quite hard to work with, because the monkey patching means you have to be familiar with lib/dataclasses.py as well as our overlay.
This PR takes a different route. Instead of using an orsodataclass decorator we just use the dataclass decorator directly. In order to provide the ability to provide the extra_attr mentioned above we have to write an __init__ method for each class.
e.g. for orsopy.fileio.base.Value we add:
    def __init__(self, magnitude, unit=None, error=None, *, comment=None, **kwds):
        super(Value, self).__init__()
        self.magnitude = magnitude
        self.unit = unit
        self.error = error
        for k, v in kwds.items():
            setattr(self, k, v)
        self.comment = comment
        self.__post_init__()

In this way we can add extra kwds without any issues.  The stdlib does allow for dataclasses to provide their own __init__ methods, so operation is quite simple. One just has to make sure that one calls __post_init__ at the end of initialisation.  IMO this approach is much simpler than the existing code. It's straightforward to extend/add extra attributes. We just add an extra parameter to the __init__ method, and specify the attribute in the class definition. The drawback is that it does add an amount of boilerplate initialisation.

What do we gain from using dataclass at all, if we need a custom init function for bascially every class?

It's basically the same __init__ method, but with different attribute names.  The main reason we still benefit from using dataclasses is the validation carried out in Header.__post_init__ and Header._resolve_type. This is important when creating instances (no point in creating Value("qwerty") when it should be Value(1.0)) of all the Header classes. However, it's even more important when we de-serialise all the yaml. dataclasses can store all their types in their field information, and we use those types to figure out how to marshal the data into the different Header classes.

What about this as the init function for Header, inherited by all the subclasses?  It seems to work.  Then you don't have to define an __init__ function for every class.
    def __init__(self, *args, **kwargs):
        self._orso_optionals = []
        own_fields = fields(self)
        own_field_names = [f.name for f in own_fields]
        field_index = 0
        for a in args:
            # field order is guaranteed
            setattr(self, own_field_names[field_index], a)
            field_index += 1
        for (k, v) in kwargs.items():
            setattr(self, k, v)
        if not hasattr(self, 'comment'):
            self.comment = kwargs.get('comment', None)

        self.__post_init__()

Update: this __init__ function makes all the tests pass (after removing all the other init functions except class Orso and class Header:
class Header:
    """
    The super class for all of the items in the orso module.
    """
    _orso_optionals: List[str] = []

    def __init__(self, *args, **kwargs):
        self._orso_optionals = []
        own_fields = list(fields(self))
        for a in args:
            # field order is guaranteed
            field = own_fields.pop(0)
            setattr(self, field.name, a)
        # process the rest of own_fields, in order:
        for field in own_fields:
            if field.name in kwargs:
                field_value = kwargs.pop(field.name)
            elif field.default_factory is not MISSING:
                field_value = field.default_factory()
            elif field.default is not MISSING:
                field_value = field.default
            else:
                raise ValueError(f"missing positional argument \"{field.name}\" for class {self.__class__.__name__}")
            setattr(self, field.name, field_value)
        # process any remaining kwargs:
        for (k, v) in kwargs.items():
            setattr(self, k, v)

        self.__post_init__()

I am curious why extra kwargs are added as class attributes for every class except Orso?  Why do we use the specially-created attribute user_data for that one class?
Attached is a diff, that if applied to this PR (in its current state) makes it pass all the tests.
inherit_init_patch.zip

Update: this init function makes all the tests pass

I tried the patch. There are pros and cons. On the one hand it makes all the classes derived from Header cleaner by removing all the boiler plate. However, it has an unfortunate side effect of making the help/docstring more opaque - the call signature gets replaced by *args, **kwargs instead of the actual signature that would be accepted.
>>> Person?
Init signature: Person(*args, **kwargs)
Docstring:
Information about a person, including name, affilation(s), and contact
information.
File:           ~/Documents/Andy/programming/orsopy/orsopy/fileio/base.py
Type:           type
Subclasses:

There would seem to be a tradeoff here. Personally I would prefer to see the correct signature than remove the boilerplate. What are your thoughts?
(I wonder if it'd be possible to write yet another decorator that would restore the function signature that would be displayed by help)

I am curious why extra kwargs are added as class attributes for every class except Orso? Why do we use the specially-created attribute user_data for that one class?

I can't remember why it's called user_data rather than anything else. It's used to include/absorb extra fields from the Header. I'd be wary about removing it though.

(I wonder if it'd be possible to write yet another decorator that would restore the function signature that would be displayed by help)

e.g.
def modify_docstring(cls):
    cls.__doc__ += str(cls.__annotations__)
    return cls

@modify_docstring
@dataclass(init=False)
class Person(Header):
    name: str

I agree, the lack of meaningful signatures is not great.  This problem we're trying to solve, creating classes where core attributes are strongly typed and documented, but where extra attributes can be added (and serialized, and deserialized!), is hard.
I have to say it feels weird to tack on random attributes to a defined class here in almost 2024 - while it felt completely normal to me 10 years ago.  I think the accepted practice on this is shifting with the mainstream use of type hints and dataclasses.

The advantage of being able to cope with extra attributes can be important in versioning orsopy. For example, we could add new attributes in a later orsopy. Files created by that newer version should still be loadable by an older version that copes with extra attributes.
I propose:

merge this PR as-is (if Artur agrees)
continue the discussion onto how/if to replace the boilerplate, and working around the docstring issue if we use the suggested patch.
make a concerted effort to complete #107. Artur wasn't sure about that one. I would like to get something along these lines completed so I can start contemplating ORSO files with detailed resolution information.
make a release.

I would be against merging this PR, we should have an extended discussion about this as it is the basis for all orsopy classes. (And it might even break genx or other software the builds on orsopy by extending classes.)
I have a few main objections with this solution:

If we want people to adapt and extend the data format, it should be as simple as possible for them. They should not have to know about our library internals to be able to create a Header derived class. That is given if you can just derive from another class or use the same logic as when creating dataclasses but not the case if you need to write custom init functions whose logic you don't understand as an outsider.
The previous solution concentrated business logic to deal with these keywords in one place, now it is spread over all classes and might make as suceptible to bugs if something is missed in one of these classes. It also makes the code less readable.
Skipping the dataclass init removes some of the dataclass functionality and could again brake, if they change how dataclasses work. For me it also seems that we re-do the main functionality of dataclasses ourselfs, in which case we could directly remove that part and keep the whole logic contained in orsopy.

For me there are two alternative routs that might be more practicle:

Go for the metaclass solution that we had in discussion at the beginning of the project. This way the classes can just be derived withou any need for @dataclass etc.
Follow Andrews suggestion of just shipping orsopy with the original dataclass module from python 3.11 (maybe reneamed) and the modifications we need for orsopy. For me this is the easiest and cleanest solution, all internal code can stay the same and we probably don't want future changes in how types/dataclasses work in this project, anyway.

I'm sorry to slow you down at this point. I'm aware that this is just based on my opinion and if everyone disagrees you can obviously go ahead in this direction.
Unfortunately I didn't have much time to invest in the last couple of months and will be on vacation starting tomorrow. If you don't mind to wait so long, we could have a videocall end of January about this.

I hope you have a good holiday. Given that you'll be away before I can reply in full, would the genx test suite pick up any issues if we were to go down this path?

I think I agree with Artur that we should rethink our approach.  It probably merits a longer discussion, when we're all back from the holidays.  I think dataclasses provide some helpful features for defining a schema in python, but they are intentionally designed to not support arbitrary init kwargs, since it's kind of the point of a dataclass to define all your fields.
I also don't understand why downstream users couldn't inherit from Header subclasses and add their own fields, instead of tacking attrs to existing classes.  For the migration problem (supporting future changes to the schema), I think we'd be much better served by developing migration functions, which is a fairly standard way to handle schema changes.  The likelihood that future changes to the ORSO standard structure would be purely additive or subtractive of fields is pretty small, and I think that is the only type of schema change we could try to accomodate with arbitrary kwargs.
I know I am likely wrong about some of my concerns above, but my vote is to hold off on any refactor for now.  There's not even e.g. a numba wheel for python 3.12 yet so I don't feel like there's a rush to have complete support for it at the moment.

What do you think of a solution like this: (found on stackoverflow)... instead of trying to force extra kwargs into dataclass init functions (which is hard and fragile), how about adding a new method "from_kwargs" for instantiating one of our classes with extra attributes?  https://stackoverflow.com/a/55101438
We could use that function in the deserializer when reading .ort files, and then we wouldn't have to modify the __init__.  The code for from_kwargs(**kw) would be much simpler, since we're not trying to do all the things dataclass initializers do, just run the built-in init and then add new kw.

This could be a solution that could also be handled with inheritance for most cases without having to write a custom init for every single case. We will have to discuss how to treat the "comments" case. I'll have a look at the code a gain and will try some prototyping. I think after diving back into the code I can better weigh the various pros and cons, too.
Can we find a date for a video call to discuss the strategy? For me the next weeks Mo/Tu look quite good.

I've made a test implementation, have a look at #120

Hi Artur,
good to see you back online. I'll have a look at your suggestions in the next few days.

Resolved by #120


feat: support setting drop effect for drop targets.

Adds an option to the useDrop hook to set the drop effect based on drop target and updates the documentation to reflect the changes.
Since there can be multiple sources of truth for what the drop effect should be (drag source options, drop target options, and alt key being pressed), my PR uses the following precedence (but I'm happy to change it if the reviewer prefers something different)

Use dropEffect from drag source
Use dropEffect from the most deeply nested drop target
If the alt key is pressed, then use "copy"
Default to "move"

Resolves: #3529

Anybody still interested in making this work?


[Feature-Request] Render RAW files from GITHUB, like MD files

Is your feature request related to a problem? Please describe.
I want to create a story with my dependencies list on storybook, example: https://github.com/SConaway/react-native-credit-card-display/blob/master/README.md
I want to render this README.MD on that story without have to copy and paste this MD source code.
A iframe embed would be cool.
Describe the solution you'd like
A component for any url on iFrame maybe or a component specific for Github MD files.
Describe alternatives you've considered
Copy and paste the MD code into my Storybook 🥲
Additional context

Hey @ebellumat Whilst this is a nice idea i don't think GitHub offer an embeddable solution. MDX Embed unifies Embed services that already exist. We do have an embed component for Gists. That's about all we can do at the moment until GitHub create an embed code... on that note if they have please do open another feature request and we'll look into it.

You could render the .md file using MDX @ebellumat
Like what @PaulieScanlon said though, that's not in the scope of this project.


OCPCLOUD-2787: Updates migration cmd to change metrics port

This change:
Removes the defaulting in the code where we set DiagnosticsAddress. It was being overwritten by --diagnostics-address in capiflags.AddManagerOptions() and setting the default value to :8443.
Updates the deployment manifests to pass --diagnostics-address with a value of :8081, so we don't clash with the cluster-capi-operator container running in the pod.

/hold
whilst i work out if we want to expose metrics with ports in the deployment yaml

/retest


implemented suggested fix in #72

Thanks very much for your contribution. It will be included in the next release, I'll try to get a bugfix release out of the door this weekend. I'll keep this PR open for now as a reminder.


Referencing async values with dynamically generated test cases?

Can someone enlighten me on how to reference async values with dynamically generated test cases?
The scenario is as follows:

Tests are dynamically generated through a Function.
A async Function needs to be invoked to fetch the value for which the tests will run against.
The value from the async Function needs to be passed to the test generator Function.

Illustration that doesn't work:
		var testArray = function(input, results) {
			it('should be a Array', function() {
				expect(input).to.be.a('array');
			});

			if (Object.prototype.toString.call(results) === '[object Array]') {
				it('should contain `' + JSON.stringify(results) + '`.', function() {
					expect(input.join()).to.equal(results.join());
				});
			}
		}

		var input;

		before(function(done) {
			require(['some/random/library/on/the/fly'], function(libraryValue) {
				input = libraryValue;
			});
		});

		testArray(input, ['test']);

Issue(s):

We cannot nest it statement(s). If I could in this scenario, it would solve the problem.
Wrapping another describe Function will be invoked immediately and not prior to the before Function completing. If this worked, I could just wrap the invocation for testArray within a describe.

So I really don't see a way around this here without re-writing code.
A hacky solution could be to use a Object reference, but I'm against it.
Example:
		var testArray = function(input, results) {
			it('should be a Array', function() {
				expect(input.results).to.be.a('array');
			});

			if (Object.prototype.toString.call(results) === '[object Array]') {
				it('should contain `' + JSON.stringify(results) + '`.', function() {
					expect(input.results.join()).to.equal(results.join());
				});
			}
		}

		var input = {};

		before(function(done) {
			require(['some/random/library/on/the/fly'], function(libraryValue) {
				input.results = libraryValue;
			});
		});

		testArray(input, ['test']);

I'm unable to find a adequate solution. Any ideas?

A working hack:
		var testArray = function(input, results) {
			it('should be a Array', function() {
				expect(input).to.be.a('array');
			});

			if (Object.prototype.toString.call(results) === '[object Array]') {
				it('should contain `' + JSON.stringify(results) + '`.', function() {
					expect(input.join()).to.equal(results.join());
				});
			}
		}

		before(function(done) {
			require(['some/random/library/on/the/fly'], function(input) {
				describe('hack describe', function() {
					_.testArray(input, ['test']);
					done();
				});
			});
		});

		it('hack it');

I can think of a few good solutions. (Well, the first one's arguably not very good, but I'll leave it up to you to decide whether it's better than the hack you've explored. I think it's less of a hack but only marginally easier to read and understand. I'd recommend either or both of the other two if you're willing to depend on promises and/or an AMD loader.)

Instead of giving the test-defining function the value you asynchronously retrieved, give it a callback to asynchronously retrieve it, to which it will in turn pass the actual test code as callbacks for when the value is asynchronously retrieved.

var testArray = function(getAndUseInput, results) {
    it('should be a Array', function(done) {
        getAndUseInput(function(input) {
            expect(input).to.be.a('array');
            done();
        });
    });

    if (Object.prototype.toString.call(results) === '[object Array]') {
        it('should contain `' + JSON.stringify(results) + '`.', function(done) {
            getAndUseInput(function(input) {
                expect(input.join()).to.equal(results.join());
                done();
            });
        });
    }
}

testArray(function(testInput) {
        require(['some/random/library/on/the/fly'], function(libraryValue) {
            testInput(libraryValue);
        });
    }, ['test']);

Note that if this uses an AMD loader (as it appears to judging from the asynchronous callback require function) then the value found by require will be cached, so the second test will get the same value to test as the first did without waiting for it to be resolved again. If whatever you get the input value from does not cache it, your function for getting it may need to do the caching instead.
Also don't forget to use done so that Mocha knows the test runs will complete by an asynchronous callback.

If you're using an AMD loader, let AMD handle it all.

// --- testArray.js
// Node.js shim, uses synchronous Node.js require to retrieve the dependencies and should therefore work with the commandline test runner.
var define = typeof define === "function" ? define : function define(deps, factory) { module.exports = factory.apply(undefined, deps.map(require)) }

define(function(){ // testArray will be used by other modules to define specific tests; it has no dependencies of its own.
    return function(input, results) {
        it('should be a Array', function() {
            expect(input).to.be.a('array');
        });

        if (Object.prototype.toString.call(results) === '[object Array]') {
            it('should contain `' + JSON.stringify(results) + '`.', function() {
                expect(input.join()).to.equal(results.join());
            });
        }
    }
}

// --- testSomeRandomLibraryOnTheFly.js
// Node.js shim, uses synchronous Node.js require to retrieve the dependencies and should therefore work with the commandline test runner.
var define = typeof define === "function" ? define : function define(deps, factory) { module.exports = factory.apply(undefined, deps.map(require)) }

define(['./testArray', 'some/random/library/on/the/fly'], function(testArray, libraryValue) {
    testArray(libraryValue, ['test']);
});

// --- use in a page
// Run Mocha only after the tests have the chance to load their libraries.
require("./testSomeRandomLibraryOnTheFly", function() {
  mocha.run()
});

If the reason you're using the testArray function to define your tests is so that the same set of tests can be defined for multiple libraries, splitting it up with modules like this may be exactly the sort of thing you're looking for.

Use promises (requires a polyfill for Internet Explorer and/or for older browsers). This is sort of like your initial hack idea inasmuch as instead of passing the value, you synchronously pass a way to retrieve the asynchronously resolved value. It's a better abstraction for it though, doesn't depend on abuse of the before hook or convoluted suite definitions, and makes the eventual use of the value asynchronous as well as the retrieval of it. Basically, promises let you inject asynchronous value retrieval into synchronously structured code by changing only the point where the asynchronous process is kicked off and the point where its result is used. Mocha has direct support for promise-based tests by letting you return a promise -- Mocha will wait for the promise to resolve or error without you having to call done(); this is an alternative way to wrap ordinary asynchronous actions in a test rather than having to use a callback to call done() when the action completes. Handily for your use case, promises also chain -- that is, the promises's then function that takes a callback to run with the resulting value will also itself return a promise, so we can pass a promise into the test definitions and use it naturally by returning the result of the test's use of the promise. And if you think all that sounds complicated, it actually comes out to something really simple and easy to follow in practice:

var testArray = function(input, results) {
    it('should be a Array', function() {
        return input.then(function(value) {
            expect(value).to.be.a('array');
        });
    });

    if (Object.prototype.toString.call(results) === '[object Array]') {
        it('should contain `' + JSON.stringify(results) + '`.', function() {
            return input.then(function(value) {
                expect(value.join()).to.equal(results.join());
            });
        });
    }
}

testArray(new Promise(function(resolve, reject) {
        require(['some/random/library/on/the/fly'], resolve);
    }), ['test']);

I like the fact that this code is pretty much self-explanatory and no longer than my introductory explanation of promises in the first place. I probably don't even need so much introductory explanation given the clarity of the code, but I like talking about the concepts going on.
Another example of promise-based tests is in the Mocha docs themselves; that documentation also links to an interesting library for assertions in this style of test.
Tests using promises can also use done in the promise callback instead of returning the promise, although it's more boilerplate and I'm not sure you'd ever need to do it this way:
    it('should be a Array', function(done) {
        input.then(function(value) {
            expect(value).to.be.a('array');
            done();
        }).catch(function(error){
            done(error)
        });
    });

So, hopefully at least one of those ideas will work for you; let me know what you think!

The first example wouldn't work well for my scenario since I need to share the same async value across multiple tests. I would need to re-invoke the require for each of the separate tests. I know in my initial illustration I'm only showing the testArray Function, but there would be many other tests which would run against the async value. If I basically switch to using require inside a before and passed the callback Function to the testArray Function, that may work. It just seems like an awfully lot of extra unnecessary code to pull this off. Would you not agree?
I'm writing tests for a AMD library. In my scenario, I don't want to use the define Function for these given tests. They're to be strictly isolated to only use the require Function.
As for the promises, I have the same argument/complaint as with the callback Function(s).
I also have to provide browser support going back to IE6 (fun times, I know.)
I could use a polyfill, but I still feel that it's cumbersome and counter-productive.
Thanks for all the suggestions, the callbacks may be the way to go. As of right now this is an example of what I'm using to get it to work. But in this example the test counter in the console progress output is incorrect. The counter will say 3/1 (instead of 3/3) tests ran successfully, since I'm hacking the test cases in.
describe('test/functional/require/module/anonymous/array', function() {
	'use strict';

	// Run the following operations before the tests are invoked.
	before(function(callback) {
		// Load the mocked module.
		require(['base/test/mock/module/name/array'], function(input) {
			// Define the tests for the asynchronous results.
			describe('The mock module should pass the following tests.', function() {
				// Tests the `input` argument.
				_.testArray(input, 1, ['test']);

				// Invoke the callback.
				callback();
			});
		});
	});

	// Mocha work-around to allow tests to be defined through the `before` Function.
	it('asynchronous');
});

Maybe instead I'll switch to something like below.
I would now need to have 2 testArray Functions.
One for sync tests and one for async tests.
Not the end of the world, but far from ideal.
	// The output value from the async callback.
	var output;

	// Run the following operations before the tests are invoked.
	before(function(callback) {
		// Load the mocked module.
		require(['base/test/mock/module/name/array'], function(input) {
			output = input;
		});
	});

	// Generate the Array tests.
	_.testArrayAsync(function() {
		return output;
	}, ['test']);

@ScottFreeCode The callback does actually work better in the case that the test progress indication actually reflects the correct number of tests that were run.

(Editted my initial callback-based example upon realizing I had a little boilerplate in there that wasn't doing anything that couldn't be done directly):
testArray(function(testInput) {
        require(['some/random/library/on/the/fly'], function(libraryValue) {
            testInput(libraryValue);
        });
    }, ['test']);

...is equivalent to...
testArray(function(testInput) {
        require(['some/random/library/on/the/fly'], testInput);
    }, ['test']);

(That's the only change I made.)

If you want to use the callback-based approach with the same library and multiple test[some thing] functions, I'd probably do something like this:
// test sets
function testArray(...) {
...same as my earlier callback-based example...
}

function testSomethingElse(...) {
...equivalent in design pattern, but checking something else about it...
}

// testing a specific library
function testSomeRandomLibraryOnTheFly(testSet) {
    testSet(function(testInput) {
        require(['some/random/library/on/the/fly'], testInput);
    }, ['test']);
}

testSomeRandomLibraryOnTheFly(testArray);
testSomeRandomLibraryOnTheFly(testSomethingElse);

Or, to run multiple different sets of tests against multiple different libraries, something to this effect:
// test sets
function testArray(...) {
...same as my earlier callback-based example...
}

function testSomethingElse(...) {
...equivalent in design pattern, but checking something else about it...
}

function testMultipleLibraries(...) {
...check something about two different libraries?...
}

// This reduces boilerplate at the call site for tying a library to a set of tests and expected result.
function testLibrary(testSet, libraries, expectedResult) {
    testSet(function(testInput) {
        require(libraries, testInput);
    }, expectedResult);
}

// libraries to test
var setsForSomeRandomLibraryOnTheFly = [testArray, testSomethingElse];
for (var index = 0; index < setsForSomeRandomLibraryOnTheFly.length; index += 1) {
    testLibrary(setsForSomeRandomLibraryOnTheFly[index], ['some/random/library/on/the/fly'], ['test']);
}

var setsForSomeOtherLibraries = [testArray, testMultipleLibraries];
for (var index = 0; index < setsForSomeOtherLibraries.length; index += 1) {
    testLibrary(setsForSomeOtherLibraries[index], ['some/other/library1', 'some/other/library2'], ['library 1 value', 'library 2 value']);
}

Since you mentioned using both synchronous and asynchronous code, here's a way to work a synchronous value into the same type of callback-based test sets:
// test sets
function testArray(...) {
...same as my earlier callback-based example...
}

function testSomethingElse(...) {
...equivalent in design pattern, but checking something else about it...
}

// This reduces boilerplate at the call site for tying a synchronously resolved value to a set of tests and expected result.
function testSynchronousValue(testSet, value, expectedResult) {
    testSet(function(testInput) {
        testInput(value);
    }, expectedResult);
}

// values to test
var synchronouslyDefinedArray = ['test'] // This is standing in for wherever the value is being synchronously retrieved from.
var setsForSynchronouslyDefinedArray = [testArray, testSomethingElse]
for (var index = 0; index < setsForSynchronouslyDefinedArray.length; index += 1) {
    testSynchronousValue(setsForSynchronouslyDefinedArray[index], synchronouslyDefinedArray, ['test']);
}

(So you'd have two functions, one for asynchronous libaries and another for synchronously resolvable values, but both would be reusable for multiple different sets of tests and multiple different libraries rather than having to write two of every test set that needs to be run asynchronously or synchronously.)
Does that work out better?

@ScottFreeCode I wound up using a wrapper inside of my test Functions to automatically invoke in the input argument if it's flagged as callback. Thanks for the help.
Do you know what their reasoning was for not allowing nested it statements? It seems like this would be a proper use case.

Glad I could help you to get it working!
I'm fairly new to Mocha, so I can't really say much as to the design decisions of the developers, but for what it's worth, I don't think nested it would solve what you think it would. (I should add at the beginning here the caveat that all this is assuming I've understood correctly; if I've got it wrong, feel free to provide a non-working example of what your preferred code would be if nested it were allowed, or any other clarification merited -- also, I'm going to be saying things like "you want" a lot not because I mean to tell you what you think but because to discuss some of this I have to address your goals, so I apologize in advance if I infer any of them incorrectly.) Practically, what you seem to want to do by calling nested it and what you did in your hacked version where describe is called inside before are the same: delay the definition of the tests by testArray and similar functions until the asynchronously retrieved value to test is resolved. Yet the reason before counts the wrong number of tests is likely also the same as the practical reason it isn't allowed to nest: Mocha seems not to have been designed to add to the set of tests to be run while in the process of running them. Even if it worked inside another it, I suspect that without redesigning Mocha to properly handle/count tests that are defined during the run you would have the same miscounting problem. It might be a little clearer to write because of being able to call testArray directly instead of inside another describe, I suppose, but for all practical purposes we could just as easily fix calling describe inside before and get the same result -- and there's a problem with calling it inside it on a higher level: namely that you'd effectively be creating a collection of tests, and a collection of tests is normally what a suite (created by describe) is, and the difference between a collection of tests defined by a suite and a collection of tests defined by a test isn't obvious on a conceptual level... Having tests sprouting out of tests makes the test program harder to reason about than it would be with a neat distinction between tests and collections of tests (aka suites).
And for all that, even granting that a test system like Mocha could be designed to allow adding to the set of tests to run in the suites and/or tests, I don't think it's a direct solution to your real goal: dealing with asynchronously retrieved values when using a separate function to define a set of tests that can be applied to more than one library or value. You want a sort of dynamic addition of tests at test runtime, whether it nested in describe nested in before or just it nested in it, because you're trying to make the test definition wait for the asynchronously retrieved value to be resolved. In turn, you want the test definition to be delayed until the variable is ready because your test-defining function will capture the variable's state at the point that definition is called. So you're tackling multiple layers of problems each because the way you tackled the layer below it created more problems; in the final analysis, the last problem created is that Mocha doesn't support dynamic addition of tests at test runtime, but that's only indirectly related to what you were originally trying to do: define tests using a separately encapsulated*1, reusable function, yet test a value that must be retrieved asynchronously.
In contrast, both promises and leveraging the loader would address the asynchronicity directly. Using the loader would explicitly declare that these tests will not be defined till the value is retrieved and the whole set of tests is not run till all the tests are defined (rather than not defining some of the tests till the value is retrieved by other tests being run). Using promises would, likewise, explicitly declare that the value being tested will in fact be resolved asynchronously; the need to delay the definition itself is then eliminated neatly. Both are obvious and conceptually simple (even if not necessarily simple to implement); more importantly, both tackle the problem of asynchronicity head-on rather than trying to work around it. I don't think I can say that about either nested it or describe called in before -- in fact, I don't even think nested it is as clear a way to address the issues as using a property in order to refer to the value updated by a blocking before (as in your first post) would be (assuming that could be made to work).
(And callbacks? They're really just a poor-man's ad-hoc substitute for promises. It's conceptually the same: instead of passing the value, pass an object that can handle a callback to use the value when the value is resolved. It's just that the object passed is itself, directly, another callback; it reads more like purely layers of callback nesting -- callbacks taking callbacks! -- and, because of lack of encapsulation*2 of that model, requires a little more boilerplate.)
So, there's the long version of my opinion on it. As with all programming, ultimately, it comes down to tradeoffs and you can choose what matters most to you. As I alluded to initially, I'm really more of a clever outsider when it comes to Mocha; so, maybe the team will decide there are good reasons to define tests during the run, whether this scenario is one of them or not. All I can do is lay out how I reason about it, which solutions I think are better and why, and hope my thoughts on the matter are at least helpful in some way. ;^)
*1, 2 I say "encapsulation" here meaning not data hiding but rather organization of code so that a set of functionality or even a design pattern is written in one place in a decoupled manner and referred to or applied multiple times rather than being written multiple times; I suppose there's probably a better (or at least less ambiguous) term for that, but I can't recall one off the top of my head.

So, apparently it's been too long since I looked closely at the Mocha documentation, because I was just now playing around with some ideas, tried to figure out how to get a commandline option to work, and thanks to reading the list of commandline options I discovered I'd been missing the --delay flag, which if I understand the documentation correctly makes this much easier to do:
var testArray = function(input, results) {
    it('should be a Array', function() {
        expect(input).to.be.a('array');
    });

     if (Object.prototype.toString.call(results) === '[object Array]') {
        it('should contain `' + JSON.stringify(results) + '`.', function() {
             expect(input.join()).to.equal(results.join());
        });
    }
}

require(['some/random/library/on/the/fly'], function(libraryValue) {
    describe("whatever suite(s) this is in, or remove this if none", function() {
        testArray(libraryValue, ['test']);
        run();
    });
});

I'd have to do some digging to find out if this is supported in the in-browser HTML reporter.

https://github.com/mochajs/mocha/issues/2221#issuecomment-214636042 should work :) In regards to using delay in the browser, just be sure to watch out for https://github.com/mochajs/mocha/issues/1799 (order matters due to an unfortunate bug)

Also, here's the relevant PR that introduced the feature:
https://github.com/mochajs/mocha/pull/1439
Thanks @ScottFreeCode for your help! :)


SBOL 2 to 3 Converter: Empty ComponentDefinition conversion

I tried converting something very minimal with the python native converter:
import sbol2
from sbol_utilities import conversion

doc2 = sbol2.Document()
comp = sbol2.ComponentDefinition()
doc2.add(comp)

doc3 = conversion.convert2to3(doc2, use_native_converter = False)

(Note this converts with no problems in the JS converter)
The first error I get is related to namespaces. it seems like the current code does not accept None namespaces when it clearly should (there is even a default mode that should return None):
r._sbol3_namespace(self, obj2)
    351     return namespaces[0]
    352 # Check if the object starts with any of the provided namespaces
--> 353 for namespace in self.namespaces:
    354     if obj2.identity.startswith(namespace):
    355         return namespace

TypeError: 'NoneType' object is not iterable

I then tried giving it a namespace with:
doc3 = conversion.convert2to3(doc2, namespaces = [sbol2.DEFAULT_NS], use_native_converter = False)
I then got an error when extracting the identity to sbol3:
File ~\AppData\Local\Programs\Python\Python311\Lib\site-packages\sbol3\identified.py:60, in extract_display_id(identity)
     58 msg += ' A displayId MUST be composed of only alphanumeric'
     59 msg += ' or underscore characters and MUST NOT begin with a digit.'
---> 60 raise ValueError(msg)

We can see from the code in pysbol3.identified.py that it tries to extract whatever is after the last forward slash:
    [...]
    display_id = parsed.path.split('/')[-1]
    if is_valid_display_id(display_id):
        return display_id
    else:
        msg = f'"{display_id}" is not a valid displayId.'
        msg += ' A displayId MUST be composed of only alphanumeric'
        msg += ' or underscore characters and MUST NOT begin with a digit.'
        raise ValueError(msg)

But the identity in SBOL2 ends with the version, not the ID. In this case my component had identity = 'http://examples.org/ComponentDefinition/example/1'. If I trim the identity first:
comp.identity = "/".join(comp.identity.split('/')[:-1])

Then the conversion runs ok. Should I just implement the trimming or is this expected to break something else? And for the namespace, should the function be looking for a None namespace or is this expected behaviour?

The same applies to the conversion back to SBOL2. I first assumed the version should default to None (which it does right now), but according to the SBOL 3.1 specification:

When SBOL 3.x Identified object is converted to SBOL 2.x, if its identity is a URL, then the identity of
the SBOL 2.x object SHOULD be constructed as [SBOL3 identity]/[SBOL2 version]. If the object does
not have an SBOL2 version property, then its version SHOULD default to 1.

Re-checking the roundtrip conversion, going from 2 > 3 > 2 with component of version = "2.2", I first start with an identity of "http://examples.org/example/2.2" and end with "http://examples.org/example"

Adding to this, keeping the namespace as None and expecting pysbol3 to handle it does not work because it just uses everything before the last separator.
For http://examples.org/ComponentDefinition/example it assumes the namespace is http://examples.org/ComponentDefinition, when it should just be http://examples.org
Therefore to avoid changes to pysbol3 this will have to be handled inside the converter code


make a video on installing a spam bot

Sorry I will not make a video, the instructions in the README are clear enough and if you don't understand commands, then Google is your best friend.


Divide top-level tasks from rest

Right now, when making a new submission, the top level tasks (Applications, Hardware, Error correction and mitigation, Simulation, Compilation) are listed alphabetically in the drop-down list that has recently updated to allow for text input from the user to enable filter search on existing tasks. This way though their different role in the platform is hidden.

I wonder if we want to make their role evident by creating an extra top-level task section where users can simply tick (multiple select) where they belong to.
Additionally based on this condition, also filter results showing only the results of lower-level tasks that fit under a top-level task.
Alternatively, top-level tasks could be automatically added explicitly if the chosen task belongs to a given top level task. For example, I choose ZNE, and QEC/QEM is added automatically.

If the purpose of making a (taxonomic) "submission" is to show "results" of "methods" against "tasks" on "platforms," I'm not sure that we need to allow top-level task selection in this section at all, as top-level tasks don't show results, ever.
What do you think about allowing top-level task selection only as a "parent task," but not as a submission foreign key reference, (i.e. attached to the submission as the user sees it)?

Pinging @willzeng because I do not have a preference (but understood they may have had a suggestion). Main focus should be to solidify existing tasks and related taxonomy to avoid duplication.

What @WrathfulSpatula suggests makes sense to me. Let's do that!


Throw error when ledger db is incompatible

Description
Previously, this would fail with an difficult to decipher error. Now it is much more understandable

backingstore-independent approach that checks if a snapshot is of the desired backingstore-type before trying to initialise a store

Probably this would be the right way to go, indeed.


auto_deband changes/improvments

[ ] downsample_h can unexpectedly break. tracking upstream: https://github.com/AkarinVS/vapoursynth-plugin/issues/9
[ ] Add cambi_mask bool to disable mask from CAMBI map. Sometimes the provided mask is not accurate enough, particularly around the edges of objects.
[ ] anti-dither filter is useful for some inputs and only present when the input is 8-bit. bool?

:pray:

Thanks for opening the issue.
For the first problem, there also seems to be an issue when the clip is not 16/9.
I'll probably try to put a workaround and then update once akarin fixes upstream.
For the second, do you also suggest passing your own mask or should it be handled separately by the user later on?
For the third, what do you mean by anti-dither filter? You mean passing Dither.NONE instead of Dither.ERROR_DIFFUSION?

For the second, do you also suggest passing your own mask or should it be handled separately by the user later on?

I have no suggestion, seems easiest to just let the user handle it afterwards.

For the third, what do you mean by anti-dither filter? You mean passing Dither.NONE instead of Dither.ERROR_DIFFUSION?

https://github.com/AkarinVS/vapoursynth-plugin/wiki/CAMBI#additional-notes

Need more samples but consider calling a simple pre-filter before CAMBI to improve consistency when resampling (particularly relevant at 10-bit): [1, 1, 0, 1, 1, 0, 0, 0, 0]

has there been any update with this?


WIP: Improvements in SUBSTOR-Potato model

Introduced and compiled the PT_BTHTIME sub-routine in the SUBSTOR-Potato model for calculating the non-linear beta thermal time.
Introduced and compiled the PT_MATURITY sub-routine into SUBSTOR-Potato to identify the start of the linear phase of tuber bulking and the attainment of physiological maturity of potato.

NOTE: This is a work in progress and requires cleanup.

Hi Dr @khan004 !
Thanks for all your work on this branch.
I will just close this branch for now because is under development. Please, when you finish all the work on your SUBSTOR model. Open a "Pull Request" again. I will test it and return to you if there is some issues or not.
Thank you.
Fabio Oliveira

Hi Dr @khan004 !
Thanks for all your work on this branch.
I will just close this branch for now because is under development. Please, when you finish all the work on your SUBSTOR model. Open a "Pull Request" again. I will test it and return to you if there is some issues or not.
Thank you.
Fabio Oliveira

Dear Fabio,
Thanks for your support!
I will follow your suggestion.
Best regards,
Khan

It is nice to see someone working on the potato model @khan004 :)


jsPDF.lines does not accept null as "style" parameter

Thank you for submitting an issue to jsPDF. Please read carefully.
Are you using the latest version of jsPDF?
using commit https://github.com/MrRio/jsPDF/commit/2c35e16f66da362afa70dc3c9c5fbc0c60dfddfd
Have you tried using jspdf.debug.js?
Steps to reproduce
var doc = new jsPDF();

doc.lines([[100,00],[0,90],[-30,0,  0,-30,  -100,-90]],
10,10, [1,1], "S", false)

Replace "S" by null and it fails.

I checked the console, but get to error message. So I assume, you mean with "it fails", that the resulting pdf is not looking as expected.
It is working as expected. If you set style to undefined then it will be interpreted as 'S' resulting in strokes. If you set style to null, you explicitly want to have no graphic state operator appending the line operation. Maybe this is kind of bad, because undefined should result the same as null, but backwards compatibility doesnt let me change this.
If i explicitly add the graphic state operator 'S' you get the doc, it will stroke.

null is used for clipping operations. You set first the lines and then you call .clip().

Sorry for being not precise: I got "Invalid arguments passed to jsPDF.lines". But now by whatever reason I cannot reproduce even with 2c35e16.
So I close it for now


Add subject to OciImageManifest

This allows creating accessory artifacts that can be associated with artifacts in a repository. Additionally added a missing error code.

Out of curiosity, where did you find the NOT_FOUND error code? I cannot find it listed under https://github.com/opencontainers/distribution-spec/blob/main/spec.md#error-codes
There is a mention of legacy docker support error codes which states "these error codes are OPTIONAL and clients SHOULD NOT depend on them". I did notice both TagInvalid and ManifestUnverified is listed under OciErrorCode though, so maybe we already set precedent for these codes?

I was seeing a serde json deserialization error saying "not found" was an unexpected error code variant when querying for a manifest that didn't exist. Adding this variant fixed it and allowed me to check the code to determine existence of an artifact.

@thomastaylor312 I think this is ready for review if you get a chance

@fibonacci1729 just for reference this was with Harbor, correct?
https://github.com/goharbor/harbor


Run tests with github actions

To run test action

Have a look at https://github.com/marketplace/actions/setup-clojure
To setup clojure actions.


Network connectivity status (No internet issue)

Hello,
How to get the response code related to network failure after the request has been made. I tried the following way:
`   func decodeErrorMessage(error: AFError) -> String
{
if error.responseCode == NSURLErrorNotConnectedToInternet
{
        }
        if let underlyingError = error.underlyingError
        {
            if let urlError = underlyingError as? URLError {

                switch urlError.code
                {
                case .networkConnectionLost:
                    return "Not connected"
                case .cannotConnectToHost:
                    return "Not connected"
                case .timedOut:
                    return "Timed out error"
                case .notConnectedToInternet:
                    return "Not connected"
                default:
                    return "Unmanaged error"
                }
            }
        }

        return "Unknown error"
    }

`
But it does not fall through the one I want, it always go to default case whenever I get no connect.

It's unlikely you'll ever be able to exhaustively list all errors that could be produced by limited connectivity. If you'd like to inspect the underlying errors from URLSession, I suggest you start by accessing the underlyingError and casting it to URLError. Your various if lets are preventing you from actually checking the errors.
if let urlError = error.underlyingError as? URLError {
  switch urlError.code {
  ...
  }
}

However, URLErrors are not the only type that can be returned by the system. There's also POSIXError and perhaps others. In general, you should ensure your error presentation logic has proper logic to handle unexpected error types.


(sourcetree) AU update no longer working

Expected Behavior
The AU script should update the Sourcetree package
Current Behavior
Current version available from https://www.sourcetreeapp.com/enterprise is 3.1.2. But Atlassian has changed its page once again. The HTML page still contains links to 3.0.17 and the links to 3.1.2 are injected through JavaScript.
Possible Solution
Steps to Reproduce (for bugs)

Run update.ps1 for the Sourcetree package

Context

Your Environment

Package Version used:
Operating System and version:
Chocolatey version:
Install/uninstall gist:

There is already a jira bug on this in the atlassian public bugtracking, but it seems like they do not update this tracker anymore.
https://jira.atlassian.com/browse/SRCTREEWIN-7045

@pascalberger @4nd3r5 is there any kind of API that we can use to make this easier?
Assuming the program auto-updates (or auto-checks), can we piggyback on the same api?

it is somewhere on https://sourcetree-nps-bridge.us-east-1.prod.public.atl-paas.net, but that is all I can see from Fiddler.

@AdmiringWorm  We did this in the past (was changed with https://github.com/chocolatey-community/chocolatey-coreteampackages/commit/8e364c1fd184721e3c4dea0dabc8f6629fdb89f2#diff-62f4977c124b3bb7b884f86a45c8c23d), but they changed installer and update with version 2. Also they have a staged rollout, so there was always discussions at what time the Chocolatey package should update (see discussions on the package page)

@pascalberger here is the only thing I've found on the page that mentions any correct download location (formatted to make it easier to read)
<script type="text/x-component">
{
	"type":"imkt.components.SourcetreeDownload",
	"params": {
		"macURL":"https://product-downloads.atlassian.com/software/sourcetree/ga/Sourcetree_3.1.2_216.zip",
		"windowsURL":"https://product-downloads.atlassian.com/software/sourcetree/windows/ga/SourceTreeSetup-3.1.2.exe",
		"enterpriseURL":"https://product-downloads.atlassian.com/software/sourcetree/windows/ga/SourcetreeEnterpriseSetup_3.1.2.msi"
	}
}
</script>

They also do some funny looking replacements in the following javascript file: https://www.sourcetreeapp.com/assets/build/js/ad-hoc/sourcetree/homepage.min.js?cdnVersion=le (use some kind of javascript formatter to make it readable)

@pascalberger @AdmiringWorm
This seems to be the way some corporations are going for making their websites. The package wps-office-free uses a helper to read the javascript generated pages. I just tried this helper to read the sourcetree website, and it found a url the 3.1.2 version. I can work on a PR for it for later.

a fix for this was merged just now.
https://github.com/chocolatey-community/chocolatey-coreteampackages/commit/dc213b0a166b1527d13062ae5b02297084c68b23


Need Mangio Crepe AI for better voice training

As explained, also we need Index. It doesn't export index atm.

WDYM?
We have index Files already:
"G:\RVC-Webui\logs\keanu_en\added_IVF88_Flat_nprobe_1_keanu_en_v2.index"
It generates them after successful training for however many Epochs you set it to.
Also, you didn´t really explain what Crepe would do better than what we already have available...


Bump to driver version 0.3.2. Fix #64 in accordance with driver changes

Tracks changes in https://github.com/ldbc/ldbc_snb_driver/pull/105

"Looks good to me"!


v0.1.42 ko.json

Korean translation by KLO (discord : KLO#1490)

Ill push into the next public release


MP-9136 - Change Formula type to return valid primitive type

@danield-ap also rebuilt the Solution in order to re-generate all files and commit them as well.
Make sure that the tests are also passing.

@gjorgji-grgovski-authoritypartners When I rebuild the whole solution I get 300+ files deleted and this error message The analyzer assembly 'Nox.Generator.dll' references version '<IP_ADDRESS>' of the compiler, which is newer than the currently running version '<IP_ADDRESS>'.
I never get new files regenerated.