TypeError: bad operand type for abs(): 'FloatNode'

Hi, your work is totally amazing :) I have been using it for a few weeks already and I faced this "bad operand type" issue recently. I have double-checked everything and I'm not using numpy anywhere. I'm little confused with what exactly might have went wrong and I'd be happy to present any working (well, not working, actually :) ) example, but right now it's just unclear what exactly to copy-paste;
Here's the actual loss, bk == autograd.numpy here, data and theta are namedtuple (the packing-unpacking part works just fine with autograd here, tested with other losses):
def predict(self, theta, data):
    const = assert_arr_shape({
        data.X.shape: ('batch_size', self.n_steps, self.n_input_dim),
        data.y.shape: ('batch_size', self.n_hidden_dim)
    })
    h_prev = bk.repeat(theta.h_0[:, bk.newaxis], const.batch_size, axis=1).T
    activation = lambda x: bk.maximum(0, 1-x)
    to_stack = []
    for i in range(self.n_steps):
        input2hidden = bk.dot(data.X[:, i, :], theta.W_input_to_hidden)
        hidden2hidden = bk.dot(h_prev, theta.W_hidden_to_hidden)
        before_activation = (input2hidden + hidden2hidden)
        h_prev = activation(before_activation)
        to_stack.append(h_prev)
    output = bk.stack(to_stack, axis=1)
    assert_arr_shape({output.shape: (None, self.n_steps, self.n_hidden_dim)})

    return output

def loss(self, theta, data):
    pred = self.predict(theta, data)
    last_step_pred = pred[:, -1, :]
    loss = bk.sum(bk.abs(last_step_pred - data.y))
    return loss

