Could not find device for node (reduce_max of complex)

tf.reduce_max(tf.constant([1 + 1j]))

TF 2.5.0, Windows 10, Python 3.9.6.

Error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Anaconda\envs\tf25_env\lib\site-packages\tensorflow\python\util\dispatch.py", line 206, in wrapper
    return target(*args, **kwargs)
  File "D:\Anaconda\envs\tf25_env\lib\site-packages\tensorflow\python\ops\math_ops.py", line 2908, in reduce_max
    return reduce_max_with_dims(input_tensor, axis, keepdims, name,
  File "D:\Anaconda\envs\tf25_env\lib\site-packages\tensorflow\python\ops\math_ops.py", line 2920, in reduce_max_with_dims
    gen_math_ops._max(input_tensor, dims, keepdims, name=name))
  File "D:\Anaconda\envs\tf25_env\lib\site-packages\tensorflow\python\ops\gen_math_ops.py", line 5781, in _max
    _ops.raise_from_not_ok_status(e, name)
  File "D:\Anaconda\envs\tf25_env\lib\site-packages\tensorflow\python\framework\ops.py", line 6897, in raise_from_not_ok_status
    six.raise_from(core._status_to_exception(e.code, message), None)
  File "<string>", line 3, in raise_from
tensorflow.python.framework.errors_impl.InvalidArgumentError: Value for attr 'T' of complex128 is not in the list of allowed values: float, double, int32, uint8, int16, int8, int64, bfloat16, uint16, half, uint32, uint64, qint8, quint8, qint32, qint16, quint16
        ; NodeDef: {{node Max}}; Op<name=Max; signature=input:T, reduction_indices:Tidx -> output:T; attr=keep_dims:bool,default=false; attr=T:type,allowed=[DT_FLOAT, DT_DOUBLE, DT_INT32, DT_UINT8, DT_INT16, DT_INT8, DT_INT64, DT_BFLOAT16, DT_UINT16, DT_HALF, DT_UINT32, DT_UINT64, DT_QINT8, DT_QUINT8, DT_QINT32, DT_QINT16, DT_QUINT16]; attr=Tidx:type,default=DT_INT32,allowed=[DT_INT32, DT_INT64]> [Op:Max]

It is said that
Value for attr 'T' of complex128 is not in the list of allowed values: float, double, int32, uint8, int16, int8, int64, bfloat16, uint16, half, uint32, uint64, qint8, quint8, qint32, qint16, quint16

I believe complex number is not supported yet?

@OverLordGoldDragon,
As mentioned in the  error message and by @collinzrj, complex128 is not supported by tf.reduce_max at this point of time. I've also tested in latest stable version2.6.0 and its not supported yet. Thanks!

@sanatmpa1 This is an unhandled exception - it helps the user to see something like
   torch.max(torch.tensor([1 + 1j]))

RuntimeError: "max_all" not implemented for 'ComplexFloat

It is still replicating in 2.9 and nightly. Attached gist for reference.

This error message is consistent for all ops across TF when you try to run something on a dtype that isn't supported.  I suggest we keep as is for reduce max.  There are separate efforts for improving error messages across the entire TF codebase.


Ability to save cache even on failure

Hi, I would need access to the cache key to be able to save the cache despite any other failures as documented here: https://github.com/actions/cache/blob/main/caching-strategies.md#saving-cache-even-if-the-build-fails

Hey Kevin - thx for the issue 👍

Just a little confused from your link - what output do you want piped through, as you've linked to an example that uses outputs.cache-hit?
Also this example is for actions/cache/restore - not actions/cache. I don't use (or need) the former.

Let me know - if it's just threading through an output from actions/cache - then that should be trivial to add in a backward compat. way.

Hey,
sorry, my bad, pasted the wrong link.
would be nice to reference the key you use in
    - name: Setup Golang cache
      uses: actions/cache@v3
      with:
        path: |
          ${{ steps.golang-path.outputs.build }}
          ${{ steps.golang-path.outputs.module }}
        key: ${{ runner.os }}-golang${{ inputs.cache-key-suffix && '-' }}${{ inputs.cache-key-suffix }}-${{ hashFiles('**/go.sum') }}
        restore-keys: |
          ${{ runner.os }}-golang${{ inputs.cache-key-suffix && '-' }}${{ inputs.cache-key-suffix }}-

with sth like:
steps:
  - uses: actions/checkout@v3
  ...
  - name: Setup Golang with cache
    id: setup-golang
    uses: magnetikonline/action-golang-cache@v3
  ...
  - uses: actions/cache/save@v3
    if: always()
    with:
      path: path/to/dependencies
     key: ${{ steps.setup-golang.outputs.cache-key }}

Right - that makes sense. I'll see what I can do.
I do find the usage case a little perplexing, why do you want to save path/to/dependencies into the cache key that would be the Golang build artifacts/modules?
I haven't used actions/cache/save - so maybe I'm missing the point.
At any rate - exposing the cache key of ${{ runner.os }}-golang${{ inputs.cache-key-suffix && '-' }}${{ inputs.cache-key-suffix }}-${{ hashFiles('**/go.sum') }} as an output from the action will be pretty trivial.

You want to explicitly save the cache in case sth further down the line fails.
in this case the post actions (aka actual saving of the cache) will not be run.
that's the reason action/cache offers actions/cache/restore & actions/cache/save to be independent of the post actions

Fair enough.
But I think the point still stands - you want path/to/dependencies in this case to be the Golang build artifacts/modules only - otherwise it won't make sense on the restore.

Hey @franklinkim - finally found some time to add this enhancement.
See: https://github.com/magnetikonline/action-golang-cache/releases/tag/v4
It technically didn't need a new major release - but since I refactored things around a bit, I didn't want to risk breaking any previous uses of the action by others in the wild - and be a good citizen. 😄.
Let me know how it goes - I added a usage example too - based on what you provided above: https://github.com/magnetikonline/action-golang-cache#action-outputs
As you can see - I'm also outputting the Golang file paths cached - saves having to re-determine these yourself.
Thanks for the suggestion!

@magnetikonline thanks very much! this will work nicely

Hey no dramas @franklinkim - let me know how/if it works out for you - sorry it took so long to get this implemented - worthy enhancement 👍


Documentation fixes for PluginNetworkPermissionScope.

Documentation fixes for PluginNetworkPermissionScope.
Motivation:
There were two issues with the documentation for PluginNetworkPermissionScope:

It was not curated, and this caused the symbol to show up at the top level of the PackageDescription documentation. This was not desired.
The abstract for the symbol was not on its own line in the DocC comments. This caused the abstract to have multiple sentences, which goes against style.

Modifications:

The PluginNetworkPermissionScope symbol was curated under the PluginPermission symbol.
The DocC documentation for PluginNetworkPermissionScope was changed to provide a single sentence abstract on its own line, and one additional sentence on a separate line.

Result:
The PluginNetworkPermissionScope documentation is now curated in the correct place, and the abstract looks correct.

@swift-ci please smoke test.


Fix: Correction, removed the content = string equalization

There are situations when the built-in print() function is needed - it is convenient. But due to the presence of a content change to string inside it, format-sensitive data may break. For example, the method can receive as String (in case of an error) so is File, but if there is a file, converting the original content to String led to an error when debagging.

If I remember it correctly, content is used for caching purposes, if you try to read the response again. This will be quite a large breaking change if I bring it in. And I don't see any tests.


OptimizeMolecule and OptimizeMoleculeConfs Argument Bug

Describe the bug
I am trying to use Chem.rdForceFieldHelpers.OptimizeMolecule and OptimizeMoleculeConfs in Python. However, I keep getting ArgumentError when using those functions. An example is provided below (constraint part neglected):
# Generate molecule
mol = Chem.MolFromSmiles('CCC[O]')
mol = Chem.AddHs(mol)
Chem.AllChem.EmbedMultipleConfs(mol, numConfs=10)

# Setup forcefield
mp = Chem.rdForceFieldHelpers.MMFFGetMoleculeProperties(mol)
ff = Chem.rdForceFieldHelpers.MMFFGetMoleculeForceField(mol, mp)

# Optimize
Chem.rdForceFieldHelpers.OptimizeMoleculeConfs(mol, ff, numThreads=1, maxIters=200)

The error I got is
ArgumentError: Python argument types in
    rdkit.Chem.rdForceFieldHelpers.OptimizeMoleculeConfs(Mol, ForceField)
did not match C++ signature:
    OptimizeMoleculeConfs(RDKit::ROMol {lvalue} mol, ForceFields::ForceField {lvalue} ff, int numThreads=1, int maxIters=200)

From my naive investigation, mol, numThreads, and maxIters should be good. Then, the assigned ff is problematic? I guess that this function is asking for ForceField but ff is actually pyForceField?
To Reproduce
You can use the above example to reproduce.
Expected behavior
No ArgumentError when using mentioned functions.
Configuration (please complete the following information):

RDKit version: 2020.09.1
OS: Mac OS 11.2
Python version (if relevant): 3.7.7
Are you using conda? Yes
If you are using conda, which channel did you install the rdkit from? rdkit

@ptosco, it looks like I didn't do a very good job of reviewing #2401, when you added OptimizeMoleculeConfs() to the python wrappers: there are no tests for those new python functions and they don't work.
Do you have time for this one or would you prefer that I take it?

@greglandrum I’ll do that.

I faced the same issue. Please help me to fix it.
My RDKit version:
rdkit                     2024.03.5        py39hc1ff0a3_1    conda-forge

I faced the same issue. Please help me to fix it.
My RDKit version:
rdkit                     2024.03.5        py39hc1ff0a3_1    conda-forge

We can't help unless you provide a code snippet showing how to reproduce the problem you saw.

My code is that:
df.loc[ind, 'ROMol'] = Chem.MolFromSmiles(row[args.smi_column])
df.loc[ind, 'Mol_H'] = Chem.AddHs(df.loc[ind, 'ROMol'])
df.loc[ind, 'Mol_H'] = AllChem.EmbedMolecule(df.loc[ind, 'Mol_H'])
df.loc[ind, 'Mol_H'] = AllChem.UFFOptimizeMolecule(df.loc[ind, 'Mol_H'])