The forward pass (loss(x), x-ravel'ed everything) executes just fine, but when I try computing the gradient (autograd.grad(loss)(x)), this exception raises.
It does indeed tries to apply abs() on the np.ndarray that has FloatNode objects instead of actual floats in it.
Thank you!
Ben

 spoiler with call stack
```
   ---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in forward_pass(fun, args, kwargs, argnum)
     30     args[argnum] = merge_tapes(start_node, arg_wrt)
---> 31     try: end_node = fun(*args, **kwargs)
     32     except Exception as e: add_extra_error_message(e)
 in packed_loss(x, data)
101             theta = self.__unpack_x(x)
--> 102             return self.loss(theta, data)
103         return x_init, theta_init, packed_loss
 in loss(self, theta, data)
41         last_step_pred = pred[:, -1, :]
---> 42         loss = bk.sum(bk.abs(last_step_pred - data.y))
43         return loss
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in call(self, *args, **kwargs)
132
--> 133         result = self.fun(*argvals, **kwargs)
134         if result is NotImplemented: return result
TypeError: bad operand type for abs(): 'FloatNode'
During handling of the above exception, another exception occurred:
TypeError                                 Traceback (most recent call last)
 in ()
57
58
---> 59 test_rnn()
 in test_rnn()
54
55     model = BasicRNN(n_hidden_dim=10, n_input_dim=15, n_steps=100)
---> 56     best_theta = model.fit(data)
57
58
 in fit(self, data)
45         # loss_grad = bk.ops.grad(loss)
46         loss1d_grad = autograd.grad(loss1d)
---> 47         self.__test_run(loss1d, loss1d_grad, x, data)
48         data_iterator = self.__warp_data_into_iterator(data)
49
 in __test_run(self, loss1d, loss1d_grad, x, data)
67
68             try:
---> 69                 loss1d_grad(x, **data_clim_pack[1])
70             except:
71                 print("Error while testing backward pass!")
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in gradfun(*args, **kwargs)
20     @attach_name_and_doc(fun, argnum, 'Gradient')
21     def gradfun(*args,**kwargs):
---> 22         return backward_pass(*forward_pass(fun,args,kwargs,argnum))
23     return gradfun
24
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in forward_pass(fun, args, kwargs, argnum)
30     args[argnum] = merge_tapes(start_node, arg_wrt)
31     try: end_node = fun(*args, **kwargs)
---> 32     except Exception as e: add_extra_error_message(e)
33     return start_node, end_node, tape
34
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in add_extra_error_message(e)
411         else:
412             raise_(AutogradHint, (extra_message, etype, value), traceback)
--> 413     raise_(etype, value, traceback)
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/future/utils/init.py in raise_(tp, value, tb)
412             exc = tp
413         if exc.traceback is not tb:
--> 414             raise exc.with_traceback(tb)
415         raise exc
416
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in forward_pass(fun, args, kwargs, argnum)
29     args = list(args)
30     args[argnum] = merge_tapes(start_node, arg_wrt)
---> 31     try: end_node = fun(*args, **kwargs)
32     except Exception as e: add_extra_error_message(e)
33     return start_node, end_node, tape
 in packed_loss(x, data)
100         def packed_loss(x, data):
101             theta = self.__unpack_x(x)
--> 102             return self.loss(theta, data)
103         return x_init, theta_init, packed_loss
104
 in loss(self, theta, data)
40         pred = self.predict(theta, data)
41         last_step_pred = pred[:, -1, :]
---> 42         loss = bk.sum(bk.abs(last_step_pred - data.y))
43         return loss
44
/home/usman/anaconda2/envs/autograd_py3/lib/python3.5/site-packages/autograd/core.py in call(self, *args, **kwargs)
131                         tapes.add(tape)
132
--> 133         result = self.fun(*argvals, **kwargs)
134         if result is NotImplemented: return result
135         if ops:
TypeError: bad operand type for abs(): 'FloatNode'
</details>

I think we don't support calling stack. Can you try rewriting it with concatenate or hstack?
We should wrap it in a primitive to make this error more transparent (if it is indeed the problem).

@mattjj , thank you for such a rapid response! rewriting it with concatenate solved the issue
Yes, that would be really great if unsupported pieces of numpy API would somehow tell that they are unsupported :) or at least if there was a list of all supported\unsupported calls somewhere in docs
If you're too busy with implementing new cool features, and there's some manual way of checking if something is supported or not, I can try to come up with this "supported calls list".
(the thing is just so amazingly cool, because it works so smoothly most of the time, that I just want to help, but the first attempt to "just sit and dig into" your code was.. semi-successful, I'd say :) )

We usually do print a specific error when a function is not supported (i.e. that the gradient is not yet implemented), but functions that take lists as input (like stack or concatenate) are particularly troublesome in how they interact with autograd's boxed values.
The thing I said above about stack was wrong (it's already wrapped in a primitive, by the same process everything else gets wrapped, but the error still happens on the forward pass). We'll either need to special-case the error or implement stack in a way that works with autograd (possibly just copying the code of numpy.stack into numpy_wrapper.py). Hmm...

I pushed an implementation of np.stack. Reopen the issue if there's still a problem.
Glad you like autograd!

It still seems like applying autograd.numpy.abs( .. autograd node.. ) is not always equivalent to builtins.abs(.. autograd node.. ) - I just had a similar error message as above (but without any np.stacks and with recent autograd version from master); the error disappeared after I replaced abs() with anp.abs(); if there is (indeed) some "preferred" way of doing that, the other one might possibly have to raise a warning or something?

I think we might be able to overload it by adding __abs__ methods to FloatNode and ArrayNode. It may have just been an oversight not to do it.

I just pushed 22ad70b to master which should include support for the builtin abs via __abs__ methods on ArrayNode and FloatNode.


The Package System Should have a LATEST and STABLE version

Description
I like the idea of package management.
However, if I have to manually track the version of each published package this defeats the purpose, as I will have to track the versions manually and/or update all .typ files (per find/perl script).
I have up to now symlinked tablex.typ from a central location so only needed to worry about one file.
Use Case
I would propose, if not already done, to mandate that a package MUST have at least a STABLE and/or a LATEST (perhaps even a NIGHTLY) version, which could be by symlinked, perhaps, so that in the example of tablex @PgBiel could replace
#import "@preview/tablex:0.0.4": *

by
#import "@preview/tablex:STABLE": *

for example, to automate this.

I strongly agree with this, but I also know that there are strong opinions from the other camp as well. The motivation is that documents should be reproducible.
Personally I'd rather have the convenience and accept the risk.
My idea for a less verbose way of ensuring reproducible documents is to set a date in the document, and packages will then use the version that was current at that date.

I think both (Latest & Greatest AND Numbered Version) are achievable and
there are real life scenarios for both.

Personally, I mostly prefer the safety of having reproducible documents. But I understand that it could be nice to easily have common versions for multiple files in a project. In that sense, however, maybe a better approach could be to use a re-exports file, like some Rust crates do? Not sure here.

We have use cases for both ways (reproducible and latest versions). It would be nice to not only have it both ways, but to be able to "freeze" a version automatically in the release pipeline. "Freezing" means, the current version gets fixed for the document during the release step.

I think good editor support for autocompleting the latest version is better. If we support "latest" or "stable", then people will just use it all the time and we'll get lots of breakage down the road.

I don't understand the first sentence.
And about the second, so what?

I don't understand the first sentence.

I mean that if use the web app or have a language server installed, the package list will be autocompleted for you. This makes it easy to use the most recent version.

And about the second, so what?

Breakage is generally something we should avoid. Sometimes it's good to be forced to do something the right way rather than the easy way. Down the road someone will be happy that their document still compiles.

Oh, ok, additional complication, I have googled
https://lsp.sublimetext.io/language_servers/#typst but this is not
trivial (and should therefor not be assumed).
While I agree that breakage should be avoided, it makes the command line
tool much more cumbersome to work with.
If a package has an issue (such as tablex at the moment), any fix bumps
the version number and now one has to find all typst files that
reference that package and change the version number.  With a large
number of files this can be come quite frustrating, especially for the
casual command line user, who has limited regex knowledge.

I agree that it's not ideal if you have to fix it in multiple files. You can put all your imports in a helper file and import that, but I acknowledge that this is a bit of a workaround. I could imagine allowing a typst.toml file for project configuration (think also root, exports, etc. which could be configured there) which allows to specify a project-wide default version for a package. But that could also be a bad idea in the end.

Unfortunately the import file must reside below the document root so
while very helpful for individual projects it would still require a
find/perl/regex or you must pay real attention of symlinking it from
one central location.  That also works, but is complicated.
My perspective is that in addition to being powerful and fast, typst
should also be easy to use for large(er) scale document production, such
as in law offices or medical practices, where GDPR/HIPAA "forbid"
storage of documents in the cloud.  Secretaries usually balk at LaTeX
and LyX, while easier, is even slower.

Sometimes one wants to fix the package version.
But, as a "normal user", most if the time I don't care. If I install some package/library, with pip in python, with cabal in Haskell, with Pkg.jl in Julia,  I don't provide a version number and expect the ecosystem to deliver a sensible default (such as, the latest stable release).
Of course it is good that we can add the version number for fully reproducible documents.

With pip, I frequently run into problems specifically because of this. Old projects don't work anymore because the dependencies aren't accurately specified.
With editor support or the TOML file and a CLI command, you can have a similar workflow to pip, which specifies the most current in the project TOML file, while still having fully reproducible results.

I know this issue is a little stale, but I think having the TOML file + CLI command is the best solution. It sounds like what Rust currently does if I'm not mistaken.
It meets many needs:

If you want a specific version, you just put it in the TOML file.
If you just want the latest version, the CLI command can take the package name, find the latest stable version, and add that to the TOML file, just like cargo add does.
In any .typ files, you only need to specify the package name, not the version.
The versions are still pinned, so documents are reproducible.

Also, packages & templates already have a typst.toml file. Parsing this file is already implemented in Typst, so all that would be required is adding logic for a new dependency section.
I think this should be optional, though, and package versions should still be able to be specified in the #import statement. This would keep Typst simple, as single-file documents would still be possible. The main problem with requiring pinned versions was within multi-file projects anyways; adding a TOML file in that case isn't as big of a deal if the project is already complex.

The current plans are pretty much what @kdkasad describes above. A typst.toml file would give a convenient way to deduplicate versions across files and could also go hand in hand with allowing git imports in a safe way.
There are no plans to support downloading always the latest versions at the moment, for the reproducibility reasons laid out above, so I'll go ahead and close this.


OpenJDK11 testing

Working on collab VM

Coverage decreased (-64.4%) to 11.965% when pulling 6470293b26d5ea16706f5b3ca9c5af91105f4d12 on feature/openjdk11 into be1f537a79769f9a6e9599e7789bb2ce570a9497 on develop.


Is a query possible?

Does the Amazon Echo/Alexa allow querying of a value?  The control works great, but I am wondering if there is a way using the HA Bridge to get Alexa to respond with a value.  For example, tell me the temperature or the current dimming value?

Nope. Not to the bridge or a philips hue hub which this emulates.

Not sure if i understand your answer....
i had the same question, so its not possible the send via http respond or simular a value back to alexa which alexa will speak?  With the Siri bridge this is possible
thanks!
btw: just working with your bridge and thanks for all the good work :-)
regards Pieter

Amazon did not put that feature in for their connection to the Hue API. This is something I cannot change as it is not in the ha-bridge.

This is not related to the Hue?
Your bridge gives me a request to my server and I can respond with a value.
Or is everything based on hue api? :-)

Everything from the Amazon Echo to the ha-bridge is based on the Hue API. The API has calls that give state back and the echo actually asks for them, but the echo does not have the code to handle your request.


Tiny Dino performance?

Hi Author,
Thanks for sharing. Have you ever tried the performance of using tiny dino in the encoder part?

Is there a tiny DINOv2? I know there is a ViT-S. The performance for the smaller versions typically degrade the performance, but not to badly. The main issue is that most compute is spent on the refinement for high resolution inputs so benefit of smaller backbone goes away.


Add unitary molecule tests for dhcp_server role

Assing static ip in docker containers
Using a fake host declared in molecule.yml
Run unitary tests

In my platform the check E301  for ansible-lint is working perfectly in skip_list  and warn_list.
I dot not know why it is not working here.

In my platform the check E301  for ansible-lint is working perfectly in skip_list  and warn_list.
I dot not know why it is not working here.

ansible-lint runs at the root of the project, it won't look at roles/core/dhcp_server/.ansible-lint.
This is the same failure than in #412, with the same command. You can safely add changed_when: False.

Hello,
I just remembered that the python module python3-netaddr.noarch will be required to be able to calculate the DHCP server configuration files.
Can we add this verification here?
Normally it's the bluebanquise role molecule test that does this verification. https://github.com/bluebanquise/bluebanquise/blob/be64686abdb5dfc763691f238b38823223a8b96c/roles/core/bluebanquise/molecule/default/verify.yml#L7
It is smart to re-check here?
Regards

I just remembered that the python module python3-netaddr.noarch will be required to be able to calculate the DHCP server configuration files.
Can we add this verification here?

This module is required on the ansible controller, not the dhcp server. It is explicitly installed here for this scenario, there is no need to verify it on the ansible controller.

I just remembered that the python module python3-netaddr.noarch will be required to be able to calculate the DHCP server configuration files.
Can we add this verification here?

This module is required on the ansible controller, not the dhcp server. It is explicitly installed here for this scenario, there is no need to verify it on the ansible controller.

Great,
That's what I wanted to know,
Thanks @btravouillon

Could you also increment role version, like you did here for nfs_server:

Well, I explicitly asked him to remove it. There is no functional change in the role, only a new molecule scenario.

Could you also increment role version, like you did here for nfs_server:

Well, I explicitly asked him to remove it. There is no functional change in the role, only a new molecule scenario.

OK. Since it was incremented for the nfs_server, I was wondering. Let's keep it like this.

Could you also increment role version, like you did here for nfs_server:

Well, I explicitly asked him to remove it. There is no functional change in the role, only a new molecule scenario.

OK. Since it was incremented for the nfs_server, I was wondering. Let's keep it like this.

That's a mistake. nfs_client introduced a new variable, not nfs_server.


Test case key-EXCITED fails on 32bit Intel (ia32/i386)

Describe the bug
On Debian, the i386 (32bit Intel) architecture autobuilder fails the key-EXCITED test. Not sure whether you are interested in that on a practical level (32bit is surely dead for scientific research), but it might be an instability in the code base. Besides, quite a few tests show warnings of differing numerical results even on regular 64bit Intel.
The problem seems to be specific to i386, 32bit ARM e.g. seems to be fine.
build log: https://buildd.debian.org/status/fetch.php?pkg=mopac&arch=i386&ver=22.1.0-1&stamp=1702330784&raw=0
The error is as follows:
test 84
        Start  84: key-EXCITED

84: Test command: /usr/bin/python3 "/<<PKGBUILDDIR>>/tests/run_test.py" "/<<PKGBUILDDIR>>/tests/keywords" "/<<PKGBUILDDIR>>/obj-i686-linux-gnu/mopac" "0.01" "EXCITED.mop"
84: Working Directory: /<<PKGBUILDDIR>>/obj-i686-linux-gnu/tests/keywords
84: Test timeout computed to be: 10000000
84:
84:
84:           MOPAC Job: "EXCITED.mop" ended normally on Dec 11, 2023, at 21:39.
84:
84: Traceback (most recent call last):
84:   File "/<<PKGBUILDDIR>>/tests/run_test.py", line 33, in <module>
84:     compare_mopac_out_file(out_line, out_list, ref_line, ref_list, float(argv[3]))
84:   File "/<<PKGBUILDDIR>>/tests/compare_output.py", line 216, in compare_mopac_out_file
84:     assert len(ref_list) == len(out_list), f'ERROR: output file size mismatch, {len(ref_list)} vs. {len(out_list)}'
84:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
84: AssertionError: ERROR: output file size mismatch, 1735 vs. 245
 79/124 Test  #84: key-EXCITED ......................***Failed    0.74 sec

Diffing the reference output against the test output shows these changes:
- CYCLE:    13 TIME:   0.039 TIME LEFT:  2.00D  GRAD.:   245.805 HEAT:  99.37512
- NUMERICAL PROBLEMS IN BRACKETING LAMDA  -504148458.072983
-  -504148458072.983       -504148458.073487<PHONE_NUMBER>26.073
-   499010958.743647
+ CYCLE:    13 TIME:   0.113 TIME LEFT:  2.00D  GRAD.:   245.805 HEAT:  99.37436
+ NUMERICAL PROBLEMS IN BRACKETING LAMBDA  -504303705.34135485       -504303705341.35486       -504303705.34185916<PHONE_NUMBER>01.34131        499165490.99536222
   GOING FOR FIXED STEP SIZE....
+ TOO MANY ITERATIONS IN LAMBDA BISECT  -504641247.27416450       -504641247.27416444       -504641247.27416444       -1.0767515046766464E-020  -2.7351938644416280E-021
[...]
+          TOO MANY ITERATIONS IN LAMBDA BISECT IN EF
[...]
+ ******************************************************************************
+ *                                                                            *
+ *     Error and normal termination messages reported in this calculation     *
  *                    *
+ * TOO MANY ITERATIONS IN LAMBDA BISECT IN EF                                 *
+ * TOO MANY ITERATIONS IN LAMBDA BISECT IN EF                                 *
  * JOB ENDED NORMALLY *

To Reproduce
Run the test suite on 32bit Intel, e.g. in a 32bit-chroot on an otherwise 64bit system.
Expected behavior
Tests suite runs fine.
Operating system
Debian unstable, i386 architecture

Thank you for pointing this out, I will make adjustments to this test for future MOPAC releases. Electronic structure software such as MOPAC contain many nonlinear optimization steps, which are fundamentally going to be erratic and chaotic in some cases and produce machine-dependent results because of slight differences in rounding and optimized order of operations. Well-written tests should be avoiding such behavior, but unfortunately this test seems to be near an unstable point of a geometry optimization that fails in different cycles on different machines (12 vs. 13). This indicates a problem with the test, not MOPAC itself.
About the numerical warnings, MOPAC was not written in a "numerically tight" way that enables results to be systematically refined to near double-precision accuracy. Rather, it is a mix of tunable accuracy parameters and hard-coded choices that produce a fundamental floor to the numerical precision, which varies based on the inherent stability of each calculation. I decided that the best way to handle this with testing was to set aggressive numerical tolerances in tests that fail a lot of the time, and to have these numerical failures flag a warning rather than an error. This is the simplest practical way to monitor MOPAC's precision floor. This does not signify any growing instability in MOPAC's code base, but rather an increasing level of scrutiny. Ideally, I'd like these warnings to motivate improvements to MOPAC's numerical precision, but that would be a substantial undertaking and just isn't a high priority right now.


(maint) Update to ruby-shadow gem

Ruby no longer supports libshadow, ruby-shadow is now the supported gem for shadow password file interactions.

CLA signed by all contributors.


nevada retirements and appointments

retired Michael Sprinkle, Kelvin Atkinson
appointed Greg Smith, Marcia Washington
https://ballotpedia.org/Greg_Smith_(Nevada)
https://ballotpedia.org/Marcia_Washington

Pull Request Test Coverage Report for Build 451

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 68.487%

Totals

Change from base Build 450:
0.0%

Covered Lines:
928

Relevant Lines:
1355

💛  - Coveralls


Feature request: spr update should update all PRs to have the reviewers.

Feature request:
git spr update -r bob -r jane -r alice should update already existing PRs on the stack to include bob, jane and alice if they are not already added as reviewers.

See #145 for related discussion: it was an explicit decision to do it this way, at least initially. I think the desire was to have a separate flag if we want to update the stack.
@ejoffe is that accurate?

I think the desire was to have a separate flag if we want to update the stack.

the spr command is already called update, so it was a bit suprising when it didn't go thru and "update" all the reviews. :)


fix timeouts definition for W3C compatible drivers for WebDriverIO

Modern browsers starts to drop out old webdriver syntax.
For example Safari 12 and FF 63 does not support old syntax for timeout setting.
We should use new w3c compatible syntax in such cases
http://webdriver.io/api/protocol/timeouts.html

Thanks!

Fix for #1241


REST service

If time permits (otherwise we can use the Java version)

Re-created this issue in dd4t-2-net


[Maestro 1.30.4] - Tests run and succeed but do not see changes execute on simulator

Describe the bug
I'm not sure if this is a bug or not, but while using Maesetro, at first I was seeing the steps of an e2e test enacted on the simulator; for example, - inputText: "myusername"would actually do that live on the simulator.
I'm not sure what happened, but now my tests still continue to work, but I don't see results on the simulator. When I try breaking the tests, they do indeed break.
To Reproduce
This was both happening on a private app I was working on, and when I tried downloading the sample wikipedia app and running it's tests. While the wikipedia app booted, when I tried adding a new step in the flow, like so:
appId: org.wikimedia.wikipedia
---
- launchApp
- tapOn: "Next"

It appeared to succeed when running maestro test ios-flow.yaml. However, the actual result of clicking "Next" on the simulator didn't seem to happen.
Screenshots
Below is a quick video in which the above described test succeeds, but the simulator does not represent the change orchestrated by the test.
https://github.com/mobile-dev-inc/maestro/assets/12987958/d60c6758-f1a3-4a43-82a1-1f0989b5f827
Environment information (please complete the following information):

Maestro version [e.g. v1.30.4]
Platform: [e.g. iOS 16.4.1, Android 11.0, Chrome]
Framework: Testing on a native .app example.
Device model and OS version: iPad Pro (11-inch) 4th generation - iOS 16.4
Simulator
Host: Intel Mac

Thanks for any input you can provide! I'm hoping I'm missing something simple that can re-enable the simulator not actually showing changes.

Has there been any updates in the meantime?
I am experiencing the same issue with current versions of maestro and iOS.
There seems to be a difference between using an iPhone and an iPad simulator.
Everything works fine on a simulated iPhone 15 (iOS 17.5), but the above described issue happens on a iPad (10th generation, iOS 17.5).
Any information would be greatly appreciated.
With this bug the tool is not usable for our project, unfortunately.
Environment information (please complete the following information):
Maestro version [e.g. v1.36.0]
Framework: Testing on a native .app example.
Device model and OS version: iPad (10th generation) - iOS 17.5
Host: Mac M3


Please support different decimal separator for toString() methods

Please support locale-specific numbers presentation using additional options

New branch with new toString(decimalMark) and similar function is pushed to the https://github.com/epam/DFP/tree/issue83-toString-custom-separator
The differences: https://github.com/epam/DFP/pull/86
Lets discuss these changes.


Update to net6

.net6 is the current LTS version, supported until November 2024.
https://dotnet.microsoft.com/en-us/download/dotnet
My goal is to get doctest-csharp updated to net6 (so I can use it
without installing .net3.1 runtime). To do that and keep the CI
builds running successfully, this project (dead-csharp) and
bite-sized-csharp (which uses dead-csharp) need to be updated.

@natehitze thanks! I'll release a major version now.

@natehitze The new major version should be on-line.


Can't run callback on receipt of local notification

This seems like a regression introduced by adding support for handling different user actions on notifications. I just need to run some badge update logic in the background when a notification is received—but I can only run said logic when a user interacts with the notification. Using an eventListener for localNotification. Is there something I'm missing?
Thanks—

any update for this?


SetExistingRowsTo with SystemMethods produces incorrect sql script

I'he found that SetExistingRowsTo with SystemMethods produces incorrect UPDATE script.
Here is example migration
Alter.Table("Table").InSchema("dbo") .AddColumn("EditDate").AsDateTime().NotNullable().WithDefault(SystemMethods.CurrentUTCDateTime).SetExistingRowsTo(SystemMethods.CurrentUTCDateTime);
and result script
UPDATE [dbo].[Table] SET [EditDate] = 'CurrentUTCDateTime' WHERE 1 = 1

Currently it doesn't support system methods, only fixed values, as under the hood it uses the same flow as the Update expression, eg,
Update.Table("Table")
    .Set(new { EditDate = DateTime.Today })
    .AllRows()

In your case you can probably use
Alter.Table("Table").InSchema("dbo")
.AddColumn("EditDate").AsDateTime().NotNullable().WithDefault(SystemMethods.CurrentUTCDateTime)
.SetExistingRowsTo(Datetime.UtcNow);

If you really wanted to use the SystemMethods when populating existing rows, I think you would have to implement them in the UpdateDataExpression.


Document prefix and glob matching

Looking for ways to handle different path combinations I came across with the glob feature through the GitHub issues. It'd be amazing to add some documentation around this and some examples about when it's convenient to use either.
Some benchmarks results would be nice as well

Feel free to send a PR for the docs

Will try if I find the time.


Sorry, you have been blocked by OpenAI

运行新版的docker容器哦时，报这个错误Sorry, you have been blocked by OpenAI
请问是什么问题，VPS是美服

简单来说


load from amazon s3 failed

I am trying to load a bedpe format file from amazon s3 bucket. the file has public permission. Unfortunately it is not working. and I see no error. I am able to load the file from local desktop but that disables the sharing of IGV web link.
https://igv.org/app/
Could you please help me with what could be the possible sources for no upload?

You probably need to add CORS support to your buckets.    See https://github.com/igvteam/igv.js/wiki/Data-Server-Requirements#cross-origin-resource-sharing-cors

You probably need to add CORS support to your buckets.    See https://github.com/igvteam/igv.js/wiki/Data-Server-Requirements#cross-origin-resource-sharing-cors

BTW Dropbox works with no configuration required.

BTW Dropbox works with no configuration required.

Thanks. it works with dropbox :)

Thanks. it works with dropbox :)

One caution about dropbox, if you remove any file you reference it the share links will be broken.   This seems obvious, but even if you replace the file with the exact name in the exact folder the share links will still be broken.   That's because the actual link to the file is a unique hash, the filename itself isn't really used.    This is how dropbox URLs work.   S3 urls do not have this problem, but they do require CORS setup.

One caution about dropbox, if you remove any file you reference it the share links will be broken.   This seems obvious, but even if you replace the file with the exact name in the exact folder the share links will still be broken.   That's because the actual link to the file is a unique hash, the filename itself isn't really used.    This is how dropbox URLs work.   S3 urls do not have this problem, but they do require CORS setup.


All markets to be reported on show Share Volume of 0.0

There were 75 markets to be reported on in my console, and in the spirit of the beta, I figured I'd give it a shot, but my patience quickly ran out after 7 or 8.  So I thought I'd at least report on any that had shares on the line.  But every single one showed a Volume of 0.0 shares.  Could that be true?  Also, I'd hate to think that any of our actual REP will be at stake for null markets :-)

Old UI issue.


requirements.txt: Pin crypto package

Pinned cryptography package to 2.1.4 series to solve
pyopenssl build fail
Reviewers Checklist

[ ] Appropriate logging is done.
[ ] Appropriate error responses.
[ ] Handle every possible exception.
[ ] Make sure there is a docstring in the command functions. Hint: Lookout for
botcmd and re_botcmd decorators.
[ ] See that 100% coverage is there.
[ ] See to it that mocking is not done where it is not necessary.

DO NOT MERGE!

proper problem found c.w. https://gitlab.com/gitmate/open-source/IGitt/blob/master/requirements.txt


moved flat object from changed to added b/c it's new

Description
moves flat object from the changed to added section. didn't think this was notable enough for CHANGELOG.
Issues Resolved
N/A
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[  x ] Commits are signed per the DCO using --signoff
[  ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #7322 (712be40) into main (b752555) will decrease coverage by 0.21%.
The diff coverage is n/a.

:exclamation: Current head 712be40 differs from pull request most recent head f8af1f4. Consider uploading reports for the commit f8af1f4 to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##               main    #7322      +/-   ##
============================================
- Coverage     70.71%   70.51%   -0.21%
+ Complexity    59516    59430      -86
============================================
  Files          4859     4859
  Lines        285369   285369
  Branches      41134    41134
============================================
- Hits         201801   201216     -585
- Misses        66956    67623     +667
+ Partials      16612    16530      -82

see 486 files with indirect coverage changes


Engine CLI Improvements

Engine CLI improvements

Closed the pull request for now as I'm working on fixing some issues that I encounterd

@dumconstantin updated the default template so it is in sync with the current documentation.


could you help me to port the code to Google Drive?

I dont have deep skills in software, could you explain me how to port this code for use google drive? wich files are necesary to change

Thanks for your interest in this repo. This repo is specifically developed for OneDrive. If you want to make it compatible with Google Drive as well, it would require significant code modifications. However, you can refer to a similar repo @alx-xlx/goindex which is specifically developed for Google Drive.

I test It, but the OneDrive Vercel Index have an impressive UX design.

I haven't used Google Drive yet. After I complete this repo, I will study Google Drive's API and authentication process.


Make DGI easy to extend by moving corruption logic to Generator classes

This adds 2 non-abstract (defaulted) methods to the Generator base class from #1194:

corrupt_inputs: takes in a list of model input values (tensors/numpy arrays etc.) created by a flow'd sequence and returns some corruption of them for DGI
corruptible_input_indices: the input tensor locations that get corrupted by corrupt_inputs and so need duplicated input tensors

Notably, the model classes don't have to know anything about corruption or DGI, it's purely a generator/sequence-level concern. Any model that uses that generator with corruption support can thus be trained in an unsupervised fashion. For instance, new models using FullBatchNodeGenerator will automatically be able to be trained with DGI.
Things to think about before merging this PR:

reproducibility: maybe corrupt_inputs should take a random state?
passing base_generator vs. the corrupted generator into DeepGraphInfomax
how does this work with tf.data-based generators?
maybe instead of defaulted methods on Generator we should add a subclass:class CorruptibleGenerator(Generator):
    @abc.abstractmethod
    def corrupt_inputs(self, ...): ...
    @abc.abstractmethod
    def corruptible_input_indices(self): ...

and then checks for "corruption support" are isinstance(generator, CorruptibleGenerator).
adding docs

This builds off #1194.

this corruptable generator approach is awesome!

I reckon for tf.data.Datasets we can do something like:
CorruptedGenerator(...):
    def __init__(self, base_gen):
        ...
    def flow(....):
        base_flow = self.base_gen.flow(...)
        if isinstance(base_flow, Dataset):
            return base_flow.map(shuffle_func)

with shuffle_func maybe stored in base_gen?

I reckon for tf.data.Datasets we can do something like:

Ah good idea. Since the generator knows that it's returning a Dataset from its own flow, I think shuffle_func could just be corrupt_inputs as per Sequences: return base_flow.map(self.base_gen.corrupt_inputs)?

Slightly prompted by https://github.com/stellargraph/stellargraph/pull/1193#discussion_r402048330 and by pondering this for the last few hours, I'm not quite happy with the code here. I feel like this corruption logic isn't a fixed behaviour of each generator, but actually a separate set of possibilities associated with each one. For instance, one could have a full-batch node generator corrupter that manipulates the adjacency in addition to the node features.
So maybe a better API is something like:
class DGICorrupter(abc.ABC):
    @abc.abstractmethod
    def corruptible_input_indices(self): ...
    @abc.abstractmethod
    def corrupt_inputs(self, inputs): ...

class CorruptedGenerator(Generator):
    def __init__(self, base_generator, corrupter: DGICorrupter):
        ...

so that a user can slot in any corrupter.
The library might provide corrupters like
class FullBatchNodeGeneratorFeaturesShuffler(DGICorrupter):
    def corruptible_input_indices(self):
        return [0]
    def corrupt_inputs(self, inputs):
        # ... shuffling code ...

class FullBatchNodeGeneratorFeaturesAdjacencyShuffler(DGICorrupter):
    def corruptible_input_indices(self):
        return [0, 2]
    def corrupt_inputs(self, inputs):
        # ... shuffling code ...

that can be used like:
CorruptedGenerator(base_generator, FullBatchNodeGeneratorFeaturesShuffler())

That's a bit verbose, but I think there's a few ways we could improve it:

consider avoiding duplicating the input tensors (so that we don't need corruptible_input_indices and thus can just pass in the corrupt_inputs functions directly, no need to have corruptible_input_indices) (discussion on Slack)
have a default_corrupter() method on Generator, and def __init__(self, base_generator, corrupter = None):, so the default_corrupter method is called is used if corrupter is None
have the builtin corrupters available on the generator type, like CorruptedGenerator(generator, generator.shuffle_features) and CorruptedGenerator(generator, generator.shuffle_features_and_adjancency) for full batch methods (or whatever, for which ever styles we support)

Notes to self: I think we can cover full batch corruption, graphsage and HinSAGE with a type like
class ShuffleTensors:
    def __init__(self, which_tensors):
        ...

where which_tensors is an sequence of sequences of integers, where the integers are indices into the input tensor array, the inner sequence represents sets tensors that are all shuffled together (e.g. (0, 1) means that corrupted[0] and corrupted[1] are sampled from the union of input[0] and input[1]), and the outer sequence represents groups of those sets.

I should summarise this discussion

Ideas for possible alternates ways to write this were:

stacking the inputs like normal, normal, ... normal, corrupted, corrupted, ... corrupted with targets like [1, 1, ... 1, 0, 0, ... 0] (i.e. double the batch size of the underlying generator)

this would allow having a non-equal 1 and 0 samples (e.g. for #1134, the InfoGraph paper suggests using more than 1 negative samples per positive sample)
we'd need to pass down the mask to the DGI layer, so that it could work out which values were positive to use for the summary input to the discriminator

having alternating batches of normal, normal, ..., normal, targets 1, 1, ..., 1, and corrupted, corrupted, ... corrupted, targets 0, 0, ..., 0 (i.e. double the number of batches of the underlying generator)

doesn't work because the discriminator for each batch needs to have the normal ones to compare against

We also brainstormed a bit about generalising DGI to work with more complicated models (e.g. a dense layer on top of a GCN model, or a completely custom set of a layers)

pass input layers/tensors to a __call__ method, so that it can duplicate them as appropriate
do something similar to APPNP.propagate_model, where DGI takes the whole Keras model and manipulates that (although that's maybe somewhat fragile, e.g. #1213?)

The approach above is different enough to this PR that it was easier to start from scratch; so I've moved it to #1243 (and #1247).


[Feature Request] Bitcoin RPC Proxy

The https://github.com/Kixunil/btc-rpc-proxy allows for finer-grained permission management for bitcoind.
It would also enable pruning for bitcoind, without abandoning applications that rely on non-pruned nodes like LND or BTCPay Server.

Fine grained permissions yes, but simulating an unpruned node does not work (yet).
See the discussion at https://github.com/cryptoadvance/specter-desktop/issues/722


Fixed a few typos

Not a huge PR, just fixed a few things I noticed in the readme

Even if it's not the generally accepted spelling of the common word, the Nix term is spelled "substituter", and our docs will match that. It looks like I accidentally used "substitutor" once though, so I'll fix that. Thank you for pointing out the "masive" typo though.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/74895

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/80675

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/86177

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.


highlight incidents with failed 3rdparty delivery status in incident view

so that users don't have to click into the detailed message view to check the twilio delivery status.
bonus point: have a per incident stats summary including success rate and some other interesting data.

I like this idea. :D


[assimp] Update to 5.3.0

https://github.com/assimp/assimp/releases/tag/v5.3.0
https://github.com/assimp/assimp/compare/v5.2.5...v5.3.0
Note:
https://github.com/assimp/assimp/issues/788 is finally resolved, allowing us to remove vendored polyclipping
https://github.com/assimp/assimp/issues/5247 forces us to add public dependency for utfcpp

qt5-3d:x64-windows-static
qt5-3d:x64-windows-static-md
qt5-3d:x64-linux
qt5-3d:x64-osx

Failed with below error:
ERROR: Feature 'system-assimp' was enabled, but the pre-condition 'features.assimp && libs.assimp' failed.
Error logs: https://dev.azure.com/vcpkg/public/_build/results?buildId=94455&view=artifacts&pathAsName=false&type=publishedArtifacts

There is a request #34061 to update to 5.3.1. Are you willing to update to the latest version directly?

Yeah why not


doesn't seem to be working

unsure exactly why its just not overriding the lasers

oh im just very cool and smart lol


Fix Windows start scripts to have a valid classpath

I was helping some Windows users deal with failures of Conjure tasks on their machines, which led me here.
The lib\ folder being passed in here is a folder containing jars in a flat structure. The format for adding such a folder to the classpath is lib\*, not lib\, which denotes a folder containing a nested directory structure with .class files.

clabot?

:+1:

:+1:

Released 1.0.1


Crash on startup with Better Mount HUD

Mod Name
Better Mount HUD
Mod Homepage
https://modrinth.com/mod/better-mount-hud
Minecraft version
1.21.1
Describe the bug
Critical error on startup
Steps to reproduce

Install Connector, Forgified Fabric API, and Better Mount HUD
Launch the game
Game crashes during startup
...

Logs
https://gist.github.com/DJChaos42/871bd882826b225cf6dda71cdf7d8d9e
Additional context
Launcher: Prism Launcher 8.4.0
Minecraft Version: 1.21.1
NeoForge Version: 21.1.42
Mods installed:

Connector 2.0.0-beta.2+1.21.1
Forgified Fabric API 0.102.0+2.0.12+1.21.1
Better Mount HUD 1.2.4

There is a similar mod that is available for Forge by default:
https://modrinth.com/mod/leave-my-bars-alone

I have had an issue opened on my mod stfu with a similar feature. It seems to also be affected by this issue and crashes instantly when using connector (FFAPI is not required).
Here is the code triggering it, just removing its reference in the mixin config file fixes it.


fix(prop-types): use PropTypes.element instead of Element

Our prop types fix was using Element instead of PropTypes.element causing our gatsby build to fail. This PR fixes that issue by using PropTypes.element.

Coverage decreased (-0.07%) to 88.173% when pulling fe1b1f304344b1fa9ab780733387428edc7cff96 on astankiewicz/fix-element-prop-type into 63a55ce7630bbf2d60651db690f415dfb8d4b22f on master.

Coverage decreased (-0.07%) to 88.173% when pulling fe1b1f304344b1fa9ab780733387428edc7cff96 on astankiewicz/fix-element-prop-type into 63a55ce7630bbf2d60651db690f415dfb8d4b22f on master.

:tada: This PR is included in version 6.2.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Issue with Library on Android Web - Introstep Highlighting and Background Darkening Not Working

Hi,
I am encountering an issue when using the library on Android Web. When running the application on a web browser on an Android phone, the introstep feature does not work as expected. The element is not highlighted, and the background is not darkened, making the text unreadable. Interestingly, the issue seems to be specific to Android devices, as it works flawlessly on other platforms. Screenshots from an iPhone 12 Pro show the correct behavior, while those from a Pixel 6 do not.

This is an issue with Flutter; their support for the Web platform is not yet fully developed.


[BUG] Missing StartWithHttpMessagesAsync in released ContainerInstance package

Describe the bug
The IContainerGroupsOperations in the published nuget package (2.0.0) doesn't have StartWithHttpMessagesAsync
Expected behavior
All the available operations should be present
Setup (please complete the following information):

OS: Windows 10
IDE : Visual Studio 2019
nuget 2.0.0

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[ x ] Bug Description Added
[ n/a ] Repro Steps Added
[ x ] Setup information Added

Thank you for opening this issue! We are routing it to the appropriate team for follow up.
@shahabhijeet, can you kindly take a look at this?

If you look at the rest api definition there is a start container api but the library does not reference it. I think it's a simple case of just regenerating this library against the complete api definition. (From memory as it was a few weeks ago I raised this)

@samkreter,  please regenerate source code from swagger spec for containerinstance since StartWithHttpMessagesAsync was missed in nuget package 2.0.0? The process is available at https://github.com/Azure/adx-documentation-pr/blob/master/engineering/adx_netsdk_process.md#sdk-generation-from-updated-spec

@samkreter, any update?

I am currently running into this issue and thought maybe I could follow the process myself, since it does not seem complicated. Unfortunately it appears that the link is either dead or I do not have access.
@erich-wang is there a public url where I can see the process so that I may submit a pull request?

Close the issue as new package was released two months ago at https://www.nuget.org/packages/Microsoft.Azure.Management.ContainerInstance/3.0.0.


how to pass output parameter to ms-sql stored procedure using knex.

Environment
Knex version: 0.15.0
Database + version: MS-SQL
OS: Windows
Feature discussion / request

Explain what is your use case
we are using Knex in node js to call MS-SQL raw query and stored procedure. In MS-SQL, we can pass both IN and OUTPUT parameter in stored procedure. Now, i am stuck, how to pass output parameter to ms-sql stored procedure.
Procedure parameter is like this :
GetEmployeeCount (@totalEmployee BIT OUTPUT);

Missing / erroneus documentation
Send issue to documentation repo, or fix it and send PR https://github.com/knex/documentation
Questions about how to use knex
Github issues are for knex development. Please send questions how to use knex to
stackoverflow or ask about it in gitter chat.

How does mssql driver support that? For oracle there was certain object syntax that must be passed to bindings to tell the driver that it is an output parameter.

like this =>
const knex = knexInstance({
client: 'mssql',
connection: {
host: environment_1.Database.host,
user: environment_1.Database.username,
password: environment_1.Database.password,
database: environment_1.Database.dbName,
options: {
encrypt: true
}
}
});

I agree, calling stored procedures with both input and output parameters would be quite a basic feature needed.

@pate313373 would you like provide PR for this needed basic feature.

Basically, the example at tedious should be more than sufficient to implement a StoredProcedure class for knex.
Unfortunately, I have 3 projects with thight deadlines at the moment, so I'm using knex and the npm package mssql natively at the same time. - However, I really don't like this workaround.
Would you consider it, if it supports MSSQL only? Because if I add this feature, most likely only for MSSQL.

@pate313373 As long as API is DB-agnostic and could potentially be implemented for other databases (which should throw an error for now), that would be an option.

@pate313373 How do you add the example you'd mentioned above as a class to an existing knex instance?

@pate313373 How do you add the example you'd mentioned above as a class to an existing knex instance?

I did not use the existing knex instance, I rather connected to the DB in parallel with tedious.


[MM-59066] server/job: prevent deletion of non-finished jobs

Summary
An issue has been pointed out that if a “Remove All” request is being made during a job is running will led to a case that plugin to delete entire data directory. So, the logic was deleting the directory of the dump. But the problem is, if a job receives a request to be deleted, and it doesn’t have a dump directory (which would be set after the job finishes), it will have an empty value. And if the empty value is given to filestore, the entire data directory will be deleted.
Ticket Link
https://mattermost.atlassian.net/browse/MM-59066

Heads up @isacikgoz I don't have permission to modify labels in this repo. I cannot remove the QA Review label.


ESLint config correction and test.

Fixes the pass of eslint config to CLIEngine. Add test to eslint options. Fixes the test of strip comment utility.
Please, pull this pull request to es-analysis/plato.
Thank you.

@conradoqg The test "Should contain total eslint issues" is not passing here


Fail quickly on Windows

xgboost-ray training currently does not work on Windows. This is because we use multiprocessing in the Rabit Tracker, but the run method is not serializable, so we have to use fork method instead of spawn. (see #42).
However, Python multiprocessing does not support fork method on Windows.
This PR immediately raises an error if Windows OS is identified with a better error message.
See #208

@Yard1 @krfricke is CI supposed to be passing? Not sure what's going on here since the change should be unrelated.

@amogkam It's a bit flaky atm. The CI looks good, let me merge.


singularity build cancelled due to unavailable arch (amd64)

While using
singularity build --remote apex.sif apex.def
following error occurs:
build (61e87324257059d3222630cc) cancelled due to unavailable arch (amd64)
FATAL:   While performing build: build image size <= 0

This error happened to all but one def file, whose content is merely:
Bootstrap: docker
From: gaow/base-notebook

which ran successfully

After the completion of the building of aforementioned def. and running
qlogin -q csg.q   + logout of the computational node.
The error disappeared.
This is a log for what happened in case this error popup again.

Thanks @hsun3163 I suggest against using remote build anyways. I changed instruction on container/singularity/README.md

Thanks @hsun3163 I suggest against using remote build anyways. I changed instruction on container/singularity/README.md

This problem happened again. None of what I done earlier can fix it (as expected). Will talk to the syslab ppl on slack later regarding this issue.

The syslab ppl said they fix the problem, will update when new problem arise


Workspace releases with [patch] need different ordering

Hey, I'm using workspaces with top level patch definitions. cargo release attempts to build and release each crate one at a time, however, as the first crate version gets bumped the publish fails as the build executes across the workspace without updating the lockfile.
I believe the correct approach here would be to apply the version bump to all crates, then to run cargo update to update the workspace lockfile, then to build/publish all crates. I can look into making this change, but, is this something you'd be interested in supporting?

cargo release should be updating the lock file after each version bump.  See https://github.com/sunng87/cargo-release/blob/master/src/main.rs#L589
So I suspect the root cause is something else and that bumping all crates first won't help (I vaguely remember it might actually break things but I could be wrong).  Do you have a repo we can reproduce on?

I think we're having the same problem with embedded-graphics. There's a repo here if you need to test stuff: https://github.com/embedded-graphics/embedded-graphics/tree/906ee1180cf31872b03aee037b9022c5fde30630
We have 4 crates: embedded-graphics, embedded-graphics-simulator, tinytga, tinybmp. The [patch.crates-io] section in the workspace Cargo.toml looks like this:
[patch.crates-io]
embedded-graphics = { path = "embedded-graphics" }
embedded-graphics-simulator = { path = "simulator" }
tinytga = { path = "tinytga" }
tinybmp = { path = "tinybmp" }

Dependencies look roughly like this:

embedded-graphics (dev) -> tinytga
embedded-graphics-simulator -> embedded-graphics
embedded-graphics-simulator (dev) -> tinybmp
tinybmp -> embedded-graphics
tinytga -> embedded-graphics

We're currently splitting repos apart, so there'll be no more workspace soon after the commit the above link is pinned to, but in its current state it may help with debugging.

I think this is a duplicate of #82, closing in favor of that.  If it isn't feel free to say how this is different


Centralized copy / multi-language files

Can we add centralized solution for copy not hard code it into components? lang.json and also consider multi language approach + react static integration,

https://github.com/yahoo/react-intl

🤔 https://angular.io/guide/i18n

https://github.com/tryggvigy/pseudo-localization

react-i18next is meant to work with Context API but we still use redux. I guess we need to either research react+redux i18n solution or do a custom implementation

here's a working prototype with react-i18next with redux https://github.com/Jam3/nyg-jam3/tree/feature/central-copy-localization


Generate new CRD: EffectiveSchedule

Summary
WIP
As discussed in #214 , step 1 for Deduplication

Checklist

[ ] Keep pull requests small so they can be easily reviewed.
[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking,
as they show up in the changelog
[ ] Update the documentation.
[ ] Update tests.
[ ] Link this PR to related issues.

RFC first round

RFC first round

I did not have a k8up-system NS, but applied the new sample schedule:
kubectl apply -f config/samples/k8up_v1alpha1_schedule.yaml

https://gist.github.com/cimnine/4ff4f16ee715d44020b96c984062caca
a) IMO, this must not lead to a panic
b) I believe that k8up must check when it starts whether there is the k8up-system namespace (or whatever is configured) and if that namespace does not exist, it should exit(1) immediately.
An alternative may be that k8up (optionally, but by default) tries to create it's namespace.

Hmm, right.
I agree on the Panic, that should be catched.
Yes, the default is hardcoded k8up-system atm. But maybe it's better to leave it internally empty, and require the admin to explicitly set it? Then we can exit early if the setting is empty. In case of the Helm chart and Kustomize, we can set a default. However, checking whether the namespace exists at startup doesn't cover the case where the namespace can be deleted after the startup, so stuff may still break.

the default is hardcoded k8up-system atm

I wouldn't make this hard-coded, should be configurable. In the Helm Chart we can make use of the Downward API to make it "automatically" to be the same namespace as K8up is installed in to.

I wouldn't make this hard-coded, should be configurable.

It's the default that is hardcoded. The value itself is already configurable.

Latest PoC looks promising:
k get effectiveschedules -n k8up-system
NAME                      SCHEDULE NAMESPACE   SCHEDULE NAME   GENERATED SCHEDULE   JOB TYPE   AGE
backup-n27qhnqkcgstt49c   default              schedule-test   4 * * * *            backup     2m41s
check-llj8p6x4z7ssh4p6    default              schedule-test   44 * * * *           check      2m41s

@tobru wanna review docs?

Thanks for the pair review @cimnine
I'll start organizing the commits now

@cimnine want to approve?
I noticed that the coverage tool does not count the coverage done with integration tests. that's probably also the reason why this PR's diff is so low.
$ make integration-test
...
kubebuilder/bin/
kubebuilder/bin/etcd
kubebuilder/bin/kube-apiserver
kubebuilder/bin/kubectl
setting up env vars
?   	github.com/vshn/k8up	[no test files]
?   	github.com/vshn/k8up/api/v1alpha1	[no test files]
ok  	github.com/vshn/k8up/cfg	0.027s	coverage: 23.3% of statements
ok  	github.com/vshn/k8up/controllers	15.596s	coverage: 27.1% of statements
ok  	github.com/vshn/k8up/executor	0.017s	coverage: 13.8% of statements
ok  	github.com/vshn/k8up/handler	0.028s	coverage: 14.1% of statements
?   	github.com/vshn/k8up/job	[no test files]
ok  	github.com/vshn/k8up/observer	0.042s	coverage: 52.6% of statements
ok  	github.com/vshn/k8up/prebackup	0.028s	coverage: 3.8% of statements
ok  	github.com/vshn/k8up/queue	0.016s	coverage: 87.5% of statements
ok  	github.com/vshn/k8up/scheduler	0.013s	coverage: 55.2% of statements

$ make test
go fmt ./...
go vet ./...
go test ./... -coverprofile cover.out
?   	github.com/vshn/k8up	[no test files]
?   	github.com/vshn/k8up/api/v1alpha1	[no test files]
ok  	github.com/vshn/k8up/cfg	0.039s	coverage: 23.3% of statements
ok  	github.com/vshn/k8up/controllers	0.028s	coverage: 6.8% of statements
ok  	github.com/vshn/k8up/executor	0.012s	coverage: 13.8% of statements
ok  	github.com/vshn/k8up/handler	0.014s	coverage: 14.1% of statements
?   	github.com/vshn/k8up/job	[no test files]
ok  	github.com/vshn/k8up/observer	0.016s	coverage: 52.6% of statements
ok  	github.com/vshn/k8up/prebackup	0.023s	coverage: 3.8% of statements
ok  	github.com/vshn/k8up/queue	0.046s	coverage: 87.5% of statements
ok  	github.com/vshn/k8up/scheduler	0.018s	coverage: 55.2% of statements

When doing tests with Goland + coverage, the total test coverage should increase from 17% to 31%
Lemme investigate a bit and make a new PR

I noticed that the coverage tool does not count the coverage done with integration tests

false alarm. I didn't notice the diff in the controllers package


Do not upscale/overize in filter_image_downsize

Timmy apparently lacks the checks about whether cropping/resizing would actually reduce (contrary to increase) an image during the image_downsize filter (Since neither filter_image_downsize nor resize() contain the oversize guards which only live inside get_image_params()).
That's one such trace I grabbed:
  25 =>
  array (
    'function' => 'post_get_meta_field',
    'type' => 'dynamic',
    'class' => 'Timber\\Integrations\\ACF',
    'file' => '/web/wp/wp-includes/class-wp-hook.php',
    'line' => 289,
    'params' =>
    array (
      'value' => '\'27721\'',
      'post_id' => '27716',
      'field_name' => '\'headerImageMobile\'',
    ),
  ),
  26 =>
  array (
    'function' => 'get_field',
    'file' => '/web/app/plugins/timber-library/lib/Integrations/ACF.php',
    'line' => 30,
    'params' =>
    array (
      'selector' => '\'headerImageMobile\'',
      'post_id' => '27716',
      'format_value' => '???',
    ),
  ),
[.... .... ...]
  33 =>
  array (
    'function' => 'format_value',
    'type' => 'dynamic',
    'class' => 'acf_field_image',
    'file' => 'web/wp/wp-includes/class-wp-hook.php',
    'line' => 287,
    'params' =>
    array (
      'value' => '\'27721\'',
      'post_id' => '27716',
      'field' => '[\'ID\' => 0, \'key\' => \'field_5f7ddcfa8c43d\', \'label\' => \'Header Image Mobile\', \'name\' => \'headerImageMobile\', \'prefix\' => \'acf\', \'type\' => \'image\', \'value\' => NULL, \'menu
_order\' => 1, \'instructions\' => \'com)\'
, \'required\' => 0, \'id\' => \'\', \'class\' => \'\', \'conditional_logic\' => 0, \'parent\' => \'group_5ba3c42472043\', \'wrapper\' => [\'width\' => \'\', \'class\' => \'\', \'id\' => \'\'], \'return_format\'
=> \'array\', \'preview_size\' => \'thumbnail\', \'library\' => \'all\', \'min_width\' => 1666, \'min_height\' => 3000, \'min_size\' => \'\', \'max_width\' => 1666, \'max_height\' => 3000, \'max_size\' => \'\', \
'mime_types\' => \'jpg,jpeg\', \'_name\' => \'headerImageMobile\', \'_valid\' => 1]',
    ),
  ),
  34 =>
  array (
    'function' => 'acf_get_attachment',
    'file' => 'web/app/plugins/advanced-custom-fields-pro/includes/fields/class-acf-field-image.php',
    'line' => 337,
    'params' =>
    array (
      'attachment' => '27721',
    ),
  ),
  35 =>
  array (
    'function' => 'wp_get_attachment_image_src',
    'file' => 'web/app/plugins/advanced-custom-fields-pro/includes/api/api-helpers.php',
    'line' => 3189,
    'params' =>
    array (
      'attachment_id' => '27721',
      'size' => '\'content-default\'',
      'icon' => '???',
    ),
  ),
  36 =>
  array (
    'function' => 'image_downsize',
    'file' => 'web/wp/wp-includes/media.php',
    'line' => 953,
    'params' =>
    array (
      'id' => '27721',
      'size' => '\'content-default\'',
    ),
  ),
  37 =>
  array (
    'function' => 'apply_filters',
    'file' => 'web/wp/wp-includes/media.php',
    'line' => 207,
    'params' =>
    array (
      'tag' => '\'image_downsize\'',
      'value' => 'FALSE',
      1 => '27721',
      2 => '\'content-default\'',
    ),
  ),
  38 =>
  array (
    'function' => 'apply_filters',
    'type' => 'dynamic',
    'class' => 'WP_Hook',
    'file' => '/web/wp/wp-includes/plugin.php',
    'line' => 212,
    'params' =>
    array (
      'value' => 'FALSE',
      'args' => '[0 => FALSE, 1 => 27721, 2 => \'content-default\']',
    ),
  ),
  39 =>
  array (
    'function' => 'filter_image_downsize',
    'type' => 'dynamic',
    'class' => 'Timmy\\Timmy',
    'file' => '/web/wp/wp-includes/class-wp-hook.php',
    'line' => 287,
    'params' =>
    array (
      'return' => 'FALSE',
      'attachment_id' => '27721',
      'size' => '\'content-default\'',
    ),
  ),
  40 =>
  array (
    'function' => 'resize',
    'type' => 'static',
    'class' => 'Timmy\\Timmy',
    'file' => '/vendor/mindkomm/timmy/lib/Timmy.php',
    'line' => 496,
    'params' =>
    array (
      'img_size' => '[\'resize\' => [0 => 3000], \'srcset\' => [0 => [...], 1 => [...], 2 => [...], 3 => [...], 4 => [...], 5 => [...], 6 => [...], 7 => [...], 8 => [...], 9 => [...], 10 => [...], 11 => [...]], \'sizes\' => \'(max-width: 1200px) 100vw, 1200px\', \'show_in_ui\' => TRUE, \'oversize\' => [\'allow\' => FALSE, \'style_attr\' => FALSE], \'name\' => \'Content - Default\']',
      'file_src' => '\'https://bar.mx/app/uploads/2021/02/foo-3-mx.jpg\'',
      'width' => '3000',
      'height' => '0',
      'crop' => '\'default\'',
      'force' => 'FALSE',
    ),
  ),
  41 =>
  array (
    'function' => 'resize',
    'type' => 'static',
    'class' => 'Timber\\ImageHelper',
    'file' => '/vendor/mindkomm/timmy/lib/Timmy.php',
    'line' => 698,
    'params' =>
    array (
      'src' => '\'https://bar.mx/app/uploads/2021/02/foo-3-mx.jpg\'',
      'w' => '3000',
      'h' => '0',
      'crop' => '\'default\'',
      'force' => 'FALSE',
    ),
  ),

uploads/2021/02/foo-3-mx.jpg is actually 1666x3000 and Timmy must know about this. Then it must not try to create an image larger than the initial one since it's has all the chances to end-up badly:

Because the resulting image bring no quality (Browser can upscale image if told so and do it quicker and better)
Because triggering imagick to upscale often lead to memory problems (Among those ran by web/wp/wp-includes/class-wp-image-editor-imagick.php many filters would consume a bunch of memory on bigger images).

Yep, you’re totally right. Timmy can easily know about whether it should upscale an image or not. I started working on this, but it’s taking a little longer than expected.

Any news regarding this?

Hey @drzraf
I’m in the process of refactoring a lot of things, because it became harder to maintain the code with a function based approach where I repeat myself quite often. There will be a new 1.0 version, including the fix for this. I made good progress in the last two weeks, so you can expect a result soon.
Sorry for keeping you waiting :)

I just added the first beta for Timmy v1.0.0 that includes a fix for this: https://github.com/mindkomm/timmy/releases/tag/1.0.0-beta.1.

I tested it and it seems to work! That's a great change.
Thank you

Great! Thanks for the feedback 👍😊


"keyof" infers type incorrectly when it is applied to interface that extends Record<string, any>

🔎 Search Terms
keyof interface extends record number
🕗 Version & Regression Information

This is the behavior in every version I tried

⏯ Playground Link
Link
💻 Code
interface EmptyInterface {};
type StringRecord = Record<string, string>;
interface Interface extends StringRecord {};

type EIFKey = keyof EmptyInterface // never
type SRKey = keyof StringRecord // string
type IFKey = keyof Interface // number | string, why not string?

🙁 Actual behavior
IFKey is number | string
🙂 Expected behavior
IFKey should be string

In general, what is indexable by string is also indexable by number:
const stringRecord: StringRecord = {};
const test1 = stringRecord["foo"];
const test2 = stringRecord[100];

const interface_: Interface = {};
const test3 = interface_["foo"];
const test4 = interface_[100];

The difference in keyof results here is surprising to me though.

I believe the difference in behavior comes down to, Record is implemented as a mapped type.  keyof MappedTypeOverString is string.  Interfaces can’t be mapped types though (AFAIK), so extending a Record<string, T> demotes it to an index signature, and keyof StringIndexSignatureType is string | number, by design.


feat(LinearAlgebra/LinearIndependent): add linearIndependent_iff_finset_linearIndependent

A family is linearly independent if and only if all of its finite subfamily is linearly independent.

Is linearIndependent_finset_map_embedding_subtype one direction of (a special case of) your lemma? It seems so... in this case can you erase linearIndependent_finset_map_embedding_subtype?

Is linearIndependent_finset_map_embedding_subtype one direction of (a special case of) your lemma? It seems so... in this case can you erase linearIndependent_finset_map_embedding_subtype?

I think you're right. but in linearIndependent_finset_map_embedding_subtype the index set Finset.map (Embedding.subtype s) t has type Finset M, whereas my version it's just t which is of type Finset s. In the following linearIndependent_bounded_of_finset_linearIndependent_bounded it uses such convention (namely the input argument of it uses Finset M) so it's not so straightforward to use my result to prove it.

Is linearIndependent_finset_map_embedding_subtype one direction of (a special case of) your lemma? It seems so...

Yeah, linearIndependent_finset_map_embedding_subtype is stated for sets, the results that connect linear independence for sets and types are later, so it seems complicated to use you result. We can maybe add the covers of linearIndependent_finset_map_embedding_subtype, but in my opinion the API for sets should be avoided.

Thanks!
bors merge


Make ref lookups aware of what streams hold what maps

Currently when a ref lookup is done by an XSLT that has multiple ref feeds the lookup will attempt the lookup against each ref stream in turn until it finds a hit.  This is fine if all ref streams contain the map being lookup up against, but in most cases each stream will contain different maps.
The MapDef => UID db already gives us the means to find out which maps are in which ref streams.  Given that a mapDef is <refStreamDef><mapName> we can just set a start key for the ref stream of interest with a null map name then scan down to find all the map names for that refStreamDef.  Would need to do this for each ref stream in the lookup.  The results could then be held as a local pipeline scoped map of mapName => refStreamDef for future lookups.  See stroom.pipeline.refdata.store.offheapstore.databases.MapUidForwardDb#getNextMapDefinition for similar scanning code.
It will mean a change to the way the lookup/load is done.  We may need to ensure all ref streams are loaded up front before doing any lookups.  Then we will know where all the maps are so subsequent lookups will be more efficient.

Fixed in beta.145


Plugin repository

Currently, there aren't really any plugins available. Only the sample plugin packaged, and few others in development. With just few plugins, which are basic, they can be bundled into the source repository, but when the project expands, the plugins will become more and should have an easier overview. Therefore I would suggest making a special repository for just plugins only. Any thoughts on this one?

Closing as this was implemented in master.


highlight.js 10.1.1 (0f5c28a4) cannot work in IE11

Hi, I am developing a small plugin/Add-in for Microsoft Word.
I need a code highlighter
I want to develop a new code highlighter by myself. After several days' attempt, I find it was so difficult to support multi language and multi styles.
So I turned into highlight.js. After 3 days learning about JS and HTML, now I can read and edit the developer.html by myself. I have develop a very simple but nice JS highlighter using highlight.js.
However, the Win Form's webBrowser object in .Net was awful. I cannot call my JS code from C# easily. After a lot of browsing on google, it turned that the built-in webBrowser class in C# was the same as IE11 so it cannot support the newer JS.
My code: https://github.com/LittleNewton/Equation_and_Codebox
You can see my JS file in src/highlight/ folder and the main JS function is in callee.html.
callee.html work very well in Chromium Edge browser. However when I open the HTML file in IE11, exception occured.
SCRIPT1002: syntax error
highlight.js (31,3)
SCRIPT5009: “hljs” was undefined
callee.html (32,4)

callee.html was showed like below:
<!DOCTYPE html>

	<meta http-equiv="X-UA-Compatible" content="IE=11">
	<meta charset="utf-8">
	<title>Callee</title>
	<link rel="stylesheet" href="./vs.css">

		<textarea id="mainTextArea"></textarea>

<button id="btn_Highlight_and_Copy" onclick="DoAllActions()">渲染代码并将其复制到剪贴板</button>

渲染后的代码

https://github.com/highlightjs/highlight.js/issues/2501
We don't support IE 11 anymore. Too old.
You could try version 9 which still worked with 11.


Trait Suggestion: Everywhere doubled line S86 is not Biconnected P44 (and 3 more traits)

Trait Suggestions
The Everywhere doubled line S86

Property
number
pi-Base missing info

is not Biconnected
P44
not in pi-Base

is not Hereditarily separable
P180
not in pi-Base

is not a Door space
P126
not in pi-Base

does not have a cut point
P204
not in pi-Base

Proofs
There are following witnesses of violating the aforementioned traits:

Trait
counterexample

P44
e.g. $(-\infty,0)\times\{0,1\}$ and $[0,+\infty)\times\{0,1\}$ are disjoint connected and cover $X$

P180
In the set $B=\mathbb R \times \{1\} \subset X$ every point is open w.r.t. the subspace topology hence $B$ is not separable

P126
e.g. $[0,1]\times\{0\}$ is neither closed (closure contains "doubled" points) nor open (ends are not in the interior)

P204
after removing $(x,e)$, the line remains connected because of $(x,1-e)$

The proofs are too simple to waste separate issues for them.

For P180 the resoning is more general (but trivial):
every space containing a not-door subspace is not door.
Proof: A neither open nor closed subset of a subspace cannot be open or closed in the whole space.
I suggest a theorem:

Locally Euclidean P122 + Door P126 => Discrete P52

which is not known today (see also this questionable search)
A non-discrete locally Euclidean space contains a subset homeomorphic to $R^n$ with $n>0$ which is not a door space.
Auxiliary comment
It would be nice if pi-Base incorporated the concept of hereditary property, but this would require a significant changes (saving meta-property and relation of inclusion/embedding) and could lead to an urge of adding other meta-properties (hereditary on open, hereditary on compact, preserved by continuous maps, etc.). I believe the most important is to have all the current properties decided for the current spaces, not rebuilding the base.

Regarding meta-properties of properties, we have discussed this multiple times in the past.  For now, not much is happening, but I would like to suggest an intermediate step towards that goal.  Will write a separate issue about it.

See #1071.


Debug flag

Is need the debug flag for print debug information?
For example:
c2go transpile -d myfile.c
flag -d for output debug information.

There is a verbose mode, but it doesn't provide much information. Maybe it would be better to have multiple levels of verbose (with the highest one being debug) that prints out everything.
We would need to define what the levels are and also what each level does.

Yes, you are right verbose mode and integration tests is enought for analizing.
If it is not actual, then please close.


Unable to download spreadsheet from ingest

Describe the bug
I am unable to download a spreadsheet for project NucleiMultiplexHashing
To Reproduce

Go to the submission page
Click on Download spreadsheet
Wait
Service unavailable message appears - the waiting message is overlaid on top

Expected behaviour
After a certain waiting time I should be able to download the spreadsheet
Screenshots / Logs

Environment

[x] prod
[ ] staging
[ ] dev

Browser

[x] Chrome
[ ] Safari
[ ] IE
[ ] Other (please specify)

Hey @aaclan-ebi - is this something you have taken? I think we need to escalate this investigation :)

https://drive.google.com/open?id=1vVQJon-IBKhQnDIaltaHtFRFz3LftI0E&authuser=mshadbolt%40ebi.ac.uk&usp=drive_fs

Interesting, i see the following error in prod logs for Ida's submission
ingest-broker-67968b8d57-zc5xg ingest-broker [app.py:1458 -        log_exception() ] 2022-02-03 09:56:32,698 - broker_app - ERROR - Exception on /submissions/e6dca5ce-60b2-4087-97bd-fb32b20db01a/spreadsheet [GET]
ingest-broker-67968b8d57-zc5xg ingest-broker Traceback (most recent call last):
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2073, in wsgi_app
ingest-broker-67968b8d57-zc5xg ingest-broker     response = self.full_dispatch_request()
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1518, in full_dispatch_request
ingest-broker-67968b8d57-zc5xg ingest-broker     rv = self.handle_user_exception(e)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/usr/local/lib/python3.6/site-packages/flask_cors/extension.py", line 161, in wrapped_function
ingest-broker-67968b8d57-zc5xg ingest-broker     return cors_after_request(app.make_response(f(*args, **kwargs)))
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1516, in full_dispatch_request
ingest-broker-67968b8d57-zc5xg ingest-broker     rv = self.dispatch_request()
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1502, in dispatch_request
ingest-broker-67968b8d57-zc5xg ingest-broker     return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/broker/submissions/routes.py", line 21, in export_to_spreadsheet
ingest-broker-67968b8d57-zc5xg ingest-broker     workbook = ExportToSpreadsheetService(app.ingest_api).export(submission_uuid)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/broker/submissions/export_to_spreadsheet_service.py", line 17, in export
ingest-broker-67968b8d57-zc5xg ingest-broker     flattened_json = self.downloader.convert_json(entity_list)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/src/hca-ingest/ingest/downloader/downloader.py", line 18, in convert_json
ingest-broker-67968b8d57-zc5xg ingest-broker     return self.flattener.flatten(metadata_list)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/src/hca-ingest/ingest/downloader/flattener.py", line 21, in flatten
ingest-broker-67968b8d57-zc5xg ingest-broker     self._flatten_entity(entity)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/src/hca-ingest/ingest/downloader/flattener.py", line 37, in _flatten_entity
ingest-broker-67968b8d57-zc5xg ingest-broker     embedded_content = self.embed_link_columns(entity)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/src/hca-ingest/ingest/downloader/flattener.py", line 72, in embed_link_columns
ingest-broker-67968b8d57-zc5xg ingest-broker     self._embed_input_ids(entity, embedded_content)
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/src/hca-ingest/ingest/downloader/flattener.py", line 116, in _embed_input_ids
ingest-broker-67968b8d57-zc5xg ingest-broker     input_ids_ids = [i.content['biomaterial_core']['biomaterial_id'] for i in inputs]
ingest-broker-67968b8d57-zc5xg ingest-broker   File "/app/src/hca-ingest/ingest/downloader/flattener.py", line 116, in <listcomp>
ingest-broker-67968b8d57-zc5xg ingest-broker     input_ids_ids = [i.content['biomaterial_core']['biomaterial_id'] for i in inputs]
ingest-broker-67968b8d57-zc5xg ingest-broker KeyError: 'biomaterial_core'
ingest-broker-67968b8d57-zc5xg ingest-broker [_internal.py:225 -                 _log() ] 2022-02-03 09:56:32,700 - werkzeug - INFO - <IP_ADDRESS> - - [03/Feb/2022 09:56:32] "GET /submissions/e6dca5ce-60b2-4087-97bd-fb32b20db01a/spreadsheet HTTP/1.1" 500 -

Seems like the downloader implementation is not able to handle datasets with file to file linking (e.g. sequencing file to analysis file linking). I'll work on a fix for this.

@aaclan-ebi to work on this

@idazucchi confirmed that the linking was fixed.
PRs ready for review:
https://github.com/ebi-ait/ingest-client/pull/43
https://github.com/ebi-ait/ingest-core/pull/112

Submission UUID: 85b5d566-bb78-4bed-89e6-2f44e7b6bd48
Project: 5b328561-4a97-40ac-b7ad-6a90fc59d374

Tested Irene's spreadsheet in staging: https://staging.contribute.data.humancellatlas.org/submissions/detail?uuid=06923b5d-942d-430f-99c2-b56f64caa96e
The spreadsheet was downloaded successfully.
Will promote to prod.

Hi @ipediez & @idazucchi The spreadsheet was generated successfully for both of your submissions in prod. You can check and download them now.


Eye tracker support

Added eye tracker data and setting support

The RT protocol connect using v1.18 and eye tracker support is > v1.19, the rt server will not fetch any eye tracker settings.


Add authenticated_user api endpoint to return current user, issue #58

This will return the current user data, including roles. Docs also updated. Close #58

Confirmed that this works with POSTMAN. Merging and closing issue #58


Remove DualStack feature gate and make it a build-in behavior

Issue Description
Type: feature request
Describe what feature you want
Now, to deploy a DualStack hybridnet cluster, we need to open the DualStack feature gate by manager/webhook parameters.
But it seems now that "an ipv4-only cluster with closed DualStack feature gate" and "a dual-stack cluster (DualStack feature gate is opened) with only ipv4 subnets" are not different at all. Maybe it's time to remove the DualStack feature gate and make it a build-in feature.
Additional context

Changes need to be done at the same time:

IPv4 address and IPv6 address of one dual-stack Pod can be assigned with different netID
Remove "status.dualStackStatistics" and dual-stack quota label

Maybe unit tests of manager need to be update.


Cut over to using the unigame client package with selective use of SwiftUI

I have separately been developing the unigame framework, which carries the "any" aspect of anyCards further (basically supporting any game that has players taking turns).  This is made possible by the fact that the unigame client provides the UI for player management, chat, and help but just has dummy UIs for setup and playing.   So, you can have a UI that has nothing to do with cards (e.g. chess, checkers, dominos, Mah Jongg ...).
Splitting responsibility for the text of the help view is an aspect of unigame that is not yet fully worked out.   It could be as simple as pasting together pieces of HTML but that assumes that the help describing the player management and the fixed aspects of setup and playing (basically, the logic of turn taking) can be written in a way that can be included in almost any game.  Not sure about that.
Currently, unigame assumes that Auth0 is used to acquire tokens (because unigame-server assumes that), but does not have an Auth0 dependency nor an Auth0.plist because each using app needs to declare its own Auth0 application identity with its own unique callbacks matching the Apple bundle ID.   The management of that split is tentatively worked out.
Most of this is currently untested.   So, the plan is to change anyCards so that it declares a dependency on unigame and becomes the first user of it.  Since unigame owns the top content view, which is SwiftUI, and the top level shells of the Setup and Playing views are also SwiftUI, this means that anyCards needs to either use SwiftUI or make use of UIViewRepresentable to embed the existing UIKit material as needed.   I will play that by ear as I go.
Logistically, since this is a huge sweeping change to anyCards I will develop the new limping version of it on a branch.

Something is limpingly working now with a playing view, no setup view, and no modal dialogs.   There is a crash in the lead player when ending the setup phase because it is dummied out and the game handle code doesn't quite understand what to do.  I think the setup view needs to be a lot like the playing view but with some extra controls.
Once we get rid of the crash (by creating a real setup view) and verify that some rudimentary play can occur, I will start restoring the modal dialogs.   They will all be redone as SwiftUI popovers or alerts.

In developing the setup controls, a couple of sub-issues come up.

In saving the current setup, a name needs to be assigned.  This will require a popup.
Similarly, we still need a deal dialog.
I it is unclear how you can delete a saved setup.   Easiest is to have a button or other touchable action that operates on the currently displayed saved setup.   We need a load button anyway.  So, having both load and delete seems ok.

There is also other logic to be added as all the button actions are still TODO at this poin

The current layout of the setup view is a mess.

Controls for naming, selecting, saving, loading and deleting setups need to be grouped together.
The other controls (deck type selection, hand area toggle, deal button, and reset button) can form a separate group.
The PlayingSurface needs attention to get its aspect ratio correct, both when it is dominating the playing view, and when it is windowed (slightly smaller) into the setup view.
Related to the previous, we need to figure out how (or whether) to lock the orientation to match the playing surface's aspect ratio.

It would also be good to get solitaire mode cleaned up so I can make sure all the interactions in the PlayingSurface are actually working.  There is some evidence that the view does not always update when it should.

This might be the way to do the orientation locking:
https://stackoverflow.com/questions/78829188/locking-rotation-to-portrait-on-swiftui-without-the-use-of-appdelegate-or-scened

This might be how you force a particular aspect ratio:
https://developer.apple.com/documentation/swiftui/view/aspectratio(_:contentmode:)-771ow

Controls for naming, selecting, saving, loading and deleting setups need to be grouped together.

The GameTokensView in unigame might provide a clue.  It has a place where the current game token is displayed, a place where selectable game tokens of the past of displayed, and add and delete buttons.   I don't want the saved setup control to occupy as much space, though, particularly vertical space.   So, I would use a picker rather than a list for the saved tokens.   The picker also takes the place of the "current" display, but we would need buttons to add, delete, and load.
The semantics of "add" would subsume "save" (the current setup is saved under the added name).

Setup view is now better.  i'm trying to use solitaire mode to shake out bugs.  Issues noted:

In solitaire mode, most of the rest of the players screen is useless and should be greyed out or replaced by some informative text.
In the setup screen, changing the deck type or hand area indicator does not seem to update the view.

But note that we should fix the playing area aspect ratio before seriously experimenting with the hand area.

If you go to the playing phase (note that both setup and playing share the same playing surface instance) there seems to be two decks.

3. The PlayingSurface needs attention to get its aspect ratio correct, both when it is dominating the playing view, and when it is windowed (slightly smaller) into the setup view.

I've done some layout tweaks to fix the aspect ratio, by using the .aspectRatio modifier as per the link posted above.   Still no orientation locking, but I expect to return to that since it is part of the TODO material in PlayingSurface.   Right now, the setup view layout looks good on iPad simulators but there are ugly overlaps when running directly on mac.  I am not worrying too much about that.
I think the next step is to get solitaire mode fully smoothed out so I can then use it to debug all the interactions involving the PlayingSurface.

The setup screen issues are mostly resolved.  Time to exercise setup and playing more fully in solitaire mode and then test multiplayer scenarios.

In order to test out more complex scenarios I will need the remaining modal dialogs (already have the dealing dialog),   The other ones I know about are

the main GridBox menu
the GridBox modification menu
the menu to toggle between grouped and ungrouped behavior for cards in the hand area (currently using UIAlertController)

Some current issues:

In working on the dealing dialog (issue #61) I concluded that PlayingSurface should always have a GridBox with the MainPlayingDeck name.  You could then count on this being true even though the deck field is computed and it is possible for it to be nil.   This turns out to be a crock.  There are games in which you would naturally want to delete the initial deck after dealing out the cards into other kinds of GridBoxes and piles.   So, I need to use deck == nil as an additional disablement criterion in places where this would matter.
It looks like the evolving GridBoxMenu items that cause new popups ("Deal" and "Modify") are tricky.  Symptom: the new Popup doesn't show.
I have not found a good way to both size and posiition the popup so that all of its buttons are showing and its placement doesn't seem weird.

It looks like the evolving GridBoxMenu items that cause new popups ("Deal" and "Modify") are tricky.  Symptom: the new Popup doesn't show.

The problem with "Deal" was simply that I didn't move the flag that controls presentation into the model, even though the dialog is now requested from more than one place.   This was easily fixed and the Deal dialog now shows.  The Modify dialog isn't written yet so I won't worry about it.

3. I have not found a good way to both size and position the popup so that all of its buttons are showing and its placement doesn't seem weird.

This is fixed now.
Getting the placement right involves calculating the right UnitPoint value for an explicit anchor.   The box dialogs are now  anchored in the center of the relevant box, which is non-weird.
However, the deal dialog has an anchor point on the main Deal button (in SetupControls) and so, when requested, it always pops up there, whether requested by the main button or from the GridBoxMenu.  In the latter case, this still seems weird.   Also, this will need to change anyway because the main deal button will not be present in the playing view but grid boxes can be present in that view.
I would be tempted to make the deal dialog always show up in the requesting box.   I see two ways to do this.

Eliminate the main deal button entirely.  It is arguably not needed because setup is no longer modal; the playing surface is not only visible but can be interacted with.   So, you want to deal, just touch the deck legend or long-press the deck.
Make the main deal button act like an adjunct of the deck if present.   It acts exactly as if you touched the deck legend and then selected "deal".   This could help novices learn the possibilities by making the availability of dealing more obvious.  But, it returns us to the problem of how to get the deal button enablement right, now that we know the deck is not guaranteed to be present.

At least part of getting the enablement right for the deal button is that the canDeal flag is on the PlayingSurface which is not Observable.   And, if we add a computed property to AnyCardsGameHandle (which is Observable) it will be exempt from observation; we need a stored property in the handle which will always be set in synchrony with changes to the PlayingSurface.

I started down the path of moving the canDeal flag to the game handle.  I realize, though, that a global canDeal flag will only reflect the state of the main deck and not of other grid boxes.   The global flag can affect the enablement of the main deal button (if we retain that) but each grid box also needs its own enablement.  Since the GridBoxMenu is built dynamically on demand, it doesn't need an observable canDeal flag.

At the end of a drag, the dealing area may have changed from clear to unclear or vice versa.  So, setCanDeal should be called there.

Fixed now.

2. I think the use of a stepper to select the dealing target is hokey and I should consider using a picker instead.

Changed over now.  Does indeed seem easier to understand and use.

Caught up on things that I've started, so back to the list of things I haven't (modify box dialog and hand grouping toggle).
At that point, I will be pretty much done with what can be tested in solitaire mode.   Communication function and orientation locking etc. have been coded, at least, so the remaining work should be test-driven.

I have run into a mysterious problem with the modify box dialog.   There were a number of distracting red-herrings which I think have been eliminated, but, I still see that the dialog sets the box name to a new value yet the box displayed on the playing surface still shows the old value.

Most problems I was seeing went away when I stopped using the "stop the world and start over" approach to getting update requests from SwiftUI in PlayingSurface.   Instead, for now, the update function is doing nothing.
ModifyBoxMenu is now working adequately although I'd like to make the popup somewhat bigger and make it more obvious that the text field for the box's name is editable.

Adding padding around the entire VStack seems to make it nicer.

The grouping dialog for the private area has been added so the cutover is "code complete" and reasonably well tested in solitaire mode.   Next steps are

Test some typical game sequences with two similar devices.
Test with dissimilar devices and device rotation to see whether scaling and orientation locking are working correctly.

Initial testing with two "identical" devices (my own iPad and a simulator for its model and OS version) we initially disappointing but the worst problems were fixed in the unigame layer by liberal use of @MainActor and then some use of @preconcurrency and @unchecked Sendable.   The goal being to get things to be on the right thread.  The cost of not doing this was sometimes that updates to @Observeable objects were not noticed by the UI.
I got some distance into setting up a game of war and then

Deleting a deck box by the lead player in the setup view is not noticed by in the partner app's playing view.
Dragging boxes in the lead player's setup view causes an anomalous result in the partner app's playing view: an empty box is left behind in the starting position.
There are also problems with chat (I opened https://github.com/joshuaauerbachwatson/unigame/issues/24 to track this in unigame.

In fact, all three problems might be unigame problems but the first two could be at either level.

Chat issues were fixed at unigame level.  Behavior now (testing still light) with two identical "devices" (one a simulator) in nearby-only, staying in portrait.   Next to test: same but using the server.

Things are now pretty good.    Noting:

Still have not tested with unlike devices or doing stressful things like rotating the view.  I don't yet really know if orientation locking is working.
As noted in https://github.com/joshuaauerbachwatson/unigame/issues/28, unigame help is not there yet so at this point anyCards help is regressed.

I think I should get at least the above two things addressed before declaring victory on this issue and merging the new anyCards into main.

Unigame help is now largely working and I've updated AnyCards help to use it.  The layering/structuring stuff seems pretty good.   The help text is up-to-date and useful at the unigame level but the AnyCards help is still backlevel, describing how things worked before the cutover.


Looking for maintainer

Hi everyone, as you can see in the issues, my response is really slow. I'm sorry for the delay and extra work that has caused. It's due time to find one or more other people who'd be willing to maintain the project. That means mostly reviewing contributions, testing, keeping an eye on documentation and code quality; but most importantly, doing releases.
If anyone is interested, please respond here. I'm open to add people to this repository, or move the repository it to a new GH organisation if desired (don't forget to update doc generation config for the latter).

I can help with this, since I anyway have a need for this plugin.

Closing this now, but all contributions are still welcome of course, there are a few issues labeled with "good first issue" even for people new to this plugin.