With smiles CCCS, the error is:
 df.loc[ind, 'Mol_H'] = AllChem.UFFOptimizeMolecule(df.loc[ind, 'Mol_H'])
Boost.Python.ArgumentError: Python argument types in
    rdkit.Chem.rdForceFieldHelpers.UFFOptimizeMolecule(int)
did not match C++ signature:
    UFFOptimizeMolecule(RDKit::ROMol {lvalue} self, int maxIters=200, double vdwThresh=10.0, int confId=-1, bool ignoreInterfragInteractions=True)

@mainguyenanhvu The error message:
 df.loc[ind, 'Mol_H'] = AllChem.UFFOptimizeMolecule(df.loc[ind, 'Mol_H'])
Boost.Python.ArgumentError: Python argument types in
    rdkit.Chem.rdForceFieldHelpers.UFFOptimizeMolecule(int)
did not match C++ signature:
    UFFOptimizeMolecule(RDKit::ROMol {lvalue} self, int maxIters=200, double vdwThresh=10.0, int confId=-1, bool ignoreInterfragInteractions=True)

tells you that you are calling the function UFFOptimizeMolecule() with an integer instead of a molecule.
You are using pandas incorrectly, this is not an RDKit issue.

I found that I have not to re-assign AllChem.EmbedMolecule to the object, just call it, and also not because of pandas:
AllChem.EmbedMolecule(mol)
AllChem.UFFOptimizeMolecule(mol)
df.loc[ind, 'Mol_H'] = mol

The problem is solved.
Thank you for your time and consideration.


Update README.md

Fix broken link.

I'm just a random person who got notified of this (maybe because I starred or clicked "Watch" on this repo) but it may be preferable to use the current URL (https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380111102) or even better the permanent URL (https://doi.org/10.1002/spe.4380111102) rather than the Wayback Machine's historical URL.

The only problem with the "correct" URL is that Wiley now wants to charge for access to the article, whereas in the past they allowed open access to it.

Maybe also link to Michael Plass's thesis https://www.tug.org/docs/plass/plass-thesis.pdf

The only problem with the "correct" URL is that Wiley now wants to charge for access to the article, whereas in the past they allowed open access to it.

Until a non-paywalled link is found, the Wiley link is more useful than a 403 Forbidden error.

The only problem with the "correct" URL is that Wiley now wants to charge for access to the article, whereas in the past they allowed open access to it.

For what it's worth I can't access the full PDF via the Wayback Machine URL you had earlier either, and as far as I can tell, I don't think they ever allowed open access to this paper. However one can easily find copies online by searching for the appropriate keywords, plus with the DOI there are… ways.


browsingContext.reload: add ignore cache E2E test

Bug: #650

For now, both true and false for ignoreCache pass. We need something else to ensure the behavior is proper. @sadym-chromium any other ideas? Network events do not seem to be enough to differentiate them.

what about fromCache flag in the network.responseCompleted event?

Good idea. Both tests have fromCache: False though.


Rule FC007 can't consume dependencies in an hash

I haven't seen this pattern elsewhere but I also don't see a lot of examples of others being as strict as I'm trying to be about dependencies.  I'm declaring cookbook dependencies like so:
dependencies = {
  'cookbook-one' => '1.8.0',
  'cookbook-two => '2.3.0'
}
dependencies.each do |k, v|
  depends k, v
end

Unfortunately this triggers FC007 because it doesn't fit either of the common patterns.
depends 'cookbook-one', '1.8.0'

OR
%{ cookbook-two }.each do |cbk|
  depends cbk
end

If I can find the time, I'll look at the API and see if I can sort it out but if someone is more familiar with declared_dependencies, feel free.

Confirmed against master


[ownership] Change is_escaping_closure to accept any ownership as an …

…operand instead of requiring guaranteed.
This is a point use that even makes sense for owned values.

@swift-ci smoke test and merge


fix: tests for use a retina image challenge

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Closes #XXXXX

We've gotten a couple of reports about this challenge in the support email. On my machine (Linux Mint 19.3), the current tests fail in Chrome (83.0.4103.116), but pass in Firefox (77.0.1).
In Chrome's dev console, the height and width of the image are both 99.986px rather than 100px, even after playing with the zoom. These changes look at the actual width and height attributes of the image, and should still allow for answers like max-width: 100px;.

Hey @scissorsneedfoodtoo , my understanding is that, this will not make the difference either, and you need to use:
element.style.width

To consistently retrieve the given value

Hi @Sky020, thanks for looking into this.
I just tried with the element.style.width method, but only got empty strings. As far as I can tell, the style property is just for getting  inline styles, or those that were set dynamically.
I also tried with getComputedStyle, but ended up getting 99.9862px in Chrome which we're trying to avoid. We could use getComputedStyle, strip px from the string, convert it to a number and round it, though.
Not really sure what the best method would be other than testing the width and height attributes directly.

the style property is just for getting inline styles, or those that were set dynamically.

You are quite right.

Not really sure what the best method would be other than testing the width and height attributes directly.

I suppose, if this PR corrects the issue on a few more browsers, and we do not want to go through the hassle of using regex, then this PR is useful as is.

I also tried with getComputedStyle, but ended up getting 99.9862px in Chrome which we're trying to avoid. We could use getComputedStyle, strip px from the string, convert it to a number and round it, though.

We've had this problem before too, I believe. It was because jQuery uses getComputedStyle as far as I remember.

Thanks for the merge @moT01 :+1: :+1:


[cl4 | newest ] CORS Blocks all headers

Expected behavior
Server sends allowed headers header with Content-Type and Authorization allowed

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight
Current behavior

Possible solution

Server sends allowed headers header with Content-Type and Authorization allowed
Steps to reproduce
on ff

Auth with API
Send ANY reqest that needs the Authorization header

Platform info

Meower Server

Python: 3.10
MongoDB: 6.2.0
Redis: Redis 5.0.14 for Windows
Meower Server Version + Build Date:

Desktop/Server

OS: Windows
Version:  10
RAM:8GB
Storage: 1TB
CPU Architecture: x86_64

Did I read the instructions before making this bug report?

I have HAVE read the instructions.

Suggestion: https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/

I ended up using that Mike
On Fri, Mar 3, 2023, 2:07 PM MikeDev101 @.***> wrote:

Suggestion:
https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/
—
Reply to this email directly, view it on GitHub
https://github.com/meower-media-co/Meower-Server/issues/166#issuecomment-1454069076,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQHW4PYGWVNOMJT4NTXKGHLW2JFQTANCNFSM6AAAAAAVH6MVMY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Closing as this seems to be fixed in the production server and CL4 is no longer planned.


2.x cli should fail gracefully if --version is 3.x

Currently, running a 2.x cli against a local 3.x snapshot simulates the issue, i.e.
helidon init --reset --url file:///Users/batsatt/dev/helidon/archetypes/helidon/target/cli-data

This results in the following error:
error: /Users/batsatt/.helidon/cache/3.0.0-SNAPSHOT/archetype-catalog.xml does not exist

Which is clearly cryptic and needs improvement.

Version 3.0.0 of this CLI is now available:

    2.3.1  This is 2.x only
    3.0.0  Supports both

Please see https://github.com/oracle/helidon-build-tools/blob/master/cli/CHANGELOG.md to update.

Using Helidon version 3.0.0-SNAPSHOT
Helidon flavor
  (1) SE
  (2) MP
Enter selection (Default: 1):
error: /Users/batsatt/.helidon/cache/3.0.0-SNAPSHOT/archetype-catalog.xml does not exist

#
# Copyright (c) 2020, 2022 Oracle and/or its affiliates.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
build-tools.version=2.0.2
cli.latest.plugin.version=
cli.version=3.0.0
cli.3.0.0.message=Supports both
cli.2.3.1.message=This is 2.x only


"Incomplete message received" error

Hi,
I have been successfully using the dbus-solaredge integration for almost a year, but today I had to factory reset my Cerbo GX and obviously lost the dbus-solaredge service.
I can't get it to work again, with the following message appearing in the log exactly every 7 seconds:
@4000000066f82b80159f1a54 2024-09-28 16:14:46,361 - DbusSolarEdge - INFO - Startup, trying connection to Modbus-Server: ModbusTCP <IP_ADDRESS>:1502, UNIT 2
@4000000066f82b80161cbe64 2024-09-28 16:14:46,369 - DbusSolarEdge - INFO - Connected to Modbus Server.
@4000000066f82b801757c2ec 2024-09-28 16:14:46,390 - root - INFO - registered ourselves on D-Bus as com.victronenergy.grid.grid_id00
@4000000066f82b831800ef84 2024-09-28 16:14:49,401 - DbusSolarEdge - ERROR - regs.isError: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received)

Unfortunately neither the workaround mentioned in #9 nor any amount of rebooting the SE inverter and/or the Cerbo and/or the dbus-solaredge service seems to work. Any ideas how to proceed or debug further here?

of course it just magically started working 5 minutes after creating the issue. sorry for the noise


basic mocking functionality

Handles emails and transactions. Forwards email sends to Postmark itself using the POSTMARK_API_TEST server token (no-op wrt. actually sending, but gives back accurate responses/error messages).

Great! Do you think it would make sense to have this in a sub package?

sure, i don't think there's anything that depends upon anything package-private

Great! 👍


Conventions for checked teardown

We have a guideline:

Destructors never fail (C-DTOR-FAIL)
Destructors are executed on task failure, and in that context a failing destructor causes the program to abort.
Instead of failing in a destructor, provide a separate method for checking for clean teardown, e.g. a close method, that returns a Result to signal problems.

Let's provide further guidance around naming the teardown method as well as how to decide whether it accepts self or &mut self.
Relevant tempdir issue: https://github.com/rust-lang-nursery/tempdir/issues/26

We would need to call close several times in case of tearing down with multiple attemts. I vote for &mut self.

Alternatively, the method can take self, and the Err variant can return the value in case of error. There is precedent for that in libstd: String::from_utf8. I think that's preferable to taking &mut self. Otherwise we might need additional state so that drop only attempts to clean up if necessary.

@kamalmarhubi close can return Result and can take &mut self. That does not contradict each other.
String::from_utf8 is opposite to close. It take the ownership of it's parameter. close does not.

@opilar if close would invalidate the object it should take self to prevent accidental use.

@dtolnay we discussed this last week and came to some conclusions but I can't remember what they were. I recall it seemed clear cut, but after reviewing this thread it doesn't seem so.

Taking &mut self makes it so you can retry a close if it fails
But taking &mut self means that you have to worry about handling all operations while in the closed state, which is quite burdensome
Take self means you either don't get to retry on failure, or you have to return self in the error type

As with all things dtor seems like it's all bad tradeoffs.
I think it's also reasonable to note that it's not obvious that retrying a failed close makes sense. Failing to close an I/O resource is almost always a nightmare, no-win scenario. I don't think I've ever seen a recommendation to retry closing a thing, and istm that an API that demanded close be retried would be extremely unfriendly. On some systems common wisdom is to assume close succeeds and just ignore failures to close. Having an explicit close in most cases seems primarily an opportunity to do some logging that something is really messed up.
On the other hand in the tempdir case, closing means delete an entire directory tree, and we know that, especially on windows, that is a fraught operation. Still, we've even recently added defensive code in tempdir to do all kinds of things to try to make the delete 'just work', so it's hard to imagine what other heroics we might expect the caller to do to fix our failure to close.

I don't think it'd be a good idea to make a "law" in case different implementations might need to do different things. I actually like encoding in type whether operation is retry-able.
The guidelines could be:

if failed operation doesn't invalidate the resource in any way, take by &mut self and return Result<(), E>
if failed operation invalidates the resource and can't be retried take bye self and return Result<(), E>
if failed operation can be retried but makes the resource otherwise unusable, take by self and return Result<(), (E, RetryHandle)>, where RetryHandle is user-defined type with retry method. The retry method should take self and return Result<(), (E, Self)> (note that in this case Self is the RetryHandle)

@Kixunil @brson What to do with an error while an object goes out of scope?
{
    let a = A::new();
} // <-- error here

@opilar I think we have to preserve current convention - just ignoring the error.

@Kixunil I think ignoring the error is incorrect.
I think close should return () and the programmer should make a choice to ignore the error or panic.
To retry and get an error we can make another method with Result<(), E> return type.

@opilar Drop::drop() should never panic as that leads to abort. There is really no other way to solve this unfortunately. Also at Unix, close can't be retried. If one wants to ensure data is written on disk, he must use fsync. AFAIK after successful fsync it doesn't matter whether close will succeed.

@Kixunil You are right. For general case I think close(&mut self) -> Result<(), E> with ignoring the error is appropriate. A developer can use it to retry the dropping operation if it does make sense.

I don't think close(&mut self) -> Result<(), E> is a good idea. Consider this scenario:

Thread 1 calls close()
close fails, but OS deletes FD
Thread 2 calls open(). The returned FD number is the same as previously closed FD
Thread 1 calls close() again to retry - FD opened by thread 2 is closed
Thread 2 has now invalid FD that was invalidated by other thread.

Obviously, close() must consume self in order to avoid this. This will become even worse if thread 3 opens another file just after thread 1 retried: threads 2 and 3 will share same FD and likely corrupt data. Finding out the cause would be a nightmare.

It can replace the file descriptor with -1 on Unix and the handle with
INVALID_HANDLE on Windows.
On Tue, Jul 11, 2017 at 5:11 AM Martin Habovštiak<EMAIL_ADDRESS>wrote:

I don't think close(&mut self) -> Result<(), E> is a good idea. Consider
this scenario:

Thread 1 calls close()
close fails, but OS deletes FD
Thread 2 calls open(). The returned FD number is the same as
previously closed FD
Thread 1 calls close() again to retry - FD opened by thread 2 is
closed
Thread 2 has now invalid FD that was invalidated by other thread.

Obviously, close() must consume self in order to avoid this. This will
become even worse if thread 3 opens another file just after thread 1
retried: threads 2 and 3 will share same FD and likely corrupt data.
Finding out the cause would be a nightmare.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/brson/rust-api-guidelines/issues/61#issuecomment-314423930,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABY2URoP0n8ED_fGONx-sNRsgFI4xZyHks5sM2ZXgaJpZM4Naj6M
.

Yes, but that completely defeats the purpose of retrying and may introduce errors that could've been caught compile-time. I like Rust because precisely it can avoid such things. I'd even say that not consuming self is anti-Rust, unless it comes with significant performance hit.

The runtime errors are going to exist one way or another if the File/whatever lives in a struct. Drop doesn't take self by value.

Sure, that doesn't mean we should allow errors being more confusing.

@dtolnay @brson seems like we're stuck here.

Clearly no resolution so far for the general case. Maybe there's a resolution for tempdir.

cc https://github.com/rust-lang/rust/issues/32255, the discussion on rust-lang/rust, notably this comment
One other point I think worth mentioning is that I think the ergonomics of &mut self vs self. In some situations self can be quite natural but in others it can be quite difficult to use. For example consider something like:
struct A { /* ... */ }
struct B { /* ... */ }
struct C {
    a: A,
    b: B,
}

impl A {
    fn close(self) -> Result<(), A> { /* ... */ }
}
impl B {
    fn close(self) -> Result<(), B> { /* ... */ }
}

impl C {
    fn close(self) -> Result<(), C> {
        let C { a, b } = self;
        match a.close() {
            Ok(()) => {}
            Err(a) => return Err(C { a, b }),
        }
        match b.close() {
            Ok(()) => Ok(())
            Err(b) => {
                // panic? store an `Option<A>`? different error?
            }
        }
    }
}

Here we've got types like A and B which have a self-style close method, and then we're trying to create a composite resource C which contains both A and B. If we try to implement a self close method on C we get in a situation where:

The method itself is pretty painful to right. Lots of destructuring, movement, handling of errors, etc.
We still have to deal with partial close states. Our first close may succeed but the latter close may fail, so we either need to communicate this in our error type or deal with optional state internally.
We probably need to manufacture a unique error type for this method instead of just returning C, and we'll likely need a unique type per-close, which can get quite wordy when we consider conventional error messages.

When compared to &mut self though:
impl C {
    fn close(&mut self) -> Result<(), MyError> {
        self.a.close()?;
        self.b.close()?;
    }
}

The &mut self version is more ergonomic to write, is the same in the "successful case", and doesn't require new kinds of errors. The downside of this approach, of course, is that a and b may be forced to contain internal optional state. In experience with futures, though, this is actually relatively rare in practice as only the leaf types need this optional state and everything else built on them can rely on optional state elsewhere. For example C here doesn't need any optional state.
This to me drives home the the debate personally, placing me firmly in the &mut self-as-a-recommendation camp.

Hm, @alexcrichton's observations about the difficulty of dealing with partially-destructured types in the by-value case is pretty convincing.

If &mut self were the guideline here, often forcing implementors to track a bool indicating a resource is closed, I'd hope we can also suggest that the proper response to doing any operation on a closed resources is to panic, e.g. assert!(!self.is_closed()).
If that is true, we might also want to say that it is acceptable to call close multiple times, to deal with retries in the partial-success case. IOW, if you have a closable thing that contains two closable things, like @alexcrichton's previous example, and on the first call to close, one succeeds, and one fails; the user needs to be able to call close again, and the impl for C needs to look like one of the following:
impl C {
    fn close(&mut self) -> Result<(), MyError> {
        self.a.close()?;
        self.b.close()?;
    }
}

impl C {
    fn close(&mut self) -> Result<(), MyError> {
        if !self.a.is_closed() { self.a.close()?; }
        if !self.a.is_closed() { self.b.close()?; }
    }
}

Hm, on the other hand, I still think it's basically hopeless to retry closes generally, and I might suggest that a failed close where multiple inner resources fail to close is one of those horrible dtor scenarios where there is no right solution, so I'm still not totally convinced against self.
Instead of @alexcrichton's outline for the multiply-closing C here:
impl C {
    fn close(self) -> Result<(), C> {
        let C { a, b } = self;
        match a.close() {
            Ok(()) => {}
            Err(a) => return Err(C { a, b }),
        }
        match b.close() {
            Ok(()) => Ok(())
            Err(b) => {
                // panic? store an `Option<A>`? different error?
            }
        }
    }
}

Where the first failed close immediately returns, I might suggest that C has a responsibility to attempt to close all internal resources and return whatever errors happened, more like
impl C {
    fn close(self) -> Result<(), C> {
        let C { a, b } = self;
        let r_a = a.close();
        let r_b = b.close();
        if r_a.is_err() { return a; }
        if r_b.is_err() { return b; }
        Ok(())
     }
}

That doesn't cover the case where both a and b failed to close of course.

Ah yeah I don't think in general we should strive to support retrying a failed close operation. The close syscall itself you can't retry on a cross-platform basis and lots of scenarios tend to bubble up from that. I'd be more worried about reclaiming resources from a closed object rather than retrying the close operation, though.
One example could be something like a buffered reader where after you close it you want to reclaim the buffer to recycle it (or something like that). In that sense I think that if we recommend self we'll also want to recommend that both variants of the Result carry Self somehow to reclaim those resources. With &mut self though we'd get this for free.
It's true though that I don't know what we would ideally do in the face of partial errors on close. I want to say this is enough:
impl C {
    fn close(&mut self) -> Result<(), MyError> {
        self.a.close()?;
        self.b.close()?;
    }
}

but I fear a "more correct" situation would look like:
impl C {
    fn close(&mut self) -> Result<(), MyError> {
        self.a.close()
            .and(self.b.close())
    }
}

Where in the latter we may drop an error on the floor but in the former we may not actually close resources.

Why don't we write helper crate for dealing with these situations instead of throwing array Rust's safety guarantee? Why even use Rust then?
Let's think about how to design multi-close API. For simplicity, assume we have only two resources a, b. Possible options:

both succeeded
a failed, b succeeded
a succeeded, b failed
both failed

Which data structure should be used for this? Yep, enum! Well, since we want to return Result, here's how to do it:
// This would be in extern crate
enum CloseError<EA, EB> {
    A(EA),
    B(EB),
    Both(EA, EB),
}

// Handy alias
type CloseResult<EA, EB> = Result<(), CloseError<EA, EB>>;

impl<EA, EB> CloseError<EA, EB> {
    fn from_results(a: Result<(), EA>, b: Result<(), EB>) -> CloseResult<EA, EB> {
        match (a, b) {
            (Ok(()), Ok(())) => Ok(()),
            (Err(A(e)), Ok(())) => Err(CloseError::A(e)),
            (Err(B(e)), Ok(())) => Err(CloseError::B(e)),
            (Err(A(ea), Err(B(eb))) => Err(CloseError::Both(ea, eb)),
        }
    }
}

// User would write just this
fn close(self) -> CloseResult<MyErrA, MyErrB> {
    CloseError::from_results(self.a.close(), self.b.close())
}

Using macros we can write CloseError2<A, B>, CloseError3<A, B, C>, CloseError4<A, B, C, D>` ...

It seems bad to break backwards compatibility because you added a new closeable private field to your type.

@sfackler what do you mean?

@Kixunil I'm guessing he means that any client code that calls close() and then does a match on the CloseError will be broken if you ever add a new variant to the CloseError enum.
This is exactly why I believe "non-exhaustive enums" (https://github.com/rust-lang/rfcs/pull/2008) are a good fit for custom error types.

@lxrec Well, that's the problem with strong typing in general: if you are too specific, you may cause backward incompatibility.

 We recommend leaving builders as prunes instead of consuming self.
I personally like the idea of the self approach better, but I think the &mut self approach is probably the best recommendation because, as @alexcrichton mentioned, you don't necessarily escape from managing internal state with the self approach. It seems to offer more flexibility as close methods becomes more complex, and that's complexity that you need to navigate carefully. Plus it's more closely aligned with Drop (but that might not actually be important).

@KodrAus I think that's actually a very good way to put it, in "simple" cases a by-value self seems to have lots of benefits but a "complex" case is where self starts to show growing pains and &mut may take over.
In the sense of guidelines I'd prefer to make a concrete recommendation one way or another to ensure that the ecosystem works well together. If you, for example, tried to compose by-value self closing methods and by-mut closing methods it'd be pretty painful :(

One thing to consider when deciding this is, that taking by self vs taking by &mut self is somewhat similar to returning Result and panicking. The first instance allows the user to choose how error states should be handled (in case of self, the user can opt-in to &mut self semantics with Option), the second one forces opinions on users. (The user can't decide that he prefers compiler checks.)
The fact is that there is no significant difference between self + Option and &mut self. In both cases, there must be a check (there's no way around it). Option is explicit opt-in to panicking (usually used with unwrap) and may be easier to debug (did your code panic on unwrap? search for unwrap()!).
Finally, "what if someone doesn't want to call unwrap() on every use?" That's what DangerousOption is for.

@Kixunil I'm not sure I follow what you mean.
As a recommendation for an API that libraries should follow, I'm in favour of &mut self because the ergonomics scale better with complexity. Also, any bugs related to using the resource after it's closed will probably be fairly localised to where it was closed. The risk is that your code panics at runtime, which can be a problem, but isn't unsafe.
If you're building an application and want to make your checked teardown take self by value, which seems like a reasonable thing to do, then you can wrap &mut self teardown methods of internal resources and do that.

What I mean is that if one takes by self the user of such thing can decide for themselves how to handle stuff. If they simply want panic semantics, they use unwrap() or DangerousOption. If they are writing a critical code, where panicking should never happen, they can still write their code in such way to ensure it doesn't.

@Kixunil I don't quite agree that an &mut self receiver as opposed to a self receiver limits your options for how to handle errors. In either case you'll receive a Result, the difference is whether the error variants includes self that will have a different scope than &mut self.
The kinds of bugs that are possible to result from &mut self that aren't also possible with self are attempting to re-use that prune'd structure after close. My argument is that the likelihood and risk of those bugs (panicking) don't warrant the complexity and loss of composability of a self receiver in libraries.
I think we've exhausted the conversations around ergonomics and compile-time safety and will either have to accept the tradeoffs of one of the approaches or not recommend anything. If we can't recommend anything then I'd suggest simply leaving tempdir's close method as-is (it's currently a self close method).
Do you have any ideas on how to move forward @dtolnay @alexcrichton?

@KodrAus It limits one how to handle accidental misuses. Taking by &mut self means it will panic and you can do nothing about it. Taking self means the code is either correct or won't compile.

My argument is that the likelihood and risk of those bugs (panicking) don't warrant the complexity and loss of composability of a self receiver in libraries.

It's not just that. Such design introduces another "invalid" state that must be handled in every method. This doesn't just slow down the code but puts burden on the implementor to write those checks (and not forget them).
What you really want is DangerousOption. It bridges the two worlds and it is sufficiently explicit.

or not recommend anything.

Maybe this is the best approach so far.

I prefer &self.  In a file scenario you open a file, write to it, and close it.  That shouldn't remove the reference to the file and it should still be able to be reopened off of the same &self.
I'd like this for a standard:
trait Close {
  fn close(&self) -> Result<(), E>;
}

Stuff will get dropped out of scope anyways.
As for the example @alexcrichton gave with nested close method calls I believe this could be handled through the Error type.  Just as Error has a cause method it could also potentially have a source method.  From that instead of using the ? operator to pass the error up the chain there can be a middle-man catch for the error that can deal with the source method.  Not to mention the fix for the implementation could also just be written into the close method in the first place should one of the two items fail to close.  If that's not the case I would argue that those multiple closes do not belong in one close as that seems to be rather unsafe and should be handled in stages rather than once in close.
In my opinion the added complexity scenarios are more the responsibility of the individual developers rather than a concern for a general standard.  Handling situations that come up as you go along is a very normal thing and using close alone, as a standard, to try and solve that is a bit much.

@danielpclark That's a very bad idea because it allows accidental use-after close. It also requires implementor to keep file name (url, whatever) stored too (allocated on the heap).

@Kixunil

That's a very bad idea because it allows accidental use-after close.

That's not necessarily the case.  If the code is implemented in a way where something can be “used” only when open then closing it would end the allowed behavior until re-opened again.

It also requires implementor to keep file name (url, whatever) stored too (allocated on the heap).

I don't see that as a bad thing.  Drop handles scope cleanup anyways.
Here's How Ruby does Tempfile
require 'tempfile'

file = Tempfile.new('foo')
file.path      # => A unique filename in the OS's temp directory,
               #    e.g.: "/tmp/foo.24722.0"
               #    This filename contains 'foo' in its basename.
file.write("hello world")
file.rewind
file.read      # => "hello world"
file.close
file.unlink    # deletes the temp file

Having the file name after was important in this use case.  I imagine unlink would be implemented in Drop in Rust for Tempfile, but there could arguably be a use case where a person doesn't use Drop in their code.

@danielpclark the difference is that if you accidentally write something like this:
let f = open("file")?;
f.read(&mut buf)?;
f.close()?;

// some code here

if(som_unlikely_condition()) {
    f.read(&mut buf)?;
}

In your case the code will panic or fail and that will be discovered only during testing. That takes time and it will require the programmer to analyze the situation to understand where the problem is. In my case it won't compile in the first place and the compiler will tell the programmer the exact line where the problem is.
Ruby is not Rust - if it was, we wouldn't have Rust in the first place. Sure, there are cases when keeping the file name around is practical, but that should be the choice of the library user.

I think the compound close example could be improved with Result/Option adapters:
impl C {
    fn close(self) -> Result<(), CCloseError> {
        let ar = self.a.close();
        let br = self.b.close();
        match (&ar, &br) {
            (&Ok(_), &Ok(_)) => Ok(()),
            _ => Err(CCloseError::from_inner(
                        ar.err(),
                        br.err()))
        }
    }
}

The caller should be able to look into CCloseError for the optional inner error data and extract whatever state (which may or may not be the original inner objects) was salvaged from the failed teardowns for graceful error handling. This might expose too much implementation detail, though.

Do we have examples of checked teardown - even if it is for APIs we don't have yet, or for APIs from other platforms - that are not close(2)?
close(2) is peculiar enough (can't be retried; the correct behavior really depends on what the app is doing) that generalizing it to other checked teardown cases seems wrong.

POSIX.1-2008 does leave the state of a file descriptor after a failed close(2) "unspecified", but from the perspective of application code, the only safe thing to do is to assume that the file descriptor has been deallocated, whether or not an error code was returned.  In other words, treat it as if the operation always succeeds, but may report an I/O error in the process; that I/O error properly belongs to a previous write operation.
So in terms of trait signatures, I would prefer close to consume self, and in the two-open-files case I would say that it is more important to be sure that both files do get closed, than to reliably report all errors.  Lots of programs don't bother checking for delayed I/O errors, and a program that really cares about robustness needs to call fsync anyway.

@federicomenaquintero

Do we have examples of checked teardown that are not close(2)?

Named temporary files might be a good case to think about.  unlink can fail for several different reasons, and you certainly do want to report the failure, but I don't think a program would want to retry it, because the failure is probably "sticky" and needs to be addressed by a human.  (For instance, someone has messed with the permissions on the parent directory behind the program's back.)  Similar to named temporary files are old-style "SysV IPC" resources - shared memory segments, inter-process queues and semaphores - these have their own namespaces, outside the filesystem, and have to be deallocated using special system calls, that again can fail, but for "sticky" reasons.

@zackw well said, thank you!

@zackw Nice examples, thanks.  So, basically:

Named temporary files - yeah, just report that they couldn't be unlinked.  There's nothing the program can do.

IPC and stuff - I'm thinking of shmat() / shmdt().  The latter can only return EINVAL basically only if you pass it something that was not what shmat() returned.  I'd hope that a Rust wrapper for that would make this impossible :)  But yeah, I see your point about OS-like calls that can fail on teardown.  Just report an error for correctness/completeness, even if the program can't really do anything about it.

The "unlink" equivalent for SysV shm is shmctl(seg, IPC_RMID, 0) which can fail with EPERM.  I'm not sure if that's possible for the process that created the segment, but yeah, same treatment as unlink seems best to me.


Problem with TabControl (TabItem header) and custom controls.

I am trying to use custom control from control library in another project as content of TabItem header. Problem is that our custom control can’t find default template when placed in TabItem header. It loads template just fine in any other case I tried it in header of expander control for example.
This is the link to repo of small project demonstrating this issue.
I would appreciate if somebody can check it as it seems like something that can create problem for many users.
Igor

Hi @igorstefus - yeah sorry our TabControl isn't great at the moment. I wonder if you would be able to try out https://github.com/AvaloniaUI/Avalonia/pull/1842 which @Gillibald has been working on and see if that fixes it for you?
If you build the PR, the easier way to test might be to use the ReplaceNugetCache scripts in https://github.com/AvaloniaUI/Avalonia/tree/master/scripts to overwrite the libraries in your package cache to with the libraries you built.
It would be really helpful if you could help us test this PR!

I have just merged that PR with current master to make sure it is up to date.

Should be fixed by #1842


Create depin-mass-adoption.md

@WinsCodes Please merge this new PR The logo for the team Parasail is below

@laeccles This event has been merged to PL Events PROD.


Error when upload the file and ingest data

Unhandled Runtime Error
ReferenceError: response is not defined
Source
components\ConfigSideNav.js (27:3) @ response
25 |   } catch (error) {
26 |     setIsLoading(false);

27 | 	response.text().then(text => {toast.error("Error Ingesting data."+text);})
| 	 ^
28 |   }
29 | };
30 |

Please check if huggingface sentence transformers are being downloaded during ingest

Solved, need install some pip packages, and upgrade python, tnkxs!


added check for rsp1 that is rsp2

This is a check to handle GBM RSP files that end with the extension '.rsp' when they in fact have multiple responses inside.
The effect of the change is to treat these as RSP2s because otherwise the user could be using an RSP coverage interval that is not valid for their source interval. The user is warned about the treatment.

Codecov Report

Merging #195 into master will increase coverage by 0.01%.
The diff coverage is 27.27%.

@@            Coverage Diff             @@
##           master     #195      +/-   ##
==========================================
+ Coverage   74.81%   74.83%   +0.01%
==========================================
  Files         126      126
  Lines       13240    13258      +18
==========================================
+ Hits         9905     9921      +16
- Misses       3335     3337       +2


Random length base example selector

Description: The length example selector always retrieves the same examples, going from top to bottom. In the case you have a lot of examples, there will not be any variation. I just copied and modified this length selector to do a random length base examples selector, so for each prompt, the examples selected will be random

Dependencies: Added the random import, not dependencies changed

Tag maintainer: for a quicker response, tag the relevant maintainer (see below),

going to close this. it needs tests at a minimum. we are also going to think more deeply about example selectors soon, we will reference this then


introduced VRGFindOrFetchPackage

VRGFindOrFetchPackage can simplify the task of composing FindOrFetchXYZ modules

This should also allow to specify a version (range) for the dependency

should be able to pass at the front of FIND_PACKAGE_ARGS

Ah, true :+1:

There is only a slight semantic issue with this approach in that find_package takes the version information as an unnamed argument and so the overall call looks like
    VRGFindOrFetchPackage(Catch2 "https://github.com/catchorg/Catch2.git" "${SEQUANT_TRACKED_CATCH2_TAG}"
            ADD_SUBDIR
            CONFIG_SUBDIR
            FIND_PACKAGE_ARGS 3
    )

where the 3 is somewhat meaningless from this context alone :thinking:

In the most recent version FIND_PACKAGE_ARGS is only used for find_package: https://github.com/ValeevGroup/kit-cmake/pull/7/files#diff-716c5f00f3c4144ece3078047f53a820429caf59037785b49ca826bb4a7da919R36

Yes, but you can't pass VERSION 3 as find_package doesn't know a VERSION argument name. Instead, you can only pass the numeric version itself. See also https://cmake.org/cmake/help/latest/command/find_package.html

Yes, but you can't pass VERSION 3 as find_package doesn't know a VERSION argument name. Instead, you can only pass the numeric version itself. See also https://cmake.org/cmake/help/latest/command/find_package.html

Ah yes ... I see, your complaint is about cosmetics ... well, I guess we could add another option but it might be safer to stick with the documented find_package signature


Include name in modal for update and delete of extension

include the name of the extension to improve usability.

@hame-c8y :This is changed with the next build and can be tested in branch: feature/migration-c8y-1021


Implementing Split Transaction

https://github.com/omisego/plasma-cli/issues/42
use:
plasma_cli split --fromutxo=UTXO_position --fromowner="from_address" --privatekey="from_privatekey" --toowner="to_address" --toamount=to_amount  --outputs=number_of_outputs --watcher="watcher_url"

Takes in a single UTXO input - split into N Outputs

if have change, add change into the next output
throws error if:

outputs are more than 4
amount to split > from amount

Note: Split is reimplementing a lot of function found in Send right now. I will refactor all the PlasmaTransactions and have them share the same interface later.

fixed https://github.com/omisego/plasma-cli/issues/41


Vertical corousel not working properly

I am trying to implement vertical corousel but facing issue with 3rd component, http://prntscr.com/ii58si
I want center one to be on the top and 1st and 3rd elements should go behind the focused one.

⚠ You did not follow the contributing guidelines!
As stated in these:

You need to fill out the issue template. This step is mandatory! Not doing so will result in your issue getting closed. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template.

The carousel is working properly. To achieve what you're after, you need to implement a custom interpolation. I've written an entire guide dedicated to this advanced feature.
You'll have to use the following trick to render the active item on top of the others:
{ zIndex: carouselProps.data.length - index }

But beware, due to a React Native bug, it just doesn't work on Android! See this for more info.


Fix Testcases for updated changes

Update the testcases to update the new changes. ETC student_id, class_id, grade

i will work on the test cases for parser


remmina: 1.2.0-rcgit.24 -> 1.2.0-rcgit.29

Motivation for this change
Updated remmina to newer version
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build remmina

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: remmina
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: remmina
Partial log (click to expand)
patching script interpreter paths in /nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/launcher.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/functions.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/remmina_filezilla_sftp.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/remmina_filezilla_sftp_pki.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/remmina_nslookup.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/remmina_ping.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/share/remmina/external_tools/remmina_traceroute.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29...
Wrapping program /nix/store/r7q6y4pd6a1l94clic26j2vgcncyg6s2-remmina-1.2.0-rcgit.29/bin/remmina

Failure on aarch64-linux (full log)
Attempted: remmina
Partial log (click to expand)
cannot build derivation '/nix/store/560k72x3gw1gbis2fhxw2dsd9shsivc8-cargo-1.26.2.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/fa14m90h5firblf1m8qf1qcgww51f3fq-librsvg-2.42.4.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/jqpisavg2c4544dpw62zch8lmgv5l4x3-gst-plugins-bad-1.14.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/wqwg410fnw9iaym374r8zb3jd7wky8px-hook.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/yfpn31bbp0snabqyac37lkbqpy6fmig0-icon-naming-utils-0.8.90.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/36xdfr0agr22ikp33y604zm6y103y5kh-adwaita-icon-theme-3.28.0.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/7kjw4gzjdzqlj0xif0pjrhcrpg46bq2n-geoclue-2.4.8.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/61pcl96rrw5b73wmzypvvf7cssgbn2fw-webkitgtk-2.20.2.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/20vwxpr8hq20ckc874myix9iaz7p7g4a-remmina-1.2.0-rcgit.29.drv': 3 dependencies couldn't be built
error: build of '/nix/store/20vwxpr8hq20ckc874myix9iaz7p7g4a-remmina-1.2.0-rcgit.29.drv' failed

Thank you. I assume you added yourself to maintainer-list.nix because you would like to become a maintainer of this package. In this case you need to modify the package meta.maintainers attribute as well:   maintainers = with maintainers; [ melsigl ];

Closing in favor of #42106 which has a newer version.


Fix the broken links caused by 0110c90

0110c90 causes a lot of broken links.
I commented on the commit, but seems @felipesanches only looks at issues. To copy:

I'm sorry, this change is quite bad at least for searchers, it broke links all over the place. See e.g.:
https://github.com/google/fonts/blob/main/CONTRIBUTING.md
https://github.com/googlefonts/glyphsets/issues/25
https://github.com/googlefonts/glyphsets/issues/13
I'm not asking you to do a revision, good heavens no, I'm sure it's good for your software's logical design. But to add a file to Lib/gftools/encodings/ rather than rm whole dir, e.g. put a README.md there @felipesanches, saying what happened, then maybe you symbolic link old files to the README, or make them all contain a link to it. Otherwise you just made tons of old discussions impossible to follow.

—https://github.com/googlefonts/gftools/commit/0110c9003f48ae79d484357075a56928d6f82d36#commitcomment-62742341

@ctrlcctrlv, I had seen your message on the commit during vacations and planned to address this in early January 2022. Sorry that I did not mention that with a small comment.
I plan to address this asap (tomorrow :-D)


Adding white background after creating a composite circular image

Hi I am trying to add a specific color background to a circular image.
The code I used to create the circular image is as follows.
sharp(image)
.resize(parseInt(req.query.width), parseInt(req.query.height))
.composite([{ input: Buffer.from(circleSVG), blend: 'dest-in' }])
.toBuffer((err2, dt1, info) => {
res.set('Content-Type', 'image/jpeg');
res.send(dt1);
});
The image is generated but I cannot add a specific color background to fill the bounding box of circular image in the background. I tried flatten with background but that does not work. what I want is that a person image is cropped in a circle and then put over a square background of a particular color.

Hi, dest-in is probably the wrong blend mode. Instead overlay an SVG containing a path of a circle-cut-from-a-square, see https://stackoverflow.com/a/26481923/4625124 for an example.

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


FileNotFoundError: [Errno 2] No such file or directory: 'results/padim/mvtec/bottle/results/padim/mvtec/bottle/weights/model.ckpt'

Before going into this bug, the sample command under the Inference section of the gave the following sample command:
python tools/inference.py
--config anomalib/models/padim/config.yaml
--weight_path results/padim/mvtec/bottle/weights/model.ckpt
--image_path datasets/MVTec/bottle/test/broken_large/000.png
But there is no such file as inference.py, so I assume it should be tools/inference/lightning.py
Steps to reproduce the behavior:

pip install anomalib==0.3.3
python tools/train.py
mkdir test_result
python tools/inference/lightning.py
--config anomalib/models/padim/config.yaml
--weight_path results/padim/mvtec/bottle/weights/model.ckpt
--image_path datasets/MVTec/bottle/test/broken_large/000.png
--save_path test_result

Error Code:
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Torchmetrics v0.9 introduced a new argument class property called full_state_update that has
not been set for this class (AdaptiveThreshold). The property determines if update by
default needs access to the full metric state. If this is not the case, significant speedups can be
achieved and we recommend setting this to False.
We provide an checking function
from torchmetrics.utilities import check_forward_no_full_state
that can be used to check if the full_state_update=True (old and potential slower behaviour,
default for now) or if full_state_update=False can be used safely.
warnings.warn(*args, **kwargs)
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Metric PrecisionRecallCurve will save all targets and predictions in buffer. For large datasets this may lead to large memory footprint.
warnings.warn(*args, **kwargs)
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Torchmetrics v0.9 introduced a new argument class property called full_state_update that has
not been set for this class (AnomalyScoreDistribution). The property determines if update by
default needs access to the full metric state. If this is not the case, significant speedups can be
achieved and we recommend setting this to False.
We provide an checking function
from torchmetrics.utilities import check_forward_no_full_state
that can be used to check if the full_state_update=True (old and potential slower behaviour,
default for now) or if full_state_update=False can be used safely.
warnings.warn(*args, **kwargs)
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Torchmetrics v0.9 introduced a new argument class property called full_state_update that has
not been set for this class (MinMax). The property determines if update by
default needs access to the full metric state. If this is not the case, significant speedups can be
achieved and we recommend setting this to False.
We provide an checking function
from torchmetrics.utilities import check_forward_no_full_state
that can be used to check if the full_state_update=True (old and potential slower behaviour,
default for now) or if full_state_update=False can be used safely.
warnings.warn(*args, **kwargs)
GPU available: True, used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
Trainer(limit_train_batches=1.0) was configured so 100% of the batches per epoch will be used..
Trainer(limit_val_batches=1.0) was configured so 100% of the batches will be used..
Trainer(limit_test_batches=1.0) was configured so 100% of the batches will be used..
Trainer(limit_predict_batches=1.0) was configured so 100% of the batches will be used..
Trainer(val_check_interval=1.0) was configured so validation will run at the end of the training epoch..
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Metric ROC will save all targets and predictions in buffer. For large datasets this may lead to large memory footprint.
warnings.warn(*args, **kwargs)
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
Traceback (most recent call last):
File "tools/inference/lightning.py", line 72, in
infer()
File "tools/inference/lightning.py", line 68, in infer
trainer.predict(model=model, dataloaders=[dataloader])
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 1026, in predict
self._predict_impl, model, dataloaders, datamodule, return_predictions, ckpt_path
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 723, in _call_and_handle_interrupt
return trainer_fn(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 1072, in _predict_impl
results = self._run(model, ckpt_path=self.ckpt_path)
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 1236, in _run
results = self._run_stage()
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 1322, in _run_stage
return self._run_predict()
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 1381, in _run_predict
return self.predict_loop.run()
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/loops/base.py", line 199, in run
self.on_run_start(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/loops/dataloader/prediction_loop.py", line 84, in on_run_start
self._on_predict_start()
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/loops/dataloader/prediction_loop.py", line 123, in _on_predict_start
self.trainer._call_callback_hooks("on_predict_start")
File "/usr/local/lib/python3.7/dist-packages/pytorch_lightning/trainer/trainer.py", line 1636, in _call_callback_hooks
fn(self, self.lightning_module, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/anomalib/utils/callbacks/model_loader.py", line 49, in on_predict_start
pl_module.load_state_dict(torch.load(self.weights_path)["state_dict"])
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 699, in load
with _open_file_like(f, 'rb') as opened_file:
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 231, in _open_file_like
return _open_file(name_or_buffer, mode)
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 212, in init
super(_open_file, self).init(open(name, mode))
FileNotFoundError: [Errno 2] No such file or directory: 'results/padim/mvtec/bottle/results/padim/mvtec/bottle/weights/model.ckpt'
Not sure what is causing the directory to be modified like that.
Hardware and Software Configuration

The program is run on Google Colab

Hi，have you solved the problem？

--weight_path weights/model.ckpt

@Liamkk

--weight_path weights/model.ckpt

This does temporarily fix the  issue, but I am getting another issue after running the code.
To run the code:
python tools/inference/lightning.py
--config anomalib/models/padim/config.yaml
--weight_path weights/model.ckpt
--image_path datasets/MVTec/bottle/test/broken_large/000.png
--save_path test_result
Error code:
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Torchmetrics v0.9 introduced a new argument class property called full_state_update that has
not been set for this class (AdaptiveThreshold). The property determines if update by
default needs access to the full metric state. If this is not the case, significant speedups can be
achieved and we recommend setting this to False.
We provide an checking function
from torchmetrics.utilities import check_forward_no_full_state
that can be used to check if the full_state_update=True (old and potential slower behaviour,
default for now) or if full_state_update=False can be used safely.
warnings.warn(*args, **kwargs)
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Metric PrecisionRecallCurve will save all targets and predictions in buffer. For large datasets this may lead to large memory footprint.
warnings.warn(*args, **kwargs)
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Torchmetrics v0.9 introduced a new argument class property called full_state_update that has
not been set for this class (AnomalyScoreDistribution). The property determines if update by
default needs access to the full metric state. If this is not the case, significant speedups can be
achieved and we recommend setting this to False.
We provide an checking function
from torchmetrics.utilities import check_forward_no_full_state
that can be used to check if the full_state_update=True (old and potential slower behaviour,
default for now) or if full_state_update=False can be used safely.
warnings.warn(*args, **kwargs)
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Torchmetrics v0.9 introduced a new argument class property called full_state_update that has
not been set for this class (MinMax). The property determines if update by
default needs access to the full metric state. If this is not the case, significant speedups can be
achieved and we recommend setting this to False.
We provide an checking function
from torchmetrics.utilities import check_forward_no_full_state
that can be used to check if the full_state_update=True (old and potential slower behaviour,
default for now) or if full_state_update=False can be used safely.
warnings.warn(*args, **kwargs)
GPU available: True, used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
Trainer(limit_train_batches=1.0) was configured so 100% of the batches per epoch will be used..
Trainer(limit_val_batches=1.0) was configured so 100% of the batches will be used..
Trainer(limit_test_batches=1.0) was configured so 100% of the batches will be used..
Trainer(limit_predict_batches=1.0) was configured so 100% of the batches will be used..
Trainer(val_check_interval=1.0) was configured so validation will run at the end of the training epoch..
/usr/local/lib/python3.7/dist-packages/torchmetrics/utilities/prints.py:36: UserWarning: Metric ROC will save all targets and predictions in buffer. For large datasets this may lead to large memory footprint.
warnings.warn(*args, **kwargs)
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
Predicting DataLoader 0:   0% 0/1 [00:00<?, ?it/s]qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/usr/local/lib/python3.7/dist-packages/cv2/qt/plugins" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: xcb.
But the results are saved in the specified "test_result" directory, not sure if anyone else face this issue.

@billyc97, are you running anomalib on a server. lightning script tries to display the output image(s), and this error occurs. If you don't want to show the output images, you could disable it
python tools/inference/lightning.py
--config anomalib/models/padim/config.yaml
--weight_path weights/model.ckpt
--image_path datasets/MVTec/bottle/test/broken_large/000.png
--save_path test_result
--disable_show_images

By the way we just merged a fix for some of the inference stuff, which also renames lightning.py to lightning_inference.py. This new inference approach is yet to be stable, and subject to change. Apologies for inconvenience


Uptime is always 100%

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
My services went offline and the uptime rate dropped immediately afterwards. The problem is that after 1-2 days it is back to 100%, this shouldn't happen because I have been using uptime for more than 2/3 weeks, and it should be 99 ....%
🐻 Uptime-Kuma Version
1.11.3
💻 Operating System and Arch
Ubuntu 20.04 x86
🌐 Browser
Mozilla Firefox
🐋 Docker Version
No docker
🟩 NodeJS Version
16.13.1

Where did you see the uptime return to 100%? The status page and the list on the dashboard only show uptime for the last 24 hours. If you looked there, that is the reason that it went to 100% after 24 hours.

Thanks, can I change this option and make sure it doesn't reset after 24h?

I don't think that's possible currently. You can view the uptime for longer periods on the dashboard page when opening a monitor. Someone opened a feature request 4 days ago for configurable time periods on the status page #1234 .

Thanks


Missing Interface type 100gbase-x-qsfp28

Environment

Python version: 3.9
Nautobot version: v1.2.4

Proposed Functionality
Add selection for QSFP28 (100GE) with compatibe text to netbox    100gbase-x-qsfp28

Use Case
Define accurate inetface type

Database Changes

External Dependencies

Is not sorted alaphabetically, but by speed and aplhabetically


Move IconFontAwesome from Icon into a separate package.

IconFontAwesome is now a default option for all our components, so we should replace it with custom icons.
FInd out how to separate IconLibrary and IconFontAwesome without duplication of styles.

Probable alternative to the current font-awesome: https://gorangajic.github.io/react-icons/index.html

We've decided to remove FontAwesome icons completely and release component for SVG icons instead.
See https://github.com/bcrumbs/reactackle/pull/43


Client Allocation Request for: Suzhou Paipaitao Information Technology Co., Ltd

Client Allocation Questions
Core Information

Name: Suzhou Paipaitao Information Technology Co., Ltd
Website / Social Media: www.taopaipai.com
DataCap Requested: 100TiB
Addresses to be Notarized: f1g3jdihzsfldw3byfee627f7uyapg7gwwadorgsq
Notary Requested: philippbanhardt

Hey @NBAPLUS - at this time the Filecoin Foundation is only considering data cap requests < 5TB. If you wish to request a lower data cap, then please make a new request via the app.
Thanks


fix(authentication-service): provide support to manage tokens for user logging in via Azure

Description
Provide support to manage tokens for user logging in via Azure
Fixes #1924
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Intermediate change (work in progress)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] Performed a self-review of my own code
[ ] npm test passes on your machine
[ ] New tests added or existing tests modified to cover all changes
[ ] Code conforms with the style guide
[ ] API Documentation in code was updated
[ ] Any dependent changes have been merged and published in downstream modules

@arpit1503khanna check the sonar


File not found in iOS

Hello,
I have used this plugin in my iOS Application. But when I'm running below code, I'm getting alert "Your picked this file " with path. But when I checked the path for that file, there was no file found. Tried this on simulator as well as iPad.
Can you please let me know what I'm missing.
FilePicker.pickFile(successCallback,errorCallback);
var successCallback = function(path) {
  alert("You picked this file: " + path);
}

Thanks in advance.

Resolved. I forgot to mark check in Capabilities in Xcode.


chore(template): remove wasm dev items

This removes things that were used during early development and should not be present in the final template.

Superseded by #11225.


Fixing GpuShuffleXorSync / DepthwiseConv

GpuShuffleXorSync was incorrectly casting floats to ints. One of the DepthwiseConv kernels was failing because of this error. This fixes the problem and reenables the kernel.

Can one of the admins verify this patch?


Add --validate-db to the nightly chain sync tests

https://github.com/input-output-hk/cardano-node/issues/495 mentions a corrupt DB that was caught by running --validate-db on a node. We should add this step to the end of our nightly chain sync to double check they ran correctly. This should just be a minor change to the buildkite script.

Can we close this?


serve headers to files correctly

duh ! My bad, there was no extensions to the file when downloaded with wget so I assumed just gzipped. Thanks for the heads up.
Originally posted by @k3yavi in https://github.com/databio/refgenieserver/issues/63#issuecomment-561340029
I can confirm that wget isn't getting the correct info. Can we update the headers on refgenieserver?
wget http://staging.refgenomes.databio.org/v2/asset/mm10/fasta/archive?tag=default
--2019-12-03 15:41:21--  http://staging.refgenomes.databio.org/v2/asset/mm10/fasta/archive?tag=default
Resolving staging.refgenomes.databio.org (staging.refgenomes.databio.org)... <IP_ADDRESS>, <IP_ADDRESS>
Connecting to staging.refgenomes.databio.org (staging.refgenomes.databio.org)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 800557520 (763M) [application/octet-stream]
Saving to: ‘archive?tag=default’

archive?tag=default        36%[============>                         ] 275.37M  28.3MB/s    eta 18s    ^C

I don't remember how to do this off the top of my head but there's surely a way to put headers on these files so that they are correctly interpreted by tools like wget...

apparently this is intended... you have to use wget --content-disposition if you want to use the server-suggested name
https://unix.stackexchange.com/questions/453465/wget-how-to-download-a-served-file-keeping-its-name
So, nevermind. we are already doing it correctly, it's just a wget behavior thing.

Oh, I wasn't aware of that flag, thanks @nsheff !!


Tumbr rate limit being hit (for default API key)

Since you bundle an API key it's being used too much, maybe allow the user to supply their own key?
{"meta":{"status":429,"msg":"Limit Exceeded"},"response":[]}

Should already, work, try to put your key in rip.properties.

There really needs to be some kind of documentation or just remove the default key as it's obviously being used too much. Tumblr does rate limit depending on IP as well as hits so if they've worked out this key is being bundled with this then it'll just keep getting less and less allowed hits before being limited like this.

Is there anything provided by Tumblr could be useful for RipMe ?

@rautamiekka not too sure I understand your question.

^ Tumblr-provided docs on API.

All that needs to be done is the default key needs to be removed and there should be a box asking for the API key when the user types in .tumblr.com. Nothing else can really be done.

Documentation: https://www.tumblr.com/docs/en/api/v2
I was under the impression that this API key was a registered API key for the application, in which case they would expect it to be bundled in an application (I think). I think it makes sense to have a default key and maybe prompt the user to register their own key when they try to use the default one. I think if the settings contain no API key then the default one will be used rather than prompting the user, but I'd have to check on this.

I've had the same thing happen to my own key before as I run a Chrome extension that had a lot of users. After a while Tumblr just ends up lower the limits further and further. It's even worse for things scraping the API.
Another thing you could do is just use the api v1 without a key.
Example: http://reblogalert.tumblr.com/api/read/json?debug=1&start=0
Docs: https://www.tumblr.com/docs/en/api/v1

I'm guessing there's a reason we stopped using the keyless API v1...

@metaprime looks like you've always used API v2
https://github.com/4pr0n/ripme/commits/master/src/main/java/com/rarchives/ripme/ripper/rippers/TumblrRipper.java

@OmgImAlexis I guess it's worth investigating the keyless API but something tells me each user would pretty quickly go over the rate limit.

The rate limit per IP for the AP v1 would be a lot higher than the rate limit for everyone using the API v2.

Fair enough...
Although if someone wants to provide an API v2 key wouldn't that be better?
I acknowledge that these two concerns can coexist.

Not really, the API v1 was depreciated but Tumblr still prefers that over v2 for scraping. I'll see if I can find the email thread I have with one of their devs but they basically confirmed this for one of my own projects as it causes less stress on their servers.

@OmgImAlexis excellent to know!


test_maya.py refactored: using parametrization where feasible

repeated code replaced by parameters provided by pytest.
source string and rexpected intentionally indented to match by column
to make checking year, month and date simpler.
Note, that the test_issue_104 was (and still is) failing.

Note, that the test_issue_104 was (and still is) failing.

That's probably timezone specific or something .. At least the tests on travis are passing - that's probably why we haven't caught it yet.


Refresh After ~10 secs

Depending on what computer you're running this code on, the LED matrix may refresh after 15 seconds hence not allowing you to see full development of the system. No solution has been found so far, other than running on a different computer.

A possible solution could be to update Atmel Studio.

Power brick was providing insufficient amperage to the board.


best way to pass vector data to Bluesky via yaqc-bluesky?

I'm looking for advice on how  to best acquire simultaneous vector data from a yaq daemon then pass it to Bluesky via yaqc-bluesky (if that is possible).   I want to acquire both in and out of phase components of a lock in signal (X and Y, alternatively R and theta) simultaneously, not sequentially, then pass it to detector(s) in Bluesky.
example: For a Stanford Research Systems lock-in (such as the SR830 or SR86x), the command SNAP?1,2,3,4,9  would return the simultaneously measured values of X [V], Y [V], R [V], theta [deg], and freq [Hz], as opposed to measurements taken one at a time in sequence.  SNAP?1,2 would return just X and Y. Here X and Y are the in phase and out of phase components of a sinusoidal time varying voltage (relative to a sinusoidal reference at the same frequency).  R is the vector magnitude and theta is phase  shift between signal and reference.
I see that the trait  is-sensor indicates arrays can be passed instead of single values, and that the trait has-mapping might allow the differing units [volts, degrees, hertz]  to be included as well . But BlueSky seems to want  devices to consist of 1D detectors with individual values. So does that mean the X and Y measurements need to be set up as individual channels ? Reading individual channels separately would break the simultaneous measurement requirement.  Alternatively, BlueSky allows "on the fly" measurements that return arrays (I think) but that isn't currently supported by yaqc-bluesky.
I understand  that the yaqc-bluesky client only implements a subset of the yaq functionality, so it might be this type of vector measurement  isn't possible. That too would be valuable knowledge (!) but I'm hoping there is a clear, preferable way to proceed that could be suggested.

For this use case, it looks like channel is the idea that you want. yaq sensors do support multiple channels read simultaneously, just structured as a key-value pair instead of an array
is-sensor is multi channel by default. Each channel can have its own units. Even with has-mapping, each channel can have only one unit.
has-mapping is more about adding independent axes to array channels, e.g. adding wavelengths to a spectrometer. the mapping values are not usually measured values, but either statically known or calculated off of a small number of inputs.
If you were measuring e.g. 1 second of data at 1 kHz for each measure command, you could have 1000 points for each X, Y, R, theta, freq, then use a mapping which was just a linspace of 0 to 1 to say the time for each index in each of the other arrays.
Mappings are pretty flexible, but most sensors use them in a fairly simple way where they have one (usually) channel that is a 1- or 2-d array (can be more, just most _aren't) and one 1-d array for each axis of the main channel.
The story is a little more complicated if you wish to set multiple values simultaneously:

All has-position is expected to have a single float input (with caveat for discrete positions, that they still map to a float)
You can run two different yaq daemons for each setpoint, but that has some hurdles for some devices/use cases:

depending on how "simultaneous" you need it to be, they will be different calls that go over the network, and so there will be some period of time between values being set
if you cannot establish multiple connections to the underlying hardware, we do not have a good way of handling that usecase in yaq (we've had ideas, but never actually been unworkable, so never got completed)

The problem is that we currently only have infrastructure to run one kind of daemon in a given process. There are mechanisms to share e.g. serial ports between these devices, but only if they are the same code.
This is not a fundamental limitation of yaq, just one we have not done the configuration work to be able to specify more complicated single processes
For the kind of devices you are talking about, yaqd-scpi may be flexible enough to do it (at least if you don't mix read and write to the same device)
If this is needed, we can revisit some of our ideas/provide proofs of concept for how this might work
we have colloquially called this the "heterogeneous catastrophe", though we are pretty sure solutions are possible, just haven't proven actually necessary with the kinds of experiments we have been doing.

Bluesky should be able to handle just about any numeric output you give it (any nd-array)
If you have large arrays, such as cameras, it should work, but there are technical limitations which make it not the best solution perhaps (specifically sending arrays over TCP takes a fair bit of time, so some (non-yaq) cameras will write their data locally and only provide bluesky with the info it needs to find that later) From the sounds of it, this isn't your use case, but we would be willing to work towards it if we had a use case in mind which required higher throughput than sending arrays over TCP while acquiring.
Here is the complete implementation of the "System Monitor" daemon, which gives cpu/ram/diskio/uptime of the computer running the daemon, which shows something with multiple channels that are provided in a single measure command:
https://github.com/yaq-project/yaqd-system-monitor/blob/de0900d934f63360c9e4ddb5d956403b521fb343/yaqd_system_monitor/_system_monitor.py#L24
If the iterative reading of channels in the default yaqd-scpi is too slow for your experiment's definition of "simultaneous", you may have to write a daemon that gets all of the values in one query string and then repacks them as a dictionary. The core functionality would be almost the same as SCPISensor but with some different parameterizations and a different _measure method. Happy to help get you up and running on that if you need it, we may even wish to add it to yaqd-scpi as an alternative parameterization. (possibly even able to flexibly do both)

Yes, I would welcome some help getting up and running!
Attached  I've modeled a possible  description for a lock-in-sensor (or vector sensor) on the SCPI-sensor TOML file
lock-in-sensor.  In that case, an SCPI-sensor "OUTP?1" query would an string with the value for the X channel and "OUTP?2" would return the same for the Y channel.
What I really want to do, however, is create channels X and Y (or R,θ)  from simultaneous reading, since sequential readings of a complex value (X + iY) introduce phase jitter not present in the actual data. To do so what I think I need to do is replace the QUERY that the SCPI daemon invokes  with sequential WRITE + READ commands and then return a dictionary with the X and Y channel values already filled in:
import csv
write "SNAP?1,2"
read response_string
fieldnames = ['X', 'Y']
voltage_dict = csv.DictReader(response_string, fieldnames)
lock-in-daemon.txt

Great insights @nfortune. There's a lot of details here, so let's first take a look at what this looks like on the client (Bluesky) side of things.
Once fakelockin is running, we can use yaqc-bluesky to make a Device instance that is compatible with Bluesky. Remember, the crucial methods for Bluesky to interact with a sensor are describe and read. We can call these methods ourselves.
>>> import yaqc_bluesky
>>> lockin = yaqc_bluesky.Device(39000)
>>> lockin.trigger()  # trigger starts a measurement
>>> lockin.read()
OrderedDict([('fakelockin_x', {'value': -0.10951101653121408, 'timestamp':<PHONE_NUMBER>.4567535}),
             ('fakelockin_y', {'value': 0.009573717711272384, 'timestamp':<PHONE_NUMBER>.4567535})])

Now we can provide Bluesky with our lockin instance to do an experiment. Let's try the built in plan count, which just takes num data points.
>>> import bluesky
>>> from bluesky import plans as bsp
>>> from bluesky.callbacks.best_effort import BestEffortCallback
>>> RE = bluesky.RunEngine()
>>> RE.subscribe(BestEffortCallback())
>>> RE(bsp.count([lockin], num=5)

Transient Scan ID: 2     Time: 2023-08-07 16:06:00
Persistent Unique Scan ID: '1ff98c08-9f57-47f2-a225-228dd9b60529'
New stream: 'primary'
+-----------+------------+--------------+--------------+
|   seq_num |       time | fakelockin_x | fakelockin_y |
+-----------+------------+--------------+--------------+
|         1 | 16:06:01.1 |       -0.209 |        0.109 |
|         2 | 16:06:01.3 |       -0.168 |        0.074 |
|         3 | 16:06:01.4 |       -0.187 |        0.130 |
|         4 | 16:06:01.5 |       -0.190 |        0.053 |
|         5 | 16:06:01.7 |       -0.227 |        0.104 |
+-----------+------------+--------------+--------------+
generator count ['1ff98c08'] (scan num: 2)

That output table you see is there because of BestEffortCallback. You can subscribe other useful callbacks to enable other useful features, for example Serializer from suitcase.csv will allow you to dump your data to a CSV file easily.
We ran the count plan above, but there are lots of built in plans to Bluesky.
https://blueskyproject.io/bluesky/plans.html
Beyond that, Bluesky aims to make it easy for you to write your own flexible plans. There are "plan  stubs" that you can compose together to design more sophisticated unique experiments. I won't go any further chatting about the client side, you can probably get a good start with the Bluesky documentation from here.

Now I'm going think a little bit about your actual hardware interface.
First off, a bit of context about the yaqd-scpi package. I wrote that package as a generic interface for setting and reading parameters over SCPI. It can work well for simple applications (and we do use it), but for more sophisticated hardware interaction it's probably best to just write a separate daemon. We've done this before, see for example the daemon for spectra physics millennia. That laser communicates over SCPI but the features are so complex that it wasn't possible to fit it into the "generic" mold provided by yaqd-scpi.

What I really want to do, however, is create channels X and Y (or R,θ) from simultaneous reading, since sequential readings of a complex value (X + iY) introduce phase jitter not present in the actual data. To do so what I think I need to do is replace the QUERY that the SCPI daemon invokes with sequential WRITE + READ commands and then return a dictionary with the X and Y channel values already filled in.

Exactly correct. What you want is pretty-much the same as yaqd-scpi-sensor...
https://github.com/yaq-project/yaqd-scpi/blob/main/yaqd_scpi/_scpi_sensor.py#L12
... but just change the _measure method. You suggested the SNAP command, which makes sense looking at the documentation. Using SNAP, measure might look like this (WARNING: untested code).
    async def _measure(self):
        out = {}
        self._instrument.write("SNAP?1,2,3,4")
        x, y, r, t = self._instrument.read()
        out["x"] = float(x)
        out["y"] = float(y)
        out["r"] = float(r)
        out["t"] = float(t)
        return out

Depending on your preferences, you could add other unique configuration or state to your stanford lock-in daemon.


Scala 2.12.13

seems we have to wait.
https://github.com/scoverage/sbt-scoverage/issues/319

seems we have to wait.
https://github.com/scoverage/sbt-scoverage/issues/319


not compatible with linux kernels < 5.11

In https://github.com/jow-/ucode/commit/0662de64bd1f61c2bba8792438fee8da0c706889 a dependency on linux kernels > 5.11 was introduced because of the use of fanout_args (https://github.com/jow-/ucode/blob/7611487b9a051f17e1cf9d21cc10b78071695b93/lib/socket.c#L1399).
This is a bummer for anyone trying to use ucode on devices with older kernels.
Would it be acceptable to have a compiletime check on the linux kernel used and remove fanout support in this case? I can provide a PR if wanted, but wanted to discuss this first.

Sure, adding necessary ifdefs for the various structs is totally fine.

Thanks for the quick response and PR is created :) https://github.com/jow-/ucode/pull/217


No WiFi after installing Crouton & Ubuntu (latest)

I have just gone through the process of installing Crouton and Ubuntu on an Acer C7 Chromebook.  All seems to have gone OK, but when in Ubuntu I have no internet access, yet Chrome OS does. When I open up the network prefs it tells me that "The system network services are not compatible with this version"
The network prefs pane shows "Network Proxy" in the left hand side as the only choice. I tried clicking the + button to add a wifi connection, but all I get as an option is VPN.
I have no idea how to get around this.  Will anyone help please?

@dnschneid - I am having issues connecting to the internet and having trouble navigating to the chroot. Any suggestions?

That is, connecting to the internet with Crouton.

My apologies! Totally fixed it. Sorry to bug you @dnschneid

I'm having the same problem with my C720 which I'm about to give to my grandson. Wifi works perfectly in Chrome OS, but it's not working in my chroot running Ubuntu 14.04.
Interfaces file contains the following:
"source-directory /etc/network/interfaces.d" and the directory "interfaces.d" is empty.
Thanks


ZN5boost6python5numpy10initializeEb: symbol not found

I installed boost numpy in a docker instance (alpine-3.8) and built a python extension but I cannot import the python module I built.
using ldd, I have
ldd /usr/local/lib/python3.7/site-packages/pydhs-1.6.6-py3.7-linux-x86_64.egg/dhs.cpython-37m-x86_64-linux-gnu.so
ldd (0x7f5a0cbb9000)
libboost_python3.so.1.66.0 => /usr/lib/libboost_python3.so.1.66.0 (0x7f5a0c726000)
libpython3.7m.so.1.0 => /usr/local/lib/libpython3.7m.so.1.0 (0x7f5a0c1ca000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f5a0be77000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f5a0bc65000)
libc.musl-x86_64.so.1 => ldd (0x7f5a0cbb9000)
libpython3.6m.so.1.0 => /usr/lib/libpython3.6m.so.1.0 (0x7f5a0b7df000)
Error relocating /usr/local/lib/python3.7/site-packages/pydhs-1.6.6-py3.7-linux-
x86_64.egg/dhs.cpython-37m-x86_64-linux-gnu.so: _ZN5boost6python5numpy10initializeEb: symbol not found
/work # cd /usr/local/lib64/

It looks like you're trying to use the version of this library that's now included in Boost itself (I can tell from the boost::python::numpy namespace for the missing symbol, as opposed to the boost::numpy namespace used here).  And that's certainly what I'd recommend doing; the code hosted here is deprecated and no longer maintained.  But in that case you'll be better off reporting problems at https://github.com/boostorg/python, where the integration version lives.


Hurley Typhoeus

Hey,
I was wondering what the interest would be in having a Hurley Typhoeus connection made and how best to submit that to Lost Island for review / use.
If you could share any thoughts or preferences on that, I'd love to work on that as I really enjoy working with Hurley over other clients

@kkirsche Try following my Excon example: https://github.com/lostisland/hurley-excon.

Will do. Do you want parallel / async requests exposed in a similar manner to how they were in faraday?
e.g. https://github.com/lostisland/faraday/wiki/Parallel-requests

@technoweenie X-Ref: lostisland/hurley-excon#2
Once I can load / use the exon adapter I'll have a go at Typhoeus and if that goes well probably Patron or Curb will be next


feat: support unflattening

feat: support unflattening
Description
Adds support for automatically unflattening objects.
Checklist

[x] The existing code style is followed
[x] The commit message follows our guidelines
[x] Performed a self-review of my code
[x] Hard-to-understand areas of my code are commented
[x] The documentation is updated (as applicable)
[x] Unit tests are added/updated
[x] Integration tests are added/updated (as applicable, especially if feature/bug depends on roslyn or framework version in use)

This is probably also a breaking change, as this could map members which were not automatically mapped before 🤔

This is probably also a breaking change, as this could map members which were not automatically mapped before 🤔

I'm not 100% sure about this, but should this use a reversed version of BuildMemberPathCandidates? If someone tries to Map + ReverseMap two objects, they might find that a different member path is used one way and back.
i.e. given Source -> Target is MyValueId = My.Value.Id where My.Value.Id is the last path to be tried. Then Target -> Source might be resolved as My.ValueId = MyValueId. This is because My.ValueId is tried before My.Value.Id

@TimothyMakkison I think this is rarely the case and IMO Mapperly choosing always the least nested path is the correct approach. This also maps the same field if a reverse mapping method is added with the exact same configuration, doesn't it?

As there seems to be no updates for several weeks I'm closing this for now. Feel free to reopen / open a new PR with updates 😊